Corentin Rossignon a écrit 28 commentaires

Des simulateurs de satellites, le cœur du programme est en C/C++. Le Tcl est utilisé pour faire l'affichage graphique ainsi que l'exécution de scripts permettant d'interagir avec le simulateur.

J'utilise ce langage tous les jours et il a de très nombreux problèmes :

• L'accès aux éléments d'une liste via lindex
• La commande set pour affecter une valeur à une variable
• Impossible de créer des données structurées (sauf TclOO, voir point suivant)
• La partie Tcl Orienté Objet est super lente, donc il ne faut pas trop l'utiliser
• Passage des arguments par copie, on peut simuler des références avec "upvar" pour accéder au contexte de l'appelant
• Le langage est hyper fragile, on arrive très souvent sur des "undefined variable" et le code se retrouve vite remplit de "info exists" pour savoir si la variable existe vraiment
• L'utilisation de la pile C qui peut conduire à des deadlocks juste en utilisant plusieurs vwait
• La communauté, j'ai écrit 3 rapports de bugs et à chaque fois on m'a envoyé bouler
• Le wiki tcl, avec les collègues on l'appelle le musée des horreurs, chacun y va de son petit bout de code pour résoudre des problèmes qui devrait être adressés par le langage (genre enlever un élément d'une liste)

Et concernant Tk :

• C'est lent, par exemple TkText comporte des opérations de base en O(n3)
• C'est moche et les thèmes n'aident vraiment pas
• Ce n'est pas thread safe, impossible d'utiliser Tk dans deux interpréteurs Tcl, ni même d'utiliser un autre toolkit graphique
• Difficile d'écrire une IHM robuste, le simple fait de fermer une boîte de dialogue peut très facilement conduire à un message d'erreur (à cause de la gestion des évènements Tcl)

Le seul avantage que je trouve à ce langage : le binding C ultra simple

file $(ls)

$() correspond à récupérer la sortie standard pour l'utiliser comme argument

Tu peux aussi tester des connexions sur udp : https://mosh.org/
Ce n'est pas du ssh mais ça à l'air de remplir les mêmes besoins

CTRL+D permet aussi de quitter le shell si le prompt est vite ;-)

Je n'ai pas l'impression que le support de Wayland ait progressé. L'historique du lien vers un article type Wiki montre que le texte est sensiblement le même depuis 2014. De plus, le gestionnaire de fenêtre Marco n'a pas l'air d'être activement développé (https://github.com/mate-desktop/marco/commits/).
Je me demande quelle sera la solution proposée entre :
- écrire un compositeur Wayland de zéro
- utiliser la bibliothèque weston-desktop
- forké Mutter

Gitlab me paraît être un très bon remplaçant pour Github, il a l'avantage d'être open source (au moins la community edition). J'ai cherché sur leur site pour savoir comment les serveurs étaient financés, mais je n'ai rien trouvé. Je me doute que le financement doit venir de l'édition entreprise, il faut juste croiser les doigts pour que ça soit suffisant. L'ajout de l'export des tickets est un vrai plus, mais si le site disparaît est-ce que l'on pourras importer ces données dans une autre forge (Github, Gforge, TFS …) ?
J'ai surtout en tête ce qui est arrivé à la forge Google Code, maintenant on retrouve souvent sur le web des liens vers Google Code qui ne sont plus valides. Bravo au développeur de Gitlab pour nous proposer un choix, même si entre Github ou Gitlab, je ne sais vraiment pas quoi choisir.

Est-ce que le 'i' manquant dans le tag est fait exprès ?

Peux-tu préciser ton propos ?

Non parce que pour moi effectivement putassier et BFMTV c’est un peu la même, sortir des interviews aussi creux que 01Net, à base de buzzwords, pour faire frémir la DSI/le ménager… ?

:-P

Tu viens de trouver les 54G de données en trop sur /dev/sda1
Vérifie bien la différence des fichiers avant et après montage avant de les supprimer (vérifie avec df /Z que c'est bien sur sda1)

Tu peux les démonter à la volée avec umount et les remonter après avoir regarder le dossier, au pire tu rebootes et tout restera comme avant (sauf si tu touches à /etc/fstab)
Dans l'ordre, je regarderai en premier sous /Z, puis /mnt/sdb1 et enfin /var

$ umount /Z
$ du -shx /Z
$ mount /Z

Si tu ne peux pas démonter un répertoire (/var va poser problème je pense), il faudra redémarrer en ne montant que /, mais ça c'est un peu plus compliqué

Il semblerait que tu ne puisse pas monter la même partition dans un mode différent.
Il faut donc démonter les autres systèmes de fichiers un-à-un

oui, ça répond à ma question.
On peux voir que ton / ne contient que 2,0G de données, il est en ext3 donc il n'y a pas de snapshot (btrfs).

Il est donc probable que les fichiers qui utilisent tout l'espace soit cachés par un point de montage.
Tu peux donc essayer de remonter /dev/sda1 en lecture seule dans un autre dossier pour t'en assurer.

$ mkdir /mnt/sda1_ro
$ mount /dev/sda1 -o ro /mnt/sda1_ro

Puis tu peux re-faire du dans /mnt/sda1_ro

L'autre explication peut provenir de fichiers supprimés qui sont toujours utilisés par un programme et la meilleur solution est de rebooter complètement la machine

Enlève l'étoile de la commande sinon tu prend en compte aussi les sous dossiers :

$ du -cshx /

c'est quel système de fichier ?

$ mount

Windows utilise le type de partition écrite dans la table de partition alors que Linux ne l'utilise pas.
https://en.wikipedia.org/wiki/Partition_type
Regarde que la valeur soit 07h et pas autre chose (genre 83h)

paste est surtout utile quand on doit manipuler des fichiers par colonne (csv, donnée pour gnuplot …)
Il s'utilise aussi conjointement à cut :

$ cut -f 1 -d ";" f1.csv > f1_1.csv
$ cut -f 3 -d ";" f2.csv > f2_3.csv
$ paste f1_1.csv f2_3.csv > f3.csv

Ces trois commandes permettent de fussioner la colonne 1 d'un fichier et la colonne 3 d'un autre fichier.

*mot[i-1] = '\0';

dois être fait juste avant le execv, dans le fils pas dans le parent.
Pourquoi avoir rajouté un deuxième fork qui fait juste un sleep(2) ?
Pour le mode arrière plan, il faut utiliser :

pid = waitpid(tmp, &etat, WNOHANG); 
if (WIFEXITED(etat))
{
  // fin de l'arrière plan
}
else
{
  // toujours en arrière plan
}

N'hésite pas à lire le manuel de waitpid pour bien comprendre le fonctionnement.
Le plus dur pour gérer l'arrière plan sera de trouver comment sauvegarder tous les 'tmp' qui représentent les fils en arrière plan. N'hésite pas non plus à renommer tes variables avec des noms compréhensibles, le 'tmp' ne devrait jamais exister dans un programme, tu t'apercevra très vite qu'un bon nom de variable est très pratique.

Il faut capturer le symbole '&' dans le mot puis le remplacer par un espace (bien) ou un caractère nul (mieux) :

  if (*mot[i-1] == '&')
  {
    *mot[i-1] = '\0';
    // Mettre ici le code pour le traitement en arrière plan
  }

Pour le waitpid, elle diffère de wait en ajoutant la possibilité d'attendre un processus particulier et de spécifier des options d'attente comme NOHANG qui permet de ne pas rester bloqué dans la fonction si le processus fils n'est pas terminé. wait(&status) est équivalent à waitpid(-1, &status, 0).
En remplaçant le paramètre -1 de waitpid par le pid du processus fils, tu n'as plus besoin de faire une boucle while autour de wait.

Réécrire un shell est un très bon exercice pour mieux comprendre les notions de processus et d'environnement sous linux.
Pour le symbole "&", il faut penser à le supprimer de la ligne de commande avant d'appeler execv, le remplacer par un caractère espace est suffisant.

Pour l'arrière plan, il ne faut pas utiliser wait mais faire plusieurs waitpid avec l'option NOHANG (non bloquant) et trouver un moyen de sauvegarder le pid du processus à attendre.
À toi de choisir comment tu souhaites appeler waitpid et surtout à quelle fréquence, certains shell l'appelle après chaque traitement de ligne.

Après si tu as vraiment envie de t'amuser, tu peux commencer à jouer avec la redirection d'entrées-sorties, les pipes, plusieurs processus en arrière plan …

C'est en effet une partie du travail effectué.
Voilà un lien qui explique les actions effectuées (d'après la documentation officielle) :
http://batsov.com/articles/2011/11/25/emacs-tip-number-3-whitespace-cleanup/

Tu lances emacs et tu fais un "M-x whitespace-cleanup"
Généralement ça fonctionne plutôt bien.

Et donc elle fonctionne comment cette recherche automatique des dépendances dans cards ?
Je pense que la plupart d'entre nous aimerait le savoir pour connaître les limites de l’approche et donc comprendre pourquoi 2% des paquets ne sont pas compatibles avec cette approche.

Pour l'instant nous ne pouvons faire que des suppositions, du genre "ça utilise ldd" ou "ça utilise l'appel système ptrace pour surveiller les fichiers lus".

Ce serait loin d'être marrant, tu perdrais surtout beaucoup d'avantages comme le gain d'espace (mémoire et disque dur) ou la correction des failles de sécurité pour tous les programmes qui utilisent la bibliothèque.

Si j'ai bien compris, la gestion des dépendances automatiques se résume à une analyse statique du binaire (sûrement à coup de ldd) pour connaître les bibliothèques utilisées puis à une recherche dans une base de donnée pour trouver les paquets associés.
On pourrait faire plus intelligent pour construire les dépendances au moment du build. Avec un crochet(hook) dans ld qui interroge directement la base de donnée, télécharge le paquet et continue son build.
Il faudrait aussi un crochet dans pkg-config ainsi qu'une analyse du code source pour trouver les dlopen. Et j'oublie sûrement plein d'autres cas de figure.
Donc beaucoup de travail pour un intérêt limité et qui de plus se limite aux langages type C/C++.

Les (rapports de) bugs ne restent jamais très longtemps parce qu'ils sont cachés sous le tapis :

XBMC uses github for development only, i.e. for pull requests and the discussion of code.

So we use a hook script to automatically close this new issue here.

If you can, we encourage you to investigate the issue yourself and create a Pull Request for us to review.
You may want to check the contributing guide: https://github.com/xbmc/xbmc/blob/master/CONTRIBUTING.md

For bug reports, feature requests and all other support, please go to http://forum.xbmc.org.

Thanks,
Team XBMC.

Oui mais au lieu d'utiliser un navigateur web on utiliserai une application qui fera office de serveur et dont le seul but sera de faire un rendu correct avec une meilleure intégration dans l'environnement client (presse-papier, glisser-déposer, …).
PS : GTK propose le backend broadway pour un rendu dans un navigateur web comme sur la vidéo, c'est dans les dépôts arch si tu veux tester.