Moi, j'ai essayé un peu et ça m'a l'air pas mal du tout.
Le "Navigo Découverte" a ceci d'intéressant que outre le fait d'être anonyme, il est surtout accessible - de fait - aux usagers qui ne résident pas en Île-de-France, les conditions d'exploitation du Navigo classique le réservant effectivement aux franciliens. Et puis si tu es pressé, l'agent RATP/SNCF peut t'en vendre dans la minute, chargé. Tu colles toi-même ta photo et ton nom par la suite. Pas la peine de se faire une séance de webcam.
Seul problème : si tu le perds, tu perds tous les forfaits qu'il y avait dessus. C'était le cas avec la carte Orange traditionnelle aussi, bien sûr, mais là, comme on peut le charger avec tous ses forfaits, ça devient plus critique. Et puis, c'est dommage de se passer de cette "fonctionnalité".
Ton lexon « commentaires » ne spécifie absolument pas qu'il est censé s'arrêter en bout de ligne. De cette façon, il pourrait bouffer tout ton fichier. Essaie de mettre un $ après "//".* ...
Je te déconseille d'utiliser return '\n' puisque tu es censé renvoyer un token défini, codé par un entier. Ton '\n' pourrait en fait passer pour le dixième lexon défini et là, pour retrouver le bug ...
En fait le problème qu'il y a à gérer le séparateur dans la grammaire, c'est que ça l'alourdit.
Non, pas si c'est bien géré. En rédigeant une grammaire propre, tu peux presque n'avoir à le spécifier qu'une seule fois.
De plus il faut distinguer la notion de séparateur et de terminateur.
En fait, non, justement. Et cela à cause du fait que la lecture de ton source est purement linéaire. On ne revient pas sur ce qui a été lu. En réalité, ton problème est de reconnaître sans ambigüité les cas où tes instructions sont proprement clôturées. Et elles peuvent l'être par trois choses différentes : Un caractère donné (par exemple, le point-virgule), un retour à la ligne, ou la fin du fichier.
C'est donc cette dernière qu'il faut reconnaître au niveau lexical et Lex te propose un mot-clé spécial pour cela : <<EOF>>
Néanmoins, le séparateur-terminateur est bel est bien un élément grammatical, ne serait-ce que parce qu'il est principalement contextuel , mais également parce qu'il peut prendre plusieurs formes.
Dès lors, ta grammaire est très simple à exprimer. une expression correcte est une « instruction dûement et proprement terminée », qui donc s'écrit :
%token TERM
expression: instruction TERM { Execute ($1); }
avec TERM :
[;\n] return TERM;
<<EOF>> return TERM;
Enfin, pour que plusieurs séparateurs puissent se succéder, qu'ils s'agisse de ; ou de retours à la ligne, il faut faire l'hypothèse que l'on fait tous implicitement quand on regarde du C ou autre langage qui le permette : le séparateur clôt une instruction vide. La grammaire devient alors :
expression
: TERM { /* non-opération */ }
| instruction TERM { Execute ($1); }
J'ajoute que ta grammaire serait ambigüe si le WHEN était optionnel et postérieur à ton RESIZE. Par contre, si c'est en préfixe, la clause RESIZE qui suit est obligatoire et lève l'ambigüité. Mais il faut toujours écrire d'une part la grammaire d'une instruction propre et d'autre part, celle qui définit comment ces instructions peuvent s'enchaîner dans une script. Ce n'est pas le cas de la tienne actuellement : ton script: embarque en vrac toutes sortes de définitions, sans les lier forcément entre elles. Et ceci pourrait te causer des problèmes pour les interpréter après les avoir reconnues.
Je ne vois pas ou est la difficulté. Mais je n'ai peut-être pas bien saisi le problème.
Le lexer intercepte le retour chariot seulement s'il n'a pas été intercepté avant, c'est-à-dire dans tes propres règles. Il peut l'être explicitement, ou via un ".", par exemple.
Le retour à la ligne peut être spécifié à Lex facilement en utilisant \n. Dès lors, tu mets ce retour et ton caractère régulier (comme ";") de séparation d'instruction dans une même expression, tu retournes un token quand tu la vérifies, et tu laisse le lexer ignorer les blancs de façon silencieuse. Donc :
instruction: phrase SEP { Execute($1); }
| phrase { Execute ($1); }
| SEP /* Ne fais rien de particulier si tu trouves un séparateur isolé */
phrase: MOT phrase
| MOT
De cette façon, les blancs ne remontent jamais jusqu'au niveau grammatical.
On remarque que j'aurais pu coller un "+" au bout de la regexp de SEP, mais ce n'est pas forcément souhaitable d'un point de vue sémantique. Un blanc peut être long de plusieurs caractères, mais chaque séparateur doit être reconnu quand même.
Quoi ? Il y a encore des gens qui ne connaissent pas Akinator ? Attention, il est TRÈS fort ! :-)
« 20 questions » était très surprenant quand il est sorti, je pense qu'Akinator est dix fois meilleur, mais il est vrai qu'il est spécialisé sur un thème particulier (les personnages).
Seul problème de ces algorithmes : comme ils apprennent des réponses des gens, certains les polluent exprès (une minorité tout de même), mais surtout, il se retrouvent avec beaucoup trop d'informations, et les réponses finissent par être moins ciblées.
Dans le principe, il s'agit simplement d'algos statistiques, à mon avis. Pondération, nuages de points, convergences, etc.
Chaque question est associée à chaque personnage, et la note de chacune d'elle est mise à jour en fonction des réponses du joueur si celui-ci confirme une proposition. Après, quand un profil commence à émerger en fonction des questions au hasard, ce n'est pas très difficile de sortir les profils déjà enregistrés qui y ressemblent le plus, et d'oser une proposition quand la proximité dépasse un certain seuil.
Par contre, je pense que chacun de ces jeux implémentent leurs propres programmes, pas qu'il y ait une algo général pour cela. Ceci dit, les trucs comme Minimax peuvent être intéressants même dans ce domaine.
Il est classiquement utilisé pour jouer, pour deviner la personne ou l'objet à laquelle pense le joueur, mais je voudrais l'implémenter pour une fonction d'identification de plantes.
Je te conseille plutôt de te pencher vers un arbre de décision, ce qui est plutôt approprié pour les plantes :-)
Au démarrage, chaque processeur crée un processus 0
Un processeur n'a pas à proprement parler de notion de processus. C'est une structure organisationnelle qui n'a de sens que du point de vue du système d'exploitation.
Autant que je sache, sur les machines SMP, le premier processeur démarre tout seul et le système se charge de réveiller les autres ensuite. L'ordonnanceur, par contre, fait l'objet d'études poussées que je serais incapable de te décrire en détails dans ce post, mais qui sont en tous points comparables à la planification de l'exécution des différents processus par un processeur seul.
On retiendra quand même la notion d'affinité processeur, qui consiste à exécuter un processus sur un même processeur le plus longtemps possible, car la rotation a un coût, ne serait-ce qu'au niveau des lignes de cache qu'il faut recharger à chaque fois. Ça donne même parfois lieu à des situations cocasses : certains processeurs d'entrée de gamme s'avèrent plus performants que leurs homologues plus évolués car il partagent une même ligne de cache. Dans la plupart des cas de figure, c'est désastreux, mais avec des opérations vectorisées et bien distribuées, ça peut être autant de données en moins à recharger, et autant d'accès bus évités, également.
Pour le douanier, il ne devait sans doute pas avoir de doute, mais maintenant il y en aura pour tous ceux qui étaient dans la salle en même temps que toi ...
La clé du mystère est donc en grande partie historique. Ce sont donc deux grandes réponses - différentes -, données par des mouvances - différentes - à un même problème.
Il faut également souligner certaines choses :
- Les sockets sont une tentative de conception d'un procédé de communication universel (à une époque où les machines personnelles étaient rarement en réseau, d'ailleurs). On retrouve des embryons d'héritage et de modèles objets en C, à une époque où ce n'était pas courant, et leur volonté de penser à tout dès le départ nous lègue malheureusement une interface lourde et remplies de choses qui ne servent à rien, mais qu'il faut quand même respecter.
- Si je ne me trompe pas, mmap() est beaucoup plus récent que shmxxx() et, de toutes façons, il sert implicitement à projeter en mémoire le contenu d'un fichier, ce en s'appuyant sur les mécanismes de la mémoire virtuelle. Le swap existe depuis belle lurette sur tous les systèmes mais cela n'a pas toujours été le cas. La manière la plus simple de réserver la mémoire nécessaire à cette projection reste l'allocation d'un segment de mémoire partagée. Il en reste que ce sont deux choses différentes.
- Le sémaphore de Dijkstra est un concept beaucoup plus abstrait que son implémentation sous Unix pourrait le laisser croire : http://fr.wikipedia.org/wiki/S%C3%A9maphore_(informatique) . La raison pour laquelle c'est un pillier des IPC SysV est que ce concept implique la participation du système pour fonctionner correctement.
- L'intérêt principal des IPC SysV est de garantir l'atomicité des transactions : en effet, les fonctions semxxx() te permettent de travailler sur des tableaux de sémaphores, lesquels sémaphores ne seront mis à jour que s'ils peuvent l'être tous en même temps et en une seule fois. C'est ce qui rend la syntaxe d'appel si compliquée, d'ailleurs.
Maintenant, pourquoi ne voit-on pas plus d'IPC SysV ? D'abord parce que le monde BSD ne les a pas utilisés dès le départ. Ensuite, parce que la majorité des processus travaillent seuls et n'ont pas besoin de communiquer entre eux, tout simplement.
On ajoutera enfin que les cas où les sémaphores, pleinement implémentés, se justifient sont nombreux, mais qu'ils dépassent bien souvent le simple cas d'école. En TP, pour faire simple, on va souvent utiliser un sémaphore tout seul, histoire de dire que l'on a utilisé le système, en obligeant un processus à en attendre un autre. Et cette tâche peut très bien être remplie avec un tube. Elle l'est généralement car c'est plus simple à déclarer et à manipuler, ça fonctionne sur tous les Unices, y compris les plus anciens, ça reste dans l'esprit fichier, et surtout c'est anonyme et automatiquement libéré à la fermeture du tube ou à la mort du processus.
Enfin, les sémaphores servent beaucoup plus à réaliser des mutex qu'à synchroniser des processus (qu'ils ne bloquent pas pour le plaisir). Mais lorsque des ressources mutuellement exclusives sont exploitées par un unique processus, alors il est plus efficace pour lui de faire sa tambouille seul que de passer par un appel système. A dire vrai, un sémaphore utilisé par un seul processus ne servirait à rien (en mode bloquant), puisqu'il n'y aurait personne d'autre pour libérer la ressource et le réveiller.
Oh oui, je sais bien. D'ailleurs, tu verras que mes propres interventions accompagnent souvent les tiennes. Sauf qu'au bout d'un moment, on finit par reconnaître le lascar ...
Non, reste. Il n'y a qu'a jeter un oeil à sa page perso linuxfr pour se rendre compte que toutes ses interventions sont du même tonneau : http://linuxfr.org/~robertix/
" Informatique ", c'est bien pratique, et c'est un terme que les anglo-saxons nous envient. Maintenant, il y a deux façons de le voir : la science du traitement de l'information (Dijkstra, téléscopes, toussa), et le monde des machines qui la servent. Et, là encore, ça n'a pas fini de troller ...
Je propose la création du Point Ch'timi jusqu'à que l'effet de mode passe.
Le film a blasté la Grande Vadrouille, est sur le point d'éperonner le Titanic ... si ça continue, on va le classer avec "Dur dur d'être un bébé" et les journaux sur le T.C.E.
Marre, quoi.
Bon, j'ai survolé l'article et ses commentaires, mais à première vue, je peux dire ceci :
- il ne faut pas confondre la liste des adresses locales, sur lesquelles le serveur va se mettre à l'écoute, de celle des machines distantes autorisées à se connecter. La première est dans postgresql.conf, la seconde dans pg_hba.conf (Host-Based Authentication).
- Tu as autorisé 127.0.0.1/32 à se connecter, avec un mot de passe. Mais si c'est le seul accès possible, il y a de fortes chance pour que ton client ouvre un socket Unix plutôt qu'une connexion TCP. Dans ce cas, il faut aussi laisser rentrer les gens en local.
- Il faut se souvenir que PG refuse de démarrer si 1) on ne lui indique pas le chemin vers le cluster, soit explicitement, en ligne de commande, avec -D, soit implicitement, en utilisant la variable d'environnement PGDATA, et 2) si le répertoire du cluster et les fichiers qu'il contient n'appartiennent pas exclusivement à l'utilisateur qui lance le serveur.
Moi, j'ai installé le mien au boulot et tout fonctionne bien.
[^] # Re: Fatalité
Posté par Obsidian . En réponse au journal Victoire de RMS sur Microsoft. Évalué à 4.
Ça veut dire qu'en fait, ils jouent au démineur ?
[^] # Re: Re:
Posté par Obsidian . En réponse au journal Adobe en passe de liberer flash?. Évalué à 10.
'faudra dire Redmonsanto, maintenant ! :-)
(Aïe, on n'est que lundi ->[])
[^] # Re: et pour ne pas être inscrit ?
Posté par Obsidian . En réponse au journal Se désinscrire des fichiers de la RATP. Évalué à 2.
[^] # Re: et pour ne pas être inscrit ?
Posté par Obsidian . En réponse au journal Se désinscrire des fichiers de la RATP. Évalué à 2.
Le "Navigo Découverte" a ceci d'intéressant que outre le fait d'être anonyme, il est surtout accessible - de fait - aux usagers qui ne résident pas en Île-de-France, les conditions d'exploitation du Navigo classique le réservant effectivement aux franciliens. Et puis si tu es pressé, l'agent RATP/SNCF peut t'en vendre dans la minute, chargé. Tu colles toi-même ta photo et ton nom par la suite. Pas la peine de se faire une séance de webcam.
Seul problème : si tu le perds, tu perds tous les forfaits qu'il y avait dessus. C'était le cas avec la carte Orange traditionnelle aussi, bien sûr, mais là, comme on peut le charger avec tous ses forfaits, ça devient plus critique. Et puis, c'est dommage de se passer de cette "fonctionnalité".
[^] # Re: Séparateur ?
Posté par Obsidian . En réponse au message YACC: retour-chariot comme séparateur. Évalué à 2.
Ton lexon « commentaires » ne spécifie absolument pas qu'il est censé s'arrêter en bout de ligne. De cette façon, il pourrait bouffer tout ton fichier. Essaie de mettre un $ après "//".* ...
Je te déconseille d'utiliser return '\n' puisque tu es censé renvoyer un token défini, codé par un entier. Ton '\n' pourrait en fait passer pour le dixième lexon défini et là, pour retrouver le bug ...
En fait le problème qu'il y a à gérer le séparateur dans la grammaire, c'est que ça l'alourdit.
Non, pas si c'est bien géré. En rédigeant une grammaire propre, tu peux presque n'avoir à le spécifier qu'une seule fois.
De plus il faut distinguer la notion de séparateur et de terminateur.
En fait, non, justement. Et cela à cause du fait que la lecture de ton source est purement linéaire. On ne revient pas sur ce qui a été lu. En réalité, ton problème est de reconnaître sans ambigüité les cas où tes instructions sont proprement clôturées. Et elles peuvent l'être par trois choses différentes : Un caractère donné (par exemple, le point-virgule), un retour à la ligne, ou la fin du fichier.
C'est donc cette dernière qu'il faut reconnaître au niveau lexical et Lex te propose un mot-clé spécial pour cela : <<EOF>>
Néanmoins, le séparateur-terminateur est bel est bien un élément grammatical, ne serait-ce que parce qu'il est principalement contextuel , mais également parce qu'il peut prendre plusieurs formes.
Dès lors, ta grammaire est très simple à exprimer. une expression correcte est une « instruction dûement et proprement terminée », qui donc s'écrit :
%token TERM
expression: instruction TERM { Execute ($1); }
avec TERM :
[;\n] return TERM;<<EOF>> return TERM;
Enfin, pour que plusieurs séparateurs puissent se succéder, qu'ils s'agisse de ; ou de retours à la ligne, il faut faire l'hypothèse que l'on fait tous implicitement quand on regarde du C ou autre langage qui le permette : le séparateur clôt une instruction vide. La grammaire devient alors :
expression: TERM { /* non-opération */ }
| instruction TERM { Execute ($1); }
J'ajoute que ta grammaire serait ambigüe si le WHEN était optionnel et postérieur à ton RESIZE. Par contre, si c'est en préfixe, la clause RESIZE qui suit est obligatoire et lève l'ambigüité. Mais il faut toujours écrire d'une part la grammaire d'une instruction propre et d'autre part, celle qui définit comment ces instructions peuvent s'enchaîner dans une script. Ce n'est pas le cas de la tienne actuellement : ton script: embarque en vrac toutes sortes de définitions, sans les lier forcément entre elles. Et ceci pourrait te causer des problèmes pour les interpréter après les avoir reconnues.
[^] # Re: Séparateur ?
Posté par Obsidian . En réponse au message YACC: retour-chariot comme séparateur. Évalué à 3.
# Séparateur ?
Posté par Obsidian . En réponse au message YACC: retour-chariot comme séparateur. Évalué à 4.
Le lexer intercepte le retour chariot seulement s'il n'a pas été intercepté avant, c'est-à-dire dans tes propres règles. Il peut l'être explicitement, ou via un ".", par exemple.
Le retour à la ligne peut être spécifié à Lex facilement en utilisant \n. Dès lors, tu mets ce retour et ton caractère régulier (comme ";") de séparation d'instruction dans une même expression, tu retournes un token quand tu la vérifies, et tu laisse le lexer ignorer les blancs de façon silencieuse. Donc :
Dans Lex :
[A-Za-z0-9]+ return MOT;
[;\n] return SEP;
[ \t]+ /* Ignore les blancs */ ;
. printf ("Erreur. Caractère non reconnu.\n");
Et dans Yacc
instruction: phrase SEP { Execute($1); }
| phrase { Execute ($1); }
| SEP /* Ne fais rien de particulier si tu trouves un séparateur isolé */
phrase: MOT phrase
| MOT
De cette façon, les blancs ne remontent jamais jusqu'au niveau grammatical.
On remarque que j'aurais pu coller un "+" au bout de la regexp de SEP, mais ce n'est pas forcément souhaitable d'un point de vue sémantique. Un blanc peut être long de plusieurs caractères, mais chaque séparateur doit être reconnu quand même.
[^] # Re: Plutôt complexe
Posté par Obsidian . En réponse au message Cherche algorithme de devinette. Évalué à 3.
« 20 questions » était très surprenant quand il est sorti, je pense qu'Akinator est dix fois meilleur, mais il est vrai qu'il est spécialisé sur un thème particulier (les personnages).
Seul problème de ces algorithmes : comme ils apprennent des réponses des gens, certains les polluent exprès (une minorité tout de même), mais surtout, il se retrouvent avec beaucoup trop d'informations, et les réponses finissent par être moins ciblées.
Dans le principe, il s'agit simplement d'algos statistiques, à mon avis. Pondération, nuages de points, convergences, etc.
Chaque question est associée à chaque personnage, et la note de chacune d'elle est mise à jour en fonction des réponses du joueur si celui-ci confirme une proposition. Après, quand un profil commence à émerger en fonction des questions au hasard, ce n'est pas très difficile de sortir les profils déjà enregistrés qui y ressemblent le plus, et d'oser une proposition quand la proximité dépasse un certain seuil.
Par contre, je pense que chacun de ces jeux implémentent leurs propres programmes, pas qu'il y ait une algo général pour cela. Ceci dit, les trucs comme Minimax peuvent être intéressants même dans ce domaine.
Il est classiquement utilisé pour jouer, pour deviner la personne ou l'objet à laquelle pense le joueur, mais je voudrais l'implémenter pour une fonction d'identification de plantes.
Je te conseille plutôt de te pencher vers un arbre de décision, ce qui est plutôt approprié pour les plantes :-)
[^] # Re: Hum
Posté par Obsidian . En réponse au journal Lisaac plus rapide que le C !. Évalué à 1.
[^] # Re: Phrase obligatoire
Posté par Obsidian . En réponse au journal Hans Reiser déclaré coupable. Évalué à 6.
# Processus != processeur
Posté par Obsidian . En réponse au message Question pour débutant. Évalué à 4.
Un processeur n'a pas à proprement parler de notion de processus. C'est une structure organisationnelle qui n'a de sens que du point de vue du système d'exploitation.
Autant que je sache, sur les machines SMP, le premier processeur démarre tout seul et le système se charge de réveiller les autres ensuite. L'ordonnanceur, par contre, fait l'objet d'études poussées que je serais incapable de te décrire en détails dans ce post, mais qui sont en tous points comparables à la planification de l'exécution des différents processus par un processeur seul.
On retiendra quand même la notion d'affinité processeur, qui consiste à exécuter un processus sur un même processeur le plus longtemps possible, car la rotation a un coût, ne serait-ce qu'au niveau des lignes de cache qu'il faut recharger à chaque fois. Ça donne même parfois lieu à des situations cocasses : certains processeurs d'entrée de gamme s'avèrent plus performants que leurs homologues plus évolués car il partagent une même ligne de cache. Dans la plupart des cas de figure, c'est désastreux, mais avec des opérations vectorisées et bien distribuées, ça peut être autant de données en moins à recharger, et autant d'accès bus évités, également.
[^] # Re: Sécurité...
Posté par Obsidian . En réponse au journal Wifi et sécurité en avion.. Évalué à 3.
[^] # Re: Sécurité...
Posté par Obsidian . En réponse au journal Wifi et sécurité en avion.. Évalué à 2.
Pour le douanier, il ne devait sans doute pas avoir de doute, mais maintenant il y en aura pour tous ceux qui étaient dans la salle en même temps que toi ...
[^] # Re: IPC vs IPC
Posté par Obsidian . En réponse au message IPC: mmap() vs shmget(). Évalué à 4.
SHM+MSG+SEM => SysV
Sockets => BSD
La clé du mystère est donc en grande partie historique. Ce sont donc deux grandes réponses - différentes -, données par des mouvances - différentes - à un même problème.
Il faut également souligner certaines choses :
- Les sockets sont une tentative de conception d'un procédé de communication universel (à une époque où les machines personnelles étaient rarement en réseau, d'ailleurs). On retrouve des embryons d'héritage et de modèles objets en C, à une époque où ce n'était pas courant, et leur volonté de penser à tout dès le départ nous lègue malheureusement une interface lourde et remplies de choses qui ne servent à rien, mais qu'il faut quand même respecter.
- Si je ne me trompe pas, mmap() est beaucoup plus récent que shmxxx() et, de toutes façons, il sert implicitement à projeter en mémoire le contenu d'un fichier, ce en s'appuyant sur les mécanismes de la mémoire virtuelle. Le swap existe depuis belle lurette sur tous les systèmes mais cela n'a pas toujours été le cas. La manière la plus simple de réserver la mémoire nécessaire à cette projection reste l'allocation d'un segment de mémoire partagée. Il en reste que ce sont deux choses différentes.
- Le sémaphore de Dijkstra est un concept beaucoup plus abstrait que son implémentation sous Unix pourrait le laisser croire : http://fr.wikipedia.org/wiki/S%C3%A9maphore_(informatique) . La raison pour laquelle c'est un pillier des IPC SysV est que ce concept implique la participation du système pour fonctionner correctement.
- L'intérêt principal des IPC SysV est de garantir l'atomicité des transactions : en effet, les fonctions semxxx() te permettent de travailler sur des tableaux de sémaphores, lesquels sémaphores ne seront mis à jour que s'ils peuvent l'être tous en même temps et en une seule fois. C'est ce qui rend la syntaxe d'appel si compliquée, d'ailleurs.
Maintenant, pourquoi ne voit-on pas plus d'IPC SysV ? D'abord parce que le monde BSD ne les a pas utilisés dès le départ. Ensuite, parce que la majorité des processus travaillent seuls et n'ont pas besoin de communiquer entre eux, tout simplement.
On ajoutera enfin que les cas où les sémaphores, pleinement implémentés, se justifient sont nombreux, mais qu'ils dépassent bien souvent le simple cas d'école. En TP, pour faire simple, on va souvent utiliser un sémaphore tout seul, histoire de dire que l'on a utilisé le système, en obligeant un processus à en attendre un autre. Et cette tâche peut très bien être remplie avec un tube. Elle l'est généralement car c'est plus simple à déclarer et à manipuler, ça fonctionne sur tous les Unices, y compris les plus anciens, ça reste dans l'esprit fichier, et surtout c'est anonyme et automatiquement libéré à la fermeture du tube ou à la mort du processus.
Enfin, les sémaphores servent beaucoup plus à réaliser des mutex qu'à synchroniser des processus (qu'ils ne bloquent pas pour le plaisir). Mais lorsque des ressources mutuellement exclusives sont exploitées par un unique processus, alors il est plus efficace pour lui de faire sa tambouille seul que de passer par un appel système. A dire vrai, un sémaphore utilisé par un seul processus ne servirait à rien (en mode bloquant), puisqu'il n'y aurait personne d'autre pour libérer la ressource et le réveiller.
[^] # Re: heu,
Posté par Obsidian . En réponse au message le menu de gnome. Évalué à 2.
Fear !
[^] # Re: heu,
Posté par Obsidian . En réponse au message le menu de gnome. Évalué à 3.
Allez, bon vent.
[^] # Re: heu,
Posté par Obsidian . En réponse au message le menu de gnome. Évalué à 2.
[^] # Re: heu,
Posté par Obsidian . En réponse au message le menu de gnome. Évalué à 5.
[^] # Re: sudo / ssh
Posté par Obsidian . En réponse au message intégrer le mot de passe dans une commande. Évalué à 8.
[^] # Re: juste un questio ncomem ça
Posté par Obsidian . En réponse au journal Priez pour nous pauvres libristes. Évalué à 3.
[^] # Re: TIC ?
Posté par Obsidian . En réponse au journal Lille, une ville sinistrée sur le plan des TIC?. Évalué à 4.
[^] # Re: Arrete de braire le cheuteumi
Posté par Obsidian . En réponse au journal Lille, une ville sinistrée sur le plan des TIC?. Évalué à 8.
Le film a blasté la Grande Vadrouille, est sur le point d'éperonner le Titanic ... si ça continue, on va le classer avec "Dur dur d'être un bébé" et les journaux sur le T.C.E.
Marre, quoi.
# Alors, à vue de nez ...
Posté par Obsidian . En réponse au message Installer postgresql. Évalué à 2.
- il ne faut pas confondre la liste des adresses locales, sur lesquelles le serveur va se mettre à l'écoute, de celle des machines distantes autorisées à se connecter. La première est dans postgresql.conf, la seconde dans pg_hba.conf (Host-Based Authentication).
- Tu as autorisé 127.0.0.1/32 à se connecter, avec un mot de passe. Mais si c'est le seul accès possible, il y a de fortes chance pour que ton client ouvre un socket Unix plutôt qu'une connexion TCP. Dans ce cas, il faut aussi laisser rentrer les gens en local.
- Il faut se souvenir que PG refuse de démarrer si 1) on ne lui indique pas le chemin vers le cluster, soit explicitement, en ligne de commande, avec -D, soit implicitement, en utilisant la variable d'environnement PGDATA, et 2) si le répertoire du cluster et les fichiers qu'il contient n'appartiennent pas exclusivement à l'utilisateur qui lance le serveur.
Moi, j'ai installé le mien au boulot et tout fonctionne bien.
Bon courage.
[^] # Re: Redémarrage en douceur
Posté par Obsidian . En réponse au message command ps. Évalué à 2.
# L'essentiel est sauf !
Posté par Obsidian . En réponse au journal Bientôt du pingouin dans l'hémicycle ?. Évalué à 2.