gato a écrit 91 commentaires

Bonjour,

tout d'abord, j'ai lu votre roman d'une traite, je l'ai trouvé excellent ! Il pourrait faire le scénario d'un film…

En effet le EPUB ne s'ouvre pas sur tablette (essai avec plusieurs lecteurs) mais un coup de conversion avec Calibre suffit à le réparer (et diminue la taille du fichier).

J'ai relevé quelques typos :

• "pluPierigs" -> "plus"
• "aurrait" -> "aurait"
• "TCSR-8\nUne" -> "TCSR-8.\nUne
• "à l'aise à bricoler" -> "à l'aise de bricoler"
• "pendant de mon approche" -> "pendant mon approche"
• "pas capacité" -> "pas la capacité"
• "des appareils des secours" -> "des appareils de secours"
• "Disposez-vous un" -> "disposez-vous d'un"

Voici une autre méthode d'affichage qui pourrait vous intéresser ; le code est écrit en C avec le module EZ-draw, c'est un petit jeu de labyrinthe 3D en affichage fil de fer. Pour calculer les parties cachées un Z-buffer colonnes est utilisé, et les transformations géométriques sont réalisées avec des matrices (comme en OpenGL).

Sources : jeu-laby.c

Une remarque : il me semble que la déclaration de l'encodage utf8 en début de source est dépréciée en Python3 (il en traine encore beaucoup dans les docs datant de Python2).

Voici un petit résolveur de sudoku écrit en bash : sudoku.sh

C'est un simple backtracking, qui trouve la solution en moins d'une seconde, affichage compris.

Actuellement il y a un casse-tête qui me plaît bien : Hashi ; on trouve sur les stores mobiles des hashis avec des centaines de grilles (par ex Hashi Together).

On peut raccourcir le for avec {a..z}, qui s'expanse en les lettres de a à z :

for char in {a..z} ; do
  echo "$char  $(grep -o $char /tmp/wordle.list | wc -l)"
done

En fait l'objectif ici n'est pas de proposer une nouvelle bibliothèque, mais de proposer un code de départ ultra-simple pour coder et tester des algorithmes en imagerie. La prise en main doit être rapide et le code doit être compréhensible pour des quasi-débutants en C++.

Le schéma d'un programme est le suivant (cf demo1.cpp) : on dérive une classe fille de la classe Astico2D et on redéfinit 3 méthodes, et c'est tout.

class MonApp : public Astico2D {
  public:
    MonApp (int argc, char **argv) : 
        Astico2D (argc, argv) 
    {
        if (!init_ok) return;  // erreur dans l'initialisation
        // ...
    }

    void afficher_touches_clavier () override
    {
        // ...
    }

    bool traiter_touche_clavier (char key) override
    {
        // ...
        return true;  // touche traitée
    }

    void effectuer_transformations () override
    {
        switch (touche_transfo) {
            ...
    }
};

int main (int argc, char **argv)
{
    MonApp app (argc, argv);
    return app.run ();
}

D'autre part tout se passe au clavier (et un peu à la souris), pas de widgets ni de callbacks (on peut juste rajouter des sliders, c'est "cadeau" avec OpenCV).

Voici le genre de résultat que l'on obtient (les transformations pour les touches '1' à '3' sont juste des emplacements pour le code à écrire) :

Je m'appuie sur OpenCV, qui est une librairie très riche, bien documentée et connue, mais ça aurait pu en être une autre en effet.

J'ai fait évoluer ce code depuis plusieurs années, en regardant où les étudiants avaient des difficultés. Chaque étudiant ou binôme me rend plusieurs TPs, et pour évaluer tout ça c'est super pratique d'avoir une interface unifiée et qui tient en 1 seul fichier !

Mkdocs-et est passé à la version 1.2 avec des petites améliorations internes (dont les fameux chemins par défaut, qui sont maintenant dans ~/.local/share/ et ~/.cache).

J'en ai profité pour poster 2 améliorations sur le github de Material for Mkdocs ; l'auteur en a accepté l'une des 2 et refusé obstinément l'autre…

Sinon, j'ai commencé à réécrire mon cours avec, cf par exemple le CM 2 , ça donne pas mal, et aussi, le markdown reste bien lisible.

La fonctionnalité la plus importante est la boîte de recherche dans tous les documents, ça c'est cool (à la fin il y aura 20 CM et 20 TP).

Au niveau markdown il manque encore un équivalent de {tabbing} en LateX, je vais voir pour écrire un plugin à l'occasion.

Il y a 2 inconvénients :

• je ne suis pas certain que ces répertoires soient standards sur MacOS ;
• on ne pense jamais à aller voir dans .local et .cache ce qui s'y trouve, noyés qu'ils sont dans la masse des répertoires cachés…

Merci pour le compliment !

Oui ce choix des dossiers est un peu personnel mais comme dit c'est configurable. J'aurais pu les mettre en répertoires cachés. Comme j'ai déjà un ~/bin avec tous mes scripts et un ~/tmp avec des trucs à jeter mais qui doivent quand même survivre à un reboot, ça allait bien.

Le répertoire temporaire est détruit à la sortie du script ; comme il y a un $$ dans le chemin, ça permet de lancer en même temps mkdocs-et.sh serve -all dans un terminal, et de faire dans un autre terminal de temps en temps un mkdocs-et.sh publish -all sans interrompre le premier, comme ça ils ont chacun leur propre tmp et ne se marchent pas sur les pieds.

L'important est que tout soit dans la même partition pour les hard links (donc pour moi ça exclut /tmp car /home a sa propre partition).

Avec l'outil présenté il y a l'embarras du choix :

• l'include Markdown --%<-- "file" lien
• l'include Jinja2 {% include "file" %} lien
• l'include javascript <script src="file"></script> lien
• l'include PHP <?php include "file" ; ?> lien

Pour ce qui est des tableaux, il y a une extension (que je n'ai pas essayée), et on peut aussi mettre des tableaux html.

Le but est de faire des pages un peu jolies sans y passer des heures (contrairement à LaTeX, que j'aime beaucoup, mais faire des slides bien présentés en LaTeX est hyper-chronophage).

non, VirtualBox est utilisé pour des TP d’administration système et réseaux ; les étudiants tournent sur Linux/Mac/Windows et l'avantage de VirtualBox est l'installation simple sur les 3 types de host, la gestion de réseaux virtuels, de disques virtuels, etc.

Par ailleurs VirtualBox donne le choix de l'hyperviseur à appeler (KVM, Hyper-V, etc) mais ça ne marche pas pour le moment :(

avec quelle version de W10, Virtualbox et quelle VM ?
Y a-t-il un paramétrage particulier de la VM, ou des options du noyau ?
J'ai un peu essayé de tout sans succès…
Au démarrage de la VM il affiche au bas de la fenêtre la petite tortue verte (au lieu de l'icone "V" bleu), grise la case VT-x/AMD-V, et à partir de là c'est fichu…

Sur les dernières versions de Windows 10 (testé avec 20H2), il y a de fortes "chances" que Virtualbox (actuellement 6.1.18) ne marche plus du tout : les VMs crachent au début ou en cours d'installation (testé pour Ubuntu 20.04, 16.04, Debian NakeDeb et CentOS8).

Ceci arrive lorsque Hyper-V est activé, car il masque les instructions VT-x/AMD-V (il pourrait ne pas le faire…). Hyper-V est logiquement activé lorsqu'on installe WSL ou WSL2 ; mais il semblerait qu'il le soit aussi pour d'autres services voire par défaut (c'est arrivé à certains de mes étudiants qui n'avaient pas installé WSL).

Voici la description description technique du problème, et à la fin du lien 2 solutions.

En gros, vous aurez soit WSL/WSL2, soit VirtualBox, mais pas les 2 en même temps…

Bonjour,

select modifie les fd_set et les timeout, c'est pourquoi il faut les réinitialiser dans la boucle avant chaque appel.

Pour une meilleur portabilité préférez pselect ou son équivalent ppoll.

À noter : la résolution des timeouts est differente selon l'interface : poll en millisec, select en microsec, pselect et ppoll en nanosec.

Emacs arrive bientôt au niveau de gedit :)

Bonjour,

j'avais un "vieux" raspberry 1B 512, je l'ai équipé avec un Hifiberry DAC (il n'est pas compatible avec le modèle DAC+). Ils fournissent un petit connecteur 8 broches qu'il faut souder sur le RPI. Je n'ai pas trouvé de boîtier pour mettre l'ensemble (ils ne sont plus vendus), alors j'ai découpé le boîtier transparent pour laisser passer les prises audios du DAC, et le tour est joué.

Côté logiciel j'ai mis RuneAudio. Je dois dire que ça marche très bien, le RPi boote en quelques secondes, et il arrive à monter sans problème tous les disques en réseau de la maison (sur la box, le médiacenter de la box, les ordis exportant du Samba), et se pilote de n'importe quel navigateur, ou de l'appli Androïd.

Le DAC est branché sur un ampli Marantz et des enceintes "GUY HF", une vieille marque (française, disparue il me semble), de très bonne qualité audio (3 voix, 2*100W).

Résultat : pas mal, mais la différence avec un CD est nette.

Questions :

• quelqu'un a-t-il testé la différence de rendu audio entre un DAC et un DAC+ ?
• l'OS de RuneAudio est un ArchLinux, or je préférerais un Raspbian ; quelqu'un a-t-il comparé RuneAudio avec Volumeio (basé sur raspbian), au niveau vitesse de démarrage et interface web ?
• quelles fonctionnalités supplémentaires apporte max2play (solution non libre) ?

Merci,

Bonjour,

y a-t'il un projet équivalent en fonctionnalités sous Gnome, utilisant GTK ou Wxwidget ?

Merci

Non, l'idée est de donner une "base nue" pour inciter les étudiants à écrire leur propres widgets ; l'expérience montre que ça leur plaît beaucoup plus que d'utiliser un truc tout fait.
Je limite de plus volontairement les fonctions graphiques pour rendre possible de nombreux exercices.

C'est assez tentant, ça réglerait de plus un petit problème pour l'affichage avec transparence : actuellement c'est fait avec un simple seuil. J'avais regardé avec les extensions X qui vont bien, mais c'était assez indémerdable, et beaucoup trop complexe pour le projet …

Parce que ce n'est pas non plus au niveau de la SDL, c'est un peu au dessus : on pourrait le situer au niveau GDK + pixbuf.

Je parle de GTK+ et Qt pour opposer la simplicité du projet. Évidemment si on se focalise sur les widgets vous avez raison.

Oui c'est le cas, mais en plus simple ; par exemple il y a un certain nombre de fonctions pour manipuler les images (rotations, zoom, etc) bien pratiques. Le but est ensuite de pouvoir (ou d'avoir envie de) passer à des toolbox "pro" comme SDL ou SFML en ayant compris quelques concepts de base, sans être perdu.

Il n'y a pas de widgets, c'est volontaire aussi : d'une part il existe déjà de nombreux toolkits qui font ça (j'en avait fait un il y a quelques années : Helium), et d'autre part ça incite les étudiants à coder eux-même ; ainsi j'ai vu des étudiants faire spontanément des boutons, ascenseurs, etc, et ça leur plaît plus que de prendre un truc tout fait.

Bonne idée, je vais regarder ça !

La prochaine étape de développement est ez-sound.c, un module qui jouerait des sons sur Linux/MacOSX/Windows. Est-ce que vous connaissez des programmes simples qui font cela ? Pour la partie chargement d'image je me suis appuyé sur stb_image.c et il existe peut-être des choses de ce genre pour les sons ? Je cherche juste à pouvoir faire quelques bruitages pour les jeux (fichiers wav), même un son à la fois sans mixage serait bien.

Je vise aussi les apprentis programmeurs sur Mac OS X (il faudrait faire un .dmg) et ceux qui utilisent windows (il faudrait un installeur qui installe aussi MinGW .. ouf). Ça ferait une grosse usine à gaz pour pas grand chose : je ne cherche pas à concurrencer SDL (qui est très bien - d'ailleurs si un jour j'ai le temps, je porterai EZ-Draw sur SDL ce qui permettra aussi de fonctionner sur Android). Comme de toutes façon le but est d'écrire un fichier C et de le compiler, autant le faire de suite.

Pour la mise à jour il faut voir le contexte : dans les salles de TP on n'a pas toujours la possibilité de demander telle version ou telle mise à jour aux sysadmins (il y a 3 campus gérés différemment et une bonne vingtaine de salles) et à l'usage c'est très pratique pour les étudiants de n'avoir qu'un tarball à télécharger et à installer en local - d'ailleurs le Makefile est réglé pour fonctionner de base sous Debian/Ubuntu/Fedora et sous Windows, il y a juste un petit réglage pour Mac OS X (ils modifient les chemins à chaque version, c'est pénible) et sous Cygwin (mystérieusement il faut -std=gnu99). J'aurais pu rendre le Makefile entièrement automatique mais il était déjà assez compliqué comme ça (les étudiants doivent pouvoir se l'approprier - surtout les débutants).

Bon évidemment si quelqu'un me propose un script qui me transforme le tarball en .deb, .rpm, .dmg ou quoique ce soit, ça m'intéresse et je mettrai un lien !

Ce n'est pas vraiment l'esprit, qui est plutôt "tout en 1 fichier" et "compilez vous-même" …