eric.bachard a écrit :
Pour information, en fin de semaine, je tente de corriger les pb de
compilation de la 2.2 avec Panther.
Je n'ai simplement pas eu le temps de m'y mettre avant.
*Attention* : c'est sans garantie, je ne suis pas certain d'y arriver,
et le pb est peut-être très compliqué à résoudre.
Il me semble que Panther a un problème avec sa version de gcc: celle-ci
est (s'il m'en souvient bien) une version de gcc4 très peu mûre qui sort
des erreurs et du code à la validité douteuse. Le port Panther pourrait
avoir plus de succès avec un gcc plus à jour (mais des librairies
autrement de base) - ce qui n'enlève rien à la possibilité de problème
difficilement solutionnable.
Mais ce sera un peu plus tard : Sébastien Plisson et moi travaillons
sur le rafraichissement en priorité, et au passage nous ajoutons le
look pour voir ;)
c'est sûr que c'est toujours plus motivant de voir une appli pas moche
se compléter peu à peu, qu'un truc atroce être fonctionnel dont il faut
coriger les erreurs graphiques - au moins en faisant l'affichage dabord,
lorsque la fonctionnalité est enfin disponible elle est belle tout de
suite...
+ j'ai oublié le regretté Terry Teague, disparu soudainement, et qui
était le seul avec qui je pouvais discuter en fait.
RIP
Oui, c'est tout à fait vrai ( j'ai affaire à quelqu'un qui connait
l'histoire du port Mac on dirait ;-) )
juste un fouille-m***e qui aime savoir - ces histoires c'est comme les
'soap' à la TV sans le côté irréaliste :D
il y a eu un comportement pas très sympa de la part des gens de Sun
vis à vis du port Mac (il faut le dire) et cela n'a absolument pas aidé.
[...]
P. Luby a travaillé chez Sun, et il semble que la séparation ne se
soit pas bien passée.
ce qui rejoint les bisbilles Sn/Port Mac ci-dessus, j'imagine
Héhé - je me rappelle des premières versions développeur (vers m56).
Quel souk à l'époque...
:)
Précision: tu parles du port Mac/Intel, là, je pense?
Tout à fait : 4 développeurs, 2 machines spéciales pour le
développement, 3 à 4 mois de boulot en tout.
Par rapport à la version PPC sachant que OOo tournait déjà sous x86
avec d'autres OSes, quelles difficultés y avait-il eu? Simple curiosité.
La difficulté essentielle, c'est le bridge : le coeur "binaire"
d'OpenOffice.org.
Dans le bridge, il y a une fonction mandataire (comprendre un proxy)
qui fait l'intermédiaire entre les différentes APIs ( Java, UNO, C++
). Ce mandataire permet à ces APIs d'echanger de façon transparente
les données, des résultats de fonctions ..et de se passer des
paramètres (qui ne sont pas rangées, ni traitées de la même manière
selon l'API) de façon *transparente*.
Pour que cela aille plus vite, le bridge est écrit en essembleur, qui
respecte l'ABI Apple ( en gros les règles à suivre à très bas niveau
pour la compilation avec gcc pour un microprocesseur donné).
compatibilité ABI qui explique pourquoi il n'était pas possible de
simplement copier-coller l'assembleur win32 ou Linux/x86 - OK, pigé.
Sans bridge, pas d'OpenOffice.org
plus qu'à sauter du pont, quoi.
Voir : http://wiki.services.openoffice.org/wiki/User:Ericb#Changelog
Note: en fait, j'ai mis des numéros au pif, et les délais ne sont pas
connus, parce qu'il peut y avoir des issues corrigées en 3 min, comme
en 3 mois. Mais quand les 10 le sont, c'est promis, on fait une
version publique alpha à tester, pour montrer qu'il y a bien un port
natif qui marche (il manquera certaines parties, qui viendront après)
tant que ça marche... A quand la version Aqua/64-bit? (oui je sais, -->[] )
Et d'autres choses comme le QA, qui fait un travail formidable (merci
au passage à tous ceux qui font les tests !! )
c'est vrai qu'on voit beaucoup plus le QA évoqué dans la résolution des
bugs, et une plus grande réactivité au niveau de l'intégration des CWS -
ce n'est désormais plus une question de savoir si un CWS sera intégré,
mais plutôt de quand...
Cordialement,
Eric Bachard
Mitch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
