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

Pylades · Le 04/02/2011, à 03:06

@grim7reaper : ne toutefois pas oublier que puts rajoute un '\n'…

@gnuuat : encore une fois, à part réduire la portabilité et rendre la lecture plus lourde (et un petit strlen ou sizeof dans ce cas précis ne serait pas de trop), ça apporte quoi, ta démarche ?
Tu peux aussi mettre tout ton code dans un asm("…");, à ce compte-là…

samυncle · Le 04/02/2011, à 03:11

.

Rolinh · Le 04/02/2011, à 04:06

grim7reaper · Le 04/02/2011, à 07:14

Pylade a écrit :

@grim7reaper : ne toutefois pas oublier que puts rajoute un '\n'…

Hum…
Et à ton avis pourquoi j'ai utilisé fputs au lieu de puts quand j'ai « corrigé » le code de :!pakman (le printf sans '\n') ?
Au hasard peut-être

Sinon, sur mon exemple avec string, on ne sait pas si elle contient ou pas un '\n' donc puts est aussi « correct » que fputs…

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

Compteur du TdCCT · Le 04/02/2011, à 07:42

Scores totaux, depuis le début :

1) 2486    nesthib
2) 2329    samuncle
3) 2006    Pylade
4) 1608    Кຼزດ
5) 1244+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1191    cm-t
7) 818    Р☢w ! ✰ :mad: ✰ (эй !)
8) 802    helly
9) 783    \\Ouranos//
10) 659    gnuuat
11) 538    Lagierl
12) 391    tshirtman
13) 214    Rolinh
14) 196    Askelon
15) 189    Kanor
16) 175    The Uploader
17) 172    nathéo
18) 121    ǤƦƯƝƬ
19) 93    petifrancais
20) 78    edge_one
20) 78    pierguiard
22) 74    kamui57
23) 70    gulp
24) 39    Le Rouge
25) 37    ilagas
26) 30    keny
27) 28    :!pakman
28) 25    GentooUser
28) 25    Morgiver
28) 25    xapantu
31) 24    ไ୦บเઢ'
31) 24    Steap
33) 20    CROWD
33) 20    d10g3n
35) 18    Ph3nix_
36) 15    timsy
37) 14    kouskous
38) 12    stratoboy
38) 12    sailing
38) 12    sakul
41) 11    alexises
41) 11    Crocoii
43) 10    Toineo
43) 10    NutMotion
43) 10    pseudovingtcinqcaracteres
43) 10    pfriedZ
43) 10    CasseTaTele
48) 9    gustare
49) 8    Mornagest
50) 7    Vista
51) 6    Zeibux
51) 6    ubuntlin
51) 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 ㋛
61) 3    Revan26914
62) 2    SoJaS
62) 2    ceric
64) 1    geenux

Répartition Posts/heure

Compteur du TdCCT · Le 04/02/2011, à 07:42

Scores de la période en cours :

1) 30    nesthib
2) 20    samuncle
3) 17    Кຼزດ
3) 17    Rolinh
5) 14    grim7reaper
6) 12    Pylade
7) 11    The Uploader
8) 10    cm-t
9) 9    gnuuat
10) 7    :!pakman
11) 4    Р☢w ! ✰ :mad: ✰ (эй !)

Pylades · Le 04/02/2011, à 13:36

grim7reaper a écrit :

Pylade a écrit :
@grim7reaper : ne toutefois pas oublier que puts rajoute un '\n'…
Hum…
Et à ton avis pourquoi j'ai utilisé fputs au lieu de puts quand j'ai « corrigé » le code de :!pakman (le printf sans '\n') ?
Au hasard peut-être

Ben non, je sais bien que tu sais ce que tu fais, la plupart du temps…

grim7reaper a écrit :

Sinon, sur mon exemple avec string, on ne sait pas si elle contient ou pas un '\n' donc puts est aussi « correct » que fputs…

Hum…

Si tu veux effacer ton message, j'effacerai celui-ci.

Elzen · Le 04/02/2011, à 14:02

Kupo les gens !

P'tite question pour les python-users : j'suis en train de faire un petit prog en ligne de commande qui a besoin qu'on lui entre un mot de passe.

J'arrive à récupérer l'entrer clavier sans problème avec sys.stdin.readline()[:-1] (bon, c'est pas du readline correct, genre les touches directionnelles marchent pas, mais ç'pour un mot de passe, donc c'est pas si grave). Ça marche bien, mais ce qui m'embête, c'est que le mot de passe s'affiche en clair sur la console, du coup.

Vous connaîtriez un moyen de faire comme pour la lecture de mots de passe des différentes commandes shell, ça prend bien l'entrée clavier, mais ça n'affiche rien (ou alors des étoiles, au pire) ?

tshirtman · Le 04/02/2011, à 14:11

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

:]

Elzen · Le 04/02/2011, à 14:14

Mais comment ça se fait que je tombe jamais sur la bonne page quand je cherche dans la doc ?

Merci

tshirtman · Le 04/02/2011, à 14:20

en fait, je connaissait pas, et je me suis dit "ah mais non, c'est la galère de faire un truc comme ça, on va encore dire que python c'est de la merde" alors j'ai googlé "python get password" ou un truc comme ça…

Elzen · Le 04/02/2011, à 14:31

Ah, ouais, avec seeks, j'ai recherché que « lire un mot de passe python » ou un truc du genre… toujours essayer en anglais aussi, les francophones n'ont pas tout essayé -_-

Bon, par contre, moins drôle : le script est sur mon serveur, quand je fais un ssh interactif et que je tape la commande manuellement, ça marche très bien, mais quand je fais directement ssh commande, ça me balance un

/usr/lib/python2.6/getpass.py:83: GetPassWarning: Can not control echo on the terminal.
  passwd = fallback_getpass(prompt, stream)
Warning: Password input may be echoed.

Et le password input est effectivement echoed

Pylades · Le 04/02/2011, à 15:06

Sinon, au lieu de t'emmerder avec un sys.stdin.readline()[:-1], tu peux tout simplement utiliser input, c'est plus, mieux intégré, et ça fonctionne comme avec Gnu Readline, donc on a les déplacements du curseur, les coupes et tout et tout.

Bon, c'est du Python 3 (normal, il n'y a que ça de vrai), mais je crois que raw_input de Python 2 fonctionne un peu pareil…

Elzen · Le 04/02/2011, à 15:24

En effet, ça a l'air plus simple que la fonction d'origine (raw_input en python 2, le input de python 2 faisant, d'après l'aide interne, un eval autour de raw_input)… néanmoins ça ne change strictement rien à mon problème

J'ai regardé dans les pages man de sh (qui redirige sur man bash ) et de ssh, mais ces histoires de terminal, ça n'a pas l'air évident à comprendre… Edit : il suffisait de rajouter l'option -t à ssh, apparemment ^^

Dernière modification par ArkSeth (Le 04/02/2011, à 17:10)

grim7reaper · Le 04/02/2011, à 17:07

Pylade a écrit :

grim7reaper a écrit :
Sinon, sur mon exemple avec string, on ne sait pas si elle contient ou pas un '\n' donc puts est aussi « correct » que fputs…
Hum…

Si tu veux effacer ton message, j'effacerai celui-ci.

Arf, le gros fail
Mea culpa, t'avais raison (ça m'apprendra à répondre alors que je viens de me lever…)
Je le laisse quand même, ça me servira de leçon

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

Pylades · Le 04/02/2011, à 17:49

@ArkSeth : oui, bien sûr, pour ton cas il faut utiliser le module getpass ; mais je disais ça parce que tu avais l'air de galérer avec ton sys.stdin.readline()[:-1]… ^^

Dernière modification par Pylade (Le 04/02/2011, à 17:49)

gnuuat · Le 04/02/2011, à 19:29

Pylade a écrit :

@gnuuat : encore une fois

Je persiste et je signe !

Pylade a écrit :

à part réduire la portabilité

Il n'y a rien de plus standart que ce que j'ai mis comme code...
Ce n'est pas comme si j'avais mis 1 à la place de STDOUT_FILENO

Pylade a écrit :

et rendre la lecture plus lourde

write : écrire
STDOUT_FILENO : numéro de fichier pour la sortie standard... Le file descriptor de la sortie standard quoi
phrase à afficher ;
taille

En quoi c'est lourd ? C'est carrément plus lisible que printf !

Pylade a écrit :

(et un petit strlen

C'est vrai

Pylade a écrit :

ou sizeof

Tu m'as pourtant reproché l'utilisation de sizeof pour l'utilisation de malloc dans ce cas précis...

Pylade a écrit :

ça apporte quoi, ta démarche ?

Juste pour montrer une autre façon de faire .

Pylade a écrit :

Tu peux aussi mettre tout ton code dans un asm("…");, à ce compte-là…

Non, ça c'est moche quand on fait du C.
Par contre en ASM... *miam*

edit : ceci est une parodie de débat \o/

Dernière modification par gnuuat (Le 04/02/2011, à 19:30)

Pylades · Le 04/02/2011, à 21:06

gnuuat a écrit :

Il n'y a rien de plus standart que ce que j'ai mis comme code...
Ce n'est pas comme si j'avais mis 1 à la place de STDOUT_FILENO

Mais ça n'est censé fonctionner que sur un système Posix ; le C standard, ça fonctionne presque partout.

gnuuat a écrit :

En quoi c'est lourd ? C'est carrément plus lisible que printf !

write ne peut pas être utilisée à la place de printf ; à la rigueur tu peux faire sprintf puis write, mais je ne vois pas trop l'intérêt…

gnuuat a écrit :

Tu m'as pourtant reproché l'utilisation de sizeof pour l'utilisation de malloc dans ce cas précis...

Où ça ?

gnuuat a écrit :

Pylade a écrit :
Tu peux aussi mettre tout ton code dans un asm("…");, à ce compte-là…
Non, ça c'est moche quand on fait du C.
Par contre en ASM... *miam*

Ben c'est un peu l'impression que ça donne, que tu veux faire exprès du bas niveau dans un langage de plus haut niveau. Ça fait un peu comme le mec qui voudrait coder un module kernel en Python…

gnuuat a écrit :

edit : ceci est une parodie de débat \o/

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

grim7reaper · Le 04/02/2011, à 22:13

Lecture du soir, bonsoir

Chris Okasaki. Purely Functional Data Structures. PhD thesis, School of Computer Science, Carnegie Mellon University, 1996. Tech report CMU-CS-96-177. a écrit :

Abstract
When a C programmer needs an efficient data structure for a particular prob-
lem, he or she can often simply look one up in any of a number of good text-
books or handbooks. Unfortunately, programmers in functional languages such
as Standard ML or Haskell do not have this luxury. Although some data struc-
tures designed for imperative languages such as C can be quite easily adapted to a
functional setting, most cannot, usually because they depend in crucial ways on as-
signments, which are disallowed, or at least discouraged, in functional languages.
To address this imbalance, we describe several techniques for designing functional
data structures, and numerous original data structures based on these techniques,
including multiple variations of lists, queues, double-ended queues, and heaps,
many supporting more exotic features such as random access or efficient catena-
tion.
In addition, we expose the fundamental role of lazy evaluation in amortized
functional data structures. Traditional methods of amortization break down when
old versions of a data structure, not just the most recent, are available for further
processing. This property is known as persistence, and is taken for granted in
functional languages. On the surface, persistence and amortization appear to be
incompatible, but we show how lazy evaluation can be used to resolve this conflict,
yielding amortized data structures that are efficient even when used persistently.
Turning this relationship between lazy evaluation and amortization around, the
notion of amortization also provides the first practical techniques for analyzing the
time requirements of non-trivial lazy programs.
Finally, our data structures offer numerous hints to programming language de-
signers, illustrating the utility of combining strict and lazy evaluation in a single
language, and providing non-trivial examples using polymorphic recursion and
higher-order, recursive modules.

(Bon je ne lirais pas tout ce soir, le papier fait quand même 162 pages, ptain j'ai aussi LDD à lire >_<)

Dernière modification par grim7reaper (Le 05/02/2011, à 01:16)

Кຼزດ · Le 05/02/2011, à 01:06

d

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

.

cm-t · Le 05/02/2011, à 01:31

'Nuit;

nesthib · Le 05/02/2011, à 03:00

plop

samυncle · Le 05/02/2011, à 03:06

helly · Le 05/02/2011, à 03:48

..........

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1751 Le 04/02/2011, à 03:06

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

#1752 Le 04/02/2011, à 03:11

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

#1753 Le 04/02/2011, à 04:06

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

#1754 Le 04/02/2011, à 07:14

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

#1755 Le 04/02/2011, à 07:42

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

#1756 Le 04/02/2011, à 07:42

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

#1757 Le 04/02/2011, à 13:36

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

#1758 Le 04/02/2011, à 14:02

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

#1759 Le 04/02/2011, à 14:11

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

#1760 Le 04/02/2011, à 14:14

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

#1761 Le 04/02/2011, à 14:20

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

#1762 Le 04/02/2011, à 14:31

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

#1763 Le 04/02/2011, à 15:06

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

#1764 Le 04/02/2011, à 15:24

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

#1765 Le 04/02/2011, à 17:07

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

#1766 Le 04/02/2011, à 17:49

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

#1767 Le 04/02/2011, à 19:29

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

#1768 Le 04/02/2011, à 21:06

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

#1769 Le 04/02/2011, à 22:13

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

#1770 Le 05/02/2011, à 01:06

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

#1771 Le 05/02/2011, à 01:08

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

#1772 Le 05/02/2011, à 01:31

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

#1773 Le 05/02/2011, à 03:00

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

#1774 Le 05/02/2011, à 03:06

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

#1775 Le 05/02/2011, à 03:48

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

Pied de page des forums