Ej, ale to by niemądre było. W Pythonie też tak to dziala, że jak trzeba (bo się nie mieści) to vm automatycznie konwertuje na większy typ, który dalej nazywa się tak samo (reprezentacja w pamięci nie jest jawna):

Python 3.4.2 (default, Oct  8 2014, 14:33:30)
[GCC 4.9.1 20140903 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a=300
>>> type(a)
<class 'int'>
>>> a=a**a
>>> type(a)
<class 'int'>

A w luaconf.h jest taka definicja:

#elif defined(LUA_INT_LONG) /* }{ long */
#define LUA_INTEGER     long

więc raczej 2+2 będzie typu long int.

Niestety działa to na tej samej zasadzie pod Windows/Linuksem/etc - tak, jeśli ktoś stworzył "bindings" do danej biblioteki. Dałoby się zrobić, pytanie czy byłoby to używalne.

@Skrzyp: spróbuje to jakoś w miarę obiektywnie ocenić, ale łatwo nie będzie ;) bo do czego i jak porównać? Konsola interaktywna odpalona na 8Mhz STE działa żwawo i pozwala eksperymentować z cechami języka z 21-wieku.

Mój pomysł był taki, żeby po pierwsze: przypomnieć sobie ANSI C, niekoniecznie w ujęciu total retro. Jak widać kod dosłownie z dzisiaj da się w PureC skompilować, no i teraz logicznie rozumując: Lua lubi się z C, więc przy odrobinie samozaparcia można spróbować "ożenić" to co przychodzi z PureC czyli GEMLIB z Lua. Znów osobiste eksperymenta - bo raz: nie znam GEMLIB (fajnie byłoby poznać), dwa nie znam Lua. Same korzyści jak widać i całkiem kształcąca zabawa ;). Aa no i jednym z założeń było działanie na Mist w trybie STEroids.

A co do współpracy z systemem - out of the box nie różni się niczym od Lua na PC. Obsługuje wejście i wyjście, plik da się otworzyć, przetworzyć, zapisać. Dla mnie szok, że jest coś takiego jak shell dla ST i to nie jeden. Gulam w każdym razie jest super.

Na moim Side1 w oryginalnym romie też był. Jakoś trzeba było spartycjonować nową kartę więć musiał być :). Na 64KB nie chciał działać, więc robiłem to pod Altirrą i kopiowałem obraz na kartę dd pod Linuksem.

Literówka, powinno być D3:>FDISK.COM (albo D3:FDISK.COM). Musi działać.

Pin, w W7 jest takie w miarę zaawansowane narzędzie do partycjonowania i na 100% da się to w nim zrobić (chodzi tylko o założenie dwóch partycji, bez uszkadzania/kasowania APT-a). U mnie problem jest w drugą stronę - Windows używam do zabawy ;) i go nie znam.

Zawsze możesz to zrobić np w gparted live-cd, te narzędzia linuksowe są po prostu bardziej przewidywalne.

Można utworzyć FAT16 do wymiany danych między PC a SDX i FAT32 dla side loadera. Przy starym side loaderze, FAT32 musi być pierwszy. Nie pytajcie mnie jaki to jest stary... U mnie w Side1 od Zaxona to taki jeszcze bez scrolla, lubię go bo jest minimalistyczny i jakieś gry mi na nim działały, a na tym ze scrollem na dole nie. Stary loader mam w Side, nowy z obsługą montowania atr/pbi w U1MB i tak jest ok.

Tutaj było więcej: http://www.atari.org.pl/forum/viewtopic … 90#p181490

Muszę się zmobilizować i nakręcić krótki filmik jak to się robi ;) bo temat jakoś dziwnie powraca, a nie jest to trudne do ogarnięcia. Może we wtorek się uda.

Hej Spencer. Sprawdzilem jeszcze raz i masz rację, tabulatorów z utf-8 nie konwertuje. Nie zauważyłem tego, bo edytor w Action! konwertuje taby na spacje przy zapisie.  Są opcje podmiany niekonwertowalnych znaków, np. --unicode-subst= ale na to pewnie już wpadłeś.

Ten błąd z makrem w stdio.h:

#if defined(__GLIBC__) && !defined(__UCLIBC__) && !__GLIBC_PREREQ > (2, 16)
_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
#endif

Brakuje mu operatora binarnego, bo pewnie makro się zmieniło w międzyczasie :)

Tabulatory konwertuje chyba ok (screen).

To ja dziękuje! Bez tabeli mapowań (nad którymi musiałeś się sporo nasiedzieć) nie mielibyśmy takiego fajnego narzędzia :)

Kompilacja na Windows nie będzie problemem, tylko w tym momencie szkoda mi było czasu na zabawę z mingw :) o wiele chętniej sprawdzam "co tam Panie nowego w Pythonie", bo od jakiegoś czasu stałem się niekompatybilny z wersją 3.