[HK][Furor] Külső, C nyelven írt libek használata egy Furor programból

Drága felebarátaim és trollocskáim! Ma a ti szeretett Harold bácsitok arról mesél nektek, miként is lehet élni ama roppant varázslat csodálatos lehetőségeivel, hogy imádott Furor programotokat megtámogassátok az Erő hatalmával... Mármint, egy külső library erejével!

Mindenekelőtt bemutatom magát a Furor progit ami egy külső libet használ. A prograny maga:

"++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>."
sto brainfuckstring // A fenti brainfuck program string változóba mentése
::: brainfucklib "libraries/libupulib_brainfuck.so.1.0.1" // Betöltjük a külső libet
:brainfuck brainfucklib "brf" // Betöltjük a brf nevű függvényt a libből a brainfuck kulcsszóba
@brainfuckstring brainfuck // használjuk a függvényt
end
{ „brainfuckstring” }
{ „brainfucklib” }

Az a sok plusz meg más izémizé az elején, egy stringben, az természetesen egy brainfuck program. Amiatt van benne a Furor progiban, mert ez a példaprogram azt mutatja be, miként lehet e brainfuck programot (a stringet) végrehajtatni egy külső lib által. Előbb azonban íme maga a Furor outputja:

Hello World!

Természetesen, e fenti szöveget nem maga a Furor írja ki közvetlenül, ez a brainfuck progi futtatásának eredménye... aki nem hiszi, járjon utána, aminek módja az hogy kimásolja a fenti brainfuck stringet és lefuttatja egy tetszőleges brainfuck interpreter által...

Na és most az, miként kell megírni a külső libet a Furorhoz. Ezt nem kell sokat magyaráznom, bemutatom az egész libet:

#include <stdlib.h>
// ........................................
#include "headers/upu_defines.h"
#include "headers/upu_branchprediction.h"
#include "headers/upu_daysofweeks.h"
#include "headers/upu_logol.h"
#include "headers/upu_upuu.h"
#include "headers/upu_strdescriptor.h"
#include "headers/upu_str.h"
#include "headers/upu_furor.h"
// **********************************************************************************************
// **********************************************************************************************
void brf(struct furorpgm *f) {
str s;s=mem(64000);streq(&s,f->d[ELS+f->d[0].g-1].u);
brainfuck(s);free(s);
f->d[0].g--;
}
// **********************************************************************************************
// **********************************************************************************************

Nem hosszú ugyebár... Ja, hát persze hogy nem hosszú, mert a trükk benne az, hogy a string„osztályom” (nem igazi osztály mert sima C nyelvű) már eleve tartalmazza a brainfuck interpretert, megírtam a magam stringjeire még jó régen... maga a lib tehát mindössze előkészíti a stringet e célra, aztán meghívja rá a megfelelő függvényt hogy „ihol ni, csináljáááá mááá' vele valamit...”

A string pointerét a lib természetesen a Furor progi stackjából kaparássza elő, aztán amikor a brainfuck lefutott, ki is törli a stackból mert nem illik a szemetet a más vermében bennehagyni...

Maga a lib természetesen úgy készítendő el, hogy lefordítjuk a megfelelő gusztustalan beállításokkal amik ilyenkor szükségesek Linux környezetben, és hozzálinkeljük a szükséges külső könyvtárakat is, jelenesetben azt ami a stringjeimről szóló sok roppant okosságot tartalmazza. (meg még két másikat is. Mondjuk az egyik nem lenne muszáj, de hátha később kibővítem valamivel s akkor kelleni fog nekije). Ezt a sok undorító szörtyögést a következő szkript futtatásával oldom meg:

#!/bin/bash
UPUULIB="libupulib_upuu.so.1.0.1"
LOGLIB="libupulib_log.so.1.0.1"
STRLIB="libupulib_str.so.1.0.1"
OPTS="-O2 -funsigned-char -funsigned-bitfields -Wall -Wno-long-long -Wextra -Wunused -Wunknown-pragmas -Wredundant-decls -Wunreachable-code"
gcc $OPTS -shared -fPIC upulib_brainfuck.c -ldl -l:libraries/$UPUULIB -l:libraries/$LOGLIB -l:libraries/$STRLIB -o libupulib_brainfuck.so.1.0.1
mv libupulib_brainfuck.so.1.0.1 ./libraries

Na már csak magának a Furor proginak a magyarázatával vagyok adós. Ez a következőképp müxi magát:

A 3 darab kettősponttal kezdődő sor betölti magát a libet úgy cakpakk. A betöltés a brainfucklib nevű változóba történik; a változó nyilvánvalóan a lib pointerét kapja meg. Ez futásidőben történik, természetesen.

Most jön a nagy varázslás! Amikor a compilerem egy olyan kulcsszóhoz ér a tokenizálás végefelé, amit eddig nem tudott értelmezni, de egy darab kettősponttal kezdődik (jelenesetben ez a

:brainfuck

kulcsszó)

akkor feltételezi, hogy „hm, ez valami olyan függvény lesz amihez nekem semmi közöm mert egy pluginból lesz betöltve később, runtime”.

Ekkor végigbogarássza a forráskódot (az elejétől!), hogy akad-e még olyan kulcsszó benne ami teljesen ugyanaz mint ez amit most talált, de nincs az elején kettőspont. Ezeknél a tokenkód egy speciális 8 bájtos mezőjébe beleteszi az előbbi kettősponttal kezdődő tokenkód címét...

Na most amikor a kettősponttal kezdődő mnemonikra (illetve, az ennek helyére bepakolt tokenkódra...) kerül a vezénylés futásidőben, akkor ő annak rendje s módja szerint betölti a megfelelő pluginfüggvényt. (Ha nem sikerül, akkor természetesen egy morcos hibaüzenet kiszenvedése után abortál). A betöltött függvény pointerét elraktározza egy speciális helyen a tokenizált kódban. Később ha a kettőspont nélküli utasításokra kerül a vezénylés, akkor a korábbi tokenizálási mágia hatására ezen utasítások tudják, hogy ők melyik „kettőspontos” utasításhoz tartoznak, hiszen ismerik annak a címét, így onnan előszedik a pluginfüggvény címét, és végrehajtatják azt, átadva neki a Furor progi pointerét... És innentől kezdve minden a pluginfüggvény felelőssége, melynek teljhatalma van a Furor progi fölött!

Ennyi az egész!

Szerintem ezt remek munka volt megcsinálnom, megérdemlem a virtuális vállveregetést. Gondoljatok bele, nem kell mindenféle bonyolult módon megnyitogatni a libeket a programból hogy dlopen meg más anyámkínja, mindent elintéz a compiler, összelinkeli ami összetartozik, a betöltött függvényhez olyan kulcsszót rendelsz amilyent csak úri kedved óhajt, s aztán azt ugyanúgy használhatod mint bármely más kulcsszót ami a Furor nyelv alapvető része... Igazán előkelő megoldás!

Hozzászólások

>> Ezt a sok undorító szörtyögést a következő szkript futtatásával oldom meg:

valamilyen build-rendszer (akár gnu make) használatán gondolkodtál már?

Én egyszerűen azért ismertem el e mondás igazát, mert rengetegszer tapasztaltam magam is. Mármint azt hogy rém nehéz beleélni magunkat egy másik programozó gondolkodási stílusába. Lehet ott akármennyi megjegyzés, dokumentáció, akármi, akkor is. Azaz tényleg igaz hogy könnyebb új kódot írni from scratch mint egy meglevőt módosítani.

Az más kérdés, ez nem mindig előnyös. Elvégre a régi kód már bizonyított általában, azaz kapott bugfixeket stb. Szóval nem azt mondom mindig jobb dolog új kódot írni, nem mindig hasznosabb, de egy biztos: KÖNNYEBB! És élvezetesebb is... Utóbbi szempont nekem, aki csak hobbysta vagyok, különösen fontos.

Ja, profi programozó meg úgyse leszek soha. 55 évesen hova erőlködjek?!

Szóval nekem kissé mások a szempontjaim mint a profiknak. Nem mindig mások, de néha igen. Én ezt a programnyelvet is ÉLVEZETBŐL fejlesztem...

Obsessed commandline-maniac.

Igen, használom a GNU make programot. Az egész Furor fordítása nálam csak annyi, hogy beírom:

make

A fenti szkriptet úgy használom, hogy természetesen a make hívja meg a megfelelő helyen. Pontosabban, a make nem ezt hívja meg hanem egy libraries.sh nevű szkriptet, ami sok más efféle szkriptet meghív maga is, többek közt meghívja ezt a fent bemutatott szkriptet IS.

Mindennek az az oka, hogy a tulajdonképpeni Furor program futtatható binárisához szükséges hozzálinkelni egy csomó ilyen-olyan libet amiket szintén magam írtam, ezeket tehát előbb elő kell állítani.

Na most mielőtt elkezdenél gúnyolódni, sietve elébemegyek a kritikának és elismerem önként, nyilvánvalóan meg lehetne oldani ezt sokkal előkelőbben, egyetlen Makefájl alkalmazásával, külső szkriptek nélkül. És bár van Makefile nálam, mégis így oldottam meg. Hm, miért is? Hát roppant egyszerű: szimplán mert nem elég mély a tudásom a make rejtelmeit illetően!

A make-nak csak a legalapabb alapjaival vagyok tisztában, bevallom becsületesen. És semmi de semmi kedvem nincs is jobban elmélyedni benne mert annyit már tudok róla hogy tele van ordas baromságokkal (azaz nekem nem tetsző dolgokkal). Például hogy tabulátorral kell kezdődjön némely sora, stb... De különben is áttekinthetetlenül bonyolult az egész istenverése. Néha olyan érzésem van, a make alkotója írt a programjához egyetlen Makefile fájlt még akkor régen amikor a make maga készen lett, s azóta mindenki csak ezt az eredeti ősi Makefájlt módosítgatja kissé, próba-szerencse alapon, amíg valahogy működni nem kezd mert senki se érti a működését...

Oké, a fenti utolsó mondatot kissé gúnyból írtam, de tényleg egy szörnyű katyvasz a szememben. Biztos képes lennék megtanulni rendesen, de elfogadhatatlanul hosszú időbe telne attól tartok, s annyit nem ér meg. Mondom, a legalapabb dolgokat ismerem belőle amennyi nekem kell, oszt' jóóóvan...

Mit csodálkozol ezen, bevallottam hogy hobbyprogramozó vagyok.

Obsessed commandline-maniac.

"Drága felebarátaim és trollocskáim! Ma a ti szeretett Harold bácsitok arról mesél nektek"

Ez a stílus újabb kitiltáshoz fog vezetni.

Gondoltam, szólok még időben.

Mert miért? Szerinted nincsenek trollok a HUP-on? Vagy az lenne sértő hogy "felebarátaim"?

Vagy ne lenne jogom úgy vélekedni, én "szeretett" vagyok legalább némelyek szemében?

Vagy tilos magamat bácsinak titulálni? Elárulom neked, teljes joggal mondom magamról hogy bácsi vagyok, mert épp ma március 26-odikán van az 55-ödik születésnapom! Ezzel az életkorral némi joggal mondható hogy bácsi vagyok, lévén hogy a HUP látogatóinak jelentős százaléka jócskán fiatalabb lehet nálam.

Obsessed commandline-maniac.

És? Láthatóan sokan errefelé arra is mindent elkövetnek hogy az én bicskámat nyitogassák... Néha még te is ezek közé tartozol sajnos. Nem, te nem trágárkodol, de keserű és fanyar, talán cinikusnak is nevezhető beszólásokkal szurkapiszkálsz, igyekszel állandóan elkedvetleníteni és a fáradozásaimat lekicsinyelleni.

Ezekhez a dolgokhoz képest (most még nem is rólad beszélek elsősorban ebben a mondatban) az én stílusom még kifejezetten irodalmi legalább, mondhatni művészi, mert tényleg olyan mint egy mese. Még ha minden más értékétől el is tekintünk, de legalább nem trágár, mint egyesek némely beszólása errefelé.

Obsessed commandline-maniac.

Milyen megkötések vannak a betöltendő függvényekre? Hány argumentumot fogadhatnak? Csak 1-et? Mi lehet a szignatúrájuk? Nem úgy volt, hogy minden adattípusod duplapontosságú lebegőpontos szám? Van string is? Milyen karakterek lehetnek egy string literálban? Milyen kódolásban kerül átadásra a külső függvény számára? 

Ne csinaljunk ugy, mintha egy interpreter irasa ekkora feladat lenne, nagyjabol vegtelen mennyisegu DSL van mar igy is a vilagon. En is csinaltam mar SQL-like szkriptnyelvet alkalmazashoz, nem akkora ordongosseg, ha az ember elotte egy whiteboard mellett vegiggondolja.

Ebben kivételesen még egyet is értek veled, nézz csak vissza a blobjaimban, valamelyikben el is ismertem nem akkora nehézség egy interpretert megírni mint a legtöbben hiszik.

Ettől függetlenül azonban akkor is tény marad, hogy én ezt csinálom, sőt MEG is csináltam már többször, korábban, akármekkora nehézség is de bebizonyítottam hogy képes vagyok rá, neutrino azonban ezt nem mondhatja el magáról, ő csak piszkálódni tud, beszólogatni „a pálya széléről”.

És hát tudod az úgy áll gelei, hogy minden vitánk ellenére rólad tényleg simán elhiszem hogy képes vagy magad is egy interpreter megírására, sőt ezt soha nem is kétlettem rólad. De neutrino esetén semmi esetre se mernék erre nagy összegben fogadni. Sőt még kicsiben se.

Obsessed commandline-maniac.

Nem olvastad el figyelmesen a blogbejegyzést. Világosan leírtam benne, a függvény amit betöltt, futtatáskor egyetlen paramétert kap csak meg (automatikusan): az épp futó Furor program struktúrájára mutató pointert! Aztán abból a függvény dolga hogy kibányássza a neki kellő paramétereket. Például a veremtárból, vagy a bájtkód tokenéből vagy akárhonnan. Az ő dolga. Megkapta a pointert, innentől kezdve teljes hozzáférése van mindenhez.

És nem, még véletlenül se úgy volt hogy minden adattípusom dupla pontosságú lebegőpontos szám! Fogalmam sincs honnan vetted ezt a tévhitet, ilyet soha az életben sehol se állítottam, mert épp az az egyik célom kezdetektől fogva, hogy a nyelvem számos adattípust támogasson!

Talán azzal kevered, eredetileg lebegőpontos számokból csak a double-t akartam támogatni valóban, de aztán meggyőztek róla hogy kéne a float is. Oké. De ettől még kezdetektől támogatva volt a mindenféle egész típusok használata is, meg a stringeké is.

Jelenleg a köüvetkezőket támogatom:

—string (saját típus, hossztárolós, stb)

—double

—float

—unsigned long long (8 bájtos)

—signed long long (8 bájtos)

—unsigned int (4 bájtos)

—signed int (4 bájtos)

—unsigned short int (2 bájtos)

—signed short int (2 bájtos)

—unsigned char

—signed char

—UNICODE karakter (a legtöbb esetben úgy viselkedik mint az unsigned int), 4 bájtos

A stringjeimben tetszőleges UNICODE karakter használható, amint a Furor címkéiben és változóneveiben is. A stringjeim minden egyes eleme 8 bájtos, azaz egy union aminek sizeof mérete pont 8 bájt. Ennek alsó részén van eltárolva a karakter UNICODE számértéke, azaz nem az UTF-8 bájtsorozata! De természetesen van rá lehetőség hogy e stringeket átalakítsuk a „normál” C-szerű stringre ami záróbájtos és ami az UTF-8 szekvenciáőkat tárolja. Kiiratásnál ez például automatikusan meg is történik...

Igen, tudom, az UNICODE tárolásához elég lenne 4 bájt is, a stringjeim mégis 8 bájtos egységekkel nyomulnak. Ennek oka hogy nálam szinte minden e stringtípusra épül, ebben vannak letárolva bizonyos esetekben a pointerek is, a tokenkódok is, stb. Ez tehát nem __csak__ egy string, hanem egy annál sokkal funkciógazdagabb adatstruktúra, osztály, vagy hogy nevezzem! Nyilván ez tekinthető a tárhely pocséklásának bizonyos értelemben, elismerem, ugyanakkor viszont rendkívül kényelmes sok szempontból. Emellett amiatt is döntöttem így, mert mély meggyőződésem, ha ma találnák fel a bájtot, az nem 8 hanem 64 bites egység lenne...

Obsessed commandline-maniac.

Az arcus cotangenssel nem lesz semmi baj, sőt, semelyik másik picit is ismertebb matematikai fügvénnyel sem, mert ezek ALAPBÓL támogatva lesznek a Furorban, bármiféle külső lib nélkül is! Fixen bele lesznek építve, lesz hozzájuk mnemonik meg minden... a nyelv szerves részei lesznek. Ezt réges-rég eldöntöttem, különben meg így volt a régebbi nyelveimben is. Ennek oka hogy egyrészt mérhetetlenül tisztelem a matematikát, volt is egy jó hosszú szakasz a gyermekkoromban amikor kifejezetten matematikus akartam lenni... Végül nem lettem az, de hála az akkori nagy felkészülésnek, állítom hogy kimagasló matematikai tudással rendelkezem, átlagemberekhez képest. Nyilván, azt elismerem, egy igazi matematikustól fényévekre vagyok... De továbbra is nagyon tisztelem és szeretem a matematikát, és emiatt egyszerűen elképzelhetetlennek tartom hogy a matematikai alapfüggvények ne legyenek támogatva „default” a nyelvemben!

Ami a „mások által írt” libeket illeti, azt majd még meglátom hogyan oldhatnám meg. Utána kell néznem. Nem mondok nemet az ötletre alapból, maradjunk ennyiben. De semmi esetre se mostanában lesz implementálva, mert ennél jóval fontosabb dolgaim is vannak perpillanat. Például, egyelőre még egy nyamvadt IF utasítás sincs a nyelvemben... Sietek megjegyezni, nem azért nincs mintha olyan marha nehéz volna implementálni az IF-et, hanem mert azon gondolkodom, milyen legyen a szintaxisa. Tudod, nem először említem, sajnos hajlamos vagyok arra hogy elboruljon az agyam és olyan jelölésrendszert implementáljak hogy később néha magam is azon csodálkozom, ekkora ordas hülyeség hogy is pattanhatott ki a fejemből...

Nem, ez nem igaz az egész nyelvemre. De néha megtetszik egy ötlet annyira hogy bele se gondolok a milyenségébe, lázas buzgalommal azonnal nekiállok lekódolni... Elég jól programozom ahhoz hogy bármit viszonylag hamar megcsináljak na és ez ilyenkor visszaüt. Mert ha nagyon nehéz volna, maradna időm a megoldáson töprengeni, s rájönni hogy hm, amit kitaláltam megoldható de nem érdemes...

Szóval most kissé inkább visszafogom magamat, és megrágom a további dolgokat, hogyan lenne legalább némileg emberbarát a szintaxis. Amit eddig megcsináltam, az oké, vállalható, mert sokszorosan bizonyított az eddigi nyelveimben. De ami ezután jön azon töprengeni kell...

Szóval a mások által írt libek támogatásának ötletét felvettem a mentális to-do listámra, oké, jó ötlet, köszi, de a prioritási sor vége felé kapott csak helyet. Még nem tudom hogyan lesz meg, lehet hogy egyszerűen teszek a nyelvbe valami mnemonikokat a dlopen-re meg más hasonlókra, a paramétereiket majd kiemelik a stackból... Ez megoldható, nem is nehéz, ezt meg tudnám csinálni most is egyetlen óra alatt, csak valami előkelőbb megodást szeretnék, szóval ez végszükség esetére marad.

Obsessed commandline-maniac.

Meggondoltam magamat. Nem jó dolog, ha a brainfuck progi végrehajtása a string„osztályom” része. Mi a fenének, ez a funkció ritkán kell... átpakoltam ezt inkább magába a libbe. Most így néz ki a brainfuck library kódja:

#include <stdlib.h>
// ........................................
#include "headers/upu_defines.h"
#include "headers/upu_branchprediction.h"
#include "headers/upu_daysofweeks.h"
#include "headers/upu_logol.h"
#include "headers/upu_upuu.h"
#include "headers/upu_strdescriptor.h"
#include "headers/upu_str.h"
#include "headers/upu_furor.h"
// **********************************************************************************************
void brainfuck(str s);
// **********************************************************************************************
void brf(struct furorpgm *f) {
str s;s=mem(64000+f->d[ELS+f->d[0].g-1].u[0].g);streq(&s,f->d[ELS+f->d[0].g-1].u);
brainfuck(s);free(s);
f->d[0].g--;
}
// **********************************************************************************************
// **********************************************************************************************
// ==================================================================================
void brainfuck(str s) {
if(s==NULL) {return;} if(s[0].g==0) {return;} if((s[1].g-s[0].g)==0) {return;}
usag length;length=sizeof(union upuu)*(s[1].g-s[0].g);
usag d;usag k;usag p;p=0;
usac *m;m = (usac *)&s[ELS+s[0].g];
usag i;for(i=0;i<length;i++) {m[i]=0;}
k=0;
while(k<s[0].g) {
switch(s[k+ELS].c[0]) {
default: k++;break;
case '<' : if(p==0)      {return;} else {p--;k++;} break;
case '>' : if(p>=length) {return;} else {p++;k++;} break;
case '+' : m[p]++;k++; break;
case '-' : m[p]--;k++; break;
case '.' : printf("%c",(char)m[p]);k++;break;
case ',' : m[p]=(usac)getchar();k++;break;
case '[' : if(m[p] > 0) {k++;} else {d=0;for(i=k+1;i<s[0].g;i++) {
           if(s[i+ELS].c[0]=='[') {d++;} else {
           if(s[i+ELS].c[0]==']') {if(d==0) {k=i+1;break;} else {d--;}}}
           } // for vége
           } // else vége
break;
case ']' : d=0; for(i=1;i<k;i++) {if(s[k-i+ELS].c[0]==']') {d++;} else {
                                  if(s[k-i+ELS].c[0]=='[') {if(d==0) {k=k-i;break;} else {d--;}}}
                                 } // for vége
break;
} // switch vége
} // while vége
}
// =======================================================================

Obsessed commandline-maniac.

Nézd, kb. bárki a szakmabeliek közül ránéz erre a kódra, és ez a kérdés fel fog merülni benne. Ez egy teljesen jogos kérdés, mivel ha megnézed, a C kódot nagyon nem így szokták formázni. Okkal nem. Ha szerinted egy jogos kérdés kötekedés, ám legyen.

És mielőtt még azt gondolnád, hogy ez nem fontos... De igenis az, ilyen szinten formázatlan kódnál már igen. Ami egy rendesen formázott kódnál azonnal látszik (hogy mi mi alatt van, mi a struktúra), az itt nem, hanem kapcsos zárójeleket kell keresgetni állandóan, mire rájön az ember, hogy egy adott else éppen melyik if-hez tartozik, a for ciklus most épp melyik if-en belül van, stb.

Debugolni se a legegyszerűbb az ilyen kódot, mivel ha soronként léptetsz, akkor egy csomó mindent végrehajt.

De mindegy, végülis megválaszoltad a kérdésemet.

Szerintem ez egy abszolút áttekinthető kód. Majdnem minden case ág kifér egyetlen sorba. ÉN EZT TUDOM ÁTTEKINTENI, s attól amit te tartasz a „szokásos” formázásnak, engem kiver a veríték, és kurvasokáig tart amíg kiismerem magamat egy olyan kódon!

És nem te vagy az első itt a HUP-on aki a formázási stílusomba köt bele, úgyhogy kezd rohadtul unalmas lenni. Majd ha közzéteszem a programnyelvemet, eressz rá egy automatikus kódformázó eszközt, sok ilyen van, ingyenesek is, és légy boldog vele. Nem értem miért kell ilyesmiből ekkora felhajtást kerítened.

NEKEM ÍGY TETSZIK, én EZT tudom áttekinteni, és többek közt épp amiatt utálom olyan rohadtul a Pythont mert azt nem tudom a saját ízlésem szerint megformázni!

És teljesen mindegy mit válaszolsz erre, az lenne a legjobb ha semmit se mert ÚGYSE TUDSZ MEGGYŐZNI, és azért nem mert ez tényleg ÍZLÉS kérdése, ízléseken meg nem érdemes vitatkozni, és épp az emberek ízlése a legnehezebben megváltoztatható. Sőt mi az hogy a legnehezebben, jószerivel lehetetlen...

Obsessed commandline-maniac.

És nem te vagy az első itt a HUP-on aki a formázási stílusomba köt bele

Most nekem ez egy picit olyan, mint a viccben, mikor a nagyapa felháborodik, hogy nem érti miért mondja a rádió, hogy valaki szembe megy az autópályán, mikor mindenki más is szembejön. Van a szakmában jó pár dolog, ami mai napig útkeresés. De van rengeteg olyan dolog, amiről tudjuk, hogy van helyette jobb. Azért "köt" bele ebbe ennyi ember, mert ez is ilyen.

Nem értem miért kell ilyesmiből ekkora felhajtást kerítened.

Azért, mert az ilyenek nehezítik a megértést (ld. a nehezebb a kódot olvasni, mint írni című rész), debugolhatóságát és nagy mértékben növeli a hibák elkövetésének valószínűségét.

Velem jönne szembe egy ilyen kód rewviewra, én is gondolkodás nélkül nyomnám lá a rejectet és dobnám vissza.

Miért olyan nehéz megérteni, hogy ez NEM team-work hanem egyemberes? Azaz, ha ÉN épp EZT a formázási stílust tudom jobban áttekinteni, akkor az úgy van jól!

Elég képtelenség azt hinnetek, majd most a projectem közepén átszokom egy másik stílusra. Ízléseket megváltoztatni a legnehezebb.

A továbbiakban az összes, a formázásra vonatkozó kritikát ignorálom, mert nincs időm ilyen piszlicsári hülyeségekkel törődni. Time is money.

Obsessed commandline-maniac.

"hogy ez NEM team-work hanem egyemberes"

Csakhogy valamilyen okból közzétetted, és a drága, mélyen tisztelt olvasóid, akikért élsz, nem tudják felfogni. Pedig többen is próbálkoznak.

Kicsit ez is olyan, mint a nyelvtan. Vannak a szabályok, amik útmutatást adnak, hogyan illik írni, és vagy te, aki nagy ívben szarsz rájuk, mert neked az szíved joga. Megmagyarázni mindent meg lehet, a saját oldaladról igazad is van, de ezzel a hozzáállással elveszted az esetleges segítőidet.

Nem engem, engem már régen elvesztettél. 

Eloszor celszeru lenne, ha leulnel, es kitalalnad a szintaxisat. Nem kell mindent az elejetol a vegeig, de ugy nem kezdenem el implemetalni, hogy meg az elagazasod nem tudod hogy fog kinezni. Sajat nyelvet meg nem irtam (na jo, ilyen egyszerubb virtualis gepes interpretert igen, Brainfuckhoz, meg sajat URISC varianshoz), de jopar olyan libraryt igen, aminel kesobb jottem ra, hogy ezt nem igy szeretnem hasznalni. Ha a hasznalatat (leendo szintaxist) eloszor interpreter nelkul kitalalod - esetleg irsz benne par programot ugy, hogy meg nem tudod tenylegesen futtatni - akkor az ilyen hasznalat kozben kenyelmetlenne valo dolgok kiderulnek.

A string feleslegesen tud brainfuckot, ezt latom, hogy kesobb javitottad.

A tipusok koze felvennem a sima byte tombot. Python 2 es 3 kozott az volt az egyik lenyeges kulonbseg, hogy a 3-ban szetvalt a string a bytes-tol. Akkor jon nagyon jol, ha massal kommunikalsz (pl. soros porton vagy TCP/IP-n).

Ha nem ismered a Lisp-et, nezd meg! Keves ennyire egyszeru szintaxisu, valoban hasznalt nyelv letezik, bar a szamolas a tiedhez hasonloan nem annyira magatol ertetodo. (az sem infix)

A forraskod jelenleg nagyjabol a CJAM-mel van egy szinten olvashatosag szempontjabol. Ez nem jo, ugyanis az egy nagyon specialis celu nyelv (mellesleg az is stack alapu, csak code golfra). Igazabol ehhez kepest tenyleg nem tudom mi bajod pont a python szintaxisaval (jo, a whitespace szokatlan eleinte).

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

A pythonnal az a bajom bő 99 százalékig hogy az indentálásos marhasága... hogy a behúzásnak jelentése van benne. Talán még szeretni is tudnám ha nem volna ez benne de így nem vagyok képes rá...

A byte tömb mint típus lehet hogy bele lesz véve, így elsőre jó ötletnek tűnik, köszi!

Elágazás különben már van benne, ma megcsináltam, most nincs időm de később írok majd róla hogyan oldottam meg.

Obsessed commandline-maniac.

Én egyszerű nyelvként a LUA-t szoktam ajánlani. Nagyon kicsi az interpretere, viszonylag kicsi az opkód-készlete. Nem véletlen, hogy a pár megabyte flash-sel rendelkező SOHO routerekben levő OpenWRT is lua-val csinálja a konfiguráláshoz szükséges dinamikus webet. A Linux kernel + apróságok mellett más nyelvre nincs hely a pici, akár 4 MB-os flash-ben.

$ ls -l /usr/bin/lua5.3
-rwxr-xr-x 1 root root 244056 márc  22 16:48 /usr/bin/lua5.3

A luajit már nagyobb falat, de az is ennyi:

$ ls -l /usr/bin/luajit
-rwxr-xr-x 1 root root 510112 márc  22 16:48 /usr/bin/luajit

Ezen felül csak az alaplibeket használja mindkettő.
 

Jo a Lua, minimalisan hasznaltam mar (iGOhoz irtam kodot, hogy a Lua-t hasznalo UI is tudjon Androidos esemelyeket kuldeni), de a Lisphez kepest bonyolult a szintaxisa. BTW a uLisp megy Atmega328P-n is: http://www.ulisp.com/show?1LG8 bar ez nem tudom mennyire hasznalhato. Gyakorlatilag egy zarojelezest kell tudnod ertelmezni, ami ugyan CF nyelvtan, de abbol pont a legegyszerubb. Ha nem akarsz parsert irni, akkor meg mindig felhasznalhatsz egy mar letezot (pl. XML/YAML), es csak a kiertekelest kell hozzatenni. Mondjuk a Furor ezeknel mar fejlettebb.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin