SL a écrit :
> S'il s'agit de JNI, c'est une interface avec le code
> compilé, pas avec le code source, n'est-ce pas ?

Exact.
Ce qui pose quelques problèmes au niveau de la portabilité, mais on a
rien sans rien...

Le Wed, 24 May 2006 13:53:59 +0200, Stéphane Zuckerman a écrit:

>
> Mais en C ou C++, le programme est compilé une fois pour toutes. En Java,
> le bytecode n'est pas totalement compilé en JIT, si ?

Inline cache le résultat des compilations, et il est possible dans le cas
de programmes genre CGI ou mod_perl, d'utiliser toujours la même JVM.

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando

Le Wed, 24 May 2006 14:22:49 +0200, SL a écrit:

>
> vous aurez du mal à m'enlever le
> préjugé que mettre du code à compiler et exécuter depuis un langage
> interprété est un peu tordu :-)

Perl n'est pas un langage interprété. Pär ailleurs la compilation du
code Inline n'a lieu qu'à la première exécution. Et on utilise très
couramment et depuis de longues années des librairies bindées en C en
Perl (y compris Tk, GTK, SDL et tutti quanti), c'est parfaitement fiable
et robuste, il n'y a pas de raison que ça ne marche pas avec Java

> Connais pas. S'il s'agit de JNI, c'est une interface avec le code
> compilé, pas avec le code source, n'est-ce pas ?

Inline aussi c'est une interface avec le code compilé. L'intégration du
source n'est qu'une commodité pour le développeur (il suffit d'avoir
essayé de lire la doc XS pour comprendre sa douleur).

--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Aït Ahmed.

Emmanuel Florac a écrit :
> Le Wed, 24 May 2006 13:53:59 +0200, Stéphane Zuckerman a écrit:
>
>>
>> Mais en C ou C++, le programme est compilé une fois pour toutes. En Java,
>> le bytecode n'est pas totalement compilé en JIT, si ?
>
> Inline cache le résultat des compilations, et il est possible dans le cas
> de programmes genre CGI ou mod_perl, d'utiliser toujours la même JVM.

Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à
chaque requête, donc il faudrait effectivement que Inline cache le
code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il
cachait la liste des méthodes publiques.

Emmanuel Florac a écrit :
> Le Wed, 24 May 2006 14:22:49 +0200, SL a écrit:
>
>>
>> vous aurez du mal à m'enlever le préjugé que mettre du code à
>> compiler et exécuter depuis un langage interprété est un peu tordu
>> :-)
>
> Perl n'est pas un langage interprété.

Ça s'appelle comment ?

Le Wed, 24 May 2006 23:13:16 +0200, SL a écrit:

>
> Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à
> chaque requête, donc il faudrait effectivement que Inline cache le
> code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il
> cachait la liste des méthodes publiques.

Et il peut utiliser la même JVM résidente pour ne pas la relancer à
chaque fois.

--
A thing of beauty is a joy forever.
J. Keats.

Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.

Le Wed, 24 May 2006 23:14:19 +0200, SL a écrit:

>
> Ça s'appelle comment ?

Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la
Java (mais pas tout à fait, parce que la totalité du code n'est pas
forcément compilée au démarrage).

--
Sutor ne ultra Crepidam.

Le Mon, 22 May 2006 01:16:32 -0700, seb666fr2 a écrit:

>
> Je parle des *APIs standard* de n'importe quel langage.

Il faudra m'expliquer l'intérêt de se limiter aux API standards de
n'importe quel langage...

--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Aït Ahmed.

Emmanuel Florac <eflorac@imaginet.fr> wrote:
> Le Wed, 24 May 2006 23:14:19 +0200, SL a écrit:
>
> >
> > Ça s'appelle comment ?
>
> Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la
> Java (mais pas tout à fait, parce que la totalité du code n'est pas
> forcément compilée au démarrage).
>

Non tu dis n'importe quoi, perl est bien un langage interprété,
perl interprète du byte code. Certes il commence d'abord à compiler ton
programme textuel en bytecode, il va compiler les expressions régulières, etc.
mais ensuite il interprète pas à pas du bytecode, qui est trés loin du code
machine. La machine virtuelle Java compile sans arrêt (particulièrement en
mode "server") le bytecode en code machine, l'optimise en fonction de
l'utilisation qui en est faite, et exécute pour l'essentiel du code machine.
C'est pour ça qu'il y a un gros facteur entre les performances de Java,
qui peuvent approcher celles du code natif, ou tout au moins ne pas être
plus de 10 fois plus lent, et les performances des langages interprétés,
perl, python, ruby qui sont au bas mot 10 fois plus lents que Java.

--

Michel TALON

Emmanuel Florac a écrit :
> Le Wed, 24 May 2006 23:14:19 +0200, SL a écrit:
>
>>
>> Ça s'appelle comment ?
>
> Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la
> Java (mais pas tout à fait, parce que la totalité du code n'est pas
> forcément compilée au démarrage).

Une machine virtuelle à la Java, c'est à-dire-qu'au lancement de
l'interpréteur perl, il ne re-compile pas le fichier texte en
bytecode, mais récupère un bytecode stocké quelque part ? Et qu'il
compile le bytecode en code machine quand il peut avec une technologie
JIT ?

Je n'ai toujours pas compris comment Inline::java pouvait ne pas
recompiler le code java en bytecode à chaque lancement d'une
l'instance de l'interpréteur. ça veut dire que Inline::java récupère
le code java, le compare au code source à partir duquel il a
byte-compilé quelque chose, et que si le code source est toujours le
même il réutilise ce code bytecompilé sauvé quelque part ?

Emmanuel Florac a écrit :
> Le Wed, 24 May 2006 23:13:16 +0200, SL a écrit:
>
>> Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à
>> chaque requête, donc il faudrait effectivement que Inline cache le
>> code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il
>> cachait la liste des méthodes publiques.
>
> Et il peut utiliser la même JVM résidente pour ne pas la relancer à
> chaque fois.

Je ne sais pas ce que c'est qu'une JVM résidente, par contre je n'ai
pas compris comment il pouvait ne pas avoir à appeller le compilateur
code java->bytecode java à chaque compilation code-perl->bytecode
perl.

Emmanuel Florac wrote:

> Il faudra m'expliquer l'intérêt de se limiter aux API standards de
> n'importe quel langage...

Parce que cela permet de juger des capacités du langage à
permettre la résolution de problèmes directement, sans être
contraint d'utiliser des APIs tierces où en minimisant le plus
possible le recours à celles-ci, afin de réduire les dépendances
vis à vis d'éditeurs tiers (libre ou non).

seb666fr2@yahoo.fr, dans le message
<1148555085.370075.186560@j73g2000cwa.googlegroups .com>, a écrit:
> Parce que cela permet de juger des capacités du langage à
> permettre la résolution de problèmes directement,

Non, évidemment: pour ça, pour juger le _langage_, il faut se restreindre
au langage, sans _aucune_ bibliothèque tierces sauf celles qui sont
structurellement indispensables.

On Wed, 24 May 2006, SL wrote:

> Emmanuel Florac a écrit :
>> Le Wed, 24 May 2006 13:53:59 +0200, Stéphane Zuckerman a écrit:
>>
>>>
>>> Mais en C ou C++, le programme est compilé une fois pour toutes. En Java,
>>> le bytecode n'est pas totalement compilé en JIT, si ?
>>
>> Inline cache le résultat des compilations, et il est possible dans le cas
>> de programmes genre CGI ou mod_perl, d'utiliser toujours la même JVM.
>
> Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à
> chaque requête, donc il faudrait effectivement que Inline cache le
> code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il
> cachait la liste des méthodes publiques.

Sauf qu'avec mod_perl/mod_php, etc, c'est un peu plus complexe que ça.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

On Thu, 25 May 2006, Nicolas George wrote:

> seb666fr2@yahoo.fr, dans le message
> <1148555085.370075.186560@j73g2000cwa.googlegroups .com>, a écrit:
>> Parce que cela permet de juger des capacités du langage à
>> permettre la résolution de problèmes directement,
>
> Non, évidemment: pour ça, pour juger le _langage_, il faut se restreindre
> au langage, sans _aucune_ bibliothèque tierces sauf celles qui sont
> structurellement indispensables.

Et dans ce cas, Perl est plutôt en tête. O:-)

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Nicolas George wrote:
> seb666fr2@yahoo.fr, dans le message
> <1148555085.370075.186560@j73g2000cwa.googlegroups .com>, a écrit :
> > Parce que cela permet de juger des capacités du langage à
> > permettre la résolution de problèmes directement,

> Non, évidemment : pour ça, pour juger le _langage_, il faut se restreindre
> au langage, sans _aucune_ bibliothèque tierces sauf celles qui sont
> structurellement indispensables.

Primo, *juger un langage* et *juger les capacités d'un langage à
permettre
la résolution de problèmes* sont 2 choses totalement différente. La
1ère
est motivée par des préjugés digne de la cour de récréation, la
seconde
est motivée par le pragmatisme.

Nicolas George wrote:
> seb666fr2@yahoo.fr, dans le message
> <1148555085.370075.186560@j73g2000cwa.googlegroups .com>, a écrit :
> > Parce que cela permet de juger des capacités du langage à
> > permettre la résolution de problèmes directement,

> Non, évidemment : pour ça, pour juger le _langage_, il faut se restreindre
> au langage, sans _aucune_ bibliothèque tierces sauf celles qui sont
> structurellement indispensables.

*juger un langage* et *juger les capacités d'un langage à permettre
la résolution de problèmes* sont 2 choses totalement différente. La
1ère
est motivée par des préjugés digne de la cour de récréation, la
seconde
est motivée par le pragmatisme.

Patrick Lamaizière <adresse@est.invalid> writes:

> Michel Billaud écrivait :
>
> >> Peux tu me citer de quelle société FreeBSD dépend? Et je parle de
> >> FreeBSD parceque c'est un système complet. Tu auras du mal il n'y en
> >> a aucune.
> >
> > Voyons, tu est sur que ça n'apparitent pas à SCO ? :-)
>
> Oui ça a déjà été jugé !
> Je n'ai pas trop suivi avec Linux, c'en est où cette histoire au fait ?

C'est très loin d'avoir été jugé. On en arrive à la fin de la phase
où les deux parties SCO et IBM doivent terminer de déposer les documents, les
témoignages et dépositions qui serviront pour la suite.

Le "Final Deadline for Expert Discovery" est le 10 juillet.

Il y a juste un problème avec SCO, c'est qu'IBM leur demande de
préciser ce que SCO leur reproche exactement. Il s'agissait au début
de "tonnes de code copié", IBM a demandé de quelles lignes dans quels
fichiers de quelle version : pschitt. Il y a eu aussi l'annonce que
SCO détenait les copyrights d'UNIX, plouf, aucun document ne le
prouve. Par contre il y a eu des documents où SCO demandait (à Novell
en 2003) de bien vouloir les lui transférer, ce qui prouve plutot
le contraire.

Maintenant, SCO prétend qu'IBM lui a piqué, peut être pas du code, des
"méthodes et concepts" qui lui appartiendrait puisqu'UNIX lui
appartient. D'une part sans préciser lesquels, ni où (version,
fichier, ligne ?) ils se concrétisent, d'autre part en oubliant que
les méthodes et concepts d'UNIX sont très largement exposés dans la
littérature depuis les années 70, et n'appartiennent donc à personne.

Et tout ça, bien sûr, SCO le fait en complète opposition avec les
ordres de la juge qui s'occupe de l'affaire. Au train où ça va, il
n'est pas impossible que l'affaire soit classée pour absence
d'élements pour fonder la plainte, que SCO se prenne une belle prune
pour mensonge (en plus de casquer pour les frais d'avocats et
judiciaires) et plainte abusive, et que les avocats de SCO dégustent
pour outrage à magistrat. Ambiance.

Il apparait que SCO est très probablement téléguidée (et soutenue
financièrement) par une autre société-dont-nous-tairons-le-nom qui
souhaitait emmerder IBM, avec l'espoir pour SCO d'arriver à une
transaction où IBM lacherait quelques sous pour avoir la paix (et
permettrait à la-societe-dont-nous-taisons-le-nom de faire un peu de
propagande sur le thème "avec le logiciel libre, un truc de pirate,
fatalement vous aurez des procès sur le cul"). Manque de bol IBM n'a
absolument aucun envie de plaisanter avec Linux, et compte bien d'une
part avoir la peau de SCO (qui ne survivra pas aux frais générés par
le procès perdu), et d'autre part mettre en evidence le lien avec la
société qui l'a un peu poussée dans cette voie (IBM a demandé à
connaitre tous les échanges, mails, réunions, etc. entre SCO et XXXX à
propos de Linux et d'IBM), ce qui va surement amener un beau retour de
manivelle.

C'est passionnant tout ça. A suivre dans http://www.groklaw.net

MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Prodejeu <prodejeu@free.fr> writes:

[java verbeux]

> C'est sûr qu'en Python un Hello, World c'est plus court :
> print "Hello, World"

en lisp

"Hello, World"

et ?

MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Michel Billaud a écrit :
> Prodejeu <prodejeu@free.fr> writes:
>
> [java verbeux]
>
>> C'est sûr qu'en Python un Hello, World c'est plus court :
>> print "Hello, World"
>
> en lisp
>
> "Hello, World"
>
> et ?

Et, t'as rien suivi à la conversation visiblement...
Si ça peut t'aider à suivre ; je répondait à un message d'Emmanuel
Florac sur la verbosité des langages (voir plus haut).

Prodejeu <prodejeu@free.fr> writes:

> Michel Billaud a écrit :
> > Prodejeu <prodejeu@free.fr> writes:
> > [java verbeux]
> >
> >> C'est sûr qu'en Python un Hello, World c'est plus court :
> >> print "Hello, World"
> > en lisp
> > "Hello, World" et ?
>
> Et, t'as rien suivi à la conversation visiblement...
> Si ça peut t'aider à suivre ; je répondait à un message d'Emmanuel
> Florac sur la verbosité des langages (voir plus haut).

Laquelle ne se mesure pas sur la longueur du programme minimum, comme
quoi la remarque sur python était hors sujet, ce que devait faire
ressortir la comparaison avec un autre langage, où le programme
minimum est encore plus court, la conclusion sur l'absence de
conclusion à en tirer étant dans le "et ?" final.

Qui n'a pas suivi ? :-)

Autrefois (années 70) la mode était de comparer les langages de
programmation sur la possibilité (et la facilité) d'utiliser le
langage pour exprimer son propre compilateur/interprète. Outre que ça
permettait le portage de compilateurs (compilateur croisé puis
bootstrap), ca mettait en évidence l'expressivité. C'était
peut être plus pertinent, pour comparer les langages que le hello
world (venu du K et R ?). A condition de comparer des langages
universels, et non spécialisés, d'ailleurs.

MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

On Fri, 26 May 2006, Michel Billaud wrote:
> Autrefois (années 70) la mode était de comparer les langages de
> programmation sur la possibilité (et la facilité) d'utiliser le
> langage pour exprimer son propre compilateur/interprète. Outre que ça
> permettait le portage de compilateurs (compilateur croisé puis
> bootstrap), ca mettait en évidence l'expressivité. C'était
> peut être plus pertinent, pour comparer les langages que le hello
> world (venu du K et R ?).

Non, dans le K&R, le premier affichage est « Bonjour, maître. » :-)

> A condition de comparer des langages universels, et non spécialisés,
> d'ailleurs.

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Michel Billaud <billaud@labri.fr> wrote:
>
> Autrefois (années 70) la mode était de comparer les langages de
> programmation sur la possibilité (et la facilité) d'utiliser le
> langage pour exprimer son propre compilateur/interprète. Outre que ça
> permettait le portage de compilateurs (compilateur croisé puis
> bootstrap), ca mettait en évidence l'expressivité. C'était
> peut être plus pertinent, pour comparer les langages que le hello
> world (venu du K et R ?). A condition de comparer des langages
> universels, et non spécialisés, d'ailleurs.

Et alors, l'un n'empêche pas l'autre:
http://codespeak.net/pypy/dist/pypy/...ase-0.7.0.html
PyPy is a MIT-licensed research-oriented reimplementation of Python written in
Python itself, flexible and easy to experiment with. It translates itself to
lower level languages. Our goals are to target a large variety of platforms,
small and large, by providing a compilation toolsuite that can produce custom
Python versions. Platform, Memory and Threading models are to become aspects
of the translation process - as opposed to encoding low level details into a
language implementation itself. Eventually, dynamic optimization techniques -
implemented as another translation aspect - should become robust against
language changes.


--

Michel TALON

Le Thu, 25 May 2006 13:00:20 +0200, SL a écrit:

>
> Une machine virtuelle à la Java, c'est à-dire-qu'au lancement de
> l'interpréteur perl, il ne re-compile pas le fichier texte en
> bytecode, mais récupère un bytecode stocké quelque part ?

Dans le dossier .Inline là où se trouve le source, ou bien dans
~/.Inline, ou bien là où on le lui dit, oui.

> Et qu'il
> compile le bytecode en code machine quand il peut avec une technologie
> JIT ?

Non, il n'y a pas de JIT Perl5.

> Je n'ai toujours pas compris comment Inline::java pouvait ne pas
> recompiler le code java en bytecode à chaque lancement d'une
> l'instance de l'interpréteur.

En comparant la date du source et du dernier bytecode généré, par
exemple?

--
A travers l'audimat, c'est la logique du commercial qui s'impose aux
productions culturelles. Or, il est important de savoir que,
historiquement, toutes les productions culturelles que je considère, -
et je ne suis pas le seul, j'espère -, qu'un certain nombre de gens
considèrent comme les productions les plus hautes de l'humanité, les
mathématiques, la poésie, la littérature, la philosophie, toutes ces
choses ont été produites contre l'équivalent de l'audimat, contre la
logique du commerce.
Pierre Bourdieu, "Sur la télévision". Raison d'Agir Editions, décembre
1996

Emmanuel Florac a écrit :
> Le Thu, 25 May 2006 13:00:20 +0200, SL a écrit:
>
>> Une machine virtuelle à la Java, c'est à-dire-qu'au lancement de
>> l'interpréteur perl, il ne re-compile pas le fichier texte en
>> bytecode, mais récupère un bytecode stocké quelque part ?
>
> Dans le dossier .Inline là où se trouve le source, ou bien dans
> ~/.Inline, ou bien là où on le lui dit, oui.

Ecoutez, je sais pas si c'est moi qui ne comprends rien ou quoi, mais
vous êtes bien en train de me dire que quand perl est invoqué, il
enregistre le byte code dans un répertoire nommé .Inline ? Et que Perl
ne parse pas le fichier texte à chaque invocation, si du byte code non
périmé existe déjà ?

>> Je n'ai toujours pas compris comment Inline::java pouvait ne pas
>> recompiler le code java en bytecode à chaque lancement d'une
>> l'instance de l'interpréteur.
>
> En comparant la date du source et du dernier bytecode généré, par
> exemple?

Certes, mais je ne vois pas Inline::Java faire cela, enfin.

<http://search.cpan.org/src/PATL/Inline-Java-0.51/Java.pm>