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

Rolinh · Le 23/12/2010, à 15:36

:!pakman a écrit :

Des si déments -> Décidément
Et ça c'est pas un pb de clavier

Non, mais c'était voulu

Ah ouais, violent l'histoire de float()

Elzen · Le 23/12/2010, à 15:53

C'est effectivement étrange et dommage que la version propre soit plus lente que l'autre, mais est-ce si grave ? J'veux dire, si on est vraiment au centième de seconde près, il vaut de toute façon mieux utiliser du C ou de l'assembleur que du Python, non ?
J'avoue que vérifier la vitesse des opérations de bases est un truc qui me vient rarement à l'esprit quand je teste un langage…

Sinon, existe-t-il un caractère unicode pour le i des complexes ?
Le i normal fait un peu moche sur le bouton de ma calculatrice, et je ne suis pas sûr que ça vaille le coup de forcer la police ou le style juste pour un seul bouton…

(Ah, et sinon, j'ai une segfault (voire plus rarement un gros plantage GTK beaucoup plus bavard) dont je n'arrive pas à déterminer l'origine qui se produit de temps en temps quand je joue avec les menus de ma calculatrice (ouverture de fichiers, évaluation de résultat en popup, etc…), et ça m'énerve)

grim7reaper · Le 23/12/2010, à 16:01

@ArkSeth : gdb est ton ami .
Ajoute

ulimit -c unlimited

dans ton .bashrc (ou équivalent selon le shell que tu utilises) pour faciliter les autopsies (autorise la création de coredump en cas de plantage sévère)

Dernière modification par grim7reaper (Le 23/12/2010, à 16:02)

Pylades · Le 23/12/2010, à 16:03

U+1D456 (que le forum refuse d'afficher).

Sinon, t'as ⅈ (U+2148).

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

Elzen · Le 23/12/2010, à 16:08

grim7reaper a écrit :

@ArkSeth : gdb est ton ami .
Ajoute
ulimit -c unlimited
dans ton .bashrc (ou équivalent selon le shell que tu utilises) pour faciliter les autopsies (autorise la création de coredump en cas de plantage sévère)

Jamais entendu parler de gdb, et à quoi est censée servir la commande en question ?

@Plyade :

The Uploader · Le 23/12/2010, à 16:10

Jamais entendu parler de gdb

O_O

grim7reaper · Le 23/12/2010, à 16:14

ArkSeth a écrit :

Jamais entendu parler de gdb

The GNU Project Debugger, le debogueur (en cli) associé à gcc (il existe des front-end graphiques mais je ne m'en sers jamais).
Bosser en C sans savoir utiliser de debogueur à des limites (le debug via printf c'est mignon mais bon, c'est pas toujours adapté non plus…)

et à quoi est censée servir la commande en question ?

grim7reaper a écrit :

@ArkSeth : gdb est ton ami .
Ajoute
ulimit -c unlimited
dans ton .bashrc (ou équivalent selon le shell que tu utilises) pour faciliter les autopsies (autorise la création de coredump en cas de plantage sévère)

Les coredump (dump de la RAM du prog lors de son décès) pouvant être utilisé par gdb lors du débug.
Bien sûr, pour un bon débug il faut compiler avec les symboles de debug (option -g de gcc)

Rolinh · Le 23/12/2010, à 16:20

Tu n'as pas fait beaucoup de C ArkSeth? Je ne m'imagine même pas coder en C sans gcc!
Quand on s'amuse avec des pointeurs, c'est juste salvateur!

Kanor · Le 23/12/2010, à 17:39

ArkSeth tu connais pdb quand même ?

Pylades · Le 23/12/2010, à 17:42

Rolinh a écrit :

Tu n'as pas fait beaucoup de C ArkSeth? Je ne m'imagine même pas coder en C sans gdb!
Quand on s'amuse avec des pointeurs, c'est juste salvateur!

Ché pas, moi Valgrind me suffit amplement…

(Même si je ne m'appelle pas ArkSeth. )

Dernière modification par Pylade (Le 23/12/2010, à 17:42)

grim7reaper · Le 23/12/2010, à 17:46

@Kanor : pdb o_O

@Pylade : Oui Valgrind c'est indispensable aussi (juste très chiant à utiliser (voire inutilisable parfois) sur les bibliothèques graphiques car il faut se créer un fichier de suppression), mais les deux programmes n'ont juste pas le même rôle.
Valgrind sert à détecter des fuites de mémoire, les accès non autorisés et à faire du profiling (comme avec gprof).
gdb est un débogueur (breakpoint, watchpoint, stacktrace, désassemblage de code, éxécution pas à pas, analyse et modification de variable et registre, etc).

Dernière modification par grim7reaper (Le 23/12/2010, à 17:51)

Kanor · Le 23/12/2010, à 18:25

Non

import pdb

http://docs.python.org/library/pdb.html

xapantu · Le 23/12/2010, à 18:59

Snif, gitorious est down chez vous aussi ? (enfin, il y a un problème de dns ?)

helly · Le 23/12/2010, à 19:07

@xapantu : http://downforeveryoneorjustme.com/

Toineo · Le 23/12/2010, à 19:08

The Uploader a écrit :

Jamais entendu parler de gdb
O_O

+1
ArkSeth, tu n'as vraiment jamais utilisé gdb ? Et un autre débogueur ? C'est juste super utile... (genre, quand tu tombes sur _le_ bug dont tu ne trouves _vraiment_ pas l'origine...)

xapantu · Le 23/12/2010, à 19:09

Meric, je connaissais pas

Mais par conte, ça va pas, parce que là, le site est pas vraiment "down", c'est juste que ça redirige vers la page d'une entreprise qui vend des dns…

Enfin, bon, c'est pas grave de toute façon

The Uploader · Le 23/12/2010, à 19:34

T'as essayé OpenDNS ?

Dernière modification par The Uploader (Le 23/12/2010, à 20:06)

Kanor · Le 23/12/2010, à 20:02

Ip de gitorious 87.238.52.168
ils ont oublié de renouvellé le domain Boulet ..

xapantu · Le 23/12/2010, à 20:16

Merci Kanor

The Uploader a écrit :

T'as essayé OpenDNS ?

Non… (j'suis un peu nul aussi, donc, je vais juste arriver à ne plus avoir de dns si j'essaye ^^)

tshirtman · Le 23/12/2010, à 20:37

Pylade a écrit :

Python 3 FTW!
 ~$ python3 -m timeit '10/3'
10000000 loops, best of 3: 0.0523 usec per loop
(Les deux autres manières prennent sensiblement le même temps en avec python3 qu'avec python.)

Tshirtman, si jamais tu voulais utiliser la nouvelle division avec Python 2.6 :
python -Q new

ah, c'est une bonne nouvelle ça

gaby@kingkong:~$ python -Q new -m timeit 10/3     
1000000 loops, best of 3: 0.732 usec per loop
[19:36]
gaby@kingkong:~$ python -m timeit 10/float(3)
1000000 loops, best of 3: 1.68 usec per loop
[19:36]
gaby@kingkong:~$ python -m timeit 10/(3*1.0) 
1000000 loops, best of 3: 0.575 usec per loop
[19:36]
gaby@kingkong:~$

bon, c'est pas encore ça en 2.6, mais bon… (j'ai plus de charge sur le pc là)

Rolinh · Le 23/12/2010, à 20:42

En même temps, comme l'a bien fait remarqué ArkSeth:

ArkSeth a écrit :

C'est effectivement étrange et dommage que la version propre soit plus lente que l'autre, mais est-ce si grave ? J'veux dire, si on est vraiment au centième de seconde près, il vaut de toute façon mieux utiliser du C ou de l'assembleur que du Python, non ?

Mais bon, c'est quand même énorme l'écart!

tshirtman · Le 23/12/2010, à 21:46

on peut vouloir la facilité du python, et s'inquiéter tout de mêmes des perfs dans les fonctions les plus fréquemment appelées de son programme…

Elzen · Le 23/12/2010, à 23:15

tshirtman a écrit :

on peut vouloir la facilité du python, et s'inquiéter tout de mêmes des perfs dans les fonctions les plus fréquemment appelées de son programme…

Sans doute, mais une différence qui échappe à la perception humaine est-elle vraiment importante ? Parce que je sais pas vous, mais moi, un truc qui prends moins d'une seconde de plus qu'un autre, j'm'en rend pas compte (mais il est parfaitement possible que ma perception du temps soit aussi limitée que mes autres perceptions)

(Et j'aime pas être d'accord avec ESR, mais quand même : « votre temps de cerveau est plus précieux que le temps de la machine » (de mémoire et en très gros))

Kanor a écrit :

ArkSeth tu connais pdb quand même ?

Non plus.

Toineo a écrit :

ArkSeth, tu n'as vraiment jamais utilisé gdb ? Et un autre débogueur ? C'est juste super utile... (genre, quand tu tombes sur _le_ bug dont tu ne trouves _vraiment_ pas l'origine...)

Ni Valgrind, ni rien d'autre de ce genre.

Jusque là, chaque fois que j'ai eu un soucis de ce genre, j'ai réussi à en identifier la cause (et pour autant que j'me souvienne, à trouver une solution) tout seul, comme un grand (sauf pour les cas où j'ai demandé sur le forum, mais dans ce cas-là, vous séchiez aussi, apparemment )
Bon, mon expérience du C est quand même assez limitée, ça doit expliquer Mais que ce soit en Java, en Python, en JavaScript ou en PHP, qui sont les langages que j'utilise plus ou moins fréquemment, jamais eu de soucis.

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

grim7reaper · Le 23/12/2010, à 23:24

Disons que Valgrind c'est très utile pour vérifier si tu as fait du bon boulot (après, on peut prendre le parti de s'en foutre aussi ).
gdb ça permet juste de débugger plus vite qu'à la main (à condition de savoir s'en servir), mais c'est sûr que l'on peut faire sans (comme on peut coder avec blocnote, donc sans completion, sans coloration syntaxique, etc). C'est un juste outil, fort pratique si l'on prend la peine de le maîtriser, mais on peut très bien développer sans.

Elzen · Le 23/12/2010, à 23:46

T'sais, certains disent ça aussi des EDI ou, dans un autre registre, des traitements de textes… et puis j'suis désolé, mais quand tu codes écrits un roman, la coloration syntaxique, y en a bizarrement moins ^^

Je n'dis pas que ces trucs sont inutiles, loins de là, mais en ce qui me concerne et la plupart du temps, le meilleur outil (en terme de praticité comme d'efficacité) de vérification de code et de débuggage que j'connaisse, ça reste le machin gris qui encombre ma boîte crânienne

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#351 Le 23/12/2010, à 15:36

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

#352 Le 23/12/2010, à 15:53

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

#353 Le 23/12/2010, à 16:01

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

#354 Le 23/12/2010, à 16:03

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

#355 Le 23/12/2010, à 16:08

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

#356 Le 23/12/2010, à 16:10

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

#357 Le 23/12/2010, à 16:14

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

#358 Le 23/12/2010, à 16:20

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

#359 Le 23/12/2010, à 17:39

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

#360 Le 23/12/2010, à 17:42

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

#361 Le 23/12/2010, à 17:46

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

#362 Le 23/12/2010, à 18:25

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

#363 Le 23/12/2010, à 18:59

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

#364 Le 23/12/2010, à 19:07

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

#365 Le 23/12/2010, à 19:08

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

#366 Le 23/12/2010, à 19:09

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

#367 Le 23/12/2010, à 19:34

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

#368 Le 23/12/2010, à 20:02

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

#369 Le 23/12/2010, à 20:16

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

#370 Le 23/12/2010, à 20:37

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

#371 Le 23/12/2010, à 20:42

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

#372 Le 23/12/2010, à 21:46

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

#373 Le 23/12/2010, à 23:15

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

#374 Le 23/12/2010, à 23:24

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

#375 Le 23/12/2010, à 23:46

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

Pied de page des forums