Luathon : on veut la mort de fr.comp.lang.lua
Sébastien
En février dernier a été ouvert un groupe *français* de discussion sur
lua : fr.comp.lang.lua.
Ces derniers temps sur f.u.f.e. (fr.usenet.forums.evolution) il est
question de fermer ce groupe.
Peut-être que cela vous laisse carrément indifférent.
Mais si vous pensez que vous risquez de vous intéresser de près ou de
loin à ce langage des fois qu'un jour pdftex soit remplacé par un autre
moteur qui tirera profit de lua (je ne sais pas on peut toujours rêver
;) ), alors allez faire un tour sur f.u.f.e. pour dire que vous voulez
qu'il reste ouvert.
Paul Gaborit
� (at) Sun, 13 Dec 2009 01:33:46 +0100,
S�bastien <s...@free.fr> �crivait (wrote):
> En f�vrier dernier a �t� ouvert un groupe *fran�ais* de discussion sur
> lua : fr.comp.lang.lua.
> Ces derniers temps sur f.u.f.e. (fr.usenet.forums.evolution) il est
> question de fermer ce groupe.
> Peut-�tre que cela vous laisse carr�ment indiff�rent.
Indiff�rent, non.
Mais vu que le forum fr.comp.lang.lua a un niveau d'activit� nul, je
comprends tr�s bien qu'on le ferme.
> Mais si vous pensez que vous risquez de vous int�resser de pr�s ou
> de loin � ce langage des fois qu'un jour pdftex soit remplac� par un
> autre moteur qui tirera profit de lua (je ne sais pas on peut
> toujours r�ver ;) ), alors allez faire un tour sur f.u.f.e. pour
> dire que vous voulez qu'il reste ouvert.
Et pourquoi ne pas laisser faire tout simplement ? Une r�ouverture de
fr.comp.lang.lua sera toujours possible lorsque la quantit� de
discussions concernant lua p�sera trop dans ce forum (ou ailleurs).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Sébastien
> � (at) Sun, 13 Dec 2009 01:33:46 +0100,
> S�bastien <s...@free.fr> �crivait (wrote):
>
>> En f�vrier dernier a �t� ouvert un groupe *fran�ais* de discussion sur
>> lua : fr.comp.lang.lua.
>> Ces derniers temps sur f.u.f.e. (fr.usenet.forums.evolution) il est
>> question de fermer ce groupe.
>> Peut-�tre que cela vous laisse carr�ment indiff�rent.
>
> Indiff�rent, non.
>
> Mais vu que le forum fr.comp.lang.lua a un niveau d'activit� nul, je
> comprends tr�s bien qu'on le ferme.
C'est vrai, je faisais juste passer une info.
Alain Ketterlin
> En février dernier a été ouvert un groupe *français* de discussion sur
> lua : fr.comp.lang.lua.
Mon serveur NNTP ne me le propose pas, pourtant c'est un serveur plutôt
académique (news.ext.jussieu.fr). Google y trouve 3 messages.
> Ces derniers temps sur f.u.f.e. (fr.usenet.forums.evolution) il est
> question de fermer ce groupe.
Je trouve que les procédures d'ouverture/fermeture de Usenet sont en
général plutôt pertinentes. S'il est proposé à la fermeture, c'est qu'il
ne sert vraiment pas à grand chose (lire : à rien).
(Au fait, n'est-ce pas ici même que l'idée de ce groupe était née ?)
> Peut-être que cela vous laisse carrément indifférent.
En fait, oui, mais je suis quand même désolé qu'on en vienne à se
préoccuper d'un langage qui n'intéresse quasiment personne.
-- Alain.
JKB
Re: Luathon : on veut la mort de fr.comp.lang.lua,
Alain Ketterlin ?crivait dans fr.comp.text.tex :
> Sébastien <s...@free.fr> writes:
>
>> En février dernier a été ouvert un groupe *français* de discussion sur
>> lua : fr.comp.lang.lua.
>
> Mon serveur NNTP ne me le propose pas, pourtant c'est un serveur plutôt
> académique (news.ext.jussieu.fr). Google y trouve 3 messages.
>
>> Ces derniers temps sur f.u.f.e. (fr.usenet.forums.evolution) il est
>> question de fermer ce groupe.
>
> Je trouve que les procédures d'ouverture/fermeture de Usenet sont en
> général plutôt pertinentes. S'il est proposé à la fermeture, c'est qu'il
> ne sert vraiment pas à grand chose (lire : à rien).
Je plussoie vigoureusement.
> (Au fait, n'est-ce pas ici même que l'idée de ce groupe était née ?)
>
>> Peut-être que cela vous laisse carrément indifférent.
>
> En fait, oui, mais je suis quand même désolé qu'on en vienne à se
> préoccuper d'un langage qui n'intéresse quasiment personne.
Il faut aussi se dire que pour utiliser un tel langage, il faut
qu'il ait des choses qui le rendent différent de langages existants.
Personnellement, je ne vois pas en quoi intégrer un tel langage dans
un moteur *TeX serait un atout. Autant intégrer quelque chose de
plus complet et de plus léger. À titre personnel et pour un certain
nombre de raisons, j'aurais tendance à inclure un truc comme FORTH
(voire un RPL quelconque). Ça resterait plus dans la philosophie
*TeX. Maintenant, s'il faut intégrer un langage moderne, le
consensus risquant d'être limité, il vaut mieux avoir des API pour y
brancher un langage externe quelconque (un peu comme ce qui a été
fait en Fortran 2003 avec les ISO_C_BINDING) et les proposer sous la
forme de modules.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Manuel Pégourié-Gonnard
> Le 13-12-2009, ? propos de
> Re: Luathon : on veut la mort de fr.comp.lang.lua,
> Alain Ketterlin ?crivait dans fr.comp.text.tex :
>> acad�mique (news.ext.jussieu.fr). Google y trouve 3 messages.
>>
Pour ce groupe en particulier, ce n'est visiblement pas grave, pas contre
c'est sans doute le signe que ce serveur ne suit pas les cr�ations,
destructions et changements de statuts des groupes dans fr.*, ce qui est
certainement plus g�nant. Je vous encourage � contacter l'administrateur
du serveur pour attirer son attention sur ce point.
>> Je trouve que les proc�dures d'ouverture/fermeture de Usenet sont en
>> g�n�ral plut�t pertinentes. S'il est propos� � la fermeture, c'est qu'il
>> ne sert vraiment pas � grand chose (lire : � rien).
>
> Je plussoie vigoureusement.
>
J'aurais plut�t dit ��il n'est pas utilis頻 que ��il ne sert � rien��,
mais au fond l'id�e est la m�me, la demande de fermeture me para�t
�galement pertinente.
>> En fait, oui, mais je suis quand m�me d�sol� qu'on en vienne � se
>> pr�occuper d'un langage qui n'int�resse quasiment personne.
>
Ahem. Constater que personne n'en parle sur usenet-fr, c'est une chose.
En d�duire qu'il n'int�resse presque personne, c'est aller un peu vite
en besogne�! (Je propose un contre-argument � peu pr�s du m�me niveau�:
si le groupe ne voit pas de traffic, c'est parce que Lua est tellement
facile � apprendre et � utiliser qu'on a pas besoin de poser de
questions dessus. Et quand on a d�j� essay� d'apprendre TeX en tant que
langage de programmation, c'est vraiment rafra�chissant.)
> Il faut aussi se dire que pour utiliser un tel langage, il faut
> qu'il ait des choses qui le rendent diff�rent de langages existants.
Comme un peu tous les langages...
> Personnellement, je ne vois pas en quoi int�grer un tel langage dans
> un moteur *TeX serait un atout. Autant int�grer quelque chose de
> plus complet et de plus l�ger.
C'est la premi�re fois que j'entends dire que Lua est lourd. Je ne vois
pas vraiment de langage de script moderne qui soit plus l�ger. Et il me
para�t assez complet pour ce qu'on veut en faire (sans parler de la
possibilit� prochaine de charger des biblioth�ques dynamiques).
> � titre personnel et pour un certain
> nombre de raisons, j'aurais tendance � inclure un truc comme FORTH
> (voire un RPL quelconque). �a resterait plus dans la philosophie
> *TeX.
C'est sur que si par ��philosophe TeX�� on entend ��langage zarbi qui
rebute le nioubi�� alors ce genre de langage �tait bien mieux plac� que
Lua :-)
> Maintenant, s'il faut int�grer un langage moderne, le
> consensus risquant d'�tre limit�, il vaut mieux avoir des API pour y
> brancher un langage externe quelconque (un peu comme ce qui a �t�
> fait en Fortran 2003 avec les ISO_C_BINDING) et les proposer sous la
> forme de modules.
>
Id�alement, pourquoi pas (encore que, �a pourrait �tre un joli foutoir
sur le CTAN). Sauf que si on se penche un peu sur le code de TeX, on se
rend compte que c'est pas vraiment �crit de fa�on � rendre ce genre de
choses faciles. Et comme un bon ��tiens�� vaut toujours mieux que deux
��tu l'auras��, je pr�f�re avoir un LuaTeX qui marche pas mal maintenant
et a des chances d'�tre stable dans quelques ann�es, qu'un super API-TeX
avec des bindings en tout pleins de langages mais qui n'existera pas
avant bien longtemps.
Au risque de passer pour un vieil aigri, j'en ai un peu soup� des trolls
sur ��pourquoi Lua�� et ce qu'il faudrait faire � la place, alors que
LuaTeX est le seul projet qui travaille concr�tement � *ouvrir* TeX tout
en le modernisant, qu'un travail �norme est fait et que �a ouvre la voie �
tout plein de choses (dont souvent, pr�cis�ment ce qu'on dit qu'il
faudrait faire � la place). Rien que pour �a, m�me si le langage choisi
�tait mauvais ou inadapt�, je pense que �a vaudrait le coup de se
r�jouir de l'existence et de la sant� de LuaTeX. Et il se trouve que Lua
est loin d'�tre aussi mauvais ou inadapt� que certains le disent, bien
au contraire.
Bref, � mon (pas si) humble avis, LuaTeX est une des meilleurs choses
qui soient arriv�s � TeX depuis quelques temps, alors profitons-en au
lieu de critiquer vainement.
--
Manuel P�gouri�-Gonnard Institut de math�matiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Hank
> Bref, � mon (pas si) humble avis, LuaTeX est une des meilleurs choses
> qui soient arriv�s � TeX depuis quelques temps, alors profitons-en au
> lieu de critiquer vainement.
J'en profite pour dire que j'ai compil� la doc de pgf (pgf CVS
2009-12-05) avec lualatex version 0.46.0 et je dois dire que �a se passe
sans probl�me (juste penser � remplacer inputenc par luainputenc). Sur
des documents aussi longs � compiler, j'aurai d� tester aussi la vitesse
de compilation par rapport � pdftex.
En tous cas, oui luatex c'est l'avenir de tex et �a marche d�j� pas mal
du tout et j'invite � le tester de plus en plus.
Pour ce qui est de la pertinence du choix de lua, la question est encore
pos�e aujourd'hui car peu de monde visiblement ne s'y est vraiment
int�ress� de suffisamment pr�s pour s'apercevoir que c'est un choix
vraiment int�ressant. Moi aussi je me suis pos� la question il y a
quelque temps et j'ai pu lire pas mal d'arguments � ce sujet et pas
seulement ceux de Hans Hagen ou ceux de Taco. En tous cas il ne
s'agissait certainement pas de faire un choix par rapport � des
pr�f�rences personnelles en mati�re de langage de programmation (le
choix de metapost est peut-�tre plus discutable cependant pour la
programmation graphique). Je vous invite l� encore � vous renseigner et
pourquoi pas � essayer le lua.
Elie
without accents:
>
> C'est la première fois que j'entends dire que Lua est lourd.
C'est assez osé en effet...
> C'est sûr que si par philosophe TeX on entend langage zarbi qui
> rebute le nioubi alors ce genre de langage était bien mieux placé que
> Lua :-)
tout est dit...
> Au risque de passer pour un vieil aigri, j'en ai un peu soupé des trolls
> sur pourquoi Lua et ce qu'il faudrait faire à la place, alors que
> LuaTeX est le seul projet qui travaille concrètement à *ouvrir* TeX tout
> en le modernisant, qu'un travail énorme est fait et que ça ouvre la voie à
> tout plein de choses (dont souvent, précisément ce qu'on dit qu'il
> faudrait faire la place). Rien que pour ça, même si le langage choisi
> était mauvais ou inadapté, je pense que ça vaudrait le coup de se
> réouir de l'existence et de la santé de LuaTeX. Et il se trouve que Lua
> est loin d'être aussi mauvais ou inadapté que certains le disent, bien
> au contraire.
Tout à fait... comme tout le monde le choix de Lua m'a paru pour le
moins étrange au début, et j'aurais préféré un langage plus répandu
comme python ou perl, ou un langage carrément geek comme le sus-cité.
Il se trouve qu'après quelques heures d'utilisation il est très
difficile de se passer de Lua et tout le reste à côté devient lourd,
lent et complexe... Donc je crois sincèrement que l'utilisation de
LuaTeX fera changer d'avis bien des sceptiques !
Pou donner un exemple qui concerne peu de gens ici (mais sait-on
jamais), pas plus tard que l'autre jour je voulais faire un s à
virgule (s typiquement roumain, différent du s à cédille, et présent
dans aucun encodage TeX) eh bien je n'ai pas trouvé sans passer par
LuaTeX et une fonte otf... la résolution du problème m'a pris le temps
de me dire "tiens si j'utilisais une fonte unicode ?", alors que s'il
avait fallu que je me plonge dans l'enfer des entrailles des encodages
de caractère/encodages de fontes/fontes/fontes virtuelles de TeX ça
m'aurait pris deux jours de migraine inutile...
> Bref, à mon (pas si) humble avis, LuaTeX est une des meilleurs choses
> qui soient arrivées TeX depuis quelques temps, alors profitons-en au
> lieu de critiquer vainement.
À mon avis (pas si) vaniteux aussi !
--
Elie
JKB
Re: Luathon : on veut la mort de fr.comp.lang.lua,
> On 13 déc, 20:04, Manuel Pégourié-Gonnard <m...@elzevir.fr> wrote
> without accents:
>>
>> C'est la première fois que j'entends dire que Lua est lourd.
>
> C'est assez osé en effet...
Je parlais de l'interprète, non du langage lui-même. Analyser une
syntaxe comme celle de Lua est plus complexe et coûteux que faire la
même chose avec un langage à pile. Ça termine d'ailleurs toujours
par une transalation dans un langage à pile si on veut que le le
langage initial soit à peu près Turing équivalent.
>> C'est sûr que si par philosophe TeX on entend langage zarbi qui
>> rebute le nioubi alors ce genre de langage était bien mieux placé que
>> Lua :-)
>
> tout est dit...
>
>> Au risque de passer pour un vieil aigri, j'en ai un peu soupé des trolls
>> sur pourquoi Lua et ce qu'il faudrait faire à la place, alors que
>> LuaTeX est le seul projet qui travaille concrètement à *ouvrir* TeX tout
>> en le modernisant, qu'un travail énorme est fait et que ça ouvre la voie à
>> tout plein de choses (dont souvent, précisément ce qu'on dit qu'il
>> faudrait faire la place). Rien que pour ça, même si le langage choisi
>> était mauvais ou inadapté, je pense que ça vaudrait le coup de se
>> réouir de l'existence et de la santé de LuaTeX. Et il se trouve que Lua
>> est loin d'être aussi mauvais ou inadapté que certains le disent, bien
>> au contraire.
>
> Tout à fait... comme tout le monde le choix de Lua m'a paru pour le
> moins étrange au début, et j'aurais préféré un langage plus répandu
> comme python ou perl,
Gnîii ? Python (avec ses conditions à la noix sur les tabulations
qui sont toutes cassées en passant d'un éditeur à un autre) ? Perl ?
À choisir, je préfère encore Lua ! J'ai un exemple très bête : pour
une obscure raison, je suis _obligé_ de remplacer les tabulations
par quatre espaces par défaut sur mes machines VMS. Autant dire que
Python est tout cassé à _chaque_ fois que j'édite le truc !... Je ne
sais pas qui a pensé à cette indentation, mais j'ai parfois envie de
la fusiller avec des balles rouillées et trempées dans de l'extrait
d'ail histoire qu'il crève à la fois du tétanos et de la gangrène
gazeuse ! Oui, mon côté pervers ressort parfois... Chassez le
naturel... ;-)
> ou un langage carrément geek comme le sus-cité.
> Il se trouve qu'après quelques heures d'utilisation il est très
> difficile de se passer de Lua et tout le reste à côté devient lourd,
> lent et complexe... Donc je crois sincèrement que l'utilisation de
> LuaTeX fera changer d'avis bien des sceptiques !
Pas sûr que le choix soit conscient. Lorsque tu auras besoin d'un
langage de programmation, tu t'orienteras vers LuaTeX parce qu'il
n'existera peut-être rien d'autre. Traînant mes oripeaux dans
les specs de langages de programmation pour utilisations bizarres,
il ne me serait pas venu à l'esprit d'utiliser Lua (ni Python ni
même Perl) pour cet usage précis. Maintenant, je ne veux pas lancer
une guéguerre de clochers.
> Pou donner un exemple qui concerne peu de gens ici (mais sait-on
> jamais), pas plus tard que l'autre jour je voulais faire un s à
> virgule (s typiquement roumain, différent du s à cédille, et présent
> dans aucun encodage TeX) eh bien je n'ai pas trouvé sans passer par
> LuaTeX et une fonte otf... la résolution du problème m'a pris le temps
> de me dire "tiens si j'utilisais une fonte unicode ?", alors que s'il
> avait fallu que je me plonge dans l'enfer des entrailles des encodages
> de caractère/encodages de fontes/fontes/fontes virtuelles de TeX ça
> m'aurait pris deux jours de migraine inutile...
Là encore, on mélange deux choses : la pertinence du choix d'un
langage et la partie émergée de l'iceberg qui est l'utilisation de
ce langage par l'utilisateur final.
>> Bref, à mon (pas si) humble avis, LuaTeX est une des meilleurs choses
>> qui soient arrivées TeX depuis quelques temps, alors profitons-en au
>> lieu de critiquer vainement.
Pas sûr que sur le long terme ce soit si profitable que cela.
Que ce soit une vistoire par KO des autres candidats, certainement.
> À mon avis (pas si) vaniteux aussi !
Idem,
Elie
>
> Pas sûr que le choix soit conscient. Lorsque tu auras besoin d'un
> langage de programmation, tu t'orienteras vers LuaTeX parce qu'il
> n'existera peut-être rien d'autre. Traînant mes oripeaux dans
> les specs de langages de programmation pour utilisations bizarres,
> il ne me serait pas venu à l'esprit d'utiliser Lua (ni Python ni
> même Perl) pour cet usage précis.
Disons que tu oublies un détail qui fait pencher très clairement la
balance vers Lua : les gens ont l'habitude de ce type de syntaxe et ne
veulent pas trop se prendre le choux (TeX est déjà suffisamment
complexe comme ça), donc un langage avec une syntaxe optimisée à mort
pour la rapidité d'interprétation rebutera plus de gens qu'il n'en
attirera... et c'est aussi un des buts intéressants de LuaTeX. Sinon
de toute façon pour les trucs qui ont besoin d'une optimisation de
bourrin, les bindings C pour Lua sont assez simple et le chargement de
librairies est en train de voir le jour dans LuaTeX... je ne comprend
pas vraiment le choix d'un langage à syntaxe complexe (sauf pour le
PC) super-optimisée qui rebuterait tout le monde... mais c'est
intéressant d'avoir ce point de vue, je ne l'avais jamais vu avant.
> Maintenant, je ne veux pas lancer une guéguerre de clochers.
Un peu tard, mais on est bien d'accord, troller sur le sujet ici a une
inutilité assez prononcée...
--
Elie
Manuel Pégourié-Gonnard
> Je parlais de l'interpr�te, non du langage lui-m�me. Analyser une
> syntaxe comme celle de Lua est plus complexe et co�teux que faire la
> m�me chose avec un langage � pile. �a termine d'ailleurs toujours
> par une transalation dans un langage � pile si on veut que le le
> langage initial soit � peu pr�s Turing �quivalent.
>
En quoi est-ce que la complexit� d'analyse syntaxique est, selon toi, un
crit�re pertinent dans le choix d'un langage � m�langer � TeX ?
> Pas s�r que le choix soit conscient. Lorsque tu auras besoin d'un
> langage de programmation, tu t'orienteras vers LuaTeX parce qu'il
> n'existera peut-�tre rien d'autre. Tra�nant mes oripeaux dans
> les specs de langages de programmation pour utilisations bizarres,
> il ne me serait pas venu � l'esprit d'utiliser Lua (ni Python ni
> m�me Perl) pour cet usage pr�cis. Maintenant, je ne veux pas lancer
> une gu�guerre de clochers.
>
Tu penses qu'il fallait prendre un langage pour utilisation bizarre�?
>> Pou donner un exemple qui concerne peu de gens ici (mais sait-on
>> jamais), pas plus tard que l'autre jour je voulais faire un s �
>> virgule (s typiquement roumain, diff�rent du s � c�dille, et pr�sent
>> dans aucun encodage TeX) eh bien je n'ai pas trouv� sans passer par
>> LuaTeX et une fonte otf... la r�solution du probl�me m'a pris le temps
>> de me dire "tiens si j'utilisais une fonte unicode ?", alors que s'il
>> avait fallu que je me plonge dans l'enfer des entrailles des encodages
>> de caract�re/encodages de fontes/fontes/fontes virtuelles de TeX �a
>> m'aurait pris deux jours de migraine inutile...
>
> L� encore, on m�lange deux choses : la pertinence du choix d'un
> langage et la partie �merg�e de l'iceberg qui est l'utilisation de
> ce langage par l'utilisateur final.
>
Pour le coup, je suis d'accord avec toi.
Mais �a rejoint un peu mon argument pr�c�dent, � savoir que ce qui
compte le plus avec LuaTeX, c'est qu'il rend TeX plus flexible en nous
donnant acc�s � tout un tas de choses (on peut par exemple cr�er des
fontes virtuelles � la vol�e et leur faire subir � peu pr�s tout ce que
notre perversion peut imaginer). Que Lua ou autre chose soit utilis�
pour �a, ce n'est certes pas totalement anecdotique, mais ce qui compte
quand m�me c'est que �a soit possible.
Je trouve dommage qu'on se focalise tellement sur le langage de
programmation plut�t que sur ce qui est rendu possible (et dont
l'interface est offerte en Lua).
>>> Bref, � mon (pas si) humble avis, LuaTeX est une des meilleurs choses
>>> qui soient arriv�es TeX depuis quelques temps, alors profitons-en au
>>> lieu de critiquer vainement.
>
> Pas s�r que sur le long terme ce soit si profitable que cela.
Je suis curieux de savoir sur quels points pr�cis tu �mets des r�serves.
> Que ce soit une vistoire par KO des autres candidats, certainement.
>
Bah, �a d�pend candidat � quoi, mais si on parle d'Unicode et de fontes,
XeTeX ne me semble pas si KO que �a, hein.
Paul Gaborit
� (at) Mon, 14 Dec 2009 09:11:21 +0000 (UTC),
JKB <knat...@koenigsberg.fr> �crivait (wrote):
> L� encore, on m�lange deux choses : la pertinence du choix d'un
> langage et la partie �merg�e de l'iceberg qui est l'utilisation de
> ce langage par l'utilisateur final.
Je pense que tu oublies au moins une cat�gorie : les concepteurs de
packages.
Pour moi, il y a :
- Les utilisateurs de LaTeX. Ils sont auteurs et leur seul but est
d'obtenir le plus facilement possible un document. Ils utilisent
LaTeX parce qu'il donne de bons r�sultats. Ils ne souhaitent pas
programmer... que ce soit en TeX, en LaTeX, en Lua ou en quoi que
ce soit !
- Les concepteurs de packages qui programment en (La)TeX des
extensions permettant aux auteurs de cr�er plus facilement leurs
documents. Ce sont eux qui seront utilisateurs de Lua (en plus de
TeX et LaTeX).
- Les programmeurs de moteurs TeX. Ce sont eux qui ont modifi� les
moteurs pour les rendre plus robustes (corrections de bugs), adapt�s
(production de PDF, int�gration des commandes Postscript en plus des
DVI, gestion dynamique de la m�moire) et programmables (ajout de
points d'entr�e dans le code (La)TeX, ajout d'un langage de
programmation comme Lua). Le choix de Lua s'est fait sur des
crit�res de s�curit�, de l�g�ret� et de capacit� "objet". Le seul
autre langage qui r�unissait ces crit�res �tait ecmascript qui est
trop orient� *ML.
Forth a d�j� donn� � Postscript et on ne peut pas dire que ce soit une
r�ussite pour les programmeurs. Les langages � pile sont tr�s bien
pour les machines. Ils sont beaucoup moins bien pour les programmeurs.
JKB
Re: Luathon : on veut la mort de fr.comp.lang.lua,
> JKB scripsit :
>
>> Je parlais de l'interprète, non du langage lui-même. Analyser une
>> syntaxe comme celle de Lua est plus complexe et coûteux que faire la
>> même chose avec un langage à pile. Ça termine d'ailleurs toujours
>> par une transalation dans un langage à pile si on veut que le le
>> langage initial soit à peu près Turing équivalent.
>>
> critère pertinent dans le choix d'un langage à mélanger à TeX ?
Ça dépend ce qu'on veut en faire. Si on part du principe qu'un
interprète obèse est pertinent, on peut prendre n'importe quel langage.
J'exagère sciemment, mais l'intégration d'un langage comme Lua me
fait penser au mariage de la carpe et du lapin.
>> Pas sûr que le choix soit conscient. Lorsque tu auras besoin d'un
>> langage de programmation, tu t'orienteras vers LuaTeX parce qu'il
>> n'existera peut-être rien d'autre. Traînant mes oripeaux dans
>> les specs de langages de programmation pour utilisations bizarres,
>> il ne me serait pas venu à l'esprit d'utiliser Lua (ni Python ni
>> même Perl) pour cet usage précis. Maintenant, je ne veux pas lancer
>> une guéguerre de clochers.
>>
> Tu penses qu'il fallait prendre un langage pour utilisation bizarre ?
Je n'ai pas dit ça, mais j'ai souvent l'impression que certains
choix (ce n'est pas vrai que pour TeX) sont le fruit d'un consensus
mou.
>>> Pou donner un exemple qui concerne peu de gens ici (mais sait-on
>>> jamais), pas plus tard que l'autre jour je voulais faire un s à
>>> virgule (s typiquement roumain, différent du s à cédille, et présent
>>> dans aucun encodage TeX) eh bien je n'ai pas trouvé sans passer par
>>> LuaTeX et une fonte otf... la résolution du problème m'a pris le temps
>>> de me dire "tiens si j'utilisais une fonte unicode ?", alors que s'il
>>> avait fallu que je me plonge dans l'enfer des entrailles des encodages
>>> de caractère/encodages de fontes/fontes/fontes virtuelles de TeX ça
>>> m'aurait pris deux jours de migraine inutile...
>>
>> Là encore, on mélange deux choses : la pertinence du choix d'un
>> langage et la partie émergée de l'iceberg qui est l'utilisation de
>> ce langage par l'utilisateur final.
>>
> Pour le coup, je suis d'accord avec toi.
>
> Mais ça rejoint un peu mon argument précédent, à savoir que ce qui
> compte le plus avec LuaTeX, c'est qu'il rend TeX plus flexible en nous
> donnant accès à tout un tas de choses (on peut par exemple créer des
> fontes virtuelles à la volée et leur faire subir à peu près tout ce que
> notre perversion peut imaginer). Que Lua ou autre chose soit utilisé
> pour ça, ce n'est certes pas totalement anecdotique, mais ce qui compte
> quand même c'est que ça soit possible.
>
> Je trouve dommage qu'on se focalise tellement sur le langage de
> programmation plutôt que sur ce qui est rendu possible (et dont
> l'interface est offerte en Lua).
>
>>>> Bref, à mon (pas si) humble avis, LuaTeX est une des meilleurs choses
>>>> qui soient arrivées TeX depuis quelques temps, alors profitons-en au
>>>> lieu de critiquer vainement.
>>
>> Pas sûr que sur le long terme ce soit si profitable que cela.
>
> Je suis curieux de savoir sur quels points précis tu émets des réserves.
Pour moi, LuaTeX fait un grand écart en essayant de concilier deux
mondes différents et c'est en ça que _pour moi_, le choix de Lua est
sujet à critiques. L'interprète TeX a un certain nombre de défauts,
mais son fonctionnement est plus celui d'une machine à états
qu'autre chose. C'est un langage à macros, en FORTH, on parlerait de
définitions, mais le principe est le même, on développe jusqu'à ce
qu'il n'y ait plus rien à développer et on regarde ce que ça donne
(je simplifie, prière de ne pas rentrer dans les cas particuliers de
l'expansion). Donc toujours _pour moi_, je trouve plus logique
quitte à intégrer un langage de plus haut niveau et plus accessible
au commun des mortels, d'utiliser un langage comme FORTH (ou
d'autres du même tonneau) et des wrappers vers d'autres langages à
partir de là, quitte à proposer Lua comme extension.
La critique que je pourrais faire n'est pas contre Lua, mais contre
la façon dont ça se présente (encore que je n'aime pas Lua, mais
c'est une réaction épidermique qui n'engage que moi). J'ai aussi
peur que tout le boulot fait par l'équipe de LuaTeX ne serve au
final à rien parce que trop restrictif à l'utilisation de Lua (et
ça, je trouve ça vraiment dommage).
>> Que ce soit une vistoire par KO des autres candidats, certainement.
>>
> Bah, ça dépend candidat à quoi, mais si on parle d'Unicode et de fontes,
> XeTeX ne me semble pas si KO que ça, hein.
Elie
> J'ai aussi
> peur que tout le boulot fait par l'équipe de LuaTeX ne serve au
> final à rien parce que trop restrictif à l'utilisation de Lua (et
> ça, je trouve ça vraiment dommage).
Je ne comprend pas vraiment cette phrase... à ce moment là que dire de
XeTeX, qui est trop restrictif à l'utilisation de TeX ! A part les
gens allergiques aux langages accessible je ne comprend pas vraiment
pourquoi l'utilisation de Lua est restrictive...
Par contre je ne partage pas ce genre de peurs : LuaTeX arrive
quasiment au même niveau que XeTeX d'un point de vue utilisateur final
pour les nouvelles features (fontspec marche), et est largement
meilleur au niveau de la rétro-compatibilité (luainputenc marche bien
mieux que xetex-inputenc)... Ça plus la réécriture en C fait que ce
sera tout sauf inutile... mais ça n'engage que moi.
--
Elie
Paul Gaborit
� (at) Tue, 15 Dec 2009 10:16:35 +0000 (UTC),
JKB <knat...@koenigsberg.fr> �crivait (wrote):
> Le 14-12-2009, ? propos de
> Re: Luathon : on veut la mort de fr.comp.lang.lua,
> Manuel P�gouri�-Gonnard ?crivait dans fr.comp.text.tex :
>> JKB scripsit :
>>
>>> Je parlais de l'interpr�te, non du langage lui-m�me. Analyser une
>>> syntaxe comme celle de Lua est plus complexe et co�teux que faire la
>>> m�me chose avec un langage � pile. �a termine d'ailleurs toujours
>>> par une transalation dans un langage � pile si on veut que le le
>>> langage initial soit � peu pr�s Turing �quivalent.
>>>
>> En quoi est-ce que la complexit� d'analyse syntaxique est, selon toi, un
>> crit�re pertinent dans le choix d'un langage � m�langer � TeX ?
>
> �a d�pend ce qu'on veut en faire. Si on part du principe qu'un
> interpr�te ob�se est pertinent, on peut prendre n'importe quel langage.
> J'exag�re sciemment, mais l'int�gration d'un langage comme Lua me
> fait penser au mariage de la carpe et du lapin.
Ok pour les interpr�teurs ob�se... Mais l'int�pr�teur Lua n'est pas
ob�se. C'est m�me l'un des plus petits dans sa cat�gorie.
> Pour moi, LuaTeX fait un grand �cart en essayant de concilier deux
> mondes diff�rents et c'est en �a que _pour moi_, le choix de Lua est
> sujet � critiques. L'interpr�te TeX a un certain nombre de d�fauts,
> mais son fonctionnement est plus celui d'une machine � �tats
> qu'autre chose. C'est un langage � macros, en FORTH, on parlerait de
> d�finitions, mais le principe est le m�me, on d�veloppe jusqu'� ce
> qu'il n'y ait plus rien � d�velopper et on regarde ce que �a donne
> (je simplifie, pri�re de ne pas rentrer dans les cas particuliers de
> l'expansion). Donc toujours _pour moi_, je trouve plus logique
> quitte � int�grer un langage de plus haut niveau et plus accessible
> au commun des mortels, d'utiliser un langage comme FORTH (ou
> d'autres du m�me tonneau) et des wrappers vers d'autres langages �
> partir de l�, quitte � proposer Lua comme extension.
Lua a �t� con�ue explicitement pour servir de langage de glue. Il n'y
a que tr�s peu de langages existants qui permettent de le faire.
De plus, il ne faut pas confondre paradigme de programmation et
support r�el de ces programmes. Avec votre raisonnement, nous
n'aurions que des langages � pile puisque c'est la seule
impl�mentation existante dans les processeurs (je mets de c�t� les
quelques processeurs bas�s sur Lisp ou autres excentricites qui n'ont
pas v�cu).
Le paradigme de programmation ne d�pend pas du langage utilis� : on
peut tr�s bien faire de la programmation orient�e objet en assembleur,
ou du fonctionnel avec TeX, ou du d�claratif en Lua, ou du proc�dural
en Python, etc. Et la machine r�elle importe peu pour d�cider quel
paradigme utilis�.
Pour moi, l'un des int�r�ts de Lua est d'ouvir le moteur TeX �
d'autres paradigmes de programmation que celui offert naturellement
par le langage de macros de TeX.
Pour terminer, comme Lua est tr�s rapide et puissant pour faire de la
glue, cela ouvre la possibilit� d'utiliser d'autres langages par
dessus (et pourquoi pas du Forth) sans trop de p�nalit�s. Le boulot
initial de placement intelligent de points d'entr�e dans le moteur TeX
sera d�ja fait.
Dominique MICOLLET
> Lua a ￜtￜ conￜue explicitement pour servir de langage de glue. Il n'y
> a que trï¿œs peu de langages existants qui permettent de le faire.
Veuillez par avance me pardonner mon ignorance : qu'est ce qu'un language de
glue ?
--
Dominique MICOLLET
Adresse email : enlever deux francs
Manuel Pégourié-Gonnard
> Paul Gaborit wrote:
>
>> Lua a �t� con�ue explicitement pour servir de langage de glue. Il n'y
>> a que tr�s peu de langages existants qui permettent de le faire.
> Veuillez par avance me pardonner mon ignorance : qu'est ce qu'un
> language de glue ?
>
Votre ignorance est toute pardonn�e, je ne pense pas que l'expression
soit si courante que �a. C'est un langage qu'on peut facilement utiliser
pour � coller � entre elles diff�rentes parties plus ou moins
h�t�rog�nes.
En l'occurence, il s'agit de coller TeX (agr�ment� de nouveaux points
d'entr�es), fontforge (ou plus tard une autre biblioth�que sachant
manipuler les formats de fontes courants), mplib, des biblioth�ques
graphiques, etc. et de pemettre � l'utilisateur interm�diaire
(concepteru de formats et modules, par opposition � l'utilisateur final)
de manipuler tout �a de fa�on aussi confortable que possible.
Paul Gaborit
� (at) Tue, 15 Dec 2009 18:01:41 +0100 (CET),
Manuel P�gouri�-Gonnard <m...@elzevir.fr> �crivait (wrote):
> Dominique MICOLLET scripsit :
>
>> Paul Gaborit wrote:
>>
>>> Lua a �t� con�ue explicitement pour servir de langage de glue. Il n'y
>>> a que tr�s peu de langages existants qui permettent de le faire.
>> Veuillez par avance me pardonner mon ignorance : qu'est ce qu'un
>> language de glue ?
>>
> Votre ignorance est toute pardonn�e, je ne pense pas que l'expression
> soit si courante que �a. C'est un langage qu'on peut facilement utiliser
> pour � coller � entre elles diff�rentes parties plus ou moins
> h�t�rog�nes.
(... et la suite...)
Tr�s bonne r�ponse de Manuel... Et j'ajoute ce message pour signaler
que le changement de sujet, que je n'avais pas vu tout de suite, m'a
bien fait rire !
Manuel Pégourié-Gonnard
> Le 14-12-2009, ? propos de
> Re: Luathon : on veut la mort de fr.comp.lang.lua,
> Manuel P�gouri�-Gonnard ?crivait dans fr.comp.text.tex :
>> En quoi est-ce que la complexit� d'analyse syntaxique est, selon toi, un
>> crit�re pertinent dans le choix d'un langage � m�langer � TeX ?
>
> �a d�pend ce qu'on veut en faire. Si on part du principe qu'un
> interpr�te ob�se est pertinent, on peut prendre n'importe quel langage.
> J'exag�re sciemment, mais l'int�gration d'un langage comme Lua me
> fait penser au mariage de la carpe et du lapin.
>
Comme le dit Paul, l'interpreteur Lua est un des plus petits du genre,
car cel� fait partie des objectifs du langage. Partant de l�, si on veut
trouver plus petit, il faut changer de cat�gorie, ce qui a un impact sur
l'accessibilit� du langage au programmeur moyen. Sachant que pour
programmer en LuaTeX il faudra toujours avoir de bonnes bases de TeX qui
n'est d�j� pas tr�s accessible, l'accessibilit� me para�t ici
importante.
Pour sacrifier cette accessibilit� � un interpr�teur plus l�ger, il
faudrait que la l�g�ret� soit particuli�tement importante. Je ne vois
pas en quoi elle le serait ici.
Par ailleurs, si l'on en croit le graphique au d�but de
http://luatex.org/talks/tug2008-taco-luatex.pdf
l'interpr�teur Lua ne repr�sente pas la majeure partie du code de
LuaTeX.
> Je n'ai pas dit �a, mais j'ai souvent l'impression que certains
> choix (ce n'est pas vrai que pour TeX) sont le fruit d'un consensus
> mou.
>
En l'occurence, on ne peut sans doute pas dire qu'il y a un consensus
fort a priori dans la ��communaut� TeX��, mais de la part des
programmeurs, je n'ai pas l'impression qu'il s'agisse d'un choix par
d�faut, au contraire.
Par ailleurs, je ne connais personne ayant effectivement utilis� la b�te
(et je ne parle pas d'utilsiateur final, mais bien de d�veloppeur) qui
s'en soit plaint.
> La critique que je pourrais faire n'est pas contre Lua, mais contre
> la fa�on dont �a se pr�sente (encore que je n'aime pas Lua, mais
> c'est une r�action �pidermique qui n'engage que moi).
Personnellement, j'aime bien Lua, mais j'essaie volontairement ici de ne
pas (trop) prendre sa d�fense afin d'�viter une querelle de langage.
> J'ai aussi
> peur que tout le boulot fait par l'�quipe de LuaTeX ne serve au
> final � rien parce que trop restrictif � l'utilisation de Lua (et
> �a, je trouve �a vraiment dommage).
>
C'est le point que j'ai visiblement beaucoup de mal � exprimer
correctement�: l'�quipe LuaTeX effectue un travail de fond important
sur la base de code de TeX. (Au passage, elle l'a convertit en C, mais
le plus important, ce sont les remaniements structurels.) Cr�er des
nouveau points d'entr�e dans ce code n'a rien de trivial, il fallait
que quelqu'un le fasse un jour et c'est en train d'�tre fait.
M�me si dans quelques ann�es l'exp�rience prouve que le mariage de Lua
et de TeX �tait une mauvaise id�e, LuaTeX aura servir de pr�curseur dans
le travail d'ouverture et de modularisation du code de TeX.
� part LuaTeX, le seul projet dont j'ai entendu parler qui vise �
remanier le code de TeX dans cette optique est un projet de David Fuchs
qui veut r�impl�menter TeX en orient� objet propre, de fa�on progressive
et avec une suite de tests exhaustive pour assurer la compatibilit�. Cf
http://www.tug.org/interviews/fuchs.html
Mais je n'ai jamais vu de r�sultat concret de ce projet, alors que
LuaTeX est une r�alit� avec laquelle on peut exp�rimenter aujourd'hui.
Bref, ind�pendamment du fait qu'� mon avis, Lua est un langage adapt�,
Lua en lui-m�me n'est pas � mes yeux l'avanc�e la plus importante faite
par le projet LuaTeX. Ce sont plut�t les nouveaux points d'entr�e dans
TeX, que ce soit pour l'utilisateur-programmeur ou pour l'interfa�age
avec des biblioth�ques ext�rieures, qui me paraissent essentiels.
JKB
Re: Luathon : on veut la mort de fr.comp.lang.lua,
> JKB scripsit :
>
>> Le 14-12-2009, ? propos de
>> Re: Luathon : on veut la mort de fr.comp.lang.lua,
>>> En quoi est-ce que la complexité d'analyse syntaxique est, selon toi, un
>>> critère pertinent dans le choix d'un langage à mélanger à TeX ?
>>
>> Ça dépend ce qu'on veut en faire. Si on part du principe qu'un
>> interprète obèse est pertinent, on peut prendre n'importe quel langage.
>> fait penser au mariage de la carpe et du lapin.
>>
> Comme le dit Paul, l'interpreteur Lua est un des plus petits du genre,
> trouver plus petit, il faut changer de catégorie, ce qui a un impact sur
> l'accessibilité du langage au programmeur moyen. Sachant que pour
> programmer en LuaTeX il faudra toujours avoir de bonnes bases de TeX qui
> importante.
>
> Pour sacrifier cette accessibilité à un interpréteur plus léger, il
> faudrait que la légèreté soit particuliètement importante. Je ne vois
> pas en quoi elle le serait ici.
Pour moi, il y a deux choses : la taille en mémoire et la rapidité
du code. Je corrige actuellement une thèse d'histoire qui est un
pavé de plus de 2000 pages et je mets littéralement la machine à
genou lorsque je compile (et comme je suis aussi obligé de débugguer
des macros absconses parce que les historiens ont des façons de
faire assez spéciales...). Bref, compacité et rapidité sont pour moi
indispensables. Maintenant, il est vrai que sur les machines
actuelles, avec des documents standard, on n'a pas trop ce genre de
problèmes.
> Par ailleurs, si l'on en croit le graphique au début de
>
> http://luatex.org/talks/tug2008-taco-luatex.pdf
>
> l'interpréteur Lua ne représente pas la majeure partie du code de
> LuaTeX.
Et ?
>> Je n'ai pas dit ça, mais j'ai souvent l'impression que certains
>> choix (ce n'est pas vrai que pour TeX) sont le fruit d'un consensus
>> mou.
>>
> En l'occurence, on ne peut sans doute pas dire qu'il y a un consensus
> fort a priori dans la « communauté TeX »,
Nous sommes bien d'acoord ;-)
> mais de la part des
> programmeurs, je n'ai pas l'impression qu'il s'agisse d'un choix par
> défaut, au contraire.
J'aimerais justement avoir des arguments forts du choix. Des vrais
arguments, pas de ceux qu'on ne donne lorsqu'on choisi python ou
perl au détriment de choses bien plus adaptées mais moins
populaires.
> Par ailleurs, je ne connais personne ayant effectivement utilisé la bête
> (et je ne parle pas d'utilsiateur final, mais bien de développeur) qui
> s'en soit plaint.
Là encore, on mélange deux choses : le choix technique du langage et
le fait que LuaTeX comble un besoin. Si j'ai une vis et qu'on me
présente un marteau pour l'enfoncer, je serai très content si jamais
je n'avais vu un tournevis...
>> La critique que je pourrais faire n'est pas contre Lua, mais contre
>> la façon dont ça se présente (encore que je n'aime pas Lua, mais
>> c'est une réaction épidermique qui n'engage que moi).
>
> Personnellement, j'aime bien Lua, mais j'essaie volontairement ici de ne
> pas (trop) prendre sa défense afin d'éviter une querelle de langage.
Je n'aime pas (mais j'essaye aussi d'en faire abstraction). Disons
que j'ai une sainte horreur des langages interprétés à notation
infixe pour avoir dû écrire des specs de langages et avoir poussé
ses specs dans leurs retranchements...
>> J'ai aussi
>> peur que tout le boulot fait par l'équipe de LuaTeX ne serve au
>> final à rien parce que trop restrictif à l'utilisation de Lua (et
>> ça, je trouve ça vraiment dommage).
>>
> C'est le point que j'ai visiblement beaucoup de mal à exprimer
> correctement : l'équipe LuaTeX effectue un travail de fond important
> sur la base de code de TeX. (Au passage, elle l'a convertit en C, mais
> le plus important, ce sont les remaniements structurels.) Créer des
> nouveau points d'entrée dans ce code n'a rien de trivial, il fallait
> que quelqu'un le fasse un jour et c'est en train d'être fait.
Ça, effectivement, c'est un point qui devait être fait. Mais c'est
indépendant de tout langage externe (si c'est bien fait et je pense
que ça l'est).
> Même si dans quelques années l'expérience prouve que le mariage de Lua
> et de TeX était une mauvaise idée, LuaTeX aura servir de précurseur dans
> le travail d'ouverture et de modularisation du code de TeX.
>
> À part LuaTeX, le seul projet dont j'ai entendu parler qui vise à
> remanier le code de TeX dans cette optique est un projet de David Fuchs
> qui veut réimplémenter TeX en orienté objet propre, de façon progressive
> et avec une suite de tests exhaustive pour assurer la compatibilité. Cf
>
> http://www.tug.org/interviews/fuchs.html
>
> Mais je n'ai jamais vu de résultat concret de ce projet, alors que
> LuaTeX est une réalité avec laquelle on peut expérimenter aujourd'hui.
>
> Bref, indépendamment du fait qu'à mon avis, Lua est un langage adapté,
> Lua en lui-même n'est pas à mes yeux l'avancée la plus importante faite
> par le projet LuaTeX. Ce sont plutôt les nouveaux points d'entrée dans
> TeX, que ce soit pour l'utilisateur-programmeur ou pour l'interfaçage
> avec des bibliothèques extérieures, qui me paraissent essentiels.
Là, on est parfaitement d'accord.
Paul Gaborit
� (at) Tue, 15 Dec 2009 20:17:00 +0000 (UTC),
JKB <knat...@koenigsberg.fr> �crivait (wrote):
> Le 15-12-2009, ? propos de
> Re: Luathon : on veut la mort de fr.comp.lang.lua,
> Manuel P�gouri�-Gonnard ?crivait dans fr.comp.text.tex :
>>
>> mais de la part des programmeurs, je n'ai pas l'impression qu'il
>> s'agisse d'un choix par d�faut, au contraire.
>
> J'aimerais justement avoir des arguments forts du choix. Des vrais
> arguments, pas de ceux qu'on ne donne lorsqu'on choisi python ou
> perl au d�triment de choses bien plus adapt�es mais moins
> populaires.
Certains arguments ont �t� donn�s ici m�me : la s�curit�, la l�g�ret�,
la facilit� d'apprentissage, la puissance expressive du langage,
l'orientation objet, la conception int�grant d�s le d�part la notion
de langage de glue, l'impl�mentation d�j� existante... J'en oublie.
>> Par ailleurs, je ne connais personne ayant effectivement utilis� la b�te
>> (et je ne parle pas d'utilsiateur final, mais bien de d�veloppeur) qui
>> s'en soit plaint.
>
> L� encore, on m�lange deux choses : le choix technique du langage et
> le fait que LuaTeX comble un besoin. Si j'ai une vis et qu'on me
> pr�sente un marteau pour l'enfoncer, je serai tr�s content si jamais
> je n'avais vu un tournevis...
Mis � part Forth qui ne r�pond pas � certains crit�res �nnonc�s
ci-dessus, quel(s) autre(s) langage(s) auriez-vous sugg�r� ?
>> Personnellement, j'aime bien Lua, mais j'essaie volontairement ici de ne
>> pas (trop) prendre sa d�fense afin d'�viter une querelle de langage.
>
> Je n'aime pas (mais j'essaye aussi d'en faire abstraction). Disons
> que j'ai une sainte horreur des langages interpr�t�s � notation
> infixe pour avoir d� �crire des specs de langages et avoir pouss�
> ses specs dans leurs retranchements...
C'est s�r qu'en �liminant d'office tous les langages � notation
infixe, cela ne laisse plus beaucoup de choix... Mais vos difficult�s
de mises en oeuvre sont-elles une raison suffisante pour rejeter toute
une famille de langages ? ;-)
Manuel Pégourié-Gonnard
> Pour moi, il y a deux choses : la taille en m�moire et la rapidit�
> du code. Je corrige actuellement une th�se d'histoire qui est un
> pav� de plus de 2000 pages et je mets litt�ralement la machine �
> genou lorsque je compile (et comme je suis aussi oblig� de d�bugguer
> des macros absconses parce que les historiens ont des fa�ons de
> faire assez sp�ciales...). Bref, compacit� et rapidit� sont pour moi
> indispensables. Maintenant, il est vrai que sur les machines
> actuelles, avec des documents standard, on n'a pas trop ce genre de
> probl�mes.
>
Pour lme d�bogage, on a pas forc�ment besoin de recompiler l'ensemble
des 2000 pages � chaque fois...
>> l'interpr�teur Lua ne repr�sente pas la majeure partie du code de
>> LuaTeX.
>
> Et ?
>
Et donc, m�me si on divisait par 2 la taille de l'interpr�teur, on ne
diminuerait pas tant que �a la complexit� globale du tout. Ce qui
relativise pas mal l'importance de la taille de l'interpr�teur.
> J'aimerais justement avoir des arguments forts du choix. Des vrais
> arguments, pas de ceux qu'on ne donne lorsqu'on choisi python ou
> perl au d�triment de choses bien plus adapt�es mais moins
> populaires.
>
Je ne sourais pas les r�sumer mieux que Paul.
JKB
Re: Luathon : on veut la mort de fr.comp.lang.lua,
>
> À (at) Tue, 15 Dec 2009 20:17:00 +0000 (UTC),
> JKB <knat...@koenigsberg.fr> écrivait (wrote):
>
>> Le 15-12-2009, ? propos de
>> Re: Luathon : on veut la mort de fr.comp.lang.lua,
>>>
>>> mais de la part des programmeurs, je n'ai pas l'impression qu'il
>>
>> J'aimerais justement avoir des arguments forts du choix. Des vrais
>> arguments, pas de ceux qu'on ne donne lorsqu'on choisi python ou
>> populaires.
>
> Certains arguments ont été donnés ici même : la sécurité, la légèreté,
> la facilité d'apprentissage, la puissance expressive du langage,
> l'orientation objet, la conception intégrant dès le départ la notion
> de langage de glue, l'implémentation déjà existante... J'en oublie.
>
>>> Par ailleurs, je ne connais personne ayant effectivement utilisé la bête
>>> (et je ne parle pas d'utilsiateur final, mais bien de développeur) qui
>>> s'en soit plaint.
>>
>> Là encore, on mélange deux choses : le choix technique du langage et
>> le fait que LuaTeX comble un besoin. Si j'ai une vis et qu'on me
>> je n'avais vu un tournevis...
>
> ci-dessus, quel(s) autre(s) langage(s) auriez-vous suggéré ?
Je n'ai pas réfléchi plus que ça, mais je serais a priori parti sur
une notation postfixe. Notation postfixe ne veut pas dire langage
'write only'. J'ai vu passer PostScript un peu plus haut. PostScript
est effectivement un langage à pile mais il n'a pas été conçu pour
être lu ni même écrit à la main et je ne le comparerais à aucun
autre langage à pile.
>>> Personnellement, j'aime bien Lua, mais j'essaie volontairement ici de ne
>>> pas (trop) prendre sa défense afin d'éviter une querelle de langage.
>>
>> Je n'aime pas (mais j'essaye aussi d'en faire abstraction). Disons
>> que j'ai une sainte horreur des langages interprétés à notation
>> infixe pour avoir dû écrire des specs de langages et avoir poussé
>> ses specs dans leurs retranchements...
>
> C'est sûr qu'en éliminant d'office tous les langages à notation
> infixe, cela ne laisse plus beaucoup de choix... Mais vos difficultés
> de mises en oeuvre sont-elles une raison suffisante pour rejeter toute
> une famille de langages ? ;-)
Ce n'est pas une difficulté de mise en oeuvre, mais une limitation
;-) Je sais parfaitement évaluer une expression en notation infixe
mais la complexité de cette analyse est au mieux en n.log(n), dans
la plupart des cas en n**2. Ça peut très vite devenir pénalisant si
le code n'est pas compilé et là, on rajoute une couche de complexité.
Par ailleurs, ça finit généralement en quelque chose qui est soit
préfixe (cas général de l'assembleur) soit postfixe (cas des
langages à piles courants).
Bref, mon expérience (mais ce n'est que la mienne, hein...) me dit
que les langages à notation infixe interprétés ont des performances
médiocres et que cette médiocrité est presque toujours due à
l'analyse des instructions et non à leur exécution.
Les langages à pile style FORTH, mais ce n'est pas le seul,
permettent aussi d'écrire des choses difficiles à écrire dans
d'autres langages à moins d'artifices plus ou moins tordus.
Bon, je crois qu'on est vraiment à la limite de la charte et je
propose d'arrêter là, non ?
JKB
Re: Luathon : on veut la mort de fr.comp.lang.lua,
Manuel Pégourié-Gonnard ?crivait dans fr.comp.text.tex :
>
>> Pour moi, il y a deux choses : la taille en mémoire et la rapidité
>> du code. Je corrige actuellement une thèse d'histoire qui est un
>> pavé de plus de 2000 pages et je mets littéralement la machine à
>> genou lorsque je compile (et comme je suis aussi obligé de débugguer
>> des macros absconses parce que les historiens ont des façons de
>> indispensables. Maintenant, il est vrai que sur les machines
>> actuelles, avec des documents standard, on n'a pas trop ce genre de
>>
> Pour lme débogage, on a pas forcément besoin de recompiler l'ensemble
> des 2000 pages à chaque fois...
En l'occurrence si puisque ça touche des histoires d'index multiples
et de bibliographies multiples, mais ce serait trop long à expliquer
ici...
Dominique MICOLLET
> ...je ne pense pas que l'expression
> soit si courante que ï¿œa
......
> de manipuler tout ï¿œa de faï¿œon aussi confortable que possible.
>
Merci. Il va falloir que je regarde cela de plus prï¿œs.
Manuel Pégourié-Gonnard
> Le 15-12-2009, ? propos de
> Re: Luathon : on veut la mort de fr.comp.lang.lua,
> Paul Gaborit ?crivait dans fr.comp.text.tex :
>> Certains arguments ont �t� donn�s ici m�me : la s�curit�, la l�g�ret�,
>> la facilit� d'apprentissage, la puissance expressive du langage,
>> l'orientation objet, la conception int�grant d�s le d�part la notion
>> de langage de glue, l'impl�mentation d�j� existante... J'en oublie.
>>
> [...]
> Je n'ai pas r�fl�chi plus que �a, mais je serais a priori parti sur
> une notation postfixe. Notation postfixe ne veut pas dire langage
> 'write only'.
Peut-�tre pas, mais niveau facilit� d'apprentissage, on fait un sacr�
bond en arri�re, pour le commun des mortels. Et comme on l'a d�j� dit,
c'est un des points importants.
> Ce n'est pas une difficult� de mise en oeuvre, mais une limitation
> ;-) Je sais parfaitement �valuer une expression en notation infixe
> mais la complexit� de cette analyse est au mieux en n.log(n), dans
> la plupart des cas en n**2. �a peut tr�s vite devenir p�nalisant si
> le code n'est pas compil� et l�, on rajoute une couche de complexit�.
Si on veut �tre pr�cis, Lua est compil� � la vol�e, pas interpr�t�.
Concernant LuaTeX en particulier (si on veut rester en charte), du
bytecode peut �tre int�gr� au format. �a fait d�j� une partie qui n'est
pas � re-compiler � chaque fois. Bon, l'argument est limit�, il reste
toujours le code ext�rieur au format � compiler � chaque fois
> Par ailleurs, �a finit g�n�ralement en quelque chose qui est soit
> pr�fixe (cas g�n�ral de l'assembleur) soit postfixe (cas des
> langages � piles courants).
>
Oui, mais en m�me temps, si on a invent� les langages de haut niveau,
c'est peut-�tre pas pas hasard, hein :-) Je vous crois tr�s volontiers
sur le fait que les langages en notation postfixe soit intrins�quement
plus rapide � interpr�ter, mais.
Le point sur lequel vous ne me convainquez pas (et que je n'ai m�me pas
l'impression de vous voir aborder), c'est pourquoi cette rapid� serait
plus importante que la facilit� d'apprentissage du langage, dans le cas
particulier de LuaTeX (sans parler des autres particuliarit�s de Lua qui
le rendent adapt� � cet usage particulier, comme sa conception en tant
que langage de glue).
JKB
Re: Luathon : on veut la mort de fr.comp.lang.lua,
>
>> Le 15-12-2009, ? propos de
>> Re: Luathon : on veut la mort de fr.comp.lang.lua,
>> Paul Gaborit ?crivait dans fr.comp.text.tex :
>>> l'orientation objet, la conception intégrant dès le départ la notion
>>> de langage de glue, l'implémentation déjà existante... J'en oublie.
>>>
>> [...]
>> Je n'ai pas réfléchi plus que ça, mais je serais a priori parti sur
>> une notation postfixe. Notation postfixe ne veut pas dire langage
>> 'write only'.
>
> bond en arrière, pour le commun des mortels. Et comme on l'a déjà dit,
> c'est un des points importants.
>
>> ;-) Je sais parfaitement évaluer une expression en notation infixe
>> mais la complexité de cette analyse est au mieux en n.log(n), dans
>> le code n'est pas compilé et là, on rajoute une couche de complexité.
>
> Si on veut être précis, Lua est compilé à la volée, pas interprété.
Compilé à la volée, ça veut dire au moins une passe pour analyser le
code et le convertir en quelque chose de compréhensible. Si la durée
de cette analyse est supérieure à celle de l'exécution effective du
code, le bytecode ne sert à rien.
> Concernant LuaTeX en particulier (si on veut rester en charte), du
> bytecode peut être intégré au format. Ça fait déjà une partie qui n'est
> pas à re-compiler à chaque fois. Bon, l'argument est limité, il reste
> toujours le code extérieur au format à compiler à chaque fois
>
>> Par ailleurs, ça finit généralement en quelque chose qui est soit
>> préfixe (cas général de l'assembleur) soit postfixe (cas des
>> langages à piles courants).
>>
> Oui, mais en même temps, si on a inventé les langages de haut niveau,
> c'est peut-être pas pas hasard, hein :-) Je vous crois très volontiers
> sur le fait que les langages en notation postfixe soit intrinsèquement
> plus rapide à interpréter, mais.
Je ne vois toujours pas en quoi un langage à notation postixe serait
plus au ou plus bas niveau qu'un langage à notation infixe.
> Le point sur lequel vous ne me convainquez pas (et que je n'ai même pas
> l'impression de vous voir aborder), c'est pourquoi cette rapidé serait
> plus importante que la facilité d'apprentissage du langage, dans le cas
> particulier de LuaTeX (sans parler des autres particuliarités de Lua qui
> le rendent adapté à cet usage particulier, comme sa conception en tant
> que langage de glue).
Je ne voulais absolument pas lancer une guerre de clocher.
Maintenant, je pars du principe certainement idiot que l'utilisateur
moyen de LaTeX (ou a fortiori de TeX) connaît un tant soit peu la
syntaxe des macros (La)TeX dont le moins qu'on puisse dire est
qu'elle n'est pas triviale (et je ne parle pas de leur expansion,
parce que là, il faut vraiment commencer à 'toucher' TeX pour
comprendre sa subtilité et la nécessité de choses comme
\expandafter). Je ne suis donc pas convaincu que la facilité
d'utilisation de Lua soit un argument de poids puisque seuls ceux
qui se sont déjà paluchés (La)TeX vont s'amuser avec Lua. Tous les
autres utilisateurs se contenteront d'utiliser des macros certes
écrites pour certaines avec Lua, mais sans jamais aller outre
l''API' de LuaTeX.
Concernant la rapidité, ça peut être quelque chose non de
discriminant mais de confort d'utilisation. Dans mon cas, vu ce que
je fais actuellement avec TeX, je n'apprécierai que très modérément
une augmentation de la durée de compilation. Je suis parfaitement
d'accord que pour la plupart du monde, c'est un point négligeable,
mais le truc sur lequel je bosse actuellement met plusieurs minutes
à compiler (avec cinq passes de compilations pour les indexes, les
bibliographies et j'en passe...).
Elie
>
> Je ne suis donc pas convaincu que la facilité
> d'utilisation de Lua soit un argument de poids puisque seuls ceux
> qui se sont déjà paluchés (La)TeX vont s'amuser avec Lua. Tous les
> autres utilisateurs se contenteront d'utiliser des macros certes
> écrites pour certaines avec Lua, mais sans jamais aller outre
> l''API' de LuaTeX.
Je ne suis pas convaincu par ça : pour faire des choses compliquées un
peu proprement, beaucoup de gens vont pouvoir faire en Lua ce qu'ils
ne voulaient pas faire en TeX parceque trop illisible et
inmaintenable ; par exemple des tableaux qu'on parcoure avec un
vulgaire for, des formules de maths un peu compliquées (je parle de
calcul, pas d'affichage), etc. Il suffira de connaître du TeX de base
avec lequel on formate habituellement un document, Lua (très simple à
apprendre, ayant une syntaxe assez proche des langages populaires),
\directlua et tex.print pour faire ça (30s d'apprentissage), et sans
plonger dans les arcanes de TeX, qui sont bieeeeen plus difficiles à
maîtriser que ces 4 choses. Je crois sincèrement que c'est une
demande ; peut-être pas de tout le monde (pas de JKB aparrement), mais
les utilisations de TeX sont assez variées, et il y aura un public
pour ça.
--
Elie
Manuel Pégourié-Gonnard
>> Si on veut �tre pr�cis, Lua est compil� � la vol�e, pas interpr�t�.
>
> Compil� � la vol�e, �a veut dire au moins une passe pour analyser le
> code et le convertir en quelque chose de compr�hensible. Si la dur�e
> de cette analyse est sup�rieure � celle de l'ex�cution effective du
> code, le bytecode ne sert � rien.
>
Oui, c'est pour �a que je pr�cisais que dans certains cas, le bytecode
pourrait �tre stock�. Mais c'est vrai que ces cas ne sont pas
majoritaires.
>> Concernant LuaTeX en particulier (si on veut rester en charte), du
>> bytecode peut �tre int�gr� au format. �a fait d�j� une partie qui n'est
>> pas � re-compiler � chaque fois. Bon, l'argument est limit�, il reste
>> toujours le code ext�rieur au format � compiler � chaque fois
>>
>> Oui, mais en m�me temps, si on a invent� les langages de haut niveau,
>> c'est peut-�tre pas pas hasard, hein :-) Je vous crois tr�s volontiers
>> sur le fait que les langages en notation postfixe soit intrins�quement
>> plus rapide � interpr�ter, mais.
>
> Je ne vois toujours pas en quoi un langage � notation postixe serait
> plus au ou plus bas niveau qu'un langage � notation infixe.
>
D�sol�, c'�tait un raccourci abusif de ma part, mais votre d�fense des
langage postfixes repose quand m�me en partie sur le fait qu'ils sont
proches de l'impl�mentation, qui est n�cessairement pr�fixe ou postfixe,
mais jamais infixe.
> Je ne voulais absolument pas lancer une guerre de clocher.
> Maintenant, je pars du principe certainement idiot que l'utilisateur
> moyen de LaTeX (ou a fortiori de TeX) conna�t un tant soit peu la
> syntaxe des macros (La)TeX dont le moins qu'on puisse dire est
> qu'elle n'est pas triviale (et je ne parle pas de leur expansion,
> parce que l�, il faut vraiment commencer � 'toucher' TeX pour
> comprendre sa subtilit� et la n�cessit� de choses comme
> \expandafter). Je ne suis donc pas convaincu que la facilit�
> d'utilisation de Lua soit un argument de poids puisque seuls ceux
> qui se sont d�j� paluch�s (La)TeX vont s'amuser avec Lua. Tous les
> autres utilisateurs se contenteront d'utiliser des macros certes
> �crites pour certaines avec Lua, mais sans jamais aller outre
> l''API' de LuaTeX.
>
Je pars du m�me principe, et je me dis que si en plus de TeX il doit se
farcir un autre langage plus difficile d'acc�s, on est pas rendus. (Mais
je croyais avoir d�j� dit �a.)
Et puis n'oublions pas que parfois, la programmation Lua pourra se
substituer � la programmation TeX. Et si vous avez d�j� manipul� des
liste en TeX, sous savez que �a sera plus facile en Lua. Donc ajouter un
langage plus simple que TeX abaisse, sur certains points (pas tous, mais
certains), la difficult� d'acc�s.
> Concernant la rapidit�, �a peut �tre quelque chose non de
> discriminant mais de confort d'utilisation.
Pr�cis�ment. Alors que j'ai l'impression que la facilit� d'acquisition
peut �tre discriminante.
Bref, je vais en rester l�, j'ai l'impression qu'on commence � tourner
en rond.
Jeremy JUST
JKB <knat...@koenigsberg.fr> a écrit :
> Je corrige actuellement une thèse d'histoire qui est un pavé de plus
> de 2000 pages et je mets littéralement la machine à genou lorsque je
> compile (et comme je suis aussi obligé de débugguer des macros
> absconses parce que les historiens ont des façons de faire assez
> spéciales...). Bref, compacité et rapidité sont pour moi
> indispensables.
Je ne sais pas si chercher à minimiser le temps de compilation à tout
prix est une bonne solution à ton problème.
Moi, je constate que:
- je passe presque toujours plus de temps à taper le document avec mes
petits doigts qu'à le compiler,
- plus le langage de programmation est intuitif, moins je fais
d'erreur dans mon code, moins j'ai besoin de compilations/tests
avant d'être satisfait.
Donc il est plus important de disposer d'un langage avec lequel je
code vite et bien que d'un langage qui compile vite. Même sur mes
documents qui mettent 8 heures à compiler, je préfère un langage avec
lequel je ferai peu d'erreurs (donc avec lesquels je ne compilerai
qu'une fois ou deux) plutôt qu'un langage abscons qui me fera la
compilation en 6 heures mais avec lequel je devrais faire quinze
compilations de test pour déboguer.
Je me suis aussi laissé dire que Lua permettait d'écrire du code déjà
considérablement plus rapide que TeX (c'est, paraît-il, très sensible
avec PGF). À partir de là, est-il encore utile de pinailler sur le
temps de compilation?
--
Jérémy Just <jerem...@netcourrier.com>
Sébastien
> Je me suis aussi laissￜ dire que Lua permettait d'ￜcrire du code dￜjￜ
> considï¿œrablement plus rapide que TeX (c'est, paraï¿œt-il, trï¿œs sensible
> avec PGF).
PGF tirera ￜ long terme partie de lua mais pour l'instant je n'ai pas
l'impression que le code de PGF ait ￜtￜ optimisￜ pour LuaTeX.
> ￜ partir de lￜ, est-il encore utile de pinailler sur le
> temps de compilation?
Non tu as raison et de toutes faï¿œons, je crois que fr.comp.lang.lua est
sauvￜ ... pour quelques mois seulement.
Julien Salort
> calcul, pas d'affichage), etc. Il suffira de connaître du TeX de base
> avec lequel on formate habituellement un document, Lua (très simple à
> apprendre, ayant une syntaxe assez proche des langages populaires),
> \directlua et tex.print pour faire ça (30s d'apprentissage), et sans
> plonger dans les arcanes de TeX, qui sont bieeeeen plus difficiles à
> maîtriser que ces 4 choses.
Est-ce que ce genre de chose est déjà possible ou pas encore ? Et
est-ce qu'il existe des tutoriaux (ou des exemples) simples et
compréhensibles pour des personnes intéressées par cette utilisation de
LuaTeX plus que par ses arcanes ?
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture !
Q: Mais pourquoi citer en fin d'article est-il si effroyable ?
R: Citer en fin d'article.
Q: Quelle est la chose la plus désagréable sur les groupes de news ?
Julien Salort
> Je me suis aussi laissé dire que Lua permettait d'écrire du code déjà
> considérablement plus rapide que TeX (c'est, paraît-il, très sensible
> avec PGF). À partir de là, est-il encore utile de pinailler sur le
> temps de compilation?
PGF exploite déjà les possibilités de Lua ?
Il va vraiment falloir que je commence à regarder alors !
Manuel Pégourié-Gonnard
> Elie <elie...@telecom-bretagne.eu> writes:
>
>> calcul, pas d'affichage), etc. Il suffira de conna�tre du TeX de base
>> avec lequel on formate habituellement un document, Lua (tr�s simple �
>> apprendre, ayant une syntaxe assez proche des langages populaires),
>> \directlua et tex.print pour faire �a (30s d'apprentissage), et sans
>> plonger dans les arcanes de TeX, qui sont bieeeeen plus difficiles �
>> ma�triser que ces 4 choses.
>
> Est-ce que ce genre de chose est d�j� possible ou pas encore ?
Oui, j'ai m�me envie de dire depuis longtemps (enfin depuis que LuaTeX
est dans TeX Live, disons).
> Et
> est-ce qu'il existe des tutoriaux (ou des exemples) simples et
> compr�hensibles pour des personnes int�ress�es par cette utilisation de
> LuaTeX plus que par ses arcanes ?
>
Pas � ma connaissance. Je dirais qu'il faut commencer par apprendre un
peu de Lua, et que le bouquin � Programming in Lua�� (PIL), dont la
premi�re �dition est en ligne � <http://lua.org/pil/> est tr�s bien pour
�a (dans un premier temps, on peut se contenter de lire I.1 � I.5 puis
de survoler III). Le manuel de r�f�rence a aussi un index bien pratique.
Ensuite, on peut parcourir un peu le manuel de LuaTeX, les points les
plus int�ressants sont les parties 3 et 4.1. Ce qu'il faut en retenir,
c'est que toutes les biblioth�ques d�crites dans la partie III de PIL
sont disponibles, plus quelques autres, qu'on a acc�s � pas mal de
variables TeX, et qu'on peut cr�er en Lua du mat�riel qui sera lu par
TeX (des morceaux de source) avec tex.print.
Pour une interface un peu plus LaTeXienne, on peut se tourner vers
luatextra.
Sébastien
> Jeremy JUST <jerem...@netcourrier.com> writes:
>
>> Je me suis aussi laissé dire que Lua permettait d'écrire du code déjà
>> considérablement plus rapide que TeX (c'est, paraît-il, très sensible
>> avec PGF). À partir de là, est-il encore utile de pinailler sur le
>> temps de compilation?
>
> PGF exploite déjà les possibilités de Lua ?
Non pas du tout encore, il faut attendre, ça viendra un jour.
> Il va vraiment falloir que je commence à regarder alors !
Ben pas la peine du coup.
Elie
>
> Est-ce que ce genre de chose est déjà possible ou pas encore ?
Tout à fait ! Je l'ai utilisé abondamment dans gregorio, mais gregorio
n'est pas franchement un bon exemple de truc simple (indépendemment de
LuaTeX vs. TheRestOfTheTeXWorld)...
> Et est-ce qu'il existe des tutoriaux (ou des exemples) simples et
> compréhensibles pour des personnes intéressées par cette utilisation de
> LuaTeX plus que par ses arcanes ?
Je ne crois pas... mais c'est vraiment d'une simplicité enfantine...
j'étais vraiment étonné du point auquel tout marche même les choses
dont on se dit qu'elles pourraient vraiment facilement planter... par
exemple lire un fichier en lua, en déduire du TeX qu'on écrit avec
tex.write, ce TeX appellant lui-même du Lua (avec \directlua), qui
réécrit du TeX (toujours avec tex.write)... j'ai été impressionné que
ça ne pose aucun problème !
--
Elie
Sébastien
> Julien Salort scripsit :
>
>> Elie <elie...@telecom-bretagne.eu> writes:
>>
>>> calcul, pas d'affichage), etc. Il suffira de conna�tre du TeX de base
>>> avec lequel on formate habituellement un document, Lua (tr�s simple �
>>> apprendre, ayant une syntaxe assez proche des langages populaires),
>>> \directlua et tex.print pour faire �a (30s d'apprentissage), et sans
>>> plonger dans les arcanes de TeX, qui sont bieeeeen plus difficiles �
>>> ma�triser que ces 4 choses.
>> Est-ce que ce genre de chose est d�j� possible ou pas encore ?
>
> Oui, j'ai m�me envie de dire depuis longtemps (enfin depuis que LuaTeX
> est dans TeX Live, disons).
C'est clair. Mais disons que Julien voudrais quelques exemples concrets
pour voir comment fonctionne lua dans Luatex.
1. Il te faut avoir
2. Il faut utiliser la commande luatex \directlua{bla bla} qu'indiquait
Elie. Elle permet de lancer une instance lua. A la place de bla bla tu
mets tes lignes en lua.
3. Il faut avoir des choses sympa � faire avec lua, style des choses
faciles � faire en lua et dure en TeX/LaTeX/ConTeXt. Alors Ok, je ne
vais pas donner trop de code lua d'une part car ce serait hors charte et
ce serait sympa d'aller en parler sur fr.comp.lang.lua (�a le ferait
vivre ce groupe, il en a besoin) et d'autre part car mes connaissances
en lua sont un peu limit�es hein. Par contre je vais illustrer la
commande lua tex.print introduite par luatex. Cette commande est ultra
utiles dans LuaTeX, personne ne peut esp�rer profiter de luatex sans
comnna�tre \directlua et tex.print. Si Elie parlait de ces deux
commandes ces parce que C'EST LA BASE.
Aller assez parler, voici quelques exemples. Compilez-les avec lualatex :
EXEMPLE 1 :
\documentclass{article}
\begin{document}
\directlua{
a=3
b=2
c=a+b
tex.print(c)
}
\end{document}
Ainsi on fait faire les calculs par lua et on imprime le r�sultat (5)
dans le pdf.
Int�r�t : gain de vitesse et de pr�cision. Pour la vitesse on s'en rend
bien compte lorsque l'on a beaucoup de calculs � effectuer. Quand � la
pr�cision, voici un exemple simple montrant clairement la sup�riorit� de
lua sur TeX (ou la faiblesse manifeste de TeX) pour les calculs :
EXEMPLE 2 :
\documentclass{article}
\usepackage{luatextra}
\usepackage{tikz}
\usepackage{multido}
\begin{document}
\foreach \n in {-0.001,-0.0009,...,0.001} \n;
\vskip 3 em
\multido{\n=-0.001+0.0001}{21}{\n; }
\vskip 3 em
\directlua{
for n=-0.001,0.001,0.0001 do
tex.print(n) tex.print(";")
end
}
\end{document}
C'est JAB qui est � l'origine de ce code et comme il le disait "le score
est sans appel : lua est impeccable alors que \foreach et \multido sont
parfaitement aux fraises : "
Manuel Pégourié-Gonnard
> EXEMPLE 2 :
> [...]
> \foreach \n in {-0.001,-0.0009,...,0.001} \n;
> [...]
> \multido{\n=-0.001+0.0001}{21}{\n; }
> [...]
> \directlua{
> for n=-0.001,0.001,0.0001 do
> tex.print(n) tex.print(";")
> end
> [...]
>
> C'est JAB qui est � l'origine de ce code et comme il le disait "le score
> est sans appel : lua est impeccable alors que \foreach et \multido sont
> parfaitement aux fraises : "
Il est joli cet exemple, j'aime bien.
D'ailleurs, je me demande comment �a va �tre g�r� quand PGF se mettra �
potentiellement utiliser Lua pour les calculs. Le gain de pr�cision en
lui-m�me est souhaitable, mais il implique des probl�mes potentiels de
compatibilit�, il me semble. Si un sp�cialiste de PGF a des infos...
Sébastien
> Manuel P�gouri�-Gonnard a �crit :
>> Julien Salort scripsit :
>>
>>> Elie <elie...@telecom-bretagne.eu> writes:
>>>
>>>> calcul, pas d'affichage), etc. Il suffira de conna�tre du TeX de base
>>>> avec lequel on formate habituellement un document, Lua (tr�s simple �
>>>> apprendre, ayant une syntaxe assez proche des langages populaires),
>>>> \directlua et tex.print pour faire �a (30s d'apprentissage), et sans
>>>> plonger dans les arcanes de TeX, qui sont bieeeeen plus difficiles �
>>>> ma�triser que ces 4 choses.
>>> Est-ce que ce genre de chose est d�j� possible ou pas encore ?
>>
>> Oui, j'ai m�me envie de dire depuis longtemps (enfin depuis que LuaTeX
>> est dans TeX Live, disons).
>
> C'est clair. Mais disons que Julien voudrais quelques exemples concrets
> pour voir comment fonctionne lua dans Luatex.
>
> 1. Il te faut avoir
J'ai pas oubli� un truc l� ?
Une distribution dans laquelle il y a une version (r�cente) du moteur
LuaTeX : TeXLive 2009 tant qu'� faire.
Paul Gaborit
� (at) Fri, 18 Dec 2009 19:36:05 +0100 (CET),
Manuel P�gouri�-Gonnard <m...@elzevir.fr> �crivait (wrote):
> D'ailleurs, je me demande comment �a va �tre g�r� quand PGF se mettra �
> potentiellement utiliser Lua pour les calculs. Le gain de pr�cision en
> lui-m�me est souhaitable, mais il implique des probl�mes potentiels de
> compatibilit�, il me semble. Si un sp�cialiste de PGF a des infos...
Pour l'instant, il est possible de remplacer un moteur de calcul par
un autre mais il faut le demander. C'est la compatibilit� minimale.
Reste que les �ventuels probl�mes de compatibilit�s d�s � un
changement de pr�cision des calculs ne seront sensibles que sur des
cas particuliers.
as
Sébastien <s...@free.fr> a écrit :
> \multido{\n=-0.001+0.0001}{21}{\n; }
\multido{\n=-0.0010+0.0001}{20}{\n; }
Julien Salort
> EXEMPLE 1 :
[...]
> EXEMPLE 2 :
[...]
Effectivement, merci pour ces exemples assez démonstratifs !
Sébastien
>
>> EXEMPLE 2 :
>> [...]
>> \foreach \n in {-0.001,-0.0009,...,0.001} \n;
>> [...]
>> \multido{\n=-0.001+0.0001}{21}{\n; }
>> [...]
>> \directlua{
>> for n=-0.001,0.001,0.0001 do
>> tex.print(n) tex.print(";")
>> end
>> [...]
>>
>> C'est JAB qui est � l'origine de ce code et comme il le disait "le score
>> est sans appel : lua est impeccable alors que \foreach et \multido sont
>> parfaitement aux fraises : "
>
> Il est joli cet exemple, j'aime bien.
>
> D'ailleurs, je me demande comment �a va �tre g�r� quand PGF se mettra �
> potentiellement utiliser Lua pour les calculs. Le gain de pr�cision en
> lui-m�me est souhaitable, mais il implique des probl�mes potentiels de
> compatibilit�, il me semble. Si un sp�cialiste de PGF a des infos...
En fait, je ne pense pas que ce soit � PGF de prendre en charge
l'utilisation de lua (au niveau du code de PGF je m'entends) pour gagner
en efficacit�. Je pense que c'est pr�cis�ment le r�le du moteur lui-m�me
de permettre de profiter de lua en proposant les outils pour. Les
concepteurs ont d�cid� certes d'introduire lua dans le moteur mais ils
ont surtout d�cid� d'offrir aux concepteurs de packages et aux
utilisateurs tout ce qu'il faut pour acc�der aux entrailles de TeX. De
toutes fa�ons, je vois mal l'�quipe de PGF maintenir une version pour
LuaTeX et une autre pour pdftex, xetex et les autres.
En fait, le fait d'introduire lua doit � mon sens permettre de gagner en
efficacit� mais il ne faut pas trop que les aptitudes en calcul du
moteur soient trop modifi�es ou perturb�es. En effet, il faut que les
personnes qui compilaient leur documents il y a dix ou quinze ans avec
LaTeX (ou Plain) retrouvent aujourd'hui ou demain un moteur avec un
comportement identique, autrement �a pourrait compl�tement modifier les
mises en page et dans ce domaine les calculs sont importants.
Je crois que les commandes TeX doivent profiter des am�liorations
apport�es par lua mais pas n'importe comment. LuaTeX doit pouvoir
conserver le comportement de TeX original (avec tous ses d�fauts) mais
doit aussi permettre de profiter de la puissance de lua. On pourrait
imaginer que LuaTeX fournissent des commandes du style \texoriginal et
\endtexoriginal. On aurait par exemple un "environnement" � l'int�rieur
duquel LuaTeX aurait le m�me comportement que le TeX original lors de la
compilation de tout le materiel se trouvant dans cet "environnement" .
Evidemment, cela suppose que LuaTeX ait un certain comportement par
d�faut (celui par exemple dans lequel les commandes sont le plus
optimis�es dans tous les sens du terme, m�me si l'on s'�loigne de TeX et
PdfTeX, on ne posera plus de probl�me de compatibilit� ascendante). On
pourrait aussi imaginer des commandes du style \pdftexoriginal et
\endpdftexoriginal pour que, l� encore, luatex se comporte comme pdftex
: ce serait utile puisque cela pourrait apporter une r�ponse au fait que
la compatibilit� avec pdftex n'est justement pas totale pour le moment.
J'imagine que l'on pourrait cr�er des commandes \xetexoriginal et
\endxetexoriginal mais c'est une autre histoire.
Pour en revenir � PGF, avec ce syst�me, si l'utilisateur de LuaLaTeX par
exemple compile un document contenant des {tikzpicture}, il utilisera
naturellement la puissance de Lua sans qu'il n'ait quoi que ce soit �
faire et sans que le concepteur de PGF n'ait � faire lui aussi quoi que
ce soit. Et si l'utilisateur veut le comportement de TeX, il n'aura qu'�
faire
\texoriginal \begin{tikzpicture} ........ \end{tikzpicture}
\endtexoriginal et l� encore sans que les concepteurs de PGF aient fait
quoi que ce soit.
Elie
>
> En fait, je ne pense pas que ce soit à PGF de prendre en charge
> l'utilisation de lua (au niveau du code de PGF je m'entends) pour gagner
> de permettre de profiter de lua en proposant les outils pour. Les
> ont surtout décidé d'offrir aux concepteurs de packages et aux
> utilisateurs tout ce qu'il faut pour accéder aux entrailles de TeX. De
> toutes façons, je vois mal l'équipe de PGF maintenir une version pour
> LuaTeX et une autre pour pdftex, xetex et les autres.
Pour être honnête, je crois que je n'ai pas compris ton message...
remettons les choses au clair : LuaTeX est compatible avec pdfTeX sauf
pour :
- l'encodage des caractères d'entrée (qui peut être modifié grâce à
luainputenc)
- quelques bidouilles dans l'algorithme de césure des paragraphes
- des trucs supplémentaires dans LuaTeX (langage lua, accès à des
points de l'algorithme, etc.), et quelques primitives pdfTeX en moins
(pdfstrcmp, pdfmatch, pdfmdfive, etc.)
À part ça c'est compatible, donc j'avoue que je ne comprend pas du
tout le coup des \pdftexoriginal... qu'est-ce que ça ferait
concrètement ? Si tu veux dire que ça lit des caractères 8 bits, que
ça prend le même algo de césures de paragraphes, que ça enlève le lua
et que ça remet les primitives TeX, alors soyons clairs, c'est
impossible, et ce n'est pas vraiment la peine d'en parler...
Sinon je ne comprend pas bien comment tu veux bénéficier de la
puissance de calcul de lua sans rien modifier du tout. LuaTeX ne
convertit pas les maths de TeX en lua ! C'est à l'auteur de paquetages
de le faire. C'est du boulot certes, mais quand on veut bénéficier de
nouvelles choses (les maths de lua sont nouvelles, elles ne remplacent
pas les maths de TeX), on est obligé d'écrire du nouveau code, je ne
comprend pas comment il pourrait en être autrement. Donc concrètement
si un paquetage veut bénéficier des maths de lua tout en étant
compatible avec pdfTeX, il est obligé de faire des \ifluatex \else \fi
un peu partout ; c'est la dure vie d'auteur de paquetages...
--
Elie
Sébastien
> On 23 d�c, 00:32, S�bastien <s...@free.fr> wrote:
>> En fait, je ne pense pas que ce soit � PGF de prendre en charge
>> l'utilisation de lua (au niveau du code de PGF je m'entends) pour gagner
>> ont surtout d�cid� d'offrir aux concepteurs de packages et aux
>> utilisateurs tout ce qu'il faut pour acc�der aux entrailles de TeX. De
>> toutes fa�ons, je vois mal l'�quipe de PGF maintenir une version pour
>> LuaTeX et une autre pour pdftex, xetex et les autres.
>
> remettons les choses au clair : LuaTeX est compatible avec pdfTeX sauf
> pour :
> luainputenc)
> - quelques bidouilles dans l'algorithme de c�sure des paragraphes
Est-ce vraiment une incompatibilit� ? C'est simplement que Luatex fera
les choses diff�remment de pdftex : c'est �a qui est important, avec un
m�me fichier .tex source, luatex peut avoir un comportement diff�rent de
pdftex mais dans certains cas (le pdf produit est diff�rent),
l'utilisateur peut avoir besoin du comportement de pdftex � la place de
celui de luatex alors m�me qu'il utilise luatex
> - des trucs suppl�mentaires dans LuaTeX (langage lua, acc�s � des
> points de l'algorithme, etc.),
L� encore il ne s'agit pas d'incompatibilit� il me semble.
> et quelques primitives pdfTeX en moins
> (pdfstrcmp, pdfmatch, pdfmdfive, etc.)
Dans la mesure o� luatex ne conna�t pas ces primitives, on ne peut plus
les utiliser c'est tout.
> � part �a c'est compatible,
oui � part �a mais �a ne l'est pas totalement donc.
> donc j'avoue que je ne comprends pas du
> tout le coup des \pdftexoriginal... qu'est-ce que �a ferait
> concr�tement ? Si tu veux dire que �a lit des caract�res 8 bits, que
> �a prend le m�me algo de c�sures de paragraphes,
oui par exemple car �a a une influence sur le r�sultat de la compilation.
> que �a enl�ve le lua
Pourquoi enlever le lua ? Je veux simplement que si j'utilise des
commandes de pdftex (je ne fais pas de distinction entre celles
originellement de TeX ou de eTeX), elles se comportent comme quand je
compile avec pdftex mais cela ne m'emp�che pas d'utiliser des commandes
introduites par luatex et qui peuvent utiliser du lua.
> et que �a remet les primitives TeX, alors soyons clairs, c'est
> impossible, et ce n'est pas vraiment la peine d'en parler...
> Sinon je ne comprend pas bien comment tu veux b�n�ficier de la
> puissance de calcul de lua sans rien modifier du tout.
Sans rien modifier du tout au code de PGF (je pr�cise).
Voil� comment. D�j� signalons d'embl�e (dites-moi si je me trompe) que
dans luatex les primitives tex n'utilisent pas lua mais cela ne signifie
pas que les primitives de tex n'aient pas �t� r��crites dans luatex (on
aurait pu faire la m�me remarque avec pdftex). Elles ont peut-�tre pu
�tre r��crites parce qu'elles avaient besoin d'�tre d�poussi�r�es
(r��criture des lignes �crites en pascal) mais le fait est que leur
comportement a pu �tre alt�r� je n'en sais rien, c'est tr�s probable.
On peut imaginer qu'une primitive tex qui a �t� r��crite dans pdftex et
qui pourrait �tre optimis�e gr�ce � lua pourrait �tre d�finie dans
luatex de la fa�on suivante :
-si cette primitive n'est pas utilis�e dans un environnement
\texoriginal ou autre, alors c'est le m�canisme le plus r�cent et, a
priori, le plus optimis� utilisant lua �ventuellement qui est utilis�,
-si cette primitive se trouve dans un environnement \texoriginal, c'est
la d�finition que l'on trouve dans tex qui est utilis�,
-si cette primitive se trouve dans un environnement \pdftexoriginal,
c'est la d�finition que l'on trouve dans pdftex qui est utilis�.
...
C'est s�r que �a peut alourdir la d�finition de certaines primitives tex
qui ont pu �tre red�finies plusieurs fois dans le temps mais cela ne
concerne pas n�cessairement toutes les primitives tex. De m�me pour les
commandes introduites par pdftex.
Tr�s na�vement, je dirais que cela ne semble pas difficile comme �a �
faire mais j'ai un gros doute (voir plus bas).
Ainsi on peut conserver les anciens comportements et les concepteurs de
luatex pourraient peut-�tre se d�tacher de l'obligation de
r�trocompatibilit� qui de toutes fa�ons ne sera pas totale dans l'�tat
actuel des choses.
> LuaTeX ne
> convertit pas les maths de TeX en lua !
non pas pour le moment mais avec le m�canisme d�crit plus haut, il le
pourrait mais encore faut-il �tre bien d'accord sur ce que l'on entend
par "les maths de tex".
> C'est � l'auteur de paquetages
> de le faire. C'est du boulot certes, mais quand on veut b�n�ficier de
> nouvelles choses (les maths de lua sont nouvelles, elles ne remplacent
> pas les maths de TeX), on est oblig� d'�crire du nouveau code, je ne
> comprend pas comment il pourrait en �tre autrement. Donc concr�tement
> si un paquetage veut b�n�ficier des maths de lua tout en �tant
> compatible avec pdfTeX, il est oblig� de faire des \ifluatex \else \fi
> un peu partout ; c'est la dure vie d'auteur de paquetages...
Pas forc�ment. En fait, je repense � ce que j'ai �crit plus haut et au
fait que dans luatex les primitives tex ne sont pas �crites avec du lua.
Je ne suis pas un pro en programmation mais �a vient peut-�tre du fait
que ce n'est peut-�tre pas possible du tout ... auquel cas, ce que je
proposais pourrait alors �tre fait au niveau d'un package. Mais ce qui
serait bien c'est que les maths de lua remplacent justement celles de
tex (ou pas sur demande de l'utilisateur �videmment) et que cette
possibilit� soit offerte � tous les utilisateurs ou concepteurs de
packages luatex une fois pour toutes afin qu'il n'y ait pas de \ifluatex
et autre \else et \fi � tour de bras.
> --
> Elie
Elie
>
> Pas forcément. En fait, je repense à ce que j'ai écrit plus haut et au
> fait que dans luatex les primitives tex ne sont pas écrites avec du lua.
> Je ne suis pas un pro en programmation mais ça vient peut-être du fait
> que ce n'est peut-être pas possible du tout ... auquel cas, ce que je
> proposais pourrait alors être fait au niveau d'un package. Mais ce qui
> serait bien c'est que les maths de lua remplacent justement celles de
> possibilité soit offerte à tous les utilisateurs ou concepteurs de
> packages luatex une fois pour toutes afin qu'il n'y ait pas de \ifluatex
En fait très peu de choses ont été changées ou optimisées entre pdfTeX
et LuaTeX... les primitives ont un comportement parfaitement
identique, les seules différences sont comme je l'ai dit l'encodage
des caractères d'entrée et la césure des lignes. Au niveau des
caractères d'entrées ce n'est pas bien grave, par contre au niveau de
l'algorithme de césure des lignes, je crois que Hans et Taco
refuseraient catégoriquement une primitive \luatexoldlinebreaks qui
remettrait l'ancien algo en route (il n'est plus dans le code, ça
voudrait dire beaucoup de boulot pour eux de le remettre)...
Pour les maths rien n'a changé et ça me semble un peu trop
progressiste pour ce monde conservateur qu'est TeX de demander des
optimisations dans les maths qui engendreraient forcément des
incompatibilités avec les documents d'il y a 30 ans (les grands pontes
de TeX tirent une fièreté énorme de ça). De plus, même moi qui ai
tendence à être progressiste, je trouverais ça abusif d'introduire des
changements dans les primitives de calcul de TeX. Donc comme les
packages tirent parti des vieilles primitives qui ne changent pas et
ne peuvent pas changer... ces paquetages ne peuvent pas s'optimiser
tout seuls à moins de changer leur code.
Concrètement ce que je ne comprend pas dans la question, c'est comment
tu voudrais optimiser les maths de TeX qui sont principalement des
\advance et des \multiply... ce sont les packages qui font des usages
complexes de ça, le moteur en lui-même fournit des choses assez
basiques. Par contre comme le moteur fournit des choses
supplémentaires en lua un poil plus optimisées, dont les packages
peuvent tirer parti, en troquant leurs machineries complexes à base de
\advance et \multiply pour du lua.
--
Elie
Manuel Pégourié-Gonnard
> oui � part �a mais �a ne l'est pas totalement donc.
>
La compatibilit� totale n'est pas et ne sera vraisemblablement jamais un
objectif de LuaTeX. L'objectif est d'atteindre ��le bon�� compromis
entre compatibilit� et �volution. En pratique, les incompatibilit�s
devraient rester minimes.
>> donc j'avoue que je ne comprends pas du
>> tout le coup des \pdftexoriginal... qu'est-ce que �a ferait
>> concr�tement ? Si tu veux dire que �a lit des caract�res 8 bits, que
>> �a prend le m�me algo de c�sures de paragraphes,
>
> oui par exemple car �a a une influence sur le r�sultat de la compilation.
>
Oui mais non. Si on veut lire de octets� la place de caract�res, on peut
le faire mais c'est pas au moteur de s'en occuper, il y a un hook pour
�a. Si on veut utiliser la � vieille�� version des c�sures (l'algo en
lui-m�me est globablement le m�me, seuls certains d�tails changent), et
ben �a ne sera pas possible parce que les auteurs de LuaTeX estiment
qu'offrir cette possibilit� allourdirait trop le nouveau code pour que
�a en vaille la peine. De toutes fa�ons, il faut bien voir qu'� ce
niveau on pinaille et que dans 99,9% des cas, les c�sures seront
identiques.
>> Sinon je ne comprend pas bien comment tu veux b�n�ficier de la
>> puissance de calcul de lua sans rien modifier du tout.
>
> Sans rien modifier du tout au code de PGF (je pr�cise).
Avant d'aller plus loin, disons tout de suite que ce n'est pas du tout
la ��philosophie�� de LuaTeX�: ils fournissent des outils, les
applications, c'est pas leur probl�mes. Le pr�t-�-porter, c'est chez
XeTeX.
> Voil� comment. D�j� signalons d'embl�e (dites-moi si je me trompe) que
> dans luatex les primitives tex n'utilisent pas lua mais cela ne signifie
> pas que les primitives de tex n'aient pas �t� r��crites dans luatex (on
> aurait pu faire la m�me remarque avec pdftex). Elles ont peut-�tre pu
> �tre r��crites parce qu'elles avaient besoin d'�tre d�poussi�r�es
> (r��criture des lignes �crites en pascal) mais le fait est que leur
> comportement a pu �tre alt�r� je n'en sais rien, c'est tr�s probable.
Non, pour l'immense majorit� des primitives, le comportement n'a pas �t�
alt�r�, ou alors juste pour l'�tendre de fa�on triviale (par exemple,
\catcode ne travaille plus sur des nombres 8-bitspas sur des nombres
vachement plus grands).
> On peut imaginer qu'une primitive tex qui a �t� r��crite dans pdftex et
> qui pourrait �tre optimis�e gr�ce � lua pourrait �tre d�finie dans
> luatex de la fa�on suivante :
>
J'ai l'impression qu'on s'�gare totalement sur la place de Lua, ici. Si
une d�veloppeur d'une variante de TeX veut � optimiser�� une primitive,
ce n'est pas en Lua qu'il va le faire, mais en C (ou en Web). Parce
qu'entre nous, les possibilit�s d'optimisation sont quand m�me
vachement plus grandes comme �a... C'est pas Lua qui sait calculer bien,
c'est C qui sait le faire avant lui.
Lua, c'est pour fournir une interface au programmeur de macros, pas pour
le programmeur du moteur lui-m�me.
>> LuaTeX ne
>> convertit pas les maths de TeX en lua !
>
> non pas pour le moment mais avec le m�canisme d�crit plus haut, il le
> pourrait mais encore faut-il �tre bien d'accord sur ce que l'on entend
> par "les maths de tex".
>
L� aussi, mettons-nous d'accord sur les faiblesses des math de TeX :
les concepts offerts ne sont pas assez �labor�s (essentiellement que de
l'arithm�tique enti�re sign�e, sur 32 bits). Ce n'est pas
l'impl�mentation qui va modifier les concepts...
Le probl�me n'est pas que TeX calcule mal�: ce qu'il fait, il le fait
tr�s bien. C'est juste qu'il fait tr�s peu de choses. La seule chose �
faire au niveau du moteur, c'est offrir plus de possibilit�s.
Pour l'instant, pour faire des choses compliqu�es (virgule flottante), on
les �mule, en TeX, � partir de concepts basiques de TeX offre. C'est
difficile, impr�cis et lent � l'ex�cution. Mais ce n'est pas TeX
lui-m�me qui calcule de fa�on impr�cise ou lente.
> Mais ce qui
> serait bien c'est que les maths de lua remplacent justement celles de
> tex
Le point, c'est que les � maths de TeX�� n'ont pas besoin d'�tre
remplac�es, mais d'�tre �tendues.