Sun a finalement annoncé le passage prochain de son langage Java, en
Open Source.
L'hésitation porte à l'heure actuelle sur le type exact de licence, Sun
voulant garder la main sur le langage.
Quoiqu'il en soit le code de Java sera ouvert.
Cela va t-il sonner le glas pour les techno .NET ?
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
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
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
SL
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.
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.
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.
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à ?
On parle bien du bytecode Java, n'est ce pas ? C'est en tout cas ce qui est écrit dans la doc de Inline... Pour le bytecode Perl, il est possible de le compiler et de stocker la version compilée dans un fichier .plc, mais pour diverses raisons cette fonctionnalité n'est pas utilisée en pratique.
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Et bien il faut regarder mieux :
if (! $o->get_java_config('built')){ # Since we didn't build the module, this means that # it was up to date. We can therefore use the data # from the cache.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Fri, 26 May 2006 20:17:02 +0200, SL a écrit :
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à ?
On parle bien du bytecode Java, n'est ce pas ? C'est en tout cas ce qui
est écrit dans la doc de Inline... Pour le bytecode Perl, il est possible
de le compiler et de stocker la version compilée dans un fichier .plc,
mais pour diverses raisons cette fonctionnalité n'est pas utilisée en
pratique.
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Et bien il faut regarder mieux :
if (! $o->get_java_config('built')){
# Since we didn't build the module, this means that
# it was up to date. We can therefore use the data
# from the cache.
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
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à ?
On parle bien du bytecode Java, n'est ce pas ? C'est en tout cas ce qui est écrit dans la doc de Inline... Pour le bytecode Perl, il est possible de le compiler et de stocker la version compilée dans un fichier .plc, mais pour diverses raisons cette fonctionnalité n'est pas utilisée en pratique.
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Et bien il faut regarder mieux :
if (! $o->get_java_config('built')){ # Since we didn't build the module, this means that # it was up to date. We can therefore use the data # from the cache.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
talon
SL wrote:
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Tu as une explication de cette affaire ici: http://perl.com/pub/a/2003/11/07/java.html
So what is Inline::Java doing for us? When it finds our Java code, it makes a copy in the .java file of the proper name (javac is adamant that class names and file names match). Then it uses our Java compiler to build a compiled version of the program. It puts that version in a directory, using an MD5 sum to ensure that recompiling happens when and only when the code changes.
De ce que je comprends ça doit lancer un interprète de Java à chaque appel sur les .class déjà compilés donc au secours les performances.
--
Michel TALON
SL <nospam@nospam.com> wrote:
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Tu as une explication de cette affaire ici:
http://perl.com/pub/a/2003/11/07/java.html
So what is Inline::Java doing for us? When it finds our Java code, it makes a
copy in the .java file of the proper name (javac is adamant that class names
and file names match). Then it uses our Java compiler to build a compiled
version of the program. It puts that version in a directory, using an MD5 sum
to ensure that recompiling happens when and only when the code changes.
De ce que je comprends ça doit lancer un interprète de Java à chaque appel
sur les .class déjà compilés donc au secours les performances.
Tu as une explication de cette affaire ici: http://perl.com/pub/a/2003/11/07/java.html
So what is Inline::Java doing for us? When it finds our Java code, it makes a copy in the .java file of the proper name (javac is adamant that class names and file names match). Then it uses our Java compiler to build a compiled version of the program. It puts that version in a directory, using an MD5 sum to ensure that recompiling happens when and only when the code changes.
De ce que je comprends ça doit lancer un interprète de Java à chaque appel sur les .class déjà compilés donc au secours les performances.
--
Michel TALON
Emmanuel Florac
Le Fri, 26 May 2006 18:27:01 +0000, Michel Talon a écrit :
De ce que je comprends ça doit lancer un interprète de Java à chaque appel sur les .class déjà compilés donc au secours les performances.
Tout à fait, c'est pourquoi il est prévu qu'on puisse faire appel à une JVM déjà chargée :
SHARED_JVM ^
Starting with version 0.30, the Inline::Java JVM can now be shared between multiple processes. The first process to start creates the JVM but does not shut it down on exit. All other processes can then connect as needed to the JVM. If any of these other processes where created by forking the parent process, the Inline::Java->reconnect_JVM() function must be called in the child to get a fresh connection to the JVM.
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
Le Fri, 26 May 2006 18:27:01 +0000, Michel Talon a écrit :
De ce que je comprends ça doit lancer un interprète de Java à chaque appel
sur les .class déjà compilés donc au secours les performances.
Tout à fait, c'est pourquoi il est prévu qu'on puisse faire appel à une
JVM déjà chargée :
SHARED_JVM ^
Starting with version 0.30, the Inline::Java JVM can now be shared
between multiple processes. The first process to start creates the JVM but
does not shut it down on exit. All other processes can then connect as
needed to the JVM. If any of these other processes where created by
forking the parent process, the Inline::Java->reconnect_JVM() function
must be called in the child to get a fresh connection to the JVM.
--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.
Le Fri, 26 May 2006 18:27:01 +0000, Michel Talon a écrit :
De ce que je comprends ça doit lancer un interprète de Java à chaque appel sur les .class déjà compilés donc au secours les performances.
Tout à fait, c'est pourquoi il est prévu qu'on puisse faire appel à une JVM déjà chargée :
SHARED_JVM ^
Starting with version 0.30, the Inline::Java JVM can now be shared between multiple processes. The first process to start creates the JVM but does not shut it down on exit. All other processes can then connect as needed to the JVM. If any of these other processes where created by forking the parent process, the Inline::Java->reconnect_JVM() function must be called in the child to get a fresh connection to the JVM.
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
SL
Le Fri, 26 May 2006 20:17:02 +0200, SL a écrit :
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à ?
On parle bien du bytecode Java, n'est ce pas ?
Non, moi j'en étais à perl lui-même.
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Et bien il faut regarder mieux :
if (! $o->get_java_config('built')){ # Since we didn't build the module, this means that # it was up to date. We can therefore use the data # from the cache.
Oui, et la seule fois où je vois cette propriété mise à vrai dans tous le package, c'est au sortir d'un sub "build" qui vient de compiler... Java.pm(420) :
$o->set_java_config('built', 1) ;
Enfin, j'ai dû passer à côté du truc.
Le Fri, 26 May 2006 20:17:02 +0200, SL a écrit :
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à ?
On parle bien du bytecode Java, n'est ce pas ?
Non, moi j'en étais à perl lui-même.
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Et bien il faut regarder mieux :
if (! $o->get_java_config('built')){ # Since we didn't build the module, this means that # it was up to date. We can therefore use the data # from the cache.
Oui, et la seule fois où je vois cette propriété mise à vrai dans tous
le package, c'est au sortir d'un sub "build" qui vient de
compiler... Java.pm(420) :
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à ?
On parle bien du bytecode Java, n'est ce pas ?
Non, moi j'en étais à perl lui-même.
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Et bien il faut regarder mieux :
if (! $o->get_java_config('built')){ # Since we didn't build the module, this means that # it was up to date. We can therefore use the data # from the cache.
Oui, et la seule fois où je vois cette propriété mise à vrai dans tous le package, c'est au sortir d'un sub "build" qui vient de compiler... Java.pm(420) :
$o->set_java_config('built', 1) ;
Enfin, j'ai dû passer à côté du truc.
SL
SL wrote:
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Tu as une explication de cette affaire ici: http://perl.com/pub/a/2003/11/07/java.html
So what is Inline::Java doing for us? When it finds our Java code, it makes a copy in the .java file of the proper name (javac is adamant that class names and file names match). Then it uses our Java compiler to build a compiled version of the program. It puts that version in a directory, using an MD5 sum to ensure that recompiling happens when and only when the code changes.
Bon, la messe est dite.
C'est assez folklo le passage où le code source est passé aux regexp pour retrouver le nom des classes publiques et enregistrer dans des fichiers ".java" le code avant de le compiler...
De ce que je comprends ça doit lancer un interprète de Java à chaque appel sur les .class déjà compilés donc au secours les performances.
Tout ça marche probablement très bien mais j'aimerais pas reposer sur un truc pareil.
SL <nospam@nospam.com> wrote:
Certes, mais je ne vois pas Inline::Java faire cela, enfin.
Tu as une explication de cette affaire ici:
http://perl.com/pub/a/2003/11/07/java.html
So what is Inline::Java doing for us? When it finds our Java code,
it makes a copy in the .java file of the proper name (javac is
adamant that class names and file names match). Then it uses our
Java compiler to build a compiled version of the program. It puts
that version in a directory, using an MD5 sum to ensure that
recompiling happens when and only when the code changes.
Bon, la messe est dite.
C'est assez folklo le passage où le code source est passé aux regexp
pour retrouver le nom des classes publiques et enregistrer dans des
fichiers ".java" le code avant de le compiler...
De ce que je comprends ça doit lancer un interprète de Java à chaque
appel sur les .class déjà compilés donc au secours les performances.
Tout ça marche probablement très bien mais j'aimerais pas reposer sur
un truc pareil.
Tu as une explication de cette affaire ici: http://perl.com/pub/a/2003/11/07/java.html
So what is Inline::Java doing for us? When it finds our Java code, it makes a copy in the .java file of the proper name (javac is adamant that class names and file names match). Then it uses our Java compiler to build a compiled version of the program. It puts that version in a directory, using an MD5 sum to ensure that recompiling happens when and only when the code changes.
Bon, la messe est dite.
C'est assez folklo le passage où le code source est passé aux regexp pour retrouver le nom des classes publiques et enregistrer dans des fichiers ".java" le code avant de le compiler...
De ce que je comprends ça doit lancer un interprète de Java à chaque appel sur les .class déjà compilés donc au secours les performances.
Tout ça marche probablement très bien mais j'aimerais pas reposer sur un truc pareil.
Prodejeu
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 ? :-)
Ben toi, puisque si tu avais lu plus haut tu aurais vu qu'il est fait mention de "verbosité de langage", mais aussi de "Hello World", en assembleur, et en Perl. L'exemple sur python était là pour montrer que l'on peut faire également très court avec ce langage (surtout pour un Hello World). Je ne savais pas qu'on pouvais faire plus court en Lisp, merci pour l'information. D'ailleurs la même expression fonctionne également très bien en Python. Quoi qu'il en soit je suis bien d'accord pour dire qu'un "Hello, World" est loin d'être suffisant pour évaluer un langage. (Mais ça a déjà été dit plus haut par Michel Talon).
C'était peut être plus pertinent, pour comparer les langages que le hello world (venu du K et R ?).
Quel est le rapport entre K&R en les "Hello, World" ?
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 ? :-)
Ben toi, puisque si tu avais lu plus haut tu aurais vu qu'il est fait
mention de "verbosité de langage", mais aussi de "Hello World", en
assembleur, et en Perl.
L'exemple sur python était là pour montrer que l'on peut faire également
très court avec ce langage (surtout pour un Hello World).
Je ne savais pas qu'on pouvais faire plus court en Lisp, merci pour
l'information.
D'ailleurs la même expression fonctionne également très bien en Python.
Quoi qu'il en soit je suis bien d'accord pour dire qu'un "Hello, World"
est loin d'être suffisant pour évaluer un langage. (Mais ça a déjà été
dit plus haut par Michel Talon).
C'était
peut être plus pertinent, pour comparer les langages que le hello
world (venu du K et R ?).
Quel est le rapport entre K&R en les "Hello, World" ?
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 ? :-)
Ben toi, puisque si tu avais lu plus haut tu aurais vu qu'il est fait mention de "verbosité de langage", mais aussi de "Hello World", en assembleur, et en Perl. L'exemple sur python était là pour montrer que l'on peut faire également très court avec ce langage (surtout pour un Hello World). Je ne savais pas qu'on pouvais faire plus court en Lisp, merci pour l'information. D'ailleurs la même expression fonctionne également très bien en Python. Quoi qu'il en soit je suis bien d'accord pour dire qu'un "Hello, World" est loin d'être suffisant pour évaluer un langage. (Mais ça a déjà été dit plus haut par Michel Talon).
C'était peut être plus pertinent, pour comparer les langages que le hello world (venu du K et R ?).
Quel est le rapport entre K&R en les "Hello, World" ?
talon
Michel Billaud wrote:
Prodejeu 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 la souplesse, qu'en fais tu?
niobe% gcl GCL (GNU Common Lisp) 2.6.7 ANSI Mar 17 2006 21:52:37
...
(+ 1 2)
3
(+ "Hello" "World!")
Error in + [or a callee]: "Hello" is not of type NUMBER.
niobe% python Python 2.4.2 (#2, Mar 15 2006, 09:09:01) [GCC 3.4.4 [FreeBSD] 20050518] on freebsd6 Type "help", "copyright", "credits" or "license" for more information.
print "Hello"+" World!" Hello World!
MB
--
Michel TALON
Michel Billaud <billaud@labri.fr> wrote:
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 la souplesse, qu'en fais tu?
niobe% gcl
GCL (GNU Common Lisp) 2.6.7 ANSI Mar 17 2006 21:52:37
...
(+ 1 2)
3
(+ "Hello" "World!")
Error in + [or a callee]: "Hello" is not of type NUMBER.
niobe% python
Python 2.4.2 (#2, Mar 15 2006, 09:09:01)
[GCC 3.4.4 [FreeBSD] 20050518] on freebsd6
Type "help", "copyright", "credits" or "license" for more information.
C'est sûr qu'en Python un Hello, World c'est plus court : print "Hello, World"
en lisp
"Hello, World"
et ?
Et la souplesse, qu'en fais tu?
niobe% gcl GCL (GNU Common Lisp) 2.6.7 ANSI Mar 17 2006 21:52:37
...
(+ 1 2)
3
(+ "Hello" "World!")
Error in + [or a callee]: "Hello" is not of type NUMBER.
niobe% python Python 2.4.2 (#2, Mar 15 2006, 09:09:01) [GCC 3.4.4 [FreeBSD] 20050518] on freebsd6 Type "help", "copyright", "credits" or "license" for more information.
print "Hello"+" World!" Hello World!
MB
--
Michel TALON
Emmanuel Florac
Le Fri, 26 May 2006 22:25:32 +0200, SL a écrit :
Non, moi j'en étais à perl lui-même.
On peut créer des fichiers Perl compilés (.plc), mais pour une raison quelconque personne n'utilise cette possibilité. Néammoins Audrey Tang a récemment utilisé cette fonctionnalité pour un module qui sert à rendre les source-filters "présentables" :). Il faudrait retrouver l'article (peut-être sur use.perl.org?).
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Aït Ahmed.
Le Fri, 26 May 2006 22:25:32 +0200, SL a écrit :
Non, moi j'en étais à perl lui-même.
On peut créer des fichiers Perl compilés (.plc), mais pour une raison
quelconque personne n'utilise cette possibilité. Néammoins Audrey Tang
a récemment utilisé cette fonctionnalité pour un module qui sert à
rendre les source-filters "présentables" :). Il faudrait retrouver
l'article (peut-être sur use.perl.org?).
--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Aït Ahmed.
On peut créer des fichiers Perl compilés (.plc), mais pour une raison quelconque personne n'utilise cette possibilité. Néammoins Audrey Tang a récemment utilisé cette fonctionnalité pour un module qui sert à rendre les source-filters "présentables" :). Il faudrait retrouver l'article (peut-être sur use.perl.org?).
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Aït Ahmed.
