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.
Posté par Obsidian .
En réponse au message Threads.
Évalué à 4.
Tu peux effectivement lancer un second thread indépendant du premier pour aller modifier des choses, mais si c'est ton seul objectif (c'est-à-dire que ça n'a pas de vocation éducative), tu risques d'aller au devant de pas mal d'ennuis : race conditions, signaux reçus par un fils mort, deadlocks, TLS, segments de mémoire partagée non partagés, etc.
En fait, il faut savoir à l'avance pourquoi on a beosin d'un thread. Si on se retrouve à envisager cette solution à postériori pour régler un problème, il y a de fortes chances pour qu'il s'agisse en fait d'une grosse erreur de conception du programme initial.
Le multitâche coopératif est, depuis les systèmes d'exploitation de récente génération, devenu synonyme de ringardise et de fiabilité douteuse mais en fait, au sein d'un même programme où les différentes fonctions peuvent se faire confiance mutuellement, c'est souvent le moyen d'atteindre l'efficacité la plus haute.
Essaie plutôt d'arriver toi-même au concept de boucle principale, c'est ce sur quoi s'appuie tout le multitâche. En gros, tu fais ta propre boucle qui fait successivement tous les actions à effectuer « simultanément », et parmi elles, le test des actions utilisateur qui te permettront de passer à l'étape suivante.
Si tu as une freebox en état de marche et un graveur de CD, tu peux télécharger les images de disques proposées par les sites web des différentes distributions. Tu les graves, et tu lances l'installation.
Comme on se doute que tu n'as pas l'intention de te débarrasser directement de Windows, il te faudra faire de la place sur ton disque. ATTENTION : Linux est un système d'exploitation complètement indépendant. Il ne s'installe pas DANS Windows. Il faut repartitionner ton disque dur pour laisser cohabiter Linux avec.
Si tu as un petit peu d'argent de côté, je te suggère, si tu débutes complètement, d'acheter un second disque dur dédié. C'est nettement moins périlleux.
Pour créer un rpm, tu regardes dans man rpm. Il y a une section BUILD. Ce sont les options qui commencent par -b ou -t.
Pour le programme portable, ça dépend de la bibliothèque que tu utilises. Si elle existe sous Windows, ton programme pourra être compilé sur les deux plateformes, mais il te faudra préalablement installer les bonnes DLL sous Windows si elles ne le sont pas encore.
Typiquement, si c'est GTK par exemple, c'est faisable.
La dernière fois qu'on l'a fait, il me semble qu'il y a avait bel et bien une entrée Windows dans le menu de démarrage, mais maintenant que tu me le dis, j'en arrive à douter. Une chose est sûre, on ne reboote jamais. Les machines restent allumées sous le prompt en mode texte, les élèves s'y loguent, font un startx (même X n'est pas lancé par défaut) et accèdent aux serveurs Windows par rdesktop.
C'est sûr que la politique tarifaire des Terminal Server est prohibitive (une licence pour le serveur, n licences pour avoir le droit de se connecter au serveur, une licence pour Terminal Services, et une licence par siège, stockée sur le terminal, pour pouvoir s'y connecter) mais il me semble que cela revient toujours moins cher que de mettre à jour chaque année le parc de l'école entier.
Bon, de toutes façons je suis dans la région parisienne, donc ... Par contre, je ne connais pas ton école mais je trouve ton attitude assez responsable. C'est plutôt rare. Si tu veux vraiment t'en sortir, le meilleur cours de C/C++, on ne le répétera jamais assez, est celui de Christian Casteyde.
La version 1 est toujours disponible gratuitement, la version 2 coûte le prix d'un café (sur les Champs Élysées).
Si tu as une imprimante laser disponible et la possibilité d'imprimer quelques centaines de pages, achète-toi un gros classeur et une perforatrice au Carrefour du coin, imprime le PDF et plonge-z-y toi, cela se lit vraiment très facilement.
Sinon, si tu connais déjà un peu le C++ mais que tu butes sur des concepts précis, n'hésite pas à laisser un message ici.
J'ai un prof d'algo qui nous fait faire le même genre de bêtise. Il faudrait qu'ils redescendent un peu sur terre et qu'ils se rendent compte qu'il arrive un moment où il faut implémenter toute cette belle théorie.
Si « complexité » ne s'entend pas au point de vue algorithmique (genre n.log(n) ), j'ai un collègue expert du Java qui utilise ceci (ça rassemble tout) :
C'est plutôt barbare comme concept. Si tu en es arrivé là, c'est qu'il a fort problablement une erreur de conception dans ton modèle, et il faudra la corriger.
Tu ne pourras pas réclamer directement une recherche sur toutes les tables, pas plus que tu ne pourras inclure implicitement toutes les colonnes d'une table dans un critère de recherche. Seuls les colonnes à afficher peuvent contenir le caractère *.
Par contre, tu peux faire une requête qui te renvoie le nom de toutes les tables, car celles-ci sont elles-mêmes stockées dans une table. Par contre, cette dernière est spécifique à chacun des moteurs de base de données. Donc ta bidouille ne sera pas portable.
Ensuite, tu ne pourras pas faire une jointure directe non plus, mais tu pourras écrire une petite procédure stockée qui les scannera une par une.
Oui, c'est vrai, mais mon post faisait justement référence au droit de l'ouvrir. C'est ce qui s'est passé avec le format GIF, également. Unisys l'a laissé se populariser jusqu'à ce qu'il devienne incontournable (GIF animé, absence du PNG à l'époque) puis a déclaré : « au fait, là, toutes ces jolies petites images qui émaillent le web, ben vous savez quoi ? Vous n'avez pas le droit de les utiliser ! :-) ».
Aujourd'hui tous les navigateurs web reconnaissent toujours le GIF (d'autant plus que le brevet est caduque) mais tout le monde a quand même compris l'utilité d'un standard ouvert.
Donc, pour en revenir à mon premier message, ce n'est pas là faire le procès de Microsoft, c'est même une très bonne chose qu'ils choisissent d'ouvrir leurs formats, c'est juste que je trouve qu'il reste trop risqué et prématuré d'architecturer tout un système autour de ces formats simplement à cause de cette annonce.
Je ne vois pas le rapport. Il est écrit : « On ne fera pas de procès [aux gens qui utilisent nos formats] même si c'est dans des logiciels concurrents ».
Mon problème est que 1) effectivement c'est normal, 2) rien ne les empêche de changer d'avis par la suite, comme il l'ont fait avec FAT en leur temps. Tant techniquement que juridiquement, un format Microsoft ne sera jamais perenne que pour eux-mêmes.
Cela ne veut pas dire que je n'écrirai pas de logiciel reconnaissant ces formats à un moment donné, mais jamais je ne m'appuierai sur ceux-ci pour la sauvegarde de données critiques ou pour l'échange d'informations officielles.
[^] # 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.
# Threads, toussa ...
Posté par Obsidian . En réponse au message Threads. Évalué à 4.
En fait, il faut savoir à l'avance pourquoi on a beosin d'un thread. Si on se retrouve à envisager cette solution à postériori pour régler un problème, il y a de fortes chances pour qu'il s'agisse en fait d'une grosse erreur de conception du programme initial.
Le multitâche coopératif est, depuis les systèmes d'exploitation de récente génération, devenu synonyme de ringardise et de fiabilité douteuse mais en fait, au sein d'un même programme où les différentes fonctions peuvent se faire confiance mutuellement, c'est souvent le moyen d'atteindre l'efficacité la plus haute.
Essaie plutôt d'arriver toi-même au concept de boucle principale, c'est ce sur quoi s'appuie tout le multitâche. En gros, tu fais ta propre boucle qui fait successivement tous les actions à effectuer « simultanément », et parmi elles, le test des actions utilisateur qui te permettront de passer à l'étape suivante.
Bon courage.
# Bienvenue
Posté par Obsidian . En réponse au message demande de conseil. Évalué à 6.
Comme on se doute que tu n'as pas l'intention de te débarrasser directement de Windows, il te faudra faire de la place sur ton disque. ATTENTION : Linux est un système d'exploitation complètement indépendant. Il ne s'installe pas DANS Windows. Il faut repartitionner ton disque dur pour laisser cohabiter Linux avec.
Si tu as un petit peu d'argent de côté, je te suggère, si tu débutes complètement, d'acheter un second disque dur dédié. C'est nettement moins périlleux.
# mount
Posté par Obsidian . En réponse au message lire une disquette sur le serveur a partir d'un TX. Évalué à 4.
# RPM + Lib
Posté par Obsidian . En réponse au message création d'un fichier rpm. Évalué à 2.
Pour le programme portable, ça dépend de la bibliothèque que tu utilises. Si elle existe sous Windows, ton programme pourra être compilé sur les deux plateformes, mais il te faudra préalablement installer les bonnes DLL sous Windows si elles ne le sont pas encore.
Typiquement, si c'est GTK par exemple, c'est faisable.
[^] # Re: Précision
Posté par Obsidian . En réponse à la dépêche Le GET rend votre Bureau Libre !. Évalué à 2.
La dernière fois qu'on l'a fait, il me semble qu'il y a avait bel et bien une entrée Windows dans le menu de démarrage, mais maintenant que tu me le dis, j'en arrive à douter. Une chose est sûre, on ne reboote jamais. Les machines restent allumées sous le prompt en mode texte, les élèves s'y loguent, font un startx (même X n'est pas lancé par défaut) et accèdent aux serveurs Windows par rdesktop.
C'est sûr que la politique tarifaire des Terminal Server est prohibitive (une licence pour le serveur, n licences pour avoir le droit de se connecter au serveur, une licence pour Terminal Services, et une licence par siège, stockée sur le terminal, pour pouvoir s'y connecter) mais il me semble que cela revient toujours moins cher que de mettre à jour chaque année le parc de l'école entier.
[^] # Re: hum
Posté par Obsidian . En réponse au message Annonce : besoin de cours en C++ sur Marseille. Évalué à 3.
Bon, de toutes façons je suis dans la région parisienne, donc ... Par contre, je ne connais pas ton école mais je trouve ton attitude assez responsable. C'est plutôt rare. Si tu veux vraiment t'en sortir, le meilleur cours de C/C++, on ne le répétera jamais assez, est celui de Christian Casteyde.
La version 1 est toujours disponible gratuitement, la version 2 coûte le prix d'un café (sur les Champs Élysées).
http://casteyde.christian.free.fr/cpp/cours/index.html
Si tu as une imprimante laser disponible et la possibilité d'imprimer quelques centaines de pages, achète-toi un gros classeur et une perforatrice au Carrefour du coin, imprime le PDF et plonge-z-y toi, cela se lit vraiment très facilement.
Sinon, si tu connais déjà un peu le C++ mais que tu butes sur des concepts précis, n'hésite pas à laisser un message ici.
[^] # Re: hum
Posté par Obsidian . En réponse au message Annonce : besoin de cours en C++ sur Marseille. Évalué à 2.
Combien elle coûte, la tienne ? :-)
# Astuce
Posté par Obsidian . En réponse au journal XFS: demain j'arrête.... Évalué à 2.
http://linuxfr.org/tips/310.html
# Mouais ...
Posté par Obsidian . En réponse au message segmentation fault sur instructions d'entrée/sortie. Évalué à 2.
Trop d'abstraction tue l'abstraction.
# Ceci :
Posté par Obsidian . En réponse au message Outil de rapport de complexité du code. Évalué à 2.
http://maven.apache.org/
Sinon ceci :
http://pmd.sourceforge.net/
# Plusieurs tables ?
Posté par Obsidian . En réponse au message Comment rechercher un mot dans plusieurs tables ?. Évalué à 3.
Tu ne pourras pas réclamer directement une recherche sur toutes les tables, pas plus que tu ne pourras inclure implicitement toutes les colonnes d'une table dans un critère de recherche. Seuls les colonnes à afficher peuvent contenir le caractère *.
Par contre, tu peux faire une requête qui te renvoie le nom de toutes les tables, car celles-ci sont elles-mêmes stockées dans une table. Par contre, cette dernière est spécifique à chacun des moteurs de base de données. Donc ta bidouille ne sera pas portable.
Ensuite, tu ne pourras pas faire une jointure directe non plus, mais tu pourras écrire une petite procédure stockée qui les scannera une par une.
Ça reste très dégueu.
Bon courage.
[^] # Re: "une très bonne analyse"?
Posté par Obsidian . En réponse au journal Les formats {Open|MS}Office Document à la loupe. Évalué à 2.
Aujourd'hui tous les navigateurs web reconnaissent toujours le GIF (d'autant plus que le brevet est caduque) mais tout le monde a quand même compris l'utilité d'un standard ouvert.
Donc, pour en revenir à mon premier message, ce n'est pas là faire le procès de Microsoft, c'est même une très bonne chose qu'ils choisissent d'ouvrir leurs formats, c'est juste que je trouve qu'il reste trop risqué et prématuré d'architecturer tout un système autour de ces formats simplement à cause de cette annonce.
[^] # Re: "une très bonne analyse"?
Posté par Obsidian . En réponse au journal Les formats {Open|MS}Office Document à la loupe. Évalué à 4.
Mon problème est que 1) effectivement c'est normal, 2) rien ne les empêche de changer d'avis par la suite, comme il l'ont fait avec FAT en leur temps. Tant techniquement que juridiquement, un format Microsoft ne sera jamais perenne que pour eux-mêmes.
Cela ne veut pas dire que je n'écrirai pas de logiciel reconnaissant ces formats à un moment donné, mais jamais je ne m'appuierai sur ceux-ci pour la sauvegarde de données critiques ou pour l'échange d'informations officielles.
[^] # Re: "une très bonne analyse"?
Posté par Obsidian . En réponse au journal Les formats {Open|MS}Office Document à la loupe. Évalué à 1.