/* Topic des codeurs [8] */

Elzen · Le 17/08/2013, à 19:58

grim7reaper a écrit :

Je manque vraiment de temps en ce moment, beaucoup de trucs (geek et non-geek) à gérer, donc non je n’ai pas encore jeté un œil.

Courage

grim7reaper a écrit :

Une seule remarque : il me semble que tu pars sur du Python 2/PyGTK. Je trouve ça vraiment dommage
Autant pout Touhy je peux comprendre (et je suis même d’accord avec ton argumentation) : tu as une grosse base de code, et il vaut mieux attendre de voir le successeur de X (vu que tu te bases sur des trucs spécifique à X, pas du pur GTK).
Autant pour un petit jeu où tu pars de zéro, je trouve ça dommage.
Mais c’est toi qui vois bien sûr.

Pas faux. Très vrai, même.

Mais vu la façon dont le truc s'oriente (plusieurs versions dans des langages différents mais dans le même dépôt) et la façon dont ça fonctionne (la plus grosse partie du code est normalement faite pour de bon et ne bougera plus ; le reste, ce sera ajouter des objets à comportement spécifique, plutôt rapide à coder (en gros, la difficulté est surtout de leur donner une tronche correcte, pour le comportement, c'est très simple)), il n'est pas inenvisageable que j'ajoute encore d'autres versions en choisissant des technos plus durables

Le truc, aussi, c'est qu'il faut que je choisisse ce que je vais prendre, comme truc plus moderne : GTK ? Qt ? Une bibli graphiqueplus spécialisée ?

Shanx a écrit :

@grim : par curiosité, le problème c’est quoi ? Python 2, ou PyGTK ? (ou les deux ?)

Les deux. PyGTK, c'est le binding de GTK2 spécifique à Python2, donc les deux sont en voie de disparition (les gens qui gèrent GTK ont décidé qu'à partir de la version 3, ils ne faisaient plus un binding spécifique par langage, mais un truc générique (gobject introspection)).

Shanx a écrit :

Petite question sans beaucoup de rapport : quand on parle d’un langage de prog’, faut-il mettre une majuscule ? J’en vois souvent une, alors que pour ma part je n’en mettrais pas. Y-a-t-il quelque part une règle typographique un peu plus précise que « selon le bon vouloir de celui qui écrit » ?

T'veux dire, pour le nom du langage ? Je dirais nom propre, donc majuscule.

Dernière modification par Elzen (Le 17/08/2013, à 20:00)

grim7reaper · Le 17/08/2013, à 20:08

Shanx a écrit :

@grim : par curiosité, le problème c’est quoi ? Python 2, ou PyGTK ? (ou les deux ?)

Les deux.
Python 2 est voué à disparaître (même si c’est pas pour demain, ni après-demain), donc autant partir sur Python 3 si possible (i.e. si les bibliothèques utilisées sont toutes dispo’ en Python 3).
PyGTK est le vieux binding GTK+ (il ne couvre que GTK2, lui aussi voué à disparaître mais pas dans un futur très proche) et c’est un binding old-school (si je puis dire).
Les bindings GTK (que ce soit Python ou autres) se basent maintenant tous sur GObject Introspection (GI pour les intimes).

Shanx a écrit :

Petite question sans beaucoup de rapport : quand on parle d’un langage de prog’, faut-il mettre une majuscule ? J’en vois souvent une, alors que pour ma part je n’en mettrais pas. Y-a-t-il quelque part une règle typographique un peu plus précise que « selon le bon vouloir de celui qui écrit » ?

Pour ma part, c’est majuscule par défaut : je prends ça comme un nom propre et ça permet de faire la distinction avec les noms communs (ruby, python, …). Il semble que Wikipédia fasse pareil (bon après c’est pas une règle de typo’, je ne sais pas s’il y’en a une à ce sujet…)

Après si le langage a une casse explicite je la respecte bien sûr.
Niveau casse explicite, je peux prendre l’exemple de Qt (c’est une bibliothèque mais le principe est là) : c’est Qt, pas qt ou QT (QuickTime…).
De même, ça se prononce cute, pas cul-thé ou je ne sais quoi comme je l’entends souvent…

Édit : grilled by Elzen pendant ma rédaction du coup je lui répond aussi

Elzen a écrit :

grim7reaper a écrit :
Je manque vraiment de temps en ce moment, beaucoup de trucs (geek et non-geek) à gérer, donc non je n’ai pas encore jeté un œil.
Courage

Merci.

Elzen a écrit :

grim7reaper a écrit :
Une seule remarque : il me semble que tu pars sur du Python 2/PyGTK. Je trouve ça vraiment dommage
Autant pout Touhy je peux comprendre (et je suis même d’accord avec ton argumentation) : tu as une grosse base de code, et il vaut mieux attendre de voir le successeur de X (vu que tu te bases sur des trucs spécifique à X, pas du pur GTK).
Autant pour un petit jeu où tu pars de zéro, je trouve ça dommage.
Mais c’est toi qui vois bien sûr.
Pas faux. Très vrai, même.
Mais vu la façon dont le truc s'oriente (plusieurs versions dans des langages différents mais dans le même dépôt) et la façon dont ça fonctionne (la plus grosse partie du code est normalement faite pour de bon et ne bougera plus ; le reste, ce sera ajouter des objets à comportement spécifique, plutôt rapide à coder (en gros, la difficulté est surtout de leur donner une tronche correcte, pour le comportement, c'est très simple)), il n'est pas inenvisageable que j'ajoute encore d'autres versions en choisissant des technos plus durables

Ok.

Elzen a écrit :

Le truc, aussi, c'est qu'il faut que je choisisse ce que je vais prendre, comme truc plus moderne : GTK ? Qt ? Une bibli graphiqueplus spécialisée ?

Ça c’est toi qui vois ^^
Tu peux même tous les choisir et laisser le choix à l’utilisateur en faisant un truc genre comme on (bon surtout moi sur cette partie-là ^^") avait codé pour Hortus Belli.

Dernière modification par grim7reaper (Le 18/08/2013, à 07:42)

Rolinh · Le 19/08/2013, à 12:23

Un article intéressant sur la réécriture d'un système de C++ vers Go. L'auteur est un ancien professeur de Harvard qui travaille maintenant chez Google. Il ne connaissait pas Go avant de commencer ce projet. Venant de quelqu'un de chez Google, l'article peut paraître un peu biaisé mais il relève tout de même les choses qui lui déplaisent dans Go à la fin de son article. Personnellement, j'ai trouvé intéressant et selon lui, quelqu'un qui a un background de C ou de C++ s'adapte très vite au Go.

@Elzen: pour les ressources, tu utilises bien les variables d'environnement de XDG en premier lieu? XDG_DATA_HOME et XDG_DATA_DIRS (avec fallback sur les répertoires par défaut si les variables ne sont pas exportées). Dans cette optique, je pense que /opt devrait être vérifié après /usr/local et ce d'autant plus que sur les systèmes BSD, les binaires non core-system (que l'utilisateur installe quoi) sont installé par défaut dans /usr/local.

Elzen · Le 19/08/2013, à 12:42

Grmblm, je savais que j'oubliais un truc.

Si je fais ça, ça semble bon ?

    resfile = os.path.join(respath, *args)
    if os.path.exists(resfile): return resfile
    if "XDG_DATA_HOME" in os.environ:
        resfile = os.path.join(os.getenv("XDG_DATA_HOME"), libname, *args)
        if os.path.exists(resfile): return resfile
    if "XDG_DATA_DIRS" in os.environ:
        for xdgdir in os.getenv("XDG_DATA_DIRS").split(":"):
            resfile = os.path.join(xdgdir, libname, *args)
            if os.path.exists(resfile): return resfile
    resfile = os.path.join(os.getenv("HOME"), ".local", "share", libname, *args)
    if os.path.exists(resfile): return resfile
    resfile = os.path.join("/usr/local", libname, "resources", *args)
    if os.path.exists(resfile): return resfile
    resfile = os.path.join("/usr/local/share", libname, *args)
    if os.path.exists(resfile): return resfile
    resfile = os.path.join("/opt", libname, "resources", *args)
    if os.path.exists(resfile): return resfile
    resfile = os.path.join("/opt/share", libname, *args)
    if os.path.exists(resfile): return resfile
    resfile = os.path.join("/usr/share", libname, *args)
    if os.path.exists(resfile): return resfile
    return os.path.join(*args)

Edit : ceci dit, Touhy ne tourne probablement pas sous *BSD, mais ce que tu indiques à ce sujet aurait plutôt tendance à me faire remettre /opt en premier : je préfère vérifier en dernier les répertoires où est censée se trouver l'installation propre, puisque, s'il y a quelque chose ailleurs, c'est que l'utilisateur a choisi volontairement de mettre des trucs à cet endroit-là, donc que c'est censé être ce que lui veux plutôt que les trucs par défaut du système. Non ?

Dernière modification par Elzen (Le 19/08/2013, à 12:52)

Rolinh · Le 19/08/2013, à 13:25

Ça me semble bon en tout cas. Et pour ton "edit", tout compte fait je pense que tu as raison.

Qu'est-ce qui pourrait empêcher Touhy de tourner sous les systèmes BSD?

Elzen · Le 19/08/2013, à 13:33

Bon, j'ai remis /opt en premier et commité ça. The Uploader, si tu veux faire la MàJ

@Rolinh : une bonne partie de l'environnement ne devrait pas avoir de soucis pour tourner (enfin, si on excepte que c'est sous GNU GPL et que ça repose, me semble-t-il, sur des biblis qui le sont aussi, or les clauses virales et les utilisateurs de *BSD ne font pas toujours bon ménage ^^) ; mais, pour tout ce qui est gestion de périphériques, j'utilise udev, qui est, me semble-t-il, une spécificité du noyau Linux. Je n'ai pas regardé ce qui se passerait exactement, mais je dirais que ce serait, au mieux, un peu limité.

The Uploader · Le 19/08/2013, à 13:51

Elzen, aurais tu un exemple du fichier de config que lit touhy-session ? Ce serait le fichier ~/.config/touhydev/touhy-session ?

edit: et hop de la pub pour rreader
(faudrait que je contribue à nouveau, d'ailleurs, vu que de toutes façons personne ne répond côté job/stage en ce moment)

Dernière modification par The Uploader (Le 19/08/2013, à 13:59)

Rolinh · Le 19/08/2013, à 15:10

@The Uploader: avec plaisir
J'ai un peu changé la roadmap hier. Le plus urgent à améliorer de mon point de vue reste le rafraîchissement des flux (voir #189). Une piste à explorer est la gem whenever qui permet de définir des tâches qui s'effectuent à intervalles réguliers à la manière de cron. J'ai vu plusieurs lecteurs de flux RSS qui demandent à mettre en place manuellement un cron qui fait genre un wget sur une page pour mettre à jour les flux. Selon moi, c'est absolument à éviter car non seulement cela demande une intervention de plus lors de l'installation mais en plus il n'est en général pas possible d'éditer les tâches cron sur un hébergement mutualisé.
Sinon, ça fait maintenant 1 mois environ que j'ai importé tous mes flux sur RReader et c'est vraiment ce qui manque le plus pour une utilisation agréable car le rafraîchissement des flux au clic sur le titre du flux induit une latence indésirable.

Elzen · Le 19/08/2013, à 15:55

The Uploader a écrit :

Elzen, aurais tu un exemple du fichier de config que lit touhy-session ? Ce serait le fichier ~/.config/touhydev/touhy-session ?

~/.config/touhydev/system/session.infos

Ça donnerait un truc comme ça :

#~ Commandes à lancer au démarrage de la session
[start]
env=touhy-full
wm=x-window-manager
0=nm-applet &
1=play /usr/share/sounds/purple/login.wav
2=pidgin &

#~ Commandes à lancer à la fermeture de la session
[stop]
0=play /usr/share/sounds/purple/logout.wav

#~ Prévenir si ces processus sont actifs
[pwatch]
0=pidgin::#theme:pidgin

Chacune des trois sections est totalement optionnelle ; si le fichier est vide ou n'est pas présent, touhy-session se contente de lancer touhy-full et le gestionnaire de fenêtres par défaut au démarrage, et rien à la fermeture.

Dernière modification par Elzen (Le 19/08/2013, à 15:55)

The Uploader · Le 19/08/2013, à 16:01

Merci.
Pour le démarrage, pourquoi pas supporter autostart ? C'est un standard FDO, non ?
(enfin ça, c'est pour le futur, c'est déjà très bien comme ça )

Dernière modification par The Uploader (Le 19/08/2013, à 16:02)

Elzen · Le 19/08/2013, à 16:15

Parce que je n'y avais pas pensé et que je ne sais pas trop comment ça marche, mais ouaip, j'vais y réfléchir
Et de rien ^^

Bon, les chantiers à mener quand j'me remettrai à bosser dessus :
– support autostart
– un vrai menu système autogénéré
– amélioration de la prise en charge des systèmes de fichiers par le réseau (tiens, il y a moyen de monter du NFS avec fuse, ou en tout cas sans avoir besoin des droits roots ?)
– gestion des aperçus de fichiers audiovisuels (récupérer une image au pif dedans)
– support pdf amélioré (gestion des titres, de la sélection, des liens…)
– possibilité de mettre les fenêtres en plein écran, et éventuellement autres types de fenêtres
– outils de configuration graphiques, ou au minimum documentation permettant d'aller bidouiller les fichiers à la main
– j'oublie des trucs ? N'hésitez pas si vous voyez quelque chose.

Eh bah, y a du boulot…

grim7reaper · Le 20/08/2013, à 18:04

Tiens, je viens de découvrir (par hasard) encore un truc super sympa avec clang : -Wdocumentation.
Pour ce que j’en ai vu, ça semble vérifier les commentaires Doxygen et ça signale les incohérences. Exemple :

slist.h:117:11: warning: parameter 'list1' not found in the function declaration [-Wdocumentation]
 * \param list1 list 1.

Sympa pour détecter les typo’ ou les commentaires de documentation pas à jour
GCC ne semble pas avoir d’équivalent pour le moment.

Sinon, je viens aussi de changer de bibliothèque pour mes tests unitaires en C.
Dans certaines fonctions, je pose des préconditions à leur utilisation (programmation par contrat quoi). Ee en cas de violation du contrat, je ne garanti plus rien (un peu comme en C, quand on viole la normes on se retrouve souvent avec un undefined behavior sur les bras, et là TOUT peut arriver).
Dans un langage un possédant la notion d’exception, il suffirait de lancer une exception et de demander à la bibliothèque de TU de vérifier que l’exception est belle est bien lancé quand il faut. Or là, je suis en C donc pas d’exception.
Du coup, j’ai choisi d’implémenter ça via assert. Ça à l’avantage de permettre la vérification (en mode debug) et de n’avoir aucun surcoût (en mode release).
Le souci, c’est que assert, ça fait un appel à abort qui va crasher le programme. C’est tout à fait le comportement voulu, mais le problème c’est que c’est intestable par 99% des bibliothèques de TU pour le C (dont CUnit que j’utilisais jusque là) car ça fait crasher toute la suite de TU
Fort heureusement, je viens de découvrir check qui est relativement simple et qui, grâce à son système basé sur fork, permet beaucoup de choses (y compris ce que je veux faire ici).
Petit extrait de la doc’ qui explique le « pourquoi forker » :

http://check.sourceforge.net/doc/check_html/check_2.html#Unit-Testing-in-C a écrit :

Writing a framework for C requires solving some special problems that frameworks for Smalltalk, Java or Python don’t have to face. In all of those language, the worst that a unit test can do is fail miserably, throwing an exception of some sort. In C, a unit test is just as likely to trash its address space as it is to fail to meet its test requirements, and if the test framework sits in the same address space, goodbye test framework.
To solve this problem, Check uses the fork() system call to create a new address space in which to run each unit test, and then uses message queues to send information on the testing process back to the test framework. That way, your unit test can do all sorts of nasty things with pointers, and throw a segmentation fault, and the test framework will happily note a unit test error, and chug along.

Et ça passe comme une lettre à la poste

Et du coup, pour faire ce que je voulais faire, j’ai juste à écrire :

tcase_add_test_raise_signal(tc_core, test_init_fail_null, SIGABRT);

The Uploader · Le 20/08/2013, à 21:06

@Elzen :

Bon, ça avance.

# Maintainer: Maximilien Noal (noal dot maximilien at gmail dot com) [AUR: xcomcmdr]

pkgname=touhy-git
_gitname=touhy
pkgver=48.7069597
pkgrel=1
pkgdesc="Elzen's desktop Environment"
arch='any'
license='GPL3'
install='touhy.install'
url='http://www.irlnc.org/touhy/'
groups='touhy'
depends=('udisks2' 'pygtk' 'python2-wnck' 'python2-notify' \
  'python2-dbus' 'python2-numpy')
makedepends='git'
optdepends=('python2-imaging: display pixel size of image files'
  'python2-mpd: MPD support'
  'python2-poppler: PDF files thumbnails'
  'python2-pyalsaaudio: set the audio volume'
  'python2-sqlite3: Midori and Firefox bookmarks integration'
  'python2-xlib: system tray'
  'python-xklavier: read and modify the keyboard layout'
  'vte: remote menus'
  'xorg-xbacklight: set the screen backlight')
md5sums=('SKIP'
  '4dbb476d0c0f559c13bde4505d81a614')
source=('git://fadrienn.irlnc.org/touhy' 'use-python2.patch')

pkgver() {
  cd ${srcdir}/${_gitname}
  echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD)
}

package() {
  cd ${srcdir}/${_gitname}
  
  mkdir -p ${pkgdir}/usr/bin
  mkdir -p ${pkgdir}/usr/lib/python2.7/site-packages
  mkdir -p ${pkgdir}/usr/share/${_gitname}
  
  cp -r resources/* ${pkgdir}/usr/share/${_gitname}
  cp -r touhy ${pkgdir}/usr/lib/python2.7/site-packages
  
  install elzquit ${pkgdir}/usr/bin

  # remove applications, they have or will have their own PKGBUILD
  rm elz* -f
  
  rm .gitignore
  rm -rf touhy
  rm -rf resources
  for _file in `ls`
  do
    install ${_file} ${pkgdir}/usr/bin
  done

  install -Dm 644 ${pkgdir}/usr/share/${_gitname}/appinfos/touhy.desktop \
    ${pkgdir}/usr/share/xsessions/touhy.desktop
  for _file in `ls ${pkgdir}/usr/bin`
  do
    patch -i ${srcdir}/use-python2.patch ${pkgdir}/usr/bin/${_file}
  done
}

use-python2.patch :

*** python.py	2013-08-20 22:00:06.099788209 +0200
--- python2.py	2013-08-20 22:00:26.848528814 +0200
***************
*** 1 ****
! #! /usr/bin/python
--- 1 ----
! #! /usr/bin/env python2

touhy.install :

post_install() {
  echo "touhy DOES NOT provide a window manager !
  You should add one in ~/.config/touhydev/system/sessions.infos
  Here is an example :
  #~ Commands launched on login
  [start]
  env=touhy-full
  wm=yourwm
  0=nm-applet &
  1=play /usr/share/sounds/purple/login.wav
  2=pidgin &

  #~ Commands launched on logout
  [stop]
  0=play /usr/share/sounds/purple/logout.wav

  #~ Warn if any of the following processes are active
  [pwatch]
  0=pidgin::#theme:pidgin

  You might want to install applications provided with touhy
  by the same author : elzaudm, elzdraw, elzedit, elzfold, elzlist,
  elznote, elzplay, elzread, elzshow, elzterm, elzview, elzword"
}

~/.config/touhydev/system/sessions.infos

[start]
env=touhy-full
wm=xfwm4
0=nm-applet &
1=play /usr/share/sounds/purple/login.wav
2=pidgin &

[stop]
0=play /usr/share/sounds/purple/logout.wav

[pwatch]
0=pidgin::#theme:pidgin

Résultat :

Pas pu sortir (pas trouvé de quoi quitter graphiquement) autrement qu'en lançant xfce4-terminal et en tuant touhy-session.

$ elzquit
Traceback (most recent call last):
  File "/usr/bin/elzquit", line 14, in <module>
Traceback (most recent call last):
  File "/usr/bin/elzquit", line 14, in <module>
    "/org/freedesktop/ConsoleKit/Manager"),"org.freedesktop.ConsoleKit.Manager")
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 241, in get_object
    "/org/freedesktop/ConsoleKit/Manager"),"org.freedesktop.ConsoleKit.Manager")
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 241, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 248, in __init__
  File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 248, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 180, in activate_name_owner
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 180, in activate_name_owner
    self.start_service_by_name(bus_name)
    self.start_service_by_name(bus_name)
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 278, in start_service_by_name
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 278, in start_service_by_name
    'su', (bus_name, flags)))
    'su', (bus_name, flags)))
  File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
  File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
    message, timeout)
dbus.exceptions.DBusExceptiondbus.exceptions.DBusException: : org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files

Eh oui, sous Arch, systemd a remplacé ConsoleKit...

J'ai aussi pas pu lancer touhy avant d'installer python2-numpy, et il ne semble pas être indiqué dans resources/require :

touhy-full                    
ImportError: numpy.core.multiarray failed to import
[1]    26031 segmentation fault (core dumped)  touhy-full

edit:
combo xfce4-touhy !

Dernière modification par The Uploader (Le 20/08/2013, à 21:30)

Elzen · Le 20/08/2013, à 21:29

Cool

/usr/bin/python2 existe chez moi aussi, donc j'dois pouvoir faire un sed sur les fichiers pour mettre ça upstream, si tu veux.

Pour numpy, je suis à peu près certain de ne pas l'utiliser directement (en fait, je ne sais même pas ce que c'est ^^") (j'viens de faire un grep sur l'ensemble du projet par acquis de conscience, aucune occurrence, à première vue). J'me demande s'il ne s'agirait pas d'une dépendance secondaire, un truc requis par l'une des bibliothèques que j'utilise, et qui n'aurait pas été correctement géré du côté de tes dépôts, mais c'est bizarre.

Pour le fichier de session, je serais d'avis de ne pas ajouter le fichier dans la conf. Je l'ai fais à titre d'exemple, mais la quasi-totalité des lignes qu'il contient dépendent de Pidgin, or il n'y a aucune assurance que les utilisateurs de Touhy utilisent Pidgin ^^
Si tu peux juste filer ça à titre d'exemple, mais en laissant la conf' de base, ce sera mieux, je pense.

Et pour ConsoleKit, j'peux rajouter un try/except pour simplement désactiver les boutons concernés si ça n'est pas présent, mais comme c'est ça qui gère l'extinction et le redémarrage, l'appli aura moins d'intérêt sans. Et je n'ai pas la moindre idée de comment je pourrais faire sans.

The Uploader · Le 20/08/2013, à 21:57

Elzen a écrit :

Cool
/usr/bin/python2 existe chez moi aussi, donc j'dois pouvoir faire un sed sur les fichiers pour mettre ça upstream, si tu veux.
Pour numpy, je suis à peu près certain de ne pas l'utiliser directement (en fait, je ne sais même pas ce que c'est ^^") (j'viens de faire un grep sur l'ensemble du projet par acquis de conscience, aucune occurrence, à première vue). J'me demande s'il ne s'agirait pas d'une dépendance secondaire, un truc requis par l'une des bibliothèques que j'utilise, et qui n'aurait pas été correctement géré du côté de tes dépôts, mais c'est bizarre.

C'est dans une des bibliothèques utilisées par touhy-full, mais c'est vrai que tu ne l'utilise pas directement. Du coup, le mettre en tant que dépendance dans touhy n'est pas la meilleure des solutions, mais c'est la seule à ma portée. Bon, à moins de voir à quel paquet python2-numpy manque dans les dépendances (pas sûr que namcap soit capable de faire ça, et j'ai pas trop envie de le faire "à la main") et de contacter le mainteneur Archlinux du paquet coupable.

Elzen a écrit :

Pour le fichier de session, je serais d'avis de ne pas ajouter le fichier dans la conf. Je l'ai fais à titre d'exemple, mais la quasi-totalité des lignes qu'il contient dépendent de Pidgin, or il n'y a aucune assurance que les utilisateurs de Touhy utilisent Pidgin ^^
Si tu peux juste filer ça à titre d'exemple, mais en laissant la conf' de base, ce sera mieux, je pense.

Il est justemen affiché à titre d'exemple par touhy.install. Le fichier ~/.config/touhydev/applications/sessions.infos, je l'ai créé manuellement pour moi, c'tout (comme par hasard j'utilise xfwm4, pidgin, et nm-applet aussi ).

Elzen a écrit :

Et pour ConsoleKit, j'peux rajouter un try/except pour simplement désactiver les boutons concernés si ça n'est pas présent, mais comme c'est ça qui gère l'extinction et le redémarrage, l'appli aura moins d'intérêt sans. Et je n'ai pas la moindre idée de comment je pourrais faire sans.

ConsoleKit est remplacé par systemd-logind, tu peux utiliser systemd-loginctl pour contrôler la session (y'a ça aussi : http://www.freedesktop.org/software/sys … rvice.html )
La doc python tient sur une feuille de PQ : http://www.freedesktop.org/software/sys … index.html .
Quant au binding python-systemd : http://packages.debian.org/experimental/python-systemd c'est expérimental...

Dernière modification par The Uploader (Le 20/08/2013, à 22:02)

Elzen · Le 20/08/2013, à 22:11

The Uploader a écrit :

C'est dans une des bibliothèques utilisées par touhy-full, mais c'est vrai que tu ne l'utilise pas directement. Du coup, le mettre en tant que dépendance dans touhy n'est pas la meilleure des solutions, mais c'est la seule à ma portée. Bon, à moins de voir à quel paquet python2-numpy manque dans les dépendances (pas sûr que namcap soit capable de faire ça, et j'ai pas trop envie de le faire "à la main") et de contacter le mainteneur Archlinux du paquet coupable.

Si j'essaye de le virer, apt-get me dit qu'il doit aussi dégager python-gtk2, carrément. Et bien sûr, plein d'autres trucs qui en dépendent.

The Uploader a écrit :

Il est justemen affiché à titre d'exemple par touhy.install. Le fichier ~/.config/touhydev/applications/sessions.infos, je l'ai créé manuellement pour moi, c'tout (comme par hasard j'utilise xfwm4, pidgin, et nm-applet aussi ).

'kay. Comme tu as mis une balise code exprès pour lui, j'pensais que tu le rajoutais. T'as le droit de choisir des sons plus cools que ceux-là, ceci dit

The Uploader a écrit :

ConsoleKit est remplacé par systemd-logind, tu peux utiliser systemd-loginctl pour contrôler la session (y'a ça aussi : http://www.freedesktop.org/software/sys … rvice.html )
La doc python tient sur une feuille de PQ : http://www.freedesktop.org/software/sys … index.html .

N'ayant pas systemd chez moi, j'préfère éviter de coder ça « à l'aveugle ». Si quelqu'un veut se charger d'ajouter l'option qu'il faut, ce sera sûrement mieux.

Bon, je mange, et je te patche ce que j'avais dit (python2 dans l'entête et simple désactivation des boutons au lieu de gros plantage). Ça ne devrait pas prendre longtemps, donc j'édite quand c'est envoyé, sauf si quelqu'un a reposté entre temps.

Edit : ç'bon, au fait. J'en ai profité pour corriger aussi quelques p'tits bugs au niveau de la bibli des applis.
Re-Edit : l'une desdites rectifs avait introduit un bug qui rendait ElzTerm inutilisable >< C'est réparé.

Dernière modification par Elzen (Le 21/08/2013, à 01:43)

The Uploader · Le 21/08/2013, à 13:06

Et voilà

J'ai plus qu'à faire la douzaine d'applications.

Elzen a écrit :

/usr/bin/python2 existe chez moi aussi, donc j'dois pouvoir faire un sed sur les fichiers pour mettre ça upstream, si tu veux.

Bon y'a encore un patch pour utiliser [core-utils] env, je sais je suis lourd.

Dernière modification par The Uploader (Le 21/08/2013, à 13:11)

Elzen · Le 21/08/2013, à 13:31

Chouette

Le patch, c'est-à-dire ?

The Uploader · Le 21/08/2013, à 13:37

$ cat use-env.patch 
*** python2.py	2013-08-21 13:15:39.349742724 +0200
--- python2-env.py	2013-08-21 13:16:05.246418971 +0200
***************
*** 1 ****
! #! /usr/bin/python2
--- 1 ----
! #! /usr/bin/env python2

$ tail -n 30 PKGBUILD

package() {
  cd ${srcdir}/${_gitname}
  
  mkdir -p ${pkgdir}/usr/bin
  mkdir -p ${pkgdir}/usr/lib/python2.7/site-packages
  mkdir -p ${pkgdir}/usr/share/${_gitname}
  
  cp -r resources/* ${pkgdir}/usr/share/${_gitname}
  cp -r touhy ${pkgdir}/usr/lib/python2.7/site-packages
  
  rm .gitignore
  rm -rf touhy
  rm -rf resources
  for _file in `ls`
  do
    install ${_file} ${pkgdir}/usr/bin
    patch -i ${srcdir}/use-env.patch ${pkgdir}/usr/bin/${_file}
  done

  install -Dm 644 ${pkgdir}/usr/share/${_gitname}/appinfos/touhy.desktop \
    ${pkgdir}/usr/share/xsessions/touhy.desktop

  # remove applications, they have or will have their own PKGBUILD
  cd ${pkgdir}/usr/bin
  for _file in `ls elz* | grep -v "^elzquit"`
  do
    rm ${_file}
  done
}

Rolinh · Le 21/08/2013, à 13:51

% namcap touhy-git-50.499d664-2-any.pkg.tar.xz
touhy-git W: Dependency included and not needed ('udisks2')
touhy-git W: Dependency included and not needed ('pygtk')
touhy-git W: Dependency included and not needed ('python2-wnck')
touhy-git W: Dependency included and not needed ('python2-notify')
touhy-git W: Dependency included and not needed ('python2-dbus')
touhy-git W: Dependency included and not needed ('python2-numpy')

Et pourquoi tu rm les ressources etc.?

The Uploader · Le 21/08/2013, à 14:02

Je préfère me fier au fichier require écrit par Elzen qu'à namcap, qui dit souvent des trucs à côté de la plaque.

Par exemple pour xfce4-volumed-pulse il me dit que pulseaudio n'est pas requis. Alors que xfce4-volumed-pulse quitte si pulseaudio n'est pas démarré.
Pour mes paquets des pilotes nvidia, il dit que nvidia-xxxx-utils n'est pas requis, alors que :

make sure nvidia depends on nvidia-utils (unless there's a good reason not to do so)

https://wiki.archlinux.org/index.php/Ke … Guidelines

Bref, faut vraiment faire gaffe avec namcap.

Quant aux rm, je vire tout ce qui ne va pas dans /usr/bin.
J'aurais pu faire un

ls -l | grep -v "^d" | awk {'print $9'}

remarque.

Dernière modification par The Uploader (Le 21/08/2013, à 14:38)

grim7reaper · Le 23/08/2013, à 01:02

On ne peut pas compiler un programme qui utilise SDL2 en C89 (il faut obligatoire passer par C99, à cause du mot-clef inline il semblerait).
Je suis tristesse

Édit : oui, c’est bien ça

/usr/include/SDL2/SDL_stdinc.h:258:1: error: unknown type name 'inline'
SDL_FORCE_INLINE void SDL_memset4(void *dst, int val, size_t dwords)
^
/usr/include/SDL2/begin_code.h:135:64: note: expanded from macro 'SDL_FORCE_INLINE'
#define SDL_FORCE_INLINE __attribute__((always_inline)) static inline

Dernière modification par grim7reaper (Le 23/08/2013, à 01:07)

The Uploader · Le 23/08/2013, à 07:24

T'es obligé d'utiliser C89 ?

grim7reaper · Le 23/08/2013, à 09:05

Non, mais j’ai l‘habitude d’écrire du C89 (portabilité maximale), et puis je voulais râler un peu

Le C99 apporte des trucs pas mal, je ne dis pas (genre restrict, inline, bool, __func__, …).
Mais ça apporte aussi son lot de truc inutiles (les commentaires //) , voire pire : franchement foireux (oui, je pense aux VLA (pas pour rien qu‘ils sont passés en optionnel pour le C11)). Et ça n’est probablement pas étranger au fait que son support soit peu répandu, même 14 ans après sa sortie.

Le compilo‘ de Microsoft ne le supporte pas, et ne le supportera jamais à priori (bien que récemment ils ont annoncés avoir implémentés des bouts qui les arrangeaient, mais toujours pas de vrai support du C99 prévu) :

https://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx?Redirected=true a écrit :

Additionally, some C99 Core Language features will be implemented in 2013 RTM:
* C99 _Bool
* C99 compound literals
* C99 designated initializers
* C99 variable declarations

En embarqué, je compterais pas trop dessus non plus…

GCC a un très bon support (mais il y a encore des 1 truc en broken et 6 missing).

clang ne supporte pas tout non plus.

http://clang.llvm.org/docs/UsersManual.html#c a écrit :

The support for standard C in clang is feature-complete except for the C99 floating-point pragmas.

Au final, seul une poignée de compilo‘ proprio‘ ont un support 100% complet du C99.
Donc j’ai pris l’habitude de rester en C89 (même si certains trucs sont sympa en C99, et que les trucs de bases sont quand même bien supporté (surtout si on se cantonne à GCC et clang).

Mais bon, je ne vais pas me priver de la SDL 2 pour si peu. Peut-être même que je vais m‘habituer au C99 après

Rolinh · Le 24/08/2013, à 13:12

@grim C'est vrai que c'est sympa le -Wdocumentation de Clang. Ceci dit, Doxygen peut générer ces warnings si on lui demande.
Sinon, c'est bien check au final? Histoire que je vois si ça vaut la peine que je l'utilise ou bien si je reste sur sput qui m'avait l'air vraiment pas mal et simple (oui, je n'ai toujours pas écrit les tests unitaires pour libgwavi...).

Dernière modification par Rolinh (Le 24/08/2013, à 13:13)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1726 Le 17/08/2013, à 19:58

Re : /* Topic des codeurs [8] */

#1727 Le 17/08/2013, à 20:08

Re : /* Topic des codeurs [8] */

#1728 Le 19/08/2013, à 12:23

Re : /* Topic des codeurs [8] */

#1729 Le 19/08/2013, à 12:42

Re : /* Topic des codeurs [8] */

#1730 Le 19/08/2013, à 13:25

Re : /* Topic des codeurs [8] */

#1731 Le 19/08/2013, à 13:33

Re : /* Topic des codeurs [8] */

#1732 Le 19/08/2013, à 13:51

Re : /* Topic des codeurs [8] */

#1733 Le 19/08/2013, à 15:10

Re : /* Topic des codeurs [8] */

#1734 Le 19/08/2013, à 15:55

Re : /* Topic des codeurs [8] */

#1735 Le 19/08/2013, à 16:01

Re : /* Topic des codeurs [8] */

#1736 Le 19/08/2013, à 16:15

Re : /* Topic des codeurs [8] */

#1737 Le 20/08/2013, à 18:04

Re : /* Topic des codeurs [8] */

#1738 Le 20/08/2013, à 21:06

Re : /* Topic des codeurs [8] */

#1739 Le 20/08/2013, à 21:29

Re : /* Topic des codeurs [8] */

#1740 Le 20/08/2013, à 21:57

Re : /* Topic des codeurs [8] */

#1741 Le 20/08/2013, à 22:11

Re : /* Topic des codeurs [8] */

#1742 Le 21/08/2013, à 13:06

Re : /* Topic des codeurs [8] */

#1743 Le 21/08/2013, à 13:31

Re : /* Topic des codeurs [8] */

#1744 Le 21/08/2013, à 13:37

Re : /* Topic des codeurs [8] */

#1745 Le 21/08/2013, à 13:51

Re : /* Topic des codeurs [8] */

#1746 Le 21/08/2013, à 14:02

Re : /* Topic des codeurs [8] */

#1747 Le 23/08/2013, à 01:02

Re : /* Topic des codeurs [8] */

#1748 Le 23/08/2013, à 07:24

Re : /* Topic des codeurs [8] */

#1749 Le 23/08/2013, à 09:05

Re : /* Topic des codeurs [8] */

#1750 Le 24/08/2013, à 13:12

Re : /* Topic des codeurs [8] */

Pied de page des forums