Εκτύπωση μπρος/πίσω στο KDE 4

Ένα από τα θέματα που σκεφτόμασταν να ασχοληθούμε στο Greek Coding Camp ήταν η υποστήριξη για εκτύπωση μπρος/πίσω (Odd/Even pages) στο KDE 4 μια και είναι μία από τις πιο ενοχλητικές ελλείψεις αυτή τη στιγμή. Η λειτουργικότητα αυτή μοιάζει μικρή αλλά στην πραγματικότητα είναι ένα ζόρικο πρόβλημα.

Η υλοποίηση πρέπει να γίνει στο Qt (QPrinter) αλλά τώρα που το Qt έγινε LGPL και έχει και repository στο gitorious αυτό είναι κάπως ευκολότερο. Τελικά ανακαλύψαμε ότι ο John Layt είχε ήδη εκδηλώσει ενδιαφέρον και έτσι το θέμα σβήστηκε από τα projects.

Σήμερα λοιπόν μετά από προσωπική επικοινωνία με το John, έκανα μια δοκιμή στην τελευταία έκδοση του κώδικά του και ανακάλυψα ότι είναι ήδη αρκετά λειτουργικός (καλύτερα από ό,τι υπάρχει αυτή τη στιγμή στο Qt).

Για όποιον χρησιμοποιεί kubuntu ή debian-based διανομή και ενδιαφέρεται να δοκιμάσει τη λειτουργικότητα υπάρχουν packages του τροποποιημένου qt 4.5.2 (karmic) στο ppa μου.

Το μεγαλύτερο πρόβλημα αυτή τη στιγμή είναι ότι ο κώδικας δε συνεργάζεται με το okular (επειδή αυτό έχει τις δικές του ρουτίνες εκτύπωσης και θέλει ειδική προσαρμογή) αλλά εφαρμογές όπως kate, konqueror κλπ δουλεύουν.

Python/glibc/locale woes

./vusb-analyzer linux-storage-read.log.gz
Warning: psyco not found, install it for a nice speed boost.
Loaded decoder module 'Storage'
Loaded decoder module 'Bluetooth'
Loaded decoder module 'Cypress'
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.6/threading.py", line 525, in __bootstrap_inner
self.run()
File "/media/part1/Benchmarks/vmware/vusb-analyzer-1.0/VUsbTools/Log.py", line 497, in run
self.parser.parse(line)
File "/media/part1/Benchmarks/vmware/vusb-analyzer-1.0/VUsbTools/Log.py", line 184, in parse
UsbIOParser.parse(self, l[1][:-1], self.parseRelativeTime(line),
File "/media/part1/Benchmarks/vmware/vusb-analyzer-1.0/VUsbTools/Log.py", line 191, in parseRelativeTime
t = self.parseTime(line)
File "/media/part1/Benchmarks/vmware/vusb-analyzer-1.0/VUsbTools/Log.py", line 208, in parseTime
parsed = time.strptime(stamp, "%b %d %H:%M:%S")
File "/usr/lib/python2.6/_strptime.py", line 454, in _strptime_time
return _strptime(data_string, format)[0]
File "/usr/lib/python2.6/_strptime.py", line 325, in _strptime
(data_string, format))
ValueError: time data 'Jan 12 00:12:25' does not match format '%b %d %H:%M:%S'

wtf? και αμέσως μετά η επιφοίτηση:

LANG=C ./vusb-analyzer linux-storage-read.log.gz

Υποστήριξη για δημιουργία εικονικών scsi vmdk δίσκων στον Qemu

Το κόλπο της χρήσης qemu-img + vmware player για να φτιάχνει κανείς vmware appliances γρήγορα και δωρεάν, είναι γνωστό σε πάρα πολύ κόσμο. Δυστυχώς όμως το "vanilla" qemu-img φτιάχνει μόνο IDE vmdk images και όχι SCSI.

Αν το .vmx αρχείο σας λοιπόν έχει το δίσκο ως SCSI, o vmplayer θα σας χαιρετήσει με ένα κάπως ψαρωτικό μήνυμα κατά το boot. Η εύκολη λύση είναι φυσικά να πούμε στο vmware ότι ο δίσκος είναι IDE, αλλά το γεγονός αυτό μου κίνησε την περιέργεια: Άραγε πόσο δύσκολο θα ήταν να φτιάχνει το qemu-img SCSI vmdk images;

Από ότι φαίνεται: πανεύκολο :)

Μάλιστα υπήρχε ήδη patch από το Søren Hansen της canonical για μία παλαιότερη έκδοση του qemu, το οποίο (άγνωστο σε μένα ακόμα το γιατί) δεν ενσωματώθηκε.

Ορίστε λοιπόν το patch αυτό, ανανεωμένο για την git έκδοση του qemu (πιθανότατα θα εφαρμόζει και στο qemu-0.10.5 που υπάρχει στην Ubuntu).

Με ενσωματωμένο αυτό το patch, υπάρχει πλέον δυνατότητα να δημιουργεί κανείς scsi images ως εξής:

qemu-img create -f vmdk -o compat6=on,scsi=on image.vmdk 8G

Εγκατάσταση VMware Player σε 2.6.31 kernel

Το VMware Workstation και ο VMware Player είναι 2 προϊόντα φιλοξενίας εικονικών μηχανών που αποδεικνύονται χρήσιμα κατά καιρούς. Δυστυχώς χρησιμοποιούν τα δικά τους (κλειστού κώδικα) kernel modules με αποτέλεσμα την ταλαιπωρία του χρήστη όταν χρειάζεται να αναβαθμίσει τον πυρήνα του σε μια πιο σύγχρονη έκδοση.

Τουλάχιστον, τα τελευταία χρόνια, όσοι παράγουν κλειστού κώδικα modules τα φτιάχνουν ως ένα ανοιχτού κώδικα "wrapper" ο οποίος καλεί ένα binary blob. Τις περισσότερες φορές οι αλλαγές στον πυρήνα επηρρεάζουν μόνο τον κώδικα του wrapper οπότε βγαίνει άκρη αλλάζοντας μόνο αυτόν.

Αυτό συνέβει μόλις και στη δική μου περίπτωση, προσπαθώντας να εγκαταστήσω το VMware-Player 2.5.2 σε ένα σύστημα με πυρήνα 2.6.31-rc4. Ευτυχώς χάρη στην υπέροχη κοινότητα δε χρειάστηκε να κάνω σχεδόν τίποτα για τη λύση αφού κάποιος από τα φόρουμ του vmware είχε φτιάξει ήδη το κατάλληλο patch.

Έχοντας το patch η εγκατάσταση είναι απλή και μπορεί να γίνει κάπως έτσι:

1. Κατεβάζουμε το vmware player (bundle) και το patch σε ένα directory, ανοίγουμε ένα τερματικό και κάνουμε 'cd' στο directory αυτό.



2. Θέτουμε μια μεταβλητή για λόγους βολικότητας:
   

   export VMWARE_DIR=`pwd`
   

   
   



3. Ξεπακετάρουμε το bundle
   

   sudo sh VMware-Player*bundle --extract=$VMWARE_DIR/tmp
   

   
   



4. Πάμε στο directory με τον κώδικα των modules:
   

   cd tmp/vmware-player/lib/modules/source
   

   
   



5. Ξεπακετάρουμε όλα τα αρχεία με τον κώδικα:
   

   for i in *.tar; do sudo tar -xf $i; done
   

   
   



6. Εφαρμόζουμε το patch:
   

   sudo patch -Np1 -i $VMWARE_DIR/vmware-6.5.2-newkernmods.patch
   

   
   



7. Τώρα μπορούμε να σβήσουμε τα tarballs:
   

   sudo rm -f *.tar
   

   
   



8. Και να φτιάξουμε νέα με βάση τα αλλαγμένα directories:
   

   for i in *-only; do sudo tar -cf ${i/-only/}.tar $i; done
   

   
   



9. Τώρα πια τα directories δε μας χρειάζονται:
   

   sudo rm -rf *-only
   

   
   



10. Μπορούμε να πάρουμε τα νέα tarballs σε ένα μέρος
    

    cd .. && sudo tar -cf source{.tar,/} &&
    sudo mv source.tar $VMWARE_DIR
    

    
    



11. Επιστρέφοντας στο $VMWARE_DIR μπορούμε τώρα να εγκαταστήσουμε τον player:
    

    cd $VMWARE_DIR &&
    sudo sh VMware-Player*bundle
    

    
    



12. Και τώρα που εγκαταστάθηκε μπορούμε να αντικαταστήσουμε το δικό του κώδικα για τα modules με το δικό μας:

    sudo rm -rf /usr/lib/vmware/modules/source &&
    sudo tar -xf source.tar -C /usr/lib/vmware/modules
    

    
    



13. Έτοιμα όλα! Μπορούμε πλέον να τρέξουμε το πρόγραμμα:
    

    vmplayer

    
    

Τώρα κανονικά θα μπορέσει να μεταγλωττίσει σωστά τα modules του και θα οδηγηθούμε σε ένα σύστημα που δουλεύει :)

Greek (mis)Transliteration Problem in dblatex: An Analysis

In a comment in a previous post, Simos Xenitellis pointed out a problem with the xelatex backend of dblatex, asking whether it has been resolved in the new TL version.

Unfortunately, it turns out it is not. This is a more in-depth analysis of the problem to help whoever wants to try their hand on a fix. (Disclaimer: I 'm a novice to intermediate TeXnician, so please feel free to point out bugs and omissions in this analysis)

Everytime I see mis-transliteration (e.g., Τιτλε instead of Title) my instict points towards the direction of the greek option of babel combined with a unicode-oriented tex processor (like xetex).

Indeed after doing a

dblatex -d --backend=xetex --verbose mytestfile-el.xml

and inspecting the generated tex intermediate output, I found this was the case.

The problem is that babel's greek option stems from an ancient era of no unicode input, so it redefines the latin letters to greek counterparts e.g., "a" becomes "α" and so on (transliteration). So, whenever this option is used, one has to include the english words in the text within \textlatin{} to get them to display properly. Unfortunately we can't really expect dblatex to do that, since it is multilingual and adding this kind of hacks would soon lead to maintainance nightmare.

What can be done

An immediate workaround is to disable the use of babel altogether:

dblatex -P latex.babel.use=0 --backend=xetex --verbose mytestfile-el.xml

that gets rid of the mistransliteration, but also removes greek hyphenation (ouch). Fortunately we can get that from the xgreek package by greek guru TeXnician Apostolos Syropoulos. Unfortunately, this package is included first time in TexLive 2008 and nobody packages both TL 2008 and dblatex with xetex backend apart from gentoo (which means you get to build them from source no matter what :).

Therefore, the only seemingly sane solution for now is to package xgreek separately for TL 2007 and change the dblatex XSL scripts to add

\usepackage{xgreek}

if the lang parameter is "el" and the backend is "xetex". Any takers?

P.S., this would also solve this debian bug

TeXLive 2008 στην OpenSuSE

Δεν ξέρω αν ενδιαφέρεται κανείς άλλος γι αυτό, αλλά η μόνη διανομή αυτή τη στιγμή που έχει binary packages για TeXLive 2008 είναι η OpenSuSE. (Το TL 2008 είναι και στη gentoo αλλά θα πρέπει να περιμένει κανείς να γίνει compile, τουλάχιστον έτσι νομίζω)

Το TeXLive 2008 είναι σημαντικό γιατί υποστηρίζει καλά τα ελληνικά στο xelatex, έχει ενσωματωμένο pdfsync και μερικά άλλα καλούδια. Για να το στήσετε σε ένα vanilla opensuse μηχάνημα / VM αρκεί να προσθέσετε το "Publishing" repo.

$ zypper ar http://download.opensuse.org/repositories/Publishing/openSUSE_11.1 publishing

$ zypper install texlive-xetex

κλπ.

H SuSE (6.4) ήταν η πρώτη μου διανομή και να που ξαναβγαίνει χρήσιμη :)

Gcc09: Sha384withECDSA και openjdk (a detective story)

Άλλο ένα project που υλοποιήθηκε στα πλαίσια του GCC2009 ξεκίνησε με αφορμή ένα debian bug που μετατράπηκε σε openjdk (classpath) bug.

Το σύμπτωμα ήταν ότι το εργαλείο keytool της java αρνιόταν επίμονα να εισάγει (import) το certificate της εταιρείας COMODO παραπονούμενο ότι ο αλγόριθμος υπογραφών "ECDSAwithSHA384" δεν είναι διαθέσιμος. Αυτό είχε ως συνέπεια σχεδόν ολόκληρο το java stack του debian/ubuntu να μεταβαίνει στην κατάσταση FTBFS (fail to build from source) πράγμα φυσικά παράλογο, γι αυτό και το bug είχε σοβαρότητα "serious".

Λίγο πριν την έναρξη του camping, ο Matthias Klose (aka doko) έκλεισε το bug με ένα κατά τη γνώμη μου προσωρινό "workaround", σύμφωνα με το οποίο το ca-certificates πακέτο παύει πλέον να παραπονιέται όταν του ζητούν να εισάγει ένα certificate του οποίου ο αλγόριθμος υπογραφής δεν είναι διαθέσιμος. Φυσικά με αυτό τον τρόπο αυξάνουν οι πιθανότητες "έκπληξης" του χρήστη ο οποίος βλέπει ότι για κάποιο μυστήριο λόγο η java εφαρμογή του δεν εμπιστεύεται ένα site παρά το γεγονός ότι το certificate authority αυτού του site βρίσκεται στο /etc/ssl όπως θα έπρεπε.

Επειδή λοιπόν επιθυμία όλων μας πιστεύω ως χρήστες είναι να μειώνονται οι δυσάρεστες εκπλήξεις όσο περνάει ο καιρός αντί να αυξάνονται, τέθηκε η ιδέα της μόνιμης διόρθωσης του προβλήματος. H δουλειά λοιπόν ήταν κατά κύριο λόγο το λεγόμενο "triaging" του bug, να ρίξουμε φως δηλαδή στο μυστήριο του γιατί ο standard αυτός αλγόριθμος δεν ήταν διαθέσιμος αλλά και η διόρθωση του bug υλοποιώντας ό,τι βρούμε ότι λείπει, προκειμένου ο αλγόριθμος να δουλέψει.

Η πρόκληση έγινε κάπως μεγαλύτερη από το γεγονός ότι ούτε εγώ ούτε ο Κωστής Αναγνωστόπουλος με τον οποίο συνεργαστήκαμε σε αυτό το project δεν είχαμε εμπειρία από την εσωτερική δομή του openjdk, χρειαζόταν δηλαδή να εφαρμοστούν οι αρχές του "large scale code reading" που τόσο ωραία έχει περιγράψει ο κος Σπινέλλης στο βιβλίο του. (Τουλάχιστον κρίνοντας από τα samples και τα περιεχόμενα αφού ομολογώ ότι δεν το έχω διαβάσει :p. Από σήμερα πάντως θα το βάλω σίγουρα στο wish-list)

Το πρώτο βήμα ήταν λοιπόν η ανάγνωση του κώδικα του keytool και η κατασκευή ενός πολύ μικρού "testcase" (γύρω στις 5 γραμμές κώδικα), το οποίο παρουσίαζε το πρόβλημα απλοποιώντας το παράλληλα σε μεγάλο βαθμό. Από εκεί και πέρα γνωρίζαμε ότι εφόσον το testcase θα δούλευε, το πρόβλημα θα είχε λυθεί.

Έπειτα, συνεχίσαμε την ανάγνωση του κώδικα του openjdk χρησιμοποιώντας το eclipse (δηλαδή στο laptop του Κωστή εφόσον στο δικό μου δεν ήθελε ούτε το 3.5 ούτε το 3.4 να δουλέψει με καμμία δύναμη και εφόσον δεν είχαμε ουσιαστικά πρόσβαση στο δίκτυο έπρεπε να ξεχάσουμε και τις άλλες εκδόσεις). Η ιδέα ήταν να εντοπίσουμε και να "ιχνηλατήσουμε" (trace) το μονοπάτι εκτέλεσης στο οποίο φορτώνονται οι αλγόριθμοι υπογραφών, προκειμένου να ανακαλύψουμε πού βρίσκεται ο κώδικας αυτών των αλγορίθμων.

(Φυσικά και το πρόβλημα δεν είναι τόσο προφανές ώστε να λύνεται με μία find/grep. Οι providers μπορεί να βρίσκονται είτε σε αρχεία java είτε σε native βιβλιοθήκες που προσπελαύνονται μέσω JNI και η όλη διαδικασία συντονίζεται από αρχεία ρυθμίσεων που και αυτά βρίσκονται σε άλλο μέρος ανάλογα με τη διανομή. ΠΡΟΣΟΧΗ! όσοι έχετε διαβάσει ως εδώ, παρακαλώ ΜΗΝ πηδήξετε από το παράθυρο, τουλάχιστον όχι ακόμα, έχει και καλύτερο παρακάτω :p)

Μετά από μια μέρα συνεχούς χτυπήματος του κεφαλιού στον τοίχο λοιπόν, καθώς και το έξτρα ρίξιμο της ψυχολογίας από το να βλέπεις άλλες ομάδες να γράφουν ένα σωρό κώδικα στο ίδιο διάστημα :p ο Κωστής έφτασε στη ρίζα του προβλήματος ενώ εγώ ήδη ασχολούμουν με την υποστήριξη των ADSL modems (περισσότερα γι αυτό σε άλλο post). Σημαντικό είναι να παρατηρήσουμε ότι το πιο βοηθητικό στοιχείο ήταν τα runtime debug messages (Debug java-prop: java.security.debug={all|provider|sunpkcs11}) και όχι η στατική ανάλυση καθώς τόσα πολλά συστατικά του security framework καθορίζονται δυναμικά κατά το χρόνο εκτέλεσης.

Για καλή μας τύχη ανακαλύψαμε ότι το πρόβλημα υπάρχει εξίσου και στο sun jdk και έχει επιλυθεί σε μεγάλο βαθμό από τον Andreas Sterbenz. Η ιδέα είναι ότι η Java χρησιμοποιεί το PKCS11 διεθνές πρότυπο μεταξύ άλλων και για κρυπτογραφία ελλειπτικών καμπυλών (Elliptic curves) και μία βιβλιοθήκη που υλοποιεί αυτό το πρότυπο είναι η NSS (γνωστή λόγω του mozilla project). Αρκεί λοιπόν να συνδέσουμε τα δύο και είμαστε έτοιμοι.

Η σύνδεση επιτυγχάνεται φτιάχνοντας απλά ένα αρχείο ρυθμίσεων (/etc/java-6-openjdk/security/sunpkcs11-NSS.conf στο debian) με τα εξής περιεχόμενα:

    name = NSS
   nssLibraryDirectory = /usr/lib
   nssDbMode = noDb
   attributes = compatibility

Μετά από αυτό, μπορούμε να προσθέσουμε το sun.security.pkcs11.SunPKCS11
security provider στο αρχείο /etc/java-6-openjdk/security/java.security προσθέτοντας απλά μία γραμμή ως εξής:

security.provider.9=sun.security.pkcs11.SunPKCS11 /etc/java-6-openjdk/security/sunpkcs11-NSS.conf

(το παραπάνω είναι μία γραμμή) και επιτέλους το testcase (και κατ' επέκταση το import του COMODO certificate) δούλεψε :)

Υπήρξε μόνο ένα πρόβλημα: πιθανότατα για λόγους κανονισμών της Aμερικής σχετικά με την εξαγωγή κρυπτογραφικών μεθόδων, ο κώδικας κρυπτογραφίας ελλειπτικών καμπυλών δεν είναι ενσωματωμένος στην προεπιλεγμένη ρύθμιση της βιβλιοθήκης NSS. Αυτό συμβαίνει ίσως και στη Fedora 11(αν και ομολογώ ότι δεν κοιτάξαμε το spec file της nss βιβλιοθήκης) με αποτέλεσμα να μην μπορεί να χρησιμοποιηθεί ο εν λόγω αλγόριθμος σε αυτή τη διανομή (πιθανόν να χρειαστεί bug report).

Στη Gentoo η μέθοδος δουλεύει με τη μικρή διαφορά ότι πρέπει να προβλέψουμε ότι η NSS βιβλιοθήκη βρίσκεται στο /usr/lib/nss και τα αρχεία ρυθμίσεων (π.χ., java.security) δε βρίσκονται στο /etc. Επίσης χρειάζεται το πακέτο dev-libs/nss-3.12.2. Τέλος, στη debian/ubuntu ο τρόπος αυτός δουλεύει αρκεί να είναι εγκατεστημένο το πακέτο libnss3-1d που περιέχει τη βιβλιοθήκη NSS.

Καταλήξαμε λοιπόν ότι το πρόβλημα έχει ήδη λυθεί και αρκεί η λύση αυτή να ενσωματωθεί στις διανομές. Για την ubuntu jaunty θα ανέβουν σύντομα πακέτα στο ppa μου που συμπεριλαμβάνουν αυτή τη λειτουργικότητα, ενώ θα γίνει συζήτηση και για ενσωμάτωση στη debian και από εκεί στην επόμενη έκδοση της ubuntu ίσως.

Το μεγαλύτερο δίδαγμα από αυτό το project ήταν ότι καμμιά φορά και το debugging/triaging ενός προβλήματος μπορεί να παρέχει αρκετές συγκινήσεις και σπαζοκεφαλιές οπότε οι triagers αξίζουν και αυτοί το σεβασμό μας :) Επίσης, μερικές φορές (όπως αυτήν) το triaging είναι το 98% της δουλειάς αφού η ίδια η επίλυση ήταν μόνο 10 γραμμές σε 2 configuration files τελικά.

Η συνεργασία με τον Κωστή ήταν τουλάχιστον εξαιρετική (μάλιστα ο ίδιος έδειξε πρωτοβουλία και ουσιαστικά έλυσε το μεγαλύτερο μέρος μόνος του) και πραγματικά ανυπομονώ να δουλέψουμε και σε άλλα project μαζί στο μέλλον :)

Gcc09: Υλοποίηση Ελληνικής Αρίθμησης

Το πρώτο από τα project του GCC09 που θα ήθελα να παρουσιάσω είναι η υλοποίηση ελληνικής αρίθμησης για το OpenOffice.org. Το project αυτό προτάθηκε αρχικά στα πλαίσια του συνεδρίου ΕΛΛΑΚ από τον Κώστα Παπαδήμα και μια και ήταν σχετικά μικρό και εύκολο, φάνηκε καλή ιδέα να το εντάξουμε στα έργα του camping μας.

Τα πράγματα έγιναν ακόμα ευκολότερα όταν μερικές μέρες αργότερα ο Διομήδης Σπινέλλης ασχολήθηκε με το πρόβλημα και παρουσίασε ένα αλγόριθμο σε Java ο οποίος καλύπτει ουσιαστικά όλους τους ακεραίους.

Εφόσον η κατάσταση είχε απλοποιηθεί τόσο, αποφασίστηκε κατά τη διάρκεια του camp να αναλάβω το project ο ίδιος, εφόσον ο Ηλίας που ήταν επίσης ενδιαφερόμενος ήταν απασχολημένος με το project των templates (στο οποίο έγινε εξαιρετική δουλειά btw, ειδικά το template για την υπεύθυνη δήλωση που φτιάχτηκε από το μηδέν).

Στο δικό μου κομμάτι, στην αρχή ασχολήθηκα με το πώς θα κάνω το build του oo.org αποδοτικά, μια και δεν είναι μικρό project ;) Ευτυχώς, η εταιρεία ΕΛΛΑΚ είχε φροντίσει να μας παρέχει πρόσβαση σε ένα αρκετά δυνατό server στο ntua (τι καλοί άνθρωποι που είναι αυτοί στην ΕΕΛΛΑΚ, σε σκλαβώνουν ώρες-ώρες :)

Δυστυχώς, λόγω τεχνικών θεμάτων δεν μπορούσαμε να έχουμε root ή sudo access οπότε δεν ήταν δυνατόν να εγκαταστήσουμε τις εξαρτήσεις. Ευτυχώς λύθηκε και αυτό χάρη στην προθυμία των διαχειριστών του server και τη μεσολάβηση του Νίκου Ρούσσου και το βράδυ ξεκίνησε το build του developer milestone 51
(σε screen session φυσικά).

Για όσους ενδιαφέρονται, η βέλτιστη εντολή για το build του oo.org σε ένα 16-πύρηνο μηχάνημα βρέθηκε να είναι η:

cd instsetoo_native &&
build --all --dlv_switch -link -P4 -- -P4

Ουσιαστικά η εντολή αυτή παράγει 4 dmake instances τα οποία τρέχουν 4 build.pl το καθένα. Το συγκεκριμμένο configuration σε συνδυασμό και με ccache και ένα καλό RAID μπορεί να κάνει το full build του oo.org ιδιαίτερα αποδοτικό για development και testing. Ας ελπίσουμε ότι κάποιο εκπαιδευτικό ίδρυμα θα σκεφτεί σοβαρά την παροχή ενός τέτοιου μηχανήματος για tinderbox σε πιο μόνιμη βάση. Περισσότερες λεπτομέρειες για τη δομή του κώδικα του oo.org, το building (και το debugging του build που είναι πιο σημαντικό) μπορούν να δοθούν σε άλλο post αν υπάρξει ενδιαφέρον.

Ας επιστρέψουμε όμως στην καθεαυτό υλοποίηση της αρίθμησης. Αντίθετα με τον τρόπο ανάγνωσης που παρουσίασε ο κος Σπινέλλης στο blog του, υπάρχει ένας αρκετά γρηγορότερος τρόπος να διαβάσει κάποιος τον κώδικα του oo.org και να τον καταλάβει αρκετά καλά ώστε να υλοποιήσει την αρίθμηση :) O τρόπος αυτός είναι φυσικά η αξιοποίηση του google και των ανθρώπινων γνωριμιών (Κωστής Παπαδήμας) ώστε να οδηγηθούμε στο patch που υλοποιεί την αντίστοιχη λειτουργικότητα για τα βουλγαρικά/κυριλλικά.

Έχοντας λοιπόν πια όλα τα συστατικά, η υλοποίηση ήταν αρκετά εύκολη. Επειδή υπήρξαν κάποιες ενστάσεις σχετικά με την άδεια χρήσης κλπ του κώδικα Java, υλοποίησα και μία έκδοση εντελώς "from scratch" η οποία μπορούσε να μετρήσει ως το 10000 (υπέραρκετό για λίστες και παραγράφους εκτός ίσως αν κάποιος θέλει να γράψει το Mathematica Book ;) την οποία θα μπορούσα να υποβάλλω αν για κάποιο λόγο δεν μπορούσαμε να βρούμε έγκαιρα τον κο Σπινέλλη (καθώς το καλοκαίρι είναι χρόνος συνεδρίων/διακοπών κλπ).

Τελικά ούτε αυτό δε χρειάστηκε (ο κος Σπινέλλης ανταποκρίθηκε σε προσωπικό email εντυπωσιακά γρήγορα), οπότε σήμερα το patch στάλθηκε στη λίστα του greek coding camp και στους υπόλοιπους ενδιαφερόμενους για review και εκτός απροόπτου θα συμπεριληφθεί επίσης στο σχετικό bug του oo.org με στόχο την ενσωμάτωση στην έκδοση 3.2.

Υπάρχουν σκέψεις για την παροχή πακέτων τουλάχιστον για ubuntu και freebsd (3.1 + ελληνική αρίθμηση) αν κάποιος δεν μπορεί να περιμένει ως την έκδοση 3.2 για αυτή τη λειτουργικότητα, αλλά προς το παρόν ας αρκεστούμε σε ένα "screencast" (please be gentle, it is my first time :p )

Ας συστηθούμε

Hello, world :)

Αιτία για τη δημιουργία αυτού του ιστολογίου αποτέλεσε το Greek coding camp 2009 και τα projects του. Με την ευκαιρία όμως ελπίζω να μπορέσω να το ανανεώνω με διάφορα θέματα σχετικά με τεχνολογία, μουσική και ίσως και κάποιες προσωπικές εμπειρίες και αναζητήσεις.