Je regarde la date de parution d'Emacs: ~ 1975
http://en.wikipedia.org/wiki/Emacs
Je regarde la date de parution de Perl: ~ 1987
http://en.wikipedia.org/wiki/Perl
On the other hand, je me dis:
Pour faire de la coloration syntaxique, il faut un "puissant" langage de
manipulation de texte.
Emacs étant paru avant Perl, Emacs étant écrit en Lisp (ou une variante),
Perl n'est pas vraiment un "équivalent (ne jouent pas vraiment dans la meme
catégorie)" de Lisp (comme Python et Ruby), pourquoi ne retrouve-t-on pas
beaucoup d'exemple de manipulation de texte en Lisp sur le Net?
Tous les mega outils/exemples de manipulation de texte sont soit des
implémenté avec outils comme sed/awk (écrits en C...) ou alors des machins
Perl.
C'est vrai que le code d'Emacs est un bon gros exemple, mais... puisque ce
langage a une telle qualité, pourquoi n'a telle pas été mise en avant?
Ou bien je suis trop jeune pour avoir connu les heures de gloire du Lisp?
L'interpréteur Emacs donne 2 si (g 2), 3 si (g 3). Un interpréteur Common Lisp donne 1.
Effectivement, c'est bizarre.
Quel en est la raison ?
Il faudrait demander à Stalman. Je subodore que la réponse est que c'est beaucoup facile à implémenter (une table de hachage globale, ou chaque binding cache les précédents, alors que pour avoir la sémantique de CL, il faut associer à chaque fontion un pointeur vers chaque variable extérieure à laquelle elle fait référence).
Bon, pour être honnète, ça a aussi ses avantages : le comportement de beaucoup de fonctions dépend de diverses variables, et c'est beaucoup plus agréable de faire :
Ce problème permet-il vraiment de dire qu'Emacs Lisp n'est pas vraiment un Lisp ?
Pour moi oui. Ça change du tout au tout la sémantique du langage.
Camille Bourgoin :
(setq a 1)
(defun f() a)
(defun g(a) (f))
(g 2)
?
L'interpréteur Emacs donne 2 si (g 2), 3 si (g 3). Un interpréteur
Common Lisp donne 1.
Effectivement, c'est bizarre.
Quel en est la raison ?
Il faudrait demander à Stalman. Je subodore que la réponse est que c'est
beaucoup facile à implémenter (une table de hachage globale, ou chaque
binding cache les précédents, alors que pour avoir la sémantique de CL, il
faut associer à chaque fontion un pointeur vers chaque variable extérieure
à laquelle elle fait référence).
Bon, pour être honnète, ça a aussi ses avantages : le comportement de
beaucoup de fonctions dépend de diverses variables, et c'est beaucoup plus
agréable de faire :
L'interpréteur Emacs donne 2 si (g 2), 3 si (g 3). Un interpréteur Common Lisp donne 1.
Effectivement, c'est bizarre.
Quel en est la raison ?
Il faudrait demander à Stalman. Je subodore que la réponse est que c'est beaucoup facile à implémenter (une table de hachage globale, ou chaque binding cache les précédents, alors que pour avoir la sémantique de CL, il faut associer à chaque fontion un pointeur vers chaque variable extérieure à laquelle elle fait référence).
Bon, pour être honnète, ça a aussi ses avantages : le comportement de beaucoup de fonctions dépend de diverses variables, et c'est beaucoup plus agréable de faire :
Ce problème permet-il vraiment de dire qu'Emacs Lisp n'est pas vraiment un Lisp ?
Pour moi oui. Ça change du tout au tout la sémantique du langage.
Camille Bourgoin
(Luc Habert) writes:
Camille Bourgoin :
(setq a 1) (defun f() a) (defun g(a) (f)) (g 2)
?
L'interpréteur Emacs donne 2 si (g 2), 3 si (g 3). Un interpréteur Common Lisp donne 1.
Effectivement, c'est bizarre.
Quel en est la raison ?
Il faudrait demander à Stalman. Je subodore que la réponse est que c'est beaucoup facile à implémenter (une table de hachage globale, ou chaque binding cache les précédents, alors que pour avoir la sémantique de CL, il faut associer à chaque fontion un pointeur vers chaque variable extérieure à laquelle elle fait référence).
Bon, pour être honnète, ça a aussi ses avantages : le comportement de beaucoup de fonctions dépend de diverses variables, et c'est beaucoup plus agréable de faire :
Ce problème permet-il vraiment de dire qu'Emacs Lisp n'est pas vraiment un Lisp ?
Pour moi oui. Ça change du tout au tout la sémantique du langage.
Effectivement. Au niveau où j'en suis (connais un peu Emacs Lisp, et commence tout juste à apprendre Common Lisp), je ne m'en suis pas rendu compte.
Merci pour ces infos.
-- Camille "Mesmento" Bourgoin jabber : web : http://jbbourgoin.free.fr/site/
lhabert@clipper.ens.fr (Luc Habert) writes:
Camille Bourgoin :
(setq a 1)
(defun f() a)
(defun g(a) (f))
(g 2)
?
L'interpréteur Emacs donne 2 si (g 2), 3 si (g 3). Un interpréteur
Common Lisp donne 1.
Effectivement, c'est bizarre.
Quel en est la raison ?
Il faudrait demander à Stalman. Je subodore que la réponse est que c'est
beaucoup facile à implémenter (une table de hachage globale, ou chaque
binding cache les précédents, alors que pour avoir la sémantique de CL, il
faut associer à chaque fontion un pointeur vers chaque variable extérieure
à laquelle elle fait référence).
Bon, pour être honnète, ça a aussi ses avantages : le comportement de
beaucoup de fonctions dépend de diverses variables, et c'est beaucoup plus
agréable de faire :
L'interpréteur Emacs donne 2 si (g 2), 3 si (g 3). Un interpréteur Common Lisp donne 1.
Effectivement, c'est bizarre.
Quel en est la raison ?
Il faudrait demander à Stalman. Je subodore que la réponse est que c'est beaucoup facile à implémenter (une table de hachage globale, ou chaque binding cache les précédents, alors que pour avoir la sémantique de CL, il faut associer à chaque fontion un pointeur vers chaque variable extérieure à laquelle elle fait référence).
Bon, pour être honnète, ça a aussi ses avantages : le comportement de beaucoup de fonctions dépend de diverses variables, et c'est beaucoup plus agréable de faire :
Ce problème permet-il vraiment de dire qu'Emacs Lisp n'est pas vraiment un Lisp ?
Pour moi oui. Ça change du tout au tout la sémantique du langage.
Effectivement. Au niveau où j'en suis (connais un peu Emacs Lisp, et commence tout juste à apprendre Common Lisp), je ne m'en suis pas rendu compte.
Merci pour ces infos.
-- Camille "Mesmento" Bourgoin jabber : web : http://jbbourgoin.free.fr/site/
Ph. Ivaldi
Le 21 mars 2007, (Luc Habert) écrivit :
Le parsing, c'est l'un des choses les plus immondes qui soient à programmer. Et c'est ÀMHA totalement crétin.
Bonjour,
Je passe mon temps à parser de façon très maladroite du code et j'aimerai avoir des conseils. Comme je ne sais pas où poser la question et que le sujet et légèrement abordé ici, je me lance (me rediriger le cas échéant).
Pour fabriquer les pages de mon site à propos d'Asymptote, je crée des répertoires par thèmes dans lesquels je place des fichiers .asy, deux fichiers texte 'titre' et title' et un makefile ultra basique qui ne fait qu'appeler un de mes deux script bash.
Grosso modo, je principe est le suivant. Après avoir compilé les nouveaux .asy et converti les images en png, Je convertis tous les .asy en .asy.html avec htmlize. Je passe ensuite les .asy.html générés dans une moulinette infâme qui transforme certaines balises (mise en commentaire pour que le code puisse être compilé) prédéfinies en du code HTML tout aussi prédéfini. Au final, j'extirpe tout le code des .asy.html compris entre les balise <body></body> à coup 'awk' et les balance dans un index.html dont l'entête est déjà faite. Bref c'est de de la grosse bidouille et les balises ne peuvent avoir que des comportements très limités (pas d'interaction entre elles, par exemple). J'aimerai bien aussi, à terme, remouliner tous ça pour générer un pdf contenant la documentation des fonctions qui se trouvent dans un fichier suivi de l'exemple qui se trouve dans un autre fichier.
Comment procéderiez vous ? Avec du xml ? avec un parseur maison en Perl ? (je ne connais ni l'un ni l'autre). Avec CDuce (que j'ai du mal à comprendre) ?
Pour l'instant les moulinettes *infâmes* que j'utilise sont ici (âme sensible à la beauté du code, s'abstenir!): http://piprim.tuxfamily.org/asymptote/bin/
-- Merci de votre attention et excusez moi pour le HS. Philippe Ivaldi. http://piprim.tuxfamily.org/
Le 21 mars 2007, lhabert@clipper.ens.fr (Luc Habert) écrivit :
Le parsing, c'est l'un des
choses les plus immondes qui soient à programmer. Et c'est ÀMHA
totalement crétin.
Bonjour,
Je passe mon temps à parser de façon très maladroite du code et
j'aimerai avoir des conseils.
Comme je ne sais pas où poser la question et que le sujet et légèrement
abordé ici, je me lance (me rediriger le cas échéant).
Pour fabriquer les pages de mon site à propos d'Asymptote, je crée des
répertoires par thèmes dans lesquels je place des fichiers .asy, deux
fichiers texte 'titre' et title' et un makefile ultra basique qui ne
fait qu'appeler un de mes deux script bash.
Grosso modo, je principe est le suivant.
Après avoir compilé les nouveaux .asy et converti les images en png,
Je convertis tous les .asy en .asy.html avec htmlize.
Je passe ensuite les .asy.html générés dans une moulinette infâme qui
transforme certaines balises (mise en commentaire pour que le code
puisse être compilé) prédéfinies en du code HTML tout aussi
prédéfini.
Au final, j'extirpe tout le code des .asy.html compris entre les balise
<body></body> à coup 'awk' et les balance dans un index.html dont
l'entête est déjà faite.
Bref c'est de de la grosse bidouille et les balises ne peuvent avoir que
des comportements très limités (pas d'interaction entre elles, par
exemple).
J'aimerai bien aussi, à terme, remouliner tous ça pour générer un pdf
contenant la documentation des fonctions qui se trouvent dans un fichier
suivi de l'exemple qui se trouve dans un autre fichier.
Comment procéderiez vous ?
Avec du xml ? avec un parseur maison en Perl ? (je ne connais ni l'un ni
l'autre).
Avec CDuce (que j'ai du mal à comprendre) ?
Pour l'instant les moulinettes *infâmes* que j'utilise sont ici (âme
sensible à la beauté du code, s'abstenir!):
http://piprim.tuxfamily.org/asymptote/bin/
--
Merci de votre attention et excusez moi pour le HS.
Philippe Ivaldi.
http://piprim.tuxfamily.org/
Le parsing, c'est l'un des choses les plus immondes qui soient à programmer. Et c'est ÀMHA totalement crétin.
Bonjour,
Je passe mon temps à parser de façon très maladroite du code et j'aimerai avoir des conseils. Comme je ne sais pas où poser la question et que le sujet et légèrement abordé ici, je me lance (me rediriger le cas échéant).
Pour fabriquer les pages de mon site à propos d'Asymptote, je crée des répertoires par thèmes dans lesquels je place des fichiers .asy, deux fichiers texte 'titre' et title' et un makefile ultra basique qui ne fait qu'appeler un de mes deux script bash.
Grosso modo, je principe est le suivant. Après avoir compilé les nouveaux .asy et converti les images en png, Je convertis tous les .asy en .asy.html avec htmlize. Je passe ensuite les .asy.html générés dans une moulinette infâme qui transforme certaines balises (mise en commentaire pour que le code puisse être compilé) prédéfinies en du code HTML tout aussi prédéfini. Au final, j'extirpe tout le code des .asy.html compris entre les balise <body></body> à coup 'awk' et les balance dans un index.html dont l'entête est déjà faite. Bref c'est de de la grosse bidouille et les balises ne peuvent avoir que des comportements très limités (pas d'interaction entre elles, par exemple). J'aimerai bien aussi, à terme, remouliner tous ça pour générer un pdf contenant la documentation des fonctions qui se trouvent dans un fichier suivi de l'exemple qui se trouve dans un autre fichier.
Comment procéderiez vous ? Avec du xml ? avec un parseur maison en Perl ? (je ne connais ni l'un ni l'autre). Avec CDuce (que j'ai du mal à comprendre) ?
Pour l'instant les moulinettes *infâmes* que j'utilise sont ici (âme sensible à la beauté du code, s'abstenir!): http://piprim.tuxfamily.org/asymptote/bin/
-- Merci de votre attention et excusez moi pour le HS. Philippe Ivaldi. http://piprim.tuxfamily.org/
lhabert
Ph. Ivaldi :
Comment procéderiez vous ? Avec du xml ? avec un parseur maison en Perl ? (je ne connais ni l'un ni l'autre). Avec CDuce (que j'ai du mal à comprendre) ?
Avec un truc comme CDuce ou XSLT. Tu veux faire de la réécriture d'arbre, ce sont des langages faits pour. Le perl, ou ce que tu fais actuellement, c'est de la réécriture de texte.
Ph. Ivaldi :
Comment procéderiez vous ?
Avec du xml ? avec un parseur maison en Perl ? (je ne connais ni l'un ni
l'autre).
Avec CDuce (que j'ai du mal à comprendre) ?
Avec un truc comme CDuce ou XSLT. Tu veux faire de la réécriture d'arbre, ce
sont des langages faits pour. Le perl, ou ce que tu fais actuellement, c'est
de la réécriture de texte.
Comment procéderiez vous ? Avec du xml ? avec un parseur maison en Perl ? (je ne connais ni l'un ni l'autre). Avec CDuce (que j'ai du mal à comprendre) ?
Avec un truc comme CDuce ou XSLT. Tu veux faire de la réécriture d'arbre, ce sont des langages faits pour. Le perl, ou ce que tu fais actuellement, c'est de la réécriture de texte.
Ph. Ivaldi
Le 24 mars 2007, (Luc Habert)écrivit :
Ph. Ivaldi :
Comment procéderiez vous ? Avec du xml ? avec un parseur maison en Perl ? (je ne connais ni l'un ni l'autre). Avec CDuce (que j'ai du mal à comprendre) ?
Avec un truc comme CDuce ou XSLT.
Je me suis lancé dans le xml et le xslt ce week-end; ça convient parfaitement à ce que je veux faire avec un peu de réécriture de texte pour sortir un xml convenable dès le départ. -- Merci.
Philippe Ivaldi. http://piprim.tuxfamily.org/
Le 24 mars 2007, lhabert@clipper.ens.fr (Luc Habert)écrivit :
Ph. Ivaldi :
Comment procéderiez vous ? Avec du xml ? avec un parseur maison en
Perl ? (je ne connais ni l'un ni l'autre). Avec CDuce (que j'ai du
mal à comprendre) ?
Avec un truc comme CDuce ou XSLT.
Je me suis lancé dans le xml et le xslt ce week-end; ça convient
parfaitement à ce que je veux faire avec un peu de réécriture de texte
pour sortir un xml convenable dès le départ.
--
Merci.
Comment procéderiez vous ? Avec du xml ? avec un parseur maison en Perl ? (je ne connais ni l'un ni l'autre). Avec CDuce (que j'ai du mal à comprendre) ?
Avec un truc comme CDuce ou XSLT.
Je me suis lancé dans le xml et le xslt ce week-end; ça convient parfaitement à ce que je veux faire avec un peu de réécriture de texte pour sortir un xml convenable dès le départ. -- Merci.
Philippe Ivaldi. http://piprim.tuxfamily.org/
lhabert
Ph. Ivaldi :
avec un peu de réécriture de texte pour sortir un xml convenable dès le départ.
Au passage : xsltproc a un parseur de soupe de tags qui, dans mon expérience, se sort très bien de merdes hallucinantes. Ça s'active avec l'option « --html ».
Ph. Ivaldi :
avec un peu de réécriture de texte pour sortir un xml convenable dès le
départ.
Au passage : xsltproc a un parseur de soupe de tags qui, dans mon
expérience, se sort très bien de merdes hallucinantes. Ça s'active avec
l'option « --html ».
avec un peu de réécriture de texte pour sortir un xml convenable dès le départ.
Au passage : xsltproc a un parseur de soupe de tags qui, dans mon expérience, se sort très bien de merdes hallucinantes. Ça s'active avec l'option « --html ».
Ph. Ivaldi
Le 26 mars 2007, (Luc Habert)écrivit :
Ph. Ivaldi :
avec un peu de réécriture de texte pour sortir un xml convenable dès le départ.
Au passage : xsltproc a un parseur de soupe de tags qui, dans mon expérience, se sort très bien de merdes hallucinantes. Ça s'active avec l'option « --html ».
Ha, il me semblait que xsltproc ne servait qu'à appliquer la feuille de style XSLT au document XML. La page man de xsltproc dit simplement: --html The input document is an HTML file.
Si, par exemple, je place le tag suivant dans du code:
/*<module file="tartanpion" anchor="truc"/>*/
le html généré par htmlize le transforme en (j'ai rajouté les sauts de ligne): /*</span><span class="comment"> <span class="asy-xml"><module file="tartanpion" anchor="truc"/> </span></span><span class="comment">*/</span>
Il faut bien que je vire les <span class="comment|asy-xml"> et modifie < >
Je m'en sorts ainsi (sur cette exemple): (defun clean-asy-htmlize() (beginning-of-buffer) (while (re-search-forward "<span class="comment"><span class="asy-xml"><(.*)></span></span>" (point-max) t) (replace-match "<1>"))) (add-hook 'htmlize-after-hook 'clean-asy-htmlize)
Je suis complètement débutant en XML donc je dis peut-être n'importe quoi... -- Philippe Ivaldi. http://piprim.tuxfamily.org/
Le 26 mars 2007, lhabert@clipper.ens.fr (Luc Habert)écrivit :
Ph. Ivaldi :
avec un peu de réécriture de texte pour sortir un xml convenable dès
le départ.
Au passage : xsltproc a un parseur de soupe de tags qui, dans mon
expérience, se sort très bien de merdes hallucinantes. Ça s'active
avec l'option « --html ».
Ha, il me semblait que xsltproc ne servait qu'à appliquer la feuille de
style XSLT au document XML.
La page man de xsltproc dit simplement:
--html The input document is an HTML file.
Si, par exemple, je place le tag suivant dans du code:
/*<module file="tartanpion" anchor="truc"/>*/
le html généré par htmlize le transforme en (j'ai rajouté les sauts de
ligne):
/*</span><span class="comment">
<span class="asy-xml"><module file="tartanpion" anchor="truc"/>
</span></span><span class="comment">*/</span>
Il faut bien que je vire les <span class="comment|asy-xml"> et modifie
< >
Je m'en sorts ainsi (sur cette exemple):
(defun clean-asy-htmlize()
(beginning-of-buffer)
(while (re-search-forward
"<span class="comment"><span class="asy-xml"><\(.*\)></span></span>"
(point-max) t)
(replace-match "<\1>")))
(add-hook 'htmlize-after-hook 'clean-asy-htmlize)
Je suis complètement débutant en XML donc je dis peut-être n'importe
quoi...
--
Philippe Ivaldi.
http://piprim.tuxfamily.org/
avec un peu de réécriture de texte pour sortir un xml convenable dès le départ.
Au passage : xsltproc a un parseur de soupe de tags qui, dans mon expérience, se sort très bien de merdes hallucinantes. Ça s'active avec l'option « --html ».
Ha, il me semblait que xsltproc ne servait qu'à appliquer la feuille de style XSLT au document XML. La page man de xsltproc dit simplement: --html The input document is an HTML file.
Si, par exemple, je place le tag suivant dans du code:
/*<module file="tartanpion" anchor="truc"/>*/
le html généré par htmlize le transforme en (j'ai rajouté les sauts de ligne): /*</span><span class="comment"> <span class="asy-xml"><module file="tartanpion" anchor="truc"/> </span></span><span class="comment">*/</span>
Il faut bien que je vire les <span class="comment|asy-xml"> et modifie < >
Je m'en sorts ainsi (sur cette exemple): (defun clean-asy-htmlize() (beginning-of-buffer) (while (re-search-forward "<span class="comment"><span class="asy-xml"><(.*)></span></span>" (point-max) t) (replace-match "<1>"))) (add-hook 'htmlize-after-hook 'clean-asy-htmlize)
Je suis complètement débutant en XML donc je dis peut-être n'importe quoi... -- Philippe Ivaldi. http://piprim.tuxfamily.org/
