[ Précédent :: 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 :: Suivant ]
Re: Ça arrive...
Il y a plus simple :
% su -c /bin/zsh
... permet de relancer un shell root depuis le compte d'un utilisateur ordinaire pourvu qu'il ait toujours le mot de passe. De là :
% passwd root
Changing password for user root.
New UNIX password: ...
Rihab, si tu as été confronté à ce problème, c'est que tu travailles en root et que ton comptes visiblement le faire souvent. ON NE TRAVAILLE JAMAIS EN ROOT en temps normal. Crée-toi un compte ordinaire et travaille avec.
[ Répondre ]
Re: et pour ne pas être inscrit ?
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é".
[ Répondre ]
Re: Séparateur ?
Alors à vue de nez :
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.
[ Répondre ]
Séparateur ?
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 :
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.
[ Répondre ]
Re: Plutôt complexe
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 :-)
[ Répondre ]
Re: Phrase obligatoire
En même temps, on retrouve la blague dans pratiquement toutes les news de DLFP qui ont traité du sujet : http://linuxfr.org/~boa13/22875.html#763568
[ Répondre ]
Processus != processeur
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.
[ Répondre ]
[ Précédent :: 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 :: Suivant ]
Cette page a été générée par Templeet en 0.1191s (dont 0.035 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Re: pas de langage SMS merci
Attention, le français n'est probablement pas la langue native de l'auteur.
C'est flagrant sur ABCÉlectronique, par exemple, où il y a beaucoup de gens, desormais, qui écrivent depuis l'Afrique du nord et font l'effort de le faire dans leur meilleur français (même si, parfois, ce n'est pas grand chose). Si l'on replace les choses dans leur contexte, certains essais que l'on qualifierait de passable en Île-de-France deviennent assez remarquable, surtout en tenant compte du fait que l'on ne serait probablement pas capables de faire l'inverse.
Ceci dit, il est assez rare que ces gens-là fassent du SMS. Mais bon, même avec Google, maintenant, on ne plus être sûr de rien ...
D'ailleurs, c'est complètement hors-sujet, mais le cas d'ABC est assez intéressant, lui-aussi : c'est l'exemple-type du forum qui est resté très propre pendant un bon bout de temps et qui a viré au trollodrome en quelques mois ...
[ Répondre ]