# Codewarrior 10 - La version ultime.



## Didier Guillion (4 Novembre 2005)

Bonsoir,

Codewarrior (CW) est abandonné sur Macintosh et la version 10 qui vient de sortir ($120) sera la dernière.
Je l'ai testée cet apres midi.
Apres quelques problèmes de validation de mon numéro de licence (résolu rapidement par le SAV) j'ai essayé de compiler un gros projet (C+Assembleur) créé avec la version 8 de CW, d'environ 1 million de ligne de code.

Tout s'est bien passé, les erreurs étaient toutes dans mes sources. 

Comparé à XCode (le meme projet existe sous XCode) c'est 2 à 3 fois plus rapide au niveau compilation/édition. Au niveau execution de l'application générée, c'est sensiblement plus réactif. 
Au niveau ergonomique, c'est incomparable.

Donc, conclusion :

-Si vous utilisez une version antérieure de CW n'hésitez pas a franchir le pas
-C'est vraiment dommage que ce produit abandonne Mac OS X, car le comparer à XCode c'est comparer une Traction avant à une Ferrari.

Cordialement


----------



## molgow (4 Novembre 2005)

Bien d'accord avec toi !
Il faut absolument qu'une bo&#238;te sorte qqch en remplacement de Codewarrior ou qu'Apple am&#233;liore tr&#232;s sensiblement son Xcode. Je vois mal comment les grosses bo&#238;tes de d&#233;veloppement pourraient avoir envie d'utiliser le produit Apple !
On peut se demander si Apple n'a pas tu&#233; Codewarrior en proposant un outil gratuit m&#234;me mauvais ?


----------



## Didier Guillion (4 Novembre 2005)

molgow a dit:
			
		

> On peut se demander si Apple n'a pas tué Codewarrior en proposant un outil gratuit même mauvais ?



Je veut dire, bon, d'accord avec toi. XCode ne tient pas la charge en développement professionnel.

En tant qu'outil pour s'amuser à developper de petits gri-gris, je le recommande chaudement, mais au delà...

Alors, soit il y a vraiment peu de développeurs sur Mac, et ils font avec, ce que j'ai du mal a comprendre, soit les boites comme MicroSoft ou Adobe utilisent autre chose, mais alors quoi ?

J'ai eut le malheur de commencer un projet sous XCode il y a deux ans, histoire de tester en vrai grandeur. Je le regrette amèrement. Maintenant le projet est volumineux, le debuggeur est "out" depuis longtemps, l'éditeur à la masse, tout se traine comme pas possible. Rien que de penser a apporter une modif, ca me fait des aigreurs a l'estomac... Et pourtant j'ai un Bi G4x1.2 Ghz, sur lequel CodeWarrior tourne parfaitement.


Cordialement


----------



## ntx (5 Novembre 2005)

Bonjour,
peut être qu'Apple imite la stratégie M$ : un produit devient utilisable à partie de la version 3 (voir Windows  ).
Je ne connais pas Code Warrior, mais j'ai eu l'occasion de travailler avec IntelliJ en Java, et c'est vrai qu'il n'y a pas photo : c'est un vrai plaisir de faire alors du Java et pourtant je ne suis pas un fan de ce langage. Si on pouvait avoir la même chose pour le C++ et l'Objective-C, ça serait le pied.


----------



## ericb2 (6 Novembre 2005)

ericb-> Didier Guillon

C'est intéressant, ce que tu dis, et je suis intéressé par ce logiciel. Pour l'instant, je fais tout en ligne de commande dans un gnome-terminal + mc + vi ou de temps en temps XCode.

Est-ce que tu penses qu'OpenOffice.org peut être managé par ce soft ?
 (~ 8 millions de lignes de code).

Pour me faire l'avocat du diable, je viens de tester la génération de documentation avec XCode et Doxygen pour une partie importante d'Ooo, et les deux s'en sont pas mal sortis.


D'avance merci


----------



## Didier Guillion (6 Novembre 2005)

ericb2 a dit:
			
		

> ericb-> Didier Guillon
> 
> C'est intéressant, ce que tu dis, et je suis intéressé par ce logiciel. Pour l'instant, je fais tout en ligne de commande dans un gnome-terminal + mc + vi ou de temps en temps XCode.
> 
> ...




Cela fait maintenant une bonne dizaine d'année que je travaille sur CW et je ne l'ai jamais "surchargé", (auparavant j'était sur MacApp et Think C) 
Mais mon plus grand projet ne depasse pas 1.5 millions de lignes.

Je dirait à priori, cela devrait fonctionner. Reste a savoir le langage utilisé et le niveau de compatibilité de ton code.

Par contre, difficile pour toi de l'essayer car les versions d'évaluation ne permettent pas de compiler des projtes de plus de 32 fichiers.

 Cordialement


----------



## deftones (7 Novembre 2005)

J'ai une petite question... CW est il très axé C++ ou bien est il possible du faire du dev Cocoa/Objective C avec ?  Car je suis prêt à quitter xCode mais pour je souhaite développer avec Cocoa et Objective C que je préfère au C++.


----------



## Didier Guillion (7 Novembre 2005)

deftones a dit:
			
		

> J'ai une petite question... CW est il très axé C++ ou bien est il possible du faire du dev Cocoa/Objective C avec ?  Car je suis prêt à quitter xCode mais pour je souhaite développer avec Cocoa et Objective C que je préfère au C++.



CW est censé compiler de l'objective C, ce qu'il fait d'ailleurs sur les exemples fournis. Je ne peut m'avancer sur le degre de compatibilité, je ne l'ai jamais testé en profondeur.

Cordialement


----------



## deftones (7 Novembre 2005)

Didier Guillion a dit:
			
		

> CW est censé compiler de l'objective C, ce qu'il fait d'ailleurs sur les exemples fournis. Je ne peut m'avancer sur le degre de compatibilité, je ne l'ai jamais testé en profondeur.
> 
> Cordialement



Mais qu'en est il du framework Cocoa ?


----------



## Didier Guillion (7 Novembre 2005)

deftones a dit:
			
		

> Mais qu'en est il du framework Cocoa ?




Apparemment pas de probleme, simplement les Nibs s'éditent avec InterfaceBuilder.

Cordialement


----------



## deftones (8 Novembre 2005)

Je sais que je vais paraître un peu lourd   Si je comprends bien, vu qu'on passe par IB, tout ce qui touche aux bindings fonctionnent sans soucis, non ?


----------



## Didier Guillion (8 Novembre 2005)

A priori, oui, mais le mieux est de tester par toi meme : CW est téléchargeable sur le site de Metrowerk.

Cordialement


----------



## ericb2 (9 Novembre 2005)

ericb2 -> Didier Guillion

Merci pour toutes les informations au sujet de CW. Je vais faire un tour sur le site de Metrowerk...


----------



## ericb2 (9 Novembre 2005)

C'est encore moi. En allant sur le site de Metrowerks.com, j'ai bien trouvé la version 10 " Studio " pour MAc OS X, mais à 99$.
Il semble qu'il ne soit pas possible d'être livré en France (ou j'ai mal cherché) ?

Auriez-vous un lien, une adresse pour :

- télécharger une version de démo pour Mac OS X (sinon Linux PPC me va)
- acheter une version ?

D'avance merci


----------



## Didier Guillion (9 Novembre 2005)

ericb2 a dit:
			
		

> C'est encore moi. En allant sur le site de Metrowerks.com, j'ai bien trouvé la version 10 " Studio " pour MAc OS X, mais à 99$.
> Il semble qu'il ne soit pas possible d'être livré en France (ou j'ai mal cherché) ?
> 
> Auriez-vous un lien, une adresse pour :
> ...



La derniere version est uniquement disponible en téléchargement (pas de CD)

Va ici :
http://www.metrowerks.com/mw/download/

Et selectionne 
"Codewarrior development studio for mac Os v10 learning edition"
Dans la premiere liste.

Ou le lien direct :

ftp://ftp.metrowerks.com/pub/tools/CW_Tools_10_0.dmg


Cordialement


----------



## Nicky Larson (12 Novembre 2005)

Xcode vaincra


----------



## Didier Guillion (13 Novembre 2005)

Nicky Larson a dit:
			
		

> Xcode vaincra



Oui, sur Mac, et c'est bien dommage. C'est facile d'etre le meilleur quand on est le seul.

Cordialement


----------



## Nicky Larson (13 Novembre 2005)

Didier Guillion a dit:
			
		

> Oui, sur Mac, et c'est bien dommage. C'est facile d'etre le meilleur quand on est le seul.
> 
> Cordialement


C'est surtout facile de critiquer Xcode qui n'existe que depuis 2003 avec un produit qui doit exister depuis au moins 10 ans ...


----------



## Didier Guillion (13 Novembre 2005)

Nicky Larson a dit:
			
		

> C'est surtout facile de critiquer Xcode qui n'existe que depuis 2003 avec un produit qui doit exister depuis au moins 10 ans ...




Je suis d'accord, il est vraiment trop facile de critiquer XCode, tant il recelle de problemes majeurs qui le rendent quasiment inutilisable.

Cordialement


----------



## Nicky Larson (13 Novembre 2005)

Didier Guillion a dit:
			
		

> Je suis d'accord, il est vraiment trop facile de critiquer XCode, tant il recelle de problemes majeurs qui le rendent quasiment inutilisable.
> 
> Cordialement


C'est bien, t'as raison, t'es l'meilleur.

Je crois qu'on va arrêter là, vu ton niveau "d'ouverture d'esprit".


----------



## Didier Guillion (14 Novembre 2005)

Nicky Larson a dit:
			
		

> C'est bien, t'as raison, t'es l'meilleur.
> 
> Je crois qu'on va arrêter là, vu ton niveau "d'ouverture d'esprit".



Par la malepeste, tu as vraiment des arguments qui tuent toi!

Quelle discussion effrennée ! quels échanges d'information et d'expérience! quel enrichissement personnel !

Ce fut passionant !


Cordialement


----------



## Nicky Larson (14 Novembre 2005)

Je te retourne le compliment.
Une recherche sur les forums a suffit pour connaître ton état d'esprit, pas besoin d'en ajouter plus.


----------



## Didier Guillion (14 Novembre 2005)

Nicky Larson a dit:
			
		

> Je te retourne le compliment.
> Une recherche sur les forums a suffit pour connaître ton état d'esprit, pas besoin d'en ajouter plus.




Ben si, vaszy rajoute en, qu'on te cerne un peu mieux.... 

Cordialement


----------



## FredoMkb (14 Novembre 2005)

Bon bon...

Dites les gars, au lieu de vous chamailler de la sorte, pourquoi ne pas nous confier vos opinions à propos des deux logiciels en question ? 

Franchement, ce serait bien plus instructif pour des personnes comme moi qui souhaitent connaître les principales différences entre ces deux pointures du développement, et ainsi être en mesure, éventuellement, de faire un choix plus pertinent...

Je possède une vielle version de CW, que je n'ai jamais utilisé à vrais dire, et j'aimerais savoir si ça vaut la coup que j'y investisse du temps pour apprendre à l'utiliser, sachant que pour l'instant le possibilités de XCode me conviennent pour ce que je fait... 

Alors, avez-vous des arguments pour mettre en valeur les qualités d'un ou l'autre soft ?

Merci à vous


----------



## Didier Guillion (14 Novembre 2005)

Bonjour,

J'ai developpé ce qui pour moi sont les principaux avantages de CW dans le premier message de ce fil.

Cordialement


----------



## FredoMkb (14 Novembre 2005)

Oui Didier, j'ai lu avec attention tes différentes contributions, mais, ce que j'aimerais savoir, ce sont, principalement, les différences en terme d'ergonomie de ces deux logiciels...

En effet, mes connaissances techniques sont très (trop) restreintes pour apprécier les avantages de l'un ou l'autre logiciel en terme du moteur de compilation, de vitesse d'exécution, d'efficacité du code ou de débugage (ça s'écrit comme-ça ?), etc.

En revanche, côté manipulation et ergonomie, j'aimerais savoir en quoi vous trouvez une solution meilleure que l'autre, sachant que mes projets sont en général de taille et compléxité très modèstes...

Merci


----------



## Didier Guillion (14 Novembre 2005)

FredoMkb a dit:
			
		

> Oui Didier, j'ai lu avec attention tes différentes contributions, mais, ce que j'aimerais savoir, ce sont, principalement, les différences en terme d'ergonomie de ces deux logiciels...
> 
> En effet, mes connaissances techniques sont très (trop) restreintes pour apprécier les avantages de l'un ou l'autre logiciel en terme du moteur de compilation, de vitesse d'exécution, d'efficacité du code ou de débugage (ça s'écrit comme-ça ?), etc.
> 
> ...



Difficile de juger pour toi, car l'ergonomie est une affaire de gout. D'une maniere general je trouve l'interface de CW plus depouillée, sur XCode on se retrouve facilement avec des fenetres dans tous les sens.

L'editeur de CW est plus rapide, il ouvre des fichiers textes de plusieurs Mo en quelque secondes, celui de XCode commence a "ramer" a partir de quelques centaines de Ko. On retrouve plus facilement les options de compilation dans CW, celles de XCode sont extremement touffues et souvent cabalistiques.

La coloration syntaxique est pour moi, meilleure sur CW, sur XCode par exemple, elle a tendance a confuser lors des copier coller.

En fait, la principale difference est qu'XCode n'est qu'une interface sur un compilateur domaine public (GCC) alors que CW propose son propre compilateur (a la base CW s'était Motorola, donc ils maitrisent bien le PPC).

Les libellés des erreurs sont plus clairs sur CW et cherchent a t'indiquer l'erreur ET la correction a faire.

La recherche de mots dans un projet est beaucoup plus rapides sur CW.

CW te permet de generer des executables pour Mac OS 9 non Carbon, ce que ne peut pas faire XCode (sauf erreur de ma part).

XCode gere mieux les "bundles" et tout ce qui est très specifique à Mac OS X et il est gratuit. 

Cordialement


----------



## FredoMkb (14 Novembre 2005)

Ok, merci beaucoup Didier pour toutes ces infos, j'attends maintenant l'avis de notre ami Nicky Larson, afin d'avoir un autre son de cloche et pouvoir ainsi me faire une meilleure idée des avantages ergonomiques de chaque logiciel...

Merci


----------



## SuperCed (14 Novembre 2005)

Nicky Larson a dit:
			
		

> C'est surtout facile de critiquer Xcode qui n'existe que depuis 2003 avec un produit qui doit exister depuis au moins 10 ans ...


Tu as tout a fait raison, le fait qu'XCode n'existe que depuis 2003 est une des raisons pour lesquelles il est moins bon.
CodeWarrior est plus mature.

J'ai un peu testé les 2. Je me souviens qu'en effet, la compilation sous CodeWarrior était beaucoup plus rapide.

Par contre, c'était assez complexe à configurer pour faire du Cocoa.

En exécution, les programmes compilés sous l'un ou l'autre se valaient.


----------



## FredoMkb (14 Novembre 2005)

Nicky Larson a dit:
			
		

> C'est surtout facile de critiquer Xcode qui n'existe que depuis 2003 avec un produit qui doit exister depuis au moins 10 ans ...





			
				SuperCed a dit:
			
		

> Tu as tout a fait raison, le fait qu'XCode n'existe que depuis 2003 est une des raisons pour lesquelles il est moins bon.
> CodeWarrior est plus mature.



Et bien, oui et non !  

En réalité, "XCode" est une évolution de l'application "Project Builder" qui, elle, est apparue en 1992, dans les laboratoires de "NeXT", pour la version 3.0 de "NeXTStep", et, "Interface Builder", est apparue en un an plus tôt, toujours chez "NeXT", mais c'est une évolution d'une autre application crée par un français, Jean-Marie Hullot, qui se nommait, au départ, "SOS Interface"...

- Copie d'écran "Project Builder"
- Copie d'écran "Interface Builder"

Toutes ces infos sont tirées de cet excellent site : Historique NeXT

Donc, je ne sais pas, entre "XCode" à "CodeWarrior", quelle application est la plus ancienne, donc la plus mature (quoique, c'est quand-même une notion assez relative), mais, en tout cas, "XCode" n'est pas si jeune qu'on pourraît le croire...

Enfin, en attendant la contribution de Nicky Larson, si d'autres ont un avis à partager par rapport aux deux logiciels en question, je suis évidemment curieux de le connaître... 

Merci


----------



## cretinoïde (18 Novembre 2005)

Didier Guillion a dit:
			
		

> Je suis d'accord, il est vraiment trop facile de critiquer XCode, tant il recelle de problemes majeurs qui le rendent quasiment inutilisable.
> 
> Cordialement



Didier tu as malheureusement toujours été d'une rare prétention...Ce n'est pas nouveau.

Il existe aujourd'hui des dizaines de GROS projets Cocoa, déployés en environnement professionnel, contenant des dizaines, des centaines de milliers de lignes de code qui sont gérés sous XCode. Je peux t'en citer des brouettes pleines.

Ce n'est pas parce que tu es habitué à un produit aussi noble et vieux soit il que tu dois vomir sur XCode à la premiere occasion. 

XCode n'est pas uniquement destiné à faire des "grisgris" comme tu l'affirmes avec une telle certitude. Cette remarque est dénuée de fondement, ridicule et foncierement idéologique. 

Que tu sois frustré par le fait que Cocoa, Bindings et CoreData impliquent des changements profonds de philosophie de développement, que tu ne saches pas t'adapter, que tu ne saches pas non plus t'éclater avec ces techno ne te permet pas de livrer ici des contre-vérités.

XCode permet beaucoup plus de choses en architecture logicielle que CodeWarrior. Indéniablement. Quand à la vitesse de compilation, cela n'a rien à voir avec XCode comme lu ci-dessus (ceux qui affirment n'ont pas compris ce qu'était un compilateur).

Bref, à mon sens, si on veut utiliser pleinement Cocoa, les bindings, CoreData qui sont des technologies tout à fait exceptionnelles, je vois pas comment on peut se passer d'XCode (et que ce soit pour des "gris gris" de 2000 lignes ou des projets de 300 000 sous subversion).

Quand tu auras pondu un projet Obj-C de plus de 100 000 lignes de code qui ressemble à quelque chose, on reparlera sereinement des plus d'XCode et de ses défauts.


----------



## Didier Guillion (18 Novembre 2005)

cretinoïde a dit:
			
		

> Didier tu as malheureusement toujours été d'une rare prétention...Ce n'est pas nouveau.
> 
> Il existe aujourd'hui des dizaines de GROS projets Cocoa, déployés en environnement professionnel, contenant des dizaines, des centaines de milliers de lignes de code qui sont gérés sous XCode. Je peux t'en citer des brouettes pleines.
> 
> ...



Ciel ! Encore un donneur de lecon qui parle dans le vide...  (Tiens au passage, pas de nouvelles de Nicky Larson, volatilisé, quand on lui a demandé de prouver ses dires)

Pour éviter de perdre du temps en blabla inutiles avec des "Qui-font-pas-eux-meme-mais-qui-ont-entendu-dire-que ..." j'attends avec impatience les liens que tu as oublié de donner sur tes projets CW et XCode...

Cordialement


----------



## molgow (18 Novembre 2005)

Les prochaines attaques personnelles à l'encontre de qui que ce soit ou messages hors-sujets seront effacés !


----------



## cretinoïde (18 Novembre 2005)

Didier Guillion a dit:
			
		

> Ciel ! Encore un donneur de lecon qui parle dans le vide...  (Tiens au passage, pas de nouvelles de Nicky Larson, volatilisé, quand on lui a demandé de prouver ses dires)
> 
> Pour éviter de perdre du temps en blabla inutiles avec des "Qui-font-pas-eux-meme-mais-qui-ont-entendu-dire-que ..." j'attends avec impatience les liens que tu as oublié de donner sur tes projets CW et XCode...
> 
> Cordialement



Mais c'est à toi de prouver ce que tu avances. 

C'est  à toi de prouver qu'aucune grosse appli en deployement professionnel n'est développée sous XCode. C'est à toi d'expliquer comment les techno d'avenir qu'Apple proposent peuvent etre pleinement exploitées sous autre chose que XCode. C'est à toi d'expliquer les avantages récents qu'offre CW en architecture logicielle cocoa. C'est à toi de nous montrer en quoi XCode ne peut faire que des "grisgris".

TU as lancé le fil avec aucun argument, ce n'est pas à moi de contre-argumenter sur du creux. (mais je te rassure tu es déjà bien épaulé dans ta démarche vaine )

Sans rancune,


----------



## Didier Guillion (18 Novembre 2005)

Ben tiens, facile...  

C'est comme si j'essayait une voiture sur un petit trajet, que je trouve qu'elle ne tient pas la route et que tu me dise, "fait 300 000 km, apres tu pourra critiquer". 
C'est a *toi* de les faire ses 300 000 km et de prendre les risques, pas a moi. 

Cordialement

PS: J'attends toujours le lien sur tes projets XCode afin que nous puission évaluer à quel titre du parle...


----------



## cretinoïde (18 Novembre 2005)

Didier Guillion a dit:
			
		

> Ben tiens, facile...
> 
> C'est comme si j'essayait une voiture sur un petit trajet, que je trouve qu'elle ne tient pas la route et que tu me dise, "fait 300 000 km, apres tu pourra critiquer".
> C'est a *toi* de les faire ses 300 000 km et de prendre les risques, pas a moi.
> ...



mais j'ai rien à prouver. Tu vociferes sur XCode sans filer un seul argument si ce n'est ta subjectivité de "vieux routard". Quoi qu'il en soit, tu nous expliqueras comment tu geres un projet moderne (cocoa, bindings, coredata, coreimage, etc) sans XCode. Tu nous expliqueras aussi pourquoi des dizaines de projets enormes utilisent XCode aujourd'hui.

Si tu tiens absolument à avoir une référence, pense à une appli "non-francaise" cocoa de plus de 275 000 lignes d'obj-c utilisant à foison, bundles, plugins et frameworks proprio ainsi que des technos Tiger. Yen a pas des masses mais je n'en dirai pas plus pour des raisons évidentes.


----------



## Didier Guillion (18 Novembre 2005)

Donc pour résumer, tu ne peut nous apporter aucune experience personnelle. Tu parles par "on-dit-que".

Cordialement


----------



## Didier Guillion (18 Novembre 2005)

Ok, un petit match pour faire avancer le schmilblick.

Le meme projet en C pur, compilé sur XCode et CW, code non optimisé pour deboggage (option [-Oo] sur XCode, Global optilisation "off" sur CW).
L'application est a l'avant plan et rien ne tourne a l'arriere plan.
Pour les deux compilateurs, headers precompilés, meme machine (G4 bi 2x1.2)
XCode v2.2 avec GCC4. 
CW 10.

Le projet fait 551 fichiers, pour 1 200 000 lignes de codes.

Temps de compilation XCode : 307 secondes.
Temps de compilation CW : 124 secondes.

Cordialement


----------



## cretinoïde (18 Novembre 2005)

Didier Guillion a dit:
			
		

> Ok, un petit match pour faire avancer le schmilblick.
> 
> Le meme projet en C pur, compilé sur XCode et CW, code non optimisé pour deboggage (option [-Oo] sur XCode, Global optilisation "off" sur CW).
> L'application est a l'avant plan et rien ne tourne a l'arriere plan.
> ...



et alors ? c'est un concours de b#*te ?

en outre, je ne vois pas dans un environnement pro comme tu dis qui utiliserait un G4 et qui par exemple compilerait (pour le plaisir peut etre) 1 200 000 lignes de code c pur.

il faudra m'expliquer ou tu veux en venir ?

mais encore une fois GCC n'est pas XCode et GBD n'est pas CW.

J'attends encore que tu parles "pragmatisme" c'est à dire en quoi XCode ne permet que de faire des "grisgris" et que CW permet d'avoir une plus grosse b*?%te.


----------



## Didier Guillion (18 Novembre 2005)

cretinoïde a dit:
			
		

> et alors ? c'est un concours de b#*te ?
> 
> en outre, je ne vois pas dans un environnement pro comme tu dis qui utiliserait un G4 et qui par exemple compilerait (pour le plaisir peut etre) 1 200 000 lignes de code c pur.
> 
> ...



Et oh, on se calme... On reste poli et on souris.

Je suis pro, c'est mon metier, développeur sur Mac, et j'utilise un G4 ne t'en déplaise.


Cordialement


----------



## cretinoïde (18 Novembre 2005)

Didier Guillion a dit:
			
		

> Et oh, on se calme... On reste poli et on souris.
> 
> Je suis pro, c'est mon metier, développeur sur Mac, et j'utilise un G4 ne t'en déplaise.
> 
> ...



la compilation distribuée sur plusieurs XServe et stations G5...Ca c'est pro


----------



## Didier Guillion (18 Novembre 2005)

cretinoïde a dit:
			
		

> la compilation distribuée sur plusieurs XServe et stations G5...Ca c'est pro



Je crois que tu t'es un peu trompé de planete...

Cordialement


----------



## SuperCed (18 Novembre 2005)

Je suis de l'avis de Didier sur le temps de compilation.

Codewarrior possède un compilateur intégré très rapide. Je ne pense pas que le compilateur de codewarrior puisse s'utiliser avec XCode.

J'ai eu à développer un gros projet en Cocoa, avec de la vidéo, du réseau, et pas mal d'interface graphique, et les temps de compilation étaient parfois assez long.
Sous CodeWarrior, on allait à l'époque 5 fois plus vite qu'avec gcc et XCode!!!

Maintenant, il parait que le retard est un peu ratrapé grâce aux "precompiled headers" (C'est ça Didier?), mais il est quand même toujours en retrait au niveau du temps de compil.

Bon, là, c'était pour comparer gcc et le compilo de Codewarrior. Remarque que si tu uilises XLC, je ne pense pas que tu gagnes non plus en temps de compilation, sans compter, il me semble, qu'il ne compile pas de code ObjectiveC.

Pour info, Cocoa marche très bien avec Codewarrior. je ne vois pas pourquoi Core Data et Core Image ne fonctionnerait pas avec CodeWarrior également. Pour les bindings, je ne sais pas s'il fonctionnent avec CodeWarrior, mais Didier pourra certainement répondre sur ce point.

Pour ma part, j'avoue préférer XCode, mais c'est surtout parce que j'avais trouvé CodeWarrior assez compliqué. Par contre, le temps de compilation est très important et il est indéniable que CodeWarrior va plus vite.

J'attends également les liens vers de grosses appli développées avec XCode. Ce n'est pas que je doute qu'il y en ait, mais il faut bien prouver ses arguments.


----------



## cretinoïde (18 Novembre 2005)

SuperCed a dit:
			
		

> Je suis de l'avis de Didier sur le temps de compilation.
> 
> Codewarrior possède un compilateur intégré très rapide. Je ne pense pas que le compilateur de codewarrior puisse s'utiliser avec XCode.
> 
> ...



Encore une fois, on répond à coté ... Relis donc ce que didier affirme ... XCode ne sait gérer que des "grigris" ... tu vas page 1 et tu t'appliques.

XCode a des défauts dont la necessaire config musclée qui est demandée. 

Maintenant si tu veux développer un projet pure Cocoa d'envergure, utilisant des technos d'avenir (surtout le couple coredata+bindings par exemple) et que tu utilises CW pour ca...je suis TRES interessé à voir le résultat  d'ailleurs j'attends encore des exemples d'envergure non-carbon de la part de didier...

Merci d'avance.


----------



## Didier Guillion (18 Novembre 2005)

Bonjour,

Oui, les headers précompilés ont bien aidé en terme de rapidité. Egalement XCode compile, si j'ai bien compris, en utilisant les deux processeurs (une tache GCC compile un fichier, ce qui compile deux fichiers simultanement)

Pour les bindings, je ne sais pas, je n'ai jamais pratiqué et j'evite de parler de ce que je connait pas... 

En fait, le compilateur de CW a été developpé par des types de Motorola et les optimisations sont plutot poussées que ce soit en terme de vitesse de compilation que de code obtenu.

Cordialement


----------



## Didier Guillion (18 Novembre 2005)

cretinoïde a dit:
			
		

> d'ailleurs j'attends encore des exemples d'envergure non-carbon de la part de didier...




Tu risque d'attendre longtemps, puisque c'est a toi de les fournir...

Cordialement


----------



## cretinoïde (18 Novembre 2005)

Didier Guillion a dit:
			
		

> Tu risque d'attendre longtemps, puisque c'est a toi de les fournir...
> 
> Cordialement



tu veux de gros projets développés sous XCode ? 

Toutes les applis Apple (et ca en fait des grosses, des moins grosses et des enormes sans compter les frameworks), les applis Omnigroup, les applis nisus, les applis Filemaker et j'en passe et des meilleurs.

Il faut savoir qu'une appli comme ComicLife dépasse allègrement les 150 000 lignes d'obj-c idem pour rapidweaver...ce ne sont pas de "petits" projets malgré leur status de shareware.


----------



## Didier Guillion (18 Novembre 2005)

Tu veut dire que tu as travaillé pour toutes ces boites ? 
Ou alors tu as seulement "entendu dire que..." ?
Et ils sont content de XCode ?
Ou alors ils l'utilisent car ils n'ont pas le choix ?

Concretement, la derniere appli que tu as ecrite, c'est quoi ?

Cordialement


----------



## SuperCed (18 Novembre 2005)

> je suis TRES interessé à voir le résultat  d'ailleurs j'attends encore des exemples d'envergure non-carbon de la part de didier...



J'en connais au moins un puisque j'avais participé au développement :
http://www.xstoner.com/

C'est un projet Cocoa, on le compilait aussi bien sous XCode que sous CodeWarrior, avec de très petites adaptations. Je ne me souviens plus si l'appli finale a été compilée avec gcc ou CodeWarrior, mais dans les 2 cas, ça fonctionnait très bien.

Et je répète que je ne vois pas ce qui empêcherait Codewarrior d'utiliser Core Image ou Core Data. Ce ne sont qude des frameworks, il n'y a pas de raison que ça ne fonctionne pas a priori.


----------



## cretinoïde (18 Novembre 2005)

Didier Guillion a dit:
			
		

> Tu veut dire que tu as travaillé pour toutes ces boites ?
> Ou alors tu as seulement "entendu dire que..." ?
> Et ils sont content de XCode ?
> Ou alors ils l'utilisent car ils n'ont pas le choix ?
> ...



Globalement, XCode est un produit tres abouti. C'est juste un veau te diront tous ces gens à la WWDC. D'ailleurs, il me semble pas t'avoir vu lors de la derniere session...


----------



## ntx (18 Novembre 2005)

Bonjour,


			
				Didier Guillion a dit:
			
		

> Egalement XCode compile, si j'ai bien compris, en utilisant les deux processeurs (une tache GCC compile un fichier, ce qui compile deux fichiers simultanement)


Tout à fait, et je pense que sur un Quad, il doit être capable de compiler 4 fichiers simultanément. Qui a essayé ?

Concernant, XCode moi j'aime bien ... surtout parce que c'est gratuit. Je ne l'ai pas utilisé sur de gros projets donc je ne ferai pas de commentaires. Mais j'ai travaillé avec des IDE bien plus abouties comme IntelliJ, malheureusement c'était pour du Java  Donc je dirais juste qu'il reste du boulot à Apple pour en faire la meilleure IDE du monde.

Je vous laisse continuer votre discussion


----------



## FredoMkb (18 Novembre 2005)

Et bein... pour une discussion relevée... on est servi 

Bon, personnellement, je ne suis qu'un très modèste débutant autodidacte, donc, pas très au fait de toutes le particularité techniques concernant le développement d'applications...

Je constate, toutefois, que les développeurs chévronés semblent plus préocupés par les aspects technologiques offerts par les environnements de développement, ce qui semble logique après tout, plutôt que par l'aspect purement ergonomique des applications en question...

Or, pour ma part, bien que je fasse mes petits "gris-gris" sans aucune prétention avec XCode, je reste persuadé que côté ergonomie on peut faire bien mieux, car, franchement, je ne trouve pas ce logiciel particulièrement productif...

Alors, je me demande, sérieusement, si les grosse boîtes qui travaillent avec XCode (il y en a certainement), n'ont pas, pour leur usage interne, des utilitaires ou plug-ins qui rendent le travail avec XCode en peu plus facile, réactif et productif... qu'en pensez-vous ?

a+


----------



## cretinoïde (18 Novembre 2005)

Didier Guillion a dit:
			
		

> Bonjour,
> 
> Oui, les headers précompilés ont bien aidé en terme de rapidité. Egalement XCode compile, si j'ai bien compris, en utilisant les deux processeurs (une tache GCC compile un fichier, ce qui compile deux fichiers simultanement)
> 
> ...



Personne n'a nié que le compilo de CW n'était pas optimisé ou tres optimisé (d'ailleurs aussi bien à la compile qu'à l'execution). GCC pour PPC est une catastrophe niveau optimisation, ce n'est pas nouveau. Avec la V4, on a du gagner 20 à 30 %  à l'exécution mais bien peu à la compile. Aujourd'hui dans ma boite aucune station G5 n'est équipée avec moins 3 Gb de Ram. C'est le confort minimum pour bosser confortablement avec XCode et bénéficier en retour de possibilités complement tournées vers l'avenir d'OS X.

D'ailleurs en parlant de GCC, avec le passage sur X86 on va sentir la différence (ou on le sent deja pour ceux qui ont la DTK).


----------



## ntx (18 Novembre 2005)

Est-ce que c'est gcc le problème ou le fait que XCode le relance pour chaque fichier qu'il doit compiler ? Car assurément si c'est cela, il faudrait qu'Apple trouve une autre méthode, comme réécrire un compilateur basé sur gcc mais qui ne se lance qu'une seule fois en prenant d'emblée tous les fichiers à compiler.


----------



## Didier Guillion (18 Novembre 2005)

ntx a dit:
			
		

> Est-ce que c'est gcc le problème ou le fait que XCode le relance pour chaque fichier qu'il doit compiler ? Car assurément si c'est cela, il faudrait qu'Apple trouve une autre méthode, comme réécrire un compilateur basé sur gcc mais qui ne se lance qu'une seule fois en prenant d'emblée tous les fichiers à compiler.




Sincèrement, je ne pense pas que le temps de chargement de GCC soit significatif dans la durée totale de traitement. C'est plutot, GCC lui meme qui n'est pas tres rapide.

Cordialement


----------



## Didier Guillion (24 Décembre 2005)

Bonsoir et Joyeux Noel,

Apparemment, si j'ai bien compris, Intel serait en train de porter ses outils de développement sur Mac OS X, ce qui serait un substitut au passage obligé sur XCode !

Excellente nouvelle !

"Intel Corp. will port its software developer tools to Mac OS X and will ship its first beta later this year, the chip maker told developers on Tuesday at its first-ever session on Mac OS X at the Intel Developer Forum in San Francisco."


http://www.eweek.com/article2/0,1895,1851752,00.asp

L'information date d'Aout, mais je ne l'ai sous les yeux que maintenant. Je ne sais pas comment cela a évolué.

A suivre...

Cordialement


----------



## Nicky Larson (27 Décembre 2005)

Pas mal pas mal.

Si j'ai bien compris, tu ne connais pas du tout les outils de développement d'Intel, mais ça sera forcément mieux que Xcode...

Enfin désolé de te casser tes rêves, mais apparemment les outils d'Intels ne seront pas un substitue à Xcode, mais des plug ins pour Xcode afin d'améliorer les performances du code généré.



> Kevin Smith, director of Intel Compiler Labs, said that Intel will port a complete set of compilers and performance-enhancing libraries to Apple Computer Inc.'s Intel-based version of Mac OS X. Intel will provide Mac tools for both single-core and multicore processors based on Intel's latest compiler technology. Smith said that the tools will contain the same feature set that Intel now provides for its Windows and Linux development tools.
> 
> "We will offer one set of tools for all OSes," said Smith.
> 
> ...



Il semble que tu seras obligé de passer à Xcode, ou d'arrêter de programmer sur mac.



			
				Didier Guillion a dit:
			
		

> Je crois que tu t'es un peu trompé de planete...
> 
> Cordialement



Pas vraiment, il parle de ça.


> "So far, the transition to Xcode has gone smoothly and Glenda says that they are particularly excited about one of Xcode's more advanced capabilities: distributed builds.
> 
> According to Adams, &#8220;In some early tests with Doom 3, *we've been able to shorten compile times for major recompiles significantly.*"


http://developer.apple.com/business/macmarket/aspyr.html

Mais bon, c'est vrai que toi t'es "un professionnel" comme tu le dis si souvent, chez Aspyr c'est que des amateurs...


----------



## Didier Guillion (28 Décembre 2005)

Nicky Larson a dit:
			
		

> Mais bon, c'est vrai que toi t'es "un professionnel" comme tu le dis si souvent, chez Aspyr c'est que des amateurs...



Tu me cherche mon gars ? Alors essaie d'être un minimum subtil, parce que la, j'ai deja vu.

Cordialement


----------



## HmJ (28 Décembre 2005)

Je ne comprends pas une chose. Il me semblait que Apple se mettait a fond sur GCC4, pour PowerPC mais aussi pour x86. Si Intel sort des plugins pour Xcode, ce sera necessairement au niveau compilateur, donc un concurrent de GCC4. Est-ce que Apple est capable de gerer deux compilateurs de front ? Est-ce que GCC4 n'etait qu'un coup de bluff ? Les compilateurs Intel sont remarquables (en tout cas sur Intel), il faut avoir programme sous Linux et GCC3 ou 4 pour comprendre l'avancee de Intel sur les autres.

Au passage, il y a cette histoire de Ars Technica (merci de ne pas trop leur taper dessus, je les tiens pour d'excellents analystes pro-Mac grace a leur sens des realites), en juillet je crois, qui disait qu'un developpeur interne de Apple etait degoute parce que l'OS est compile avec des optimisations au niveau de la taille des programmes, pas du tout au niveau de la rapidite / reactivite. On en est ou, ca reste d'actualite ?


----------



## Didier Guillion (28 Décembre 2005)

HmJ a dit:
			
		

> Je ne comprends pas une chose. Il me semblait que Apple se mettait a fond sur GCC4, pour PowerPC mais aussi pour x86. Si Intel sort des plugins pour Xcode, ce sera necessairement au niveau compilateur, donc un concurrent de GCC4. Est-ce que Apple est capable de gerer deux compilateurs de front ? Est-ce que GCC4 n'etait qu'un coup de bluff ? Les compilateurs Intel sont remarquables (en tout cas sur Intel), il faut avoir programme sous Linux et GCC3 ou 4 pour comprendre l'avancee de Intel sur les autres.


Apple gère deja plusieurs compilateur dans XCode, puisque l'on a le choix entre GCC3 et GCC4. Il n'y aurait donc a priori, aucun probleme pour ajouter le compilateur Intel dans la liste. (Considere qu'XCode est une interface graphique qui invoque des lignes de commande shell, un compilateur est juste un exécutable lancé avec une liste de commandes)

C'est en effet au niveau de la vitesse de compilation et de l'optimisation du code qu'Intel peut apporter un gros plus.



> Au passage, il y a cette histoire de Ars Technica (merci de ne pas trop leur taper dessus, je les tiens pour d'excellents analystes pro-Mac grace a leur sens des realites), en juillet je crois, qui disait qu'un developpeur interne de Apple etait degoute parce que l'OS est compile avec des optimisations au niveau de la taille des programmes, pas du tout au niveau de la rapidite / reactivite. On en est ou, ca reste d'actualite ?



Je ne sais pas, je n'ai pas d'informations la dessus.

Cordialement


----------



## olof (28 Décembre 2005)

Ou pourquoi pas, une version de GCC optimisée ?!?!?


----------



## cretinoïde (29 Décembre 2005)

Didier Guillion a dit:
			
		

> Tu me cherche mon gars ? Alors essaie d'être un minimum subtil, parce que la, j'ai deja vu.
> 
> Cordialement



J'ignore s'il te cherche mais encore une fois tu réponds à coté du fond.


----------



## Didier Guillion (30 Décembre 2005)

cretinoïde a dit:
			
		

> J'ignore s'il te cherche mais encore une fois tu réponds à coté du fond.



Désolé, les discussions de cours de maternelle de m'interesse plus, va jouer ailleurs.

Cordialement


----------



## Didier Guillion (30 Décembre 2005)

Bonjour,

Il est possible de s'inscrire sur le site Intel pour etre tenu au courant. Pour ceux que cela intéresse c'est ici :

http://www.intel.com/cd/software/products/asmo-na/eng/227389.htm

Apparemment il n'y a pas de compilateur Obj-C de prévu, mais le Fortran et le C++ sont au menu.

Cordialement


----------



## Nicky Larson (30 Décembre 2005)

Didier Guillion a dit:
			
		

> Désolé, les discussions de cours de maternelle de m'interesse plus, va jouer ailleurs.
> 
> Cordialement



Attaques personnelles: toujours présentes quand on est à court d'arguments et/ou que l'on refuse de se remettre en cause (ie on est convaincu d'avoir raison).


----------



## Didier Guillion (30 Décembre 2005)

Nicky Larson a dit:
			
		

> Attaques personnelles: toujours présentes quand on est à court d'arguments et/ou que l'on refuse de se remettre en cause (ie on est convaincu d'avoir raison).



je vois que tu es spécialiste de la question.

Cordialement

PS: Si vous alliez polluer un autre sujet ?


----------



## cretinoïde (30 Décembre 2005)

Didier Guillion a dit:
			
		

> je vois que tu es spécialiste de la question.
> 
> Cordialement
> 
> PS: Si vous alliez polluer un autre sujet ?



Méprisant et prétentieux petit personnage !

Bref, heureusement que tu maitrises AppleScript sinon il te resterait pas grand chose 

Sans rancune, vieux.


----------



## cretinoïde (31 Décembre 2005)

Didier Guillion a dit:
			
		

> Bonjour,
> 
> Il est possible de s'inscrire sur le site Intel pour etre tenu au courant. Pour ceux que cela intéresse c'est ici :
> 
> ...



Le fortran et le C++ pour les applications commerciales nouvelles generations (comprendre en cocoa) c'est l'avenir !

Merci Didier de diffuser la bonne parole aux jeunes developpeurs !!!!


----------



## ederntal (31 Décembre 2005)

relax tout le monde.

Je passe dans le coin de temps en temps juste pour ma culture, je connais rien en programmation.
et bas vous donnez vraiment pas envie de vous cotoyer.

Zen!


----------



## Nicky Larson (31 Décembre 2005)

cretinoïde a dit:
			
		

> Le fortran et le C++ pour les applications commerciales nouvelles generations (comprendre en cocoa) c'est l'avenir !
> 
> Merci Didier de diffuser la bonne parole aux jeunes developpeurs !!!!



Il manque plus que le cobol


----------



## cretinoïde (31 Décembre 2005)

et le logo sur MO5, sans oublier le basic extended !

Qu'est ce qu'on se marre !!!!


----------



## mpergand (31 Décembre 2005)

[mode troll ON]

ObjectiveC trop de la balle !
Utilisé par 0,001% des devs dans le monde, plante comme du C et presque aussi lent que java !

Think different !


----------



## Nicky Larson (31 Décembre 2005)

mpergand a dit:
			
		

> [mode troll ON]
> 
> ObjectiveC trop de la balle !
> Utilisé par 0,001% des devs dans le monde, plante comme du C et presque aussi lent que java !
> ...



Depuis quand un langage de programmation plante ?


----------



## cretinoïde (31 Décembre 2005)

Nicky Larson a dit:
			
		

> Depuis quand un langage de programmation plante ?



Depuis qu'objective-c necessite une MRJ comme Java :rateau:


----------



## Didier Guillion (1 Janvier 2006)

cretinoïde a dit:
			
		

> Méprisant et prétentieux petit personnage !



Tiens, des insultes maintenant...
Tu porte vraiment bien ton pseudo.
Ne compte pas sur moi pour me rabaisser a ce niveau.
Et si c'est de la pretention, tant mieux.

Cordialement


----------



## molgow (1 Janvier 2006)

Cette discussion était pourtant bien partie. Mais si vous persistez à avoir une discussion inintéressante et aussi peu constructive, je sais pas s'il est nécessaire de laisser ce sujet ouvert.

Comme j'ai la conviction que vous êtes des gens intelligents, je vous laisse encore une chance de vous auto-modérer... mais ça sera peut-être pas pour longtemps, c'est à vous de voir


----------



## molgow (1 Janvier 2006)

Maintenant, pour revenir au sujet. Si on résume, sur les futurs MacIntel, nous auront peut-être plus de choix pour les compilateurs : compilo optimisé par Intel ou gcc.
Par contre, on aura qu'un seul IDE nous permettant de développer des applications Carbon/Cocoa ?!
Vu que CodeWarrior va être arrêté, peut-on espérer que quelqu'un se lance dans le développement d'un nouveau IDE pour Mac ? Qu'en pensez-vous ?


----------



## Didier Guillion (1 Janvier 2006)

Bonsoir,

XCode n'est pas la premiere et la seule tentative d'"enrober" des compilateurs/linkeurs comme GCC dans une interface plus amicale que la ligne de commande. Des tentatives existent deja sur Linux (il y a quelques années il me semble avoir testé quelque chose qui s'appellait "KDE quelque chose" sur Linux Red Hat). A l'époque ce n'était guère concluant mais c'est peut etre une des possibilités interessante et a suivre.

De tout ce que j'ai vu, XCode reste cependant le plus aboutit.

Un des problemes de la programmation Cocoa/Obj-C est qu'il n'existe pas de documentation expliquant la structure interne des Nibs (ou si je me trompe, merci de donner le lien) comme s'était le cas pour les ressources Mac OS anterieure à X. Personnellement, j'hésiterait a baser une appli professionnelle, destinée à durer, sur un format de fichier non publié.
Le passage obligé est donc Interface Builder. A mon gout, il est plutot complexe et plutot fragile.

Cordialement


----------



## cretinoïde (1 Janvier 2006)

Didier Guillion a dit:
			
		

> Bonsoir,
> 
> XCode n'est pas la premiere et la seule tentative d'"enrober" des compilateurs/linkeurs comme GCC dans une interface plus amicale que la ligne de commande. Des tentatives existent deja sur Linux (il y a quelques années il me semble avoir testé quelque chose qui s'appellait "KDE quelque chose" sur Linux Red Hat). A l'époque ce n'était guère concluant mais c'est peut etre une des possibilités interessante et a suivre.
> 
> ...



(... passage pas constructif du tout ...) (a ce moment la efface aussi le message du dessus histoire d'etre coherent du début à la fin). Rien ne t'oblige à utiliser les nibs pour tes interfaces, tu peux les coder entierement "à la main". Et c'est parfois utile. 

Maintenant dans le cadre des excellents, modernes et innovants bindings + coredata, IB devient tres tres pratique et productif.


----------



## Didier Guillion (1 Janvier 2006)

cretinoïde a dit:
			
		

> (... passage pas constructif du tout ...)


Je ne vois pas le lien sur la doc dans ta réponse, merci de la fournir avant de faire des jugements.

Cordialement


----------



## cretinoïde (1 Janvier 2006)

Didier Guillion a dit:
			
		

> Je ne vois pas le lien sur la doc dans ta réponse, merci de la fournir avant de faire des jugements.
> 
> Cordialement


Heu comment te le dire sans te vexer et te faire passer pour quelqu'un qui ne sait pas de quoi il parle...

En fait, tu n'as jamais du consulter la doc sur AppKit (ce qui en soit est assez grave puisque tu te prononces avec autant de certitudes négatives sur Cocoa / XCode) et donc que tu racontes vraiment n'importe quoi....(puisque Appkit c'est avec Foundation la premiere chose à lire)

Consulte par exemple (mais juste par exemple hein ??), avec tes petits doigts agiles (ou pas) les 2 classes suivantes : 

NSButton & NSWindow.

Tu y verras des méthodes "accessibles à la main" : affichage, positionnement, etc, etc....tu en fais donc ce que tu veux...

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGControls/chapter_18_section_2.html

je cite : "Cocoa: Round buttons are available in Interface Builder. To create one programmatically, use the NSButtonCell method setBezelStyle with NSCircularBezelStyle as the argument. See Buttons in Cocoa User Experience Documentation." ---> Et ca date bien de 2000 voire avant.

 (... une phrase qui n'a rien à faire dans une discussion constructive ...)

Quand aux nibs....glisse donc les fichiers du package sur n'importe quel editeur de texte, et tu verras que c'est une structure XML (+ archiving)...enfin je dis ca, je dis rien.


----------



## Didier Guillion (1 Janvier 2006)

Bonsoir,

Je crois que l'on se comprends mal. Je sais que l'on peut creer des Nibs 'a la main', mais ceci n'explique pas la maniere dont ces Nibs sont mémorisés dans le fichier (ce que j'appele structure du fichier Nib). 
Il existe la possibilté via une ligne de commande de terminal de "dumper" certaines informations des Nibs (a des fins de traduction) mais pas toutes.
La définition de la structure du fichier des ressources Nibs assurerait perennité et portabilité.
Si tu veut utiliser le meme code sur plusieurs environnements, par exemple Mac OS et Windows, il est necessaire de connaitre la structure des Nibs pour les utiliser sous Windows. C'est ce que je fait depuis plusieurs années avec les ressources ancien format.
Donc, (désolé Modo), mais ma question reste valable, il y a t'il une doc expliquant la structure de ces fichiers Nibs.

Cordialement


----------



## cretinoïde (1 Janvier 2006)

Didier Guillion a dit:
			
		

> Bonsoir,
> 
> Je crois que l'on se comprends mal. Je sais que l'on peut creer des Nibs 'a la main', mais ceci n'explique pas la maniere dont ces Nibs sont mémorisés dans le fichier (ce que j'appele structure du fichier Nib).
> Il existe la possibilté via une ligne de commande de terminal de "dumper" certaines informations des Nibs (a des fins de traduction) mais pas toutes.
> ...




j'avoue ne pas comprendre ce que tu voudrais faire. mais je persiste à dire que les nibs comportent une structure "XML like", un peu comme le format d'interfca XAML introduit par MS dans longhorn.


----------



## Didier Guillion (1 Janvier 2006)

cretinoïde a dit:
			
		

> j'avoue ne pas comprendre ce que tu voudrais faire. mais je persiste à dire que les nibs comportent une structure "XML like", un peu comme le format d'interfca XAML introduit par MS dans longhorn.



C'est amusant, ce que tu dit est a la fois tres interessant et étonnamment agressif. Ce n'est pas la guerre bon sang, inutile de truffer tes messages d'allusions personnelles. Personne ne sait tout sur tous les sujets et j'adore apprendre des choses nouvelles.

Dans mes Nibs, j'ai plusieurs fichiers, et tu as raison, "Classes.nib", "Info.nib" semblent etre des structures XML. Mais si je regarde les fichiers principaux, "objects.nib" "keyedobjects.nib" pour moi c'est du binaire opaque. Tu as un outil particulier pour les "dumper" ?

Cordialement


----------



## cretinoïde (1 Janvier 2006)

Didier Guillion a dit:
			
		

> C'est amusant, ce que tu dit est a la fois tres interessant et étonnamment agressif. Ce n'est pas la guerre bon sang, inutile de truffer tes messages d'allusions personnelles. Personne ne sait tout sur tous les sujets et j'adore apprendre des choses nouvelles.
> 
> Dans mes Nibs, j'ai plusieurs fichiers, et tu as raison, "Classes.nib", "Info.nib" semblent etre des structures XML. Mais si je regarde les fichiers principaux, "objects.nib" "keyedobjects.nib" pour moi c'est du binaire opaque. Tu as un outil particulier pour les "dumper" ?
> 
> Cordialement



il faut essayer de les desarchiver avec les methodes qui vont bien. j'avoue ne pas avoir essayé mais ca doit etre certainement possible (mais utile ?)...

connais tu ceci ?

http://members.capmac.org/~deanhall/python/IntroToUsingPyObjC.html

il me semble qu'ils ont réalisé ce que tu veux faire ...une sorte de passerelle cocoa vers python (et donc exploitation des .nib)...


----------



## Didier Guillion (1 Janvier 2006)

Rassure toi, l'utilité je l'ai.
Merci pour le lien je vais explorer cela, meme si dans une premiere lecture cela me semble un peu éloigné de ma demande. C'est plus une interface pour utiliser les Nibs via Python, mais sur Mac OS X. Non ?
Un conseil, quand tu entre dans un forum technique, essaie de fournir tes references, applications créées par exemple, que l'on cerne mieux tes domaines de compétence.

Cordialement


----------



## mpergand (1 Janvier 2006)

> Personnellement, j'hésiterait a baser une appli professionnelle, destinée à durer, sur un format de fichier non publié.
> Le passage obligé est donc Interface Builder. A mon gout, il est plutot complexe et plutot fragile.



Le problème est le même pour les Bindings et Coredata, ces technos sont jeunes et n'ont pas fait encore suffisamment leurs preuves. Pour un développement pro, c'est plutôt rédhibitoire...

Pour Coredata, vu la lenteur d'ObjC, on peut sérieusement se poser des questions sur ces performances. Voir les commentaires/réactions sur la dev-list ...

Un bug lié aux bindings via InterfaceBuilder peut devenir un vrai cauchemar et faire perdre pas mal de temps.

Personellement, les bindings, je veux bien les utiliser pour gérer un simple panneau de préférences, mais j'y réfléchirai à deux fois avant de baser toute appli entière dessus. Trop risqué.


----------



## mpergand (1 Janvier 2006)

Jusqu'a preuve du contraire les fichiers nibs ne sont pas documentés par Apple, d'ailleurs c'est bien embêtant pour le projet http://www.gnustep.org/


----------



## cretinoïde (1 Janvier 2006)

mpergand a dit:
			
		

> Le problème est le même pour les Bindings et Coredata, ces technos sont jeunes et n'ont pas fait encore suffisamment leurs preuves. Pour un développement pro, c'est plutôt rédhibitoire...
> 
> Pour Coredata, vu la lenteur d'ObjC, on peut sérieusement se poser des questions sur ces performances. Voir les commentaires/réactions sur la dev-list ...
> 
> ...



1 - CoreData et sa pseudo lenteur n'ont rien à voir avec la simili lenteur d'Obj-C. Tout cela c'est de l'amalgame à 2 sous. CoreData n'est pas lent, en revanche mal utilisé il peut l'etre (c'est ce qui a été clairement défini sur les listes). Il existe deja de "belles" appli basé sur CoreData + bindings qui ne sont pas "lentes" (terme bateau qui ne veut foncierement rien dire si on l'explicite pas en détails). Apple demande d'utiliser CoreData selon certains mécanismes précis (trop long à expliquer ici cf les listes). 

2 - Les bindings (contrairement à CoreData d'ailleurs) ne sont pas si jeunes (10.3) et sont tres aboutis. Ici encore des appli les utilisent et pas des moindres. Aucun argument en leur défaveur n'a été présenté. 

3 - "un bug lié aux bindingts via IB peut devenir un vrai cauchemard" ... si ma tante en avait ce serait mon oncle...


----------



## cretinoïde (1 Janvier 2006)

mpergand a dit:
			
		

> Jusqu'a preuve du contraire les fichiers nibs ne sont pas documentés par Apple, d'ailleurs c'est bien embêtant pour le projet http://www.gnustep.org/



bien embétant peut etre, utile je ne sais pas.

http://developer.apple.com/document...withIBS/ibs_concepts/chapter_2_section_3.html


----------



## Thierry6 (1 Janvier 2006)

Didier Guillion a dit:
			
		

> XCode n'est pas la premiere et la seule tentative d'"enrober" des compilateurs/linkeurs comme GCC dans une interface plus amicale que la ligne de commande. Des tentatives existent deja sur Linux (il y a quelques années il me semble avoir testé quelque chose qui s'appellait "KDE quelque chose" sur Linux Red Hat). A l'époque ce n'était guère concluant mais c'est peut etre une des possibilités interessante et a suivre.



Le couple gagnant chez KDE : K-Develop (IDE) et QT Designer (interface)
http://directory.fsf.org/KDevelop.html


----------



## Didier Guillion (2 Janvier 2006)

cretinoïde a dit:
			
		

> bien embétant peut etre, utile je ne sais pas.
> 
> http://developer.apple.com/document...withIBS/ibs_concepts/chapter_2_section_3.html




Le lien fonctionne, mais quel rapport avec la discussion ?

Cordialement


----------



## Didier Guillion (2 Janvier 2006)

mpergand a dit:
			
		

> Jusqu'a preuve du contraire les fichiers nibs ne sont pas documentés par Apple, d'ailleurs c'est bien embêtant pour le projet http://www.gnustep.org/



C'est bien ce qui me semblait. Merci de confirmer cela.

Cordialement


----------



## Nicky Larson (2 Janvier 2006)

(... attaque personnelle sans lien avec le sujet ...)
A la limite, si tu ne fais pas confiance en Apple, je ne vois pas pourquoi tu essaies d'utiliser leurs technos. 

Programme directement en Java. Bien que le nouvel utilitaire pour faire les interfaces graphiques en Java de Netbeans par exemple souffre du même problème que les Nibs. La team de netbeans ayant décidé qu'il était plus facile pour eux de générer (et maintenir) des fichiers pour les interfaces "fermés".


----------



## SuperCed (9 Janvier 2006)

HmJ a dit:
			
		

> Au passage, il y a cette histoire de Ars Technica (merci de ne pas trop leur taper dessus, je les tiens pour d'excellents analystes pro-Mac grace a leur sens des realites), en juillet je crois, qui disait qu'un developpeur interne de Apple etait degoute parce que l'OS est compile avec des optimisations au niveau de la taille des programmes, pas du tout au niveau de la rapidite / reactivite. On en est ou, ca reste d'actualite ?



Je reprends la discution au milleu.
Intel et Microsoft préconisent d'utiliser le flag qui permet de réduire la taille du code et on l'accélération des performances. En fait, le flag qui accélère les performances augmentent considérablement la taille de l'éxécutable car les méthodes sont mises en inline le plus souvent possible.
Ok, vous aller me dire : "c'est pas bien grave que l'appli et surtout, la partie code prenne un peu plus de place, les disques sont gros maintenant". Cependant, il existe une réelle cause, vérifiée assez souvent par la méthode empirique. En fait, les codes de grosses tailles ont parfoit du mal à entrer en totalité dans les mémoire cache de processeur, surtout quand il y a beaucoup de processus qui tournent simultanément.

Intel s'est apperçu que la plupart des programmes (il y a des exceptions), le fait de réduire la taille du code exécutable augmentait les chances que ce code soit en totalité en mémoire cache, et du coup, augmentait les performances.
Donc en général, sous gcc comme sur les compilateurs Intel, il faut mieux créé un code petit en taille. Bien sur, si on fait des tests et qu'on s'apperçoit que la version compilées avec les flags de vitesse (-O3 et autres sur gcc) va plus vite, il ne faut pas s'en priver. Mais quand on ne sait pas trop, mieux vaut optimiser pour diminuer la taille du code.


----------



## Didier Guillion (12 Janvier 2006)

Bonjour,

je suis d'accord avec toi SuperCed, sauf que... Rien n'oblige de compiler tout le code en optimisation de taille, la plupart des compilateurs permettent de n'optimiser que certaines parties du code, les plus sensibles, par exemple en C via inline <nom de fonction>. Ou via des #pragma.

Cordialement


----------



## SuperCed (12 Janvier 2006)

J'ai déjà vu les inline et des pragma. Pour ces derniers, je n'ai jamais su à quoi ça servait. Je savais juste que ça donnait des intructions au compilateurs.

J'ai vu d'autres instructions de ce type lorsque j'avais regardé la librairie VAST-C qui permettait de vectoriser des codes automatiquement ou presque pour une utilisation d'Altivec.
Finalement, tout était dans le "presque" puisque bien souvent, le code vectorisé généré était plus lent que le code non vectorisé. il fallait donc donner plein d'instruction à VAST pour qu'il fasse du meilleur boulot et finalement, c'était presque aussi complexe que de vectoriser soi-même son code...

Peux-tu m'expliquer un peu plus comment fonctionnent les pragma? Je ne demande pas un cours complet, mais simplement un exemple pour que je comprenne vaguement comment ça fonctionne.

Utilises-tu souvent les fonctions inline? Dans quels cas? Même question pour les instructions de compilation, tu mets souvent des pragma? Dans quels cas ça t'es utile? Dans des portions de code critiques?


----------



## Didier Guillion (12 Janvier 2006)

Les pragma permettent de regler les options de compilation comme l'optimisation, l'alignement des données et fonction. Cependant ils peuvent changer d'un compilateur a l'autre.
Par exemple sur CodeWarrior j'utilise :

Reglage local du type d'optmisation
	#pragma optimization_level 4

Reglage du niveau de mise de fonction inline automatique, les fonctions trop longue ne seront pas mise inline. Les compilateurs evaluent la longueur des fonctions n'ont pas en ligne de code machine resultat mais une unité interne.

	#pragma inline_depth(smart)

Diverses optimisations locales qui peuvent avoir un effet bénéfique ou le contraire :

	#pragma opt_strength_reduction on
	#pragma opt_unroll_loops on
	#pragma opt_vectorize_loops on

Je suppose que des équivalents ou similaires existent en GCC.

A noter, que l'excellent outil Shark fourni avec les developer tools te permet de savoir où le temps CPU est passé, c'est precis à la ligne assembleur pret... Il donne meme des conseils d'optmisation, souvent judicieux.

Cordialement


----------



## SuperCed (12 Janvier 2006)

Peux-tu m'expliquer ce qu'est l'alignement des données?

Pour le reste, j'ai compris, et ça a l'air très puissant, mais je pense qu'il faut posséder des bonnes connaissances en complexité voire en assembleur.

Quelques est l'ordre de grandeur de performance que tu arrives à gagner en touchant aux instructions de compilation?

Est-ce que ça ne prend pas trop de temps comparé aux gains obtenus?


----------



## Didier Guillion (12 Janvier 2006)

SuperCed a dit:
			
		

> Peux-tu m'expliquer ce qu'est l'alignement des données?
> 
> Pour le reste, j'ai compris, et ça a l'air très puissant, mais je pense qu'il faut posséder des bonnes connaissances en complexité voire en assembleur.
> 
> ...




Oui, en effet il vaut mieux savoir lire un minimum l'assembleur. Mais pour debogger aussi de toute manière.

L'ordre de grandeur entre non optimisé et optimisé est assez important, mais cela depends de l'application. Une application basée sur une interface va de toute facon passer 90% du temps dans le systeme donc tu ne verra pas de difference. Mais si tu ecrit une application avec de gros calcul, commme un encodeur/decodeur MPEG par exemple, avec des fonctions qui passent tres souvent et prennent 80% de ton temps CPU, cela vaut le coup de gagner 10-15 % dessus. Et si tu ne gagne pas assez, il vaut mieux la reecrire en assembleur.

Pour l'alignement des données, je ne suis pas tres callé en microprocesseur, mais si j'ai bien compris, il y a un cache pour les instructions, l'agencement des instructions en mémoire peut perturber le fonctionnement de ce cache. 
De meme certains processeurs aiment tomber sur des mulitples de 32, 16 ou 8 octets (peut etre aussi le cache).
Ce que te signale d'ailleurs Shark.

Cordialement


----------



## KNT (20 Janvier 2006)

Didier Guillion a dit:
			
		

> Oui, en effet il vaut mieux savoir lire un minimum l'assembleur. Mais pour debogger aussi de toute manière.
> 
> L'ordre de grandeur entre non optimisé et optimisé est assez important, mais cela depends de l'application. Une application basée sur une interface va de toute facon passer 90% du temps dans le systeme donc tu ne verra pas de difference. Mais si tu ecrit une application avec de gros calcul, commme un encodeur/decodeur MPEG par exemple, avec des fonctions qui passent tres souvent et prennent 80% de ton temps CPU, cela vaut le coup de gagner 10-15 % dessus. Et si tu ne gagne pas assez, il vaut mieux la reecrire en assembleur.
> 
> ...



Pour information, et de ma propre expérience lors du développement des routines de rasterisations de sprites :

- Code brut compilé avec Codewarior optimisations compilo à fond = Coef 1

- Désassemblage et "cheating" des instruction en C (manière d'écrire, ordre, etc..) = coef 1,2

- Réécriture en Assembleur PPC, avec obsession de l'optimisation maximal de l'usage des registres du PPC, et du chevauchement des instructions en vue d'une utilisation maximal des 2 ALU = Coef 1,4


Bref, en gros là ou cela vaut vraiment le coup de se fatiguer, en faisant de la haute couture , j'ai gagné 40% de perfs.

Maintenant j'ai pas testé sous Xcode, avec GCC, mais j'image que cela sera comme sous Cw si pas plus mauvais.


----------



## Nicky Larson (3 Septembre 2006)

Didier Guillion a dit:


> Bonsoir,
> Un des problemes de la programmation Cocoa/Obj-C est qu'il n'existe pas de documentation expliquant la structure interne des Nibs (ou si je me trompe, merci de donner le lien) comme s'&#233;tait le cas pour les ressources Mac OS anterieure &#224; X. Personnellement, j'h&#233;siterait a baser une appli professionnelle, destin&#233;e &#224; durer, sur un format de fichier non publi&#233;.
> Le passage oblig&#233; est donc Interface Builder. A mon gout, il est plutot complexe et plutot fragile.
> 
> Cordialement



Il y a du nouveau l&#224; dessus. Depuis tr&#232;s r&#233;cemment, le projet GNUStep est capable de g&#233;n&#233;rer et de lire des fichiers Nib fonctionnant sur Mac OS X.

http://heronsperch.blogspot.com/2006/08/nib-encoding-now-working-in-gnustep.html 

La question est: comment ont ils fait si rien est document&#233; ?


----------



## Didier Guillion (3 Septembre 2006)

Nicky Larson a dit:


> Il y a du nouveau l&#224; dessus. Depuis tr&#232;s r&#233;cemment, le projet GNUStep est capable de g&#233;n&#233;rer et de lire des fichiers Nib fonctionnant sur Mac OS X.
> 
> http://heronsperch.blogspot.com/2006/08/nib-encoding-now-working-in-gnustep.html
> 
> La question est: comment ont ils fait si rien est document&#233; ?




Tu cree un NIB vide, tu dumpe le contenu, tu ajoute un objet au NIB, tu regarde ce qui a chang&#233;, tu en deduit une portion de la structure du fichier et tu recommence pour tous les objets possibles. Bien sur, si le format des NIBS change tu recommence a zero...

Et en plus, ils font le contraire, convertir un format ouvert vers le format ferm&#233; des Nibs, ce qui est plus facile mais reste n&#233;anmmoins remarquable.

Autre solution, ils ont simplement fait une conversion de leur format GNU en texte et le traite par le convertisseur de texte en Nib.

Cordialement


----------



## harlock59 (4 Octobre 2006)

tout ceci dit, quelqu'un saurait-il o&#249; acheter codewarrior 10 ?


----------



## ntx (4 Octobre 2006)

EBay ?


----------



## Didier Guillion (4 Octobre 2006)

Peut etre ici :

http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=010984007869597059286926661

Cordialement


----------



## tantoillane (7 Novembre 2006)

Les liens sur la premi&#232;re page pour t&#233;l&#233;chager la version de d&#233;mo ne sont plus valides, est-ce parce que cette version de d&#233;mo est abandon&#233;e ou parce que les liens ne sont plus bons ?

Merci


----------



## Céroce (8 Novembre 2006)

Didier Guillion a dit:


> Pour l'alignement des donn&#233;es, je ne suis pas tres call&#233; en microprocesseur, mais si j'ai bien compris, il y a un cache pour les instructions, l'agencement des instructions en m&#233;moire peut perturber le fonctionnement de ce cache.



Non, Didier, c'est pas une histoire de cache. Imagine que tu utilises un processeur dont le bus de donn&#233;es est de 32 bits (tous les PowerPC jusqu'au G4).


```
Align&#233;           Non align&#233;
Adresse 0       A
Adresse 1       B                         A 
Adresse 2       C                         B
Adresse 3       D                         C
Adresse 4                                 D
```
Tu peux acc&#233;der directement &#224; la donn&#233;e align&#233;e, puisqu'elle se situe sur une adresse multiple de 4 octets (= 32 bits). Tu peux lire la donn&#233;e avec une seule instruction.

Pour la donn&#233;e non align&#233;e, par contre, il te faudra 3 instructions:
Une pour l'octet A
Une pour le mot BC
Une pour l'octet D

Cons&#233;quence: c'est plus lent. Et comme on dispose de plein de m&#233;moire, mieux vaut aligner.


----------



## tatouille (9 Novembre 2006)

Didier Guillion a dit:


> C'est amusant, ce que tu dit est a la fois tres interessant et &#233;tonnamment agressif. Ce n'est pas la guerre bon sang, inutile de truffer tes messages d'allusions personnelles. Personne ne sait tout sur tous les sujets et j'adore apprendre des choses nouvelles.
> 
> Dans mes Nibs, j'ai plusieurs fichiers, et tu as raison, "Classes.nib", "Info.nib" semblent etre des structures XML. Mais si je regarde les fichiers principaux, "objects.nib" "keyedobjects.nib" pour moi c'est du binaire opaque. Tu as un outil particulier pour les "dumper" ?
> 
> Cordialement



les NIB enfin les resources les composants sont bien des structures xml 

"objects.nib" "keyedobjects.nib" sont des "binary plist" (unpackable)
ca n'est pas du tout ferm&#233; c'est juste pas document&#233; 
-> defaults  et CF-Lite src si tu veux observer 

duplicate un "keyedobjects.nib" et renomme en "keyedobjects.plist" puis ouvre le sous "Property List Editor"


----------



## Didier Guillion (10 Novembre 2006)

tatouille a dit:


> les NIB enfin les resources les composants sont bien des structures xml
> 
> "objects.nib" "keyedobjects.nib" sont des "binary plist" (unpackable)
> ca n'est pas du tout fermé c'est juste pas documenté
> ...



Je prends un "objects.nib", je le dumpe en hexa, et c'est bien du binaire. Tu fait comment pour convertir ce binaire en texte XML ?

Cordialement


----------



## tatouille (10 Novembre 2006)

Didier Guillion a dit:


> Je prends un "objects.nib", je le dumpe en hexa, et c'est bien du binaire. Tu fait comment pour convertir ce binaire en texte XML ?
> 
> Cordialement



Binary data :

 < _[hexadecimal codes in ASCII]_ >

en faite plus compliqu&#233; (unicode)
(tu as un header bien-sur qui specifie le fichier )


10.4/CF-368/Parsing.subproj/

ne fait pas attention c'est un premier rangement des sources
il n'y pas a encore le filtre versionning (pas fini la DB)
src.gnu-darwin

mais bon dans ce sujet il ya un peu trois sujets en m^me temps


----------



## tatouille (10 Novembre 2006)

KNT a dit:


> j'ai pas test&#233; sous Xcode, avec GCC, mais j'image que cela sera comme sous Cw si pas plus mauvais.



GCC est un bon compiler mais si tu fais n'importe quoi avec tu obtients des r&#233;sultats mauvais
GCC est une collection et beaucoup de ses utilitaires ne sont pas utilis&#233;s

je vois souvant des projects qui ne font pas la diff&#233;rence entre preprocessed et non-preprocessed
deplus il ya beaucoup d'optimisation suivant les platformes et elles sont peu utilis&#233;es

sans parler des nombreuses options Apple Only

GCC est beaucoup moins "assist&#233;" donc il faut un peu de rigueur 
ce qui fait malheureusement defaut &#224; beaucoup de dev 

je suis affol&#233; par le flou artistique des formations (grandes &#233;coles / facult&#233;s / &#233;coles d'ing&#233;gnieur) 
des + jeunes en France , souvant les gens sortant d'&#233;cole en contrat de qualification ont une bien meilleur
approche et un niveau de tr&#232;s loin sup&#233;rieur et chez les autodidactes too

 [RECADRAGE]

et j'aimerais bien aussi ici que les petits ***s se calment avec Didier

Didier ds la profession , c'est ce qu'on appel un *master* 
+ de 15 ans d'exp&#233;rience en C/CPP de gros softwares &#224; son actif ... 

vous pouvez donc plaisanter avec lui mais de la 
&#224; le prendre pour un imb&#233;cile il ya des limites !!!!!!!!!!!!!!!!


----------



## Céroce (10 Novembre 2006)

tatouille a dit:


> [RECADRAGE]
> 
> et j'aimerais bien aussi ici que les petits ***s se calment avec Didier
> 
> ...



Tout à fait d'accord Tatouille. Je voulais dire que Didier a le mérite de programmer en indépendant. Ca demande du courage et une relation suivie avec le client. Je ne suis pas forcément d'accord pour ce qui est de son entêtement face à Cocoa, mais il a des contraintes que n'ont pas les projets qui ont été cités, à savoir la compatibilité de ses applis avec d'anciennes machines, et la pérénité du code pour les prochaines années.

C'est autre chose que bidouiller un truc sur un coin de table que personne d'autre n'utilisera jamais. Quand vous aurez fait un boulot comparable au sien, vous pourrez donner votre avis, mais je pense que d'ici là, vous aurez beaucoup gagné en sagesse.


----------



## Vivid (10 Décembre 2006)

je confirme, tardivement mais je confirme, didier et son frere sont des tronches, ils respirent comme il cree du code, c'est hallucinant! pour creer du code pour un Mo5, Atari, Amstrad il faut etre un bon et un vrai bon  c'est pas du java ou une quelconque POO, ce genre d'experience sa forme! il n'y a que les meilleurs qui en sont capable. C'est meme des fois presque rageant de voir autant de talent . Des virtuoses, DES TRONCHES!!! je vous dit. Que je meurent de suite si je ment.

 Je les connais depuis 20 ans maintenant et c'est une grande chance pour moi et pour le monde du Mac en general.
Soyez content de les avoir sur votre forum, des pointures pareilles la majorite prefere meme pas perdre leur temps a discute avec des personnes qui s'aparente plus a des supporter qu'a de vrais programmeurs pro ou programmeurs 'amateur', le temps c'est de l'argent surtout pour un professionnel.

En plus de ca ils ont des qualites humaine; pedagogue, patient (on la vue dans ce forum!), gentil, abordable et surtout pas pedant ou pretentieux pour un sous, Ah non vraiment pas je vous assure.

Les premiers temps que je les connus, moi aussi c'etait bla bla bla, j'etait jeune, adolescent et mes bla bla bla s'apparente plus a de l'enthousiasme et une passion pas bien maitriser qu'autre chose et ils sont ce genre de personne qui disent rien, ou pas grand chose, pas du genre a t'ecraser verbalement comme une merde, parceque les armes ils les ont, heureusement je suis observateur, et j'ai vite compris a qui j'avais a faire. 

Faut imaginer, moi, des grandes phrases toutes faites prise dans des journaux, tu extrapole le peu de chose que tu connais, ou souhaite connaitre et vas y, bla, bla ,bla dans le fond tu ne l'a meme pas mis en pratique, et eux des questions pointues, pratiques, bien ciblees, argumentees et la, si t'es pas con tu freine...  et puis tu 'approfondie', tu 'creuse' pour savoir a qui tu as a faire.. et tu decouvre..
Sur le moment c'est un grand coups au moral , ensuite c'est la honte qui prevaut, puis tu te souviens de toutes les conneries que tu as pu dire devant eux, tu as vraiment l'impresion de pedaler a fond dans le vide . 

Pas parceque je me croyais plus fort que tout le monde mais plutot, par le gouffre entre leur travail, leur experience, leur savoir et le mien, et la tu te dis "il m'en rester de la route a faire...."    cela m'a apris l'humilite, cela recadre les choses, c'est bien , j'avais compris de mon chef la 'lecon', par la pratique .


Par la suite et bien plus tard, je vous dit pas combien de fois ils m'ont aider quand il a fallut que j'aprenne le C et la Rom du Mac, en meme temps, quand j'avais pas assez de recul, pour trouver mes erreurs, erreurs repeter depuis le debut d'un projet... eux toujours patient pourtant du travail ils en ont, la boutique il faut qu'elle tourne, moi je n'en vie pas, eux si. Meme la, toujours present. Ils mon vraiment fait gagner du temps. C'est un plaisir de discuter profession avec eux. J'en est connut des IUT, des ingenieurs informaticiens et pourtant... est en informatique tant que tu n'as pas fait! tu ne sais pas a 100&#37; c'est pas la theorie qui nourrit son homme (intellectuellement et financierement).


Je suis pas maitre a faire des compliments, mais quand il faut, il faut. Et puis tout le monde n'a pas la chance de les connaitres, alors je me suis permis de vous donner mon avis.

Sur ce, je vous souhaite une bonne nuit, une bonne semaine, bientot les vacances!, et desoles pour l'orthographe.

Cordialement.


----------



## tantoillane (10 Décembre 2006)

Vivid a dit:


> le temps c'est de l'argent surtout pour un professionnel.




Et bien moi, il m'en a fallu du temps pour tout lire :rateau: 
Mais je suis bien d'accord avec toi Vivid,


----------

