Clipper, CCC

Nyaraláskor szoktam egy-egy nagyobbat lökni a CCC-n. Régebbi nyarakon készült a többszál támogatás, kivételkezelés, mostanra azonban nem látok magam előtt ilyen jelentős munkát, ui. a CCC3 meglehetősen készen van (önfény:).

Megemlítem itt, hogy a CCC3 a Unicode/UTF-8 támogatásban tér el a CCC2-től, és már tavaly ősz óta készen van. Ugyanezt a lépést kellene megtennie a Pythonnak, de már legalább egy éve nem jutnak 2-ről a 3-ra. Olyan kiváló nyelvben pedig, mint a Ruby (a Linuxvilág cikke szerint) még híre sincs a Unicode/UTF-8-nak. A késlekedés oka (szerintem), hogy nem tudják visszafelé kompatibilis módon megoldani a Unicodera áttérést. Namost vagy olyan okos valaki mint a Jávások, akik eleve (10+ éve) beépítették a nyelvbe a Unicodeot, vagy le kell nyelni a békát, amit az inkompatibilitás jelent. A CCC-vel az a helyzet, hogy a CCC2 továbbra is karban van tartva, ezzel fordulnak a Latin-1/2 kódolást használó régebbi, nem portolt alkalmazások, az új, többnyelvű programok viszont CCC3-mal.

A Python és Ruby el van árasztva mindenféle csatolókkal a legkülönfélébb külső modulokhoz. A CCC-ben ezt nem tudjuk utólérni, egy-két dolog azért nálunk is készül. Most pl. SSL támogatás:

Lett egy (kis) SSL függvényinterfész könyvtár (triviális). A socketek (fd-k) kaptak egy burkoló osztályt. Az SSL kapcsolatok is kaptak egy burkoló osztályt. Ezek az osztályok nem az OOP szépsége kedvéért készültek, hanem, hogy az egyforma interfészek lehetővé tegyék, hogy ugyanaz a program (az SSL bekapcsolásától eltekintve) egyformán működjön plain és secure socketekkel.

A _kis_ jelző, azt jelenti, hogy a függvényinterfész nem tartalmaz mindent (nem is értek mindent), de a fontos dolgokat igen. A CCC program képes SSL kapcsolatot felvenni, szerver és kliens oldalon hitelesíteni a másik felet és természetesen titkosítva kommunikálni.

Ha már, akkor a websrv-t kiegészítettem SSL támogatással. A websrv az egyik kedvenc programom. Egy demó web szerver, ami nem versenyezhat ugyan az Apache-csal, de azért van benne néhány dolog: CGI, PHP, SSI és most HTTPS támogatás. A websrv többszálú és (ami legfontosaabb) a forráslistája még mindig nem éri el az 1000 sort.

Régen volt már kiadósan tesztelve a websrv. A mostani teszt alkalmával 3 óra alatt 1 millió HTTPS lekérdezést szolgált ki (100 request/sec). Egyszerre 8 wget kliens volt a támadó. A szerver átlagosan 5-6 szálon futott, időnként elérte a 8-at. A lekérdezések 20%-a php oldal volt. Egy ilyen teszt leginkább a multithread kezelés stabilitását méri.

Ha már, akkor a Jáva terminálos programokat (jtlib) is kiegészítettem SSL támogatással, ezek most saját erőből tudnak hitelesíteni, titkosítani. Persze továbbra is használható az sslforward.

1-2 hétig nem volt frissítve a CCC. Nem lehetett kommitolni az svn szerverbe. Ráadásul nyáron 14400-as internetem van, az is rögtön megszakad, ha fúj egy kis szél, ezért nem volt könnyű megtalálni a hibát. Végül rájöttem, hogy az a baj, hogy az svn nem bír olvasni a /dev/random-ból (blokkolva olvasná, de nem jön belőle semmi). Nem tudtam jobbat kitalálni mint, hogy újraindítottam az egész gépet, amivel lenullázódott a 388 napos uptime.

Mellesleg az eset mutatja, hogy valamennyire az uptime is informatív, pl. jelzi, hogy előfordulnak-e ilyen apróbb hibák.

Üdv mindenki!
Eléggé elvetélt próbálkozás, de azért elkezdtem gyúrni ezeket a neuron hálókat.
Van valaki köztetek, aki ért ezekhez? :D
Lenne pár kérdésem.

Hello!
szagolgatom a neuronhálós kódolást.
A "tudást" ugye a neuronok közötti kapcsolat erősségével lehet kifejezni. Namost ahhoz, hogy maradandó legyen a tudás, ahhoz le kéne azt tárolni.
Ez pedig úgy néz ki, hogy van 3 tömböm, melynek elemei objektumok

arr1:={objNew(),objNew(),...,objNew()}
arr2:={objNew(),objNew(),...,objNew()}
arr3:={objNew(),objNew(),...,objNew()}

Miképpen tudom jól eltárolni ezen tömböket?
Az arr2bin() nem tud mit kezdeni az ojjektumokkal.

CCC upgrade után a programom indításkor elszállt adatbázis hibával. Megnéztem a
változásokat és azt olvastam hogy CCC a bytea típus kezelésénél a 8.1.x Postgresql
verzió által kedvelt megoldást alkalmazza.
Ezekszerint mostantól kötelező ennek a használata, vagy van valami megoldás a
7.4.x-es hez igazítani.

A CCC2 nincs már fejlesztve, viszont fontos alkalmazások vannak benne. Ezért a CCC3-beli jt és sql2 könyvtárban történt fejlesztéseket backportoltam CCC2-be:

A Jáva terminálban nem volt sok változás.

Az sql2-nek csak egy kezdetleges változata volt CCC2-ben, ez most följött a mai szintre.

Emlékeztető: A CCC2 és CCC3 közötti fő eltérés, hogy az előbbi nem különbözteti meg a karaktereket és byteokat. Az utóbbi a karaktereket unicode-dal ábrázolja, a bytesorozatok számára pedig egy új típust használ. Ezt készülnek meglépni a Python 3-ban is. A CCC3-ban már egy éve kész van. A Jáva a kezdetektől ilyen volt.

Sziasztok, érdekelnek valakit DEB csomagok, és azok telepítése? CCC3 van DEB csomagban, és írok róla Wikit, ha van rá igény.

w

Korábban is tudtam, hogy a GNU Jáva és a Mono Boehm-féle konzervatív szemétgyűjtéssel működik. Csak nem jól értettem, miről van szó. Azt ui. fel sem tételeztem, hogy a Jáva és a Mono ne rendelkezne saját szemétgyűjtéssel. Ezért azt hittem, hogy a "Boehm-féle konzervatív" egy algoritmust jelent, amit implementáltak a Monoban.

Hát nem így van. A Boehm szemétgyűjtés egy kész implementáció, könyvtár (libgc), ami eleve installálva van az Ubuntun. Ezt a könyvtárat _tetszőleges_ C program belinkelheti. A "konzervatív" jelzőn azt értik, hogy a szemétgyűjtés nem igényel semmiféle compiler támogatást.

Miután megértettem, hogy erről van szó, (próbaképpen) kicseréltem a variable.cpp-t egy olyan példányra, amiben a globális függvényeknek dummy (üres) implementációja van. Az egészet lefordítottam egyszálúra (eddig 20 perc munka) és most futnak a CCC programok Boehm szemétgyűjtéssel.

Most ezt nézegetem. Egyelőre csak egyszálú programokon, de elvileg mennie kell többszálon is.

Érdekelne, ki hogyan készít nyomtatást ccc3-ban.
Elsősorban helyi (LAN) és ügyviteli alkalmazásokra gondolok.
Mik a tapasztalatok, javaslatok?

Az az érdekesség van, hogy a thread_mutex_lock és unlock Linuxon remekül működik egy programomban, szépen nullát adnak mindig vissza. Windowson viszont az unlock 1-et ad vissza, ez az EPERM üzenet, és azt jelenti, hogy Operation not permitted, a doksi szerint ez azt jelenti, hogy a hívó szál nem birtokolja a mutexet. De akkor miért nem panaszkodott a mutex_lock? Van valakinek ötlete? A program amúgy jól tűnik működni, látszólag nem akadnak össze a szálak.

w