A supposer qu'une entreprise veuille mettre son parc sous Linux.
Et qu'elle reçoive des documents venant d'Access, Excel,... peut-elle
les lire , les travailler et les renvoyer de manière que le
destinantaire sur produits Microsoft puisse les lire, etc...
?
"Manuel Leclerc" , dans le message <40e28c71$, a écrit :
Bien sûr, mais la question n'est pas là. La question est : le programme va-t-il exécuter les instructions indiquées dans le source, ou va-t-il faire N'IMPORTE QUOI ?
Il va exécuter les instructions indiquées, évidemment.
"Manuel Leclerc" , dans le message <40e28c71$1@neottia.net>, a écrit :
Bien sûr, mais la question n'est pas là. La question est : le
programme va-t-il exécuter les instructions indiquées dans le
source, ou va-t-il faire N'IMPORTE QUOI ?
Il va exécuter les instructions indiquées, évidemment.
"Manuel Leclerc" , dans le message <40e28c71$, a écrit :
Bien sûr, mais la question n'est pas là. La question est : le programme va-t-il exécuter les instructions indiquées dans le source, ou va-t-il faire N'IMPORTE QUOI ?
Il va exécuter les instructions indiquées, évidemment.
george
"remy" , dans le message <cbtrd4$fs1$, a écrit :
cela cree une liste chaine de pointeur sur la structure de depart
Ce n'est pas le cas.
et franchement les quelques milli secondes que je perds ou que je gagne ne me pertube pas si je veux un code qui bouste je ne prends pas java
En l'occurence, ça peut être plusieurs minutes, plusieurs heures, selon comment c'est utilisé.
"remy" , dans le message <cbtrd4$fs1$1@news-reader3.wanadoo.fr>, a
écrit :
cela cree une liste chaine de pointeur sur la structure de depart
Ce n'est pas le cas.
et franchement les quelques milli secondes que je perds ou que je gagne
ne me pertube pas si je veux un code qui bouste je ne prends pas java
En l'occurence, ça peut être plusieurs minutes, plusieurs heures, selon
comment c'est utilisé.
La réponse est dans <cbrt68$hnb$, on tourne en rond.
george
JKB , dans le message , a écrit :
Non. C'est un peu le même argument que celui qui consiste à prétendre que l'écriture arabe ressemble à un plat de nouilles car on ne sait pas la lire. Donc mauvais argument, changer d'argument.
Pas du tout, il y a une vraie notion qui explique la meilleure lisibilité de l'infixe : les arguments sont plus regroupés près de l'opérateur.
Comme à une expression algébrique d'ailleurs : 'g(x)' est-elle une fonction ou simplement le x-ième élément du vecteur g ?
Ça, c'est un mauvais argument : fondamentalement, c'est la même chose.
JKB , dans le message <slrnce53lj.285.bertrand@grossebaf.systella.fr>, a
écrit :
Non. C'est un peu le même argument que celui qui consiste à
prétendre que l'écriture arabe ressemble à un plat de nouilles car
on ne sait pas la lire. Donc mauvais argument, changer d'argument.
Pas du tout, il y a une vraie notion qui explique la meilleure
lisibilité de l'infixe : les arguments sont plus regroupés près de
l'opérateur.
Comme à une expression algébrique d'ailleurs : 'g(x)' est-elle une
fonction ou simplement le x-ième élément du vecteur g ?
Ça, c'est un mauvais argument : fondamentalement, c'est la même chose.
Non. C'est un peu le même argument que celui qui consiste à prétendre que l'écriture arabe ressemble à un plat de nouilles car on ne sait pas la lire. Donc mauvais argument, changer d'argument.
Pas du tout, il y a une vraie notion qui explique la meilleure lisibilité de l'infixe : les arguments sont plus regroupés près de l'opérateur.
Comme à une expression algébrique d'ailleurs : 'g(x)' est-elle une fonction ou simplement le x-ième élément du vecteur g ?
Ça, c'est un mauvais argument : fondamentalement, c'est la même chose.
JKB
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
"Manuel Leclerc" , dans le message <40e28c71$, a écrit :
Bien sûr, mais la question n'est pas là. La question est : le programme va-t-il exécuter les instructions indiquées dans le source, ou va-t-il faire N'IMPORTE QUOI ?
Il va exécuter les instructions indiquées, évidemment.
Non. Mais ce serait trop long à expliquer ici, il faudrait rentrer dans le détail des architectures et des passages de paramètres, distinguer les compilateurs qui mettent tout en vrac de ceux qui ne mélangent pas les instructions et les données...
Comme il va vous falloir une exemple ;-)
J'ai cherché pendant deux ans (!) un bug à la turc sur une sparc32. Les appels aux routines se font pas rotations de registres (c'est un SSparc, donc les i0-i7 deviennet oO-o7... Enfin, un RISC...). Le truc perdait un registre dans la rotation (i6 pour ne pas le nommer) et exécutait dans l'appel de la fonction n'importe quoi (le même code sur i386 plantait lamentablement). Lorsque je dis n'importe quoi, cela veut dire que les instructions de ma fonction de calcul n'était pas exécutées, mais que le retour se faisait tout de même en renvoyant une valeur qui n'était pas n'importe quoi pour la fonction effectivement exécutée. J'ai tout mis en cause, donné le code au support de Sun en me disant qu'il y avait un bug dans la fenêtre de pile du SSaprc-II, utilisé des compilos différents avec le même résultat. Au bout de 2 ans, je suis tombé par hasard sur la source du problème, une chaîne allouée au vol en oubliant le 0xO final. Moralité, un bug à l'autre bout du programme dans une fonction qui n'a rien à voir peut provoquer en C du fait même du langage des dysfonctionnements à l'autre bout du code, voire l'exécution de n'importe quoi (c'est entre nous une des grandes failles des OS écrits en C par des pieds gauches).
JKB
Le 30-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
"Manuel Leclerc" , dans le message <40e28c71$1@neottia.net>, a écrit :
Bien sûr, mais la question n'est pas là. La question est : le
programme va-t-il exécuter les instructions indiquées dans le
source, ou va-t-il faire N'IMPORTE QUOI ?
Il va exécuter les instructions indiquées, évidemment.
Non. Mais ce serait trop long à expliquer ici, il faudrait rentrer
dans le détail des architectures et des passages de paramètres,
distinguer les compilateurs qui mettent tout en vrac de ceux qui ne
mélangent pas les instructions et les données...
Comme il va vous falloir une exemple ;-)
J'ai cherché pendant deux ans (!) un bug à la turc sur une sparc32.
Les appels aux routines se font pas rotations de registres (c'est un
SSparc, donc les i0-i7 deviennet oO-o7... Enfin, un RISC...). Le
truc perdait un registre dans la rotation (i6 pour ne pas le
nommer) et exécutait dans l'appel de la fonction n'importe quoi (le
même code sur i386 plantait lamentablement). Lorsque je dis
n'importe quoi, cela veut dire que les instructions de ma fonction
de calcul n'était pas exécutées, mais que le retour se faisait tout
de même en renvoyant une valeur qui n'était pas n'importe quoi pour
la fonction effectivement exécutée. J'ai tout mis en cause, donné le
code au support de Sun en me disant qu'il y avait un bug dans la
fenêtre de pile du SSaprc-II, utilisé des compilos différents avec le
même résultat. Au bout de 2 ans, je suis tombé par hasard sur la
source du problème, une chaîne allouée au vol en oubliant le 0xO
final. Moralité, un bug à l'autre bout du programme dans une
fonction qui n'a rien à voir peut provoquer en C du fait même du
langage des dysfonctionnements à l'autre bout du code, voire
l'exécution de n'importe quoi (c'est entre nous une des grandes
failles des OS écrits en C par des pieds gauches).
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
"Manuel Leclerc" , dans le message <40e28c71$, a écrit :
Bien sûr, mais la question n'est pas là. La question est : le programme va-t-il exécuter les instructions indiquées dans le source, ou va-t-il faire N'IMPORTE QUOI ?
Il va exécuter les instructions indiquées, évidemment.
Non. Mais ce serait trop long à expliquer ici, il faudrait rentrer dans le détail des architectures et des passages de paramètres, distinguer les compilateurs qui mettent tout en vrac de ceux qui ne mélangent pas les instructions et les données...
Comme il va vous falloir une exemple ;-)
J'ai cherché pendant deux ans (!) un bug à la turc sur une sparc32. Les appels aux routines se font pas rotations de registres (c'est un SSparc, donc les i0-i7 deviennet oO-o7... Enfin, un RISC...). Le truc perdait un registre dans la rotation (i6 pour ne pas le nommer) et exécutait dans l'appel de la fonction n'importe quoi (le même code sur i386 plantait lamentablement). Lorsque je dis n'importe quoi, cela veut dire que les instructions de ma fonction de calcul n'était pas exécutées, mais que le retour se faisait tout de même en renvoyant une valeur qui n'était pas n'importe quoi pour la fonction effectivement exécutée. J'ai tout mis en cause, donné le code au support de Sun en me disant qu'il y avait un bug dans la fenêtre de pile du SSaprc-II, utilisé des compilos différents avec le même résultat. Au bout de 2 ans, je suis tombé par hasard sur la source du problème, une chaîne allouée au vol en oubliant le 0xO final. Moralité, un bug à l'autre bout du programme dans une fonction qui n'a rien à voir peut provoquer en C du fait même du langage des dysfonctionnements à l'autre bout du code, voire l'exécution de n'importe quoi (c'est entre nous une des grandes failles des OS écrits en C par des pieds gauches).
JKB
JKB
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
J'aimerais bien savoir en quel honneur.
La réponse est dans <cbrt68$hnb$, on tourne en rond.
Non, mais si pour vous c'est la même chose... Je ne puis rien faire. Est-ce que vous vous êtes déjà posé le problème _sématiquement_ ? Avez-vous déjà réalisé un interpréteur ? Un compilateur ? Faites l'expérience et revenez nous voir.
JKB
Le 30-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnce53bh.285.bertrand@grossebaf.systella.fr>, a
écrit :
J'aimerais bien savoir en quel honneur.
La réponse est dans <cbrt68$hnb$1@nef.ens.fr>, on tourne en rond.
Non, mais si pour vous c'est la même chose... Je ne puis rien faire.
Est-ce que vous vous êtes déjà posé le problème _sématiquement_ ?
Avez-vous déjà réalisé un interpréteur ? Un compilateur ? Faites
l'expérience et revenez nous voir.
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
J'aimerais bien savoir en quel honneur.
La réponse est dans <cbrt68$hnb$, on tourne en rond.
Non, mais si pour vous c'est la même chose... Je ne puis rien faire. Est-ce que vous vous êtes déjà posé le problème _sématiquement_ ? Avez-vous déjà réalisé un interpréteur ? Un compilateur ? Faites l'expérience et revenez nous voir.
JKB
JKB
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Non. C'est un peu le même argument que celui qui consiste à prétendre que l'écriture arabe ressemble à un plat de nouilles car on ne sait pas la lire. Donc mauvais argument, changer d'argument.
Pas du tout, il y a une vraie notion qui explique la meilleure lisibilité de l'infixe : les arguments sont plus regroupés près de l'opérateur.
Non. Cela n'est vrai que pour les expressions simples.
Comme à une expression algébrique d'ailleurs : 'g(x)' est-elle une fonction ou simplement le x-ième élément du vecteur g ?
Ça, c'est un mauvais argument : fondamentalement, c'est la même chose.
Hi hi hi hi, encore rraté !... L'élément d'un vecteur est traité comme une case mémoire (pour faire simple), alors que l'évaluation d'une fonction est traité comme un appel à une routine interprétée au vol ou une fonction intrinsèque au langage, ce qui est _totalement_ différent (sémantiquement parlant).
JKB
Le 30-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnce53lj.285.bertrand@grossebaf.systella.fr>, a
écrit :
Non. C'est un peu le même argument que celui qui consiste à
prétendre que l'écriture arabe ressemble à un plat de nouilles car
on ne sait pas la lire. Donc mauvais argument, changer d'argument.
Pas du tout, il y a une vraie notion qui explique la meilleure
lisibilité de l'infixe : les arguments sont plus regroupés près de
l'opérateur.
Non. Cela n'est vrai que pour les expressions simples.
Comme à une expression algébrique d'ailleurs : 'g(x)' est-elle une
fonction ou simplement le x-ième élément du vecteur g ?
Ça, c'est un mauvais argument : fondamentalement, c'est la même chose.
Hi hi hi hi, encore rraté !... L'élément d'un vecteur est traité
comme une case mémoire (pour faire simple), alors que l'évaluation
d'une fonction est traité comme un appel à une routine interprétée
au vol ou une fonction intrinsèque au langage, ce qui est
_totalement_ différent (sémantiquement parlant).
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Non. C'est un peu le même argument que celui qui consiste à prétendre que l'écriture arabe ressemble à un plat de nouilles car on ne sait pas la lire. Donc mauvais argument, changer d'argument.
Pas du tout, il y a une vraie notion qui explique la meilleure lisibilité de l'infixe : les arguments sont plus regroupés près de l'opérateur.
Non. Cela n'est vrai que pour les expressions simples.
Comme à une expression algébrique d'ailleurs : 'g(x)' est-elle une fonction ou simplement le x-ième élément du vecteur g ?
Ça, c'est un mauvais argument : fondamentalement, c'est la même chose.
Hi hi hi hi, encore rraté !... L'élément d'un vecteur est traité comme une case mémoire (pour faire simple), alors que l'évaluation d'une fonction est traité comme un appel à une routine interprétée au vol ou une fonction intrinsèque au langage, ce qui est _totalement_ différent (sémantiquement parlant).
JKB
Manuel Leclerc
Bien sûr, mais la question n'est pas là. La question est : le programme va-t-il exécuter les instructions indiquées dans le source, ou va-t-il faire N'IMPORTE QUOI ?
Il va exécuter les instructions indiquées, évidemment.
Jusqu'à l'instruction "indiquée" qui provoque un "undefined". Après cette instruction ton "évidemment" est évidemment faux.
Je suis un peu étonné de ta mauvaise foi sur le sujet. Quel rapport "spécial" as-tu avec le C ?
-- You must click "Yes" on the Security Warning to get Smiley Central. Don't Worry - this is standard. The Security Warning appears before you download anything off of the Internet.
Bien sûr, mais la question n'est pas là. La question
est : le programme va-t-il exécuter les instructions
indiquées dans le source, ou va-t-il faire N'IMPORTE
QUOI ?
Il va exécuter les instructions indiquées, évidemment.
Jusqu'à l'instruction "indiquée" qui provoque un "undefined".
Après cette instruction ton "évidemment" est évidemment faux.
Je suis un peu étonné de ta mauvaise foi sur le sujet.
Quel rapport "spécial" as-tu avec le C ?
--
You must click "Yes" on the Security Warning to get Smiley Central. Don't
Worry - this is standard. The Security Warning appears before you download
anything off of the Internet.
Bien sûr, mais la question n'est pas là. La question est : le programme va-t-il exécuter les instructions indiquées dans le source, ou va-t-il faire N'IMPORTE QUOI ?
Il va exécuter les instructions indiquées, évidemment.
Jusqu'à l'instruction "indiquée" qui provoque un "undefined". Après cette instruction ton "évidemment" est évidemment faux.
Je suis un peu étonné de ta mauvaise foi sur le sujet. Quel rapport "spécial" as-tu avec le C ?
-- You must click "Yes" on the Security Warning to get Smiley Central. Don't Worry - this is standard. The Security Warning appears before you download anything off of the Internet.
Manuel Leclerc
Je ne vois pas bien à quel moment cet ajustement pourrait être considéré comme "inutile".
Cette remarque me fait me poser une question indiscrète : as-tu une expérience réelle de la programmation en C ?
Oui, mais peux-tu m'expliquer le rapport entre ta question et ma question ?
-- I have systematically eliminated all references to "software", because some people disagree about what it means. --Andrew Suffield
Je ne vois pas bien à quel moment cet ajustement pourrait
être considéré comme "inutile".
Cette remarque me fait me poser une question indiscrète : as-tu
une expérience réelle de la programmation en C ?
Oui, mais peux-tu m'expliquer le rapport entre ta question
et ma question ?
--
I have systematically eliminated all references to "software",
because some people disagree about what it means.
--Andrew Suffield
