mothsART a écrit 180 commentaires

C'est vrai que l'idée est là : ce projet pourrait tout à fait cibler des personnes âgés ou débutantes.

debcargo qui est lui-même dev en Rust !
Les builds pour l'ensemble des architectures : c'est complexe mais ça en vaut le coup !
Vraiment intéressant.

debcargo qui est lui-même dev en Rust !
Les builds pour l'ensemble des architectures : c'est complexe mais ça en vaut le coup !
Vraiment intéressant.

je suis pas sur de comprendre :

ça veut dire que vous créer l'ensemble des dépendances dans des paquets séparés ?
Si oui, ça veut dire que vous générez un fichier control à partir du cargo.toml ?

C'est bien la 0.10.0 que j'ai empaqueté : have fun!

C'est vrai que mon utilisation est cloisonné sur de l'émulateur de terminal donc l'intérêt est moindre.

Bien sur que je suis curieux.

C'est vraiment sans appel :

time python -c "import re; print(re.search('(a*)*c', 'a' * 30))"
None
python -c "import re; print(re.search('(a*)*c', 'a' * 30))"  506,43s user 0,39s system 61% cpu 13:43,80 total

et le code équivalent en Rust (après compilation en release) :

extern crate regex;
use regex::Regex;

fn main() {
    let re = Regex::new("(a*)*c").unwrap();
    print!("{:?}", re.find("aaaaaaaaaaaaaaaaaaaaaaaaaaaaa"));
}

ça donne :

time ./target/release/essai_regex
None./target/release/essai_regex  0,00s user 0,00s system 53% cpu 0,007 total

J'ai mis moins 10 fois moins de temps à compiler + exécuter en rust.

Faut croire… je connaissais pas !
Mais pourquoi c'est pas le comportement par défaut (ou au moins dans les distrib) parce que je vois pas à quoi ça sert sans.

Ben non (je me suis mal exprimé) : avec less, t'as un fichier de 2 lignes, t'es obligé de quitter quand même donc tu perds l'avantage d'un simple cat.

J'ai suivi ce projet aussi du coin de l'oeil mais plus d'un point de vue didactique. (comment vont-ils dev tel commande unix)

Il n'y a pas encore de versionning : c'est pas un peu tôt pour en faire un paquet ?

Je regardais dans les jours qui viennent ce que je peux faire ;)

Pas vraiment prévu, non.
Dans un premier temps, j'ai réfléchi à ma pomme (enfin plutôt à la distrib PrimTux) : je voulais empaqueter mes projets Rust … puis voyant que certains projets intéressants n'étaient pas dispo pour Ubuntu/Debian j'ai joint l'utile à l'agréable.

Je ne serais pas contre le fait de porter upstream mais pour cela, j'aimerais bien connaitre la procédure.
J'ai mis l'ensemble de mon travail sur mes dépôts GIT.

Exact, j'ai également suivi le travail de Burntsushi.
C'est lui qui est le principal dev de la lib de regex de Rust donc ripgrep est vraiment un proof of concept de sa qualité. (basé sur une machine à état fini)

C'est effectivement édifiant de voir sa démarche jusqu'au benchmark : un savoureux mélange entre la mise en pratique d'un automate fini, de petites astuces pour gagner en perf, sa comparaison avec la concurrence etc.

Y'a l'approche théorique pour un projet sain et le pragmatisme du dev.

exact, un oubli.

j'aurais tendance à dire que bat c'est plutôt cat + less car on peut naviguer de page en page, aller au début ou à la fin du fichier avec les touches qui vont bien.
C'est franchement un confort de ne pas réfléchir à la taille du fichier : avant de l'utiliser, ça m'arrivait de faire des cat sans le less et de pester derrière.

Il faudrait sans doute proposer la même fonctionnalité aux autres outils que sont exa, fd, ripgrep.

Pour rigrep, je ne faisais même plus gaffe mais j'ai ceci dans mon .zshrc :

export LESS='-R'
alias rg='rg --pretty'

On ne c'est pas penché sur la question et il n'y a pas encore eu de demande dans ce sens.

Comme mentionné dans l'annonce, cette distrib est bâtie sur la raspbian strech donc ça doit être disponible.

J'ai créé un sujet sur le forum : http://forum.primtux.fr/viewtopic.php?pid=13158#p13158
Si t'as déjà fait sur raspbian, je t'invites à partager de la doc à ce sujet : je testerais et si c'est concluant, je rajouterais un tuto dans le wiki de Primtux.

Je ne vois pas LXTerminal qui est le terminal de LXDE et par extension le terminal par défaut d'une raspbian.

Je viens de sortir une version 1.0.rc3.
Cette dernière comporte :

• 1 nouvelle fonctionnalité + 1 correctif concernant le dysfonctionnement signalé par pym.aldebaran:
  La prévisualisation et les fichiers générés comportent désormais un icône "Ajuster la page à l'illustration".
  Le zoom arrière sur un indice reste centré autours de l'indice

• 1 bug bloquant sous firefox : le fonctionnement du drag and drop des indices est désormais identique à chrome.

• 1 bug firefox de déplacement du svg lors du retour en mode édition.

Les deux derniers étant rapportés par Cyril Borne dans une issue github.
J'encourage d'ailleurs chacun à procéder de cette façon : https://github.com/mothsART/editInteractiveSVG/issues

J'ai également rafraîchit la doc.
Le paquet sur le ppa a également été rafraîchit mais le build ne c'est toujours pas terminé : https://launchpad.net/~jerem-ferry/+archive/ubuntu/app-illustration/+builds

Par curiosité, j'ai testé l'incorporation de svg à la place d'une image et miracle, le svg est converti en base64.
C'est une fonctionnalité que j'ignorais et qui est déjà présente (il va falloir que j'en parle dans la doc ainsi que dans le menu d'aide)

Néanmoins, le greffon d'ajout d'image est vraiment spartiate : il est impossible de redimensionner, déplacer après import.
Je ne sais pas si ça pourra être résolu : il faudrait que je mettes le nez dans le source de trumbowyg (l'éditeur wysiwyg utilisé)

Sur la page de pouvoir zoomer/dézoomer avec la molette de la souris

Pas bête : ça concerne l'éditeur, l'animation finale ou les 2 ?

Pouvoir switcher d'une puce numérotée à une autre depuis la souris/clavier (flèches ?)

Ok pour le clavier. Faudra sans doute que je prévois un surlignage pour désigner la puce avec le focus.

Le switch à la souris ? Tu peux détailler ?

Merci tout d'abord aux aventuriers qui ont testés !
Si le soft est pas trop mal fini, c'est aussi grâce aux équipes de PrimTux et AbulEdu qui ont testés, conseillés, aiguillés, suggérés !

Alors j'y vais de mon petit rapport de bug tout simple : lorsque l'on clique sur un numéro, …

En effet, je vais voir pour modifier ça… c'était au départ plus une fonctionnalité qu'un bug car lorsqu'un indice est très excentré, on ne voit plus une partie des autres indices.

Je pense que je vais envisager un bouton pour re-centrer l'image. Le plus dur va être de trouver le bon terme et/ou logo.

Comment tu le positionnes par rapport à Sozi ? Cela pourrait il être complémentaire ?

Je ne connais Sozi que de nom.
Du coup, j'ai installé et vois que c'est également un beau projet.
J'ai pas suffisamment de recul pour dire si on marche sur les mêmes plate-bandes.

Je dirais que mon soft n'a jamais eu vocation de faire de diaporama.

Ensuite, ce qui nous différencie à première vue c'est aussi les dépendances : Sozi est lié à Inkscape et Python alors que mon soft se base sur des technos web.

Bref, même si on peut arriver au même résultat, c'est aussi ça qui fait le libre :

choisir son outil dans la diversité.

Pourrais tu faire apparaître des objet svg dans les zones de texte ?

J'ai intégré un module pour insérer des images un peu en dernière minute.

Pour une version 2.0, j'ai déjà noté la possibilité de rajouter des vidéos et du son.
Néanmoins, ça nécessitera de revoir le fichier produit (un zip ou zim) : pour les images, je triche en convertissant en base64.

Pour du svg, c'est moins compliqué : j'en prend note pour une version intermédiaire.

xpath plus simple : permet moi d'en douter.
Fiable : j'ai envie de répondre : ça dépend.
Dans le cadre du soft "update-warners" qui ne fait pas vraiment du scraping poussé mais juste la récupération d'un motif de chaine, (c'est pas une regex d'ailleurs) je trouve ça plutôt malin et xpath me semble surfait.
Je n'arrive pas à trouver de cas ou "soit disant" xpath serait plus fiable.
Pour moi, xpath c'est bien sur du xml normalisé (via xsl) mais pas pour du html ou l'arbo peut vite changer du tout au tout.

boite == tag ?

je parlais du format RSS (XML normalisé) et non pas du fonctionnement des agrégateurs de flux RSS qui lui fait bien du polling sur le protocole HTTP mais pourrais changer leur comportement si ils passaient par du websocket.

Faudrait un RSS (ou équivalent) mais via websocket: du coup, il suffirait de se connecter à un canal et d'attendre le push du serveur.

Bien évidement, c'était à prendre aux dixième degré.
Mais mon clavier à suivi ma première pensée : c'est l'endroit idéale pour se défouler ?!

Néanmoins, je dirais que le nerd de la guerre, c'est le sujet : si c'est un débat scientifique, technique, le but est louable : on peut avoir un éventail des pour et des contres et pourquoi avec une modération supprimant les arguments déjà évoqués.

Si c'est un domaine qui fait rentrer l'interprétation, les croyances, ça peu vite très vite dériver.