J'ai constaté l'écran ce matin... Google a lancé son propre truc.
Sauf que ça ne m'intéresse pas, d'autant plus que je trouve le net déjà bien trop pollué par ces réseaux de boulets exhibitionnistes.

alors voila j'ai crée un éditeur de texte avec delphi7 il fonctione parfaitement sauf que lorsqu'on enregistre un fichier on ne peut pas choisir l'extention comme *.txt *.rtf donc si on peut m'aider... merci
tenez voici le code en pascal:

procedure TForm1.ToolButton3Click(Sender: TObject);
begin

FileSaveDialog1.Execute;

RichEdit1.Lines.SaveToFile(FileSaveDialog1.FileNam
e);

end;

mon erreur stupide d'aujourdhui.

On implemente en C des tonnes d'algorithmes de partitionnement de matrice.
Une fonction que l'on utilisait au prealable se met a avoir un comportement bizarre
la valeure qui est retourner dans le corps de la fonction n'est pas le meme que celui qui est recupere a l'exterieur. Je me dis que mon pointeur de pile est dans les choux a cause d'un access memoire a la con. Je le passe dans valgrind. pas d'erreur. Je verifie les variables autour dans la pile, toujours rien d'anormale, juste cette valeure est pourrie.

Je commence a me dire que le bug a l'air mystique et je verifie la fonction appellante. Je vois qu'elle utilise un heap qui est gere par une lib externe. L'etudiant qui a ecrit le code me dit que c'est la premiere fois que l'on utilise ce code de heap et qu'il pense que le probleme est la. Je lui demande ou est le code de test de la heap, il me dit que comme c'est une lib externe, il a fait confiance au code et n'a pas ecrit de code de test.

Me voila parti dans l'ecriture d'un test complique de la heap pour verifier tous les corners case auxquels je pense. L'implementation de la heap passe tous les tests. Je retourne sur le code et dans mon debugger et a rajoutter des informations de debuggage et je ne vois toujours pas de bug.

Je me dis que si on oublie de passer des parametres a une fonction, ca pourrait decaler le pointeur de pile. Je verifie les parametres de fonction, tout ce passe bien.

Je continu de me dire que le code de cette heap est un peu obscure avec tout plein d'appel a pthread et des modificateur de conventions d'appel. Je commence a reecrire une file a priorite dans un tableau. Ca aura une performance minable, mais ca me permettra de debuger. Quand l'implementation est fini. Je la teste et l'integre dans notre base de code.

Le code ne marche toujours pas. Je me repose la question "qu'est ce qui peut mettre le souk dans une pile?". Je pense aux fonction a nombres d'arguments variable et commence a traquer tous les appels a printf. Une fois qu'ils sont tous commenter/desactiver, je reteste le code. Toujours le meme bug.

Je retourne voir les declarations de mes fonctions et verifie les prototype un a un. la fonction qui m'interesse prends bien 5 parametres en entree, un pointeur sur double et 4 entier et retourne un double. Retourne un double ? ca devrait retourner une position dans un tableau ! Je verifie l'implementation de la fonction, elle retourne un entier...

Conclusion, le code que l'on etait entrain d'ecrire pense que la fonction retourne un double et fait un type cast vers entier silencieux.
Le compilateur n'a rien vu parceque la definition et la declaration sont dans deux processus de compilation different!

Lecon du jour:
Le bug est toujours plus stupide que tu ne le pense.
Le C n'est pas un langage assez typer.
On pourrait ajouter des informations de debugage pour faire beeper le linker.

Une journée vraiment calme sur ce forum...

Ca veut dire que tout marche bien. C'est plutot bon signe !

En plus, je manque cruellement de temps en ce moment donc ca m'evite d'avoir un backlog de moderation.

Je passe régulièrement durant la journée, entre ici et developpez.com. Ca me fait faire autre chose 5 minutes. Il m'arrive même parfois d'aller sur le forum linux au hasard.

Je serai pas contre un peu plus d'activité ou de débats parfois.

mmm, ca peut se faire.

"Le C n'est pas un langage assez typer."

Ce genre de message est pas mal. Dire que je croise toujours des gens (dont mon prof de programmation de prépa) qui trouve que le système de type de Caml (par exemple) est une gêne pour programmer et pas une aide.

Justement, un petit jeu
Voici un code PHP :

$var = true ;
if( $var == "true" ) echo("C'est vrai !");
if( $var == "false" ) echo("C'est faux !")
if( $var == "caribou" ) echo("C'est un cariboo !");
if( $var == 4 ) echo("C'est le nombre 4!") ;

Sans tester, essayez de prévoir la sortie (en gros quelle expression if renvoie vrai ou faux).

Si on suppose que ce sont les chaînes qui sont convertie en booléen (c'est un tout petit peu plus logique que le contraire) alors j'imagine que au moins le premier et le troisième test sont vrai. Le second l'est peut-être, ça dépend de quelles chaînes sont converties vers false (selon les langages c'est soit "" soit "false" soit les deux).

Le dernier test est très probablement vrai aussi car j'imagine que 4 se cast en vrai plutôt que true en 1 ou -1 ce qui n'est pas très logique.

un langage qui me forcerait a faire explicitement tous les types cast m'irait tres bien.

Pour le code de _skip, je ne sais plus bien comment c'est en PHP, mais il y a un operateur === qui existe egalement qui a un comportement different de == quand les types variables sont differents.

Je viens de tester le code de skip et mon interpreteur en pense :
Parse error: syntax error, unexpected T_IF, expecting ',' or ';' in /home/erik/- on line 3 (numero de ligne edite)

Le resultat me fait vraiment dire que php est un langage encore plus pourri que bash.

sans tricher!

Il manque un ; à la 3ème ligne :o)
_________________________________________
          http://silvertux.free.fr/

_________________________________________
          http://silvertux.free.fr/

"Je viens de tester le code de skip et mon interpreteur en pense :
Parse error: syntax error, unexpected T_IF, expecting ',' or ';' in /home/erik/- on line 3 (numero de ligne edite)

Le resultat me fait vraiment dire que php est un langage encore plus pourri que bash."

stop accuser le langage, il manque un point virgule a la fin de la troisième ligne, s'too

Evidement que j'ai corrige le ; a la ligne 3. Je parle du vrai resultat que ca donne qui est ridicule.

dnob700 était pas loin

La réponse est donc :

C'est vrai !
C'est faux !
C'est un caribou !
C'est le nombre 4 !

J'ai du codé une API sur les services fournis par notre boîte en Php, c# et java.
C'est bien PHP qui m'a causé le plus de soucis, comme quoi la facilité offerte est pas toujours un avantage sur le long terme sur des bases de codes non triviales (52 classes).

Si vous avez pas de tests unitaires qui couvrent 100% du code en PHP, vous pouvez presque rien garantir tant certains gags de ce genre peuvent s'avérer trompeurs. Et puisqu'il n'y a pas de compilation, une simple fausse manip (retour à la ligne malencontreux, ou frappe clavier involontaire) en jetant un oeil au code peut tout flinguer à votre insu.

le PHP est pour moi un exemple d'un langage qui est aujourd'hui utilisé pour des besoins qui ne semblent pas ceux pour lesquels il a été créé. Je pense surtout aux grosses applications web.

tu peux tester le type des données à tester avec === ou !== du coup, tu ne devrais rien voir dans ton test si tu remplaces les ==.

bon, je devrais lire avant de poser une réponse

Je sors.

hai all

je cherche un moyen de créer un répertoire virtuel en ram. l'idée serait que son fonctionnement soit transparent, càd qu'on puisse l'utiliser comme un vrai volume

en fait, j'ai envie de sortir un jeu en deudé (voire 3D ) sur disquette, pour goûter aux joies de l'optimisation de l'espace disque. pour ça, paq8px est mon ami.

Sauf qu'il ouvre des archives et crée des fichiers a coté, je ne vois pas comment le détourner pour qu'il envoie des choses en ram. est-ce qu'il existe une méthode pour créer un volume comme ça, en RAM, utilisable comme n'importe quel volume physique (pour le chargement des ressources via les librairies graphiques)?