Garbage Collecte active des warnings
Adau
Membre
Bonjour,
Tout d'abord, je suis nouveau ici sur ce forum, et tout nouveau en matière de programmation.
J'ai appris le C en école d'ingénieur pour faire des systèmes embarqués, et de ce coté pas de problème.
Pourquoi apprendre l'Objectif-C ? Disons que je voulais pouvoir faire des interfaces sympas pour les systèmes que je met en place, sous MacOs parce que tout le monde sait le faire sous Windows, et aussi parce que je trouve ce langage très élégant.
Bref, passons aux choses sérieuses.
Je suis en train de suivre deux bouquins en même temps pour apprendre. Tout se passe bien, mais j'ai toujours des warnings qui surviennent lorsque j'active le garbage collector (supported ou required).
Je ne sais pas ce que vous pensez du garbage collector, mais pour ce que je cherche à faire, ne pas l'utiliser me compliquerait la tâche pour un gain de performance nul.
Voici les warnings en question:
2009-04-24 12:22:47.636 KVCFun[783:10b] Error loading /Library/InputManagers/Cooliris/Cooliris.bundle/Contents/MacOS/Cooliris: dlopen(/Library/InputManagers/Cooliris/Cooliris.bundle/Contents/MacOS/Cooliris, 265): no suitable image found. Did find:
/Library/InputManagers/Cooliris/Cooliris.bundle/Contents/MacOS/Cooliris: GC capability mismatch
2009-04-24 12:22:47.650 KVCFun[783:10b] Error loading /Library/InputManagers/GrowlSafari/GrowlSafariLoader.bundle/Contents/MacOS/GrowlSafariLoader: dlopen(/Library/InputManagers/GrowlSafari/GrowlSafariLoader.bundle/Contents/MacOS/GrowlSafariLoader, 265): no suitable image found. Did find:
/Library/InputManagers/GrowlSafari/GrowlSafariLoader.bundle/Contents/MacOS/GrowlSafariLoader: GC capability mismatch
Je précise que j'ai bien Cooliris d'installé, ainsi que Growl avec son plug-in Safari.
Je joint à ce message un des programmes d'exemple du bouquin de Aaron Hillegass, au cas où.
Dans l'absolu, c'est pas méchant du tout, car tout les programmes fonctionnent parfaitement, mais j'aimerai comprendre d'où les warnings proviennent et comment les supprimer.
Merci d'avance.
Tout d'abord, je suis nouveau ici sur ce forum, et tout nouveau en matière de programmation.
J'ai appris le C en école d'ingénieur pour faire des systèmes embarqués, et de ce coté pas de problème.
Pourquoi apprendre l'Objectif-C ? Disons que je voulais pouvoir faire des interfaces sympas pour les systèmes que je met en place, sous MacOs parce que tout le monde sait le faire sous Windows, et aussi parce que je trouve ce langage très élégant.
Bref, passons aux choses sérieuses.
Je suis en train de suivre deux bouquins en même temps pour apprendre. Tout se passe bien, mais j'ai toujours des warnings qui surviennent lorsque j'active le garbage collector (supported ou required).
Je ne sais pas ce que vous pensez du garbage collector, mais pour ce que je cherche à faire, ne pas l'utiliser me compliquerait la tâche pour un gain de performance nul.
Voici les warnings en question:
2009-04-24 12:22:47.636 KVCFun[783:10b] Error loading /Library/InputManagers/Cooliris/Cooliris.bundle/Contents/MacOS/Cooliris: dlopen(/Library/InputManagers/Cooliris/Cooliris.bundle/Contents/MacOS/Cooliris, 265): no suitable image found. Did find:
/Library/InputManagers/Cooliris/Cooliris.bundle/Contents/MacOS/Cooliris: GC capability mismatch
2009-04-24 12:22:47.650 KVCFun[783:10b] Error loading /Library/InputManagers/GrowlSafari/GrowlSafariLoader.bundle/Contents/MacOS/GrowlSafariLoader: dlopen(/Library/InputManagers/GrowlSafari/GrowlSafariLoader.bundle/Contents/MacOS/GrowlSafariLoader, 265): no suitable image found. Did find:
/Library/InputManagers/GrowlSafari/GrowlSafariLoader.bundle/Contents/MacOS/GrowlSafariLoader: GC capability mismatch
Je précise que j'ai bien Cooliris d'installé, ainsi que Growl avec son plug-in Safari.
Je joint à ce message un des programmes d'exemple du bouquin de Aaron Hillegass, au cas où.
Dans l'absolu, c'est pas méchant du tout, car tout les programmes fonctionnent parfaitement, mais j'aimerai comprendre d'où les warnings proviennent et comment les supprimer.
Merci d'avance.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
En fait les logiciels cités sont des plugins (Growl, SafariPlugin, ...) ce qui fait qu'à chaque lancement d'une appli quelconque, le système va regarder si, dans le dossier officiel où se toruvent tous les plugins installés, il y en a un qui correspond à ton appli, pour le charger dans ton appli le cas échéant. C'est le fonctionnement normal et automatique du LaunchServices. Mais le truc c'est que pour ça faut qu'il inspecte le plugin, et au moment où il fait ça, il te met un warning parce que ton appli est garbage-collectée et le plugin ne l'est pas... donc potentiellement il essayerait de charger un plugin non-GC dans une appli GC, c'est ça qu'il te signale.
Perso j'ai le même genre de warning avec Inquisitor (plugin Safari)... et ce à chaque fois que je lance des softs utilisant le GC... comme l'application Xcode elle-même : dès que j'ai lancé Xcode, si je vais dans la Console (sans même parler de charger un de mes projets, l'appli Xcode toute seule quoi) je vois des warnings du même genre...
Donc bon pas de quoi s'inquiéter je pense.
Y'a-t-il un moyen de mettre tout ceci en mode verbose ? Pour éviter de surcharger inutilement la console ?
Maintenant je ne sais pas si ça supprime aussi les warnings dont tu parles, c'est pas dit, mais à tester. Moi je sais que quand je lance Xcode, apparait toujours dans la console : (suivi donc d'une ligne [tt]<QuietXcode> loaded successfully[/tt] depuis que j'ai installé QuietXcode, là où avant à la place de cette ligne dans la console j'avais 150 warnings émis par Xcode lui-même)
Pas du bien... et totalement déconseillé pour l'apprentissage !
Je te renvoies à ce sujet.
Au moins, je comprend l'origine des warnings. Vu qu'il y en a que deux, et qu'ils prennent seulement quelques lignes, je vais m'en accoutumer.
Au passage, quietXcode ne marche pas pour retirer ces warnings, dommage.
Quant au Garbage Collector, je pense, sûrement à mal, l'activer quand même. En effet, les programmes que je compte faire ne seront que des interfaces utilisateurs pour des systèmes embarqués. En fait, tout se fait à l'aide de programmes écrit par mes soins en C en ligne de commande. Mon programme en cocoa ne devrait que lancer ces lignes de commande avec les bons arguments.
Et puis sinon, j'ai bien peur de squatter ce forum avec des problèmes de mémoire...
En effet les systèmes embarqués ont une mémoire limitée, bien plus limitée que la mémoire de nos machines de bureau... et surtout rares sont celles qui "swappent" (utilisent de la mémoire virtuelle comme on a sur nos machines de bureau pour sauvegarder la RAM sur disque et ainsi pouvoir virtuellement utiliser plus de mémoire).
D'ailleurs en particulier sur l'iPhone (pour prendre l'exemple type de système embarqué sur lequel tu peux avoir à faire une interface en Cocoa héhé), non seulement j'ai vu plus d'une fois des cas de ralentissement (voire de crash) pour la seule raison que je ne relâchais pas mes objets assez tôt... (un objet "autorelease" ou marqué collectable (= éligible pour le "garbage collection" est relâché bien plus tard que si tu faisais toi-même un release au moment où n'en avais vraiment plus besoin)... mais en plus sur iPhone il n'y a pas de Garbage Collector (le runtime iPhone de l'implémente pas)
Donc je ne sais pas ce que tu appelles vraiment "système embarqué" mais méfie-toi, le thème de la mémoire n'est pas à prendre à la légère... encore moins sur des systèmes mobiles ou embarqués.
En C, j'ai codé des fonctions pour configurer de tels systèmes. Ces fonctions prennent en compte tout les problèmes de mémoires à l'intérieur du système embarqué. En fait, tout ça c'est mes études et mon boulot, fabriquer des machines autonomes qui effectue une tâche qui peut être n'importe quoi.
Ce que je veux faire c'est au lieu de lancer ces programmes en ligne de commande, je veux coder une application en cocoa qui le fasse à ma place, où tout les paramètres seraient entré par l'utilisateur dans une interface plus pratique.
Dans l'absolue, ça ne m'est pas demandé, mais c'est pour commencer à faire mes propres programmes simples et faciles en cocoa, dans un vrai contexte de programmation.
Je ne crois pas que de tels programmes soit doit d'avoir une gestion critique de leur mémoire.
Vous allez me dire (et vous aurez raison) que ce n'est pas une bonne habitude à prendre, et que je serais largué pour les prochains programmes plus compliqué que je voudrais faire...
Chez moi il est en permanence activé. Je suis prêt à parier que dans quelques années on aura plus a gérer les désallocations, GC sera obligatoire. A part une volonté d'optimisation des performances, je ne vois pas l'intérêt de se compliquer la vie et de laisser la porte ouverte à des fuites de mémoire.
Pour le moment, je n'ai pas eu de soucis mais je ne code pas (avec XCode/Cocoa) depuis très longtemps et en dilettante (trop de boulot par ailleurs, la programmation n'est pas (n'est plus) mon métier).
Je ne pense pas qu'il y aura de nouvelle évolution de l'Objective-C, celle-ci ayant clairement été faite pour " récupérer " des développeurs Java.
Le GC pour moi c'est à vocation "pratique" genre "solution pour se faciliter la vie"... mais ça a été amené à l'Objective-C pour séduire ceux qui viennent de Java ou ont du mal avec la gestion mémoire.
Mais rien ne vaut une bonne base pour savoir gérer la mémoire... En particulier parce que le GC n'est pas toujours aussi efficace, en particulier d'une part libère les objets plus tard que si on les libère à la main, mais de plus nécessite que le GC vérifie tous les éléments créés pour voir s'ils sont encore utilisés... ce qui prend du temps aussi...!
(Pour avoir mis déjà les mains dans le cambouis du moteur javascript SpiderMonkey, avec donc toute une partie de gestion du Garbage-Collector aussi... je peux te dire que les perfs sont parfois dramatiques par rapport à une gestion manuelle...)
Mais surtout quand on voit que par exemple aujourd'hui côté Objective-C, la tendance est plutôt au développement sur iPhone qu'au développement sur Mac.... Or que sur iPhone, mémoire limitée oblige et contraintes de développement mobiles (dont bcp de développeurs iPhone n'ont pas conscience car n'ont jamais développé sur device embarqué), le GC serait une catastrophe... surtout qu'il n'y a pas de swap et de mémoire virtuelle comme sur les ordis (qui est totalement transparente en plus ce qui fait qu'on a l'impression que c'est jamais grave d'avoir une grosse empreinte mémoire...) sur un iPhone...
D'ailleurs pour preuve, Apple ne l'a même pas implémenté le GC sur iPhone !
L'iPhone n'est pas le Mac. Je doute qu'Apple revienne en arrière pour adopter les outils de dev de l'iPhone au Mac. Je pense au contraire que suivant les innovations successives de l'iPhone (CPU plus rapide, plus de mémoire, etc.), les outils se rapprocheront de plus en plus de ceux du Mac.
Cela dit, tu ne fais que souligner mon propos: On utilise pas GC quand on a besoin de performances et que l'on doit économiser les ressources. Pour ma part, je développe des outils de gestion qui interrogent et mettent à jour des bases de données. Le besoin en ressource est quasi nul aussi GC est le bienvenu.
Je maintiens mon pari, GC n'est pas apparu par hasard et une fois qu'on l'utilise, revenir à la préhistoire est très très difficile.
(J'ai l'impression de revivre le débat Vi vs Emacs
Je n'y crois pas trop ... Si tu commences l'Obj-C, je te conseille comme Schlum et Ali de ne pas activer le GC et de régler tout de suite le pb de la gestion de la mémoire. On en prend (assez) vite l'habitude , et c'est une excellente discipline , comme celle de s'inquiéter des warnings qui peuvent cacher de gros bugs ...
Je ne doute pas que vous ayez tous raison. Mais pour le moment ça fonctionne très bien et j'ai d'autres chats à fouetter (j'en suis au drag&drop...)
Non, il est apparu pour faire les yeux doux à la communauté énorme des développeurs Java (ça a assez bien fonctionné d'ailleurs...)
Parler de préhistoire, c'est gonflé :P Je te signale que le C existe encore est est très largement utilisé ! De même que le C++ qui n'a pas de Garbage Collector. Et que le Java et le C# qui en ont un sont des langages avec lesquels on a le plus de problèmes au final avec les gros projets.