donc comme mon extension C pour Ruby retourne un objet ruby je souhaite
ajouter, par exemple une fonction du type "errno" et une autre "errmsg"
cette dernière donnant - en clair - le mesage d'erreur en anglais (je
n'envisage pas d'internationalisation).
y a t'il un tuto qqpart sur ce sujet ?
des gaffes à éviter ?
dans ce cas j'envoie sur stderr un message en clair.
Et bien dans ce cas, fais que ta fonction retourne ton objet ruby, et en cas d'erreur : - retourne Qnil - positionne une variable globale avec un code d'erreur (mais pas errno, comme dit par d'autres, c'est réservé par stdlib)
Ok. tu as raison. Y'a déjà assez d'embrouillamini avec errno comme ça. Le plus simple est de lever une exception qui est traitée plus bas dans le stack. Si on n'a pas l'API pour, on peut de débrouiller avec setjump/longjump.
- il te faut aussi une petite fonction, qui, en fonction du code d'erreur, retourne une chaîne de caractères contenant le message d'erreur adéquat,
Là tu fignoles, mais bon tu as raison dans le cas d'un vrai programme C.
A partir de là tu embrouilles tout le monde : tu commences à penser en Ruby à haute voix, alors qu'ici on ne sait parler que le C ... :)
A ce sujet, fr.comp.lang.general (forum trop méconnu) accueille en ce moment des conversations et joutes diverses entre Ruby, Python et Simple (un nouveau langage qui mérite vos avis). Je suggère un FU2 vers fclg pour ne pas déborder fclc. Les fclceurs reviennent de vacance et tiennent à retrouver leur forum dns l'état où ils l'ont laissé.
Il parait même que Emdel va faire son come-back.
-- http://patrick.davalan.free.fr/
Hamiral wrote:
dans ce cas j'envoie sur stderr un message en clair.
Et bien dans ce cas, fais que ta fonction retourne ton objet ruby, et
en cas d'erreur :
- retourne Qnil
- positionne une variable globale avec un code d'erreur (mais pas
errno, comme dit par d'autres, c'est réservé par stdlib)
Ok. tu as raison. Y'a déjà assez d'embrouillamini avec errno comme ça.
Le plus simple est de lever une exception qui est traitée plus bas dans
le stack. Si on n'a pas l'API pour, on peut de débrouiller avec
setjump/longjump.
- il te faut aussi une petite fonction, qui, en fonction du code
d'erreur, retourne une chaîne de caractères contenant le message
d'erreur adéquat,
Là tu fignoles, mais bon tu as raison dans le cas d'un vrai programme C.
A partir de là tu embrouilles tout le monde : tu commences à penser en
Ruby à haute voix, alors qu'ici on ne sait parler que le C ... :)
A ce sujet, fr.comp.lang.general (forum trop méconnu) accueille en ce
moment des conversations et joutes diverses entre Ruby, Python et
Simple (un nouveau langage qui mérite vos avis).
Je suggère un FU2 vers fclg pour ne pas déborder fclc. Les fclceurs
reviennent de vacance et tiennent à retrouver leur forum dns l'état où
ils l'ont laissé.
dans ce cas j'envoie sur stderr un message en clair.
Et bien dans ce cas, fais que ta fonction retourne ton objet ruby, et en cas d'erreur : - retourne Qnil - positionne une variable globale avec un code d'erreur (mais pas errno, comme dit par d'autres, c'est réservé par stdlib)
Ok. tu as raison. Y'a déjà assez d'embrouillamini avec errno comme ça. Le plus simple est de lever une exception qui est traitée plus bas dans le stack. Si on n'a pas l'API pour, on peut de débrouiller avec setjump/longjump.
- il te faut aussi une petite fonction, qui, en fonction du code d'erreur, retourne une chaîne de caractères contenant le message d'erreur adéquat,
Là tu fignoles, mais bon tu as raison dans le cas d'un vrai programme C.
A partir de là tu embrouilles tout le monde : tu commences à penser en Ruby à haute voix, alors qu'ici on ne sait parler que le C ... :)
A ce sujet, fr.comp.lang.general (forum trop méconnu) accueille en ce moment des conversations et joutes diverses entre Ruby, Python et Simple (un nouveau langage qui mérite vos avis). Je suggère un FU2 vers fclg pour ne pas déborder fclc. Les fclceurs reviennent de vacance et tiennent à retrouver leur forum dns l'état où ils l'ont laissé.
Il parait même que Emdel va faire son come-back.
-- http://patrick.davalan.free.fr/
pere.noel
Eric Levenez wrote:
Je suis largué sur ce que tu veux faire.
c'est simple, prenons le problème "à l'envers".
je souhaite qu'en Ruby un utilisateur puisse appeller certaines fonctions de Carbon.framework et CoreFoundation.framework celles qu'utilise l'Alias Manager et plus spécifiquement encore celles relatives aux Alias Records.
but de la manip : laisser l'utilisateur final placer et déplacer|renommer ces fichiers comme il veut sans que l'appli écrite en Ruby les perde de vue.
MAIS je ne souhaite pas qu'il ait à comprendre (sauf s'il le souhaite) les mécanismes utilisés par "mac OS X" (pour faire court).
-- une bévue
Eric Levenez <news@levenez.com> wrote:
Je suis largué sur ce que tu veux faire.
c'est simple, prenons le problème "à l'envers".
je souhaite qu'en Ruby un utilisateur puisse appeller certaines
fonctions de Carbon.framework et CoreFoundation.framework celles
qu'utilise l'Alias Manager et plus spécifiquement encore celles
relatives aux Alias Records.
but de la manip : laisser l'utilisateur final placer et
déplacer|renommer ces fichiers comme il veut sans que l'appli écrite en
Ruby les perde de vue.
MAIS je ne souhaite pas qu'il ait à comprendre (sauf s'il le souhaite)
les mécanismes utilisés par "mac OS X" (pour faire court).
je souhaite qu'en Ruby un utilisateur puisse appeller certaines fonctions de Carbon.framework et CoreFoundation.framework celles qu'utilise l'Alias Manager et plus spécifiquement encore celles relatives aux Alias Records.
but de la manip : laisser l'utilisateur final placer et déplacer|renommer ces fichiers comme il veut sans que l'appli écrite en Ruby les perde de vue.
MAIS je ne souhaite pas qu'il ait à comprendre (sauf s'il le souhaite) les mécanismes utilisés par "mac OS X" (pour faire court).
-- une bévue
pere.noel
Hamiral wrote:
Et bien dans ce cas, fais que ta fonction retourne ton objet ruby, et en cas d'erreur : - retourne Qnil - positionne une variable globale avec un code d'erreur (mais pas errno, comme dit par d'autres, c'est réservé par stdlib) - il te faut aussi une petite fonction, qui, en fonction du code d'erreur, retourne une chaîne de caractères contenant le message d'erreur adéquat, mais ne l'affiche pas, en effet ce n'est pas aux fonctions utilitaires de faire cela. Tu peux être amené à vouloir afficher ce message d'erreur dans une boîte de dialogue plutôt que sur stdout ou stderr par exemple ...
ok, pas de pb c'est clair avec Qnil (pas d'alloc memoire) je garantis le fait qu'un utilisateur ne pourra aller plus loin. si un des paramètres d'entrée n'est pas adéquat (par ex nom d'un fichier inexistant sur le file system) ce n'est pas de ma responsabilité, j'ai juste à lui signaler ce que je fais déjà par la méthode "#path_exists?".
dans les autres cas le prog se termine normalement avec un errno != 0 et un errmsg.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans le file system me pose problème.
A partir de là tu embrouilles tout le monde : tu commences à penser en Ruby à haute voix, alors qu'ici on ne sait parler que le C ... :)
ben oui c'est le pb, je suis guidé par l'utilisation que je fais de C . -- une bévue
Hamiral <hamiral@hamham.fr> wrote:
Et bien dans ce cas, fais que ta fonction retourne ton objet ruby, et en cas
d'erreur :
- retourne Qnil
- positionne une variable globale avec un code d'erreur (mais pas errno,
comme dit par d'autres, c'est réservé par stdlib)
- il te faut aussi une petite fonction, qui, en fonction du code d'erreur,
retourne une chaîne de caractères contenant le message d'erreur adéquat,
mais ne l'affiche pas, en effet ce n'est pas aux fonctions utilitaires de
faire cela. Tu peux être amené à vouloir afficher ce message d'erreur dans
une boîte de dialogue plutôt que sur stdout ou stderr par exemple ...
ok, pas de pb c'est clair avec Qnil (pas d'alloc memoire) je garantis le
fait qu'un utilisateur ne pourra aller plus loin. si un des paramètres
d'entrée n'est pas adéquat (par ex nom d'un fichier inexistant sur le
file system) ce n'est pas de ma responsabilité, j'ai juste à lui
signaler ce que je fais déjà par la méthode "#path_exists?".
dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.
A partir de là tu embrouilles tout le monde : tu commences à penser en Ruby
à haute voix, alors qu'ici on ne sait parler que le C ... :)
ben oui c'est le pb, je suis guidé par l'utilisation que je fais de C .
--
une bévue
Et bien dans ce cas, fais que ta fonction retourne ton objet ruby, et en cas d'erreur : - retourne Qnil - positionne une variable globale avec un code d'erreur (mais pas errno, comme dit par d'autres, c'est réservé par stdlib) - il te faut aussi une petite fonction, qui, en fonction du code d'erreur, retourne une chaîne de caractères contenant le message d'erreur adéquat, mais ne l'affiche pas, en effet ce n'est pas aux fonctions utilitaires de faire cela. Tu peux être amené à vouloir afficher ce message d'erreur dans une boîte de dialogue plutôt que sur stdout ou stderr par exemple ...
ok, pas de pb c'est clair avec Qnil (pas d'alloc memoire) je garantis le fait qu'un utilisateur ne pourra aller plus loin. si un des paramètres d'entrée n'est pas adéquat (par ex nom d'un fichier inexistant sur le file system) ce n'est pas de ma responsabilité, j'ai juste à lui signaler ce que je fais déjà par la méthode "#path_exists?".
dans les autres cas le prog se termine normalement avec un errno != 0 et un errmsg.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans le file system me pose problème.
A partir de là tu embrouilles tout le monde : tu commences à penser en Ruby à haute voix, alors qu'ici on ne sait parler que le C ... :)
ben oui c'est le pb, je suis guidé par l'utilisation que je fais de C . -- une bévue
pere.noel
Eric Levenez wrote:
exact car ce que retourne ma fonction c'est un instance d'objet ruby ça me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer d'utiliser cette instance d'objet.
Donc tu parles du code d'erreur d'une fonction C, et pas d'un programme.
Ok alors il y a différentes traditions. Voici quelques exemples
Si une fonction retourne un entier, alors une valeur particulière indique une erreur (genre 0 ou -1) et les autres une valeur normale.
Si une fonction doit retourner un pointeur, alors elle retourne NULL en cas d'erreur et une autre valeur en cas de succès.
Les fonctions systèmes retournent typiquement -1 en cas d'erreur et positionnent une variable globale errno qui est positionnée en cas d'erreur (variable pas touchée si fonction ok). Il est de tradition aussi de ne jamais faire une fonction utilisateur sur ce principe. En fait errno n'est pas forcément une variable, cela peut être une fonction, une macro, une expression... Donc on laisse le système s'occupé de errno
Pour les fonctions utilisateurs, au lieu de coder dans le code de retour une erreur et une valeur, on utilise de plus en plus un code du type :
int fct(int in1, char *in2, int *out1, char **out2);
La fonction a 2 paramètres en sorties que la fonction initialisera. Ils sont donc passés par des pointeurs. La fonction retourne juste 0 ou 1 pour indiquer qu'elle s'est bien passée ou non. Les valeurs retournées sont dans des pointeurs.
dans ce cas j'envoie sur stderr un message en clair.
Oui, une fonction peut afficher sur stderr un message d'erreur, mais une fonction générique n'affiche rien. C'est le programme appelant qui fait l'affichage;
OK, merci beaucoup c'est clair pour moi, ça me paraît logique tout ça.
dans les autres cas le prog se termine normalement avec un errno != 0 et un errmsg.
Un programme ? Mais je croyais que tu parlais de fonction. :-/
"errno" est normalement réservé aux fonctions systèmes.
ok je changerai le nom de cette fonction, ce n'est pas un prog mais une fonction, je b'ai que des fonctions dans mon source C.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans le file system me pose problème.
en fait dans mon prog C je n'ai qu'une fonction "réelle" les autres
Je comprends plus rien. Maintenant tu parles _vraiment_ d'un programme :-/
non quand je dis programme ici c'est l'ensemble de mes fonctions, en fait ce n'est pas un "programme" du tout, s'il y a prog ça situerait au niveau ruby pas en C.
étant des setters|getters (come on dit en Java) qu'on ne peut utiliser qu'à condition d'avoir retourné un objet non null (Qnil en C ext to ruby). je n'ai qu'une méthode singleton c'est #version.
La tu parles de méthode. C'est une "fonction" l'Objective-C ou autre ou est-ce vraiment un programme ?
côté C je n'ai QUE des fonctions MAIS avec la magie de l'extension C définie dans <Ruby.h> avec UNE de ces fonctions C je réalise * en Ruby * une classe dont j'instancie un objet, les autres fonctions C étant toutes, sauf une, des méthodes d'instance de classe, la seule méthode de classe, singleton, est celle qui donne la version de mon extension.
donc (je réfléchis tout haut)
Oui, je vois bien que tout n'est pas clair et que si tu construisait d'abord clairement ta question, la réponse que nous pourrions te donner serait plus claire elle-aussi.
dans le cas d'un path inexistant, je peux retourner un objet + un message d'erreur sur stderr car je souhaite avoir le moins possible de sortie bloquante par exit(1).
Exit c'est pour sortir d'un programme, pas d'une fonction.
OK, merci c'est très clair ça, c'est d'ailleurs ce que j'avais "intuité"...
-- une bévue
Eric Levenez <news@levenez.com> wrote:
exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.
Donc tu parles du code d'erreur d'une fonction C, et pas d'un programme.
Ok alors il y a différentes traditions. Voici quelques exemples
Si une fonction retourne un entier, alors une valeur particulière indique
une erreur (genre 0 ou -1) et les autres une valeur normale.
Si une fonction doit retourner un pointeur, alors elle retourne NULL en cas
d'erreur et une autre valeur en cas de succès.
Les fonctions systèmes retournent typiquement -1 en cas d'erreur et
positionnent une variable globale errno qui est positionnée en cas d'erreur
(variable pas touchée si fonction ok). Il est de tradition aussi de ne
jamais faire une fonction utilisateur sur ce principe. En fait errno n'est
pas forcément une variable, cela peut être une fonction, une macro, une
expression... Donc on laisse le système s'occupé de errno
Pour les fonctions utilisateurs, au lieu de coder dans le code de retour une
erreur et une valeur, on utilise de plus en plus un code du type :
int fct(int in1, char *in2, int *out1, char **out2);
La fonction a 2 paramètres en sorties que la fonction initialisera. Ils sont
donc passés par des pointeurs. La fonction retourne juste 0 ou 1 pour
indiquer qu'elle s'est bien passée ou non. Les valeurs retournées sont dans
des pointeurs.
dans ce cas j'envoie sur stderr un message en clair.
Oui, une fonction peut afficher sur stderr un message d'erreur, mais une
fonction générique n'affiche rien. C'est le programme appelant qui fait
l'affichage;
OK, merci beaucoup c'est clair pour moi, ça me paraît logique tout ça.
dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.
Un programme ? Mais je croyais que tu parlais de fonction. :-/
"errno" est normalement réservé aux fonctions systèmes.
ok je changerai le nom de cette fonction, ce n'est pas un prog mais une
fonction, je b'ai que des fonctions dans mon source C.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.
en fait dans mon prog C je n'ai qu'une fonction "réelle" les autres
Je comprends plus rien. Maintenant tu parles _vraiment_ d'un programme :-/
non quand je dis programme ici c'est l'ensemble de mes fonctions, en
fait ce n'est pas un "programme" du tout, s'il y a prog ça situerait au
niveau ruby pas en C.
étant des setters|getters (come on dit en Java) qu'on ne peut utiliser
qu'à condition d'avoir retourné un objet non null (Qnil en C ext to
ruby). je n'ai qu'une méthode singleton c'est #version.
La tu parles de méthode. C'est une "fonction" l'Objective-C ou autre ou
est-ce vraiment un programme ?
côté C je n'ai QUE des fonctions MAIS avec la magie de l'extension C
définie dans <Ruby.h> avec UNE de ces fonctions C je réalise * en Ruby *
une classe dont j'instancie un objet, les autres fonctions C étant
toutes, sauf une, des méthodes d'instance de classe, la seule méthode de
classe, singleton, est celle qui donne la version de mon extension.
donc (je réfléchis tout haut)
Oui, je vois bien que tout n'est pas clair et que si tu construisait d'abord
clairement ta question, la réponse que nous pourrions te donner serait plus
claire elle-aussi.
dans le cas d'un path inexistant, je peux
retourner un objet + un message d'erreur sur stderr car je souhaite
avoir le moins possible de sortie bloquante par exit(1).
Exit c'est pour sortir d'un programme, pas d'une fonction.
OK, merci c'est très clair ça, c'est d'ailleurs ce que j'avais
"intuité"...
exact car ce que retourne ma fonction c'est un instance d'objet ruby ça me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer d'utiliser cette instance d'objet.
Donc tu parles du code d'erreur d'une fonction C, et pas d'un programme.
Ok alors il y a différentes traditions. Voici quelques exemples
Si une fonction retourne un entier, alors une valeur particulière indique une erreur (genre 0 ou -1) et les autres une valeur normale.
Si une fonction doit retourner un pointeur, alors elle retourne NULL en cas d'erreur et une autre valeur en cas de succès.
Les fonctions systèmes retournent typiquement -1 en cas d'erreur et positionnent une variable globale errno qui est positionnée en cas d'erreur (variable pas touchée si fonction ok). Il est de tradition aussi de ne jamais faire une fonction utilisateur sur ce principe. En fait errno n'est pas forcément une variable, cela peut être une fonction, une macro, une expression... Donc on laisse le système s'occupé de errno
Pour les fonctions utilisateurs, au lieu de coder dans le code de retour une erreur et une valeur, on utilise de plus en plus un code du type :
int fct(int in1, char *in2, int *out1, char **out2);
La fonction a 2 paramètres en sorties que la fonction initialisera. Ils sont donc passés par des pointeurs. La fonction retourne juste 0 ou 1 pour indiquer qu'elle s'est bien passée ou non. Les valeurs retournées sont dans des pointeurs.
dans ce cas j'envoie sur stderr un message en clair.
Oui, une fonction peut afficher sur stderr un message d'erreur, mais une fonction générique n'affiche rien. C'est le programme appelant qui fait l'affichage;
OK, merci beaucoup c'est clair pour moi, ça me paraît logique tout ça.
dans les autres cas le prog se termine normalement avec un errno != 0 et un errmsg.
Un programme ? Mais je croyais que tu parlais de fonction. :-/
"errno" est normalement réservé aux fonctions systèmes.
ok je changerai le nom de cette fonction, ce n'est pas un prog mais une fonction, je b'ai que des fonctions dans mon source C.
le cas où l'utilisateur a entré un path inexistant "physiquement" dans le file system me pose problème.
en fait dans mon prog C je n'ai qu'une fonction "réelle" les autres
Je comprends plus rien. Maintenant tu parles _vraiment_ d'un programme :-/
non quand je dis programme ici c'est l'ensemble de mes fonctions, en fait ce n'est pas un "programme" du tout, s'il y a prog ça situerait au niveau ruby pas en C.
étant des setters|getters (come on dit en Java) qu'on ne peut utiliser qu'à condition d'avoir retourné un objet non null (Qnil en C ext to ruby). je n'ai qu'une méthode singleton c'est #version.
La tu parles de méthode. C'est une "fonction" l'Objective-C ou autre ou est-ce vraiment un programme ?
côté C je n'ai QUE des fonctions MAIS avec la magie de l'extension C définie dans <Ruby.h> avec UNE de ces fonctions C je réalise * en Ruby * une classe dont j'instancie un objet, les autres fonctions C étant toutes, sauf une, des méthodes d'instance de classe, la seule méthode de classe, singleton, est celle qui donne la version de mon extension.
donc (je réfléchis tout haut)
Oui, je vois bien que tout n'est pas clair et que si tu construisait d'abord clairement ta question, la réponse que nous pourrions te donner serait plus claire elle-aussi.
dans le cas d'un path inexistant, je peux retourner un objet + un message d'erreur sur stderr car je souhaite avoir le moins possible de sortie bloquante par exit(1).
Exit c'est pour sortir d'un programme, pas d'une fonction.
OK, merci c'est très clair ça, c'est d'ailleurs ce que j'avais "intuité"...
