Számrendszerek és a bevezető nullák

Egy apró kellemetlenség, amit bash-ben könnyű elkövetni, nekem legalább is sikerült. Alkönyvtár neve ilyesmi:

20140024.123

Ebből az első 4 számjegy az év, utána a pontig az, hogy az év hanyadik napja van. Igen ám, de ha ez nullával kezdődik, a bash oktálisan értelmezi, így aztán a 0008-ra hibát fog dobni. Amire nem, az is helytelenül lesz feldolgozva.

Így aztán le kellett csippentenem a vezető nullákat. Amíg nem kaptam hibaüzenetet, elkerülte a figyelmem.

( bucko | 2014. 01. 24., p – 22:00 )

Ha elfogadsz egy jótanácsot, kihagyod a pontokat! Higgyél nekem, már több mint 20 éve csinálom. :)
Aláhúzást meg csak a .. használnak. (Tetszőleges ledorongoló szó helyettesíthető.)
Ha meg olyan szenior fejlesztő akarsz lenni, mint akivel én dolgoztam, akkor csak UUID alakú fájlneveket használsz! (pl. 0be3a278-9737-40a0-a994-7bf6ef7cf3cf)
Azt jóval könnyebb olvasni. :(

Azon túl, hogy semmi baj a ponttal egy alkönyvtár nevében, erről azért mégis csak az IBM-et kellene meggyőznöd. ;) Azt a software-t, amelyik ezt így csinálja, ők írták, a szerveren már így van az anyag, nekem a feldolgozása jutott, amit elsőre el is böktem, mint fentebb írtam.

Tavaly év vége felé ez nem tűnt fel, hiszen pl. a 308. napja az évnek hármassal kezdődik, azt a bash még decimálisan értelmezte.

Egyértelműen én vagyok a hibás, pusztán azért írtam róla blogot, mert nagyon könnyű ebbe beleszaladni. Elkerülte a figyelmem elsőre.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( poliverzum | 2014. 01. 24., p – 22:07 )

Ember, hálás köszönetem e postodért! Épp e pillanatban írom a doksit a programnyelvem eddig elkészült részéről. Na és pont az efféle dolgok miatt amikről a postodat írtad, döntöttem úgy már évekkel ezelőtt, hogy ha majd írok egy programnyelvet, abban nem lesz olyan ökörség, hogy a kezdő nulla oktális vagy bármi más számrendszert jelöljön. Nálam az oktális számrendszert az jelzi, ha a szám az „o” vagy „O” betűvel kezdődik...

Mondom ezt rég eldöntöttem, be is építettem a nyelvembe már, épp ezen percekben írom róla a doksit, de gondoltam megkukkolom a HUP-ot új hírek után... Erre belefutok e blogodba! És mély elégedettséget éreztem az olvasásakor, mert megerősített abban, hogy íme nagyonis helyesen döntöttem a nyelvem előzetes megtervezésekor!

Gondolom valami Poliverzum Language vagy ilyesmi akart lenni.

Egyebkent a szamitogepek hoskoraban meg elterjedten hasznaltak a 10-es es 16-os szamrendszerek mellett 8-ast. C-ben (es ami szintaktikailag azt masolja) emiatt maradt benne.
A hup-on idonkent feltunik egy szegedi szamitogepes kiallitas, ott is van ilyen gep, ahol 3 bites csoportok vannak (es oktalisan szamol a mernoki pultja).

--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.

Nem az a baj hogy van oktális számrendszer, hanem ez a hülyeség, hogy a kezdő nulla jelzi hogy ő oktális.
A másik az, hogy ez amiatt is logikátlan, mert a hexa számokat meg a 0x jelzi. Na most ugye a 0x is nullával kezdődik. Azaz ha az interpreter be is olvassa az első nullát, ebből még baromira nem tudja, ez miféle szám akar lenni.

Nálam tehát ez most így van a nyelvemben:

Kezdőkarakter:

0-9 : Decimális szám
% : bináris szám
$ : hexa szám (Ez amiatt is kedves nekem, mert már a C-64 esetén is így volt, az ottani assemblyben).
o vagy O : oktális szám

További vezérlőkarakter-jelentések, de csak bizonyos esetekben:

A-Z vagy a-z : Az illető karakter ASCII kódja, azaz önmaga
' : Az aposztróf utáni karakter ASCII kódja, kivétel nélkül, akkor is ha az nem kiiratható karakter vagy ha valami whitespace.

Akad még pár más variáció is, de azok hosszabb magyarázatokat igényelnének. Általában arra törekszem, s nemcsak az aritmetikai kifejezések kiértékelésénél de a teljes nyelvi struktúra megvalósításánál is, hogy az interpreternek ne kelljen bonyolult döntéseket hoznia futás közben, és adatokat tárolni veremtárban vagy máshol későbbi feldolgozás céljára, hanem az hogy mit kell épp csinálnia, teljesen világosan következzék abból, épp melyik interpreter-rutin/függvény fut, annak mely pontján tart épp a program, valamint hogy épp miféle karaktert olvasott is be a forráskódból. Az persze megengedett, hogy e karakterrel esetleg indexeljen bizonyos belső táblázatokat alkalomadtán.

Ez különben roppantmód hasonlatossá teszi interpreteremet a Turing-gépekhez, mert azok is az „állapotgép” modellre épülnek, aholis a gépnek van pár „állapota”, s ebből meg a „szalagról” beolvasott karakterből következik, mit kell csináljon, s ezután milyen másik „állapotba” kerül a gép. Természetesen miután én egy „mindennapi feladatokra HASZNÁLHATÓ” interpretert tervezek, nálam azért az ilyesmi még így is jócskán bonyolultabb, mint egy elméleti célokra kitalált hótt-egyszerű Turing-gépnél, szerintem ha egzakt módon összeírnám hányféle „állapota” lehet az interpreteremnek, néhány ezer alatt biztos nem úsznám meg, de azért amennyire csak lehetséges ezen idea felé törekszem, eddig sikerült is követnem ezen célomat, még nagyon nehéz sem volt, azaz állíthatom hogy a hasonlóság igazán szignifikáns és meggyőző!

a problemat nem oldottad meg, lasd az alabbi kodot:

o12345 = 123;
orig_val = o1234;
Orig_val = o12345;

Ezzel igy konkretan megolted az o es O-val kezdodo valtozok lehetoseget, hacsak a valtozokat nem prefixeled mondjuk Ŧ-vel, hogy biztosan egyedi legyen.

Es ami meg szebb, hogy igy az elso karakter alapja nem tudod eldonteni, hogy az most valtozo vagy szam, lasd ezt:
o12332342348234786239462394234b, ebben az esetben egeszen a vegeig fel kell parseolnod, es csak a legutolso karakter beolvasasanal tudod eldonteni, hogy az szam vagy mas token.

C eseteben a valtozo [a-zA-z_]-vel kezdodhet, epp ezert, hogy kapasbol el lehessen donteni, ami pedig szammal kezdodik a kovetkezo alaku ([0-9]*|0[0-7]*|0[xX][0-9a-f]|0[bB][01]*) az pedig szam.

Nem, nem érted a koncepciót! :)

Ahogy pld a Bash esetén a változók prefixe a $ jel, úgy nálam a @ jel.

Ennek megfelelően az alábbi jelölések mind ugyanazt a változót határozzák meg:

@A
@'A
@65
@$41
@%1000001

Az természetesen nyilvánvaló, hogy e fenti variációkból a legelső, a @A stílusú a leggyorsabban feldolgozható az interpreter számára, de az csak akkor használható, ha a változó kódja egy kiiratható karakter, sőt kifejezetten épp betű.

E két variáció:

o101
O101

szintén a decimális 65 értéknek felel meg, de a változókra utaló @ jel után nem használható, mert ott az „o” vagy „O” karakter önmaga ASCII kódját jelenti. Használható azonban ezen oktális jelölésmód más esetekben, amikor nem változók nevét (indexét) jelöli, hanem valami egyéb szerepe van.

Továbbá, változók indexét megadhatjuk más változókkal is:

@@@$a0

Ez C nyelvre átírva kb a következőknek felelne meg:

@$a0 » v[160] // Mert $a0 = decimális 160
@@$a0 » v[v[160]]
@@@$a0 » v[v[v[160]]]

és így tovább.

Megjegyzem, vannak ennél érdekesebb lehetőségek is, amikoris egy memóriacímen tárolt unsigned char érték is megmondhatja a változó indexét, s persze azt hogy épp melyik memóriacímről van szó, azt is megadhatjuk egy változóval, ami a fentiekhez hasonlóan lehet akármennyire is többszörösen indirekt...

Nyilvánvaló persze, efféle ravaszságokra a legtöbbször nem szorulunk rá, többnyire elegendőek az olyasféle alakok hogy @a, @d, @F, stb. De azért jó dolog e lehetőség alkalmanként azt hiszem. Véleményem szerint, aki szereti a Perl nyelvet, hamar megbarátkozik majd az én nyelvemmel is. Bár reguláris kifejezések még nincsenek benne. De ezt ne csodáld, még az elején tartok. Az majd „coming soon”... Igazából azokkal az a bajom, hogy sajna akad pár egymásnak gyökeresen ellentmondó „szabvány” a regexpekkel kapcsolatban, másképp értelmezi azokat még pár mindennaposan használt linuxos program is (hogy például melyik karakter speciális jelentését kell bekapcsolni vagy épp kikapcsolni), meg „alap” regexp és „kiterjesztett” regexp, mindenféle olyasmik hogy mikori szabványokat használ egy-egy implementáció, meg hogy „lassú” vagy „mohó” kiértékelés, és én csak kapkodom a fejemet, nem támadt még ihletem arra vonatkozóan, melyik lenne a legjobb nekem, melyik mellett kötelezzem el magamat.

Emiatt is van az hogy egyelőre abbahagytam a fejlesztést, amíg meg nem írom a Világirodalom legrészletesebb doksiját addig a pontig, ameddig a nyelvem már elkészült. Volna ugyan kedvem fejleszteni tovább, nincsen abban hiba, de direkt visszafogom magamat, hogy NEM, előbb ameddig eljutottam, addig legyen kész a full doksi.

( bAndie9100 | 2014. 04. 19., szo – 10:46 )


fn=20140024.123
year=${fn:0:4}
doy=${fn:4:3}
if [ 10#$doy -ge 152 -a 10#doy -le 243 ]; then echo Nyár vagyon.; fi

a törtrész a fajlnévben a netidõ?

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack