Newsgroup: it.comp.macintosh
Titolo: gioia: Qt+SIP+PyQt (versioni GPL) tutti funzionanti su Mac...!

Benche` SIP sia ancora tecnicamente un "release candidate", mi pare
finalmente che tutta la filiera Qt -> SIP -> PyQt, negli ultimi release
(GPL) disponibili, funzioni a puntino.  La compilazione (soprattutto di
Qt) prende TANTO tempo (oltre 4 ore sul mio iBook G4, 384 MB di RAM,
solo per Qt...), ma vabbe`, e` un'una tantum.
Affiancato a Python stesso, Twisted+Nevow, OpenSSL, PostgreSQL, e
robetta minore, PyQt era l'ultimo "mattoncino" che mi mancava fra quelli
che uso pesantemente come sviluppatore.  (Non so perche` ma wxPython non
mi ha mai convinto altrettanto, da un punto di vista puramente tecnico,
anche se e` un po' che su Mac va proprio a puntino).  Praticamente mi
manca solo OpenOffice 1.1 (pero` sento dire gran cose dell'ultimissimo
snapshot... che pare pero` vada compilato, e a 'sto punto aspetto la
settimana prossima cosi` provo sul Powermac che dovrebbe far prima...:-)
e tutti i miei strumenti principali li ho (in addizione a tutte le altre
carinerie Apple;-).  Gaudio!-)
Alex

 settimana prossima cosi` provo sul Powermac che dovrebbe far prima...:-)
tu dici? :))))
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan

 manca solo OpenOffice 1.1 
Sul sito di OO e' uscita la versione 1.1 anche se devi ricompilartela
perche' a quel che ho visto qualche giorno fa il pacchetto non era
ancora disponibile.
-- 
Ciao
Fabio

 
Boa lo trovo il massimo dell'instabilita', e poi serve per fare Gui per
wxPython, (se ti interessa per quello c'e' anche wxGlade). Per Qt prova
a dare un occhiata a eric che sembra parecchio funzionale, non ha un
designer per gui perche' si appoggia al designer ufficiale trolltech
pero' come IDE e' abbastanza completo (anche se sotto Os x mi e'
sembrato un po' instabile) se no per te ovviamente non posso che
consigliare Emacs con il mode python :-)
Ma ti stai avvicinando anche tu al Python  ? Marco Balestra tra un po'
ci caccia se aumentiamo troppo ;-)
-- 
Ciao
Fabio

 Ma ti stai avvicinando anche tu al Python  ? 
no comment.
-- 
mi hanno tanato...

 tu dici? :))))
Visto il tono con cui parla la pagina sulla compilazione di OO.o 1.1 su
Mac, dico si`...!-)
Alex

 ancora disponibile.
Si`, e` uno dei miei piani (appena KLM si decide a riportarmi a casa,
per ora sono bloccato all'aeroporto di Amsterdam da oltre quattr'ore, ma
dicono che fra un'oretta si risolve, speriamo...)
Alex

 
Questa e' una bella notizia, wxPython e' un ottimo framework ed e' un
peccato che molti (tra cui me) si facciano dei problemi nello sfruttarlo
solo per la documentazione.  
-- 
Ciao
Fabio

 Mac, dico si`...!-)
beh. io qui le casse di birra le ho... potrei anche affrontare suddetta
compilazione [ anche se al momento mi trovo molto bene con NeoOffice ].
In pratica credo che aspettero` il pacchetto, non posso permettermi la
macchina a casa per un giorno (ovviamente non posso portarmela in giro,
pena essere deriso dalla mia batteria ;) 


 pena essere deriso dalla mia batteria ;) 
Gia`, e` il "vantaggio" di un NON-portatile...;-).
Alex

 Gia`, e` il "vantaggio" di un NON-portatile...;-).
lol :)


 OK, facci sapere.
ho cominciato ad avere i primi problemi con SIP
ld: Undefined symbols:
_PyCFunction_NewEx
_PyGILState_Ensure
_PyGILState_Release
make[1]: *** [sip.so] Error 1
make: *** [all] Error 2
questo lo da in compilazione.
io avevo fatto il python configure.py, poi make, e ha cosi` reagito.
versione 4.0-rc3
con la 3.x dava pure errore ed eseguendo python build.py mi diceva di
usare la 4.


 Mi vergogno quasi a chiedere che cosa sia...
Mi scuso ma non so bene come tradurlo in Italiano.  Dunque, un qualsiasi
programma, nel suo "iter" (il latino si puo`, si?-) dalla concezione al
rilascio definitivo, passa attraverso varie fasi.  Le prime versioni
distribuite (di solito "solo a utenza amica":-) sono note come "alfa", e
nessuno si aspetta che siano molto solide, magari neppure complete.  Col
passar del tempo arrivano le "beta", gradualmente meglio.
Una volta, dall'ultima beta si passava direttamene al "rilascio", la
versione "vera" del programma ("release").  Al giorno d'oggi usa
rilasciare "per tentativi".  Finite le beta, quando lo sviluppatore
pensa che sia tutto a posto "ma non si sa mai", rilascia un "release
candidate", cioe` una versione "candidata a essere quella definitiva di
rilascio".  Se nessuno ci trova bachi, bene, si cambia solo il numero di
versione togliendo l'RC che tipicamente indica il Release Candidate.
Se qualcuno trova bachi, si rammendano, poi si fa un secondo release
candidate, e cosi` via.  SIP e` al suo terzo RC per la versione 4.0 ...
Alex

 versione 4.0-rc3
Interessante, perche` e` esattamente la versione che ho compilato e
istallato anch'io senza nessun problema.  Vediamo un po'...:
kallisti:~/downloads/sip-4.0rc3/siplib alex$ otool -L sip.so
sip.so:
        /System/Library/Frameworks/Python.framework/Versions/2.3/Python
(compatibility version 2.3.0, current version 2.3.0)
        libqt.3.dylib (compatibility version 3.3.0, current version
3.3.1)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 71.0.0)
kallisti:~/downloads/sip-4.0rc3/siplib alex$ 
E d'altra parte:
kallisti:~/downloads/sip-4.0rc3/siplib alex$ otool -T -v
/System/Library/Frameworks/Python.framework/Versions/2.3/Python | grep
PyCFunction_NewEx
methodobject.o   _PyCFunction_NewEx
kallisti:~/downloads/sip-4.0rc3/siplib alex$ otool -T -v
/System/Library/Frameworks/Python.framework/Versions/2.3/Python | grep
PyGIL            
pystate.o        _PyGILState_Ensure
pystate.o        _PyGILState_GetThisThreadState
pystate.o        _PyGILState_Release
pystate.o        __PyGILState_Fini
pystate.o        __PyGILState_Init
kallisti:~/downloads/sip-4.0rc3/siplib alex$ 
quindi tutti i simboli che a te trova irrisolti a me li risolve
correttamente la libreria dinamica di Python (istallata di natura come
parte di Panther, se non sbaglio).  Confermi di averla anche tu e che
contiene i dovuti simboli?  Se si`, resta da capire perche` a te non la
trova e a me si`, e debuggheremo la configurazione, immagino...
Alex


-- 
Ciao
Fabio

 parte di Panther, se non sbaglio).
infatti, + il pacchetto aggiuntivo di Jansen (ma quello penso lo avessi
anche tu).
piuttosto ho idea che il casino fosse dovuto al fatto che ho installato
anche python 2.2 (i darwin ports avevano deciso che ce ne era bisogno
per mettere su qualcosa che non ricordo...). Siccome nel PATH avevo
prima /opt/local/lib che quella di sistema, credo che lui andasse a
beccare le vecchie librerie del python. 
Comunque ora l'ho tolto, e mi da un nuovo errore creativissimo. [ ne
parlo poi ]
altra cosa che mi ero dimenticato di dire, sia prima sia ora riuscivo (e
riesco) a compilare correttamente applicazioni QT.
Introduco questo per spiegare che mi risulta inspiegabile l'errore che
da ora
Dome:~/Desktop/sip-4.0rc3 $ python configure.py 
Error: This version of Qt seems to use tmake but the TMAKEPATH
environment is not set.
la quale cosa e` logica poiche` non uso tmake... la cosa strana e` che
prima tmake non me lo chiedeva...


 prima tmake non me lo chiedeva...
Se vuoi possiamo scavare per capire in quali condizioni il configure.py
si convinca della necessita` di tmake, ma piu` in generale mi pare di
capire che la configurazione della tua macchina, in generale, e`
abbastanza incasinata (darwin ports, python 2.2, PATH strano, e poi che
altro...?).  Temo che accumulando un numero sufficiente di strati
sovrapposti non ne esci piu`...!-)
Dunque, tornando al configure.py: un semplice grep mostra che il
problema appare se os.access(qname, os.F_OK) torna un valore falso,
cioe` se qname non e` un file, dove anzitutto deve sicuramente essere
NON soddisfatta la condizione:
"QMAKESPEC" in os.environ.keys()
e inoltre neppure opt_platform, e qname viene costruito concatenando gli
elementi di path :
qname = os.path.join(qt_dir, "mkspecs", "default", "qmake.conf")
tu lo hai QMAKESPEC in environment?  Suppongo di no.
Allora dobbiamo scoprire com'e` che opt_platform non e` settata e cosa
vale qt_dir e perche` non hai qt_dir/mkspecs/default/qmake.conf ...
Per fortuna, sapendo gia` che a me python configure.py va bene, nasta
aggiungere un poco di print nella funzione rilevante, tipo alla linea
515 subito dopo la costruzione di qname un:
        print 'qname=%r' % (qname,)
da cui impariamo che, nel mio caso:
qname='/Developer/qt/mkspecs/default/qmake.conf'
che putacaso esiste eccome.  Nel tuo caso, cosa viene invece per qname
inserendo quel print?  Poi continuiamo a scavare sino a scoprire quale
delle tante feature strane del tuo environment sta ingannando il
configure.py di sip...
Alex
 

 configure.py di sip...
allora.. mi hai messo sulla giusta strada... 
qt non viene installato dentro ad opt seguendo la filosofia di
/Developer/qt
pertanto mi reinstallo tutto nel modo standard. anche perche` ormai ho
pasticciato a livelli notevolissimi, in pratica si farebbe solo il
triplo della fatica per nulla.
il grosso problema e` che i ports si installano in /opt/local ...
maledetti loro ;)


 maledetti loro ;)
Scusa ma non capisco perche` questo dovrebbe essere un problema grosso.
Alex

 Scusa ma non capisco perche` questo dovrebbe essere un problema grosso.
ormai non lo e`... mi sono messo a posto quasi tutti i paths vari...
piu` che altro la cosa brutta che sto scoprendo dei ports e` che il
sistema di dipendenze non e` buono come pensavo.


 sistema di dipendenze non e` buono come pensavo.
Ouch, questo si` e` un problema.  Sui port di OpenBSD non ho mai visto
problemi...
Alex

 problemi...
qui in sostanza in parte entrano in conflitto con i tools di macos (per
esempio ho installato gawk, che pero` mette su anche un symlink ad awk,
che siccome viene prima nel path ''nasconde'' la versione del macos).
e poi imho gli aggiornamenti non sono fatti bene. ovvero i vecchi
pacchetti restano quelli, anche se uno gli aggiorna sotto le cose.
non c'e` update, bisogna disinstallare e reinstallare. ovviamente la
cosa diventa noiosa con pacchetti che hanno dipendenze multiple.


 cosa diventa noiosa con pacchetti che hanno dipendenze multiple.
Doppio ahi.  Meglio forse restare a fink, allora.
Alex

 Doppio ahi.  Meglio forse restare a fink, allora.
infatti io sto passando tutto su fink, salvo qualche crosscompiler che
con i ports va su con una facilita` indicibile... 
anche se sono due mesi che li ho su e non ho ancora avuto tempo di
giocarci....


 Questo potrebbe magari essere una buona idea, si`...
allora, ho cancellato i ports dal mio ambiente, rimosso ogni traccia dei
ports.
purtroppo ho scoperto dopo che non erano minimamente responsabili, li ho
''puntiti'' inutilmente... contro loro avevano solo un sistema di
dipendenze subottimale.
installato di fresco QT dentro /Developer/qt.
mi da esattamente lo stesso errore di linking.
ho poi fatto le prove che mi hai detto, ed io nel Framework di Python
*ho* i simboli.
e non ho altre versioni di python installate.
tuttavia ho trovato un'altra copia del Python.framework
in 
/Library/Frameworks
questa senza i simboli cercati. [ e ce ne e` pure una terza dentro 
/Developer/SDKs/MacOSX10.3.0.sdk/System/Library/Frameworks/Python.framew
ork , ma questa non da problemi ].
Eliminato quella dentro /Library/Frameworks ha funzionato tutto. Lo dico
caso che mai questo problema lo incontri anche qualcun altro.
In sostanza ho idea che il problema potesse essere l'installazione di un
package Python sotto Jaguar, rimasto li spurio...
Ora mi funziona tutto ;)
grazie del supporto ;)


 grazie del supporto ;)
Prego!
Alex

 Bene!  Anche PyQt?
pure quello... adesso mi sto wgettando il libro open source (QT
programming with Python)...
L'interfacciamento con Python e` davvero naturale, a differenza di
quella con objc [ o dovrei anche li prendermi il cuore in mano e fare
from objc import * ].
Anche se effettivamente QT e` abbastanza ricca da sovrapporsi in parte
ai vantaggi di un linguaggio di alto livello...
Piu` che altro mi preoccupano gli eseguibili che genererei. Ovvero in
C++ linkando staticamente ottengo un eseguibile piu` grande che
semplicemente usando la condivisa, eppure molto portabile.
Su OS X potrei usare la versione statica [ non tutti hanno QT ], su
Linux quella dinamica (o anche quella statica), o semplicemente dare
solo i sorgenti.
Ma ho visto che PyQT non e` cosi` comune. Per esempio su Debian ho delle
grosse magagne a fare andare il tutto... o meglio, apt-get non basta, e
dovrei in sostanza fare a mano... ma a questo punto non posso piu`
contare sul fatto che le librerie necessarie siano gia` sul sistema
ospite. O meglio, QT c'e`, Python c'e`, ma non certo SIP e PyQT.
In sostanza visto quanto e` bello QT mi ero illuso di poter sviluppare
da un unico albero di sorgenti sia per GNU/Linux - f/o/nBSD etc... che
su MacOS X... Ma ho paura che PyQT non sia diffuso abbastanza... dovrei
probabilmente linkare il tutto staticamente e ''compilare'' il programma
python... o meglio, dovrei dire ''impacchettare''. Vabbe...
Per beccare i vari moduli, che programma usi? PackageManager non funge
bene... trucchi?


 bene... trucchi?
A me PackageManager funziona benissimo (trovi molti piu` moduli su siti
alternativi, non solo su quello di base, se e` quel che intendi).  Non
sara` che hai di nuovo problemi con quel robo in /Library/Frameworks
...?
Alex

 ...?
no.. quello e` stato abbattuto :)


 sito?
Credo proprio di si`. PackageManager non ha una interfaccia simpatica :)
-- 
nif from outer space

 no.. quello e` stato abbattuto :)
In effetti il bug che riscontri (le distutils danno giustamente la
versione attuale della piattaforma, le URL non sono aggiornate di
continuo per starle dietro) non ha nulla a che vedere con questo.
Alex

 Credo proprio di si`. PackageManager non ha una interfaccia simpatica :)
Si usa meglio da linea di comando (opinione personale), peraltro anche
la Wiki dice che la sua GUI e` "buggy ma usabile" o qualcosa del genere.
Alex


anche a me funge... ma c'e` un modo di specificarlo come predefinito?


 anche a me funge... ma c'e` un modo di specificarlo come predefinito?
Editando il modulo pimp, come ti ho gia` suggerito...
Alex

 la Wiki dice che la sua GUI e` "buggy ma usabile" o qualcosa del genere.
pywrap giusto?
io pero` non trovo ne manuale ne nulla... seccante...


 continuo per starle dietro) non ha nulla a che vedere con questo.
beh, grazie al trucchetto ora funge...


 Editando il modulo pimp, come ti ho gia` suggerito...
non avevo ancora letto :)



e` presente il link al database per Mac OS X 10.3.2 (darwin 7.0.2).
Ci sono differenze rispetto a quello che indichi tu (darwin 6.6)?
Inoltre non capisco una cosetta: tempo fa, ho installato un package (non
ricordo quale) che dipendeva dal pacchetto "nascosto" WriteableBin.
Naturalmente WriteableBin non e` un vero e proprio package: e`
sufficiente modificare i permessi della dir
/System/Library/Frameworks/Python.framework/Versions/2.3/bin per
renderlo "attivo" e permettere l'installazione di altra robetta.
Il "problema" e` che, in seguito, riparando i permessi con Utility
Disco, la directory in questione riottiene i permessi originali.
Esistera` un modo per rendere permanente la modifica? (Anche se,
effettivamente, non e` che uno si installi nuovi pacchetti tutti i
giorni...)


 giorni...)
Purtroppo non so da dove l'Utility Disco scopra quali permessi
"dovrebbero esserci" su vari file e directory.  Senza dubbio c'e` un
qualche file o database da aggiornare con queste info, ma non ho proprio
idea di dove si trovi.  Il problema e` indipendente da Python quindi
forse su qualche sito di trucchi MacOSX ci sono piu` dati...?
Alex

 io pero` non trovo ne manuale ne nulla... seccante...
Scusa ma credo di avere perso il filo di questa sotto-conversazione.
Dici 
http://www.pythonmac.org/wiki/BundleBuilder
 ?
PyWrap e` parte della collezione Py che complementa wxPython e trovi
qualcosa a 
http://wiki.wxpython.org/index.cgi/PyWrap
 ma non capisco bene
cosa c'entri.
Alex




 cosa c'entri.
c'entra che avevo toppato :)



ok.. ty.. non avevo capito :)


 c'entra che avevo toppato :)
NP!
Alex