J'avais aussi fait quelques essais qui ne m'avaient pas convaicu du tout. En cherchant un peu, je suis tombé sur la librairie vdk, qui offre une interface C++ à Gtk
Un builder a aussi été développé, vdkbuilder.
La librairie et le builder existent pout GTK1 et 2
En fait, j'ai le problème lors de l'installation. Il m'explique gentiment que le répertoire où j'essaie d'installer mes librairies ne ressemble pas du tout à un répertoire pouvant contenir des librairies. (C'est moi qui libtoolize avec la version 1.4.2a)
J'en fais pas une maladie, car c'est un programme perso, je laisse le source, et je désinstalle avec make uninstall
> Si tu commences à faire des ./configure && make && make install, je ne penses pas que le gestionnaire de paquet aime longtemps.
Juste pour dire que par défaut, ce genre de commande ne vient pas mettre le bordel dans /usr/bin et consort, mais dans /usr/local. Stow peut alors venir aider. Quoique depuis un certain temps, libtool n'aime pas du tout les make install prefix=/usr/local/stow/...
t'es candidat ? parce que justement, l'administration Bush projette de lancer un programme de surveillance des citoyens par les citoyens. GW voudrait recruter au moins 4% de la population lambda américaine. Celle bossant à des postes clefs (postiers, dépanneurs, livreurs...).
Ce projet porte le doux nom de TIPS.
Si tu veux te débarasser de ton voisin encombrant, c'est le moment...
> Bref AZF, curieusement on ne sait toujours pas si c'est un accident.
Arretons d'entretenir des rumeurs débiles.
Quand j'entends des raisonnements du style, "olala, vu la force de l'explosion, c'était un attentat!", ça me fais bondir.
En plus, moi, si j'avais voulu perpétrer un attentat sur l'AZF, je me serais plutôt concentré sur les gaz mortels qui s'y trouvaient. Plus rien ne milite en faveur de l'attentat. Rien n'a d'ailleur jamais milité en faveur d'un attentant, excepté une parano post 11 septembre
Je ne vois pas ou est le problème sur les timers.
tu crée tes flots via la méthode adhoc et tu utilise un "sleep"ou un "nanosleep" avec un temps adapté.
Ca marche parfaitement. Mais j'ai sans doute du manquer quelque chose.
Maintenant, au niveau des signaux, je n'ai jamais fais de mutithreading poussé sous linux, mais il FAUT de toute façon un flot intercepteur qui agit en conséquence.
Exact. Quelques fois, la configuration d'un composant peut être assez ardue. Un "clickodrome" peut alors être d'une aide précieuse. Mais dès que l'on commence à maitriser la conf du composant, je trouve que l'efficacité passe par la ligne de commande. Un pt'it coup de vim est quand même plus rapide qu'une avalanche de clicks.
effectivement, ça merdouille un peu. vgscan part en boucle. Je m'en était aperçu un jour et sans chercher à comprendre, je l'ai viré de la crontab. Bon, il y a eu une amélioration : il n'y a plus d'assertion noyau.
Je n'ai, à ce jour jamais perdu de données malgré des mises à jour particulièrement sportives. Nouvelle version (beta) de lvm qui refuse obstinément de reconnaitre le volume logique ...
Je commence à utiliser des cartes X.25.
Je me suis orienté d'abord vers les cartes Sangoma, qui ont l'air bien supporté. Le seul revendeur (à ma connaissance) en france est une boite parisienne du nom de Ercom
J'ai du, pour des problèmes de marché, changer mon fusil d'épaule.
Je me suis orienté vers les cartes X.25 AT-FUT-D de Thalès [1] (Ex Dassault AT). J'ai pas encore eu le temps de voir en détail.
C'est basé sur les Streams SYSV. Ils utilisent l'implémentation linux LiS [2]. Le driver est prévu pour le 2.2.14 et ne fonctionne pas sur machine multipro, mais je crois qu'ils en on développé un nouveau. On n'a pas les sources du driver, et pas les sources de la lib XTI/TLI qui est fournie avec la carte.
Sinon, Dassault a visiblement un forte expérience Unix, contrairement à Eicon qui parait-il fournirait des drivers linux pour ses cartes X.25
La carte embarque un OS et du code qui gère le protocole X.25 jusqu'au niveau 3, je crois.
La configuration se fait à travers une interface texte à la ncurses.
> - un ouvrage sur lex & yac
Depuis le thread sur lex et yacc, et les conseils de certains d'aller voir ailleurs, j'ai découvert pccts.
J'ai mis lex et yacc à la poubelle, depuis.
Je ne pense pas qu'il faille utiliser les threads pour simplifier la vie des programmeurs. D'ailleurs, ce n'est souvent qu'une façade. Debugger un programme multithread est un horreur. La maintenance n'est pas forcément aisée, et la validation de tels programmes est assez problématique.
Utilisons les threads pour améliorer les performances.
Le partage de donnée entre threads coûte cher en terme de synchronisation (prise de verrou, switch du contexte ...) et cela, contrairement à ce qui a été dit plus haut stresse pas mal la mémoire.
La gestion des E/S bloquantes via des threads, est je pense, quand on commence à avoir un nombre conséquent de socket, une hérésie. J'imagine d'ailleurs que apache ne fait pas ce genre de chose.
Sur linux les threads utilisent le modèle 1x1 ( http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#K(...) ) et béneficient de la répartition de charge sur plusieurs µpro. Je crois d'ailleurs qu'il n'y a aucun moyen sur linux d'attacher un thread à un µpro ce qui peut être problématique.
En plus, dans le cadre d'une utilisation en C++, on a eu de gros soucis avec les exceptions.
[^] # Re: Bof. bof ...
Posté par Stephane Pion . En réponse à la dépêche Deux nouveaux Mozilla. Évalué à 4.
L'historique fonctionne bien chez moi.
[^] # Re: Question de debutant.
Posté par Stephane Pion . En réponse à la dépêche Développer des applications GNOME avec Anjuta. Évalué à 10.
Un builder a aussi été développé, vdkbuilder.
La librairie et le builder existent pout GTK1 et 2
Bon, la version 2 est un peu beta, et c'est un peu sportif, des fois, mais ça me suffit amplement.
http://sourceforge.net/projects/vdkbuilder/(...)
Pour les debianistes,
apt-get install vdkbuilder/vdkbuilder2
[^] # Re: bof bof...
Posté par Stephane Pion . En réponse à la dépêche APT vs. RPM: Aucun des deux. Évalué à 9.
J'en fais pas une maladie, car c'est un programme perso, je laisse le source, et je désinstalle avec make uninstall
Stéphane
[^] # Re: bof bof...
Posté par Stephane Pion . En réponse à la dépêche APT vs. RPM: Aucun des deux. Évalué à 10.
Juste pour dire que par défaut, ce genre de commande ne vient pas mettre le bordel dans /usr/bin et consort, mais dans /usr/local. Stow peut alors venir aider. Quoique depuis un certain temps, libtool n'aime pas du tout les make install prefix=/usr/local/stow/...
Stéphane
[^] # Re: Re:Oui parobablement
Posté par Stephane Pion . En réponse à la dépêche Fin des prix « éducation » pour MS. Évalué à 1.
http://www.aclu.org/action/tips107.html(...)
[^] # Re: Re:Oui parobablement
Posté par Stephane Pion . En réponse à la dépêche Fin des prix « éducation » pour MS. Évalué à 5.
Ce projet porte le doux nom de TIPS.
Si tu veux te débarasser de ton voisin encombrant, c'est le moment...
-1 pque off topic
[^] # Re: les pissenlits par la racine ;)
Posté par Stephane Pion . En réponse à la dépêche Article sur les positions des partis politiques sur les brevets logiciels. Évalué à 3.
Arretons d'entretenir des rumeurs débiles.
Quand j'entends des raisonnements du style, "olala, vu la force de l'explosion, c'était un attentat!", ça me fais bondir.
En plus, moi, si j'avais voulu perpétrer un attentat sur l'AZF, je me serais plutôt concentré sur les gaz mortels qui s'y trouvaient. Plus rien ne milite en faveur de l'attentat. Rien n'a d'ailleur jamais milité en faveur d'un attentant, excepté une parano post 11 septembre
http://toulouse.azf.free.fr/articles/0915.html(...)
Que ce soit un attentat, ça arrange surtout Total.
Il reste que l'usine était dans un état de décrépitude avancé (dixit les sous-traitants).
[^] # Re: linuuuuuuuuuuuuux
Posté par Stephane Pion . En réponse à la dépêche Quel OS pour le multiprocesseur ?. Évalué à 1.
tu crée tes flots via la méthode adhoc et tu utilise un "sleep"ou un "nanosleep" avec un temps adapté.
Ca marche parfaitement. Mais j'ai sans doute du manquer quelque chose.
Maintenant, au niveau des signaux, je n'ai jamais fais de mutithreading poussé sous linux, mais il FAUT de toute façon un flot intercepteur qui agit en conséquence.
Stéphane
[^] # Re: GUI + fichiers texte
Posté par Stephane Pion . En réponse à la dépêche Clickodrome vs. ligne de commande. Évalué à 10.
Stéphane
[^] # Re: Ext 3
Posté par Stephane Pion . En réponse à la dépêche Red Hat 7.2 dispo. Évalué à 1.
Je n'ai, à ce jour jamais perdu de données malgré des mises à jour particulièrement sportives. Nouvelle version (beta) de lvm qui refuse obstinément de reconnaitre le volume logique ...
Stéphane
[^] # Re: Ext 3
Posté par Stephane Pion . En réponse à la dépêche Red Hat 7.2 dispo. Évalué à 6.
...
/dev/vg01/lv01 on /spare type ext3 (rw)
...
ça marche très bien lvm et ext3. Je n'utilise que le chainage de partitions, noyau 2.4.10 et patch ext3 adéquat.
Stéphane
[^] # Re: question x25
Posté par Stephane Pion . En réponse à la dépêche Haute disponibilité sous les systèmes à base de Linux. Évalué à 7.
Je me suis orienté d'abord vers les cartes Sangoma, qui ont l'air bien supporté. Le seul revendeur (à ma connaissance) en france est une boite parisienne du nom de Ercom
J'ai du, pour des problèmes de marché, changer mon fusil d'épaule.
Je me suis orienté vers les cartes X.25 AT-FUT-D de Thalès [1] (Ex Dassault AT). J'ai pas encore eu le temps de voir en détail.
C'est basé sur les Streams SYSV. Ils utilisent l'implémentation linux LiS [2]. Le driver est prévu pour le 2.2.14 et ne fonctionne pas sur machine multipro, mais je crois qu'ils en on développé un nouveau. On n'a pas les sources du driver, et pas les sources de la lib XTI/TLI qui est fournie avec la carte.
Sinon, Dassault a visiblement un forte expérience Unix, contrairement à Eicon qui parait-il fournirait des drivers linux pour ses cartes X.25
La carte embarque un OS et du code qui gère le protocole X.25 jusqu'au niveau 3, je crois.
La configuration se fait à travers une interface texte à la ncurses.
Stéphane
[1]http://www.idatys.thomson-csf.com/telecoms/c_file.htm(...)
[2]http://www.gcom.com/(...)
[^] # Re: C'était donc en 1991 !
Posté par Stephane Pion . En réponse à la dépêche Linux, 10 ans déjà. Évalué à 1.
[^] # Re: petite requête
Posté par Stephane Pion . En réponse à la dépêche Linkers and Loaders. Évalué à 1.
Depuis le thread sur lex et yacc, et les conseils de certains d'aller voir ailleurs, j'ai découvert pccts.
J'ai mis lex et yacc à la poubelle, depuis.
http://www.antlr.org(...)
ça génère, au choix, du C, du C++ ou du Java, et les possibilités de l'analyseur grammatical sont largement supérieures à celles de yacc.
[^] # Re: ATTENTION C'EST EN ANGLAIS !!!
Posté par Stephane Pion . En réponse à la dépêche lex & yacc. Évalué à 1.
ISBN 2-84177001-X
[^] # Re: threads/process
Posté par Stephane Pion . En réponse à la dépêche Caudium v/s Apache. Évalué à 1.
Utilisons les threads pour améliorer les performances.
Le partage de donnée entre threads coûte cher en terme de synchronisation (prise de verrou, switch du contexte ...) et cela, contrairement à ce qui a été dit plus haut stresse pas mal la mémoire.
La gestion des E/S bloquantes via des threads, est je pense, quand on commence à avoir un nombre conséquent de socket, une hérésie. J'imagine d'ailleurs que apache ne fait pas ce genre de chose.
Sur linux les threads utilisent le modèle 1x1 ( http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#K(...) ) et béneficient de la répartition de charge sur plusieurs µpro. Je crois d'ailleurs qu'il n'y a aucun moyen sur linux d'attacher un thread à un µpro ce qui peut être problématique.
En plus, dans le cadre d'une utilisation en C++, on a eu de gros soucis avec les exceptions.
Pis, les gourous unix, ben, ils aiment pas les threads. D'ailleurs, John Ousterhout a publié il y a quelques années un manifeste anti thread ( http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm(...) ).
Stéphane