Newsgroup: it.comp.macintosh
Titolo: Potreste non voler comprare un MacIntel [gmp et altri]

Beh, se per caso nel vostro lavoro o nel vostro hobby è importante usare
gmp... non fatelo. Non comprate un MacIntel.
Dopo un po' di inspiegabili errori (risolvibili solo disattivando
completamente le ottimizzazioni) ho chiesto in mailing list.
La risposta è stata piana e semplice:
I mac intel non sono supportati. Con un tono come dire: 
sono cazzi tuoi (ma questa è una mia interpretazione).
Un po' come dire... sei tu che te lo sei voluto il Mac... se usavi
"Software Veramente Open Source"... (altra interpreatazione mia).
Certo... magari non avete bisogno di gmp o di ginac o di cln (cln
semplicemente non funziona, mi chiedo se clisp invece lo faccia.
Esattamente non ho capito se cln e clisp condividono codice o
semplicemente uno è l'implementazione indipendente degli interi del
lisp.
OCaml pure lui ha i suoi problemi. Ma li gli sviluppatori si sono
sbattuti: c'è già una versione beta in un ramo secondario di sviluppo
che risolve i problemi.
Insomma... queste sono alcune cose che ho provato. Immagino che non
siano le uniche a non funzionare. Mi sento tanto tanto betatester.
La macchina è stupenda... ma ho perso circa una settimana di lavoro e
non sono ancora riuscito a fare andare tutto quanto.
Enjoy.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 non sono ancora riuscito a fare andare tutto quanto.
C'era da immaginarselo comunque, anche io sto' combattendo con una serie
infinita di piccoli problemi, ma con una serie nuova cosi' era da
mettere in conto...
-- 
Porco Jobs!

 mettere in conto...
Si, ma mi sto girocoglionando forte. E a Jobs un bel coretto di
vaffanculo glielo farei volentieri. Anche se al momento mi sembra siano
più quelli di gmp che stanno facendo in modo seccante.


 che e`
appunto la "veste" Python di GMP.  Il Macbook Pro mi e` appunto arrivato
giusto ieri.  Purtroppo, con la 2a ed del Nutshell in "chiusura", non
trovero` sicuramente "a breve" il tempo di lavorare su GMP; ma chiuso il
Nutshell e dopo una bella settimana di vacanza in Arizona (Gran Canyon),
verso fine aprile il tempo dovrei finalmente averlo.
E non ho il minimo dubbio che, con o senza l'aiuto di altri
sviluppatori, riusciro` a far funzionare GMP sul Macbook.  E` il
vantaggio dell'open-source... se fosse una applicazione o libreria
chiusa non potrei avere nessuna fiducia in merito.
Certo, se a te serve oggi, e non sei in grado o non hai il tempo di
farlo funzionare, ci puo` essere un transitorio spiacevole.  Ma alla fin
fine sono proprio queste le esperienze che costruiscono un carattere!-)
Alex
 

 fine sono proprio queste le esperienze che costruiscono un carattere!-)
Si. A me servirebbe più o meno a breve. E sopra devo fare girare
dell'altro software (cui falliscono dei make check, bisognerà capire se
per colpa sua oppure di "bachi" non noti in gmp non ottimizzato).
Quello che mi ha seccato, è il modo in cui mi hanno risposto in mailing
list. Come se dicendo "i Mac intel" non sono supportati si risolvesse
qualcosa. Ho chiesto se avevano suggerimenti su dove mettere le mani
(gli errori sono drammaticamente assurdi), e la risposta è stata non c'è
stata.
Purtroppo gmp non è un giocattolino per cui possa apprendere la
conoscenza degli internals in breve tempo (e comunque sembrerebbe --
almeno uno -- un baco sulla configurazione, più che nel codice).
E purtroppo gli autotools io li ho usati in team, ma non ci ho mai
dovuto mettere direttamente le mani.


 stata.
questo e' l'opensource, ragazzo... bello, in teoria

 questo e' l'opensource, ragazzo... bello, in teoria
che cazzo vorrebbe dire sta cosa?
-- 
My WebSpace: 
www.digitroom.com
 /In lavorazione/
non studio non lavoro non guardo la tv
non vado al cinema non faccio sport

 questo e' l'opensource, ragazzo... bello, in teoria
Direi che il problema non è "essere open". Anzi, questa è una garanzia
che prima o poi i problemi saranno fixati.


 che cazzo vorrebbe dire sta cosa?
vorrebbe dire che spesso in teoria trovi tutto e in pratica hai una roba
che sulla tua piattaforma non compila liscia e/o la cui documentazione,
quando va bene, sono 12754 paginette con tutte le classi realizzate da
qualche programmello automatico senza una mezza riga scritta che ti
orienti vagamente

 che prima o poi i problemi saranno fixati.
no il problema non e' che sono open, il problema e' che chi li porta
avanti privilegia e testa sulla piattaforma che usa e generalmente non
documenta un cazzo

 documenta un cazzo
No, la documentazione c'è. È il mio tempo di mettere le mani in tutto
l'ambaradan che non c''è.


 l'ambaradan che non c''è.
Mai dovuto scrivere un plugin per gimp vero?
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 Mai dovuto scrivere un plugin per gimp vero?
In Perl o in C o in cosa?
Comunque scrivere un plugin è diverso da mettere le mani *dentro*
l'applicazione: i plugin li fanno apposta per non costringere a
familiarizzare con tutta l'applicazione, ma solo con una "facile"
interfaccia ridotta.


 l'ambaradan che non c''è.
quello che non e' chiaro e' cosa ha di *speciale* darwin intel rispetto
a che so io fedora intel, o debian intel o... non mi dire che anche
quelle non sono supportate...

 dovuto mettere direttamente le mani.
*AAAAAA[etc]AAArgh* -- la cosa che odio di piu` nel SW opensource sono
proprio gli autotools.  Se il problema diventa debuggare gli autotools,
invece che debuggare codice macchina, lascio perdere, e vedro` come
portare gmpy ad usare (in alternativa a GMP) le librerie proprietarie
intel o checchessia d'altro, sorry.
Alex

 proprio gli autotools.  
alle volte le *soluzioni* a questo problema sono peggiori del male
mi e' capitato recentemente, nel tentativo *fallito* di
trovare/compilare una libreria DICOM *usabile*, di trovare cmake, scons,
bjam... che uno si trova costretto a installare e usare a mo' di ricetta
di cucina senza capire granche' di quello che succede, e figurarsi se
qualcosa va storto
tra poco finiremo con l'avere un build system dedicato per ogni progetto
e amen
(detto questo gli autotools fanno veramente ribrezzo)

 interfaccia ridotta.
ROFTL! la doc. per scrivere un plugin si riduce a 3-4 pagine, se vai a
chiedere nel newsgroup, o sul canale irc ti rispondono "guarda il codice
dei plugin esistenti e fai copia-incolla".
Non parliamo poi della doc. di gtk, che non e' completa/aggiornata.


 Non parliamo poi della doc. di gtk, che non e' completa/aggiornata.
Strano, afair la doc di gtk non era male. Ma non ci lavoro da diversi
anni.


 quelle non sono supportate...
Il fatto che in quanto MacOS ha ovviamente le sue peculiarità (a livello
cretino, ormai gestito, ma relativamente di recente, il fatto che usi
-dynamiclib invece di -shared ; un bel po' di progetti andavano
compilati staticamente solo perchè libtool toppava sta cosa).
Inoltre *ovviamente* i vari unices non sono assembly compatibili. Poi
adesso devo fare due prove, ma sembrerebbe che MacOS X per certe cose è
atipico. Peccato non avere linux boxes sotto mano.


 intel o checchessia d'altro, sorry.
Si. Io temo che il problema sia quello. Un file generato chiamato
tmp_qualcosa.s è semplicemente vuoto (mentre dovrebbe essere pieno).
La cosa divertente è che questo accade *solo* se abiliti --enable-cxx.
Se usi l'interfaccia piana, non succede nulla. Ah, e in mailing list
sono d'accordo che --enable-cxx non dovrebbe comportare nulla del genere
(again... i mac intel non sono supportati, ma imho c'è qualcosa di
aggrovigliato nel configure).
Intendo dire.. non succede nulla, finchè non fai make check. A quel
punto partono errori di linking a randa (errori che non ci sono se
semplicemente linki gmp ad un eseguibile, per dire gmpbench).


 (detto questo gli autotools fanno veramente ribrezzo)
Sinceramente però non vedo un mucchio di altre soluzioni.
Nel senso che il problema di fare girare sw su vari unices ciascuno
leggermente incompatibile è davvero peloso.
Altre soluzioni efficaci non ne ho viste (ancora). A meno di non
appoggiarsi ad un qualche linguaggio di alto livello moderno e scriversi
un filino di codice a mano.
Ma immagino che non si voglia introdurre una dipendenza da un linguaggio
di scripting e si voglia rimanere a shell.


 di scripting e si voglia rimanere a shell.
scons e' appunto in python... dovrebbe gustarti
(quello che odio e' l'eccesso di soluzioni, ma non era piu' semplice non
creare il problema :-O?)

 atipico. Peccato non avere linux boxes sotto mano.
eh, hai voluto risparmiare :-PPP

 (a parita' di gcc dico)
Il modo in cui fai le chiamate di sistema cambia però (per esempio se
compili un programmino cretino sotto MacOS non fa nemmeno vere e proprie
"chiamate di sistema" ma usa .indirect_symbol 


 scons e' appunto in python... dovrebbe gustarti
Non lo conosco.. hai link?


 Il modo in cui fai le chiamate di sistema cambia però 
ma sei davvero sicuro di averne bisogno dall'asm? boh...

 Non lo conosco.. hai link?
www.scons.org
(non per dire ma e' la prima hit di gugle)

 ma sei davvero sicuro di averne bisogno dall'asm? boh...
Si. gmp scritta in C sul mio CoreDuo va più piano che sul G4 con una
moderata ottimizzazione assembly. Nel software di calcolo tutt'ora
ottimizzare le 4 o 5 funzioni chiave alla base è semplicemente
impagabile.
Addirittura a lungo GMP è stata molto più cazzuta su AMD, proprio perchè
meglio ottimizzata (adesso on so).


 
www.scons.org
Interessante. Lo hai usato? Funziona bene?
Come è la curva di apprendimento?


 impagabile.
magari basta ottimizzare solo alcuni pezzi di quelle 4-5 funzioni,
lasciando fuori le malloc, per dire (senza sapre che sia gmp)

 Come è la curva di apprendimento?
io sto a 0 :-)

 lasciando fuori le malloc, per dire (senza sapre che sia gmp)
Non credo che ci faccia dentro delle malloc. Il mio era solo un esempio.


 io sto a 0 :-)
Ok. resto con te ;)


 fBSD x86
senza sforzo
(per scrivertelo dovrei imparare l'asm x86... mai frequentato) 

 (per scrivertelo dovrei imparare l'asm x86... mai frequentato) 
Io ti dico che non ci riesci. Ribadisco, a meno di ridurti a pura
algoritmica. Purtroppo per fare un programma completo non puoi
prescindere da qualche forma di interazioene con l'os.
Comunque per asmx86 sono contento. Č quello che conosco meglio, ormai.
Il 68k sono secoli che non lo guardo, e all'epoca ero proprio piccolino!


 Per esempio questo funziona:
aggiungo solo l'ultima considerazione
mi pare cosi' strano che usare/non usare l'assembly cambi
*sostanzialmente* (1) le cose
cazzo quelli erano gli anni 80!
oggi (si suppone) abbiamo compliatori sofisticati, che ottimizzano,...
(btw hai pensato a cercarti un compilatore intel? magari ottimizza
meglio del gcc) 
non sara' percaso che il tuo programmello al livello basso fa un uso
pesantte dell'altivec?
se cosi' fosse, e' mia impressione che le unita' vettoriali intel siano
ancora dietro
vabbeh, buon lavoro
(1) un g4 non *dovrebbe* prenderle da un core duo (2,3)
(2) ma tutta quella libreria cosi intensa usa un solo core? tze'! :-P
(3) giobbs dicsit

 (2) ma tutta quella libreria cosi intensa usa un solo core? tze'! :-P
La libreria non č multithread in se (ovviamente). Peraltro se uno lancia
un lavoro pesante, vanno entrambi i core, ma immagino sia l'os a
palleggiarsela.


 palleggiarsela.
mhhh l'os che spezzetta un unico tred fra due core? fantascienza?

 mhhh l'os che spezzetta un unico tred fra due core? fantascienza?
O semplicemente menu meter che da infos a braccio.
Uno dei due č piů alto (tipo adesso uno č a 78% e l'altro a a 58%), poi
qando finisce tornano a 5, 6 % tutti e due.
Semplicemente IMHO lo scheduler lo spara un po' su un coore un po'
sull'altro. Ammesso che non precisa conoscenza di come sia dentro il
processore, immagino che sta cosa potrebbe non essere un enorme
problema. Ma dovrei documentarmi prima di fare l'affermazione.


 compilazione)
Dunque, come ho teste` postato come commento sul tuo blog (commento alla
tua entry del 26 marzo "gmp 4.2 on MacIntel"), almeno con 4.2 il
problema e` tutt'altro: e` che l'ld dell'Apple fa cose un po' strane,
ma, dovendo, lo si frega facilmente.  Piccola.patch:
--- gmp-4.2.orig/tests/x86call.asm      2006-03-14 10:57:54.000000000
-0500
+++ gmp-4.2/tests/x86call.asm   2006-04-06 00:10:03.000000000 -0400
@@ -110,8 +110,20 @@
        movl    G(calling_conventions_save_esi), %esi
        movl    G(calling_conventions_save_edi), %edi
        movl    G(calling_conventions_save_ebp), %ebp
 
        jmp     *G(calling_conventions_retaddr)
 
 EPILOGUE()
 
+
+C void gmp_x86check_workaround_apple_ld_bug()
+C
+C Apple ld has an annoying bug that causes it to only load members from
+C static archives that satisfy text symbol dependencies.  This
procedure
+C creates a bogus dependency on a text symbol in x86check.o (in
libtests.a)
+C to ensure that ld loads it, also making all of the needed non-text
+C symbols available.
+
+PROLOGUE(gmp_x86check_workaround_apple_ld_bug)
+       jmp     *G(calling_conventions_check)
+EPILOGUE()
patch -p0 di questo filettino, make clean, make, make check, tutto
peffetto.  Non ho il tempo di sottoporre la patch a GMP (sto partendo
per 10 gg al Gran Canyon, yay!-) -- se potessi farlo tu, o chiunque
altro, ne sarei grato, cosi` la prossima patch di GMP 4.2 uscira`
"pronta per Macintel"!-)  Il buffo e` che bug e patch li ho trovati in
fretta solo grazie all'aiuto di un collega, ma appena visto ho
riconosciuto che questo NON e` il primo ld per un qualche Unix con
questo tipo di "misfeature", solo che non mi ricordo quando fu che ci
sbattei il muso (forse un SunOS prima che si chiamasse Solaris).
Alex

 ma, dovendo, lo si frega facilmente. 
Visto e ho postato nella buglist di gmp. Qui mi ero scordato :)
Grazie!


 "pronta per Macintel"!-)  Il buffo e` che bug e patch li ho trovati in
Grazie, ho visto che hai postato (speriamo l'accettino), io intanto sono
riuscito in fretta e furia a rimediare alla scadenza dell'account
individual.net
 (il vecchio aveva: residenza in Italia, carta di credito
italiana ormai scaduta, mail di yahoo che uso per postare ma non
funziona praticamente piu` [uso invece gmail], ... praticamente tutto
cambiato!-).  Cortesissimi e prontissimi come sempre i tedeschi!
Alex

 cambiato!-).  Cortesissimi e prontissimi come sempre i tedeschi!
Bene, ottimo.
Io sto lavorando attorno al baco sul c++.
Sai dove posso trovare informazioni sul "PIC"?
