Codewarrior 10 - La version ultime.

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
Cliquez pour agrandir...
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.
 
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
 
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.
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
Cliquez pour agrandir...


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.
 
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.
Cliquez pour agrandir...

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
 
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
Cliquez pour agrandir...

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)...
 
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
 
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.
Cliquez pour agrandir...

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 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 ...

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é.
Cliquez pour agrandir...

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...
 
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.
Cliquez pour agrandir...

Le couple gagnant chez KDE : K-Develop (IDE) et QT Designer (interface)
http://directory.fsf.org/KDevelop.html
 
(... 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".
 
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 ?
Cliquez pour agrandir...

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.
 
  • J’aime
Réactions: WebOliver et molgow
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
 
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?
 
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
 
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?
 
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.

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?
Cliquez pour agrandir...


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
 

Sujets similaires

bertrand
  • Fermé
Synthèse Macbook : Un Modèle Raté
Réponses
278
Affichages
30K
Mac
macinside
M
P
Réaction sur Windows XP... Vive le Mac !
Réponses
27
Affichages
2K
Réagissez !
Le Gognol
Le Gognol
M
10.1 Installation et premier bilan
Réponses
22
Affichages
3K
macOS
tontoncroco
T
Haut Bas
Back