J'ai le grand plaisir de vous annoncer la naissance d'un projet qui me trottait dans la tête depuis quelques temps déjà. Tout à commencé quand j'ai voulu lancer divers programmes sur des machines distantes via ssh. Que les programmes soient sout forme binaire ou scripts python, ruby, perl, ... il y avait souvent des soucis.
Pourtant il y a une solution. Il existe un langage standardisé qui est présent dans toute connexion ssh "normale": le shell. Pourtant, malgré tout ses avantages, le shell n'est pas à mon avis d'assez haut niveau. L'idéal aurait été de trouver un compilateur d'un langage haut niveau vers shell.
A ma grande surprise, et ce malgré un certains nombre de recherches avec divers mots clés, je ne suis jamais tombé sur un compilateur disposant d'un backend shell. Ai je mal cherché? Peut être. Fidèle à la philosophie du libre: "Si les outils existants ne satisfont pas tes besoins, retrousse tes manches" je me suis lancé dans la création d'un tel compilateur.
Le shell c'est bien, mais il aurait été triste de ne disposer que d'un backend shell. Étant tombé amoureux de TeX en tant que langage de programmation, je n'ai pas pu résister au défi de développer également un backend TeX.
Voici donc le Weird Compiler. Le projet en est à ses tout débuts donc ne vous attendez pas à toute la richesse d'un Objective Caml, Haskell ou Scala, il en est TRES TRES loin. Mais tout de même, les exemples basiques tournent. Si vous voulez participer au projet, faites vous plaisir, tout teste à faire!
Un grand merci à Tuxfamily d'herberger le projet.
# De la doc ? Des exemples ?
Posté par Florence Birée (site web personnel) . Évalué à 5.
Ça à l'air d'être un projet fun, mais il manque des bouts de documentation, ou des exemples de code sur le site web, histoire qu'on puisse voir la tête que ça a sans télécharger le machin.
(Un screenshot ! Un screenshot !)
[^] # Re: De la doc ? Des exemples ?
Posté par erdnaxeli (site web personnel) . Évalué à 2.
La doc est dans le dépot git.
Ça ressemble à du fonctionnel, avec des « let x = fun y -> y + 1 in (x 2) ». Et ça pond du code imbitable, en TeX ou sh. C'est pas mal pour faire un script incompréhensible.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: De la doc ? Des exemples ?
Posté par GTof . Évalué à 3.
Et pour le shell, super lent!
[^] # Re: De la doc ? Des exemples ?
Posté par GTof . Évalué à 1.
Tout à fait. Y'a quelques exemples et une doc épurée dans les sources, je les mettrais sur le site demain.
# Been there, done that
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
Il y a plusieurs années, pour un cours de compilation, j'avais écrit un compilateur miniML -> perl, et deux amis miniML -> PHP et miniML -> Shell…
Et aussi, pour lancer des programmes sur des machines distantes, ben, t'as des trucs comme GXP ou Condor qui sont très bien…
[^] # Re: Been there, done that
Posté par GTof . Évalué à 1.
J'aimerais beaucoup y jeter un oeil!
# Limitations sérieuses
Posté par Michaël (site web personnel) . Évalué à 3.
Si j'ai bien compris ton problème, que tu n'explicites pas vraiment, l'exécution de tes programmes en langage de haut niveau est rendue difficile par l'inhomogénéité des plate-formes d'exécution. C'est ça?
Le gros problème du shell est qu'il est très lent et donc si tu t'en sers pour faire autre chose que ce pour quoi il est conçu (combiner l'exécution d'autres programmes), cela va te laisser un petit goût amer.
Programmant beaucoup en TeX je trouve ton idée de compiler vers TeX sympa, mais tu vas aussi croiser un problème de taille: la mémoire allouée par TeX est limitée.
[^] # Re: Limitations sérieuses
Posté par Julien Fontanet (site web personnel) . Évalué à 3.
inhomogénéité→ hétérogénéité;)
[^] # Re: Limitations sérieuses
Posté par Michaël (site web personnel) . Évalué à 2.
Ah oui merci! Quand je l'ai écrit ça piquait un peu les doigts…
[^] # Re: Limitations sérieuses
Posté par neil . Évalué à 1.
En même temps le nouveau compilateur de TeX qui monte (LuaTeX) prend un chemin opposé en proposant du Lua pour faire toute la partie programmation.
[^] # Re: Limitations sérieuses
Posté par GTof . Évalué à 1.
Certes mais LuaTeX c'est tricher. Plus sérieusement, compiler vers du TeX a l'avantage de rester dans un monde homogène et tres stable. De plus, l'objectif a terme est d'intégrer un système de type à la ML, ce dont ne dispose pas Lua. En résumé, le but est de proposer des constructions évolués tout en restant 100% compatible avec l'existant. Et puis la programmation en TeX est certes difficile mais très intéressante et riche d'enseignement.
[^] # Re: Limitations sérieuses
Posté par neil . Évalué à 1.
Oui, mais ça rajoute une couche qui n'est pas forcément stable. L'avantage principal de LuaTeX c'est de pouvoir utiliser des polices OpenType, ce qui est quand même un minimum pour faire de la typographie aujourd'hui.
Là je plussoie grandement. Mais c'est surtout une question de goûts j'imagine.
Tout à fait, mais le TeX est caché par le compilateur ici.
[^] # Re: Limitations sérieuses
Posté par Michaël (site web personnel) . Évalué à 3.
Ben voilà!
En fait (je crois) que l'avantage ne réside pas tellement dans la possibilité d'utiliser ces polices — c'est déjà possible avec pdfTeX — mais de faciliter (idéalement automatiser) l'utilisation des fontes «installées» sur le système dans TeX. En principe les fontes de TeX et les fontes du système sont deux mondes à part.
TeX a quelques défauts de conception, par exemple, l'algorithme de coupure des pages travaille à l'aveugle et ne considère pas les coupures sur plusieurs pages pour prendre sa décision, mais je ne pense pas que LuaTeX y change quelque chose! Les algorithmes de placement des flottants ou de succession des modèles de page seront probablement plus faciles à écrire en Lua qu'en TeX — quoique :)
Un gros problème de TeX est la difficulté qu'il y a à créer de nouveaux modèles de documents. LuaTeX devrait permettre d'écrire plus facilement des modèles très généraux, plus facilement personnalisables. À mon avis la personnalisation sera un vrai cauchemar à cause des dépendances entres les paramètres que l'auteur du modèle n'aura pas forcément pu intégrer dans son modèle.
Pas du tout. Les systèmes de types qu'il y a en Lua (Perl, Python) sont tout pourris et n'aident pas du tout le programmeur à éviter de faire des fautes. Toutes les fautes de frappe dans les noms des méthodes, interversion dans l'ordre des paramètres, ne sont détectés qu'à l'éxécution — si le code en question est exécuté. Par exemple si tu fais un calcul qui dure 3h et que tu fais une faute de frappe dans le code qui sauvegarde le résultat, c'est reparti pour un tour. Heureusement, on a des centrales nucléaires.
Dans les langages fortement typés à la ML, le compilateur est capable de détecter un grand nombre d'erreurs, celles qui restent sont essentiellement les erreurs:
— de protocole, il faut relire la description du protocole!
— d'algorithme, si la méthode est mauvaise, il faut la changer!
— de système, mais qui c'est qui essaie d'écrire dans un fd ferme, mh?
autrement dit les vrais erreurs.
[^] # Re: Limitations sérieuses
Posté par c^3 . Évalué à 1.
Ça me rappelle Melt (http://forge.ocamlcore.org/projects/melt/), un projet similaire à LuaTex mais avec OCaml à la place de Lua (normal, c'est issu d'un labo français). Je ne sais par contre pas du tout où ça en est :)
The cake is a lie.
[^] # Re: Limitations sérieuses
Posté par Michaël (site web personnel) . Évalué à 2.
Ça n'a pas grand chose à voir: Melt aide les programmes OCaml à écrire des fichiers LaTeX. Il existait effectivement une imitiation de TeX en OCaml, appellée ANT.
http://ant.berlios.de/
Cependant, ANT n'est pas une réimplémentation de TeX, ce qui est probablement une des raisons de son succès plutôt limité.
# Problème de make sous Mac et *BSD
Posté par Ontologia (site web personnel) . Évalué à 3.
Sous Mac (et de façon très liée, sous *BSD), il faut toujours mettre un argument de répertoire à find. Hors là il n'y en a pas, ce qui fait échouer le make.
bash
`find -type f -not \( -iname "*.wc" -or -iname "Makefile" \) -exec /bin/rm -fv {} \;
find: illegal option -- t
find: illegal option -- y
find: illegal option -- p
find: illegal option -- e
find: f: No such file or directory
Il faut écrire : find . -type f -not ( -iname "*.wc" -or -iname "Makefile" ) -exec /bin/rm -fv {} \;
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Problème de make sous Mac et *BSD
Posté par GTof . Évalué à 1.
Merci! C'est corrigé sur le dépôt git et les archives.
[^] # Re: Problème de make sous Mac et *BSD
Posté par yellowiscool . Évalué à 2.
Je n'ai pas mon mac pour vérifier sous la main, mais est-ce qu'il existe aussi l'argument -delete pour la version bsd de find ? C'est quand même plus pratique que faire un appel à rm.
Envoyé depuis mon lapin.
[^] # Re: Problème de make sous Mac et *BSD
Posté par Frank-N-Furter . Évalué à 2.
Oui:
-delete Delete found files and/or directories. Always returns true. This executes from the current working directory as find recurses down the tree. It will not attempt to delete a filename with a "/" character in its pathname relative to "." for security reasons. Depth-first traversal processing is implied by this option.
Depending on the time of day, the French go either way.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.