/* Topic des codeurs couche-tard [3] */

Кຼزດ · Le 18/12/2010, à 02:38

Rolinh a écrit :

The Uploader a écrit :
on a vu gcc, makefile à la main, gdb, et le codage "à l'ancienne" en cours d'unix, hein... Mais au bout d'un moment 4 terminaux ouverts à la fois c'est plus gérable, c'est tout.
Ben on te dit qu'avec les bons outils: oui
Un joli environnement tiling qui se pilote tout à la main, il n'y a rien de tel

Ou juste un tmux bien splitté comme y faut

Кຼزດ · Le 18/12/2010, à 09:54

plop après le plantage

Elzen · Le 18/12/2010, à 12:31

ArkSeth a écrit :

Je teste ça et j'vous tiens au courant.

Ouaip, ça marche super bien, en effet.

grim7reaper a écrit :

Bon, j'ai un peu avancé.

Au fait, j'dois installer quels paquets pour tester ça ?

Et sinon, deux p'tites questions pour mon C :

1- plutôt que de faire setlocale(LC_NUMERIC, "C"); juste avant le parsage du nombre et setlocale(LC_NUMERIC, ""); juste après, j'peux pas plutôt faire juste le premier en haut du main et laisser comme ça tout au long de l'exécution ? J'vois pas ce que le retour à la valeur par défaut apporte…

2- tu m'disais que tu faisais des tests sur fscanf et que tu me tenais au courant ^^
On est partis sur une déclaration à la mode Pascal, donc var varname: type, donc je suppose que ça va ressembler à une boucle avec du fscanf(file, "var %s:", target); dedans, mais j'aurais besoin d'un peu plus de précisions ^^

grim7reaper · Le 18/12/2010, à 12:52

ArkSeth a écrit :

ArkSeth a écrit :
Je teste ça et j'vous tiens au courant.
Ouaip, ça marche super bien, en effet.
grim7reaper a écrit :
Bon, j'ai un peu avancé.
Au fait, j'dois installer quels paquets pour tester ça ?

Pour l'instant je n'ai pas posté suffisament de code pour que tu puisses tester grand-chose (de toutes manières, ça ne fait pas grand chose pour le moment ^_^).
Sous Ubuntu, ou assimilé, ça doit être le paquet ghc6. Il devrait suffire je pense, ou peut-être qu'il faudra les libghc6* (à voir).
Il faudra probablement 1 ou 2 modules en plus (pour la completion et le type mime), qui seront soient dans les dépôt, soit à récupérer sur hackage mais je les préciserait en temps utile.

1- plutôt que de faire setlocale(LC_NUMERIC, "C"); juste avant le parsage du nombre et setlocale(LC_NUMERIC, ""); juste après, j'peux pas plutôt faire juste le premier en haut du main et laisser comme ça tout au long de l'exécution ? J'vois pas ce que le retour à la valeur par défaut apporte…

Ça permet à l'utilisateur de garder sa locale (donc d'utiliser ses habitudes, la virgule comme sépatateur décimal entre autre). C'est plus user-friendly (même en console).
Mais oui, tu peux.

2- tu m'disais que tu faisais des tests sur fscanf et que tu me tenais au courant ^^
On est partis sur une déclaration à la mode Pascal, donc var varname: type, donc je suppose que ça va ressembler à une boucle avec du fscanf(file, "var %s:", target); dedans, mais j'aurais besoin d'un peu plus de précisions ^^

Oui, et je t'avais répondu (mais vu que c'était en plein milieu du débat tu ne l'as peut-être pas vu).
Bref, ce n'était pas très concluant mais après réflexion, je pense que j'avais mal attaqué le problème.
Peut-être qu'en lisant les lignes via fgets, puis en faisant un strstrt(line, "var") puis un sscanf à cet endroit ça devrait le faire (si tant est qu'une déclaration ne s'étale pas sur plusieurs lignes, sinon il faudra ruser).

Bon, j'ai un train à prendre donc il faut que j'y aille, je posterais éventuellement plus d'info sur le format à utiliser pour faire un « bon » sscanf (%s c'est peut-être risqué, à voir).

Dernière modification par grim7reaper (Le 18/12/2010, à 12:54)

Pylades · Le 18/12/2010, à 16:14

ArkSeth a écrit :

[…] valle (ou vale ? Le dico d'Iceweasel n'en connaît aucun des deux ) […]

Ou vaille ?

grim7reaper a écrit :

[…]
Une des solutions possible c'est de faire un chercher-remplacer du point par une virgule dans ta chaîne avant l'appel à strtod.

C'est moche, ça, en plus tu supposes que la locale de l'utilisateur est fr_FR.
N'est-il pas possible de refixer la locale à C après l'appel à gtk_init ?

ArkSeth a écrit :

Kanor a écrit :
Au sujet du projet je me pose la question suivante on fait comment pour utiliser des fichiers se nommant 0 ! ? ..
On en a déjà parlé
J'ai supprimé (sur une remarque de ce genre de grim7reaper) la fonctionnalité « fichier1 fichier2 » sans rien derrière, donc maintenant, toute ambiguïté est levée : le premier mot est systématiquement un nom de fichier, et le second en est un si et seulement si il y a trois mots sur la commande.
Kanor a écrit :
je pense qu'on devrait mettre les function au début (comme proposé par pylade si je me trompe pas)
Je n'avais pas répondu parce que j'attendais les avis des autres, mais personne d'autre n'a réagit… en ce qui me concerne, je ne vois pas l'intérêt, mais si vous tenez à développer ça en plus, je n'y vois pas d'inconvénient.
Simplement, sémantiquement parlant, il s'agit uniquement de faire du traitement sur des fichiers. Donc il me semble beaucoup plus logique d'utiliser les noms de fichiers comme « commandes », et de préciser ensuite en paramètre le traitement à effectuer (d'ailleurs, « fichier » tout seul n'est après tout qu'une simplification de « fichier 0 » pour faciliter l'écriture).
[…]

Ben du coup je serais plutôt partisan du premier argument comme nom de fichier, du second comme comme commande, et des suivants comme noms de fichiers supplémentaires.

Sinon, pour le bug du forum ; ici ça a toujours fonctionné sur la confiance pour les points. Contrairement à l'intransigeance qui règne sur le TdCT, on a parfois corrigé les scores.

Soyez honnêtes : combien de points auriez-vous eus ?

Кຼزດ · Le 18/12/2010, à 16:16

Pour le compteur, le post #101 (binary post o/) était mon dernier de la soirée

Pylades · Le 18/12/2010, à 16:38

The Uploader a écrit :

Ça fait plein de trucs sans te le dire… au un utilisant les bons outils, on sait exactement ce qui est fait et quand c'est fait.
T'inquiète pas va, je sais ce qu'il fait :
-quand il compile : appelle à g++ (projet cpp en ce moment) avec les paramètres que je lui ai donné...
-quand je debug : appelle à gdb
-trucs qu'il fait sans me dire : scanner le code pour enrichir la complétion... et c'est tout.
Ben, quand tu distribues ton code, comment les gens font pour le compiler ? Ils installent ton IDE et utilisent le fichier de projet spécialement pour ? Tu ne va pas te faire que des amis…
Nan, j'ai un joli makefile...
PS : on a vu gcc, makefile à la main, gdb, et le codage "à l'ancienne" en cours d'unix, hein... Mais au bout d'un moment 4 terminaux ouverts à la fois c'est plus gérable, c'est tout.
PPS : Code::Blocks un bon IDE, laisse moi rire... Même VS fait mieux, et pourtant pour compiler un truc écrit avec ça, faut le fichier du projet, et clicker partout...

C'est peut-être que mon expérience des IDE est biaisée par le fait que je n'ai utilisé que Code::Blocks.

Mais si tu as un makefile, à quoi te sert un IDE alors ?

The Uploader · Le 18/12/2010, à 16:42

Mais si tu as un makefile, à quoi te sert un IDE alors ?

Plus facile à gérer que 4 terminaux... Tout est intégré dans une seule fenêtre, notamment l'arborescence des fichiers du projet...

xapantu · Le 18/12/2010, à 16:45

Ben, déjà, tu as une seule fenêtre, et parfois, je trouve ça plus pratique. Un truc tout bête : tu as une erreur de compilation, tu cliques dessus et tu arrive direct sur le bon fichier avec la bonne ligne. Ou encore, tu lance ton programme en debug, paf, segfault, tu arrive direct à l'instruction fautive. Je trouve que c'est plus pratique que de scruter l'erreur pour voir quel est le fichier responsable et la ligne et de rechercher la ligne pendant quelques temps…

Après, ça te fais aussi un éditeur complet (j'utilise codelite pour ma part), bon, rien de plus que vim quand on sait l'utiliser correctement, je suppose mais bon…

Elzen · Le 18/12/2010, à 16:47

Pylade a écrit :

Ou vaille ?

Ah ouais, tiens. Mais c'est dingue, ça m'était venu spontanément, niveau prononciation

Pylade a écrit :

Ben du coup je serais plutôt partisan du premier argument comme nom de fichier, du second comme comme commande, et des suivants comme noms de fichiers supplémentaires.

Mm, oui, effectivement, ça peut ne pas être mal du tout…

Mais dans ce cas, « fichier1 - fichier2 » pour déplacer, ça fait bizarre, il faudrait un autre opérateur, j'pense.

Pylade a écrit :

Soyez honnêtes : combien de points auriez-vous eus ?

Aucun, j'suis blacklisté ^^

Кຼزດ · Le 18/12/2010, à 16:48

ArkSeth a écrit :

Mais dans ce cas, « fichier1 - fichier2 » pour déplacer, ça fait bizarre, il faudrait un autre opérateur, j'pense.

→

Pylades · Le 18/12/2010, à 16:56

On va essayer de rester en ASCII (portable)…
On peut imaginer « > ».

Dernière modification par Pylade (Le 18/12/2010, à 16:56)

Elzen · Le 18/12/2010, à 16:57

→ ou > (ou plutôt, ← ou <, vu le sens des opérations), je l'avais déjà suggéré pour les liens symboliques (ça se lirait « fichier2 pointe vers fichier1 »)…
(Enfin, j'avais dû ne mettre que <, pour effectivement privilégier l'ascii)

D'un autre côté, pas facile de trouver un truc facile à taper et qui ait du sens à la lecture

Dernière modification par ArkSeth (Le 18/12/2010, à 16:57)

Pylades · Le 18/12/2010, à 17:03

xapantu a écrit :

Ben, déjà, tu as une seule fenêtre, et parfois, je trouve ça plus pratique. Un truc tout bête : tu as une erreur de compilation, tu cliques dessus et tu arrive direct sur le bon fichier avec la bonne ligne. Ou encore, tu lance ton programme en debug, paf, segfault, tu arrive direct à l'instruction fautive. Je trouve que c'est plus pratique que de scruter l'erreur pour voir quel est le fichier responsable et la ligne et de rechercher la ligne pendant quelques temps…

Après, ça te fais aussi un éditeur complet (j'utilise codelite pour ma part), bon, rien de plus que vim quand on sait l'utiliser correctement, je suppose mais bon…

Avec Vim, je n'ai qu'une seule fenêtre (avec possibilité d'avoir plusieurs fichiers ouverts, que ce soit par onglets, fenêtres splittées ou tampons), et ça m'amène directement à la ligne fautive sur les erreurs de compilation. En revanche, pour les segfaults, je me demande bien comment ça marche… Moi j'utilise Valgrind pour les repérer…

xapantu · Le 18/12/2010, à 17:06

Ah ? Il faudrait vraiment que je prenne le temps d'apprendre comment fonctionne vim…

tshirtman · Le 18/12/2010, à 17:13

pour le C en tout cas, on peut faire ça oui, quand tu tape :make, il compile, et avec une compinaison de touche que j'utilise jamais (je fais pas de C) il t'amène à l'erreur suivante.

helly · Le 18/12/2010, à 17:17

tshirtman a écrit :

pour le C en tout cas, on peut faire ça oui, quand tu tape :make, il compile, et avec une compinaison de touche que j'utilise jamais (je fais pas de C) il t'amène à l'erreur suivante.

Bha genre, il te dis erreur en ligne 42, tu tapes 42 et tu te retrouves à la ligne 42 .

Pylades · Le 18/12/2010, à 17:29

Et si le fichier où s'est produite l'erreur n'est pas ouvert, tu fais comment ?

Vim, lui, l'ouvre et t'amène directement à la bonne ligne.

tshirtman · Le 18/12/2010, à 17:32

c'est ce qui m'embête d'ailleurs, il te l'ouvre dans un buffer, et mets ce buffer dans ton onglet actuel, j'aime pas trop…

Pylades · Le 18/12/2010, à 17:37

Tu préférerait quoi ?
Ça se configure probablement…

tshirtman · Le 18/12/2010, à 17:41

un nouvel onglet si il n'est pas actuellement ouvert, sauter vers l'onglet ouvert sinon…

grim7reaper · Le 18/12/2010, à 17:54

Pylade a écrit :

C'est moche, ça, en plus tu supposes que la locale de l'utilisateur est fr_FR.

Oui, solution à La Rache, mais je ne sors l'artillerie que lorsque l'on me le demande.

N'est-il pas possible de refixer la locale à C après l'appel à gtk_init ?

Oui, Cf. mon autre solution.

Ben du coup je serais plutôt partisan du premier argument comme nom de fichier, du second comme comme commande, et des suivants comme noms de fichiers supplémentaires.

Avouez que vous avez tous attendu que je finisse de coder mon truc pour tout changer

Soyez honnêtes : combien de points auriez-vous eus ?

10, mais bon je ne demande pas spécialement réparation (les points ne sont pas la raison qui me font participer à ce topic)

ArkSeth a écrit :

D'un autre côté, pas facile de trouver un truc facile à taper et qui ait du sens à la lecture

Cette fois, j'attends que ça soit fixé avant de modifier mon code

helly · Le 18/12/2010, à 20:50

Bon, allé j'ai mis la première ligne du clfb .

grim7reaper · Le 18/12/2010, à 20:53

En ce qui concerne le format des commandes c'en est où ? La réforme est passée ?

@helly : La première ligne d'une grande et noble lignée (du moins on l'espère)

Dernière modification par grim7reaper (Le 18/12/2010, à 20:54)

Elzen · Le 18/12/2010, à 21:06

grim7reaper a écrit :

En ce qui concerne le format des commandes c'en est où ? La réforme est passée ?

La réforme passera si on se fixe sur les opérateurs.

« fichier1 - fichier2 » pour déplacer, ça vous paraît bizarre, ou pas ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#101 Le 18/12/2010, à 02:38

Re : /* Topic des codeurs couche-tard [3] */

#102 Le 18/12/2010, à 09:54

Re : /* Topic des codeurs couche-tard [3] */

#103 Le 18/12/2010, à 12:31

Re : /* Topic des codeurs couche-tard [3] */

#104 Le 18/12/2010, à 12:52

Re : /* Topic des codeurs couche-tard [3] */

#105 Le 18/12/2010, à 16:14

Re : /* Topic des codeurs couche-tard [3] */

#106 Le 18/12/2010, à 16:16

Re : /* Topic des codeurs couche-tard [3] */

#107 Le 18/12/2010, à 16:38

Re : /* Topic des codeurs couche-tard [3] */

#108 Le 18/12/2010, à 16:42

Re : /* Topic des codeurs couche-tard [3] */

#109 Le 18/12/2010, à 16:45

Re : /* Topic des codeurs couche-tard [3] */

#110 Le 18/12/2010, à 16:47

Re : /* Topic des codeurs couche-tard [3] */

#111 Le 18/12/2010, à 16:48

Re : /* Topic des codeurs couche-tard [3] */

#112 Le 18/12/2010, à 16:56

Re : /* Topic des codeurs couche-tard [3] */

#113 Le 18/12/2010, à 16:57

Re : /* Topic des codeurs couche-tard [3] */

#114 Le 18/12/2010, à 17:03

Re : /* Topic des codeurs couche-tard [3] */

#115 Le 18/12/2010, à 17:06

Re : /* Topic des codeurs couche-tard [3] */

#116 Le 18/12/2010, à 17:13

Re : /* Topic des codeurs couche-tard [3] */

#117 Le 18/12/2010, à 17:17

Re : /* Topic des codeurs couche-tard [3] */

#118 Le 18/12/2010, à 17:29

Re : /* Topic des codeurs couche-tard [3] */

#119 Le 18/12/2010, à 17:32

Re : /* Topic des codeurs couche-tard [3] */

#120 Le 18/12/2010, à 17:37

Re : /* Topic des codeurs couche-tard [3] */

#121 Le 18/12/2010, à 17:41

Re : /* Topic des codeurs couche-tard [3] */

#122 Le 18/12/2010, à 17:54

Re : /* Topic des codeurs couche-tard [3] */

#123 Le 18/12/2010, à 20:50

Re : /* Topic des codeurs couche-tard [3] */

#124 Le 18/12/2010, à 20:53

Re : /* Topic des codeurs couche-tard [3] */

#125 Le 18/12/2010, à 21:06

Re : /* Topic des codeurs couche-tard [3] */

Pied de page des forums