Lucas a écrit 87 commentaires

Il y a par exemple cuisine-libre.fr.

Ne retiens pas ta respiration ;)

J'utilise désormais Lollypop, merci beaucoup !

Le sujet des podcasts m'intéresse vraiment, et je veux bien essayer de proposer la prise en charge de ça si tu n'as pas le temps.
Je ferai un brouillon des fonctionnalités que j'envisage dans un ticket ce soir.

Je m'étais amusé à l'implémenter en quelques heures, c'est vraiment incroyable comment un concept aussi simple donne des résultats aussi bons. Le code se trouve sur GitHub.

Merci pour le pointeur vers ce numéro, je ne l'avais jamais lu.

Il ne semble pas y en avoir chez moi (evince 3.18.1 debian testing), seulement les raccourcis N/P permettent de passer d'une page à une autre j'ai bien l'impression.

En prenant d'autres exemples qui composent un paragraphe, il ne semble pas possible de produire une interpréteur TeX qui se comporte conformément à l'interpréteur original sans en réimplémenter tous les aspects. Est-ce donc ton but?

Ça me semble aller de soi quand je dis vouloir "lire du TeX". Je ne vois pas ce qui te pose problème en fait…
Une fois encore, le but est de proposer une solution au problème de traitement par flot avec une application au TeX.

Dans la bibliothèque en cours de développement, il y a un environnement qui contient les registres (globaux et locaux) pour toutes les dimensions internes de TeX (enfin qui en contient de plus en plus).
Cet environnement est modifié au fur et à mesure du traitement suivant les actions des primitives TeX sur ce même environnement.

Si tu aimes les formats TeX qui ne sont pas LaTeX, j'en profite pour faire de la pub pour Cadet. :)

Tu en avais déjà fait la pub ici non ? Il me semble l'avoir découvert suite à un journal.

Il me semblait avoir été clair, mais l'objectif de cette dépêche n'est aucunement de parler de ToolXiT pour le moment, qui est juste un prétexte pour parler de ce qui est énoncé dans le titre : lire du .

Pour le moment cette bibliothèque est une application de ce que j'ai appris et une preuve de concept en constante évolution.
Sur le long terme, le but est de pouvoir l'utiliser en frontend d'import pour une bibliothèque plus large de manipulation de documents. J'y reviendrai surement plus tard quand la série sera plus avancée, mais c'est vraiment pas l'objectif du moment.

Je commence par la base donc avec l'interpréteur de macros. Ce que tu dis est cité dans l'article, et bien identifié, sur le fait que l'état change et que le comportement ultérieur en est affecté, et justement tout ce qui est dit ici expose (à un haut niveau) ce problème, les réponses viendront dans les articles suivants de cette série.

Un point capital que tu effleures sans vraiment énoncer – et que je veux donc souligner – est que TeX est un système de composition typographique tandis que LaTeX est un système de description de documents. Bien-sûr, strictement parlé, toutes les primitives TeX peuvent être utilisées dans un document LaTeX, mais il est recommandé d'utiliser LaTeX comme un système déclaratif en “oubliant” qu'il est écrit en TeX. Si tu t'intéresses à la manipulation des documents LaTeX sous forme symbolique, tu peux donc faire des hypothèses restrictives sur leur structure, qui te permettraient d'écrire un analyseur syntaxique.

Je ne parle pas de ici, mais comme dit dans le titre je parle du problème de "lire du ". Comme je le dis aussi ci-dessus, j'explique ce que apporte et les problèmes que j'ai avec (ça reste personnel bien sûr comme analyse) et justement je ne veux pas faire d'approximations, comme il en existe un paquet dans pas mal d'outils.
Je ne veux pas faire du mais du , ce qui permet plus de choses derrière car ça ne présuppose aucun format utilisé. Ce qui est recommandé dans le cadre de est hors sujet là, je ne souhaite pas écrire un document, je ne dis pas comment utiliser , je parle de lire du en exposant le problème à un haut niveau.

De plus cette série utilise aussi comme prétexte pour parler de traitement de données par flot et pour présenter un outil pour ce faire : les iteratees (teasing !).

Si tu es à la recherche de sources d'inspiration pour résoudre les problèmes que tu vas rencontrer, il y a littéralement des dizaines d'implémentations de TeX – ou de variantes – dans des languages divers, et je crois même qu'il existe une bibliothèque C encapsulant l'interpréteur TeX.

Cf. https://en.wikipedia.org/wiki/New_Typesetting_System, https://www.ctan.org/tex-archive/systems/ant?lang=en

Je connais bien sûr ces projets, j'ai fait pas mal de recherches avant de me lancer, mais mon but n'est pas de le copier. Il n'existe pas des dizaines de vraies implémentations de , beaucoup font des raccourcis pour justement pouvoir le parser au sens traditionnel et sont en fait des parsers d'un sous ensemble de . Je ne veux pas encapsuler l'existant mais proposer une autre solution au problème. Je ne veux pas non plus proposer un nouveau langage mais avoir une interpréteur complet d'un langage existant, le but étant à terme de pouvoir l'utiliser sur des documents déjà écrits.

En bref, le but de cet article est de présenter une problématique (le fait que ce soit du est juste un prétexte, ça pourrait s'appliquer à d'autres données), et la suite sera de montrer comment j'y réponds. Ce n'est pas de la pub pour ToolXiT, qui est à l'état de jouet inutile. Cette dépêche en attend d'autres, comme je le précise au début, seule elle n'apporte rien d'autre que l'énoncé d'une problématique.
Je ne voudrais pas qu'on se trompe en lisant cette dépêche en pensant qu'elle présente un remplaçant à ou un autre système, ou bien qu'elle parle du traitement de documents en , c'est hors du périmètre.

ps : si quelqu'un sait comment faire les petits numéros avec lien pour les notes…

Dans la page wiki en bas de l'aide mémoire http://linuxfr.org/wiki/aide-edition#notes-de-bas-de-page

Voire ou

Cet article est le premier d'une série. Je reviendrai sur la bibliothèque par la suite, là le but était de présenter le problème de la lecture d'une entrée écrite en TeX.

LyX est vraiment bien pour combiner WYSIWYG et rendu fait par TeX.
Son approche est intéressante, le TeX est un format de stockage plus qu'une fin en soi dans LyX, qui lui gère vraiment un document. Je trouve l'outil super sympa même s'il est d'aspect rugueux.

Allons, ne me dis pas que tu ne lis pas les commentaires ?

;)

Je te pointe le journal qui dis que les sources sont disponibles si tu paie et le contrat social debian qui indique que la gratuité de l'accès aux sources est la première règle d'un logiciel libre selon Debian.

En fait non, le contrat social parle bien de licence d'un composant dans Debian qui ne doit pas réclamer de royalties ou de limitations de redistribution. Rien ne dit dans le contrat social que le composant a atterri gratuitement dans Debian (par exemple si Debian devient sponsor). Juste que la licence (ici GPL comme dit Zenitram et c'est tout ce dont le contrat social parle, de la licence pas de comment Debian se procure le composant) n'empêche pas Debian de le redistribuer, gratuitement, de modifier, etc…

Donc tu interprètes le contrat social de la mauvaise manière ici je pense.

En plus de l'exemple de gnumdk ci-dessus, on peut lire sur leur site :

Free.fr has shipped millions of set top boxes in France, powered by EFL. The Openmoko Freerunner sold thousands of devices with EFL and Enlightenment on them. Yellow Dog Linux for the Sony PS3 ships with Enlightenment as the default. EFL has been used on printers, netbooks and more. It powers the Samsung Galaxy Gear watches, is behind the Samsung Z1 Phone and the Samsung SUHD Smart TVs that run Tizen. Cameras also use Enlightenment and EFL such as the Samsung NX1 and the Samsung NX300M smart Camera. Also GPS units such as models from Coyote Run EFL on a lean and mean RTOS. Also Web conference cameras such as Biscotti use EFL to do their work.

Nevermind j'avais mal compris

En fait non, même si dans ce sens résigner est désuet et que le verbe est transitif.

Dans le cas du bytecode Java, ce n'est pas toujours possible car certaines contraintes n'existent pas dans le bytecode mais existent dans le Java.
Par exemple, le fait que la première instruction d'un constructeur doivent être l'appel au constructeur de la super classe n'existe pas dans le bytecode. Scala utilisait ça par moment.

De même dans la gestion des exceptions, Java est connu pour ses checked exceptions qui font partie de l'interface, cependant c'est une contrainte purement au niveau du source, et pas dans le bytecode. Même si les checked exceptions se retrouvent dans l'interface du bytecode, elles ne sont explicitement pas vérifiées. Scala n'a pas ce concept. Pour avoir du bytecode Scala avec exceptions décompilé avec qui recompile en Java, il faut réinférer toutes les exceptions qui ne sont pas des RuntimeException pour les ajouter dans l'interface. Bref, ce n'est pas direct.

Scala génère aussi des suites d'instructions bytecode qui peuvent ne correspondre à aucune construction en Java. Par exemple les boucles en Java sont compilées d'une certaine manière et Scala les transforme différemment, notamment dû au fait qu'un for scala se traduit en des appels à des méthodes du style map et flatMap. Le compilateur Scala fait aussi de l'optimisation des récursions terminales triviales, je ne suis pas sûr de comment un décompilateur Java peut retraduire ça, si le code généré correspond à comment le compilateur Java compilerait un while.

Il y a plein de raisons pour lesquelles il est impossible de ressortir du Java à partir de bytecode, la JVM étant moins restrictif que le langage Java. Les obfuscateurs de bytecode jouent là dessus, en réorganisant les instructions pour sans changer la sémantique mais en créant des séquences qui sont inatteignables depuis le Java.

L'avantage du bytecode est surtout d'être encore assez abstrait pour être portable, il n'a pas besoin de coller au langage source. Surtout pour la JVM maintenant qui fait tourner du bytecode généré depuis plein de langages très différents (java, scala, closure, groovy, python, ruby, ocaml, …). Par exemple le bytecode OCaml est assez loin du langage source, voir les instructions

J'ajouterais à tous tes liens un excellent cours (en anglais), très pédagogique, sur à la fois le formalisme et la preuve de programme, le tout très orienté (et écrit en) Coq, et que je recommande souvent, l'excellent Software Foundations de Benjamin C. Pierce.

Bien sûr il est irréaliste de vouloir développer un programme d'envergure en Coq mais ces techniques commence à être disponibles sur des langages "mainstream".

Laborieux, certes, irréaliste pas sûr… Connais tu compcert ?
C'est un compilateur C écrit en Coq dont chaque représentation interne est formellement spécifiée et chaque transformation est formellement prouvée en Coq (notamment les optimisations qu'il applique).

edit : je voulais répondre à newca, pardon…

Ce serait en effet une bonne idée, on en fait une grosse utilisation dans tous les composants de \BlueLaTeX. Il faut que je trouve le temps de faire un truc cohérent, sinon yapuka :)

Merci.

Pour répondre à tes deux points :

je me suis qu'à peine penché sur les bases de données orientées documents, je me suis toujours demandé si créer pleins de petits documents potentiellement liés entre eux était une bonne pratique. As-tu des info là dessus ? As-tu fais des tests avec Couch ?

Je me suis demandé la même chose et la réponse de la documentation dit que lorsque l'on arrive dans les millions ça commence à poser des problèmes. Pour ces cas extrêmes j'ai réfléchi au fait de pouvoir choisir la manière dont sont stockés les composants, et de les embarquer dans un seul document dans un champs, disons, components. Je pense qu'en fait le cas d'usage influe beaucoup sur ce qui fait sens. Dans un premier temps pour \BlueLaTeX j'ai privilégié l'approche qui réduit les conflits. À vrai dire, les documents sont liés entre eux de manière assez simple et les vues nécessaires pour les gérer le sont aussi, notamment, il n'y a pas de fonction reduce, mais uniquement un index des composants par entité et par type. Le protocole entre CouchDB et le server de query est particulièrement mauvais pour les fonctions reduce en l'état, un meilleur protocole est en cours de développement et devrait améliorer les latences. Je n'ai pas remarqué de lenteurs particulières, et des utilisateurs de sohva m'ont fait part de bonnes performances même avec des bases assez chargées. Si les vues peuvent être construites de manière incrémentielle, et que l'on ajoute les données au fil de l'eau, alors le temps passé à construire les vues est aussi mieux réparti et ne se fait pas trop sentir. Le cas des entités dans sohva doit rentrer dedans. J'avoue que je n'ai pas fait de tests de limites pour le moment, c'est toujours en développement mais je vais le planifier :)

je n'ai pas bien compris où se trouve le document. Tu montre des composants qui représentent des bouts logique de document (faire une rotation, placer un texte à tel endroit). Tu as une surcouche à TeX/LaTeX ? Si oui cela ne pose-t'il pas problème (des limitation de la surcouche, des bugs dans le rendu TeX de celle-ci) ?

En fait les composants représentent les méta données d'un projet LaTeX du point de vue \BlueLaTeX. Les fichiers TeX quant à eux sont enregistrés normalement sur le disque dur et compilé sur le disque de manière tout à fait normale.
En base de données ne se trouvent que les données nécessaires à la gestion des permissions, des cycles de vie, des utilisateurs, etc… Typiquement le composant compiler d'un papier a cette tête là :

{
   "_id": "x1ef7eb26809749fb:compiler",
   "_rev": "1-b41dd8557bfe0f9ad73ce0334da2d2b3",
   "compiler": "pdflatex",
   "synctex": true,
   "timeout": 30,
   "interval": 1,
   "sohva-entities-type": "component",
   "sohva-entities-name": "gnieh.blue.compile.CompilerSettings",
   "sohva-entities-entity": "x1ef7eb26809749fb"
}

Et sert en quelque sorte de descripteur de build pour le papier avec l'id x1ef7eb26809749fb :

• compiler avec pdflatex
• générer les donnés SyncTeX
• le processus système timeout après 30 secondes
• et un intervalle d'au moins 1 seconde est imposé entre deux compilation
• le reste des champs est spécifique à la couche de gestion des entités

Si on regarde le composant core de ce même papier, on verra :

{
   "_id": "x1ef7eb26809749fb:core",
   "_rev": "1-a3602ca121f7f9f7a2990203543e98ee",
   "name": "test paper",
   "creation_date": "2014-08-24T14:21:33.382",
   "sohva-entities-type": "component",
   "sohva-entities-name": "gnieh.blue.couch.Paper",
   "sohva-entities-entity": "x1ef7eb26809749fb"
}

Qui contient la date de création et le nom donné par l'utlisateur à ce papier.

Bref, ce sont uniquement des meta données sur le papier, spécifiques à \BlueLaTeX, il n'y a aucune surcouche à LaTeX écrite pour ce qui est de la compilation des documents.

J'espère avoir clarifié les choses sinon hésite pas à demander :)

Une des grosses différences est le protocole de synchronisation fondamentalement différent qui assure une convergence là où le protocole easysync peut diverger. Ce point est important pour nous surtout dans une vision décentralisée où finalement une instance \BlueLaTeX peut être un noeud dans un réseau d'instances interconnectées. Rien que la question de ce protocole de synchronisation change complètement la façon dont marche le client, le serveur, la gestion et l'affichage des différences, etc… Bref c'est plus la même chose du tout.

Il y a aussi beaucoup plus qu'un éditeur à ajouter, comme tous les concepts de rôles et workflow que nous souhaitions avoir.

Pour l'enregistrement des révisions, nous avons une autre approche différente basée sur l'intégration dans un logiciel de gestionnaire de versions, plutôt que de laisser cette compétence à l'algorithme de synchronisation (qui s'occupe de synchroniser, pas de versioner). Utiliser un gestionnaire de version dont c'est le métier permet d'hériter de tout un tas de fonctionnalités intéressantes comme des branches, des tag, etc… Et ces concepts sont dans notre viseur depuis le début.

Comme je l'ai précisé, \BlueLaTeX a pour vocation d'être plus qu'un simple éditeur \LaTeX, c'est d'être une plate-forme d'édition assez complète, l'approche me semble fondamentalement différente de celle d'etherpad. Je ne critique pas leur approche ou ce qui a été fait, je trouve etherpad très bien, mais ça ne correspond pas à ce que nous voulons avoir.

Ensuite à l'époque où nous avons commencé etherpad était aussi en scala, mais très monolithique, ce qui ne collait pas à notre vision. Maintenant etherpad c'est du node.js, techno que je ne maîtrise pas (ok c'est pas un argument, tout s'apprend :)).

Bon, encore un commentaire sur un truc que j'ai en tête :D Ça fait plaisir de voir que je suis pas le seul à avoir ces idées :)
J'ai un module à l'état de proto chez moi qui compile du markdown (c'est plutôt simple). A priori tout est là, il suffit de pouvoir choisir le type de document lors de la création, mais le protocole de synchronisation se moque pas mal de ce qu'il synchronise, donc rien à changer de ce côté.

La partie que je maîtrise le moins est le client, il faudrait pouvoir charger un viewer par type de document et pas un truc statique. J'en parlerai avec Thomas qui s'est occupé du client pour voir à quel point ça implique de modifier son code. Mais oui tout est possible, et l'archi modulaire a été pensée en ce sens.

Toutes ces questions sont intéressantes, et nous avons déjà des plans pour, il faut que nous publions notre roadmap mise à jour, mais en résumé :
- un reviewer dans un contexte d'une publication scientifique ne peut pas modifier le papier, seulement le commenter. L'idée lorsque l'on passera le papier en mode revue est de figer la version du document (un tag) et de permettre aux personnes ayant les droits pour, de commenter le produit final, avant de repartir pour un incrément. Un état est ajouté au projet permettant certaines actions et en interdisant d'autre. Ceci est notre but, pas encore implémenté mais une partie de l'infrastructure pour y arriver est en place.
- nous appelons les outils installés sur le système pour compiler (voir commentaire plus haut), donc oui une suite complète texlive est envisageable vu que c'est ce que nous utilisons. D'ailleurs un fichier .bib est créé par défaut avec un nouveau document. Le processus de build du document (bibtex ou non ? index ou non ? …) est figé et rudimentaire mais pareil dans notre roadmap un système plus souple est pensé et prévu.
- pareil, pour les templates perso c'est dans les tuyaux.

Mais ne nous dispersons pas, tout ceci n'a aucun sens tant que les fonctionnalités de base ne sont pas stabilisées, nous préfèrons travailler en profondeur sur cette version pour avoir un truc qui marche et une vision claire, que de faire un truc tout en largeur qui tombe dès qu'on éternue à côté. N'en déplaise à certains, ceci est encore un projet en construction, pas un produit fini ;) Mais on y travaille avec nos ressources disponibles !

Je me souviens oui, on a pas mal été occupé depuis.

Est-ce que vous utilisez la version de SharelaTeX ?

Je ne suis pas sûr de comprendre le sens de la question. Si on l'utilise pour comparer ? si notre code dépend du leur ?
La réponse à la première question est que oui j'ai testé, mais maintenant j'utilise \BlueLaTeX (eat your own food). Pour le deuxième cas, non. Notre viewer est pdf.js intégré par Thomas dans notre client, écrit par nous from scratch.

Pour une instance de \BlueLaTeX chez vous, je pense que le mieux c'est de reprendre contact par mail et que tu nous dises ce dont vous avez besoin exactement afin de voir ce qui est déjà ok ou non et donner une idée de la faisabilité en l'état.

J'espère pouvoir publier la M2 d'ici 2 semaines environ, qui devrait corriger pas mal de petites instabilités et surtout permettre de lancer le service plus proprement, mais c'est encore de la bêta, ne pas oublier :)