log4z

Screencast

noreply@blogger.com (Zeroflag) — Thu, 18 Sep 2008 23:12:00 +0000

Feltoltottem egy demonstracios videot a jshot weblapjara a korabbi posthoz kapcsolodoan. Megtekintheto itt.

Widget selection

noreply@blogger.com (Zeroflag) — Thu, 18 Sep 2008 19:39:00 +0000

A JxCapture egy kereskedelmi capture library javahoz. Screenshotot persze alapbol is lehet kesziteni javaban thirdparty lib nelkul (java.awt.Robot-tal), de vannak olyan featureok amiket nem lehet megoldani csak nativ hivasokkal. Az ilyen oprendszer specifikus dolgokhoz ez a lib is JNI-t hasznal de tobbfele platforma letezik implementacioja. A webstartos demo app tartalmaz egy erdekes featuret ami a "Select Window/Object" menupont alatt erheto el.

Ezzel nem csak ablakokat tudunk kivalasztni a kepernyon hanem az azon levo komponenseket is. (Pl.: gombot, textfieldet, paneleket stb) Tehat minden olyat ami az opreracios rendszer szintjen kulon widgetkent van nyilvantartva. Amikor user raviszi az egeret egy ablakra akkor progi kijeloli vagy az egesz ablakot vagy az azon levo widgetet. A dolog annyira megtetszett hogy eldontottem hogy megcsinalom JShotba is.

Tisztan javaban sajnos ezt nem lehet megoldani mert az ablakok manageleset az oprendszer windowmanagere vegzi. A problema megoldasahoz fel kellett frissitenem a mar elegge megkopott c++ es winapi ismereteimet. Amire szuksegunk van az az hogy le tudjam kerdezni az eger kurzor alatt talalhato ablak/widget koordianatajat es meretet. A dolog ugyanugy fog mukodni mint a "region capture", azaz a user egy teljeskepernyos ablakot fog latni rajta a desktoprol keszitett keppel es eger mozgatasra ezen kijelolodik az aktualis widget.

Ehhez 2 native methodra lesz szukseg:

private native int[] getWidgetRectUnderCursor( int x, int y );

private native void takeWidgetStateSnapshot();

Az elso megadja az egerkurzor alatt talalhato widget elhelyezkedeset. A masodik pedig keszit egy "snapshotot" az ablakok elhelyezkedeserol. Erre csak azert van szukseg hogy ne kelljen minden eger mozgataskor ujra lekerdezni melyik ablak hol talalhato. Addig ugysem valtozik semmi mert a felhasznalo csak egy kepet fog latni a desktoprol.

JNI-nel megszokott modon a classbol legeneraljuk header filet. Ez nalam javah -jni hu.jshot.plugins.nativ.WindowUtils

Az alabbi 2 fuggvenyt kell megirunk cpp-ben.

JNIEXPORT void JNICALL Java_hu_jshot_plugins_nativ_WindowUtils_takeWidgetStateSnapshot
(JNIEnv *env, jobject obj) ;

JNIEXPORT jintArray JNICALL Java_hu_jshot_plugins_nativ_WindowUtils_getWidgetRectUnderCursor
(JNIEnv *env, jobject obj, jint px, jint py);

A konkret megvalositas pedig annyi hogy lekerdezzuk a lathato ablakokat megfelelo Z order szerint es az eger kurzor alatti legmagasabb Z orderrel rendelkezo ablakot vesszuk. Ha az ablakon belul tovabbi widgetre mutat a kurzor akkor azt adjuk (ill. ezek kozul a legkisebbet) vissza egyebkent magat az ablakot.

Azt hogy egy ablak lathato-e az IsWindowVisible fgv-vel kerdezhetjuk le. Ez viszont nem azt adja vissza hogy az adott ablak a felhasznalo szamara valoban lathato-e, hanem hogy az ablak vagy annak parentjenek van-e WS_VISIBLE styleja. Vagyis hogy explicit nem hideoltak-e. Ettol meg a felhasznalo szamara nem biztos hogy lathato mert eltakarhatja egy vagy tobb mas ablak.

BOOL IsWindowVisible(
HWND hWnd // handle of window
);

Az talcara letett ablakokat kiszurhetjuk az IsIconic winapi hivassal

BOOL IsIconic(
HWND hWnd // handle of window
);

A fentebb emlitett problema nem jelent igazan gondot ha ugyis az eger kurzor alatti legnagyobb Z orderrel rendelkezo ablakot valasztjuk. Akkor a takarasban levo
ugysem fog kivalasztodni mert ha van felette vmi akkor annak biztos nagyobb a Z ordere is. Ha csak felig van takarasban akkor ki lehet valasztani de az nem is baj.

Az ablakokat egyszeruen le lehet kerdezi az EnumWindows fgv-vel. Ez egy callbacket ker elso parameterkent ami minden ablak handlejevel meg fog hivodni. A masodik parameterben meg atadhatunk pl egy listat amibe eltaroljuk a hwnd-ket.

BOOL EnumWindows(
WNDENUMPROC lpEnumFunc, // pointer to callback function
LPARAM lParam // application-defined value
);

BOOL CALLBACK EnumWindowsProc(

HWND hwnd, // handle to parent window
LPARAM lParam // application-defined value
);

A child windowkat teljesen hasonloan kerdezhetjuk le az EnumChildWindows fgv-vel. Csak a fenti paremetereken kivul a parent hwndjet is meg kell adnunk.

BOOL EnumChildWindows(

HWND hWndParent, // handle to parent window
WNDENUMPROC lpEnumFunc, // pointer to callback function
LPARAM lParam // application-defined value
);

Az EnumWindows csokkeno Z orderben kapjuk az ablakokat
Az ablak meretet es koordinatait a GetWindowRect fuggvennyel kerdezhetjuk le.

BOOL GetWindowRect(

HWND hWnd, // handle of window
LPRECT lpRect // address of structure for window coordinates
);

Igy mar minden megvan a megvalositashoz amit most nem fogok egy az egyben bepastelni csak par reszletet.

A StateSnapshot tartalmaz egy vector<widget>-et. Tegyuk fel hogy az ablakok mar ki vannak gyujtve ebben. Ahol a widget tartalmazza a handlet, RECT-et es a child komponenskere mutato listat valamint meg tudja mondani egy tetszoleges pontrol hogy az az ablakon belul helyezkedik-e el, es hogy milyen child komponensen van eppen a kurzor.

A lathato ablakokbol kivalasztjuk azt ami az eger kurzor alatt van.


Widget* StateSnapshot::getWindowUnderPoint( int x, int y ) {

    Widget::WidgetList *lst = getVisible();
    Widget *widget = NULL;

    for ( int i = 0; i         Widget *w = lst->at(i);
        if ( w->pointInside( x, y) ) {
            widget = w;
            break;
        }
    }
    delete lst;

    return widget;
}

A legkisebb teruletu child komponens kivalasztasa:


Widget* Widget::getChildUnderPoint( int x, int y ) {
    int area = -1;
    Widget *widget = NULL;

    for ( int i = 0; i < childList.size(); ++i ) {

        Widget *w = childList[ i ];

        if ( w->pointInside( x, y ) ) {
            if ( area == -1 || w->area() < area ) {
                area = w->area();
                widget = w;
            }
        }
    }

    return widget;
}

Ez pedig az amit a JNI fuggvenyunk ( getWidgetRectUnderCursor ) hivni fog. Eloszor megkeresi melyik ablakra mutat a kurzor. Majd megnezni hogy milyen widget van az ablakon belul azon a helyen. Ha semmi akkor visszater az ablakkal egyebkent a child widgettel.


Widget* StateSnapshot::getWidgetUnderPoint( int x, int y) {
    Widget *w = getWindowUnderPoint( x, y );

    if ( w == NULL ) {
        return NULL;
    }

    Widget *child = w->getChildUnderPoint( x, y );

    if ( child == NULL ) {
        return w;
    }

    return child;
}

Erdemes kiprobalni tobbfele ablakkal a featuret. Ha megnezzuk pl NB-vel (vagy barmilyen mas swinges alkalmazassal) erdekes eredmenyre jutunk. Semmilyen child widgetet nem fogunk tudni kivalasztani csak magat az ablakot, mivel a swing a komponenseit sajat maga rendereli le. Eclipsenel viszont siman megy a gombok es panelek kivalasztasa mivel SWT mar az OS widgetjeit hasznalja. Vannak persze nativ alkalmazasok is ahol nem tudunk mindent kivalasztani egyenkent mert sajat komponenseket hasznalnak. De az ezeket magabafoglalo widget mar kijelolheto.

Remelhetoleg xlibbel is hasonloan egyszeruen megoldhato. A kovetkezo (wines) JShot verzio mar tartalmazni fogja a featuret ami hamarosan letoltheto lesz.

jshot.info

noreply@blogger.com (Zeroflag) — Wed, 30 Jul 2008 22:50:00 +0000

A JShot weblapja ezentul a http://jshot.info cimen erheto el. Felraktam par screencastot, shotot meg eztazt.

Swing, JShot etc

noreply@blogger.com (Zeroflag) — Fri, 25 Jul 2008 22:55:00 +0000

Egy picit el lett hanyagolva az utobbi idoben a blog de itt a nyar - meg amennyi maradt belole - ugyhogy igyekszek irni par postot.

Egy korabbi bejegyezesben mar irtam egy JShot nevezetu ScreenCapture utilityrol. Kicsit felelevenitve ez egy javas screenshot keszito es uploader utility amivel az elkeszitett screenshotot feltolthetjuk az elore beallitott helyre. Tobbfele feltolto plugin van hozza. Pl ftp, http (ami a kepfeltoltes.hu-ra tolti), skype file sender. Az elobbi ketto feltoltes utan megjeleniti es a vagolapra masolja az urlt is. Az egesznek annyi a lenyege hogy ha meg akarjuk mutatni a kepernyo egy reszet vkinek akkor upload es mar pastelhetjuk a linket.

A proginak elkeszult az elso publikus teszt verzioja. Letoltheto egyelore innen.

Feature lista:

Teljes kepernyo, desktop, aktiv window, taskbar capture. (az utobbi 3 csak jni-vel win alatt)
Area capture user alatal kivalasztott terulet
Editalasi es rajzolasi funkciok (alakzatok, szabadkezi, szoveg, copy/cut/paste, radir, floodfill, effektek, rotate, flip, crop, merge, stb)
Uploader pluginok: ftp/http/skype mindegyikhez kulon profileok hozhatok letre
Alakzatok tulajdonsagainak allitasa
Feltoltesek egylepesben systemtrayrol
Undo/Redo

Ami remlehetoleg meg jon:

Vmi IPC a tray app es a futo app kozott, az azonos peldanyban valo kep megnyitashoz pl.
Hotkeyek (keyboard hook jni-vel, nem igerem hogy minden platformra de winre biztos)

Irnek par szot a fejlesztes soran szerzett tapasztalatokrol. A java igazabol nem olyan eros a desktop vonalon ezzel gondolom nem mondtam ujat. Viszont imho meg igyis nagyobb produktivitas erheto el vele mint pl cpp+egy nativ guitoolkit-tel, pusztan a managed kodbol szarmazo elonyok miatt. Az elonyok es hatranyok targyalasanal viszont nem art kulonvalasztani hogy mi az ami a fejlesztesi szempontbol jo vagy rossz illetve a felhasznalonak jo vagy rossz.

User szemszogebol a a swinges alkalmazas csunya es lassu. Legalabbis sokan mondjak. Plusz azontul hogy csunya nagyon elut a kinezete a operendszeren futo nativ alkalmazasoktol. Ez utobbi imho hulyeseg. Vannak eleg latvanyos Look and feel-el is (pl liquid). Az hogy mashogy nez ki mint egy nativ alkalmazas meg nem feltetlen hatrany, sot teljesen szokvanyos. Rengeteg alkalamzas van ami nagy szamban hasznal sajat renderelesu komponenseket, es a userek is szeretik cserelgeni a skineket ha van ra lehetoseguk. Eleg megnezni az official msn klienst win alatt, kb semmi nem emlekeztet belole win32-es widgetekre. Ez a bongeszokre ugyanugy igaz. Az operanal se a Windos Native az alapertelemzett skin hanem valami egeszen csicsas kinezet van defaultbol beallitva. Nem beszelve arrol hogy sokan hasznalnak crossplatformos (pl gtk-s xchat, gimp) programokat, amiknek ugyanugy elut a kinezete az alap widgetektol mint egy swinges progie. Tehat egyaltalan nem lenne problema ez, csak sajnos az alapertelmezett Metal/Ocean laf tenyleg nem olyan tetszetos.

Ami a lassusagot illeti a startup tenyleg lehetne joval gyorsabb, de ez az ami csak bizonyos alkalmazasoknal fontos. Vannak olyan programok ahol a user elvarja hogy kattintasra azonnal bejojjon. Egy lightweight editor vagy kepnezegeto pl ilyen. Egy screencapture utilitinel is ez az elvaras. Ennek en ugy probaltam megfelelni hogy kulon valasztottam a main appot, es egy a systemtrayen futo kis alkalmazast. Ez memoria hasznalat szemontjabol is kevezobb. Amikor a user ki akarja valasztni a kepernyo egy reszet akkor duplakattint a systrayes ikonra vagy menubol kivalasztja az area capturet. Ekkor bejon egy awt-s ablak rajta egy canvassal ami kirajzolja screenshotot. Azert awt-s mert ezt lehet fullscreenre rakni es eleg gyors ahhoz
hogy azonnal bejojjon. Igy az egesznek olyan hatasa van kb mintha a kepernyon jelone ki a felhasznalo kepreszletet. A kep feltolteset vagy editalasat mar a main app vegzi el. Igy annak startuptimeja adodik hozza a feltoltesi idohoz, amihez kepest a startup mar elhanyagolhato.

Fejlesztesi szempontjabol swing szerintem egy jol felepitett osztalykonyvtar. A komponensek konnyen kiterjeszthtok. Ami elonye hogy ez tenyleg full platformfuggetlen, a komponensek ugyanugy viselkednek es ugyanugy neznek ki mindenhol. Ez a nativ crossplatform guitoolkitekrol altalban nem mondhato el. Viszont alapbol nagyon keves komponens van. Szerintem mar delphi 1.0-ba is tobb volt. Amig ott egy 10 tabos lapozhato widgetre voltak kipakolva, addig az osszes swinges kompi elfer egyetlen JPanelen. Nincs pl calendar, statusbar, datetimepicker. Valamint viszonylag alap dolgokhoz is sokat kell kodolni.

Nem igazan ismerek jol hasznalhato rad gui buildert hozza. Bar a matisse kisebb nagyobb hibai ellenere jol hasznalhato dialogok es static formok megtervezesere.

Ami meg feltunt hogy van par idegesito memoria felszabaditasi hiba ami mar igen regota megvan es sajnos nem nagyon akarjak javitani. Ez abbol adodik hogy a swingben jopar helyen van olyan static referencia ami a sajat komponenseinkre mutathat. A gc az ilyeneket nem fogja tudni felszabaditani, se azokat amikre ez a widget hivatkozik. Megoldas az hogy disposekor kezzel leszedjuk az osszes komponenst rola plusz kulso objectre mutato fieldek nullozzuk. Igy csak az ures widget marad bent a memoriaban a rajta levo stuffok legalabb mar nem. Vagy valami dummy komponenst letrehozunk hogy kiusse a static referencet. Ez nalam jelentkezett a drag and drop-nal hasznalt TransferHandler-ben ahol a SwingDragGestureRecognizer static valtozo hivatkozott a komponemsemre. Persze a kovetkezo muveletkor ezt felulirja egy uj referenciaval, de valami mindig maradni fog benne. JInternalFramnel szinten van memoria felszabaditasi problema. Ha letrehozunk egy framet majd disposeoljuk, nem fogja tudni felszabaditani csak ha csinalunk egy kovetkezot is. A legutolso viszont mindig bent fog maradni a memoriaban. Ami megrosszabb hogy nem csak JInternalFrame-re hanem sima JFram-re is mukodik.

Szoval osszessegeben lenne meg hova fejlodnie a dolognak. De biztos vagyok benne hogy ha SWT-ben vagy .NET-ben csinaltam volna akkor is lenne ehhez hasonlo szivas lista csak mas jellegu problemakkal. Az ember mindig azt szidja amivel eppen dolgozik :)

De attol meg a JShot mukodik - mar amennyira egy developer a sajat alkalmazasat teszteni tudja - minden eszrevetelt szivesen fogadok.

Karacsonyi wish list

noreply@blogger.com (Zeroflag) — Mon, 25 Dec 2006 15:54:00 +0000

Java™ SE 7 wish list

Peter Ahé egy eredekes Java Dolphin-os whishlistet fogalmazott meg blogjaban. Szamomra egy-ket otlet eleg meredeknek tunik, de van olyan is amit szivesen latnek a 7-es javaban.

"Real closures"

Closures-rol mar tobben irtak. Nekem akkor ez egy uj dolog volt mert az altalam hasznalt nyelvek nem igazan tamogatjak. Tulajdonkeppen kodblokk amit egy fuggveny parameterkent adunk meg. Ertelmezesem szerint annyiban tud tobbet mint egy callback/delegate/anonymousinnerclass hogy a blokkon kivuli lokal valtozokat eleri. Tipikusan azt csinalja hogy egy collection minden elemere meghivja a megadott blokkot, az pedig valamilyen muveletet vegez a kapott parameterrel. Ilyesmit lehet csinalni javaban egy anonymous inner class + final tomb referenciaval, de a dolog lenyege inkabb az lenne hogy egy egyszeru szerkezetet szolgaltat amivel roviden megoldhato a dolog.

Rubyban ezzel sokat szoktak operalni. Python mar kevesbe tamogatja de map/filter + lambda-val lehet hasonlo hatast elerni. Amiota bejott a List comprehension, azota amikor csak lehet mindenki azt hasznalja mert sokkal attekinthetobb.

Nem egy olyan dolog ami nelkul ne lehetne elni, de ha valami atlathato syntaxot talalnak ki neki akkor lehet hogy jo lesz.

"Type aliasing"

pl.: "import java.util.List<String> as StringList;"

Ez csak egy aprosag de jol nez ki. Pythonban is van ilyen bar ott ritkan hasznalom, mert viszonylag rovidek es konnyen megjegyezhetoek a modul es package nevek. Javaban viszont a kacifantosabb nevek -foleg igy genericel kombinalva- leroviditesere jol johet. Mivel ugyis csak importban hasznalhato (remelhetoleg) igy nem ront az olvashatosagon.

"Super packages"

Hmm, nekem nincsenek ilyen igenyeim a packagekkel kapcsolatban, de akik nagy meretu frameworkoket fejlesztenek azoknak lehet.

"Shorthand syntax for declaring properties"

Azaz "property String foo"-bol csinal setter/gettert. Ez ebben a formban nem tudom miert jo nekunk. Egyreszt a legtobb IDE ugyis auto generalja, masreszt ha a setter/getterbe sajat kodot akarok rakni akkor nem hasznalhatom. Max olyan formaban lenne ertelme mint ahogy C#-ban van. De akkor meg szvsz a kezdetektol kellett volna alkalmazni, nem utolag belerakni. Szerintem ez igy felesleges.

"Array syntax for collections"

"How sweet is this:
final map = new HashMap<String, Integer>();
map["one"] = 1;"

Na igen, ez tok jo lenne csak sztem egyaltalan nem illik bele a java nyelvezetebe.

"Shorthand syntax for declaring local variables"

Ezen mar akkor is enyhen ledobbentem amikor meglattam hogy C#-nal ilyet akarnak.
Vagyis lokal valtozokat tudok ugy deklaralni hogy nem irom ki a tipust mert az az ertekadas alapjan dol el. Erre tobbfele javaslat is van.

JavaScript-re emlekezteto syntax: (szerintem ez a legrondabb)
var foo = "bar";

Vagy:
final foot = "bar"; (mivel ha final akkor ugyis csak egyszer tudom inicializalni)

Gosling pedig a kovetkezo syntaxot javasolta:
foo := "bar"; // Valaki mar meg is patchelte azota a javac-t hogy elfogadja ezt az ertekadast. Hat igen, GPL.. :)

A "var"-os nal azonkivul hogy JS-re emlekeztet meg uj keywordot is be kell vezetni. Enumnal is volt ilyen hogy 1.4-es sourcban pl valtozonevkent hasznaltak, 1.5-re nem lehetett egyazegyben leforgatni mert ott mar reserved word. De a legfobb ervem az hogy hulyen nez ki (akarcsak pascal styelos operator) :).

Legeloszor a dinamikusan tipusos nyelvekre asszocialtam de ettol meg nyilvan ugyanugy static typing marad.

(Egyebkent meg a dinamukusan tipusos nyelveknek szvsz nem is az az igazi elonye (ami egyesek szerint nagy hatrany is lehet) hogy nem kell kiirni a tipust hanem sokszor egyszeruen nem is erdekel hogy kinek mi a tipusa. Max az hogy mit tud az illeto objektum. Ha egy file objectnek es egy socket objectnek is van read metodusa akkor nekem az egyforman jo hiaba total kulonbozo a ket objektum. Ugyanugy hasznalhatom anelkul hogy kozos interfacet irnek ra benne a read methoddal. Ezert ritkan is lehet olyat latni hogy isinstance, helyette inkabb hasattr-t hasznalnak. Abba nem mennek bele hogy alkalmas-e ilyen nyelv nagy rendszerek fejesztesere mert ebbe nem tudnek allastfoglalni. (mindenesetre van ra pelda boven). Kisebb programok fejlesztesenel viszont ez nagy mertekben novelheti a produktivitast (masok szerint meg a hibalehetoseget:)).

Visszaterve a javahoz, nem tudom hogy van-e a dolgonak azon kivul haszna hogy nem kell leirni par karaktert. Uj keywordot es operatort meg szerintem hanyagolni kene.

Gondolkodtam hogy en milyen featuret latnek szivesen de nem sok ertelmes dolog jutott eszembe. kack viszont ezt javasolta:

catch( Exception1, Exception2, Exception 3 ) { }

Ezt most max ugy lehet hogy kozos parent-et csinalok nekik es azt kapom el. De vegulis elofordulhat hogy logikailag nem illik bele vmelyik Exception egy bizonyos hiearchiaba de attol meg egyuttesen szeretnem elkapni oket.

Nem vagyok az uj featureok ellen, csak az olyanokat nem szeretem amik rontjak az olvashatosagot, vagy nagyon "hackelhetove" teszik a nyelvet. Ez alatt azt ertem hogy ugyanazt a dolgot tobbfelekeppen meg lehet csinalni, pl egy sorban ugyhogy senki nem fogja erteni mit csinal az a sor, vagy tobben es akkor esetleg atlathatobb lesz. Ha a Closures-nek vmi szar syantox talalnak ki akkor abbol lehet ilyen problema. Az olvashatosagot szvsz a tul sok keywordel, tul sok speci operatorral is le lehet rontani. Szoval szerintem mertekkel kene kezelni ezeket a featureoket.

Java SE 6

noreply@blogger.com (Zeroflag) — Mon, 11 Dec 2006 22:05:00 +0000

Kijott a a JDK 1.6-os verzioja, amit idaig mustang kodneven emlegettek. Jol idozitettek a felev vegere igy nem nagyon van idom megnezegetni. Amit a betas tapasztalatok alapjan tudok hogy sok szep desktop feature kerult bele mint pl systemtray icon, antialiasingos font, splashscreen. NB-t megneztem milyen 1.6al. A textek eddig sem voltak nalam szalkasak egy cleartext utility miatt de most mintha megszebb lenne, bar lehet csak placebo. Sebesseg novekedest majdnem minden verzional igergetnek, de ezt egy desktop appnal annyira nem veszem eszre. Eddig sem volt se tul gyors se tul lassu. De ez majd hosszabb hasznalat utan ugyis kiderul. Ha lesz idom megnezem alaposabban.

Jah es a kedvencem: "java -cp ".;libs/*" Progi"
De vajon miert nem jutott ez mar hamarabb eszukbe? :)

lol?

noreply@blogger.com (Zeroflag) — Sun, 05 Nov 2006 00:43:00 +0000

ehehe

LayerTable

noreply@blogger.com (Zeroflag) — Sun, 01 Oct 2006 19:35:00 +0000

Egy kis JShot upgrade. A shapek zorderjet egy LayerTable segitsegevel lehet valtoztatni, drag and droppal.

Opera 9.02RC2

noreply@blogger.com (Zeroflag) — Thu, 21 Sep 2006 11:52:00 +0000

innen

JShot

noreply@blogger.com (Zeroflag) — Sat, 09 Sep 2006 22:25:00 +0000

Regota nem postoltam ugyhogy itt az ideje. Utobbi idoben egy regebbi alkalmazason dolgoztam. A JShot egy screen capture program ami a kepenyrol csinal screenshotot, amit szerkeszthetunk vele, valamint feltolthetjuk egy lepesben ftp serverre, a linket pedig a vagolapra masolja. Az otlet onnan jott hogy gyakran elofordult hogy im/irc-en meg kellett mutatni a kepernyo egy reszet masik szemelynek. Ilyenkor a hagyomanyos modszer hogy nyomsz egy printscreent, elinditasz vmi kepszerkesztot, bepasteled, elmented, elinditasz egy ftp kliens, feltoltod, linket meg kezzel beirod. Na ezt a nem keves lepest akartam automatizalni, ezert kezdtem fejleszteni a jshotot. A legelso verzio kb ennyit csinalt es nem tobbet. A mostani viszont egy kis refactoringon ment at, helyenkent ujra is kellett irni, valamint rakas uj featurevel is bovult. Kepszerkesztesi funkciok kerultek bele, rajzolni lehet a kepre. Kulonbozo elore legyartott alakzatokat rapakolni layerkent. Amiket utolag mozgatni, meretezni lehet. Kicsinyites, nagyitas, tukrezes, forgatas, par effekt, stb. A gui pedig teljesen mdi-s lett. A program 100% pure java/swing igy fut mindenhol. Meg par fontosabb featuret szeretnek belerakni mielott publikus verziot csinalok belole. Addig is nehany onkentes "beta teszter" (= @ismeros) hasznalja. Egy shotot azert megelolegezek :)
ime:

Pocket Torrent

noreply@blogger.com (Zeroflag) — Tue, 08 Aug 2006 15:25:00 +0000

Jelenleg a Python 2.4.3-es verzioja elerheto pocket pc-n is. Ez tartalmaz egy interaktiv interpretert es az alap csomagok nagy reszet. Pl van xmlrpclib, smtplib, ftplib, stb es tkintert is ra lehet haxolni. Nincs viszont pl distutils meg signal. Legegyszerubb ilyenkor ugy letesztelni az interpreter kepessegeit ha egy meglevo nagyobb projectet probalunk meg rajta elinditani. A bittorrent 3.9.1es verziojat valasztottam. Ezt probaltam konzol modban futtani(btlaunchmany.py). Meglepo modon mindossze egyetlen egy sort kellett atirni benne es onnantol tokeletesen futott.
A RawServer.py ha nem win32 paltformon fut(es ez most ce platform), akkor os.pipe-ot probal hasznalni ami ppc-s pythonnal nem letezik. De ez felfoghato a forras hibajakent is, mert azt feltetelezi hogy minden nem win32es platforom van pipe es lehet selectelni is fileokat. Ezt kellett atirni, illetve meg beleirtam a parancssoros parametert is kozvetlenul a forrasba hogy ne kelljen azzal is vacakolni. Letoltottem vele 5megas teszt filet majd ugyhagytam hogy seedelje egy ideig. Egyetlen problemam az volt hogy storage-re nem akart menteni, se az SD kartyara, se az iPAQ storera. Igy nagyobb fileokkal nem tudtam kiprobalni. De szerintem ezis egy szep eredmeny hogy gyakorlatilag egy az egyben elfut egy pc-re irt program ppc-n. Ez nem mondhato el se .netrol se javarol. Mert az elobbinel eleve compact frameworkot kell hasznalni utobbinal meg CDC/CLDC-s vm-re kell forditani. (csak olyanbol hasznalhato nem igazan van).

Megoldas a metaclasses

noreply@blogger.com (Zeroflag) — Sun, 23 Jul 2006 22:28:00 +0000

Ujra vissza az elozo problemahoz. A metaclassok tulajdonkeppen olyan osztalyok amiknek a peldanyai is osztalyok. Ez igy elsore lehet furcsan hangzik mert az ember ugy tanulta hogy az osztalyok peldanyai az objectek. Objectet az ember ugy csinal hogy van egy osztalya ami sablonkent mukodik es az alapjan csinal belole peldanyt. Ugyanazt meg lehet tenni osztallyal is, azaz egy olyan masfajta osztaly kell ami maga is osztalyt ir le. Ez a masfajta osztaly a metaclass. Pythonban a legnyilvanvalobb, beepitett metaosztaly a type. De ilyen a types.ClassType is. Ez elobbi a beeptitett osztalyok metaclassa, az utobbi pedig a user altal gyarott osztalyoke. Pythonban maguk az osztalyok is objectkent vannak megvalositva, ugyanugy (legalabbis az en problemam szempontjabol) jonnek letre (egy metaclass peldanyaikent), mint a normal objectek. Ez pedig megoldast jelent szamomra, mert nincs mas dolgom mint csinalni egy uj metaosztalyt, aminek a konstruktoraba elrejtem az interface ellenorzo kodomat. Ebbol a metaosztalybol csinalni egy uj peldanyt, azaz egy normal osztalyt. Ez lesz az Interface osztaly aminek a metaosztalya az InterfaceType. Az Interface mar egy teljesen normalis osztaly, ebbol leszarmatathatok barmilyen interfacet. pl.:


class ITest( Interface ):
    def test(self, t): pass

Mivel az Interface osztaly az InterfaceType konstruktorat orokolte (metaosztalyoknak is van konstruktoruk ami akkor fut le ha peldanyt hozunk letre belole, azaz normal osztalyt a metaosztalybol), az ITest pedig az ovet. Igy az ITest osztaly megkrealasakor, le fog futni a metaosztalyomban levo ellenorzo kod. Hangsulyozom hogy osztaly letrehozasakor, nem osztaly peldanyositasakor. Ezutan ezt az interfacet "implementalom", amihez ugyanugy az oroklest hasznalom.


class Test( ITest ):
    def test(self, t):
        return t

A Test osztaly letrehozasakor szinten lefut az ellenorzes. Mi is van ebben az ellenorzesbe. Eloszor is lekerdezi az aktualis osztaly metodusait. Jelen esetben a Test krealasakor ez a 'test' metodus. Lekerdezi az osztaly direkt oseit. Ha ennek az osnek az ose Interface osztaly akkor o maga egy Interface. ITest jelen esetben. Igy el tudom donteni hogy a Test osei kozul melyik az interface mert nem biztos hogy csak ITestbol fog szarmazni, lehet ott mas nem interface osztaly is. Tehat megvannak az implementalando interfacek (ITest vagy Interface osztaly letrehozasakor nem fog ilyet talalni ekkor nem is ellenoriz semmit). Az interfacek metodusait egyenkent lekerdezem, jelen esetben megkapom az Itest.test(self, t)-t, es megnezem hogy ez egyenlo-e (marmint 2 fuggveny referencia) az aktualis osztaly a Test, ugyanilyen nevu (mert hat biztos hogy van neki ilyen hiszen orokolte, kerdes hogy a user feluldefinialta-e) metodusaval. Ha a 2 referencia megegyezik akkor csak sima oroklesrol van szo, ha kulonbozo akkor felul lett definialva, azaz a user kozvetlenul beleirta a kodba, tehat implementalta. Ezutan leellenorozm meg a fuggveny parametereinek a szamat is, ha nem stimemel ugyanugy assert errorozik (azert assert, mert az letilthato egy parancsosoros parameterrel ha pl release verzional nem akarjuk ellenorizgetni). Szoval ha en azt mondom hogy class Test( ITest, Base1, Base2 ), es az ITest interfacebol szarmazik, a Base1/2 pedig normal osztaly, akkor az ITestben levo metodusokat koteles vagyok feluldefinialni.

Es akkor jojjon a kod:


from types import MethodType

def getMethods( clz ):
    return [i for i in dir(clz) if type(getattr(clz, i)) == MethodType]

class InterfaceType(type):

    def __new__(cls, name, bases, dct):
        return type.__new__(cls, name, bases, dct)

    def __init__(cls, name, bases, dct):
        super(InterfaceType, cls).__init__(name, bases, dct)

        for b in bases:
            if b.__base__.__name__ == 'Interface':
                imet = getMethods( b )
                for m in imet:
                    assert getattr( cls, m ) != getattr( b, m ),                        'WARNING: method %s not implemented in %s' % ( m, cls.__name__ )

                    assert getattr( cls, m ).func_code.co_argcount == getattr( b, m ).func_code.co_argcount,                        'WARNING: method %s not correctly implemented in %s (parameter mismatch)' % ( m, cls.__name__ )

Interface = InterfaceType('Interface', (), {})

Mivel metaclassrol van szo lathato hogy konstruktorban nem self, hanem cls, azaz metaosztaly peldanyra mutato referencia van. A __new__ az __init__ elott hivodik meg es az uj osztaly peldanyaval ( ami most szinten osztaly mivel metaclassbol hozza letre ) ter vissza ('type' osztaly factorykent mukodik). Elofordulhat hogy ugy jon letre az osztaly hogy az __init__ nem hivodik meg pl picklevel serializaljuk be, ilyenkor az ellenorzes sem fog lefutni (normal osztaly betolteskor szerintem le kell mindig). De a 2 cls parameter nem ugyanaz a 2 fuggvenyben. A __new__ban a self-el analog a metaosztaly sajat referencia van, mig a konstruktorban az aktualis metaosztaly peldany, azaz normal osztalyra mutato referencia. A for loopban a direkt ososztalyokbol kivalasztjuk azokat akiknek az ose az Interface, es ezutan kovtkezik a metodusok osszehasonlitasa. Az utolso sor nagyon fontos, Interface = InterfaceType('Interface', (), {}), itt hozok letre az InterfaceType metaosztalybol egy peldanyt, azaz egy normal Interface osztalyt.

Itt pedig a test kod


from interface import Interface

class ITest( Interface ):
    def test(self, t): pass

class Cloneable( Interface ):
    def clone(self): pass

class Test( ITest, Cloneable ):
    def lofasz(self):
        return t

    def test(self, t):
        return t

    def clone(self):
        print 'clone'

class Test2( Test):
    pass

A modszer meg erosen kiserleti, tesztelest igenyel, de elsore nem latok olyan problemakat mint az elozo kettonel.

Masodik nekifutas

noreply@blogger.com (Zeroflag) — Sat, 22 Jul 2006 23:38:00 +0000

Elozo postomban leirt modszer nemigazan hasznalhato addig amig nincs osztaly decorator. Most mashogy kozelitettem meg a problemat es a class static valtozojaba taroltam a interfaceket. pl.:


class ITest:
      def test(): pass

class Test:
      __implements__ = ( 'ITest', 'interface_pkg.interfaces.iclone.clone.Cloneable', 'serializable.Serializable' )

      def sample(self): pass
      def serialize(self): pass
      def clone(self): pass
      def test(self): pass

A syntax hasonlo mint zopenal (de azt nem tudom hogy ellenorzi). Lathato hogy modul/csomag nevet fel kell tunetni az osztaly neve elott. Ha nincs odairva semmi (mint az ITest-nel) akkor az aktualis fileban fogja keresni az adott osztalyt(interfacet).

Az ellenorzes pedig a kovetkezokeppen mukodik. A modul importalast hookoltam, igy a sajat importerem lefog futni minden import elott (ezert kell torolni az import cachet). Ez az importer ellenorzi az importalando fileban levo osszes osztalyt, megnezi van-e valamelyiknek __implements__ static attributuma. Ha talal ilyet, akkor az abban talalhato interfaceket betolti, es lekerdezi a benne levo metodusokat. Majd megnezi hogy az implementalo oszalyban ezek benne vannak-e. Ha igen akkor visszater a modullal, egyebkent hibat ir es None-t kuld vissza, ami ImportError-t fog okozni.

Hasznalat pedig a kovetkezo. Eloszor interface_checker -t kell importalni, ami hookolja magat. Innentol kezdve ha valamit importalunk akkor azt leellenorzni. Ebbol viszont mar ki lehet talalni mi a problema ezzel a modszerrel. A __main__ modul betoltesenel hamarabb nem tudja hookolni magat (mert legkorabban ott lehet importalni) igy az abban levo osztalyokat nem ellenorzni.

Ezenkivul kicsit olyan haxolos benyomast kelthet a dolog. Azert teszem megis koze, mert a import hookolas egy jo feature, es hata inspiral masokat egyeb problemak
megoldasara. Pl az urlimport - amivel httprol lehet python modult betolteni - is ezt hasznalja. De pl olyat meg nem lattam hogy adatabazisbol lehetne ugyanigy importalni, pedig ez is hasznos lehet.

Ime InterfaceImporter highly experimental verzioja:


class InterfaceImporter:

"""
TODO: check number of parameters
TODO: asserterror
TODO: check main module
"""

    disable = False

    def __init__(self, path):
        print '[init]: at', path

    def find_module(self, fullname, path=None):
        if InterfaceImporter.disable: return None
        print '[find module]: %s at %s' % ( fullname, path )
        return self

    def load_module(self, fullname):
        print '[load module] at', fullname

        InterfaceImporter.disable = True

        try:
            mod = __import__(fullname)

            # get all class from the module
            classes = [ i for i in dir( mod ) if type(getattr(mod, i)) == ClassType ]

            print 'Module %s contains %s class(es)' % (fullname, classes)

            try:
                for clazz in classes:

                    clazz = getattr(mod, clazz)

                    if not hasattr( clazz, '__implements__'):
                        # no __implements___ field found, skip this class
                        print 'No interface in %s' % (clazz)
                        continue

                    interfaces = getattr( clazz, '__implements__')
                    print '%s implements %s interface(s)' % ( clazz, interfaces )

                    iobjes = []
                    for inf in interfaces:
                        if inf.rfind( '.' ) == -1:
                            ipkg = fullname
                            iname = inf
                            inf = ipkg + '.' + inf
                        else:
                            iname = inf[inf.rindex('.')+1:]
                            ipkg = inf[:inf.rindex('.')]

                        iobj = __import__( ipkg )
                        for isub in inf.split('.')[1:]:
                            iobj = getattr(iobj, isub )

                        iobjes.append( iobj )

                    self.checkInterfaces( clazz, iobjes )

            except AssertionError, e:
                print "implementation error: %s" % (str(e))
                return None
            except Exception, ex:
                print 'Error:', str(ex)
                return None
            else:
                print 'All method implemented'
        finally:
            InterfaceImporter.disable = False

        return mod

    def getMethods( self, clz ):
        return [i for i in dir(clz) if type(getattr(clz, i)) == MethodType]

    def checkInterfaces( self, clazz, interfaces ):
        cmethods = self.getMethods( clazz )
        print 'class methods of %s: %s' % ( clazz,cmethods )
        for inf in interfaces:
            imethods = self.getMethods( inf )
            print 'interface methods of %s: %s' % ( inf, imethods )
            for i in imethods:
                assert i in cmethods,                    `i` + ' not correctly implemented'

# import hook
sys.path_hooks = [x for x in sys.path_hooks if x.__name__ != 'InterfaceImporter']
sys.path_hooks.append(InterfaceImporter)
sys.path_importer_cache.clear()

Az import hookolasrol bovebben pep-0302-ben lehet olvasni. Itt azt is leirjak hogy milyen protocolt kell kovetnie az importer osztalynak. Ez a protocol dolog olyan a pythonnal mint az interface statictyping nyelveknel. Ez mindossze annyit tesz hogy doksiba leirjak hogy milyen metodusok szuksegesek ahhoz h mukodjon. Ha valamit kihagyunk majd runtime kiderul, de amig hapog es duck-kent viselkedik addig duck :)
Egyebkent meg unittest rulez.

Python interface

noreply@blogger.com (Zeroflag) — Fri, 21 Jul 2006 12:07:00 +0000

Az interface egy hasznos dolog, kulonosen ha frameworkot tervez az ember. Az adott specifikaciot eloszor interfacekkel irjuk le, majd arra adunk egy konkret implementaciot. Az interface alapjan mas is eltudja kesziteni a meglevovel kompatibilis de eltero implementaciot. A kozos interface pedig biztositja hogy meglevo mas libekkel egyutt tudjon mukodni. Pythonban nincsenek interfacek, es ugy vettem eszre hogy legtobben nem is nagyon tartanak ra igenyt. Ugyanakkor a nagyobb frameworkok mint zope, kifejlesztettek interfacekre sajat modszert. Megprobaltam en is irni egy egyszeru decoratort ami ellenorzi hogy egy osztaly implementalta-e maradektalanul a megadott interfacet.

Egy ehhez hasonlot akartam eloszor csinalni, de class decorator (meg?) nincs pythonban igy a syntax ezt nem engedi meg.


@implements( [IInterface1, IInterface2] ) # not supported 
class Test:
    ...

Ezert fuggveny decoratorral probalkoztam. Konstruktort altalban explicit megadja az ember igy erre huztam ra a decorator fuggvenyt. A problema ezzel hogy peldanyositaskor ellenorzi, nem pedig a modul betoltesekor, igy csak runtime derul ki ha baj van. (De talan hamarabb mintha metodus hivasnal jonnenk ra hogy nem letezik az adott fuggveny)


class ITest:
      def testMethod(self): pass

class Cloneable:
      def clone(): pass

class Test:

      @implements( (ITest, Cloneable) )

      def __init__(self, s, i):
          print s, i

      def testMethod(self):
          print 'implemented'

      def clone(self):
          print 'clone test'

t = Test( 'test', 1 )
t.testMethod()
t.clone()

A konstruktorra kell hattatni a decoratort, ami visszad egy olyan fuggvenyt ami leellenorzi az implementaciot es meghivja az eredeti konstruktort. A tovabbi problema ezzel hogy minden egyes peldanyositaskor lefut az ellenorzes, es feleslegesen lassit. Ezt esetleg meg lehetne oldani egy global release/debug flaggel amit ha kikapcsol az ember akkor skipeli az ellenorzest. Ha valami static initializacios blokkba el lehetne helyezni hasonlo modon az ellenorzest es ugy a modul importalasanal le tudna ellenorizni akkor hasznalhato lenne. Ha valakinek van erre hasznalhato otlete az irja meg plz.

A decorator amit en hasznaltam a kovetkezo:


def implements( infaces ):
    """
       implements decorator
       usage:
             class Sample:
                   @implements( (IInterface1, IInterface2, IInterfaceN  )
                   def __init__(self, args):
                       ...
       warning: this will check the implementation at runtime, before every creation of the instance
    """
    def f( init ):

        from types import MethodType

        def getMethods( clz ):
            return [i for i in dir(clz) if type(getattr(clz, i)) == MethodType]

        def checkInterface( clazz ):
            cmethods = getMethods( clazz )
            for inf in infaces:
                imethods = getMethods( inf )
                for i in imethods:
                    assert i in cmethods,                           `i` + ' not correctly implemented'

        def new_init(ref, *args, **kargs): # this will be the new constructor
            checkInterface( ref.__class__ )
            return init(ref, *args, **kargs)

        return new_init

    return f

Python 2.5 beta

noreply@blogger.com (Zeroflag) — Tue, 11 Jul 2006 22:30:00 +0000

Megjelent a python2.5 masodik betaja. Csak most volt idom kiprobalni par uj featuret ezert nemirtam az elsorol. Errol viszont most egy kicsit bovebben fogok.

Nezzuk milyen ujdonsagokat rejteget szamunkra. Elszor is van amd64 portja ami tok jo (lesz majd). Mostmar van a c-s '?:'-hez hasonlo felteteles kifejezes bar teljsen mas syntaxal. "x = cond ? 1 : 0" helyett "x = (1 if cond else 0)". A zarojel nem kotelezo de azt ajanljak(nagyon helyesen) hogy hasznaljuk a jobb olvashatosag miatt. Nem tudom eldonteni hogy ez jo vagy rossz, eddig se volt nehez leirni azt 2 sort, a python pedig sose arrol volt hires hogy kevesebbet kell gepelni (mint pl perl) hanem hogy rendkivul jol olvashato a kod. Eloszor arra gondoltam hogy c-s verziot kellett volna akkor mar belerakni, mert azt mindenki ismeri es megszokta mar. Viszont az egyaltalan nem illik a python szintakszisahoz. Valoszinuleg azert viszolyogtam eloszor tole mer rogton a perles "expression if (condition)" -re asszocialtam, (Na akkor mar csak az unless hianyozna es kb dobnam kukaba az egesz nyelvet:)) node nem errol van szo ugyhogy lehet hogy hasznosnak fog bizonyulni.

Van egy masik nyelvi feature aminel egyaltalan nem volt kerdes hogy jo-e vagy nem. Megpedig hogy finally megengedett lett exceptionnel egyutt.

Azaz:


try:
   print 1/0
except Exception, e:
       print e
finally:
        print 'finally'

Ez egyertelmuen ql, johetett volna hamarabb is.

Ha mar finally akkor ugylatszik nem alltak meg ennel a developerek hanem tovabbmentek es csinaltak egy meg egyszerubb modszert a clean-up es hasonlo muveletek lefuttatasara. Bejott egy uj kulcsszo a "with" (es "as") aminek segitsegevel az object tulajdonkeppen sajat maga vegezheti a clean-up-ot, eroforras felszabaditast illetve minden olyat amit altalban az ember a finally blockba tesz. Kovetkezokeppen kell elkepzelni:


with kifejezes as valtozo:
     valtozo.fgv1
     valtozo.fgv2

Az erdekes ebbe az hogy a with block vegen vagyha kivetel keletkezett, tehat mindekeppen lefut egy cleanup amit az osztalyban van elore definialva. Olyan objectet hasznalhatunk with blockba ami tamogatja ezt, un. Context Manager protocolt. Ami egyszeruen annyit jelent hogy egy elore meghatarozott interface metodusaival rendelkezik, de errol majd kesobb.

Hogy vilagosabb legyen ime egy filekezelos pelda:


with open('file.txt', 'r') as f:
    for line in f: print line

A muvelet vegen a file szepen lezarodik, anelkul hogy ki kene irni az f.close()-t.

A PEP-ben erre a modszerre tobb peldat is mondanak, pl I/O muvelet mint filekezeles, thread lock hogy ne felejtsunk el releaselni, es ami nekem a legjobban tetszett az a tranzakcio kezeles. Erre fogok most kiterni.

Tehat van egy db tablank akarunk valamilyen muveleteket vegrehajtani rajta, ha pl valamelyik nem sikerul egy kivetel miatt akkor rollbackelje az egeszet egyebkent mehet a commit.

Ezt ezt ehhez hasonlo koddal megtehetjuk.


db = DatabaseConnection()
# begin transaction
with db as cursor:
     cursor.insert('first row')
     cursor.delete('another row')

De nezzuk mi van a hatterben azaz hogy tudunk olyan osztalyt csinalni ami tamogatja a with-et. Eloszor is ez a bizonyos Context Manager eloirja szamunkra hogy legyen az osztalynak egy __enter__ es egy __exit__ metodusa. Az enter a blockba valo belepeskor hivodik meg es visszaadja azt az objectet amin a muveletet szeretnenk elvegezni. Ez fog az 'as' kulcsszo utan megadott valtozoba eltarolodni. ( masszoval cursor = db.__enter__() ) Kell hogy legyen tovabba egy __exit__(self, type, value, tb) amibe altalaba cleanupot tesszuk. Itt a commitot, rollbackat vagy a db connectionpooling lezarast. Az exit parameterei ugyanaz mint a sys.exc_info(). Innentol kezdve mar haszanhatjuk is a with-et.

A lenti examplet a PEP-bol vettem es egeszittem ki, a DatabaseConnection az ami tudja ezt a bizonyos interfacet, van neki exit es entere. Az enter visszater a cursorral amivel insertelhetunk vagy torolhetunk az adatbzisbol. Az exit pedig ha nincs kivetel akkor commitol, egyebkent rollbackkel. Az exit visszateresi erteke is fontos, ez altalaban false, ami azt jelenti hogy a kivetelt ujradobja, a true (csak a pelda miatt true) pedig teljesen elnyeli.


from __future__ import with_statement # ez elvileg csak a betaban kell, kesobbiekben alapbol importalni fogja

class Cursor:
      def insert(self, s):
          print 'insert', s

      def delete(self, s):
          print 'delete', s
          raise Exception('Database exception: delete error')


class DatabaseConnection:
      def __enter__(self):
          self.cursor = Cursor()
          return self.cursor

      def __exit__(self, type, value, tb):
          if tb is None: # No exception
             # do commit
             print 'COMMIT'
          else:
               # do rollback
               print 'ROLLBACK', value
          # release the connection object...
          return True #False



db = DatabaseConnection()
# begin transaction
with db as cursor:
     cursor.insert('first row')
     cursor.delete('another row')

A program kimenete pedig a kovetkezo:

insert first row
delete another row
ROLLBACK Database exception: delete error

Ugyanis a deleteben szandekosan dobtam egy kivetelt, ellenkezo esetben kommitol.

Errol lehet azt is gondolni hogy nem egy nagy dolog, raadasul eddig is siman meg lehett finallyval mostmeg irhatok neki kulon osztalyokat. A dolog lenyege inkabb az szerintem hogy ezekutan a standard runtime osztalyai es valoszinuleg a thirdparty libek nagyresze is tamoatni fogja ezt a modszer ahol ez szukseges, azaz nem nekem kell megirni a cleanupot minden muveletnel hanem az object gondoskodni fog arrol hogy a block vegen lezarja a filet, bezarja a socket kapcsolatot/adatbazist stb. Szerintem tokjo featurenek nez ki. Ja, es van egy contextlib modul amibe olyan decorator van definialva ami leegyszerusiti a context managerek fuggvenybol torteno gyartasat.

Van meg relativ import, es sok mas uj feature is, ezeket mindenki olvassa el a whatsnew-ban.

Opera 9

noreply@blogger.com (Zeroflag) — Tue, 20 Jun 2006 15:02:00 +0000

Navegre.
Megjelent az Opera 9 release valtozata.
Lehet upgradelni a betakat.

Vista meg a kszzammel

noreply@blogger.com (Zeroflag) — Mon, 19 Jun 2006 20:02:00 +0000

Mar vagy egy hete itt pihen a vista beta dvd isoja de nem tudtam kiprobalni azon egyszeru ok miatt hogy nem volt egy ures dvdm. Tegnap ez a problema is elharult, igy mar csak az install hibauzenetet kellett megfejteni hogy semmi se allhasson utamba.
Kovetkezot irta miutan kapott egy 30G-s ntfsre formazott particiot.

"windows is unable to find a system volume that meets its criteria for installation"

Google-vel taltam jobbnal jobb 5leteket. Pl huzzak le rola mindent, keyboardot, egeret stb-t. Masik kedvencem h probaljam meg 2x-esen kiirni a dvdt. (ahahah 1hetet vartam mire lett egy dvd-m) Termeszetesen egyiket se probaltam ki mert mar onmagukban nevetsegesek. A problemat valojaban az okozta hogy a grub nem jelolte ki aktivra a bootolando particiot hanem folyamatosan a sol-os particonak volt beallitva a bootflag. Gyorsan orvosoltam, dd (wines), mbr beolvas 512 meretu fileba, vistas partico offsetje megkeres, 0x80 bootflaghez beiir, (a masiknal 0x00), dd visszair. Tudom hogy lehet ezt egyszerubben is :)
Igy mar rogton eltunt a hibauzenet es szepen elkezdte pakolni az egy dvdnyi anyagot.
Install kozbe tobbszor is rebootolgatott, a vegen pedig letrehozatott velem egy usert. A loginScreen egyebkent tokszep meg ugy altalaban minden eleg designos, max az volt illuiziorombolo amikor ugyanaz a ezereves bejelentkezo zene csendult fel
belepesnel. Az mbr-t termeszetesen szo nelkul hazavagta, lecserelte sajat bootmanagerere. Igy vissza kellett pakolni a sajatot hogy tudjak xpt is bootolni. Na es ezutan tortent az erdekes dolog, miutan visszaraktam az mbr-be az enyemet,
es az xp es a sol rendesen bootolt, a vista viszont mar nem. Megprobaltam grubbal, ugyanugy nem volt jo. Bejott a win bootloadere kiirt hogy vmi winloadert nem talal es annyi. DVD-rol recovery console viszont felajanlott vmi 'automatikus javitast'. Az ilyeneket nagyon szeretem mert fogalmam sincs mit csinal, szep lett volna ha megint leszedi a bootmanagert. De nem, minden maradt a regi viszont mar tudott bootolni a vista grubbal es bootmanageremmel is.
Elso eszrevetel az hogy securitys dolgokra nagyobb hangsulyt fektettek. Pl netbeans fel se tudtam rakni mert az installnak, adminkent futtatva se volt semmilyen fileirasi joga :). Nem tudom kinek a hibajabol. A totcom install pedig valamiert el se indult. Ugyhogy ragework-ot hasznaltam. 64bites jse tigert tettem fel, es most derult ki szamomra hogy ebben nincs webstart tamogatas, ugyhogy a 32bites
webstartot kulon kellett felrakni. Vegyesen mentek a 64 es 32bites progik, van kulon 'program fils(32)' es 64, mint a 64es xp nel is. Semmi fele teljesitmenybeli problema nem volt, ugyment kb minden mint xpn.
Noh de terjunk ra, avalon, winfx, xaml es hasonlo buvszavakra. Eleg nehezen tudok eligazodni mar ezek kozott mert .netes hireket nem nagyon kovettem ujabban figyelemmel.
Avalon ha joltudom az uj generacios UI framework ami d3d-t hasznal(hat) rendereleshez. XAML pedig egy xml alapu 'ui' leiro nyelv alkalmazasokhoz,
amivel a guit tervezhetjuk meg ugy hogy egy single line C# kodot nem kell leirni. WinFS-rol is beszeltek annakidelyen de ilyen ugytudom meg nem kerult bele.
Letoltottem a legujabb IronPythont mert annak az egyik screencastjaba lattam egy XAML-es demot. Egy szamologep guija volt leirva xaml-be, minden gombnak kulon abszolut koordinatakkal. Gondlom van layout lehetoseg is,
de szamologep tipikusan az amit anelkul is meg lehet csinalni. Szoval a demo jol mukodott par sor koddal meg lehetett jeleniteni az xaml-bol felepitett
ablakot. Ez egy kifejezetten jo otlet szerintem a guibuilderek szempontjabol is, mert nem kodot kell generalniuk hanem csak egy xmlt. Javaba SwiXML neven
ismerhetunk hasonlo elven mukodo frameworkot. (meg meg lattam mast is de annak nem jut a neve eszembe).
Javaeknak is belekene huzniuk, mert desktop oldalon .net mar a kezdetektol elorebb jart, es ugynezki egyre csak jobb lesz.
Igaz azis hogy a .net a tudasa foleg egy platform kornyekere koncentralodik, illetve hogy szerveroldalon teljesen mas szempontok szamitanak.

Ami a legjobb ebbe a vista dologba hogy elvileg a win32apit felejthetjuk el es kapunk egy annal sokkal magasabb szintu .net apit. Igy remelhetoleg
nem csak a userek orulhetnek majd az uj oprendszernek es a desingos featureinek, hanem a fejlesztoknek is jobb dolguk lesz :].

PyHook

noreply@blogger.com (Zeroflag) — Mon, 12 Jun 2006 22:22:00 +0000

Az utobbi egy honapban 2x kellett kicserelni a ramot a desk gepben, es meg mindig nem jo valami mert idonkent ugy random BSODzik vmitol. Eleg idegesito gepeles kozben ha elszall es kezheti elorol (legalabbis legutobbi mentestol) az ember. Ugyhogy elhataroztam h amig ez a problema fennall, rakok egy keyloggert sajat gepre. Vagyis, inkabb irni jobb lenne. Regebben csinaltam keyboard hook alapjan mukodo progit cpp/winapival de most inkabb a konnyebb utat valasztottam. A PyHook egy thirdparty lib pythonhoz amivel meglehetosen egyszeruen hookolhatjuk az egeret/billentyuzetet. Egy hookmanagert kell letrehozni, beallitani egy eventet, es aktivalni a hookot. 3sor. A callbackben pedig szepen megkapjuk a lenyomott bill kodjat, a forras ablak handlejet, titlejet, a leutes idejet.. stb. Persze az egesz win alatt muxik mert nativ win32apis hivasokat (SetWindowsHook) wrappel. De hat nekem pont ez kell.


  >>> import pyHook, pythoncom
  >>> def kbproc( evt ): print evt.Ascii
  ... 
  >>> hm = pyHook.HookManager()
  >>> hm.KeyDown = kbproc
  >>> hm.HookKeyboard()
  >>> pythoncom.PumpMessages()

Egy olyasmit akarok ami kategoriazalja a logot a forras app-tol fuggoen. Szoval kulon logolja azt amit a bongeszobe irok, kulon azt amit az editor, es mondjuk nem logolja azt amit az irckliensbe.
Mivel az eventbol kiolvashato az ablak handleje ami eppen aktiv volt a billentyuzet leutes pillanataban ez eleg egyszeruen megoldhato. A handle alapjan az hozza tartozo app pid-jet kell meghatarozni, az alapjan pedig le lehet kerdezni a program nevet. (GetModuleFileName)

Ime a prototipus:


  def getProcNameByPID( pid ):
      h = None
      try:
         h = win32api.OpenProcess(win32con.PROCESS_QUERY_INFORMATION | win32con.PROCESS_VM_READ, False, pid)
         return os.path.basename( win32process.GetModuleFileNameEx( h, 0 ) )
      finally:
         if h: h.Close()

Ja, es a pidet az ablak handle-bol pedig igy kaptam meg:


  win32process.GetWindowThreadProcessId( evt.Window )[1]

A keyboard proc pedig a kovetkezo:


  def keyBoardProc( evt ):
      if evt.Key == 'F12':
         hm.KeyDown = None
         hm.UnhookKeyboard()
         return
      if evt.Ascii:
         fname = '%s.log' % ( getProcNameByPID( win32process.GetWindowThreadProcessId( evt.Window )[1] ) )
         open( fname, 'a' ).write( "%c" % (evt.Ascii) )

Lathato hogy F12-re probaltam meg unhookolni viszont, ilyenkor a lib egy AV-vel elszall, ugyhogy ez a feature nemigazan mukodik. Ha valaki tudja miert plz irja meg.
Mindenesetre a szelektalas jol mukodik, konnyen beallithato kulonbozo filter, hogy pl ircklienst vagy jatekot ne logolja mert az egyik ugyis logol maganak, a masiknal meg tok felesleges.

Majd ha lesz vmi vegleges verzio, esetleg kozzeteszem :)

NetBeans Collaboration

noreply@blogger.com (Zeroflag) — Sun, 04 Jun 2006 21:28:00 +0000

Az elozo postomhoz kapcsolodik hogy egy tok erdekes plugint taltaltam nb-hez. Ahogy a neveben is benne van a fejlesztoknek az egyutmukodeset segiti elo. Tartlamazza a hagyomanyos IM funkciokat, uzenetkuldes, partner felvetele stb, valamint az uzenetek formazasat syntax highlightolasat. Igy nem gond ha par soros kodot akarunk kuldeni, szepen megformazva kiszinezve kuldi el. Ezzel meg persze alig lenne tobb egy normal IM-nel. A legjobb hogy a komplett projectet meg lehet osztani, a tobbi koder lathatja a forrast, modosithatja, sot buildelheti meg futtathatja is. Amig valaki editalja a forrast addig a kornyezo sorokat a tobbiek szamara bejeloli es addig ok azt a kodreszletet nem tudjak szerkeszteni, majd amikor befejezte a modositast megjeleniti a tobbiek szamara is.

A plugin weblapjan gondolom bovebb infokat lehetne olvasni, de amiota probalom nekem nem jon be az oldal. NB5.5beta-val probaltam, update centerrol felrakhato "NetBeans Developer Collaboration" neven.

Netbeans pluginok

noreply@blogger.com (Zeroflag) — Sat, 03 Jun 2006 11:00:00 +0000

Idaig foleg eclipset hasznaltam de egyre jobban kezdek atterni NB-re. Szerintem sokkal intuitivebb, a featureok magatol ertetodobbek. Kicsit lassabban reagal meg tobbet eszik, de ez konnyen orvosolhato ha megfelelo vasat tesz az ember ala. Magaval eclipsevel sincs bajom inkabb egyketto 'erdekesen mukodo'/aluldokumentalt thirdparty pluginnal van problema. NB meg amiket alapbol tartalmaz azok ugylatom jol is mukodnek. Eclipse mellett szokott azaz erv lenni hogy 'dejo sok plugin van hozza', en mint ahogy fentebb irtam ezt inkabb hatranykent elem meg. De mindenesetre megneztem a netbeans plugin kepessegeit. Tulsagosan nem merultem el benne csak 2 egyszeru modult raktam ossze. Ennek a menetet fogom most leirni.

Biztos tobben voltak mar olyan helyzetbe hogy nehany soros kodreszletet kellett volna megosztani IM-en, IRCen vagy akarmilyen chaten valakivel. Kozvetlenul oda masolni ha par sornal tobb a kod akkor nem tul szerencses. Egyreszt attekinthetlen mert a tabokat altalban nem tartja meg, raadasul sok protokolon limitalva van az egyszerre elkuldheto szovegmennyiseg, legrosszabb esetben pedig a chatkliens mindenfele smiley jelekkre csereli a spec karaktereket a kodban. Erre vannak az ilyen 'nopaste' oldalak, ahol weben elpostolja a koder, az szepen kiszinezi, majd ad egy linket ahol meg lehet nezni illetve mutatni masnak. Tehat egy olyan plugint irtam ami a NB editoraban kijelolt kodot elkuldi egy ilyen oldalra majd megjeleniti a kapott linket. Az oldal pedig ami most hardcoded benne van a pluginba a http://phpfi.com/. (Egyebkent meg semmi kozom a phphoz csak ezt az oldalt ismerem :) )
Egy olyan esemenyre lesz szuksegem ami akkor kovetkezik be ha a user az editor popup menujet megnyitja. Valamint szuksegem van tovabba arra hogy lekerdezzem az eppen kijeolt kodot.

Noh, akkor nezzuk lepesenkent.

New project/NetBeans Plug-in Module kell nekunk.

Ezutan adunk neki egy nevet meg locationt/prj dirt.

Majd package nevet, config fileokat.

Elkeszult az uj projectunk, es most jon a lenyeg az action wizard. File/New/Action.

Tobb fele actiont lehet letrehozni, pl olyat ami context menure- vagy file menure kattintva generalodik. Ezeket kulonfele Cookie osztalyok reprezentaljak. Ami nekem kellett most azt az EditorCookie tudja, mivel rajta keresztul konnyeden elerhetem az eppen editalando forrast. GUI regisztracional az editor context menujebe regeltem be. Igy ha a forrasba jobb(ami nekem bal) gombbal kattintunk akkor felbukkano menuben benne lesz az ujjonnan beregisztralt modulunk.
Ha ezt mind megtettuk akkor az action wizard legeneral nekunk egy skeletont osztalyt aminek az performAction metodusa fog meghivodni a menure kattintaskor. Ide kell beirnunk a action kodunkat.

Egy EditorCookie peldanytol le tudjuk kerdezni az eppen nyitva levo JEditorPane-eket. Ez meg egy mezei swing komponens, innen mar a megszokott modon megy a kijeolt szoveg lekerdezese a getSelectedText() metodussal. Ha ez megvan mar csak fel kell postolni a cuccot az oldalra, de ezt nem reszletezem mert nem tartozika plugin temakorhoz. Egyebkent sima URLConnection-el csinaltam.

Egy kis osszedobott kodreszlet arrol amiron fentebb beszeltem:

    protected void performAction(Node[] activatedNodes) {
        EditorCookie c = (EditorCookie) activatedNodes[0].getCookie(EditorCookie.class);        
        if (c != null) {
            JEditorPane[] panes = c.getOpenedPanes();
            if (panes.length > 0) {
                String selection = panes[0].getSelectedText();                
                if ( "".equals( selection ) || selection == null ) {
                    JOptionPane.showMessageDialog( null, "At first you have to select the code snippet." );
                    return;
                }                
                Map params = new HashMap();
                params.put( "nick", "netbeans" );
                params.put( "descr", "netbeans code" );
                params.put( "lang", "java" );
                params.put( "source", selection );                
                try {
                    WebPost wp = new WebPost( "http://phpfi.com", params );
                    String response = wp.post();                    
                    LinkFrame lf = new LinkFrame();
                    lf.setLink( wp.getUrl().toString() );                    
                    lf.setVisible( true );                    
                } catch ( Exception e ) {
                    e.printStackTrace();
                    JOptionPane.showMessageDialog( null, "error: " + e.getMessage() );
                }                
            }            
        }
    }

Tesztelesre 2 fele lehetosegunk is van. Alapbol futtatasnal indit egy ujabb NetBeans peldanyt ami az en 512 mega rammal felvertezett gepemet nagyon megviselte(nagyon erik a ram vasarlas). Vagy betolthetjuk az eppen futo NB-be is a modult. Ekkor figyelmeztet hogy veszelyes es hasonlok, de nekem most nem volt belole gondom. Villamgyorsan (najo, NBhez kepest villamgyorsan) bedeployozta es az aktulis context menuben mar ott is figyelt a beregelt modulom. Egy klikkre pedig .nbm filet lehet generalni az egeszbol amit mar barki be tud deployozni a sajat NetBeanse ala a Tools/Update Center/Install Manually menuben.

Szoval osszesegeben tok jo IDEnek tunik, ami nincs benne alapbol itt is megoldhato kulso modullal, viszont nem vagyok rakenyszerulve hogy alap funkciokhoz is thirdparty pluginokat rakogassak fel. Valamin a Matisse is egy olyan dolog amit valoszinuleg nehezen tudnek nelkulozni a jovoben.

Kicsit bovebb infok + flashdemok elerhetok
http://platform.netbeans.org/tutorials/ innen.

Solaris?

noreply@blogger.com (Zeroflag) — Sun, 28 May 2006 22:25:00 +0000

Kiprobaltam a sol10 legujabb verziojat. De install nem ment olyan egyszeruen (kesobb kiderult nem biztos hogy a sol hibajabol) mert rogton ugy kezdte hogy:

"bzcat: Can't open input file /cdrom/Solaris_*/Tools/Boot/X.cpio.bz2: No such file or directory"

Persze a file pontosan ott volt ahol nem talalta. Ennek ellenere tovabbment de a dns/regional settings/stb beallitasok utan vegleg elszallt ezzel az uzivel:

"ERROR: The disc you inserted is not a Solaris OS CD/DVD"

Ilyenkor altalaban reflexbol googlehez nyul az ember. En is igy tettem, es lattam h nem vagyok egyedul ezzel a problemaval, volt mar masnak is ilyen baja. Ott bios allitgatas oldotta meg a problemat nalam az nem segitett. Mivel a gep mar regota hw hiba gyanus (pl a cdrol is hol bootolt hol nem), kicsereltem a cd ide kabelet, es egybol helyrejott.
Ezutan mar semmi problema nem volt az installal, siman felment a 4 cdnyi anyag.
Elso eszrevetel az volt a korabbi buildhez kepest (03/05-ot hasznaltam egy rovid ideig) hogy a bootmanagert lecsereltek grub-ra. Ez nem is baj. Viszont nem emlexem hogy mikor kerdezte volna a setup hogy hova akarok bootmanagert rakni igy egybol felulirta a sajatomat ami az mbr-be volt. Ez sem baj, majd visszarakom. (Viszont a grubba magatol beirta a wines particiot)

Az alaplapom szerepel a HCL listan igy azzal nagy baj nem volt. Leszamitva az alaplapra integralt VT6122 chipsetes halokartyat amihez thirdparty drivert kellett googlezni. Viszont ez hamar megvolt (thx to Masayuki Murayama). Az default sun cc forditoval lefordult, es meglepo mondon elsore mukodott is. Az egesz muvelet keresessel, readme olvasassal, forgatassal nem volt tobb 5-10 percnel. A szinten alaplapra integralt hangkartya viszont egybol mukodott es az XSun is tamogatja a radeon9250, igy a JDS is elsore elindult.

JDS ranezesre nem nagy valtozasokon ment at (attol meg lehet hogy a changelogba 2ezer bugfix van:) ), a start(?) menu (java menu?) ikonja ugyemlexem mas volt. Szoval ugyanolyan gnomeos/gtk-s kicsit lomha de szep joszag. Ami nagyon derek hogy alapbol ott a legfrissebb java runtime, sot JMF is, ami csak egy plusz opcionalis csomag lenne, itt megkapja a user outofthebox.
Eleg sok swinges utiliti van alapbol, es ebben a kornyezetben szerintem tokre jol is neznek ki az metal/ocean laf-al.
Ezek kozul a kedvencem ami nagyon elnyerte tetszesemet a Sun Update Manager . Winupdatehez hasonloan, kulonboz security patcheket, frissiteseket installalhatunk. Termeszetesen egy szep kis swinges kliens program van hozza, amibol ki lehet valasztgatni az installalando cuccokat a dependencyket pedig magatol lekezeli, es felrakott updateket akar uninstallni is lehet. Kulonlegessege hogy remote is managelheto bongeszobol egy webappal. Be lehet regelni tobbfele systemet amit karban akar tartani a user. Aki nem latta meg annak itt egy flashdemo meg egy kep:

Szoval tokjo lenne az egesz ha a hardware tamogatasa nagyobb lenne. Ez idovel persze javulni fog, de addig is aki teheti vegyen egy Ultra20 workstationt azon valszinu minden mukodni fog:). Ja es szoftver tamogatottsaggal is vannak kisebb gondok, pl eclipsebol meg mindig csak motifos van ami hat akar milyen szogbol nezem szerintem ronda:). Mercurybol sincs alapbol solaris package vagy install, de a slackwares verziobol kioperalva siman futott a pure swinges msn/jabber kliens. Azureus package szinten csak sparcos solarisra van. Szval pont ezek a javas appok amiktol elvarna az ember (a swingestol mindenkeppen de az persze mukodott is csak a keszitoje nem csinalt solos distribet) hogy gond nelkul mukodjenek itt is.
Jake2 -t is megprobaltam de ehhez eleve pesszimistan altam hozza mert ide nativ 3d konyvtarak is kellenek. Webstarttal nem is mukodott mivel a jnlp-be eleve csak lines meg wines libek voltak addolva, mast nem tudott letotleni. Az install szinten nem rakott fel semmit. Utaneztem es jogl-hez talaltam nativ solos libraryt, de lwjgl meg openal stb-t mar nem keresgeltem.
Ha mar javas appoknal tartunk kerestem es talaltam egy tokjo swinges filekezelot. Webstartal ez se indult el elsore vmier, de letoltve siman futott. Szoval http://www.ragework.com/ nekem igy elsore elegge bejon, tud szambazni, ftpzni, sftpzni, es azert egy mc-nel kenyelmesebb felulete van. Ja es nem is draga csak 34$. Aki parhuzamosan hasznal tobb fele os-t annak idealis imho.

Vegere akkor a summary:
A hw/sw tamogatottsagi problema az termeszetes egy olyan os-nal ami desktopokon meg nincs kello mertekben elterjedve. Foleg az hw ami gond lehet tvtuner/wlan/usbs kutyuk/szirszar amit osszevasarol a user es ra akarja dugdosni a gepre, mert sw tulajdonkep van minden ami fontos egy atlag usernek es ha nem valogatos es nem akar azert is mast hasznalni akkor ezen a teren nem lesz gondja vele. A hw support meg remelhetoleg idovel egyre jobb lesz. Aki csak fejlesztesre akarja hasznalni (netbeans rulez), es nem egy mindenes os-kent, jatekra/multimediara/stbre annak erdemes kiprobalnia.

Nem zope, de megteszi

noreply@blogger.com (Zeroflag) — Fri, 26 May 2006 13:23:00 +0000

Bar zope szervert szerettem volna blogolashoz, be kell ernem ezzel. Talan a zopebol mar lehet sejetni mirol fog szolni a blog egy resze. Noh nem zoperol mert az nincs, hanem inkabb pythonrol. De elorelathatolag javarol tobb szo fog esni. Meg ugy altalaban prog/info es azzal kapcsolatos dolgok. Igyexem szemelyes dolgokrol minel kevesebbet irni, igy nem biztos hogy olyan gyakran fogok postolgatni. Kezdetnek legyen eleg ennyi info, tobbit majd kesobb.