speagram-devel Mailing List for Speagram
Status: Alpha
Brought to you by:
lukaszkaiser
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(16) |
Jul
(4) |
Aug
(8) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Lukasz K. <luk...@gm...> - 2005-12-22 00:47:34
|
This list has been so silent recently that Iwant to test it. - lk |
From: Lukasz K. <luk...@gm...> - 2005-01-12 01:42:04
|
Hi. I recompiled speagram and toss using Nemerle from boot/ in snapshot from 11.01.2005 version 0.2.1.99.3731. To avoid confusion with multiple snapshots please use this one if possible. In speagram there are still some warnings that have to be corrected but except for this it compiles without problems. The speagram archive inside toss is also updated to the one compiled against the latest Nemerle snapshot. - lk |
From: Lukasz K. <luk...@gm...> - 2004-10-12 21:02:44
|
Hej. Odpowiedz nalezy do cyklu rozmow autystycznych. > Ostatnio mi sie wydaje, ze jesli dac mozliwosc dodawania do kazdej funkcji > i typu jakiegos opisu (zwyklego stringa) ... Ja napisze troche wiecej jak to widze i czemu podsystemy takie jak sa nie wydaja mi sie najlepsze. Po pierwsze jak to widze: 1) kazda definicja funkcji, typu, danych oraz regula parsowania w systemie ma liste tagow 2) tag to para (key : string = value : string) 3) po starcie speagramu aktywne sa jedynie reguly z tagiem core=true, inne reguly parsowania trzeba aktywowac podajac jako argument liste tagow ktore powinny byc ustawione na zadane wartosci 4) problem identycznych nazw: moglo by sie zdarzyc, ze jakas funkcja nie jest aktywna i zostanie zdefiniowana funkcja o identycznej nazwie; moglibysmy chciec miec dwie identycznie nazywajace sie funkcje o roznych tagach - jak to zrobic ? Mysle, ze w taki sposob: Po pierwsze do kodowanej nazwy definiowanej funkcji / typu powinno byc dodawane jednoznaczne id - to pozwala trzymac w systemie funkcje o identycznych nazwach i roznych tagach. Po drugie aby korzystac z dwoch takich funkcji rownolegle trzeba dac mozliwosc aktywacji ktora dodaje wartosc zadanego tagu. Wyobrazam to sobie tak, ze jesli mam dwie funkcje fib, jedna ma tak module = foo, druga ma tag module = bar, to system powinien zachowywac sie w taki sposob: - jesli zrobie activate nil to powinien probowac aktywowac wszystkie dostepne reguly parsowania i wykryc, ze dwie sa identyczne i zglosic blad nie aktywujac nic - jesli zrobie za to activate nil with tag module, to rowniez powinien probowac aktywowac wszystkie, ale te ktore posiadaja tag module powinny go uwzgledniac, tzn. nie bedzie mozna napisac fib 3, tylko fib 3 with module = foo albo bar. Mam nadzieje, ze to wystarcza jako krotki opis mojego spojrzenia na sprawe. Sa oczywiscie rozne potencjalne wady i zalety. Oczywiscie wszystko zaczyna sie od tego, ze uzywanie podsystemow tak jak namespace w innych jezykach nie pasuje do speagramu bo wywolania funkcji nie sa standardowe. Powinno byc tez jasne, ze majac tagi da sie zrobic wszystko to na co pozwalaja podsystemy a nawet wiecej, bo mozna otagowac funkcje roznymi tagami co czasem moze byc przydatne. Jest kwestia zlozonosci, ale ja uwazam ze i tak jesli chodzi o wyszukiwanie regul parsowania, definicji typow i funkcji i danych to bedziemy musieli zmienic obecne listy na tablice hashujace, bo inaczej to nigdy nie bedzie wydajne. Jak to juz zmienimy to trzymanie wszystkiego na jednym poziomie nie powinno byc problemem, byc moze trzeba bedzie uwazniej algorytmicznie dobrac struktury danych do slownikow, zeby moc wyszukiwac po tym co potrzeba. Dla mnie tagi moga tez pomoc zrobic nasz kod czytelniejszym. Jesli to bedziemy robili to chcialbym przerzucic ciezar obecnego "named ..." na tagi, tzn. odpowiedni tag mowiacy o nazwie. Obecny system kodowania i robienia "named" nie jest niestety rzecza, ktora bedzie sie skalowac, bo ma problemy z taka sama nazwa pare razy oraz powoduje klopoty z koniecznoscia nadawania nazw wczesnie zeby mozna ich uzywac. Ogolnie to jest dziwne, ze coding jest kompilowane jeszcze zanim jest w ogole definicja systemu, potem trzeba podmieniac te dummy names na prawdziwe i myslec, zeby o niczym nie zapomniec - to nie jest ladnie a z tagami byloby ladniej. Dodatkowo okreslanie ktora regula definiuje zmienna a ktora nie (co jest wazne, bo te ze zmiennymi sa usuwane przy finalize) tez jest teraz nieco poza kontrola i daloby sie to kontrolowac tagiem. Trzeba tez bedzie kiedys umozliwic usuwanie z systemu typow i funkcji a razem z nimi trzeba wyrzucac dotyczace ich reguly parsowania. Zeby pamietac ktora regula dotyczy ktorej funkcji / typu moznaby probowac jakos to odczytac z definicji i nazw tych typow / funkcji, ale to moze nie byc takie proste i uzywanie tagow zamiast tego (no i dostosowanie struktury slownika zeby uzyskac dobra wydajnosc) wydaje sie lepszym rozwiazaniem. Rowniez sam zbior aktywych regul moze byc po prostu wyrozniony tagiem i pobierany gdy trzeba jesli typ danych slownika bedzie wystarczajaco dobrze zaprojektowany i efektywny algorytmicznie. Po przedstawieniu tych rzeczy jeszcze jedna uwaga praktyczna - to jest oczywiscie bardzo duzo roboty i nie zrobimy tego na 0.1. Ale ja bym chcial, zebysmy do tego czasu sie zdecydowali czy robimy to w ten sposob i spisali dosc porzadny design. Wyjasniam, dlaczego to jest potrzebne. Otoz musimy w miare ustabilizowac typ wiadomosci wysylanych do systemu zeby mozna oddzielic rzeczy ze speagram core i oddzielic je zupelnie od biblioteki. Biblioteke trzeba zaczac chociaz szkicowac, glownie po to zeby ludzie mogli swoje rzeczy tam wrzucac i nie musieli ich przepisywac potem od nowa ani nie kolidowali z naszymi i to jest zupelnie konieczne na 0.1, bo chociaz to nie bedzie wiele osob, ale ktos moze zaczac cos w tym pisac (!!!) i bedzie potem na nas bardzo zly jak sie tego nie bedzie dalo w zaden prosty sposob przelozyc na nastepna wersje. Oczywiscie wtedy na wersje 0.1 wyrzucilibysmy w ogole support dla podsystemow, pewnie i tak zostaniemy z jednym bo czasu jest malo a zeby to zrobic dobrze to jest jeszcze duzo pracy. Ale trzeba miec chociaz pojecie co bedziemy robic zeby przynajmniej typ wiadomosci wysylanych byl w wiekszej czesci ustalony. Napiszcie prosze, co myslicie i jak wy byscie to zrobili, no i prosze napiszcie w miare szybko. - lk |
From: Lukasz K. <luk...@gm...> - 2004-10-07 20:46:31
|
Hej. Mysle nad tym troche z Andrzejem juz od dluzszego czasu i teraz znalazlem sie w pewnej rozterce, wiec moze lepiej pomyslmy razem na liscie. Pytanie jest wg. mnie takie: czy my w ogole chcemy podsystemy ? Ostatnio mi sie wydaje, ze jesli dac mozliwosc dodawania do kazdej funkcji i typu jakiegos opisu (zwyklego stringa) i dac mozliwosc wlaczania i wylaczania funkcji z danym opisem, to bedzie to zarowno znacznie prosciej jak i znacznie uzyteczniej. Bo cale drzewo podsystemow w speagramie, gdzie notacja z kropkami ze zwyklych jezykow po prostu nie ma sensu wydaje mi sie zle, nie pasujace. Ale nie wiem, nie trafilem na razie w ogole na naturalny przyklad funkcji o tej samej nazwie. Prosze - zastanowcie sie i napiszcie. - lk |
From: rzyjontko <rz...@op...> - 2004-09-04 09:55:01
|
Lukasz Kaiser wrote: >=20 > > digitsum (nat_float (nat_cons (m, d), 1)) >=20 > Jaki warunek ?=20 Warunek opisuj=B1cy dopasowanie si=EA termu do lewej strony regu=B3y przepisywania. =AFadna liczba nie dopasuje si=EA do termu=20 nat_float (nat_cons (m, d), 1). > Choc rzeczywiscie, liczenie sumy cyfr liczb typu floating point=20 > jest dosc malo powszechnym zajeciem. Ale po co je liczysz? Ale wykluczanie u=BFy=E6 to nie jest rozwi=B1zanie. Chcesz, zmusza=E6 u=BFytkownika do szukania innych dr=F3g na osi=B1gni=EAcie celu? Musia=B3= by=B6 ka=BFdemu z osobna t=B3umaczy=E6, =BFe tak si=EA nie robi, bo tutaj podj=EA= ta zosta=B3a taka decyzja projektowa, =BFe tak nikt nie napisze. > > Samo nat_cons sugeruje, ??e liczba jest wi??ksza od 10, ale=20 > > wyk??adnik =3D=3D 1 sprawia, ??e liczba musi by?? jednocyfrowa. >=20 > Rzeczywiscie, rzutowanie jest zle, musze zmienic funkcje liczaca > wykladnik.=20 _Nic_ Ci to nie pomo=BFe. Podkre=B6lam: tego si=EA _nie da_ naprawi=E6 bez zmiany ca=B3ej reprezentacji. Nie obliczysz wyk=B3adnika, bo nie masz z czego: ta liczba nie ma warto=B6ci: to jest term - lewa strona regu=B3y przepisywania. Nie zawiera konkretnych cyfr, tylko zmienne. Jakiegokolwiek wyk=B3adnika nie u=BFyjesz: b=EAdzie =BCle. Ale nie mo=BFesz u=BFy=E6 zmiennej zamiast wyk=B3adnika, bo wtedy dopasuj=B1 si=EA r=F3wnie=BF liczby nieca=B3kowite. > Ale obsluge 3 roznych + to juz sam musisz dodac do handlerow. Z punktu widzenia generatora: + jest po prostu funkcj=B1, kt=F3ra si=EA nazywa +. Wyst=EApuje tylko po prawej stronie regu=B3 przepisywania i jest wklejany bez =BFadnego sprawdzania jakie s=B1 jego argumenty. > Moja propozycja jest taka, zeby zmienic kodowanie na: >=20 > cons_float (m, c) =3D m * 10^c To niewiele zmienia. > No a przy kodowaniu r musisz niestety policzyc cyfry znaczace po > kolei. Najbardziej znaczaca cyfra r to chyba jest Jednym s=B3owem: iteracyjnie. Te=BF o tym my=B6la=B3em, dlatego na=20 pocz=B1tku zaproponowa=B3em, =BFe mo=BFe lepiej by by=B3o, gdyby interpre= ter kombinator=F3w potrafi=B3 obliczy=E6 cz=EA=B6=E6 u=B3amkow=B1 liczby jako= liczb=EA ca=B3kowit=B1 w zapisie dziesi=EAtnym. Ale ja najwy=BFej napisz=EA sobie w kombinatorach funkcj=EA, kt=F3ra to robi i tyle. --=20 rzyjontko http://www.student.ii.uni.wroc.pl/~rzyj/ |
From: Lukasz K. <ka...@te...> - 2004-09-04 00:19:51
|
Hej. > digitsum (nat_cons (m, d)) > > jest po rzutowaniu przerabiany na: > > digitsum (nat_float (nat_cons (m, d), 1)) > > Ca??y problem polega na tym, ??e nie istnieje liczba ca??kowita > spe??niaj??ca ten warunek. Jaki warunek ? Choc rzeczywiscie, liczenie sumy cyfr liczb typu floating point jest dosc malo powszechnym zajeciem. Ale po co je liczysz? Moze jednak zadeklarowac typ argumentu digitsum jako integers i w ten sposob ominac problem (dodajac tez +, -, itp. dla integers). > Samo nat_cons sugeruje, ??e liczba jest wi??ksza od 10, ale > wyk??adnik == 1 sprawia, ??e liczba musi by?? jednocyfrowa. Rzeczywiscie, rzutowanie jest zle, musze zmienic funkcje liczaca wykladnik. Oczywiscie potrzebuje do tego wlasciwie zdefiniowanego digitsum i +, sprobuje je napisac niedlugo. Ale obsluge 3 roznych + to juz sam musisz dodac do handlerow. > Jest spory problem z precyzj?? oblicze??. Najpierw problem. Niech r > b??dzie liczb?? rzeczywist??. Jako term r jest reprezentowane w postaci: > > r = cons_float (m, c) > > co oznacza: > > r = 0.m * 10 ^ c > > ??atwo jest obliczy?? c jako: > > c = floor (1 + log (r)) > > Niestety gorzej jest z m. ??ukasz zaproponowa??, ??eby m oblicza?? ze > sta???? precyzj??. Dla ustalenia uwagi przyjmijmy, ??e precyzja jest 2, > czyli bierzemy pod uwag?? tylko 2 miejsca po przecinku. Wtedy: > > m = floor (10^2 * (r / 10^c)) Pierwsza uwaga: jesli r = 0.m * 10^c i mamy r i c to nie ulega zadnej watpliwosci, ze 0.m = r / 10^c > Przyk??ady: > r = 0.70 --> c = 0, m = 7 wydaje sie byc ok ... > r = 1.07 --> c = 1, m = 10 0.10 * 10^1 = 1.0 poprawnie > r = 7.00 --> c = 1, m = 70 tez poprawnie ... OK, ja chyba rozumiem problem - mozna sobie wywalic zera na koncu, bo tak to jest z liczbami po przecinku. Kodowanie jest niejednoznaczne po prostu. Moja propozycja jest taka, zeby zmienic kodowanie na: cons_float (m, c) = m * 10^c Nie tracimy w ten sposob zadnej dokladnosci, natomiast rzeczy sie robia latwiejsze. Nadal mamy ten sam problem z niejednoznacznoscia, ale teraz moga przynajmniej zrzutowac m na m * 10^0. No a przy kodowaniu r musisz niestety policzyc cyfry znaczace po kolei. Najbardziej znaczaca cyfra r to chyba jest d1 (r) = floor (r / 10^floor (log (r))) przyklad: r = 9002 d1 (r) = [9002 / 10^4] = 9 dalej trzeba chyba najpierw wywalic te 9000 z gory: r' = r - d1(r) * 10^floor (log(r))) -- 2 no i potem policzyc tego floor (log(r)) - 1 cyfre: d2(r) = floor (r' / 10^floor (log(r) - 1)) Po takim glupim przykladzie widac, ze to sie chyba mozna tak, zeby sobie dzielic przez 10^odpowiedniej i reszte brac mod 10. kth_digit_dividor (r, k) = 10^ (floor (log (r)) - k + 1) kth_digit (r, k) = floor (r / kth_digit_dividor (r, k)) % 10 Co myslisz ? - lk |
From: rzyjontko <rz...@op...> - 2004-09-01 16:55:28
|
Dzisiaj dalej si=C4=99 babra=C5=82em z przek=C5=82adem liczb do kombinato= r=C3=B3w. Pozwol=C4=99 sobie podzieli=C4=87 si=C4=99 swoimi spostrze=C5=BCeniami. 1. Rzutowanie ------------- Zacz=C4=85=C5=82em debuggowa=C4=87 przek=C5=82ad funkcji digitsum, kt=C3=B3= ra ma sumowa=C4=87 cyfry liczby ca=C5=82kowitej. Okaza=C5=82o si=C4=99, =C5=BCe nast=C4=99puj=C4=85= cy term: digitsum (nat_cons (m, d)) jest po rzutowaniu przerabiany na: digitsum (nat_float (nat_cons (m, d), 1)) Ca=C5=82y problem polega na tym, =C5=BCe nie istnieje liczba ca=C5=82kowi= ta spe=C5=82niaj=C4=85ca ten warunek. Samo nat_cons sugeruje, =C5=BCe liczb= a jest wi=C4=99ksza od 10, ale wyk=C5=82adnik =3D=3D 1 sprawia, =C5=BCe liczba m= usi by=C4=87 jednocyfrowa. 2. Precyzja ----------- Jest spory problem z precyzj=C4=85 oblicze=C5=84. Najpierw problem. Nie= ch r b=C4=99dzie liczb=C4=85 rzeczywist=C4=85. Jako term r jest reprezentowan= e w postaci: r =3D cons_float (m, c) co oznacza: r =3D 0.m * 10 ^ c Gdzie m i c to liczby ca=C5=82kowite (a liczba 0.m nale=C5=BCy do przedzi= a=C5=82u [0.1, 1]). Przy generowaniu kodu wynikowego musz=C4=99 w jaki=C5=9B spos= =C3=B3b obliczy=C4=87 m i c maj=C4=85c dane r. Niestety okazuje si=C4=99 to nie = takie proste. =C5=81atwo jest obliczy=C4=87 c jako: c =3D floor (1 + log (r)) Niestety gorzej jest z m. =C5=81ukasz zaproponowa=C5=82, =C5=BCeby m obl= icza=C4=87 ze sta=C5=82=C4=85 precyzj=C4=85. Dla ustalenia uwagi przyjmijmy, =C5=BCe p= recyzja jest 2, czyli bierzemy pod uwag=C4=99 tylko 2 miejsca po przecinku. Wtedy: m =3D floor (10^2 * (r / 10^c)) Przyk=C5=82ady: r =3D 0.70 --> c =3D 0, m =3D 7 r =3D 1.07 --> c =3D 1, m =3D 10 r =3D 7.00 --> c =3D 1, m =3D 70 W tej sytuacji liczba ca=C5=82kowita 7 zostanie przerzutowana na par=C4=99 (m =3D 70, c =3D 1). Jak zatem sprawdzi=C4=87, czy podany float jest cyf= r=C4=85? Nale=C5=BCy sprawdzi=C4=87, czy jego m jest jedn=C4=85 z warto=C5=9Bci (0= , 10, 20, 30...) Niestety to sprawia, =C5=BCe ten sam kod nie mo=C5=BCe by=C4=87 u=C5=BCyw= any do obs=C5=82ugi liczb ca=C5=82kowitych i liczb zmiennoprzecinkowych. Czekam na komentarze. --=20 rzyjontko http://www.student.ii.uni.wroc.pl/~rzyj/ |
From: rzyjontko <rz...@op...> - 2004-08-24 08:29:49
|
Ciesz=EA si=EA, =BFe to szybciej dzia=B3a. Teraz wi=EAkszo=B6=E6 czasu p= rogram sp=EAdza na parsowaniu w=B3a=B6ciwego pliku. Mam tak=B1 pro=B6b=EA: czy m=F3g=B3by=B6 wrzuci=E6 jak=B1=B6 funkcj=EA op= eruj=B1c=B1 na listach, =BFebym m=F3g=B3 przetestowa=E6, czy to faktycznie dzia=B3a? Przyda=B3aby si=EA te=BF jaka=B6 funkcja na liczbach ca=B3kowitych, oraz = jakie=B6 funkcje na liczbach "niepe=B3nych", cho=E6by abs (a najlepiej co=B6 bardz= iej skomplikowanego, mo=BFe podzielno=B6=E6 przez 5, albo 3). --=20 rzyjontko http://www.student.ii.uni.wroc.pl/~rzyj/ |
From: Lukasz K. <ka...@te...> - 2004-08-23 22:09:29
|
Hej. Nie jest latwe zycie w .NET. Pogooglowalem i wygooglowalem, jest cos takiego jak klasa BinaryWriter i BinaryReader. Robi sie to tak: def bw = BinaryWriter (stream); bw.Write (int, string, byte, ...) def br = BinaryReader (stream); br.ReadString () br.ReadInt32 () ... Zmienilem nasza seralizacje, zeby zamiast WriteCos uzywala tych klas, takze inne funkcje teraz ich uzywaja. Plik parsed skurczyl sie z 10 do 6 MB (nie pytajcie jak) ale niezaleznie teraz czytanie trwa tak ze 20 razy krocej, program uruchamia sie mniej wiecej od razu w przeciwienstwie do tego co bylo. Oczywscie trzeba nowe make parsed sobie zrobic. - lk P.S. W sumie to nie takie dziwne, ze przeczytanie 10MB bajt po bajcie trwa znacznie dluzej niz przeczytanie zcachowanego po 7 bajtow. Pewnie gdybysmy sami pisali i czytali stringi nie po bajcie tylko po kilka to by tez bylo szybciej, ale nie ma sie raczej co z tym bawic jak jest w bibliotece. |
From: Lukasz K. <ka...@te...> - 2004-08-23 01:07:57
|
Hej. Zrobilem pare zmian. Po pierwsze przed make check konieczne jest make parsed, ktore generuje pliki .sp?.parsed z ktorych sie potem czyta binarnie. Trzeba to przejrzec, tzn. poprawic wielkosc po serializacji i kolejnosc (teraz jest chyba odwrocone). Posprzatalem troche generator, ale nie testowalem, najpierw trzeba inne bledy poprawic. Jacek: wynik combo testu jest inny niz byl od twoich ostatnich zmian, ale moze jest poprawny, musisz to nam powiedziec. Ja tylko dolozylem do systemu jedna funkcje, ktora sie teraz bez sensu generuje do combo, ale to nie problem. Funkcja jest natomiast ciekawa: nie podobalo mi sie, ze reguly deklaruje sie =>, chcialem to zmienic na "is". No to zmienilem, ale chce, zeby => tez dzialalo. No to dodalem funkcje => i zdefiniowalem: {var_1 => var_2} is {var_1 is var_2}. No i dziala :). Aha, robie pewne testy ktore generuja Ambigous, nie przejmujcie sie tym. - lk |
From: Lukasz K. <ka...@te...> - 2004-08-20 16:24:33
|
Hej. > Zastanawia?em si? nad zmian? nazwy makra i widz?, ?e jest absolutnie > konieczna bo sugeruje, ?e makro robi co? innego. Niestety ono nie > w??cza pliku ?r?d?owego nemerle, bo musia?oby umie? go sparsowa? - > makra zwracaj? drzewa rozbioru. To makro zwraca zawarto?? pliku jako > string. Przemianuj? je na IncludeAsString. Aaa, to rzeczywiscie trzeba zmienic nazwe :). > ?eby to zmieni? trzebaby X zrobi? digit zamiast integer. Masz racje, zmienie to w weekend, trzeba bedzie zmienic tez kodowanie wtedy. - lk |
From: rzyjontko <rz...@op...> - 2004-08-20 15:21:18
|
Lukasz Kaiser wrote: > > To nie jest takie proste. Jak to jest w jezyku to nie musisz tego pisac= , > robic dllki itp.=20 Zastanawia=B3em si=EA nad zmian=B1 nazwy makra i widz=EA, =BFe jest absol= utnie konieczna bo sugeruje, =BFe makro robi co=B6 innego. Niestety ono nie w=B3=B1cza pliku =BCr=F3d=B3owego nemerle, bo musia=B3oby umie=E6 go spar= sowa=E6 - makra zwracaj=B1 drzewa rozbioru. To makro zwraca zawarto=B6=E6 pliku ja= ko string. Przemianuj=EA je na IncludeAsString. > Ok, mysle, ze to jest dobrze. Kod do wczytywania z dllek jest np. > w speagram.n jesli nie chce ci sie pisac od nowa. Poradzi=B3em ju=BF sobie. > To mi sie natomiast wcale ni podoba. To powinno byc proste, powinno > wystarczyc podac dla kazdego konstruktora funkcje, ktora go rozklada > i wtedy powinny juz wszystkie patterny dzialac, tzn. np. dla integers > musisz tylko rozlozyc pos i neg, dla naturals musisz rozlozyc na > / 10 i % 10 (czy jakos tak) a dla floatow musisz podac czesc przed, > po przecinku i expa. Chyba to bedzie prawie wszystko, czemu to jest > problem ? Interface ITypeHandler tego nie robi ? Bo sam interface to > nie wszystko, matching i tak musi byc generowany rekurencyjnie w pewien > sposob, nie mozna zwalic calej tej rekurencji na interface. Je=B6li chodzi o liczby ca=B3kowite, to faktycznie da si=EA to zrobi=E6. = Ale to tylko z tego wzgl=EAdu, =BFe konstruktor do=B3=B1cza kolejn=B1 cyfr=EA= na koniec liczby, a nie na pocz=B1tek. Co prawda odzyskanie warto=B6ci zmiennej z liczby nie b=EAdzie proste, ale wykonalne. Natomiast z floatami jest gorzej, bo np. liczba 723 ma kilka reprezentacji, wi=EAc je=B6li dopasuj=EA wzorzec cons_float (X, Y, Z) to mo=BFe by=E6: X =3D 7 Y =3D 23 Z =3D 2 albo X =3D 72 Y =3D 3 Z =3D 1 =AFeby to zmieni=E6 trzebaby X zrobi=E6 digit zamiast integer. --=20 rzyjontko http://www.student.ii.uni.wroc.pl/~rzyj/ |
From: Lukasz K. <ka...@te...> - 2004-08-20 12:14:15
|
Hej. > Ja r?wnie? przeszed?em na =. Skoro to drugie przypisanie ma zosta? > usuni?te. I chocia? zawsze by?em zwolennikiem <-, to przyznaj?, ?e > znaku r?wno?ci u?ywa si? ?atwiej i nie wydaje mi si?, ?eby zmniejsza? > czytelno?? programu. Ok. Dla czytelnosci ja w weekend zmienie to wszedzie w kodzie. > My?l?, ?e nie warto. To jest taki drobiazg, ?e ka?dy mo?e sobie co? > takiego napisa?. I po to w sumie s? makra. To nie jest takie proste. Jak to jest w jezyku to nie musisz tego pisac, robic dllki itp. No a takie include jest czasem bardzo przydatne i szkoda jest linkowac sie ciagle ze specjalna biblioteka po to. To powoduje, ze tego sie rzadko uzywa, gdyby bylo w jezyku to ja na przyklad uzywalbym tego czesciej. Poza tym w Nemerle sa rozne dziwne i malo przydatne makra, np ostatnio te do asynchronicznych rzeczy, a nie ma takiego malego ale bardzo przydatnego include, ktore jest na dodatek ciekawym przypadkiem uzycia makra. Dlatego mysle jednak, zeby wrzucic. > Propozycja > ---------- > > Aby zrobi? to w miar? mo?liwo?ci og?lnie wprowadzamy interfejs > ITypeHandler, kt?ry definiuje funkcje s?u??ce do generacji konstrukcji > termu, dekompozycji termu i matchingu. Dla ka?dego wbudowanego typu > nale?y napisa? klas?, kt?ra implementuje ten interfejs. Opr?cz tego > potrzebny jest jeszcze plik konfiguracyjny, kt?ry ??czy nazwy > konstruktor?w z odpowiednim handlerem. Oto przyk?ad dla list: > > <type> > <dll>handler-combo-list.dll</dll> > <class>LKAW.CodeGenerator.TermHandlerList</class> > <cons>list_nil</cons> > <cons>list_cons</cons> > </type> > > Przy starcie generator przebiega wszystkie tak zdefiniowane typy, > wczytuje podan? klas? z podanej dll-ki, tworzy obiekt handlera i > zwi?zuje go z podanymi nazwami konstruktor?w. Za ka?dym razem, gdy > generator napotka jeden z podanych konstruktor?w, uruchamiane s? > funkcje odpowiedniego handlera. Ok, mysle, ze to jest dobrze. Kod do wczytywania z dllek jest np. w speagram.n jesli nie chce ci sie pisac od nowa. > Dlatego na razie zostawi?em obs?ug? liczb tak jak by?a do tej pory, > czyli obs?uguje tylko "pe?ne sta?e liczbowe". To mi sie natomiast wcale ni podoba. To powinno byc proste, powinno wystarczyc podac dla kazdego konstruktora funkcje, ktora go rozklada i wtedy powinny juz wszystkie patterny dzialac, tzn. np. dla integers musisz tylko rozlozyc pos i neg, dla naturals musisz rozlozyc na / 10 i % 10 (czy jakos tak) a dla floatow musisz podac czesc przed, po przecinku i expa. Chyba to bedzie prawie wszystko, czemu to jest problem ? Interface ITypeHandler tego nie robi ? Bo sam interface to nie wszystko, matching i tak musi byc generowany rekurencyjnie w pewien sposob, nie mozna zwalic calej tej rekurencji na interface. Aha - dobrzeTo mi sie natomiast wcale ni podoba. To powinno byc proste, powinno wystarczyc podac dla kazdego konstruktora funkcje, ktora go rozklada i wtedy powinny juz wszystkie patterny dzialac, tzn. np. dla integers musisz tylko rozlozyc pos i neg, dla naturals musisz rozlozyc na / 10 i % 10 (czy jakos tak) a dla floatow musisz podac czesc przed, po przecinku i expa. Chyba to bedzie prawie wszystko, czemu to jest problem ? Interface ITypeHandler tego nie robi ? Bo sam interface to nie wszystko, matching i tak musi byc generowany rekurencyjnie w pewien sposob, nie mozna zwalic calej tej rekurencji na interface. Aha - dobrze by tez bylo przeniesc codegen do addons/codegen, co myslicie ? - lk |
From: rzyjontko <rz...@op...> - 2004-08-20 07:58:02
|
Lukasz Kaiser wrote: >=20 > Andrzej: zaczles uzywac =3D zamiast <- ? Ja mysle, zeby tak nie robic, > zostanmy dopoki sie da przy <-. Ja r=F3wnie=BF przeszed=B3em na =3D. Skoro to drugie przypisanie ma zost= a=E6 usuni=EAte. I chocia=BF zawsze by=B3em zwolennikiem <-, to przyznaj=EA, = =BFe znaku r=F3wno=B6ci u=BFywa si=EA =B3atwiej i nie wydaje mi si=EA, =BFeby = zmniejsza=B3 czytelno=B6=E6 programu. > Rowniez w ramach porzadku - Jacek - makro include jest bardzo ladne, al= e > moze byc przydatne w roznych miejscach. Proponuje, zebys je wrzucic do > Nemerle, to bedzie lepszy porzadek a i Nemerle cos zyska. My=B6l=EA, =BFe nie warto. To jest taki drobiazg, =BFe ka=BFdy mo=BFe so= bie co=B6 takiego napisa=E6. I po to w sumie s=B1 makra. Teraz b=EAdzie o generatorze. Problem ------- Chodzi o to, =BFeby mo=BFna by=B3o pewne typy term=F3w identyfikowa=E6 z natywnymi typami j=EAzyka docelowego. Propozycja ---------- Aby zrobi=E6 to w miar=EA mo=BFliwo=B6ci og=F3lnie wprowadzamy interfejs ITypeHandler, kt=F3ry definiuje funkcje s=B3u=BF=B1ce do generacji konstr= ukcji termu, dekompozycji termu i matchingu. Dla ka=BFdego wbudowanego typu nale=BFy napisa=E6 klas=EA, kt=F3ra implementuje ten interfejs. Opr=F3cz= tego potrzebny jest jeszcze plik konfiguracyjny, kt=F3ry =B3=B1czy nazwy konstruktor=F3w z odpowiednim handlerem. Oto przyk=B3ad dla list: <type> <dll>handler-combo-list.dll</dll> <class>LKAW.CodeGenerator.TermHandlerList</class> <cons>list_nil</cons> <cons>list_cons</cons> </type> Przy starcie generator przebiega wszystkie tak zdefiniowane typy, wczytuje podan=B1 klas=EA z podanej dll-ki, tworzy obiekt handlera i zwi=B1zuje go z podanymi nazwami konstruktor=F3w. Za ka=BFdym razem, gdy generator napotka jeden z podanych konstruktor=F3w, uruchamiane s=B1 funkcje odpowiedniego handlera. Dalsze problemy --------------- Rozwa=BFali=B6my z =A3ukaszem problem pojawiania si=EA zmiennych we wzorc= u lewej strony regu=B3y przepisywania, wewn=B1trz konstruktora liczb ca=B3kowitych. I tak np. abs (pos_int (X)) -> pos_int (X) abs (neg_int (X)) -> pos_int (X) O ile nie trudno sobie wyobrazi=E6 obs=B3ug=EA czego=B6 takiego, o tyle n= ie wiem jak sobie poradzi=E6 z tym: div_by_ten (nat_cons (X, nat_digit (0))) -> true div_by_ten (X) -> false Oczywi=B6cie nie trudno sobie wyobrazi=E6 znacznie bardziej skomplikowane patterny, kt=F3re maj=B1 zdefiniowanych wi=EAcej "dziur" w termie typu liczba ca=B3kowita, a co dopiero je=B6li takie dziury b=EAd=B1 si=EA poja= wia=B3y gdzie=B6 w mantysie, albo cesze liczby zmiennoprzecinkowej. Dlatego na razie zostawi=B3em obs=B3ug=EA liczb tak jak by=B3a do tej por= y, czyli obs=B3uguje tylko "pe=B3ne sta=B3e liczbowe". --=20 rzyjontko http://www.student.ii.uni.wroc.pl/~rzyj/ |
From: Lukasz K. <ka...@te...> - 2004-08-19 23:18:19
|
Hej. Przerzucilem pliki i zrobilem pare zmian, ktore koncza w pewnym sensie zaplanowany dawno temu redesign, chciaz oczywiscie jeszcze duzo trzeba poprawic. Po pierwsze mamy teraz katalog addons w ktorym znajduja sie rzeczy rozszerzajace podstawowa funkcjonalnosc core_system. Taka rzecza jest na przyklad skladnia pseudo Nemerle jaka dodalismy dla Bena i ona jest dlatego jako addon w nem_language. Generator tez powinien byc addonem, ale jeszcze tego nie zmienilem ladnie. Kazdy addon sklada sie z pliku .spg ktory dostarcza potrzebnych addonowi typow, funkcji, regul parsowania etc. oraz z dll, ktora dostarcza potrzebnych update_handlerow. Na razie jedynym addonem jest nem_language, ale jako przyklad wystarczy. Przy okazji wyrzucilem stare rzczy, ktore juz i tak nie dzialaly i testy, ktorych juz i tak nie dalo sie uruchomic. Testy wrzucilem do jednego pliku do simple_language, zeby tam straszyly zeby pamietac, ze trzeba zrobic ich odpowiedniki. Cos co sie nazywalo speagramapp nie moglo sie chyba nazywac gorzej, wiec nazywa sie core_system, ale konkurs na lepsza nazwe trwa. Andrzej: zaczles uzywac = zamiast <- ? Ja mysle, zeby tak nie robic, zostanmy dopoki sie da przy <-. Ustawilem make check tak, ze sprawdza generowane combo_code i robi diffa z wynikiem, ktory ja znam jako poprawny (mam nadzieje, ze sie nie myle). To jest troche oszukane, bo speagram.n oraz core_system.n maja zakodowane wzgledne sciezki, tzn. ze jesli sie uruchomi speagram.exe z innego katalogu to wszystko sie polozy. Jak w programie speagram.exe dobrac sie do sciezki do wywolanego programu ? Kiedys za dobrych czasow to byl chyba automatycznie pierwszy argument ktory sie dostawalo, ale teraz to ja nie wiem. Wpisalem to wszystko i inne rzeczy tez do todo zeby nie zapomniec. Jak bedziemy mieli podsystemy, to mysle, ze core_lang.spc i core_systems.spg powinny sie wrzycac do podsystemu System.Core, natomiast pluginy do swoich odpowiednio. Aha - jest core_systems.spg czytane przy inicjalizacji po core_lang.spc. Tam jest poczatek definicji messages, one beda potrzebne zeby core_system mogl robic takie rzeczy jak import regul z podsystemow, tworzenie nowych, zmienianie, czy tez np. zapisanie sie do pliku lub wyswietlenie calosci. Mielismy cos podobnego w starym language. Jak to juz bedzie to trzeba szybko wykorzystac serializacje do zapisania stanu systemu po inicjalizaji i zeby czekac tak dlugo. Mozna uzywac make zeby miec pewnosc, ze binanie zasavowany system nie jest starszy od wersji tekstowej. Ok, to chyba tyle. W ramach porzadkow - Andrzej, przejrzyj testsuite / runtest, moze to trzeba przerzucic do unit tests ? Podobnie jacek, zobacz co jest z tym gentest i byc moze wrzuc go do unit tests. Pamietaj, ze generator jest teraz w addons/generator (ale nie musisz go robic ladnym addonem, po prostu popraw gentest i ew. wrzuc go do unit_tests). Rowniez w ramach porzadku - Jacek - makro include jest bardzo ladne, ale moze byc przydatne w roznych miejscach. Proponuje, zebys je wrzucic do Nemerle, to bedzie lepszy porzadek a i Nemerle cos zyska. - lk |
From: Lukasz K. <ka...@te...> - 2004-07-19 00:17:13
|
Hej. Duzo zmian sie zrobilo i jak zwykle nie wszystko do konca tak, jak mialo byc, ale po kolei. Po pierwsze mamy katalog core_types i taki tez namespace i tam sa typy. Ze wzgledu na bug w Nemerle nie da sie deklarowac innych klas w srodku variantow, wiec jest modul terms a w nim variant Term i tak samo dla innych. To nie ma sensu dla typed terms, parse rules czy systems, mozna by tam to zmienic, ale na razie nie mialem na tyle czasu (dlatego tez niektore funkcje zostaly public static, chciaz powinny byc wewnetrzne klas). Moze sie ludzie od Nemerle obudza i cos powiedza o tym bugu, bo on zupelnie zabija kompilator. Gdyby to poprawili, to moznaby ujednolicic i usunac te zbedne zewnetrzne moduly. Na razie zostawilem tak, mysle ze jest lepiej niz bylo. Zostawilem tez osobno makra i serializacje. Mysle, ze kod sie zrobil klarowniejszy, jasne sa tez zaleznosci miedzy plikami, zeby byly jeszcze bardziej wyrazne jest Makefile tak zrobiony, ze mamy duuzo malych dlli. Nie wiem czy chcemy tak miec nadal, ale dla robienia porzadku to bylo bardzo pomocne. Co do kodowania: czesc Andrzeja pracy z kodowainem wyladowala w utils, czesc w terms.n. Natomiast ja walczylem potem z kodowaniem w glownej czesci, czyt. language. Po pierwsze oddzielilem generator i reasoner od langauge. Musialem dodac im pare parametrow i przez to nie kompiluje sie gentest.n. Nie poprawialem tego, bo jak skonczymy z tym kodowaniem to wrocimy do tego jak bylo pewnie i wtedy sie poprawi (chyba, ze gentest jest pilnie potrzebny, mam nadzieje, ze nie). Poza tym doszedlem do takich wnioskow: po pierwsze cos trzeba miec zakodowane w kodzie, zeby jakos ruszyc, ew. czytac to z plikow, ale inaczej sie nie da; najmniejsze to bez czego ja nie umiem ruszyc, to kodowanie stringow, list i typow; oddzielilem to ladnie w core_lang.n w konsturktorze. po drugie zrobilem w parse_rules.n abstrakcyjna funkcje robiaca regule z ciagu syntax_elements, ktora potem na dwa rozne sposoby wykorzystuje w core_lang.n; w ten sposob mamy reguly parsowania dla konstruktorow i dla typow dosc ladnie, znacznie bardziej przejrzyscie niz te rozne RulesOf... w language.n. dalej zrobilem w core_lang.n siedem regul parsowania, takich ad-hoc, ktore pozwalaja parsowac nazwy typow i konstruktorow; jak mozna wpisywac typy i konstruktory jest na przyklad w core_test.in w src/; przy okazji pojawil sie problem, ze separator pojawial sie w nazwach, wiec zaminiam go w typach na zastepstwo separatora - Andrzej, obejrzyj to zebys wiedzial o co chodzi, tam gdzie string.Replace w core_lang.n. poza tym core_lang.n spamietuje w tablicach hashujacych nazwy typow i konstruktorow jakie sie podaje, zeby mozna potem korzystac z nich do kodowania. Jesli chodzi o to, co robic dalej, to ja mysle, ze trzeba rozszerzyc core_test.in tak, zeby zawieral wszystkie podstawowe typy przy okazji testujac core_lang.n. Potem trzeba w core_lang.n wpisac odpowiednie, tzn. takie jakie beda wynikaly z tego pliku .in, nazwy nakonstruktory i typy. Ja sobie to wyobrazam tak, ze modul core_lang jak sie inicjalizuje, to czyta jkis plik i parsuje. Potem sprawdza, czy ma wszystkie typy bazowe w tablicy hashujacej i czy typy w tablicy zgadzaja sie z tymi, ktore sam ma hard-coded i jeslitak, to mow, ze ok. Wtedy mozna przerobic coding tak, zeby korzystal z tego modulu i jego tablic hashujacych. No a jak to bedziemy mieli, to dopisac reszte funkcjonalnosci language.n korzystajac tylko z core_lang i tego kodowania powinno byc prosto. W koncu w core_lang jest juz generacja regul dla nazw typow i konstruktorow, zostana tylko funkcje i messages. W kazdym razie uwazam, ze trzeba uzyc tego core_lang i napisac od nowa kodowanie i language i wyrzucic stare. To wyglada na duzo pracy, ale powinno pojsc szybko. Oczywiscie Jacek masz pewnie jeszcze prace z kompilacja a potem trzeba pomyslec o tych kombinatorach, wiec nad tym language bede siedzial glownie ja z Andrzejem. Prosze, poogladajcie kod i to jak to teraz wyglada i napiszcie mi albo poggadamy. Bardzo mozliwe, ze warto zmienic zaleznosci w Makefile'ach, nie przygladalem sie temu dokladnie. Jako ze niektore pliki sie zrobily calkiem duze, moze warto zaczac uzywac np. #region zamiast albo dodatkowo do naszych ogranicznikow, co myslicie ? - lk |
From: Lukasz K. <ka...@te...> - 2004-07-12 20:25:02
|
Hej. > Niestety generowanie nie dzia?a dop?ki si? nie ma naprawionego > queue.n, wi?c zr?bcie sobie "svn up", "make" i skopiujcie Nemerle.dll > z katalogu out.stage3. To byloby tyle jesli chodzi o moje marzenie, zeby pozostac przy Nemerle 1.4 a nie latac znowu po snapshotach. Mam nadzieje, ze zbootstrapuja niedlugo i sie przesiadziemy na jakis snapshot, bo mi sie nie chce kompilowac co chwile kompilatora. Ale oczywiscie ty uzywaj tego z dobrym queue, my sie przerzucimy jak tylko snapshot sie pojawi. - lk |
From: rzyjontko <rz...@op...> - 2004-07-12 20:15:29
|
Uda=B3o mi si=EA wygenerowa=E6 drzewa if=F3w dla "standardowych" funkcji: appenda, makepair i copylist. Jakby=B6cie dysponowali przyk=B3adami innych funkcji, to ch=EAtnie potestuj=EA. Niestety generowanie nie dzia=B3a dop=F3ki si=EA nie ma naprawionego queue.n, wi=EAc zr=F3bcie sobie "svn up", "make" i skopiujcie Nemerle.dll z katalogu out.stage3. --=20 rzyjontko http://www.student.ii.uni.wroc.pl/~rzyj/ |
From: rzyjontko <rz...@op...> - 2004-07-04 23:43:56
|
Zwr=F3ci=B3 mi co=B6 takiego: --> TestGenerateFunc=20 LKAW.Speagram.Common+InternalError: I.Reasoner.1 in <0x004dd> LKAW.Speagram.Reasoner:AllSubstitutions (LKAW.Speagram.Term) in <0x00040> _N_lm__N_l4628_4631:_N_l4628 (object) in <0x00163> Nemerle.Collections.List:RevMap (Nemerle.Core.list,Nemerle.I= nternal.Func1) in <0x0001a> Nemerle.Collections.List:Map (Nemerle.Core.list,Nemerle.Inte= rnal.Func1) in <0x00481> LKAW.Speagram.Reasoner:EqualForAll (LKAW.Speagram.Term,LKAW.= Speagram.Term) in <0x0004a> _N_lm_eq_f_a_5056:eq_f_a (object) in <0x00149> Nemerle.Collections.List:Find (Nemerle.Core.list,Nemerle.Int= ernal.Func1) in <0x003e5> _N_lm_filter_eq_forall_5043:filter_eq_forall (object,object) in <0x00193> LKAW.Speagram.Generator:NormalizeTermList (Nemerle.Core.list= ) in <0x00717> LKAW.Speagram.Generator:Generate (LKAW.Speagram.Term_type,in= t) in <0x0031d> LKAW.Speagram.GeneratorTest:TestGenerateFunc () --=20 rzyjontko http://www.student.ii.uni.wroc.pl/~rzyj/ |
From: Lukasz K. <ka...@te...> - 2004-06-22 09:55:18
|
Hej. > Czy mam te? napisa? garbage collector? Bo te funkcje b?d? gubi?y > termy w trakcie dzia?ania. Nie nie nie - wlasnie nie. Cala zabawa ma polegac na tym, ze nie ma zadnego garbage collectora a my dajmey nastepujaca gwarancje - jesli piszesz programy liniowe (ilosc zmiennych po lewej = ilosci zmiennych po prawej) to beda one szybkie i efektywne pamieciowo. Potem bedziemy optymalizowac, zeby sprawiac zeby programy byly jak najbardziej liniowe, ale to potem. Jesli jakas zmienna z lewej strony wystepuje kilka razy po prawej to musisz uruchomic copy (term) i zrobic jej gleboka kopie, jesli jakas po lewej nie wystepuje po prawej, to musisz uruchomic free (term) i zrobic glebokie free, trudno. - lk |
From: rzyjontko <rz...@op...> - 2004-06-21 16:58:39
|
Czy mam te=BF napisa=E6 garbage collector? Bo te funkcje b=EAd=B1 gubi=B3= y termy w trakcie dzia=B3ania. --=20 rzyjontko http://www.student.ii.uni.wroc.pl/~rzyj/ |
From: Lukasz K. <ka...@te...> - 2004-06-21 13:34:00
|
Hej. > Czy ja dobrze rozumiem jak to ma wygl?da?? Czy dla zadanego systemu > ma si? wygenerowa? plik ?r?d?owy C, w kt?rym s? zdefiniowane funkcje > systemu? Tak. Pewnie on bedzie korzystal z jakiegos recznie napisanego pliku C z definicjami np. typu Term, poza tym chcemy miec mozliwosc podlaczania niektorych funkcji i typow zewnetrznych, tzn. napisanych recznie w C, (np. arytmetyki). Ale zasadniczo tak jak mowisz. - lk |
From: rzyjontko <rz...@op...> - 2004-06-21 13:22:20
|
Czy ja dobrze rozumiem jak to ma wygl=B1da=E6? Czy dla zadanego systemu ma si=EA wygenerowa=E6 plik =BCr=F3d=B3owy C, w kt=F3rym s=B1 zdefiniowan= e funkcje systemu? --=20 rzyjontko http://www.student.ii.uni.wroc.pl/~rzyj/ |
From: Lukasz K. <ka...@te...> - 2004-06-17 23:05:17
|
Hej. Robimy przesiadke na ostatni snapshot Nemerle (16.06). Na razie dziala operator przypisania "<-" ("=" tez), wiec to zostawilem. Poza tym uzywam makr StructuralEquality oraz StructuralHashCode, wiec Equals i GetHashCode trzeba pisac recznie tylko dla wariantow. Napisalem glupie GetHashCode dla typow i termow - trzeba je zmienic na troche madrzejsze, tzn. uwzgledniajace argumenty. W kazdym razie po tych poprawkach i drobnych dodatkach w wyswietlaniu informacji oraz tu i tam genarator dziala dobrze, tzn. tak jak myslalem ze mial dzialac. Pewnie jeszcze troche trzeba tam przejrzec kod, ale zasadniczo to fajnie, no a Jacek moze sie powoli zaczac zajmowac czytaniem i pisaniem dokladniejszego designu do generowania kodu C :). - lk |
From: Lukasz K. <ka...@te...> - 2004-06-09 01:01:06
|
Hej. Generator znowu dziala :). Trzeba sie tam jeszcze przyjrzec czemu czasem przy generacji funkcji jest depth < 0 (na razie wykomentowalem) oraz czy nie ma jakichs trywialnie zapetlajacych sie funkcji typu f (x) => f(y), ale dziala. No i kod nawet jest przejrzysty teraz :). Fajnie :). Poza tym dodalem normalizacje i usuwanie powtorzen po drodze przy generacji, ale troche nieefektywne. Zeby dzialalo zupelnie dobrze, to niewatpliwie bedzie potrzeba jeszcze przynajmniej trzech rzeczy: 1) funkcji cmp dla typow i termow, zeby moc sortowac termy i zmniejszyc zlozonosc usuwania duplikatow po normalizacji (n^2 -> nlogn dla n ok. 10000 juz cos, przynajmniej w teorii). 2) zrobic specjalna wersje funkcji Rewriter.Normalize, ktora nie zmatchuje z X symbolu funkcyjnego, tylko i wylacznie konstruktor. Problem polega na tym, ze czesto sie pisze w funkcji na koncu taki pattern co matchuje wszystko, no i wtedy jesli pod tym jest przy generacji symbol funkcyjny, to on tez odpada a to jest przy generacji zle, takie leniwe wtedy nie powinno miec miejsca. 3) wyjasnic sprawe z GetHashCode, zeby byly w Nemerle i dzialaly tez u nas jakos sensownie (nie wiem na ile te z System.Object sa ok). Poza tym przydalby sie jakis parametr verboseness w generatorze, zeby moc sie orientowac gdzie sie jest w tej generacji jak sie czeka tak dlugo. No ale to szczegoly, zasadniczo kod jest przejrzysty i dziala fajnie :). Aha, no i moze to nasze doTest.script wrzucic do Makefile jako make check czy jak to powinno byc ? - lk |