Ok psychoh13 désolé... J'essaierais de faire attention la prochaine fois... Là j'avoue j'ai le temps pour rien donc j'aurais dû attendre d'avoir un peu plus de temps pour me poser et écrire un truc digne d'être lu...
Cela dit là je dois retourner à mes maths, et le problème ayant été résolu la discussion est close, merci à tous de vous être penchés sur mon problème, et encore merci à Schlum pour l'avoir solutionné si rapidement !
Et pas besoin de runLoop. De plus inutile de mettre des userInfo dans un timer si tu ne les utilises pas; Il faut aussi savoir que l'argument d'une méthode appelée par un timer est un NSTimer, et c'est même le NSTimer qui a fait l'appel.
Bah si quand même :P Sans runLoop, bye bye le timer, le thread se termine une fraction de seconde après son allocation
Schlum relis mon message et surtout le paragraphe précédent celui que tu cites avec le code compris... Tu pourras remarquer que dedans je conseille la suppression pure et simple du NSTimer donc le runLoop devient lui aussi inutile.
À part ça, j'ai un peu bossé sur le code depuis mon premier message jusqu'à maintenant, et j'ai donc pondu un code fonctionnel et pas trop bordelique qui fait supposément la même chose que le tien, à la différence qu'il est lisible, qu'on s'y retrouve dedans, et qu'il exploite au mieux les capacité de Cocoa.
Juges-en par toi-même, je pense que ça t'aidera à faire un peu moins de trucs à l'arrache (le code est commenté pour plus de commodité) :
et bin t'es du genre tenace toi.. Bin écoute merci beaucoup quand même... Quant au timer, il paraà®t évident que dans le code dont j'ai besoin le truc tourne pas "à l'infini" mais doit pouvoir s'arrêter et repartir à la demande... Bref... Le code fourni n'a rien à voir avec ce que j'utilise...
Enfin merci quand même, et j'espère que d'ici une vingtaine d'années tu m'en voudras plus ??
Regarde au moins le code que je t'ai donné... Et si je suis tenace, c'est parce que tu vas nous revenir dans quelques jours pour nous montrer un autre bogue dans ton code et que tu n'arriveras pas à déceler parce que ton code n'est pas du tout organisé... Je préfère prendre les devant... Les mauvaises habitudes se prennent vite.
Sinon ça s'appelle boucle infinie parce que la condition de la boucle c'est "YES", cependant on peut très bien l'arrêter de l'intérieur, et ensuite redémarrer le thread, au final c'est du pareil au même...
Oui oui nan mais je l'ai regardé et le regarderais avec attention d'ailleurs, je reconnais clairement que c'est plus propre que tout ce que j'ai jamais été capable de programmer c'est clair... C'est juste que ça répond pas à la question, je reconnais que je fournis un exemple crade et boiteux et que j'aurais pas dû faire ça, seulement j'ai une autre vie que la programmation (une vie de prépa pour l'instant ) et c'est pas du tout mon boulot, je code de temps en temps pour mon plaisir et pour des trucs dont j'ai besoin ou envie, et ça s'arrête là ... Mais merci pour le code, il est clairement bien foutu y'a rien à dire ;-)
Sans rancune et désolé de m'être énervé, la fatigue on va dire
Je te rassure, il répond quand même à ta question, tu peux y voir dedans l'utilisation de la classe NSLock qui permet donc de protéger des accès concurrentes dans ton code.
Schlum relis mon message et surtout le paragraphe précédent celui que tu cites avec le code compris... Tu pourras remarquer que dedans je conseille la suppression pure et simple du NSTimer donc le runLoop devient lui aussi inutile.
Ouais, enfin ça revient au même, sauf que comme tu disais je ne sais plus où, le NSTimer gère un NSAutoReleasePool automatique que tu n'auras pas en mettant le thread en "sleep". Donc à moins de mettre toi même en place un NSAutoReleasePool dans la boucle, tu risques de faire exploser ta mémoireÂ
Les deux méthodes se valent, je ne pense pas qu'il y en ait une meilleure que l'autre...
Le NSTimer te permet en plus de garantir qu'il y a exécution (dans la mesure du possible) de manière régulière, alors que le "sleep" ne permet pas de savoir tous les combien le truc est lancé (car ne tient pas compte du temps d'exécution du code en lui même). Ou alors il faut calculer la date avant l'exécution, puis déduire d'autant le sleep...
PS : pour faire un sleep, pas la peine d'utiliser le rouleau compresseur en s'embêtant avec une méthode de NSThread et en créant un objet NSDate à calculer en allant chercher la date actuelle et qui en plus surchargera inutilement l'autoReleasePool... Un petit "usleep" et c'est bon :P
Ton "dans la mesure du possible" est tout à fait évocateur, excuse-moi, mais le NSTimer n'a pas plus de garantit que le +sleepUntilDate:. Sinon c'est vrai que c'est énooooooooorme UN objet de plus dans l'autorelease pool qui est supprimé juste après, la mémoire va se casser la gueule avec cette technique, et c'est vrai que c'est de l'artillerie lourde, mon dieu, deux appels de méthodes ! Bientôt tu vas me reprocher de programmer en Objective-C... M'enfin.
Ton "dans la mesure du possible" est tout à fait évocateur, excuse-moi, mais le NSTimer n'a pas plus de garantit que le +sleepUntilDate:. Sinon c'est vrai que c'est énooooooooorme UN objet de plus dans l'autorelease pool qui est supprimé juste après, la mémoire va se casser la gueule avec cette technique, et c'est vrai que c'est de l'artillerie lourde, mon dieu, deux appels de méthodes ! Bientôt tu vas me reprocher de programmer en Objective-C... M'enfin.
Ah oui, NSTimer est plus garanti que sleepUntilDate ça c'est certain... Si tu as un NSTimer appelé toutes les secondes qui fait une action qui dure 0.2 s et que tu passes ça avec un sleep, au bout de 5s tu as un décalage d'une seconde. C'est énorme, en fonction de ce que tu veux faire !
Je ne reproche pas de programmer en Objective-C, je reproche le "tout objet" dans lequel on est tombé et qui est parfois ridicule. Que va faire ton "sleepUntilDate" ? Il va d'abord : 1 - Créer un objet date, l'allouer, l'initialiser 2 - Aller chercher la date actuelle et y ajouter ton offset 3 - Mettre à jour l'objet date 4 - Mettre l'objet date dans l'autoReleasePool 5 - Aller chercher la date actuelle 6 - Calculer combien il y a en microsecondes entre la date du jour et celle qui est dans ton objet date 7 - Appeler "usleep" avec ce nombre de microsecondes 8 - Release de l'objet date plus tard
Alors excuse moi, mais quand je peux zapper 7 étapes sur 8, je le faisÂ
Tu sais, j'ai l'impression que tu le prends mal, mais je dis pas ça pour t'embêter hein... Je parle d'expérience personnelle.
Avant j'étais comme ça, Objective-C à fond... Puis quand j'ai travaillé sur la version Mac de DxO Optics Pro, les vieux développeurs Mac qui travaillaient dans l'équipe se foutaient de ma gueule : - "Ah mais n'utilise pas Cocoa là , CoreGraphics c'est carrément plus efficace" - "Mais non, là utilise la fonction C, ça sert à rien d'utiliser ce wrapper mal foutu" etc...
Du coup, maintenant je regarde avant d'utiliser les techniques Cocoa si c'est du lard ou du cochon. Et parfois je remets en question de grands pans de Cocoa (comme la gestion des NSThread par exemple, cf. ce sujet : http://www.objective-cocoa.org/forum/index.php/topic,2390.0.html )
[...] Du coup, maintenant je regarde avant d'utiliser les techniques Cocoa si c'est du lard ou du cochon. Et parfois je remets en question de grands pans de Cocoa (comme la gestion des NSThread par exemple, cf. ce sujet : http://www.objective-cocoa.org/forum/index.php/topic,2390.0.html )
Je te rejoins.
En fait, Cocoa/Obj-C, c'est idéal pour tout ce qui touche à l'UI et les structures de données gravitant autour. C'est à peu près potable pour ce qui est communication basique (gérer des requêtes ftp ou http).
mais il ne faut pas hésiter à descendre d'un étage lorsqu'il s'agit de trifouiller dans le hard, la mémoire, ou les grosses structures de données. Et heureusement, Mac OSX le permet (CoreFoundation, Carbon, IOKit).
Merci de te pencher sur mon problème en tout cas, mais je pense qu'il faut chercher plus basique, j'ai jamais réellement bien saisi comment fonctionne l'allocation mémoire, et visiblement je dois mal gérer l'objet thePath1.... Et ça doit être lié au fait que c'est dans un nouveau NSThread parce qu'il n'y a pas de problème dans le cas contraire...
Réponses
Cela dit là je dois retourner à mes maths, et le problème ayant été résolu la discussion est close, merci à tous de vous être penchés sur mon problème, et encore merci à Schlum pour l'avoir solutionné si rapidement !
Bah si quand même :P
Sans runLoop, bye bye le timer, le thread se termine une fraction de seconde après son allocation
Tu pourras remarquer que dedans je conseille la suppression pure et simple du NSTimer donc le runLoop devient lui aussi inutile.
À part ça, j'ai un peu bossé sur le code depuis mon premier message jusqu'à maintenant, et j'ai donc pondu un code fonctionnel et pas trop bordelique qui fait supposément la même chose que le tien, à la différence qu'il est lisible, qu'on s'y retrouve dedans, et qu'il exploite au mieux les capacité de Cocoa.
Juges-en par toi-même, je pense que ça t'aidera à faire un peu moins de trucs à l'arrache (le code est commenté pour plus de commodité) :
[Fichier joint supprimé par l'administrateur]
Enfin merci quand même, et j'espère que d'ici une vingtaine d'années tu m'en voudras plus ??
^^
Et si je suis tenace, c'est parce que tu vas nous revenir dans quelques jours pour nous montrer un autre bogue dans ton code et que tu n'arriveras pas à déceler parce que ton code n'est pas du tout organisé... Je préfère prendre les devant... Les mauvaises habitudes se prennent vite.
Sinon ça s'appelle boucle infinie parce que la condition de la boucle c'est "YES", cependant on peut très bien l'arrêter de l'intérieur, et ensuite redémarrer le thread, au final c'est du pareil au même...
Sans rancune et désolé de m'être énervé, la fatigue on va dire
Ouais, enfin ça revient au même, sauf que comme tu disais je ne sais plus où, le NSTimer gère un NSAutoReleasePool automatique que tu n'auras pas en mettant le thread en "sleep".
Donc à moins de mettre toi même en place un NSAutoReleasePool dans la boucle, tu risques de faire exploser ta mémoireÂ
Les deux méthodes se valent, je ne pense pas qu'il y en ait une meilleure que l'autre...
Le NSTimer te permet en plus de garantir qu'il y a exécution (dans la mesure du possible) de manière régulière, alors que le "sleep" ne permet pas de savoir tous les combien le truc est lancé (car ne tient pas compte du temps d'exécution du code en lui même).
Ou alors il faut calculer la date avant l'exécution, puis déduire d'autant le sleep...
PS : pour faire un sleep, pas la peine d'utiliser le rouleau compresseur en s'embêtant avec une méthode de NSThread et en créant un objet NSDate à calculer en allant chercher la date actuelle et qui en plus surchargera inutilement l'autoReleasePool...
Un petit "usleep" et c'est bon :P
Ah oui, NSTimer est plus garanti que sleepUntilDate ça c'est certain...
Si tu as un NSTimer appelé toutes les secondes qui fait une action qui dure 0.2 s et que tu passes ça avec un sleep, au bout de 5s tu as un décalage d'une seconde. C'est énorme, en fonction de ce que tu veux faire !
Je ne reproche pas de programmer en Objective-C, je reproche le "tout objet" dans lequel on est tombé et qui est parfois ridicule.
Que va faire ton "sleepUntilDate" ? Il va d'abord :
1 - Créer un objet date, l'allouer, l'initialiser
2 - Aller chercher la date actuelle et y ajouter ton offset
3 - Mettre à jour l'objet date
4 - Mettre l'objet date dans l'autoReleasePool
5 - Aller chercher la date actuelle
6 - Calculer combien il y a en microsecondes entre la date du jour et celle qui est dans ton objet date
7 - Appeler "usleep" avec ce nombre de microsecondes
8 - Release de l'objet date plus tard
Alors excuse moi, mais quand je peux zapper 7 étapes sur 8, je le faisÂ
Je parle d'expérience personnelle.
Avant j'étais comme ça, Objective-C à fond...
Puis quand j'ai travaillé sur la version Mac de DxO Optics Pro, les vieux développeurs Mac qui travaillaient dans l'équipe se foutaient de ma gueule :
- "Ah mais n'utilise pas Cocoa là , CoreGraphics c'est carrément plus efficace"
- "Mais non, là utilise la fonction C, ça sert à rien d'utiliser ce wrapper mal foutu"
etc...
Du coup, maintenant je regarde avant d'utiliser les techniques Cocoa si c'est du lard ou du cochon. Et parfois je remets en question de grands pans de Cocoa (comme la gestion des NSThread par exemple, cf. ce sujet :
http://www.objective-cocoa.org/forum/index.php/topic,2390.0.html )
Je te rejoins.
En fait, Cocoa/Obj-C, c'est idéal pour tout ce qui touche à l'UI et les structures de données gravitant autour.
C'est à peu près potable pour ce qui est communication basique (gérer des requêtes ftp ou http).
mais il ne faut pas hésiter à descendre d'un étage lorsqu'il s'agit de trifouiller dans le hard, la mémoire, ou les grosses structures de données.
Et heureusement, Mac OSX le permet (CoreFoundation, Carbon, IOKit).
.