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

Rolinh · Le 10/03/2011, à 12:19

bruno_pages a écrit :

Vu qu'on est sur un forum kubuntu cela ne sautait pas aux yeux

Effectivement. En même temps, je ne me suis pas plaint du fait qu'il me fallait le compiler.

bruno_pages a écrit :

J'ai également packagé Bouml pour ArchLinux 2009.08 et 2010.05 (en 32 bits)

Il n'y a pas de versions pour Archlinux étant donné que c'est une distribution en rolling release donc packager pour deux snapshots (ce que sont 2009.08 et 2010.05) n'a pas de sens.

bruno_pages a écrit :

Libre à vous bien-sûr de l'utiliser ou non, cela ne change rien pour moi puisque vous ne payez pas pour cela.

Exact. Ce que je voulais soulever, c'est que j'imagine que la plupart des personnes auront la même réaction que moi et que par conséquent, bouml partira aux oubliettes.

tshirtman a écrit :

1/ le C c'est mal
2/ le C c'est mal

A mon avis c'est plutôt le fait de se limiter à un haut niveau qui est mal... En faisant la chaine depuis des langages très haut niveau comme Python jusqu'à l'assembleur permet de penser autrement quand on code...

tshirtman · Le 10/03/2011, à 13:02

Oh, mais j'ai fais pas mal de C ^^ même s'il n'est pas parfait (on a trouvé quelques jolis bugs là dernière fois que j'ai posté un projet en C ici) mais j'en ai fait… (et de l'assembleur aussi). Après, tout langage étudié change la façon dont on code, et dont on pense, (ou alors ça valait pas le coup).

Et je pense que j'ai fais du meilleur C *après* avoir fait beaucoup de python.

Si je me mets au LISP (plus vieux que le C ) c'est aussi pour voir d'autres abstractions et bousculer un peu mes habitudes.

bruno_pages · Le 10/03/2011, à 13:52

Rolinh a écrit :

Il n'y a pas de versions pour Archlinux étant donné que c'est une distribution en rolling release donc packager pour deux snapshots (ce que sont 2009.08 et 2010.05) n'a pas de sens.

je ne suis vraiment pas un spécialiste d'Archlinux, j'utilise juste des versions live pour packager Bouml, mais même si effectivement le mode de fonctionnement n'est pas par exemple celui de Debian ou Ubuntu, je n'ai pas pris ces deux versions par hasard, je n'ai fais que suivre ce qui est/a été indiqué sur la page de téléchargement http://www.archlinux.org/download/ où on peut lire texto Current Release: 2010.05

Кຼزດ · Le 10/03/2011, à 14:03

bruno_pages a écrit :

bouml prend effectivement 3 plombes à compiler
Bouml fait un peu plus qu'écrire hello world, on n'a rien sans rien

En effet, le temps de compilation n'est pas un reproche, mais une constatation (je compile pas mal d'autres logiciels).
Bouml reste bien l'outil UML le plus complet que je connaisse, ça ne m'empêche pas de lui faire des reproches.

les raccourcis claviers qui fonctionnent rarement « tu croyais que tu avais sauvegardé ton projet ? ET BIEN NON MOUHAHAHAHAHA »
sous Qt l'activation des raccourcis a effectivement quelques soucis car tout dépend de la sous fenetre active, par contre sauf si vous avez redéfini le control-s pour autre chose ce racourcis est valable partout et marche toujours
de toute façon il n'est pas possible de sortir de Bouml sans sauvegarde s'il y a eu des modifs sauf bien-sur si vous confirmer explicitement la sortie sans sauvegarde lorsque Bouml vous le demande, ou si vous tuez la chose via un kill -9 par exemple, bref je ne comprends pas cette remarque

Je me doutais bien que le problème était principalement dû à Qt3. Disons que le problème de la sauvegarde est surtout ennuyeux à cause de crashs occasionnels, qui font qu'on perd environ tout le projet si on n'a pas pensé à bien vérifier qu'il était sauvegardé. (ça et la corruption des fichiers qui arrive sans raison des fois, même si beaucoup plus rarement, fait que j'ai un peu d'appréhension à l'utiliser)

« Tu viens de supprimer par erreur la classe que tu venais de passer 3h à faire ? DOMMAGE POUR TOI MOUHAHAHAHAHA »)
comprends toujours pas, la destruction d'une élément peut être annulée tant qu'on n'a pas fermé le projet

D'accord, c'était pas une classe, effectivement, quand on détruit une classe, on peut toujours « défaire » l'action. Cependant, ça ne marche pas souvent pour le reste (associations, attributs, etc…). Le ctrl-z souffre du même problème que le ctrl-s, à savoir qu'il marche par moments uniquement.

3 heures pour faire une classe ? vous devriez sans doute changer d'activité

Pas envie.
Sinon, on m'impose(ait) bouml pour faire tout l'uml, et la version packagée par debian est assez étrange (quand on va dans « à propos », il y a marqué 4.5, mais ça semble plutôt être dans les 4.15…).

J'ai également packagé Bouml pour ArchLinux 2009.08 et 2010.05 (en 32 bits)

Oui, mais je n'installe pas un logiciel dont je n'ai pas les sources, ce qui est le cas pour bouml 4.23+. (et l'absence de sources fait que je ne peux pas non plus le mettre dans les dépôts arch, à moins de passer par une méthode pas propre, que je me refuse à appliquer)

Rolinh · Le 10/03/2011, à 14:09

Je ne le disais pas spécialement pour toi étant donné que j'avais bien compris que tu avais fait de l'assembleur mais plutôt de manière générale (et d'ailleurs, je pense que ta remarque tenait exclusivement du troll ).
Quelqu'un qui doit concevoir des cartouches à encre pour des stylos produira certainement des cartouches plus efficaces s'il connait les propriétés de l'encre et l'ergonomie d'un stylo. (ok, exemple vraiment pourri mais je pense que le principe exposé est compréhensible ^^). Bref, c'est bien d'être ouvert et de vraiment comprendre ce qui se passe.
Exemple: j'avais une fois questionné une vague connaissance à propos de quelque chose spécifique à Python dont je n'avais pas la réponse. Lui, ingénieur, me répond: "je n'en sais rien, je ne travaille que sur des langages haut-niveau" (preuve s'il en fallait qu'il n'y connaissait rien...). Donc en bref, j'imagine que pour ce genre de personne même la notion de type est vague... donc il n'imagine pas le cout d'une conversion de type etc. et le code résultant ne peut pas être bien (l'histoire des types et juste un exemple pour illustrer mon propos).

Par contre:

tshirtman a écrit :

Et je pense que j'ai fais du meilleur C *après* avoir fait beaucoup de python.

Tu pourrais développer? ça m'intéresse vraiment

Rolinh · Le 10/03/2011, à 14:20

@bruno_pages: oui, mais juste au-dessus de current release, il est écrit ceci:

All available images can be burned to a CD, mounted as an ISO file, or be directly written to a USB stick using a utility like `dd`. These are intended for new installations only; an existing Arch Linux system can always be updated with `pacman -Syu`.

tshirtman · Le 10/03/2011, à 15:08

Rolinh a écrit :

Je ne le disais pas spécialement pour toi étant donné que j'avais bien compris que tu avais fait de l'assembleur mais plutôt de manière générale (et d'ailleurs, je pense que ta remarque tenait exclusivement du troll ).

[sifflotte]

Quelqu'un qui doit concevoir des cartouches à encre pour des stylos produira certainement des cartouches plus efficaces s'il connait les propriétés de l'encre et l'ergonomie d'un stylo. (ok, exemple vraiment pourri mais je pense que le principe exposé est compréhensible ^^). Bref, c'est bien d'être ouvert et de vraiment comprendre ce qui se passe.
Exemple: j'avais une fois questionné une vague connaissance à propos de quelque chose spécifique à Python dont je n'avais pas la réponse. Lui, ingénieur, me répond: "je n'en sais rien, je ne travaille que sur des langages haut-niveau" (preuve s'il en fallait qu'il n'y connaissait rien...). Donc en bref, j'imagine que pour ce genre de personne même la notion de type est vague... donc il n'imagine pas le cout d'une conversion de type etc. et le code résultant ne peut pas être bien (l'histoire des types et juste un exemple pour illustrer mon propos).

oui, ou plutot non

Quelqu'un qui croit connaitre le bas niveau va tenter de faire du code plus efficace, en fonction de ses présupposés, mais il se peut qu'il se trompe, en voulant faire le travail d'un autre. Bon, c'est sur que pour la conception, savoir si on va forcer le compilateur à faire des opérations couteuses ou pas est important, mais tenter de faire de l'optimisation à sa place coute parfois en performance (j'avais un pdf là dessus).

Celà dit, un langage qui abstrait les types pourra faire plus d'optimisation en analysant l'algo, qu'un dont les représentations internes sont importantes quand on développe, car le développeur utilisera le type de la façon prévue, pas en fonction des détails d'implémentations.

Par contre:
tshirtman a écrit :
Et je pense que j'ai fais du meilleur C *après* avoir fait beaucoup de python.
Tu pourrais développer? ça m'intéresse vraiment

j'ai tout simplement beaucoup plus de considération pour l'élégance et la concision depuis que j'ai fait beaucoup de python, les dev C ont une certaine tendance à être fier de faire du code incompréhensibles (en insistant sur le fait que SI, c'est tout à fait clair, ce que ça fait, il suffit de connaitre les effets d'un << sur un type flottant, voyons!) promettant de gagner quelques pouillemes de secondes tous les 30 000 ans, et à ne pas appeler une fonction pour quelques lignes.

Le fait d'utiliser des références tout le temps m'a aidé a utiliser les pointeurs de façon beaucoup plus saine aussi.

Enfin, pour t'en dire plus faudrait que j'en refasse, je t'avoue qu'entre le moment ou je me suis fait cette remarque, et maintenant, il y a eu un certain temps sans trop de code C développé (enfin, à part des exemple < 100 lignes quoi).

grim7reaper · Le 10/03/2011, à 15:36

tshirtman a écrit :

(en insistant sur le fait que SI, c'est tout à fait clair, ce que ça fait, il suffit de connaitre les effets d'un << sur un type flottant, voyons!)

LOL
Bah l'effet est super simple : ça compile pas (même sans ajouter d'options à gcc le laxiste)…
Les opérandes doivent être entier, c'est imposé par la norme.

À la limite, tu peux le faire passer en castant en entier comme une brutasse, du coup tu tronques ton nombre flottant et après ça fonctionne comme un entier standard.
Après, tu peux toujours essayer de réutiliser le résultat en tant que flottant, mais j'ai du mal à voir l'intéret car ça m'étonnerait que tu puisses faire des tranformations valables sur des flottants en y allant au bit à bit vu la manière dont c'est codé en interne…

Dernière modification par grim7reaper (Le 10/03/2011, à 15:41)

bruno_pages · Le 10/03/2011, à 15:38

Кຼزດ a écrit :

crashs occasionnels, qui font qu'on perd environ tout le projet si on n'a pas pensé à bien vérifier qu'il était sauvegardé.

qu'elle version utilisez-vous ? avez-vous signalé cela ? (je n'ai pas connaissance de crash)

Кຼزດ a écrit :

D'accord, c'était pas une classe, effectivement, quand on détruit une classe, on peut toujours « défaire » l'action. Cependant, ça ne marche pas souvent pour le reste (associations, attributs, etc…). Le ctrl-z souffre du même problème que le ctrl-s, à savoir qu'il marche par moments uniquement.

le undelete n'est pas limité aux seules classes, il existe (heureusement) pour tout les types d'élément du modèle

par contre le ctrl-z n'est pas associé à undelete par défaut, à priori vous confondez la destruction d'un élément du modèle et le retrait d'un élément d'un diagramme, ce qui n'est pas la même chose.

Кຼزດ a écrit :

je ne peux pas non plus le mettre dans les dépôts arch

tout à fait

@Rolinh : oui, et la production des versions live est la plus active que j'ai jamais vu

The Uploader · Le 10/03/2011, à 16:59

j'ai tout simplement beaucoup plus de considération pour l'élégance et la concision depuis que j'ai fait beaucoup de python, les dev C ont une certaine tendance à être fier de faire du code incompréhensibles (en insistant sur le fait que SI, c'est tout à fait clair, ce que ça fait, il suffit de connaitre les effets d'un << sur un type flottant, voyons!) promettant de gagner quelques pouillemes de secondes tous les 30 000 ans, et à ne pas appeler une fonction pour quelques lignes.

Je rencontre souvent ce genre de code, et ce genre de personnes...
Je ne suis plus tout seul, je ne suis donc bel et bien pas fou de préférer des noms de variables de plus de un caractère! Merci! XD

Dernière modification par The Uploader (Le 10/03/2011, à 17:00)

grim7reaper · Le 10/03/2011, à 18:00

tshirtman a écrit :

les dev C ont une certaine tendance à être fier de faire du code incompréhensibles

Les developpeurs C, bof pas tant que ça.
Les developpeurs Perl par contre…
D'ailleurs même moi je fais du code moins lisible en Perl qu'en C (en même temps Perl offre tellement de raccourcis aux initiés que j'ai du mal à m'en priver )

Dernière modification par grim7reaper (Le 10/03/2011, à 18:01)

tshirtman · Le 10/03/2011, à 18:34

grim7reaper a écrit :

tshirtman a écrit :
(en insistant sur le fait que SI, c'est tout à fait clair, ce que ça fait, il suffit de connaitre les effets d'un << sur un type flottant, voyons!)
LOL
Bah l'effet est super simple : ça compile pas (même sans ajouter d'options à gcc le laxiste)…
Les opérandes doivent être entier, c'est imposé par la norme.
À la limite, tu peux le faire passer en castant en entier comme une brutasse, du coup tu tronques ton nombre flottant et après ça fonctionne comme un entier standard.
Après, tu peux toujours essayer de réutiliser le résultat en tant que flottant, mais j'ai du mal à voir l'intéret car ça m'étonnerait que tu puisses faire des tranformations valables sur des flottants en y allant au bit à bit vu la manière dont c'est codé en interne…

http://en.wikipedia.org/wiki/Fast_inverse_square_root

(ok, c'est sur un long, pardon, mais bon, vu ce qu'il en fait, on est pas à ce détail prêt).

(oui, ça a un intérêt, c'est rapide, pour le coup, mais hugh…)

grim7reaper · Le 10/03/2011, à 18:50

Nan mais c'est connu ce hack (il y a même des chercheurs qui ont trouvé une constante encore meilleure ).

Et là c'est OK, c'est sur un entier.
Ca que tu appelles « détail » c'est ce qui fait la différence entre un code qui viole la norme et qui ne compile pas et un code valide. Pour moi c'est loin d'être un détail…

En tout cas, ce mec a réussi une des rares modifs sur un entier qui donne un résultat cohérent une fois repassé en flottant et ça c'est classe (en même temps ce n'est pas n'importe qui).

Dernière modification par grim7reaper (Le 10/03/2011, à 18:51)

tshirtman · Le 10/03/2011, à 19:01

C'est convertis en entier pour que ça compile, mais c'est sur la zone mémoire d'un long…

Enfin, c'était un exemple extrême, mais les devs C sont du genre à faire ce genre de choses même quand c'est pas nécessaire, parfois… ils aiment faire leur malin…

(cela dit, l'article indique que carmack n'est pas l'auteur, on est pas tout à fait sûr de qui c'est d'ailleurs)

grim7reaper · Le 10/03/2011, à 19:06

tshirtman a écrit :

C'est convertis en entier pour que ça compile, mais c'est sur la zone mémoire d'un long…

Ta phrase n'a aucun sens…
Je pense que tu voulais dire « mais c'est sur la zone mémoire d'un flottant », sinon tu m'inquiètes

Et non, la conversion ne sert pas qu'à permettre la compilation : elle restreint aussi le nombre de bits sur lequel il bosse (ce qui à une incidence sur l'algo).

Dernière modification par grim7reaper (Le 10/03/2011, à 19:07)

tshirtman · Le 10/03/2011, à 19:58

Hmmm un long c'est pas un flottant deux fois plus long? Enfin oui mais de toutes façons il fait une opération prévue pour un int sur un flottant, enfin sûr ses bits, c'est ce que je voulais dire. (une partie seulement ça ok, je savais pas)

grim7reaper · Le 10/03/2011, à 20:20

tshirtman a écrit :

Hmmm un long c'est pas un flottant deux fois plus long?

Non, un long c'est un int qui peut être plus grand (genre int sur 32 bits et long sur 64, mais chez moi int == long). Les autres types entiers sont short et long long (ce dernier n'est disponible qu'en C99).
Les types flottants c'est float et double (et long double en C99)

tshirtman a écrit :

(une partie seulement ça ok, je savais pas)

Bah en fait ça dépend, c'est pas toujours le cas.
Je crois que float -> long, il bosse bien sur tout les bits (encore que ça dépend peut-être de l'archi, faudrait que je regarde si la norme dis quelque chose à ce sujet).
En double, il ne bosserai que sur une partie (je suppose, faudrait que je vérifie pour être sûr).

Dernière modification par grim7reaper (Le 10/03/2011, à 20:26)

tshirtman · Le 10/03/2011, à 20:22

T'imagine quand même pas que j'ai lu toutes les explications? ^^

Édit: erreur de mot, fucking mode swipe...

Dernière modification par tshirtman (Le 10/03/2011, à 20:35)

grim7reaper · Le 10/03/2011, à 20:24

Ouais en fait, j'ai écrit un peu trop vite du coup j'ai édité mon post.
C'est pas vraiment marqué, c'est plutôt moi qui ai fait une interprétation (qu'il faudrait vérifier pour être sûr).

Dernière modification par grim7reaper (Le 10/03/2011, à 20:25)

grim7reaper · Le 10/03/2011, à 23:46

Glob sécu.

Dernière modification par grim7reaper (Le 11/03/2011, à 01:21)

Pylades · Le 11/03/2011, à 00:30

Glob alcoolisé.

Sir Na Kraïou · Le 11/03/2011, à 01:02

Schgrmbl.

cm-t · Le 11/03/2011, à 01:30

'Nuit;

The Uploader · Le 11/03/2011, à 01:31

prout! PHP ça pue du fion!

Rolinh · Le 11/03/2011, à 02:05

@tshirtman: merci pour tes précisions

Sinon, quand je parlais des types... On vient d'avoir une preuve que trop faire de Python détruit les neurones (ceux qui transforment le café en code) ^^
(oui, il est très velu )

Pour l'histoire des dev C, bah oui, on en trouve des comme ça. Mais franchement, si c'est bien écrit, le C c'est loin d'être illisible.
Et il y en a qui sont champion pour compliquer les choses (qui a dit développeurs GNU ^^ ?).
Je reviens toujours sur le même exemple mais pour moi il est flagrant: ça c'est complétement illisible et monstrueux comme code alors que ça se lit comme un livre.... (sans parler du fait que l'un est monstrueusement plus long que l'autre pour faire, au final, la même chose...)

/me va faire dodo après avoir passé son aprem+soirée à faire du pl-sql (arglllll...)... Le pire c'est que je sais qu'une pétée de PHP m'attend pour ce weekend

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#376 Le 10/03/2011, à 12:19

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

#377 Le 10/03/2011, à 13:02

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

#378 Le 10/03/2011, à 13:52

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

#379 Le 10/03/2011, à 14:03

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

#380 Le 10/03/2011, à 14:09

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

#381 Le 10/03/2011, à 14:20

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

#382 Le 10/03/2011, à 15:08

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

#383 Le 10/03/2011, à 15:36

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

#384 Le 10/03/2011, à 15:38

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

#385 Le 10/03/2011, à 16:59

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

#386 Le 10/03/2011, à 18:00

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

#387 Le 10/03/2011, à 18:34

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

#388 Le 10/03/2011, à 18:50

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

#389 Le 10/03/2011, à 19:01

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

#390 Le 10/03/2011, à 19:06

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

#391 Le 10/03/2011, à 19:58

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

#392 Le 10/03/2011, à 20:20

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

#393 Le 10/03/2011, à 20:22

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

#394 Le 10/03/2011, à 20:24

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

#395 Le 10/03/2011, à 23:46

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

#396 Le 11/03/2011, à 00:30

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

#397 Le 11/03/2011, à 01:02

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

#398 Le 11/03/2011, à 01:30

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

#399 Le 11/03/2011, à 01:31

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

#400 Le 11/03/2011, à 02:05

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

Pied de page des forums