[ XPost fco.mac-os.x, fcsm.prog, suivi dans ce dernier ]
Bonjour,
Ca va faire 10 ans que MacOSX est sorti, mais malgré de nombreuses
années passées à coder en C/C++ sur MacOS Prehistoric, je n'ai pas
encore réussi à me mettre à Cocoa. Pour mes besoins, Perl me suffit en
mode texte.
Mais après avoir parcourun une paire de docs "Obective-C pour les
programmeurs C++ expérimentés", j'essaye de m'y mettre.
Je me souviens avoir énormément appris, surtout avec ThinkC et la Think
Class Library, où tout le source était disponible, que ce soit la LibC
ou le Framework. Idem avec Codewarrior.
J'ai pu ainsi développer des programmes assez fouillés, utilisant les
threads, les interruptions sur i/o, etc.
Je n'aurai jamais pu y arriver sans la possibilité de tracer à travers
le code du Framework, c'est instructif au possible. Sans compter que,
comme c'est censé être pas mal codé, on peut y apprendre des techniques
utiles.
Or, en Objective-C, si j'ai bien compris, beaucoup de choses se passent
par l'envoi de messages, et si on sait d'où ils partent, quand c'est son
propre code, c'est impossible de trouver à quel objet ils arrivent, et
ça peut être la mauvaise instance, parce qu'on s'est planté à un
endroit, par ex. Et je n'ai pas trouvé, sans être étonné, parce que ça
n'existe sûrement pas, d'option dans XCode pour fixer un point d'arrêt
"au retour dans mon code".
J'ai eu beau fouiller tout le site Developpeur Apple, je n'ai trouvé
nulle part de bibliothéques de symbololes pour debugger *dans* Cocoa. Il
y a bien des versions Debug des Frameworks, mais pas de symboles de
debug dedans.
J'ai mal cherché, ou bien Cocoa est définitivement "closed source" ?
Merci,
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Le 29/01/11 21:20, Xavier a écrit : J'ai mal cherché, t'as mal cherché, ce n'est pas ce qui manque et même en Français maintenant...
Globalement il y a des émetteurs ce qui ressemble a un appel de fonction, ou encore des sélecteurs (pointeur de fonction) disons une forme un peu différente...
Et des récepteurs qui se chargent de capter les messages.
ou bien Cocoa est définitivement "closed source" ?
Je crois que c'est même Open Source, le nom des classes est très bien définis correspondent assez bien a leurs significations...
Mais nous avons aussi Interface Builder qui fait toute ou partie graphique, certaines applications pouvant même se faire sans une ligne de code...
Le 29/01/11 21:20, Xavier a écrit :
J'ai mal cherché,
t'as mal cherché, ce n'est pas ce qui manque et même en Français
maintenant...
Globalement il y a des émetteurs ce qui ressemble a un appel de
fonction, ou encore des sélecteurs (pointeur de fonction) disons une
forme un peu différente...
Et des récepteurs qui se chargent de capter les messages.
ou bien Cocoa est définitivement "closed source" ?
Je crois que c'est même Open Source, le nom des classes est très bien
définis correspondent assez bien a leurs significations...
Mais nous avons aussi Interface Builder qui fait toute ou partie
graphique, certaines applications pouvant même se faire sans une ligne
de code...
Le 29/01/11 21:20, Xavier a écrit : J'ai mal cherché, t'as mal cherché, ce n'est pas ce qui manque et même en Français maintenant...
Globalement il y a des émetteurs ce qui ressemble a un appel de fonction, ou encore des sélecteurs (pointeur de fonction) disons une forme un peu différente...
Et des récepteurs qui se chargent de capter les messages.
ou bien Cocoa est définitivement "closed source" ?
Je crois que c'est même Open Source, le nom des classes est très bien définis correspondent assez bien a leurs significations...
Mais nous avons aussi Interface Builder qui fait toute ou partie graphique, certaines applications pouvant même se faire sans une ligne de code...
xavier
Aegidius wrote:
t'as mal cherché, ce n'est pas ce qui manque et même en Français maintenant...
Euh... oui, mais où ?
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Aegidius <aegidius@live.fr> wrote:
t'as mal cherché, ce n'est pas ce qui manque et même en Français
maintenant...
Euh... oui, mais où ?
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Il y a longtemps que j'écume tout ça. Je n'ai jamais trouvé ce que je cherche, càd où trouver les versions Debug (celles de XCode n'ont *pas* de symboles) des Frameworks du système...
Mon but est de ne pas me retrouver dans l'hyperespace quand je fais un "Step into" sur
return NSApplicationMain(argc, argv);
Je voudrais, comme je le faisais avec ThinkC et CodeWarrior, tracer, dans ce cas, dans tous les constructeurs avec le code source affiché, pas l'assembleur, évidement. Ce n'est qu'un exemple.
Si tu as plus précis, merci beaucoup.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Aegidius <aegidius@live.fr> wrote:
GG est ton ami taper = "programmation Cocoa"
Il y a longtemps que j'écume tout ça. Je n'ai jamais trouvé ce que je
cherche, càd où trouver les versions Debug (celles de XCode n'ont *pas*
de symboles) des Frameworks du système...
Mon but est de ne pas me retrouver dans l'hyperespace quand je fais un
"Step into" sur
return NSApplicationMain(argc, argv);
Je voudrais, comme je le faisais avec ThinkC et CodeWarrior, tracer,
dans ce cas, dans tous les constructeurs avec le code source affiché,
pas l'assembleur, évidement. Ce n'est qu'un exemple.
Si tu as plus précis, merci beaucoup.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Il y a longtemps que j'écume tout ça. Je n'ai jamais trouvé ce que je cherche, càd où trouver les versions Debug (celles de XCode n'ont *pas* de symboles) des Frameworks du système...
Mon but est de ne pas me retrouver dans l'hyperespace quand je fais un "Step into" sur
return NSApplicationMain(argc, argv);
Je voudrais, comme je le faisais avec ThinkC et CodeWarrior, tracer, dans ce cas, dans tous les constructeurs avec le code source affiché, pas l'assembleur, évidement. Ce n'est qu'un exemple.
Si tu as plus précis, merci beaucoup.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Patrick Stadelmann
In article <1jvww2p.1ldv7lzfujhvyN%, (Xavier) wrote:
Je voudrais, comme je le faisais avec ThinkC et CodeWarrior, tracer, dans ce cas, dans tous les constructeurs avec le code source affiché,
C'est impossible, le code source de Cocoa n'est pas public.
Patrick -- Patrick Stadelmann
In article <1jvww2p.1ldv7lzfujhvyN%xavier@groumpf.org>,
xavier@groumpf.org (Xavier) wrote:
Je voudrais, comme je le faisais avec ThinkC et CodeWarrior, tracer,
dans ce cas, dans tous les constructeurs avec le code source affiché,
C'est impossible, le code source de Cocoa n'est pas public.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
C'est impossible, le code source de Cocoa n'est pas public.
Ah, c'est bien ce que je pensais. Ca simplifie pas le debugging, par rapport à des frameworks Open Source comme Powerplant ou TCL. Dommage.
M'en vais peut-être racheter une licence CodeWarrior et faire du Carbon, à ce compte, j'aime pas les trucs opaques.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Aegidius
Le 30/01/11 22:49, Xavier a écrit :
Patrick Stadelmann wrote:
C'est impossible, le code source de Cocoa n'est pas public.
Ah, c'est bien ce que je pensais. Ca simplifie pas le debugging, par rapport à des frameworks Open Source comme Powerplant ou TCL. Dommage.
M'en vais peut-être racheter une licence CodeWarrior et faire du Carbon, à ce compte, j'aime pas les trucs opaques.
Bein en fait avec Cocoa tu n'as pas vraiment besoin de rentrer dans le code source et développer en Carbon risque quant même d'être un peu mis de coté ensuite, rien de possible pour l'iPhone et l'iPad c'est tout de même un peu dommage.
Les fonctions de base en Cocoa qui ne te conviennent pas tu dérives et basta, ensuit il y a une quantité d'exemples assez impressionnante, ensuite aussi en cas de problèmes sur un appel de fonction Cocoa, les forums ne manque pas et c'est bien rare que la question n'ait pas déjà été posée, sinon généralement dans la 1/2 journée on a une réponse
Le 30/01/11 22:49, Xavier a écrit :
Patrick Stadelmann<Patrick.Stadelmann@unine.ch> wrote:
C'est impossible, le code source de Cocoa n'est pas public.
Ah, c'est bien ce que je pensais. Ca simplifie pas le debugging, par
rapport à des frameworks Open Source comme Powerplant ou TCL. Dommage.
M'en vais peut-être racheter une licence CodeWarrior et faire du Carbon,
à ce compte, j'aime pas les trucs opaques.
Bein en fait avec Cocoa tu n'as pas vraiment besoin de rentrer dans le
code source et développer en Carbon risque quant même d'être un peu mis
de coté ensuite, rien de possible pour l'iPhone et l'iPad c'est tout de
même un peu dommage.
Les fonctions de base en Cocoa qui ne te conviennent pas tu dérives et
basta, ensuit il y a une quantité d'exemples assez impressionnante,
ensuite aussi en cas de problèmes sur un appel de fonction Cocoa, les
forums ne manque pas et c'est bien rare que la question n'ait pas déjà
été posée, sinon généralement dans la 1/2 journée on a une réponse
C'est impossible, le code source de Cocoa n'est pas public.
Ah, c'est bien ce que je pensais. Ca simplifie pas le debugging, par rapport à des frameworks Open Source comme Powerplant ou TCL. Dommage.
M'en vais peut-être racheter une licence CodeWarrior et faire du Carbon, à ce compte, j'aime pas les trucs opaques.
Bein en fait avec Cocoa tu n'as pas vraiment besoin de rentrer dans le code source et développer en Carbon risque quant même d'être un peu mis de coté ensuite, rien de possible pour l'iPhone et l'iPad c'est tout de même un peu dommage.
Les fonctions de base en Cocoa qui ne te conviennent pas tu dérives et basta, ensuit il y a une quantité d'exemples assez impressionnante, ensuite aussi en cas de problèmes sur un appel de fonction Cocoa, les forums ne manque pas et c'est bien rare que la question n'ait pas déjà été posée, sinon généralement dans la 1/2 journée on a une réponse
Patrick Stadelmann
In article <1jvxix3.my5xg71pk062oN%, (Xavier) wrote:
M'en vais peut-être racheter une licence CodeWarrior et faire du Carbon, à ce compte, j'aime pas les trucs opaques.
Carbon est autant opaque que Cocoa.
Patrick -- Patrick Stadelmann
In article <1jvxix3.my5xg71pk062oN%xavier@groumpf.org>,
xavier@groumpf.org (Xavier) wrote:
M'en vais peut-être racheter une licence CodeWarrior et faire du Carbon,
à ce compte, j'aime pas les trucs opaques.
Carbon est autant opaque que Cocoa.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Oui, mais non. Carbon, c'est que des API systèmes, alors que Cocoa c'est tout un tas de frameworks. Pas comparable.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Patrick Stadelmann
In article <1jvz5k8.18geni6xkzi9kN%, (Xavier) wrote:
Patrick Stadelmann wrote:
> Carbon est autant opaque que Cocoa.
Oui, mais non. Carbon, c'est que des API systèmes, alors que Cocoa c'est tout un tas de frameworks. Pas comparable.
Il s'agit de deux niveaux d'abstraction différents, oui. Mais dans les deux cas, le but est d'isoler le développeur des détails d'implémentation. Il y a des milliers de développeurs qui utilisent Cocoa sans jamais avoir eu accès aux sources et qui arrivent tout de même à écrire des applications !
Patrick -- Patrick Stadelmann
In article <1jvz5k8.18geni6xkzi9kN%xavier@groumpf.org>,
xavier@groumpf.org (Xavier) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> Carbon est autant opaque que Cocoa.
Oui, mais non. Carbon, c'est que des API systèmes, alors que Cocoa c'est
tout un tas de frameworks. Pas comparable.
Il s'agit de deux niveaux d'abstraction différents, oui. Mais dans les
deux cas, le but est d'isoler le développeur des détails
d'implémentation. Il y a des milliers de développeurs qui utilisent
Cocoa sans jamais avoir eu accès aux sources et qui arrivent tout de
même à écrire des applications !
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jvz5k8.18geni6xkzi9kN%, (Xavier) wrote:
Patrick Stadelmann wrote:
> Carbon est autant opaque que Cocoa.
Oui, mais non. Carbon, c'est que des API systèmes, alors que Cocoa c'est tout un tas de frameworks. Pas comparable.
Il s'agit de deux niveaux d'abstraction différents, oui. Mais dans les deux cas, le but est d'isoler le développeur des détails d'implémentation. Il y a des milliers de développeurs qui utilisent Cocoa sans jamais avoir eu accès aux sources et qui arrivent tout de même à écrire des applications !
