Là, je ne vois pas trop ce que l'on peut faire pour le coup!
Ben nous rapporter les lignes qui précèdent et suivent immédiatement le message kernel panic.
Un kernel panic, ça peut être grave mais cela peut aussi ne pas l'être du tout : Par exemple, si tu as déplacé un disque ou une partition, au hasard, celle qui contient "/", le kernel ne peut plus monter le fichier racine ni, donc, aller plus loin. Cela suffit à provoquer un panic. C'est très impressionnant mais cela se règle en deux coups de cuillère à peau.
Autre problème possible, un pilote de périphérique à la noix. Dans ce cas, il faut essayer de l'isoler (les messages devraient t'aider), puis débrancher le périphérique concerné avant de démarrer. Aviser ensuite.
Et cela fait suer parce que cela oblige à mettre en place un gestionnaire spécial à l'écoute des signaux de la fenêtre. De plus, la fenêtre est déjà redimensionnée automatiquement par GTK, puis manuellement par mon code. Ça se voit et ça consomme des ressources, spécialement quand le serveur X est déporté sur un Thin Client.
Je vais essayer de faire autrement. Avec les attributs shrinkable ou autre, ce doit bien être possible.
Oui, et il devient beaucoup plus facile de proposer un Linux par la suite. Fini les *.xls, et autres *.ppt, place aux *.odf !
« - Moi je veux bien essayer autre chose, mais à condition que je puisse toujours lire mes CV en *.odt et mes présentations en *.odp. C'est possible ?
- Mais très certainement, ma petite dame ! :-) »
Une distribution Linux, c'est un peu comme un menu Best-Of chez MacDonalds. Les hamburgers que tu trouves dans ton sac sont les mêmes que ceux que tu auraient achetés à la pièce, mais préparés, regroupés et livrés sous une formule spéciale et pratique pour le consommateur.
Coté Linux, il faut déjà insister sur les classiques :Linux est un noyau (l'infrastructure minimum pour permettre de faire fonctionner des applications). Tout ce que va autour sont en fait la suite logicielle du projet GNU.
Le truc, c'est que ces logiciels se comptent par milliers. Il faut donc quelqu'un pour préparer un CD qui contiennent les plus intéressants, te permette d'aller télécharger les autres, et surtout te les installe tous automatiquement et en une fois. Il faut aussi au préalable préparer ton ordinateur à les recevoir et faire la configuration générale de chacun d'eux, post-installation.
Faire une telle « compilation » puisque c'est bien de cela qu'il s'agit, plus créer les outils qui permettent de mettre le tout en place demande des dizaines de personnes très compétentes et plusieurs années pour que le tout soit au point. Surtout qu'il ne s'agit pas seulement de réaliser le travail une fois, mais il faut aussi maintenir à jour les logiciels et s'assurer à chaque fois que leur nouvelle version n'entrera pas en conflit avec l'environnement existant (intégration).
En revanche, tous les logiciels étant à la base libres, n'importe qui peut s'atteler à cette tâche et tenter de la mener à bien. Tu peux même créer un système Linux sans CD d'install, à partir de rien, en téléchargement patiemment chaque utilitaire, et créant ta partition toi-même etc. Tu en as pour facilement deux ans mais c'est faisable, et parfois recommandé. Cela s'appelle formellement un Linux-From-Scratch (LFS) : http://www.linuxfromscratch.org/
Plusieurs groupes se sont donc déjà collés à ce lourd travail et proposent leur propre « distribution » des logiciels GNU et du noyau Linux. Les plus célèbres sont RedHat et Debian.
Les autres, à de rares exceptions près, s'appuient sur les premières (car les logiciels distribués restent libres) et en dérivent.
À toi donc d'en essayer plusieurs et de choisir au final celle qui te convient le mieux, en sachant que tu finiras toujours, à la fin, par récupérer le même logiciel.
Posté par Obsidian .
En réponse au message Plug in.
Évalué à 6.
Tout d'abord, bravo pour ta persévérance. Comme je sais que tu débutes sous Linux, je dirais que tu découvres là un système qui demande que l'on mette les mains dans le camboui, mais qui te garantira une stabilité exemplaire par la suite, et la possibilité de le dépanner sans avoir à tout réinstaller (voire même sans l'arrêter du tout).
Pour le plug-in, le mieux est d'aller le chercher directement sur le site de Macromédia :
Clique sur le bouton Download et tu devrais arriver automatiquement sur la page de téléchargement en français du module concerné, pour Linux. Les instructions sont sur cette page.
Il te faudra probablement lancer l'installeur en root (cause probable de ton problème). Mais sinon, dans tous les cas, il s'agit simplement d'une bibliothèque *.so (l'équivalent Unix d'une DLL) et éventuellement d'un fichier *.xpt pour Mozilla/Firefox. Ces deux fichiers doivent simplement se trouver dans le répertoire /usr/lib/mozilla-firefox/plugins (ou au moins, il doit y avoir dans ce répertoire des liens symboliques vers l'emplacement exacts des fichiers concernés).
Tu refermes et tu rouvres Firefox et tout devrait rentrer dans l'ordre.
En ce qui me concerne, j'utilise GLADE dans un premier temps pour me générer des exemples de code en fonction de ce que j'ai envie de produire, puis j'écris mes fonctions moi-même pour n'en garder que la substantifique moelle.
Ensuite, le mieux c'est le site de GTK lui-même. On y trouve des tutoriaux et toute l'API GTK proprement documentée (en langage C).
Ces trois derniers liens sur sont valables pour GTK 2 mais tu trouveras sur la page d'accueil (premier lien) tout ce qu'il faut pour GTK 1.2 aussi. Elle est pas belle, la vie ? :-)
D'une manière générale, il est difficile de pas troller lorsque l'on évoque feu Edsger Dijkstra.
Je sais que tu postes cela pour mon bien mais je fais partie des gens qui n'adhèrent pas automatiquement à ses idées (et je ne suis pas le seul si l'on en croit cette célèbre citation extraite de kernel/sched.c : http://www.coda.cs.cmu.edu/doc/talks/linuxvfs/tsld031.htm ). La discussion était d'ailleurs déjà très animée il y a trois ans :
Je reproche majoritairement deux choses aux disciples de Dijkstra :
1) Tuer dans l'oeuf tout risque de discussion en assénant des vérités toutes faites du style : « It is practically impossible to teach good programming to students that have had a prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration. ». Dijkstra devrait être au quotidien un type pas du tout facile à vivre et ne devait pas aimer que l'on remette en cause ses théories :-)
Aujourd'hui, les gens qui le suivent considèrent les gens qui soutiennent toute théorie « déviante » comme étant nécessairement sots, ou au mieux dans l'ignorance. Cela me rappelle un peu Dan, le scientifique illogique :-)
Quand on en arrive à de telles extrémités, c'est en général par manque de pertinence de l'argumentation.
2) Raisonner de manière essentiellement mathématique. J'entends par là : tenter d'appliquer le modèle de raisonnement et l'analyse des problèmes traditionnels à l'informatique. Il faut bien se rendre compte qu'algorithmie et programmation sont deux domaines sensiblement différents et que ce n'est pas parce Dijkstra a brillament résolu le problème du colporteur que la manière dont il va l'implémenter va être propre.
bien souvent l'essentiel des bugs sont sur des effet de bord dans des conditions mal traitée ou pas traitées du tout. dans la liste on trouve :
- mauvaise gestion du malloc()/free()
- mauvaise gestion des IPC
- explosion d'etat interdependant car le code ne permet de faire autrement dans le delai imparti ( car sinon faut tout recoder )
... et Dieu tue un chaton aussi. Ces exemples sont les problèmes classiques récurrents de la programmation système. On les attribue à toutes les causes possibles et imaginables quand on a envie de se faire le détracteur d'une méthode particulière.
On ne doit pas imbriquer nos if() de la même manière car moi, au contraire, je tiens cette méthode pour être la plus élégante façon de résoudre ces problèmes, spécialement ceux des malloc(). C'est même la seule chose qui me réconcilie un peu avec Dijkstra. La sacro-sainte programmation structurée ne trouve sa réelle signification que sous cette forme. Tout ce qui est conditionné par un if() doit se trouver à l'intérieur.
Il y a belle lurette que grâce à cela, je n'utilise plus exit() et qu'il n'y a qu'un seul return, toujours à la fin de mes fonctions.
si on regarde bien, il n'y a là dedans que des erreurs de conceptions ou d'implementation. ce qui m'amene a une regle que j'enonce ainsi :
- tout programme ou bout de programme dont la couverture en condition est superieur à 5 tends necessairement à être buggé
Moi, j'en assène une autre, attribuée à Euclide de Mégare et qui orne le portail mathématique du Wikipédia français :
« Ce qui est affirmé sans preuve peut être nié sans preuve »
Quant à la lisibilité, l'important est de garder de la cohérence tout au long de son propre code. Le reste n'est qu'affaire de subjectivité. Il y a de fortes chances pour qu'un code lisible selon tes critères soit parfaitement obscur pour quelqu'un d'autre. Moi, je pense que lorsque l'on est trop à cheval sur la forme, c'est que l'on ne l'est pas assez sur le fond.
si tu as un doute, reprends le propos de dijkstra sur les goto
Ben voyons, je parle de if() imbriqués et tu me parles de gotos ? Comme je le dis au dessus, il me semble que l'inclusion des différentes routines est justement le meilleur moyen de s'en débarrasser. Sémantiquement parlant, un analyseur de code (autre grand sujet de troll et d'étude en algorithmie) sera immédiatement capable de reconnaitre si un bloc d'instruction est dépendant d'un if() ou pas. Si on les remet à plat, on perd cette possibilité.
Aujourd'hui, il faut necessairement comprendre le propos de Dijkstra comme les conditions prealable au goto sont a eviter.
Oui, mais ce n'est pas suffisant. Il faut également le saisir de la manière dont il a voulu l'exprimer. Jamais un troll en informatique n'aura été si proche d'une guerre de religion. Dijkstra était déjà un fondamentaliste, mais la plupart des intégristes interprètent aujourd'hui ses propos selon le sens qui leur plaît et partent en croisade contre tous les autres.
Dijkstra a produit beaucoup de bon matériel, mais il faudrait voir à ne pas prendre tout ce qu'il a dit comme paroles d'évangile.
Tout ceci étant dit, je te remercie quand même d'avoir pris le temps de te pencher sur mon problème (d'une part) et tenter de m'éclairer (d'autre part).
À l'édition de liens, tu génères deux exécutables :
Eh oui ! Tout le problème vient de là.
Je ne veux pas générer deux fichiers exécutables distincts, et par conséquent, je ne veux pas utiliser non plus de fonctions du style execv() ou autre ...
D'un point de vue purement algorithmique, c'est tout-à-fait faisable. D'ailleurs mon application inclue deux modules : tty et gtk. Respectivement pour avoir une version texte ou graphique de l'interface, laquelle est dans le schéma général complètement détachée du moteur du jeu ou des autres modules. Il est tout-à-fait possible de forker au bon endroit avec le premier module, pour la simple raison que c'est moi qui ai le contrôle de la boucle principale. Il n'est malheureusement pas possible d'en sortir temporairement sous GTK. De plus, ce dernier module sous-tend une connexion au serveur X et la X-Lib n'aime pas du tout le multi-thread. On ne peut même pas refermer le socket inutilisé dans le processus fils, au risque de refermer complètement la connexion à X.
On retombe toujours sur le même problème : Soit on implique directement deux threads dès le lancement de l'application, soit il faut générer - et installer - deux exécutables et faire invoquer l'un par l'autre avec un exec().
Je pense que je vais confier le soin de forker à la fonction d'initialisation du module GTK, le considérer comme une nécessité de cette lib et éviter de compromettre le reste de l'appli pour cela.
Deux processus distincts, un pour le client, un pour le serveur, oui.
Mais être obligé de créer deux processus pour la partie cliente simplement pour éviter d'hériter de GTK au moment où je forke, ça, ça m'ennuie.
D'une manière générale, le multithreading est très bien, mais c'est souvent un moyen de pallier une conception douteuse. C'est un peu comme mettre un exit(0) au milieu d'un programme, là où des if() imbriqués auraient parfaitement résolu le problème.
Merci pour ton aide, je vais tenter d'être plus clair :
L'idée est de permettre à l'utilisateur de lancer un dæmon sur commande, grace à un clic.
Plus précisément, je fais une application (un jeu) qui peut être à la fois serveuse ou cliente dans le sens où elle embarque tout le code nécessaire aux deux fonctions, parce que le tout reste très concis, et que c'est nettement moins contraignant pour l'utilisateur que d'avoir deux exécutables. Cependant, elle ne remplit jamais les deux rôles à la fois : elle est soit cliente, soit serveuse. Quant au serveur proprement dit, il doit naturellement se détacher de la console, aller se rattacher à init et évidement n'utilise aucune interface graphique.
Je pense également que le moyen le plus propre de s'en sortir est effectivement de placer la boucle GTK dans un processus propre et de faire tout le travail sérieux en dehors, mais cela me fait suer de lancer deux processus simplement pour gérer une interface graphique de base.
Je vais jeter un coup d'oeil du coté de cette lib.
Pour la sérialisation, tu as tout-à-fait raison, mais j'avais fait exprès de ne pas employer le terme, car un pro du langage Java m'avais expliqué que la sérialisation se contentait de mettre les données binaires d'un objet bout à bout pour les faire passer dans un canal quelquonque, et que l'externalisation avait en plus pour but de convertir les données de façon à pouvoir les exporter.
# Les logs ?
Posté par Obsidian . En réponse au message [kernel Panic] Ajout d'une carte wifi. Évalué à 3.
Ben nous rapporter les lignes qui précèdent et suivent immédiatement le message kernel panic.
Un kernel panic, ça peut être grave mais cela peut aussi ne pas l'être du tout : Par exemple, si tu as déplacé un disque ou une partition, au hasard, celle qui contient "/", le kernel ne peut plus monter le fichier racine ni, donc, aller plus loin. Cela suffit à provoquer un panic. C'est très impressionnant mais cela se règle en deux coups de cuillère à peau.
Autre problème possible, un pilote de périphérique à la noix. Dans ce cas, il faut essayer de l'isoler (les messages devraient t'aider), puis débrancher le périphérique concerné avant de démarrer. Aviser ensuite.
Bonne chance
[^] # Re: Les GtkPaned
Posté par Obsidian . En réponse au message GTK: Dimensions d'un objet d'un panneau redimensionnable.. Évalué à 2.
Je vais essayer de faire autrement. Avec les attributs shrinkable ou autre, ce doit bien être possible.
Merci quand même.
[^] # Re: Les GtkPaned
Posté par Obsidian . En réponse au message GTK: Dimensions d'un objet d'un panneau redimensionnable.. Évalué à 2.
[^] # Re: Attention quand meme
Posté par Obsidian . En réponse à la dépêche La Gendarmerie Nationale passe à Firefox et Thunderbird. Évalué à 5.
« - Moi je veux bien essayer autre chose, mais à condition que je puisse toujours lire mes CV en *.odt et mes présentations en *.odp. C'est possible ?
- Mais très certainement, ma petite dame ! :-) »
[^] # Re: Ma mienne
Posté par Obsidian . En réponse au sondage Ma résolution pour 2006. Évalué à 5.
... et tu tires la chasse juste avant, aussi. Non, mais :-)
Je n'avais pas osé la faire moi-même, celle-là. Sinon, quand on est bien élevé, on dit :
mv coredump /dev/null
[^] # Re: .
Posté par Obsidian . En réponse au journal Kadéo bounty. Évalué à 4.
[^] # Re: Ma mienne
Posté par Obsidian . En réponse au sondage Ma résolution pour 2006. Évalué à 6.
# Ma mienne
Posté par Obsidian . En réponse au sondage Ma résolution pour 2006. Évalué à 6.
En plus, j'ai eu des haltères et une balance pour Noël ! Si si :-)
# Qui vivra verra.
Posté par Obsidian . En réponse au journal [DADVSI] Reponse de Mme Boutin. Évalué à 3.
# Distribs et hamburgers
Posté par Obsidian . En réponse au message Hello les ami(e)s. Évalué à 2.
Coté Linux, il faut déjà insister sur les classiques :Linux est un noyau (l'infrastructure minimum pour permettre de faire fonctionner des applications). Tout ce que va autour sont en fait la suite logicielle du projet GNU.
Le truc, c'est que ces logiciels se comptent par milliers. Il faut donc quelqu'un pour préparer un CD qui contiennent les plus intéressants, te permette d'aller télécharger les autres, et surtout te les installe tous automatiquement et en une fois. Il faut aussi au préalable préparer ton ordinateur à les recevoir et faire la configuration générale de chacun d'eux, post-installation.
Faire une telle « compilation » puisque c'est bien de cela qu'il s'agit, plus créer les outils qui permettent de mettre le tout en place demande des dizaines de personnes très compétentes et plusieurs années pour que le tout soit au point. Surtout qu'il ne s'agit pas seulement de réaliser le travail une fois, mais il faut aussi maintenir à jour les logiciels et s'assurer à chaque fois que leur nouvelle version n'entrera pas en conflit avec l'environnement existant (intégration).
En revanche, tous les logiciels étant à la base libres, n'importe qui peut s'atteler à cette tâche et tenter de la mener à bien. Tu peux même créer un système Linux sans CD d'install, à partir de rien, en téléchargement patiemment chaque utilitaire, et créant ta partition toi-même etc. Tu en as pour facilement deux ans mais c'est faisable, et parfois recommandé. Cela s'appelle formellement un Linux-From-Scratch (LFS) : http://www.linuxfromscratch.org/
Plusieurs groupes se sont donc déjà collés à ce lourd travail et proposent leur propre « distribution » des logiciels GNU et du noyau Linux. Les plus célèbres sont RedHat et Debian.
Les autres, à de rares exceptions près, s'appuient sur les premières (car les logiciels distribués restent libres) et en dérivent.
À toi donc d'en essayer plusieurs et de choisir au final celle qui te convient le mieux, en sachant que tu finiras toujours, à la fin, par récupérer le même logiciel.
# var/spool et daemon.
Posté par Obsidian . En réponse au message Programmer un outil d'impression.... Évalué à 2.
http://www.google.fr/search?hl=fr&q=Unix+daemonize&b(...)
Sinon pour le reste, il y a le répertoire /var/spool qui permet de stocker temporairement les fichiers à envoyer en série vers la file d'impression.
[^] # Re: encore plus simple
Posté par Obsidian . En réponse au message Borne internet sur Linux : restreindre les applis, les sites, etc... Évalué à 2.
[^] # Re: encore plus simple
Posté par Obsidian . En réponse au message Borne internet sur Linux : restreindre les applis, les sites, etc... Évalué à 2.
A++
# Le plugin.
Posté par Obsidian . En réponse au message Plug in. Évalué à 6.
Pour le plug-in, le mieux est d'aller le chercher directement sur le site de Macromédia :
http://www.macromedia.com/software/flashplayer/
Clique sur le bouton Download et tu devrais arriver automatiquement sur la page de téléchargement en français du module concerné, pour Linux. Les instructions sont sur cette page.
Il te faudra probablement lancer l'installeur en root (cause probable de ton problème). Mais sinon, dans tous les cas, il s'agit simplement d'une bibliothèque *.so (l'équivalent Unix d'une DLL) et éventuellement d'un fichier *.xpt pour Mozilla/Firefox. Ces deux fichiers doivent simplement se trouver dans le répertoire /usr/lib/mozilla-firefox/plugins (ou au moins, il doit y avoir dans ce répertoire des liens symboliques vers l'emplacement exacts des fichiers concernés).
Tu refermes et tu rouvres Firefox et tout devrait rentrer dans l'ordre.
[^] # Re: Adresse virtuelle
Posté par Obsidian . En réponse au message recherche formation gtk+. Évalué à 2.
Ensuite, le mieux c'est le site de GTK lui-même. On y trouve des tutoriaux et toute l'API GTK proprement documentée (en langage C).
C'est par ici :
http://www.gtk.org/
http://www.gtk.org/faq/
http://www.gtk.org/tutorial/
http://www.gtk.org/api/
Ces trois derniers liens sur sont valables pour GTK 2 mais tu trouveras sur la page d'accueil (premier lien) tout ce qu'il faut pour GTK 1.2 aussi. Elle est pas belle, la vie ? :-)
[^] # Re: en tout cas quelque chose existe pour linux
Posté par Obsidian . En réponse au journal Et google earth pour Linux alors ????. Évalué à 3.
[^] # Re: pas clair ...
Posté par Obsidian . En réponse au message GTK : Forker depuis la boucle principale. Évalué à 2.
D'une manière générale, il est difficile de pas troller lorsque l'on évoque feu Edsger Dijkstra.
Je sais que tu postes cela pour mon bien mais je fais partie des gens qui n'adhèrent pas automatiquement à ses idées (et je ne suis pas le seul si l'on en croit cette célèbre citation extraite de kernel/sched.c : http://www.coda.cs.cmu.edu/doc/talks/linuxvfs/tsld031.htm ). La discussion était d'ailleurs déjà très animée il y a trois ans :
http://linuxfr.org/2002/08/09/9216.html
Je reproche majoritairement deux choses aux disciples de Dijkstra :
1) Tuer dans l'oeuf tout risque de discussion en assénant des vérités toutes faites du style : « It is practically impossible to teach good programming to students that have had a prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration. ». Dijkstra devrait être au quotidien un type pas du tout facile à vivre et ne devait pas aimer que l'on remette en cause ses théories :-)
Aujourd'hui, les gens qui le suivent considèrent les gens qui soutiennent toute théorie « déviante » comme étant nécessairement sots, ou au mieux dans l'ignorance. Cela me rappelle un peu Dan, le scientifique illogique :-)
Quand on en arrive à de telles extrémités, c'est en général par manque de pertinence de l'argumentation.
2) Raisonner de manière essentiellement mathématique. J'entends par là : tenter d'appliquer le modèle de raisonnement et l'analyse des problèmes traditionnels à l'informatique. Il faut bien se rendre compte qu'algorithmie et programmation sont deux domaines sensiblement différents et que ce n'est pas parce Dijkstra a brillament résolu le problème du colporteur que la manière dont il va l'implémenter va être propre.
... et Dieu tue un chaton aussi. Ces exemples sont les problèmes classiques récurrents de la programmation système. On les attribue à toutes les causes possibles et imaginables quand on a envie de se faire le détracteur d'une méthode particulière.
On ne doit pas imbriquer nos if() de la même manière car moi, au contraire, je tiens cette méthode pour être la plus élégante façon de résoudre ces problèmes, spécialement ceux des malloc(). C'est même la seule chose qui me réconcilie un peu avec Dijkstra. La sacro-sainte programmation structurée ne trouve sa réelle signification que sous cette forme. Tout ce qui est conditionné par un if() doit se trouver à l'intérieur.
Il y a belle lurette que grâce à cela, je n'utilise plus exit() et qu'il n'y a qu'un seul return, toujours à la fin de mes fonctions.
Moi, j'en assène une autre, attribuée à Euclide de Mégare et qui orne le portail mathématique du Wikipédia français :
« Ce qui est affirmé sans preuve peut être nié sans preuve »
Quant à la lisibilité, l'important est de garder de la cohérence tout au long de son propre code. Le reste n'est qu'affaire de subjectivité. Il y a de fortes chances pour qu'un code lisible selon tes critères soit parfaitement obscur pour quelqu'un d'autre. Moi, je pense que lorsque l'on est trop à cheval sur la forme, c'est que l'on ne l'est pas assez sur le fond.
Ben voyons, je parle de if() imbriqués et tu me parles de gotos ? Comme je le dis au dessus, il me semble que l'inclusion des différentes routines est justement le meilleur moyen de s'en débarrasser. Sémantiquement parlant, un analyseur de code (autre grand sujet de troll et d'étude en algorithmie) sera immédiatement capable de reconnaitre si un bloc d'instruction est dépendant d'un if() ou pas. Si on les remet à plat, on perd cette possibilité.
Oui, mais ce n'est pas suffisant. Il faut également le saisir de la manière dont il a voulu l'exprimer. Jamais un troll en informatique n'aura été si proche d'une guerre de religion. Dijkstra était déjà un fondamentaliste, mais la plupart des intégristes interprètent aujourd'hui ses propos selon le sens qui leur plaît et partent en croisade contre tous les autres.
Dijkstra a produit beaucoup de bon matériel, mais il faudrait voir à ne pas prendre tout ce qu'il a dit comme paroles d'évangile.
Tout ceci étant dit, je te remercie quand même d'avoir pris le temps de te pencher sur mon problème (d'une part) et tenter de m'éclairer (d'autre part).
# Que de la gueule !
Posté par Obsidian . En réponse au journal Plop!. Évalué à 4.
Tu ne tiendras pas trois heures :-)
[^] # Re: pas clair ...
Posté par Obsidian . En réponse au message GTK : Forker depuis la boucle principale. Évalué à 2.
Eh oui ! Tout le problème vient de là.
Je ne veux pas générer deux fichiers exécutables distincts, et par conséquent, je ne veux pas utiliser non plus de fonctions du style execv() ou autre ...
D'un point de vue purement algorithmique, c'est tout-à-fait faisable. D'ailleurs mon application inclue deux modules : tty et gtk. Respectivement pour avoir une version texte ou graphique de l'interface, laquelle est dans le schéma général complètement détachée du moteur du jeu ou des autres modules. Il est tout-à-fait possible de forker au bon endroit avec le premier module, pour la simple raison que c'est moi qui ai le contrôle de la boucle principale. Il n'est malheureusement pas possible d'en sortir temporairement sous GTK. De plus, ce dernier module sous-tend une connexion au serveur X et la X-Lib n'aime pas du tout le multi-thread. On ne peut même pas refermer le socket inutilisé dans le processus fils, au risque de refermer complètement la connexion à X.
On retombe toujours sur le même problème : Soit on implique directement deux threads dès le lancement de l'application, soit il faut générer - et installer - deux exécutables et faire invoquer l'un par l'autre avec un exec().
Je pense que je vais confier le soin de forker à la fonction d'initialisation du module GTK, le considérer comme une nécessité de cette lib et éviter de compromettre le reste de l'appli pour cela.
Merci à tous pour votre aide, en tous cas.
[^] # Re: pas clair ...
Posté par Obsidian . En réponse au message GTK : Forker depuis la boucle principale. Évalué à 2.
Mais être obligé de créer deux processus pour la partie cliente simplement pour éviter d'hériter de GTK au moment où je forke, ça, ça m'ennuie.
D'une manière générale, le multithreading est très bien, mais c'est souvent un moyen de pallier une conception douteuse. C'est un peu comme mettre un exit(0) au milieu d'un programme, là où des if() imbriqués auraient parfaitement résolu le problème.
[^] # Re: pas clair ...
Posté par Obsidian . En réponse au message GTK : Forker depuis la boucle principale. Évalué à 2.
L'idée est de permettre à l'utilisateur de lancer un dæmon sur commande, grace à un clic.
Plus précisément, je fais une application (un jeu) qui peut être à la fois serveuse ou cliente dans le sens où elle embarque tout le code nécessaire aux deux fonctions, parce que le tout reste très concis, et que c'est nettement moins contraignant pour l'utilisateur que d'avoir deux exécutables. Cependant, elle ne remplit jamais les deux rôles à la fois : elle est soit cliente, soit serveuse. Quant au serveur proprement dit, il doit naturellement se détacher de la console, aller se rattacher à init et évidement n'utilise aucune interface graphique.
Je pense également que le moyen le plus propre de s'en sortir est effectivement de placer la boucle GTK dans un processus propre et de faire tout le travail sérieux en dehors, mais cela me fait suer de lancer deux processus simplement pour gérer une interface graphique de base.
Merci quand même.
# Re: Journal : Chat du Monde sur le peer to peer
Posté par Obsidian . En réponse au journal Chat du Monde sur le peer to peer. Évalué à 3.
Aucun rapport avec ça ? :
http://www.chatsdumonde.com/
[^] # Re: Guerre des endians
Posté par Obsidian . En réponse au message Récupérer les offsets des membres d'une structure.. Évalué à 2.
Merci beaucoup, je n'ai pas trouvé en cherchant au hasard.
Je me doutais bien qu'elle devait exister.
A bientôt.
[^] # Re: libs11n ?
Posté par Obsidian . En réponse au message Récupérer les offsets des membres d'une structure.. Évalué à 2.
Je vais jeter un coup d'oeil du coté de cette lib.
Pour la sérialisation, tu as tout-à-fait raison, mais j'avais fait exprès de ne pas employer le terme, car un pro du langage Java m'avais expliqué que la sérialisation se contentait de mettre les données binaires d'un objet bout à bout pour les faire passer dans un canal quelquonque, et que l'externalisation avait en plus pour but de convertir les données de façon à pouvoir les exporter.
Merci pour le tuyau.
[^] # Re: Guerre des endians
Posté par Obsidian . En réponse au message Récupérer les offsets des membres d'une structure.. Évalué à 2.
Pour l'utilisation réseau, pas de problème, je compte sortir le tout sous forme texte.
Merci pour ta suggestion.