🚀 go-pugleaf

W dniu wtorek, 15 sierpnia 2017 13:56:17 UTC+2 użytkownik (fir) napisał:
> W dniu sobota, 12 sierpnia 2017 12:29:24 UTC+2 użytkownik (fir) napisał:
> > W dniu sobota, 12 sierpnia 2017 12:17:53 UTC+2 użytkownik (fir) napisał:
> > > W dniu środa, 9 sierpnia 2017 22:52:17 UTC+2 użytkownik (fir) napisał:
> > > > W dniu środa, 9 sierpnia 2017 22:43:21 UTC+2 użytkownik (fir) napisał:
> > > > > while( DrawNextPixel(x_goal, y_goal) );
> > > > > 
> > > > > cos w tym stylu (kazde wywolanie wysuje czy tam wyzanacza jeden pixel) jest t mz postac jakby bardziej ogolna 
> > > > 
> > > > bardziej ogolna bylaby 
> > > > 
> > > > while( DrawPixel (NextPixel (goal)))
> > > > 
> > > > chodzi o odzielenie wyznaczanie pixeli od rysowania (i w moim kodzie tak bylo bo czasem potrzebyowalem wynikow bressenhama 
> > > > nap do algorytmu sprawdzania widocznosci a nie konkretnie do rysowania))
> > > > 
> > > > while tutaj tez powinno byc jakaz mechanika raczej wewnetrzną w jezyku tak by mozna pisac
> > > > 
> > > > DrawPixel(NewPixel(goal));
> > > > 
> > > > lub przynajmniej
> > > > 
> > > > repeating DrawPixel(NewPixel(goal));
> > > > 
> > > > bez martwienie sie przekazywaniem warunkow końca co jest nieporeczne
> > > > 
> > > > ale poki co c czegos takiego nie przewiduje
> > > > 
> > > > (dygresja)
> > > > [te rozmyslanie nad jezykiem to troche meka wiec chyba lepiej wrocic do sicla ]
> > > 
> > > w sumie mozna by sie zastanowic nad uzytecznymi funkcjami sicle w kontekscie dwu 
> > > troche znanych mi zadań
> > > - pisania asemblera
> > > - pisanie kompilatora c
> > > 
> > > o asmie chyba juz kiedys myslelem 
> > > 
> > > poczatek jak zwykle
> > > 
> > > 
> > > 
> > > #include "small-icl.c" 
> > > 
> > > int main() 
> > > { 
> > > 
> > >   chunk asm = LoadChunk("some.asm"); 
> > > 
> > >   chunks lines = SplitAfterCharacter(asm, 0x0a); 
> > > 
> > >   int asm_lines_length = ChunksLength(lines); 
> > > 
> > >   CreateFile("asm output.bin"); 
> > > 
> > >     for(int i=0; i<asm_lines_length; i++) 
> > >     { 
> > >      // use lines.beg[i]   
> > > 
> > 
> > 
> > sorry powinno byc raczej lines.first[i] (pisalem o tych pomylkach)
> > 
> > z tego co kojarze wiec powino byc 
> > 
> >  chunks words = SplitOnWords(lines.first[i]);
> > 
> >  dalej raczej przydalyby sie (jesli mowimy ciagle o ogolnych funkcjach tekstowych) pewnie sprawdzenia czy dane slowo jest slowem czy liczbą (cos w stylu funkcji check if number (?) trzebby sie tez zdecydowac czy to splitowanie na slowa ma uwzgledniac slowa z symbolami w srodku (ttaj pewnie tak i pewnie to jest troche nistandardowe, dzilenie na slowa pewnie by szlo po spacjach czyli moze lepiej uzyc SplitOnWordsByWhitespaces())
> > 
> > moze pozniej skrobne kod na sucho bo kompilowac mi sie nie chce (pisanie na suchop swoja droga wartoby sie pewnie pouczyc bo podejrzewam moze byc szybkim sposobem pisania)
> > 
> >  
> > 
> > 
> > >     }
> > > 
> > >   return 0; 
> > > 
> > > } 
> > > 
> > > w srodku trzebby chyba dac po prostu splitowanie po slowach i switche.. ale o tym troche pozniej bo jestem zmeczony jak zwykle
> > > 
> 
> w sumie jak widac napisanie asemblera (gdzie mam na mysli flushowanie hexa na output) jest raczej bardzo latwe - niewiele jest to trudniejsze niz zliczenie wystapien liter w pliku
> 
> ciagle troche gorzej z wygenerowaniem tej peowkiej obwoluty (o czym juz nieraz wspominalem) inny problem to tez problem tego 
> ze to co kiedys wydawalo mi sie 'fascynujace' (jak napisanie sobie asemblera) dzis wydaje mi sie 'nudne' (oba te slowa nie sa zbyt dokladne ale nieststy roznica jest, slowo 'nudne' jest tu chyba nawet niedostateczne
> ale chyba nie mam sily opisywac i uzmyslawiac 
> sobie tego jaki jest dzis moj psychologiczny stosunek do pisania asemblera)
> 
> tak czy owak bede jednak musial to chyba 
> (ten asembler) napisac i to chybe powinienem to zrobic najpozniej do konca roku (samej roboty przewiduje na maksymalnie tydzien ale
> bedzie trzeba uwazac chyba by sie nie zniechcecic w polowie bo jak sie zniechcece to znowu odloze ta robote na pol roku i wtedy si enie wyrobie : o )
> 
> we will see, moze przysiade w jakis chlodniejszy dzien

chyba zebym zrobil wczesniej troche roboty na sucho? (przez robote na sucho mam na mysli glownie czytanie i ew przemyslanie/przedyskutowanie paru wnioskow bez klepania i odpalania kompilatora)

co prawda od roboty na sucho tez mozna, 
wydaje sie, zniechęcic - robota na sucho 
jest chyba postrzegana jako bardziej lajtowa 
niz typowa mokra robota, jak to jest naprawde to nie wiem