Ba le truc c'est que çà c'est trivial à hacker dans ranger, il y a un fichier (scope.sh) qui fait globalement un truc du genre (en pseudo-code)
switch(mimetype)
case bidule:
methode_qui_genere_du_txt
donc c'est facile de faire:
case 'video/*':
mplayer --flag libcaca -dump txt
Le truc c'est que pour les "vraies" images, il passe par un autre mécanisme qui n'est plus un dump txt, mais l'image est directement passée dans w3m et affichée. Ce qui veut dire qu'il faut aller hacker dans le code python pour ajouter un hook du genre "if pas_format_dimage_geré(image): image = convert_to_image(image)" et faire un convert_to_image qui depende du type (genre pdftoimage/movietoimage…) et cela demande un peu plus de hacking dans le core du projet (aulieu de le faire dans le fichier scope.sh qui est un fichier setting utilisateur).
C'est même énorme de pouvoir visionner les images dans un terminal ! Par contre c'est dommage qu'il ne permette pas de convertir un pdf/film/… en image (avec pdftoppm ou mplayer) et ensuite de l'afficher.
Le mode VCS est aussi un peu foireux/lent avec mercurial, je sens que je vais hacker ce week-end.
Merci, grâce à cela, je viens de virer les quelques derniers packets gnomes que je gardais depuis longtemps (i.e. eog, nautilus et gnome-terminal, replacé par urxvt qui sait afficher les images)
Malgré son orthographe dramatique, je peux t'assurer que dans cette discussion c'est surement le type qui est le plus objectif car il connait très bien git et encore plus mercurial.
J'aimerais vraiment que on arrête la notion de diff et que on passe à des changeset sémantiques en gardant le diff en dernier recours.
Quand je déplace un bout de code, renomme un ensemble de fonctions, ajoute un test autour d'un bloc de code et indente celui-ci, j'aimerais vraiment que les merges futurs continuent d'avoir cette information pour merger mon code.
Typiquement, après un merge entre une branche refactorée (où on a changé le nom de la fonction haha en hihi) et une autre branche qui a ajouté un appel à cette fonction, le merge peut bien se passer, en laissant tout fois un code invalide car il reste l'appel qui n'a pas été renommé. (d'ailleurs, vous reglez cela dans le merge ou dans un commit suivant ?)
Je ne sais pas à quel point il serait possible de faire des commit qui décrivent non pas le changement, mais la recette du changement (Cela pourrait bêtement être un script).
D'ailleurs, à y réfléchir, il me semble difficile de réaliser cela sans toucher l'arrière du palais, ce qui risque de déclencher un réflexe nauséeux. Montage donc ?
Réflexe qui peut se contrôler. C'est presque un pré-requis pour toute jeune fille voulant entrer dans l'industrie du porn. (Je te laisse chercher sur wikipedia, l'article Gorge profonde explique bien le truc. C'est wikipedia, mais c'est tout de même NSFW). (Je trouve passionnant comment wikipedia traite de façon très clair, concise des sujets pour le moins difficile à traiter).
Il faut que je prenne quelque temps pour réfléchir à l'approche que tu proposes, mais c'est en effet intéressant, merci.
Ceci dit, écrire les dépendances à la main est en général peut contraignant — si on écrit la liste une seule fois à un seul endroit — car il s'agit d'une liste stable et cela permet d'avoir cette liste sous les yeux pour déboguer.
C'est un point sur lequel je ne suis pas d'accord, la liste de dépendance c'est implicitement le document .tex qui la donne et je n'ai pas envie de me répéter, sachant que je change souvent celles-ci.
Pour commencer, on définit une commande TeX MyFancyGraphic
[…]
Dont l'effet est d'inclure l'image filename et de poubelliser (ignorer) le reste.
Donc il faut inventer un nom, c'est à mon sens une limitation.
Ensuite on écrit un programme makedepend_blender — en OCaml, mais on s'en cogne ;) — qui prépare les dépendances. Il lit tes fichiers TeX et écrit un fichier .depend_blender contenant des lignes du type
Donc il faut que le programme parse le document racine à la recherche d'inclusions vers d'autres documents. C'est faisable, mais c'est dur à rendre robuste (si par exemple quelqu'un défini une macro qui appelle \input).
(Si les fichiers image ont d'autres dépendances, il faut trouver une convention pour les ajouter dans MyFancyGraphic et demander à makedepend_blender d'écrire leurs noms à droite de filename.in.)
Donc tu dois spécifier les dépendances à la main, alors que certaines commandes pourraient les gérer d'elles mêmes.
Par contre ce que tu propose me donne une idée pour simplifier mon implémentation. Je garde la commande "MyFancyGraphic", sans le "filename", et la seule chose que fait latex c'est générer un nom de fichier unique basé sur la commande et d'inclure ce nom de fichier unique. Après mon script de build parse le fichier .tex (et ses sous-fichiers) et génère les dépendances en utilisant le même mécanisme, et c'est gagné.
tl;dr: Je ne veux pas à avoir à lister mes dépendances autre part que dans le .tex et je veux pouvoir lister facilement celles-ci, même quand elle proviennent d'un processus de construction très complexe ayant plusieurs fichiers en dépendance et plusieurs paramètres.
Ta solution est intéressante, sauf qu'elle force à décrire dans le makefile la liste de toutes tes dépendances. Ma (courte) thèse contient actuellement plusieurs dizaines de dépendances générées et je n'ai pas envie de devoir les décrire une par une dans le makefile sachant que je le fais déjà dans le .tex.
Use case simple
J'ai besoin de convertir les .poulet en .tortue.
dans latex:
\includegraphics{hibou.tortue}
Là latexmk (ou rubber) est capable d'appeler make pour toutes les dépendances, ainsi :
$ make hibou.tortue
Il y a une règle relativement simple qui dit que :
%.tortue: %.hibou
tortufy $*
Use case avancé
J'ai un programme qui prend en paramètre un nom de svg (source.svg) et la liste de calques à exporter (calque1 et calque2) et qui génère un .pdf.
(ici il me prend tous les .svg que mercurial connait, mais bon)
Ça commence à faire mal ici (en gros, je suis le seul humain de tout ceux qui bossent sur ce projet (i.e, heureusement que c'est ma thèse) qui veut encore lire le makefile).
Cas pathologique (90% de mes use cases)
Je veux un fichier de sortie qui dépend d'un nombre de fichiers d'entrés indéterminé et de N paramètres. Dans mon latex je fais :
et dans mon makefile, et bien je ne sais pas ce que je fais. J'avais adopté une nouvelle solution, je sous-traitais à un script :
%__uber.png:
mon_script $*
qui génère la liste de dépendances qui sera évalué par make à la prochaine passe pour gérer correctement mon build.
Et là je meurs.
Solution actuelle
Alors finalement je fais autrement. J'ai une fonction
\includegraphisCommand{}
Qui prend une commande.
LaTeX ouvre un pipe et écrit cette commande et lit dans un pipe le nom du fichier à inclure.
Un démon (en python, mais on s'en cogne) lit dans le pipe la commande à exécuter, et écrit le nom temporaire de sortie après exécution (en gérant bien évidement un cache pour ne pas reconstruire tout à chaque fois).
Et dans mon code python, j'ai défini une fonction :
def svg(input, layers):
output_name = nom_unique('svg', input, layers) # genere un nom unique pour ce fichier de sorti, basé sur le nom et les arguments de la méthode
if must_rebuild([output_name], [input]): # fonction générique qui regarde si il faut rebuilder
# action pour builder
return output_name
Ainsi:
a) chaque action de build est en fait une simple fonction python dans un fichier, fonction paramétrée comme bon me semble et appelée naturellement depuis mon .tex. Mon pire exemple c'est :
b) Je m’embête plus à trouver des noms pour mes fichiers générés, j'ai une fonction de hash à la con qui fait cela, met tout dans /tmp et voila. En plus c'est sympa, le nom dépend des paramètres de la commande et pas de l'endroit ou elle est appelée dans le .tex. Ainsi si je décide de tester en changeant un paramètre, cela va compiler pendant 2 heures, et si je revient sur la version précédente, cela va reprendre l'ancien fichier déjà présent dans le cache.
c) Toutes les dépendances sont mise à jour lors de la passe sur le .tex et dirigées par le contenu du .tex. Ainsi tout est bien synchronisé.
d) Je peux intégrer des "plugins" dans mon outil de rendu. Par exemple, à tout moment, je peux dire que les résultats images qui sortent sont downscalés, ainsi mon pdf se construit plus vite (cela permet d'avoir le bon visuel dans le pdf, à la qualité près, sans prendre 30 minutes parce que toutes mes images hautes résolutions tuent les performances)
Ma plus grosse limitation actuellement, hormis le coté code non robuste et pas du tout vendable, c'est que cela ne gère pas la construction en parallèle des dépendances.
Donc pour conclure, je cherche un outil plus puissant pour générer mes dépendances. Actuellement j'ai une solution foireuse qui fonctionne, mais pas très sérieuse.
J'ai lu la documentation en diagonale et ce qui m’embête c'est que j'ai l'impression que c'est (pour la partie latex du moins) une n-ième version de rubber/latexmk/yourbuildscript.
Ce que j’attends d'un outil de build pour latex c'est une gestion correcte des dépendances générées. Rubber ne sait faire cela que pour des cas simples (i.e.: générer un .poulet à partir d'un .tortue), latexmk à le même problème, mais sait déléguer à make, mais cette délégation se fait en plusieurs passes et généralement c'est le carnage (i.e.: tu appelles make, qui appelle latexmk pour générer la liste des dépendances, qui appele make, qui génère celles-ci et rappel latexmk… 9 fois sur 10 j'ai un truc recompilé pour rien ou pas recompilé, quand je ne parle même pas d'un echec de latexmk qui perd les pédales).
J'ai craqué, j'ai fais une tambouille maison dégueulasse et utilisable seulement par moi et cela me déprime, et chaque fois que je vois quelqu'un proposer un outil de build pour LaTeX, j'espere que on va me sortir de ce calvaire.
Et vous, vous gérez comment vos dépendances générées ? Attention, je ne parle pas de cas simple du genre convertir des .svg en .pdf, mais plutôt de cas du genre vous voulez afficher une image qui est le résultat du rendu d'une scène avec blender, puis passé dans 4 passes d'image magick, passé dans FFMPEG pour ressortir des images de diagnostic, et bien évidement tout cela doit être paramétré dans le .tex car je peux vouloir changer un paramètre de rendu.
En gros, chaque fois que je vais dans un répertoire avec un dépot HG qui est lié à un dépôt distant, cela prend du temps ET cela me demande un password ;( Il faudrait juste un élément de config pour pas qu'il s'amuse à vérifier à chaque fois, je m'en cogne un peu de savoir en permanence que je suis sync ou pas sur le dépot distant.
Sinon j'aime bien, sauf que j'ai désactivé les VCS pour l'instant.
Le gros souci de ces technologies c'est que cela manque d'outils.
Du coté "carte graphique", c'est Cuda ou meurt. Tout ce qui contient "Open" dans le nom manque d'outils. À une époque, Nvidia fournissait les mêmes outils de diagnostics pour Cuda et pour OpenCL, mais depuis peu (sous Linux en tout cas), les outils nvidia ne sont plus capables de me faire un diagnostic sur mes kernel OpenCL…
Pour ceux qui n'en ont jamais fait, en gros Cuda/OpenCL/OpenGL Compute c'est simple, vous écrivez un code compact, léger, joli, de 30 lignes pour faire une addition de vecteur et cela tourne relativement vite. Après vous, regardez ce que disent les outils, et vous vous rendez compte que vous n'utilisez que 5% de la puissance théorique de votre GPU… Bon, on améliore un peu son code, au final il fait 500 lignes, contient des "barrier()" de partout, des copies de mémoire de partout et quelques bits hacks et l'on est content. En Cuda c'est simple parce que nvidia fourni des outils qui te disent presque quels bithack seront efficaces. En OpenCL, c'est dans le flou artistique… Et une fois que tu as fini de coder, tu as 2**N façon de lancer ton code et en fonction de la façon dont tu le fais, c'est plus ou moins lent, et cela dépend de la carte utilisée… ARGGGG. (Si cela intéresse, je peux faire un journal sur l'écriture d'une somme en OpenGL compute et quelques débats sur les optimisations et le bordel que c'est.)
Maintenant, j'ai craqué, je fais tous mes kernel en OpenGL compute, et je ne fais que des codes "simples et intuitifs", en acceptant de ne tourner qu'à 10% de la puissance théorique..
Côté CPU, OpenMP c'est vraiment sympa, mais je lui préfère intel TBB qui, au lieu d'être à base de directive de précompilateur, est une librairie. Sur le papier, j'aime moins, mais c'est subjectif.
Ma petite réflexion du jour s'adresse aux décideurs qui ont entendu parler du GPGPU : "Un GPU n'est pas un tool magique qui multiplie votre puissance de calcul par plusieurs millions. Oui, c'est intéressant, oui c'est puissant, mais cela vient avec un cout de dev/maintenance non négligeable et cela ne règle pas tous les problèmes. Et si vous preniez autant de temps pour optimiser vos codes CPU que vos codes GPU, sans doute que vous ne vous poseriez pas la question d'utiliser un GPU". (PS: oui, j'en ai marre des comparaisons qui bench du code CPU de merde, sans SIMD, sans thread, avec des patterns d'accès mémoire naze, sur un cpu à 30 euros avec un TDP de 3 Watt et qui les comparent à 2 ans de dev sur un code GPU optimisé au poil pour une gamme de cartes particulières, qui coute 600 euros et consomme 400 Watts !)
mais existerait-il une possibilité de dire cette œuvre appartient au domaine publique mais personne ne peut l'exploiter hormis sous sa forme originel(autrement dit pour ce cas une BD, quelques films et animations)? Afin d'éviter toutes autre utilisation, figurine/pub/jouets/etc…
Genre du libre/public à deux vitesses. Si t'es gentil c'est public, mais si t'es méchant, alors c'est pas public. C'est 'achement libre tout ça.
Je suis au courant du support de GEGL, mais c'est vrai que c'est une chose que j’attends comme le messie depuis quelques année et c'est vrai que cela prend du temps (simple constatation, ce n'est pas un reproche, j'ai préféré envoyer mes patchs à Blender et LuxRender plutôt qu'a GIMP, donc je râlerais le jour où j'aurais un peu contribué ;)
Par exemple même sur blender, quand on applique un effet de miroir sur un objet, au bout d'un moment on va l'appliquer et se mettre à travailler dans les détails.
Oui, mais pour moi il s'agit d'une limitation du miroir de blender, qui devrait par exemple n’être applicable que sur une sous-partie de l'objet.
De la même manière, un filtre "miroir" dans Gimp devrait pouvoir étre applicable qu'à une sous partie de l'image (en utilisant par exemple un masque de sélection).
Mais c'est la différence entre le dessin industriel et l'art. Dans l'art, on cherche pas à sauver l'info, mais à avoir le meilleur résultat final. Or c'est souvent incompatible.
C'est malheureusement le problème. Cependant je suis persuadé que les artistes auraient à gagner d'un workflow moins destructif (à condition que celui-ci ne soit pas compliqué). Enfin bon, je divague mais je ne propose rien, donc bon ;)
Ce que je regrette avec ce genre d'outil c'est que cela soit destructif. En gros, quand on dessine d'un coté de l'image, cela se contente d'effectuer la même action de l'autre coté. L'approche différente serait d'avoir un "filtre/effet/modificateur" qui applique le miroir. (Un peu comme le modificateur miroir dans Blender).
C'est surement une des choses qui m’empêche de devenir un artiste, c'est accepter la perte d'une information importante (qui est la symétrie ici). Parce qu'au final, cette image pourrait se simplifier à :
Un calque qui contient l'image du haut
Un calque qui contient le bateau
Un effet de calque qui duplique et miroir les deux autres calques
Un effet de calque qui redimensionne et tinte le calque de reflet.
Ainsi il est possible par la suite de transformer l'image original et d'obtenir la mise à jour dans le reflet directement. Alors qu'avec l'approche actuelle, la déformation et la tinte du reflet sont définitifs et toute modification est maintenant impossible.
Ce que j'aimerais voir dans Gimp c'est un outil de composition basé noeuds (comme celui de Blender) pour la composition des calques.
Toi t'as jamais eu un pote qui sous prétexte de te filer un coup de main défonce complètement ta salle de bain et te laisse en plan avec du carrelage et des morceaux de fils.
Merci, je sais, c'est ce que j'ai expliqué plus tôt (au début du thread auquel je m'auto repond.). C'est assez enervant quand on essaye d'avoir une discussion un peu plus avancé de se faire répondre ce que l'on a préalablement expliqué plus tôt. (Un peu comme sur le chan irc d'ubuntu, et depuis peu d'arch linux… Quand tu as un soucis, les seuls aides que tu obtient te conseil des trucs que tu as déjà testé ;)
Mon problème c'est que je n'ai jamais réussi à générer un bout de code tel que:
while(variable){}
avec variable modifiée à l’extérieur et que cela génère une boucle infinie. Automatiquement GCC et Clang me régénérait des fetch pour mettre à jour tout cela. Donc je voulais savoir si j'étais dans un cas bien défini ou pas.
Mais c'est bon, j'ai trouvé un exemple tout con qui marche bien. Stop en -O0 et boucle infinie au dela.
// g++ -std=c++11 -Wall -Wextra -lpthread fichier.cpp
#include <thread>
#include <iostream>
#include <unistd.h>
int f;
void thread1()
{
while(!f);
}
int main()
{
f = 0;
std::thread t1(thread1);
// give t1 some time to run
sleep(1);
f = 1;
t1.join();
}
Je suis d'accord, mais si on est pas à la seconde près, le cache sera un jour mis à jour et cela va fonctionner.
Ma question c'est plutôt, est-ce que cela marche tout seul (i.e.: sans volatile et avec potentiellement autant de latence que le cache/write buffer peut prendre) ? Est-ce que je suis garanti que GCC ne me fera pas une boucle infinie. En fait je torture mon code depuis un bout de temps et je suis incapable de générer du code ou gcc/clang remplace cela par une boucle infinie.
Ma question est plus poussé, c'est "Est ce que le fait que GCC/Clang ne remplace pas cela par une boucle infinie est un comportement documenté/standard/… et si oui pourquoi ?".
Ce qui me fait toujours peur c'est que j'ai commencé a me renseigner sur volatile et autre suite à une question existentielle, si j'ai une boucle, genre
running = 1;
while(running)
{
// fait quelque chose, mais ne touche pas à running
}
Ici il semblerait que mon compilateur soit en droit de de remplacer cela par une boucle infinie, d'où le besoin de volatile.
En faisant quelques tests, il semblerait que le compilateur (ici gcc en O3) prenne cette liberté seulement si running n'est pas utilisé autre part dans le code. Si jamais il est fait référence à la variable running avant la boucle pour un appel de fonction ou autre, GCC génère tout de même le read, même sans volatile.
Ainsi je me demande donc. Est-ce une limitation de GCC/CLANG qui n'essaye pas d'optimiser dans ce cas ? Est-ce voulu pour protéger le codeur d'une erreur grossière de code ou y a il une raison bien spécifiée qui fait que dans ce cas le compilateur n'a pas le droit de protéger ?
Hors le atomic est une opération hardware spécifique du CPU (Je ne sais pas comment elle fonctionne, mais il y a des chances que ton CPU soit capable en un unique cycle de faire le get/l'incrementation/le set).
[^] # Re: Pcmanfm puis ranger
Posté par Guillaum (site web personnel) . En réponse au journal Quand le vaisseau tombe à l'eau, il faut trouver le poisson. Évalué à 3.
Ba le truc c'est que çà c'est trivial à hacker dans ranger, il y a un fichier (scope.sh) qui fait globalement un truc du genre (en pseudo-code)
switch(mimetype)
case bidule:
methode_qui_genere_du_txt
donc c'est facile de faire:
case 'video/*':
mplayer --flag libcaca -dump txt
Le truc c'est que pour les "vraies" images, il passe par un autre mécanisme qui n'est plus un dump txt, mais l'image est directement passée dans w3m et affichée. Ce qui veut dire qu'il faut aller hacker dans le code python pour ajouter un hook du genre "if pas_format_dimage_geré(image): image = convert_to_image(image)" et faire un convert_to_image qui depende du type (genre pdftoimage/movietoimage…) et cela demande un peu plus de hacking dans le core du projet (aulieu de le faire dans le fichier scope.sh qui est un fichier setting utilisateur).
Bref, plus de boulot ;)
[^] # Re: Pcmanfm puis ranger
Posté par Guillaum (site web personnel) . En réponse au journal Quand le vaisseau tombe à l'eau, il faut trouver le poisson. Évalué à 3.
C'est même énorme de pouvoir visionner les images dans un terminal ! Par contre c'est dommage qu'il ne permette pas de convertir un pdf/film/… en image (avec pdftoppm ou mplayer) et ensuite de l'afficher.
Le mode VCS est aussi un peu foireux/lent avec mercurial, je sens que je vais hacker ce week-end.
Merci, grâce à cela, je viens de virer les quelques derniers packets gnomes que je gardais depuis longtemps (i.e. eog, nautilus et gnome-terminal, replacé par urxvt qui sait afficher les images)
[^] # Re: Pcmanfm puis ranger
Posté par Guillaum (site web personnel) . En réponse au journal Quand le vaisseau tombe à l'eau, il faut trouver le poisson. Évalué à 3.
Je viens d'essayer ranger et… MERCI !
# Et les autres ?
Posté par Guillaum (site web personnel) . En réponse au journal DD & Valve. Évalué à 2.
Et les dev archlinux ou blender ou luxrender hein ?
bon, je sors (même si je suis un peu déçu…)
[^] # Re: Mercurial vu par Facebook
Posté par Guillaum (site web personnel) . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 4.
Malgré son orthographe dramatique, je peux t'assurer que dans cette discussion c'est surement le type qui est le plus objectif car il connait très bien git et encore plus mercurial.
[^] # Re: c'est une question de philosophie
Posté par Guillaum (site web personnel) . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Un jour j'utiliserais Darcs rien que pour cela.
J'aimerais vraiment que on arrête la notion de diff et que on passe à des changeset sémantiques en gardant le diff en dernier recours.
Quand je déplace un bout de code, renomme un ensemble de fonctions, ajoute un test autour d'un bloc de code et indente celui-ci, j'aimerais vraiment que les merges futurs continuent d'avoir cette information pour merger mon code.
Typiquement, après un merge entre une branche refactorée (où on a changé le nom de la fonction haha en hihi) et une autre branche qui a ajouté un appel à cette fonction, le merge peut bien se passer, en laissant tout fois un code invalide car il reste l'appel qui n'a pas été renommé. (d'ailleurs, vous reglez cela dans le merge ou dans un commit suivant ?)
Je ne sais pas à quel point il serait possible de faire des commit qui décrivent non pas le changement, mais la recette du changement (Cela pourrait bêtement être un script).
[^] # Re: NSFW
Posté par Guillaum (site web personnel) . En réponse au journal Richard Stallman a changé. Évalué à 5.
Réflexe qui peut se contrôler. C'est presque un pré-requis pour toute jeune fille voulant entrer dans l'industrie du porn. (Je te laisse chercher sur wikipedia, l'article Gorge profonde explique bien le truc. C'est wikipedia, mais c'est tout de même NSFW). (Je trouve passionnant comment wikipedia traite de façon très clair, concise des sujets pour le moins difficile à traiter).
[^] # Re: Problématique
Posté par Guillaum (site web personnel) . En réponse au journal BSD Make Pallàs Scripts 2.0. Évalué à 2.
Il faut que je prenne quelque temps pour réfléchir à l'approche que tu proposes, mais c'est en effet intéressant, merci.
C'est un point sur lequel je ne suis pas d'accord, la liste de dépendance c'est implicitement le document .tex qui la donne et je n'ai pas envie de me répéter, sachant que je change souvent celles-ci.
[^] # Re: Problématique
Posté par Guillaum (site web personnel) . En réponse au journal BSD Make Pallàs Scripts 2.0. Évalué à 2.
Donc il faut inventer un nom, c'est à mon sens une limitation.
Donc il faut que le programme parse le document racine à la recherche d'inclusions vers d'autres documents. C'est faisable, mais c'est dur à rendre robuste (si par exemple quelqu'un défini une macro qui appelle \input).
Donc tu dois spécifier les dépendances à la main, alors que certaines commandes pourraient les gérer d'elles mêmes.
Par contre ce que tu propose me donne une idée pour simplifier mon implémentation. Je garde la commande "MyFancyGraphic", sans le "filename", et la seule chose que fait latex c'est générer un nom de fichier unique basé sur la commande et d'inclure ce nom de fichier unique. Après mon script de build parse le fichier .tex (et ses sous-fichiers) et génère les dépendances en utilisant le même mécanisme, et c'est gagné.
[^] # Re: Problématique
Posté par Guillaum (site web personnel) . En réponse au journal BSD Make Pallàs Scripts 2.0. Évalué à 3.
tl;dr: Je ne veux pas à avoir à lister mes dépendances autre part que dans le .tex et je veux pouvoir lister facilement celles-ci, même quand elle proviennent d'un processus de construction très complexe ayant plusieurs fichiers en dépendance et plusieurs paramètres.
[^] # Re: Problématique
Posté par Guillaum (site web personnel) . En réponse au journal BSD Make Pallàs Scripts 2.0. Évalué à 3.
Sommaire
Merci pour ce message.
Ta solution est intéressante, sauf qu'elle force à décrire dans le makefile la liste de toutes tes dépendances. Ma (courte) thèse contient actuellement plusieurs dizaines de dépendances générées et je n'ai pas envie de devoir les décrire une par une dans le makefile sachant que je le fais déjà dans le .tex.
Use case simple
J'ai besoin de convertir les .poulet en .tortue.
dans latex:
Là latexmk (ou rubber) est capable d'appeler make pour toutes les dépendances, ainsi :
Il y a une règle relativement simple qui dit que :
Use case avancé
J'ai un programme qui prend en paramètre un nom de svg (source.svg) et la liste de calques à exporter (calque1 et calque2) et qui génère un .pdf.
Dans mon latex:
\includegraphics{source__calque1_calque2_layers.pdf}
Le soucis c'est que on ne peut plus faire de règle makefile simple du genre :
avec %1 et %2 des trucs génériques qui seront par la suite associés à $1 et $2
Ce cas reste encore un peu simple, car finalement il suffit d'écrire pour chaque fichier svg du répertoire la règle :
et on peut faire cela avec une macro make:
(ici il me prend tous les .svg que mercurial connait, mais bon)
Ça commence à faire mal ici (en gros, je suis le seul humain de tout ceux qui bossent sur ce projet (i.e, heureusement que c'est ma thèse) qui veut encore lire le makefile).
Cas pathologique (90% de mes use cases)
Je veux un fichier de sortie qui dépend d'un nombre de fichiers d'entrés indéterminé et de N paramètres. Dans mon latex je fais :
et dans mon makefile, et bien je ne sais pas ce que je fais. J'avais adopté une nouvelle solution, je sous-traitais à un script :
qui génère la liste de dépendances qui sera évalué par make à la prochaine passe pour gérer correctement mon build.
Et là je meurs.
Solution actuelle
Alors finalement je fais autrement. J'ai une fonction
Qui prend une commande.
LaTeX ouvre un pipe et écrit cette commande et lit dans un pipe le nom du fichier à inclure.
Un démon (en python, mais on s'en cogne) lit dans le pipe la commande à exécuter, et écrit le nom temporaire de sortie après exécution (en gérant bien évidement un cache pour ne pas reconstruire tout à chaque fois).
Exemple :
Et dans mon code python, j'ai défini une fonction :
Ainsi:
a) chaque action de build est en fait une simple fonction python dans un fichier, fonction paramétrée comme bon me semble et appelée naturellement depuis mon .tex. Mon pire exemple c'est :
b) Je m’embête plus à trouver des noms pour mes fichiers générés, j'ai une fonction de hash à la con qui fait cela, met tout dans /tmp et voila. En plus c'est sympa, le nom dépend des paramètres de la commande et pas de l'endroit ou elle est appelée dans le .tex. Ainsi si je décide de tester en changeant un paramètre, cela va compiler pendant 2 heures, et si je revient sur la version précédente, cela va reprendre l'ancien fichier déjà présent dans le cache.
c) Toutes les dépendances sont mise à jour lors de la passe sur le .tex et dirigées par le contenu du .tex. Ainsi tout est bien synchronisé.
d) Je peux intégrer des "plugins" dans mon outil de rendu. Par exemple, à tout moment, je peux dire que les résultats images qui sortent sont downscalés, ainsi mon pdf se construit plus vite (cela permet d'avoir le bon visuel dans le pdf, à la qualité près, sans prendre 30 minutes parce que toutes mes images hautes résolutions tuent les performances)
Ma plus grosse limitation actuellement, hormis le coté code non robuste et pas du tout vendable, c'est que cela ne gère pas la construction en parallèle des dépendances.
Donc pour conclure, je cherche un outil plus puissant pour générer mes dépendances. Actuellement j'ai une solution foireuse qui fonctionne, mais pas très sérieuse.
# Problématique
Posté par Guillaum (site web personnel) . En réponse au journal BSD Make Pallàs Scripts 2.0. Évalué à 3.
J'ai lu la documentation en diagonale et ce qui m’embête c'est que j'ai l'impression que c'est (pour la partie latex du moins) une n-ième version de rubber/latexmk/yourbuildscript.
Ce que j’attends d'un outil de build pour latex c'est une gestion correcte des dépendances générées. Rubber ne sait faire cela que pour des cas simples (i.e.: générer un .poulet à partir d'un .tortue), latexmk à le même problème, mais sait déléguer à make, mais cette délégation se fait en plusieurs passes et généralement c'est le carnage (i.e.: tu appelles make, qui appelle latexmk pour générer la liste des dépendances, qui appele make, qui génère celles-ci et rappel latexmk… 9 fois sur 10 j'ai un truc recompilé pour rien ou pas recompilé, quand je ne parle même pas d'un echec de latexmk qui perd les pédales).
J'ai craqué, j'ai fais une tambouille maison dégueulasse et utilisable seulement par moi et cela me déprime, et chaque fois que je vois quelqu'un proposer un outil de build pour LaTeX, j'espere que on va me sortir de ce calvaire.
Et vous, vous gérez comment vos dépendances générées ? Attention, je ne parle pas de cas simple du genre convertir des .svg en .pdf, mais plutôt de cas du genre vous voulez afficher une image qui est le résultat du rendu d'une scène avec blender, puis passé dans 4 passes d'image magick, passé dans FFMPEG pour ressortir des images de diagnostic, et bien évidement tout cela doit être paramétré dans le .tex car je peux vouloir changer un paramètre de rendu.
# Hum... Les remote repository c'est pas top
Posté par Guillaum (site web personnel) . En réponse à la dépêche Liquidprompt version 1.7. Évalué à 2.
En gros, chaque fois que je vais dans un répertoire avec un dépot HG qui est lié à un dépôt distant, cela prend du temps ET cela me demande un password ;( Il faudrait juste un élément de config pour pas qu'il s'amuse à vérifier à chaque fois, je m'en cogne un peu de savoir en permanence que je suis sync ou pas sur le dépot distant.
Sinon j'aime bien, sauf que j'ai désactivé les VCS pour l'instant.
# Blue sky
Posté par Guillaum (site web personnel) . En réponse à la dépêche Décès de Cédric Blancher, chercheur en sécurité informatique. Évalué à 0.
Cf title.
# Manque d'outils !
Posté par Guillaum (site web personnel) . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 6.
Le gros souci de ces technologies c'est que cela manque d'outils.
Du coté "carte graphique", c'est Cuda ou meurt. Tout ce qui contient "Open" dans le nom manque d'outils. À une époque, Nvidia fournissait les mêmes outils de diagnostics pour Cuda et pour OpenCL, mais depuis peu (sous Linux en tout cas), les outils nvidia ne sont plus capables de me faire un diagnostic sur mes kernel OpenCL…
Pour ceux qui n'en ont jamais fait, en gros Cuda/OpenCL/OpenGL Compute c'est simple, vous écrivez un code compact, léger, joli, de 30 lignes pour faire une addition de vecteur et cela tourne relativement vite. Après vous, regardez ce que disent les outils, et vous vous rendez compte que vous n'utilisez que 5% de la puissance théorique de votre GPU… Bon, on améliore un peu son code, au final il fait 500 lignes, contient des "barrier()" de partout, des copies de mémoire de partout et quelques bits hacks et l'on est content. En Cuda c'est simple parce que nvidia fourni des outils qui te disent presque quels bithack seront efficaces. En OpenCL, c'est dans le flou artistique… Et une fois que tu as fini de coder, tu as 2**N façon de lancer ton code et en fonction de la façon dont tu le fais, c'est plus ou moins lent, et cela dépend de la carte utilisée… ARGGGG. (Si cela intéresse, je peux faire un journal sur l'écriture d'une somme en OpenGL compute et quelques débats sur les optimisations et le bordel que c'est.)
Maintenant, j'ai craqué, je fais tous mes kernel en OpenGL compute, et je ne fais que des codes "simples et intuitifs", en acceptant de ne tourner qu'à 10% de la puissance théorique..
Côté CPU, OpenMP c'est vraiment sympa, mais je lui préfère intel TBB qui, au lieu d'être à base de directive de précompilateur, est une librairie. Sur le papier, j'aime moins, mais c'est subjectif.
Ma petite réflexion du jour s'adresse aux décideurs qui ont entendu parler du GPGPU : "Un GPU n'est pas un tool magique qui multiplie votre puissance de calcul par plusieurs millions. Oui, c'est intéressant, oui c'est puissant, mais cela vient avec un cout de dev/maintenance non négligeable et cela ne règle pas tous les problèmes. Et si vous preniez autant de temps pour optimiser vos codes CPU que vos codes GPU, sans doute que vous ne vous poseriez pas la question d'utiliser un GPU". (PS: oui, j'en ai marre des comparaisons qui bench du code CPU de merde, sans SIMD, sans thread, avec des patterns d'accès mémoire naze, sur un cpu à 30 euros avec un TDP de 3 Watt et qui les comparent à 2 ans de dev sur un code GPU optimisé au poil pour une gamme de cartes particulières, qui coute 600 euros et consomme 400 Watts !)
[^] # Re: Fôtes
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. Évalué à 4.
J'en ai quelques autres, je crois :
"quelque-chose que Dirk Hondel avait déclaréE"
"la plupart d'entre nous ait" - > aient
"a aussi été fusionnée dans ce noyau" -> ONT aussi été fusionnéEs…
[^] # Re: Précision qui m'intérroge
Posté par Guillaum (site web personnel) . En réponse au journal Tintin tombera-t-il un jour dans le domaine public ?. Évalué à 7.
Genre du libre/public à deux vitesses. Si t'es gentil c'est public, mais si t'es méchant, alors c'est pas public. C'est 'achement libre tout ça.
[^] # Re: Destructif ?
Posté par Guillaum (site web personnel) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 3.
Merci pour cette réponse.
Je suis au courant du support de GEGL, mais c'est vrai que c'est une chose que j’attends comme le messie depuis quelques année et c'est vrai que cela prend du temps (simple constatation, ce n'est pas un reproche, j'ai préféré envoyer mes patchs à Blender et LuxRender plutôt qu'a GIMP, donc je râlerais le jour où j'aurais un peu contribué ;)
Oui, mais pour moi il s'agit d'une limitation du miroir de blender, qui devrait par exemple n’être applicable que sur une sous-partie de l'objet.
De la même manière, un filtre "miroir" dans Gimp devrait pouvoir étre applicable qu'à une sous partie de l'image (en utilisant par exemple un masque de sélection).
C'est malheureusement le problème. Cependant je suis persuadé que les artistes auraient à gagner d'un workflow moins destructif (à condition que celui-ci ne soit pas compliqué). Enfin bon, je divague mais je ne propose rien, donc bon ;)
# Destructif ?
Posté par Guillaum (site web personnel) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 3.
Ce que je regrette avec ce genre d'outil c'est que cela soit destructif. En gros, quand on dessine d'un coté de l'image, cela se contente d'effectuer la même action de l'autre coté. L'approche différente serait d'avoir un "filtre/effet/modificateur" qui applique le miroir. (Un peu comme le modificateur miroir dans Blender).
C'est surement une des choses qui m’empêche de devenir un artiste, c'est accepter la perte d'une information importante (qui est la symétrie ici). Parce qu'au final, cette image pourrait se simplifier à :
Un calque qui contient l'image du haut
Un calque qui contient le bateau
Un effet de calque qui duplique et miroir les deux autres calques
Un effet de calque qui redimensionne et tinte le calque de reflet.
Ainsi il est possible par la suite de transformer l'image original et d'obtenir la mise à jour dans le reflet directement. Alors qu'avec l'approche actuelle, la déformation et la tinte du reflet sont définitifs et toute modification est maintenant impossible.
Ce que j'aimerais voir dans Gimp c'est un outil de composition basé noeuds (comme celui de Blender) pour la composition des calques.
[^] # Re: Tu es dur
Posté par Guillaum (site web personnel) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 10.
Toi t'as jamais eu un pote qui sous prétexte de te filer un coup de main défonce complètement ta salle de bain et te laisse en plan avec du carrelage et des morceaux de fils.
# Pointeurs
Posté par Guillaum (site web personnel) . En réponse à la dépêche Blagues d'informaticiens. Évalué à 7.
C'est un pointeur qui traverse la route, et PAF, segfault!
[^] # Re: Ai-je bien compris ?
Posté par Guillaum (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Merci, je sais, c'est ce que j'ai expliqué plus tôt (au début du thread auquel je m'auto repond.). C'est assez enervant quand on essaye d'avoir une discussion un peu plus avancé de se faire répondre ce que l'on a préalablement expliqué plus tôt. (Un peu comme sur le chan irc d'ubuntu, et depuis peu d'arch linux… Quand tu as un soucis, les seuls aides que tu obtient te conseil des trucs que tu as déjà testé ;)
Mon problème c'est que je n'ai jamais réussi à générer un bout de code tel que:
while(variable){}
avec variable modifiée à l’extérieur et que cela génère une boucle infinie. Automatiquement GCC et Clang me régénérait des fetch pour mettre à jour tout cela. Donc je voulais savoir si j'étais dans un cas bien défini ou pas.
Mais c'est bon, j'ai trouvé un exemple tout con qui marche bien. Stop en -O0 et boucle infinie au dela.
[^] # Re: Ai-je bien compris ?
Posté par Guillaum (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Je suis d'accord, mais si on est pas à la seconde près, le cache sera un jour mis à jour et cela va fonctionner.
Ma question c'est plutôt, est-ce que cela marche tout seul (i.e.: sans volatile et avec potentiellement autant de latence que le cache/write buffer peut prendre) ? Est-ce que je suis garanti que GCC ne me fera pas une boucle infinie. En fait je torture mon code depuis un bout de temps et je suis incapable de générer du code ou gcc/clang remplace cela par une boucle infinie.
Ma question est plus poussé, c'est "Est ce que le fait que GCC/Clang ne remplace pas cela par une boucle infinie est un comportement documenté/standard/… et si oui pourquoi ?".
[^] # Re: Ai-je bien compris ?
Posté par Guillaum (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Ce qui me fait toujours peur c'est que j'ai commencé a me renseigner sur volatile et autre suite à une question existentielle, si j'ai une boucle, genre
running = 1;
while(running)
{
// fait quelque chose, mais ne touche pas à running
}
Ici il semblerait que mon compilateur soit en droit de de remplacer cela par une boucle infinie, d'où le besoin de volatile.
En faisant quelques tests, il semblerait que le compilateur (ici gcc en O3) prenne cette liberté seulement si running n'est pas utilisé autre part dans le code. Si jamais il est fait référence à la variable running avant la boucle pour un appel de fonction ou autre, GCC génère tout de même le read, même sans volatile.
Ainsi je me demande donc. Est-ce une limitation de GCC/CLANG qui n'essaye pas d'optimiser dans ce cas ? Est-ce voulu pour protéger le codeur d'une erreur grossière de code ou y a il une raison bien spécifiée qui fait que dans ce cas le compilateur n'a pas le droit de protéger ?
[^] # Re: Ai-je bien compris ?
Posté par Guillaum (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 6.
Lire: unique instruction, et moinsser moi ;)