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

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

✰ ✰

kamui57 · Le 19/02/2011, à 01:15

grim7reaper a écrit :

Tremblez développeurs de peu de foi, Wokerm le terrible est de retour et son PowerShell nous montrera la voie

Oh oui le PowerShell va encore nous éblouir !

PS C:\TEMP> $b = Get-ChildItem monfichier.txt; $b.length

(trouvé sur le net, jsais pas coder en shell powerful moi)

PS U:\TDCCT> $h = Get-ChildItem date; $h.hour
00:11
PS U:\TDCCT>if ($h -lt 4) {"Ça y est on est demain \o/"}

PS : ce code n'est pas testé, je décline toute responsabilité en cas de crash de Wine

Sur ce, bonne nuit.

tshirtman · Le 19/02/2011, à 01:15

gaby@fofinho:~/ultimate-smash-friends$ python -m timeit -c '[ i for i in range(10000) if i%2 ]'
1000 loops, best of 3: 1.8 msec per loop
gaby@fofinho:~/ultimate-smash-friends$ python -m timeit -c 'filter(lambda x: x%2, range(10000))'
100 loops, best of 3: 2.7 msec per loop

bon, faut voir dans d'autres situations, mais je vois pas trop en quoi ça varierait énormément, apparemment "filter" est beaucoup plus lent que son équivalent en list comprehension…

grim7reaper · Le 19/02/2011, à 01:26

Python 2.7.1

grim7reaper@chaos ~]$python2 -m timeit -c '[ i for i in range(10000) if i%2 ]'  
100 loops, best of 3: 2.6 msec per loop
grim7reaper@chaos ~]$python2 -m timeit -c 'filter(lambda x: x%2, range(10000))' 
100 loops, best of 3: 4.3 msec per loop

Python 3.1.3

grim7reaper@chaos ~]$python -m timeit -c '[ i for i in range(10000) if i%2 ]' 
100 loops, best of 3: 3.8 msec per loop
grim7reaper@chaos ~]$python -m timeit -c 'filter(lambda x: x%2, range(10000))'
1000000 loops, best of 3: 1.23 usec per loop

Apparemment Python 3 change la donne.

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

Kanor · Le 19/02/2011, à 02:20

Ça me semblait louche et j'ai trouvé la cause de cette différence
filter en version 3 retourne un générateur à la différence de la version 2
donc en résumé

python -m timeit -c '[ i for i in range(10000) if i%2 ]'
1000 loops, best of 3: 1.74 msec per loop
python3 -m timeit -c '[ i for i in range(10000) if i%2 ]'
1000 loops, best of 3: 1.94 msec per loop

et

python -m timeit -c 'filter(lambda x: x%2, range(10000))' 
100 loops, best of 3: 2.6 msec per loop
python3 -m timeit -c 'list(filter(lambda x: x%2, range(10000)))'
100 loops, best of 3: 3.9 msec per loop

j'ai rajouté un list pour que le filter de la version 3 retourne aussi une liste.

edit un peu mieux dans les version 2 il faut mieux utiliser xrange

python -m timeit -c '[ i for i in xrange(10000) if i%2 ]'
1000 loops, best of 3: 1.55 msec per loop

Dernière modification par Kanor (Le 19/02/2011, à 02:25)

The Uploader · Le 19/02/2011, à 03:02

Bn;

Pylades · Le 19/02/2011, à 03:03

Hum… pub !

nesthib · Le 19/02/2011, à 04:03

plop

samυncle · Le 19/02/2011, à 04:09

nesthib a écrit :

plop

Кຼزດ · Le 19/02/2011, à 04:11

Hop.

cm-t · Le 19/02/2011, à 06:08

'Nuit;

Compteur du TdCCT · Le 19/02/2011, à 08:42

Scores totaux, depuis le début :

1) 2602    nesthib
2) 2461    samuncle
3) 2076    Pylade
4) 1686    Кຼزດ
5) 1358+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1255    cm-t
7) 888    Р☢w ! ✰ :mad: ✰ (эй !)
8) 826    helly
9) 783    \\Ouranos//
10) 659    gnuuat
11) 542    Lagierl
12) 422    tshirtman
13) 235    Rolinh
14) 225    The Uploader
15) 212    Kanor
16) 196    Askelon
17) 172    nathéo
18) 121    ǤƦƯƝƬ
19) 93    petifrancais
20) 82    kamui57
21) 78    edge_one
21) 78    pierguiard
23) 71    :!pakman
24) 70    gulp
25) 39    Le Rouge
26) 37    ilagas
27) 30    keny
28) 26    gustare
29) 25    GentooUser
29) 25    Morgiver
29) 25    xapantu
32) 24    ไ୦บเઢ'
32) 24    Steap
34) 20    CROWD
34) 20    d10g3n
36) 18    Ph3nix_
37) 15    timsy
38) 14    kouskous
39) 12    stratoboy
39) 12    sailing
39) 12    sakul
42) 11    alexises
42) 11    Crocoii
44) 10    Toineo
44) 10    NutMotion
44) 10    pseudovingtcinqcaracteres
44) 10    pfriedZ
44) 10    CasseTaTele
44) 10    Zeibux
50) 8    Mornagest
51) 7    Vista
52) 6    ubuntlin
52) 6    asma.geek
54) 5    tendances-tdct
54) 5    kinouchou
56) 4    danychou56
56) 4    Neros
56) 4    Biaise
56) 4    totoflute
56) 4    pinballyoda ㋛
56) 4    NLS le pingouin
62) 3    Revan26914
63) 2    SoJaS
63) 2    ceric
65) 1    geenux

Répartition Posts/heure

Compteur du TdCCT · Le 19/02/2011, à 08:42

Scores de la période en cours :

1) 152    samuncle
2) 146    nesthib
3) 128    grim7reaper
4) 95    Кຼزດ
5) 82    Pylade
6) 74    Р☢w ! ✰ :mad: ✰ (эй !)
6) 74    cm-t
8) 61    The Uploader
9) 50    :!pakman
10) 38    Rolinh
11) 31    tshirtman
12) 24    helly
13) 23    Kanor
14) 17    gustare
15) 9    gnuuat
16) 8    kamui57
17) 4    NLS le pingouin
17) 4    Lagierl
17) 4    Zeibux

tshirtman · Le 19/02/2011, à 14:53

@kanor et grim: oui, j'avais googlé un peu là dessus après, et j'étais tombé sur un post explicatif sur stackoverflow, dans ce genre de cas il faut en effet bien faire gaffe à la construction de l'instruction, ça peut vraiment jouer sur les perfs…

grim7reaper · Le 19/02/2011, à 17:26

Aujourd'hui j'ai découvert l'existence des Knights of the Lambda Calculus ^^

Rolinh · Le 19/02/2011, à 17:30

Avant d'aller faire une recherche, je me doutais bien que c'était un truc en rapport à Lisp/scheme ^^

EDIT: j'adore

Dernière modification par Rolinh (Le 19/02/2011, à 17:31)

grim7reaper · Le 19/02/2011, à 17:45

Forcément, avec un nom pareil c'était évident

Dernière modification par grim7reaper (Le 20/02/2011, à 04:02)

Pylades · Le 19/02/2011, à 20:22

Tiens, j'ai un peu bossé sur Libstropt, aujourd'hui. Je vais peut-être faire un commit. Bon, pour le moment c'est surtout de la forme, mais je vais faire un peu de fond : positionner errno. Normalement, un malloc qui n'échoue pas les fonctions de string.h laissent errno intacte, non ?

grim7reaper · Le 19/02/2011, à 21:17

Pylade a écrit :

Normalement, un malloc qui n'échoue pas […] laissent errno intacte, non ?

Une fonction peut modifier errno, même en cas de succès.
C'est bien précisé dans la norme

ISO/IEC 9899:TC3 a écrit :

7.5 Errors <errno.h>
[…]
The value of errnois zero at program startup, but is never set to zero by any library
function. The value of errno may be set to nonzero by a library function call
whether or not there is an error, provided the use of errno is not documented in the
description of the function in this International Standard.
[…]

Le man va dans le même sens

man 3 errno a écrit :

The <errno.h> header file defines the integer variable errno, which is set by system calls and some library functions in the event of an error to indicate what went wrong. Its value is significant only when the return value of the call indicated an error (i.e., -1 from most system calls; -1 or NULL from most library functions); a function that succeeds is allowed to change errno.
Valid error numbers are all nonzero; errno is never set to zero by any system call or library function.

Cela dit, tu n'as pas besoin de positionner errno avant un malloc.
Il suffit de tester son retour et si c'est NULL alors tu peux utiliser errno.
Le positionnement d'errno est utile pour des fonctions comme strtol vu que tu utilise sa valeur pour vérifier un dépassement de capacité (tu ne sais pas si la fonction a vraiment echouée au moment où tu testes).

Pylade a écrit :

les fonctions de string.h laissent errno intacte, non ?

Je ne crois pas que les fonctions de string.h (du moins celles que j'utilisent couramment), positionnent errno, mais en cas de doute il faut consulter le man.

Dernière modification par grim7reaper (Le 19/02/2011, à 21:34)

Pylades · Le 20/02/2011, à 01:59

Bon, ça ne m'arrange pas, cette affaire…

Tant pis, je ferai ma propre variable globale d'erreur.

Sinon, j'avais oublié de le dire, mais maintenant aucune des lignes de mon code ne dépasse les 72 caractères (sauf dans les headers et la notice).

Dernière modification par Pylade (Le 20/02/2011, à 01:59)

cm-t · Le 20/02/2011, à 02:02

'Nuit;

Pylades · Le 20/02/2011, à 02:14

Enfin, bon, j'attends de voir ta réponse demain, pour la variable globale.

grim7reaper · Le 20/02/2011, à 02:16

Pylade a écrit :

Bon, ça ne m'arrange pas, cette affaire…

Pourquoi ?
Tu veux faire quoi en fait ?

Pour la globale faut voir : je pense que ça risque de causer des problèmes (pour la réentrance et le multithread).

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH, qu'est ce que c'est moche comme terme !
Je vais continuer à dire thread-safe…

Dernière modification par grim7reaper (Le 20/02/2011, à 02:28)

Pylades · Le 20/02/2011, à 02:29

Je voudrais permettre de réaliser de nombreux appels aux fonctions de l'interface pour paramétrer les Option sans s'occuper de la valeur de retour, et pouvoir tester à la fin une fois pour toutes s'il y a eu échec.

Parce que

int fail = 0;
fail |= appel1();
fail |= appel2();
…
fail |= appel42();
if (fail)
{
  die("Ça a merdé…\n");
}

ça fait un peu lourdingue…

Donc passer par errno aurai pu être intéressant, mais on peut toujours créer sa propre globale, de toute façon cette bibliothèque n'a pas vocation à être utilisée en multi-threading…

Sinon, quelqu'un connaîtrait-il un endroit où l'on peut voir les règles par défaut de Make ; ainsi que le contenu des variables un peu spéciales, telles CFLAGS, lorsqu'elles ne sont pas affectées explicitement ?

Tiens, tu m'as grillé en éditant… pas grave, je n'ai quand même rien à ajouter.

Dernière modification par Pylade (Le 20/02/2011, à 02:30)

grim7reaper · Le 20/02/2011, à 02:38

Pylade a écrit :

int fail = 0;
fail |= appel1();
fail |= appel2();
…
fail |= appel42();
if (fail)
{
  die("Ça a merdé…\n");
}

ça fait un peu lourdingue…

Je ne trouve pas ça particulièrement moche (au pire tu peux mettre += au lieu de |= pour pas choquer les novices ), ça me semble une façon correcte de procéder.
Sinon, tu pourrais mettre un flag de validité dans la structure elle-même.

Pylade a écrit :

Donc passer par errno aurai pu être intéressant, mais on peut toujours créer sa propre globale, de toute façon cette bibliothèque n'a pas vocation à être utilisée en multi-threading…

Je trouve toujours ça un peu moche de limiter l'usage qu'il pourra être fait d'une bibliothèque, ça peut poser des problèmes aux utilisateurs après. Mais c'est vrai que dans ton cas je vois mal faire du parsage de ligne de commandes en utilisant des thread (mais bon, on sait jamais ^^)

Pylade a écrit :

Sinon, quelqu'un connaîtrait-il un endroit où l'on peut voir les règles par défaut de Make ; ainsi que le contenu des variables un peu spéciales, telles CFLAGS, lorsqu'elles ne sont pas affectées explicitement ?

Je crois que pour les règles c'est ici (de toute façon ça doit être dans cette section). Pour les variables c'est là.

Dernière modification par grim7reaper (Le 20/02/2011, à 02:44)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2151 Le 19/02/2011, à 01:02

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

#2152 Le 19/02/2011, à 01:15

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

#2153 Le 19/02/2011, à 01:15

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

#2154 Le 19/02/2011, à 01:26

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

#2155 Le 19/02/2011, à 02:20

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

#2156 Le 19/02/2011, à 03:02

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

#2157 Le 19/02/2011, à 03:03

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

#2158 Le 19/02/2011, à 04:03

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

#2159 Le 19/02/2011, à 04:09

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

#2160 Le 19/02/2011, à 04:11

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

#2161 Le 19/02/2011, à 06:08

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

#2162 Le 19/02/2011, à 08:42

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

#2163 Le 19/02/2011, à 08:42

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

#2164 Le 19/02/2011, à 14:53

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

#2165 Le 19/02/2011, à 17:26

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

#2166 Le 19/02/2011, à 17:30

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

#2167 Le 19/02/2011, à 17:45

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

#2168 Le 19/02/2011, à 20:22

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

#2169 Le 19/02/2011, à 21:17

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

#2170 Le 20/02/2011, à 01:59

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

#2171 Le 20/02/2011, à 02:02

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

#2172 Le 20/02/2011, à 02:14

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

#2173 Le 20/02/2011, à 02:16

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

#2174 Le 20/02/2011, à 02:29

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

#2175 Le 20/02/2011, à 02:38

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

Pied de page des forums