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

tshirtman · Le 17/05/2011, à 17:38

Ben c'est indiqué dans le commentaire du hello.c comment le compiler

Pylades · Le 17/05/2011, à 17:42

Ah ouais, tiens, je n’avais pas remarqué le hello.c… ^^

tshirtman · Le 17/05/2011, à 20:52

tu diras quand t'as le temps pour les explications sur les guillemets

Rolinh · Le 17/05/2011, à 20:57

tshirtman a écrit :

tu diras quand t'as le temps pour les explications sur les guillemets

++

The Uploader · Le 17/05/2011, à 21:08

Le xfwm4-tiling fonctionne, c'est sympa pour comparer des bouts de code, par exemple. ^^

Rolinh · Le 17/05/2011, à 21:11

The Uploader a écrit :

Le xfwm4-tiling fonctionne, c'est sympa pour comparer des bouts de code, par exemple. ^^

Quand je ne suis pas sur AwesomeWM, j'apprécie.

Pylades · Le 17/05/2011, à 21:36

tshirtman a écrit :

peut tu me dire pourquoi les doubles quotes seraient mal, au fait?
la différence entre les simples et doubles quotes étant à ma connaissance la résolution des noms de variables...

Ben, le but des simple quotes, c’est de délimiter une chaîne qui sera transférée telle quelle à la commande. Et ça, c’est exactement ce que l’on souhaite. Les doubles quotes, c’est pour délimiter un motif qui sera soumis à interprétation avant d’être transmis à la commande. Et se lancer dans l’interprétation d’une regex avant de la passer, c’est suicidaire…
L’interprétation comporte échappement (rien que ça, ça devrait déjà dissuader), expansion des paramètres et variables, substitution de commande, expansion arithmétique (alors que t’as des $ qui peuvent traîner dans les regex, c’est encore moins engageant), expansion de l’historique, et peut-être découpage de mots (jamais rien compris à ce bidule).
Ça veut dire qu’avec les double quotes, t’es obligé de faire très gaffe à ce que tu fais, avec toujours la possibilité de faire des erreurs. Il est même impossible de mettre un simple ! dans une chaîne délimité par double quotes. En plus, c’est incorrect sémantiquement, quand on fait des regex.

Mais la solution à ces problèmes est simple : utiliser les simple quotes. Ils ne sont pas là pour faire joli, et devraient même être utilisés plus souvent que leurs collègues, dans une utilisation courante d’un shell. Moi je ne me casse pas la tête ; je le leur fais confiance et je suis tranquille…
Et donc, avec les regex, c’est toujours les simple quotes.

The Uploader · Le 17/05/2011, à 22:56

Bon... eXtended Module Player lui non plus n'est pas à jour niveau APIs d'audacious (ça compile pas sous forme de plugin, et yaourt ne me met que la version standalone), pourtant le paquet existe bien pour Ubuntu, y compris natty : http://packages.ubuntu.com/fr/natty/xmp-audacious
Patch Debian/Ubuntu downstream ? Le mystère s'épaissit.. ;/

Ou alors c'est moi qui bug...

Mais c'est déjà mieux qu'Unix Amiga Delitracker Emulator qui ne compile même pas en stand-alone, même si xmp a l'air bien plus limité dans le nombre de trackers supportés qu'uade..

edit : un autre plugin pour .MODs et dérivés existe : DUMB (même situation que pour xmp).

... C'est la pagaille en fait! >_<

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

tshirtman · Le 17/05/2011, à 23:21

Pylade a écrit :

Ben, le but des simple quotes, c’est de délimiter une chaîne qui sera transférée telle quelle à la commande. Et ça, c’est exactement ce que l’on souhaite. Les doubles quotes, c’est pour délimiter un motif qui sera soumis à interprétation avant d’être transmis à la commande. Et se lancer dans l’interprétation d’une regex avant de la passer, c’est suicidaire…
L’interprétation comporte échappement (rien que ça, ça devrait déjà dissuader), expansion des paramètres et variables, substitution de commande, expansion arithmétique (alors que t’as des $ qui peuvent traîner dans les regex, c’est encore moins engageant), expansion de l’historique, et peut-être découpage de mots (jamais rien compris à ce bidule).
Ça veut dire qu’avec les double quotes, t’es obligé de faire très gaffe à ce que tu fais, avec toujours la possibilité de faire des erreurs. Il est même impossible de mettre un simple ! dans une chaîne délimité par double quotes. En plus, c’est incorrect sémantiquement, quand on fait des regex.
Mais la solution à ces problèmes est simple : utiliser les simple quotes. Ils ne sont pas là pour faire joli, et devraient même être utilisés plus souvent que leurs collègues, dans une utilisation courante d’un shell. Moi je ne me casse pas la tête ; je le leur fais confiance et je suis tranquille…
Et donc, avec les regex, c’est toujours les simple quotes.

hum, ok, donc c'est pas franchement prudent, mais rien n'indique que ce ne soit jamais ce qu'on veux, ou inoffensif la plupart du temps… Ce n'est pas interdit, ni faux, faut juste savoir le sens des symboles qu'on utilise en bash, et les échapper si besoin…

@The Uploader: si des patchs sont appliqués, normalement tu les trouves dans le dossier debian/patches du packet source debian.

Dernière modification par tshirtman (Le 17/05/2011, à 23:23)

The Uploader · Le 17/05/2011, à 23:37

ok merci, je verrai ça.

En fait, un paquet dumb-audacious existe aussi. Seul le plugin audacious d'uade n'existe pas en tant que paquet pour Ubuntu (et ça a l'air justement le plus complet, enfin disons un peu plus que la libdumb sur laquelle se base dumb et sa version plugin. J'aimerai pas plusieurs plugins qui se marchent sur les pieds : ça risque de planter..).

Mais ça avance! \o/

PS : pour tester tout ça un bon gros dossier de ziks 'chips' s'impose :

http://zakalwe.fi/uade/download.html a écrit :

RSYNC/git server for Amiga chip songs
A public rsync server for various Amiga chip songs (over 8000 files or about 300 MiBs of data):
$ rsync -avz zakalwe.fi::chip /local/path/
rsync does easy and fast updates for the collection. rsync only transfers new or changed bits. Therefore bandwidth is not wasted, and updates are fast.
Alternatively, you can use git for syncing the collection:
$ git clone git://zakalwe.fi/chip
And after the first clone, you can do incremental updates just by running:
$ cd chip
$ git pull

bonne nuit ^^

Dernière modification par The Uploader (Le 17/05/2011, à 23:38)

Rolinh · Le 17/05/2011, à 23:42

@Pylade: merci pour l'explication. Cependant, je pense comme tshirtman, je ne pense pas qu'il faille diaboliser pour autant.
Pis de toute façon, bash c'est un langage de shell interactif (enfin, c'est vraiment relatif à côté de zsh^^), pas vraiment un truc à faire des scripts vu les performances...

Кຼزດ · Le 18/05/2011, à 01:08

hop

cm-t · Le 18/05/2011, à 01:09

chocolat kanor
&&
'Nuit;

Sir Na Kraïou · Le 18/05/2011, à 01:38

,

Pylades · Le 18/05/2011, à 02:30

tshirtman a écrit :

[…]
hum, ok, donc c'est pas franchement prudent, mais rien n'indique que ce ne soit jamais ce qu'on veux, ou inoffensif la plupart du temps… Ce n'est pas interdit, ni faux, faut juste savoir le sens des symboles qu'on utilise en bash, et les échapper si besoin…
[…]

Ben disons que t’as intérêt à faire vachement gaffe avec les double quotes si tu ne veux pas te planter, que ça alourdit la syntaxe, que sémantiquement c’est plus que limite et qu’il n’est même pas possible de mettre un simple bang. Alors qu’à côté t’as les simple quotes qui sont faits pour ça et qui sont simple. Dans cas, en t’accordant avec la loi de Murphy, tu t’arranges pour ne jamais utiliser la première solution ; et toujours la deuxième. C’est aussi simple que ça.

Sans diaboliser, tu utilises l’outil approprié à la tâche. On ne code pas d’OS en javascript. On ne devrait pas mettre de double quotes à une regex.

nesthib · Le 18/05/2011, à 03:24

plop

Pylades · Le 18/05/2011, à 03:54

Bon, c’est prouvé, on code carrément mieux la nuit. En revanche la doc de la GLib est mal foutue, ça commence à être lourd. Où puis-je trouve de la documentation sérieuse sur g_file_get_contents ? C’est dit où ce que je dois faire avec le retour de g_file_info_get_content_type, un fois utilisé (je pense que ça doit pointer vers quelque chose qui est détruit avec le GFileInfo associé, mais ça serait cool que ça soit bien expliqué).

Enfin bref, la doc cryptique ça commence à me les briser, menu…

Compteur du TdCCT · Le 18/05/2011, à 07:42

Scores totaux, depuis le début :

1) 3276    nesthib
2) 2996    samuncle
3) 2703    Pylade
4) 2077    Кຼزດ
5) 1690+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1600    cm-t
7) 1220    na kraïou
8) 866    helly
9) 858    \\Ouranos//
10) 659    gnuuat
11) 565    Lagierl
12) 562    tshirtman
13) 381    Rolinh
14) 324    The Uploader
15) 288    nathéo
16) 249    Kanor
17) 196    Askelon
18) 160    :!pakman
19) 121    ǤƦƯƝƬ
20) 93    petifrancais
21) 91    kamui57
22) 78    edge_one
22) 78    pierguiard
24) 70    gulp
25) 42    sakul
26) 39    Le Rouge
27) 37    ilagas
28) 33    xapantu
29) 30    keny
30) 26    gustare
30) 26    d10g3n
32) 25    GentooUser
32) 25    Morgiver
34) 24    ไ୦บเઢ'
34) 24    Steap
36) 20    CROWD
37) 18    Ph3nix_
38) 16    kouskous
39) 15    timsy
40) 12    stratoboy
40) 12    sailing
42) 11    alexises
42) 11    Crocoii
44) 10    Toineo
44) 10    NutMotion
44) 10    pseudovingtcinqcaracteres
44) 10    pfriedZ
44) 10    CasseTaTele
44) 10    Zeibux
44) 10    THS`
51) 8    Mornagest
52) 7    Vista
53) 6    ubuntlin
53) 6    asma.geek
55) 5    tendances-tdct
55) 5    kinouchou
57) 4    danychou56
57) 4    Neros
57) 4    Biaise
57) 4    totoflute
57) 4    pinballyoda ㋛
57) 4    NLS le pingouin
57) 4    ceric
57) 4    Dice-Man
65) 3    Revan26914
65) 3    raspouillas
65) 3    sweetly
68) 2    SoJaS
69) 1    geenux
69) 1    ArzhurBZH

Répartition Posts/heure

Compteur du TdCCT · Le 18/05/2011, à 07:42

Scores de la période en cours :

1) 170    Pylade
2) 106    nesthib
3) 90    na kraïou
4) 67    samuncle
5) 64    Кຼزດ
6) 58    cm-t
7) 40    nathéo
8) 27    Rolinh
9) 25    tshirtman
10) 24    The Uploader
11) 18    Kanor
12) 15    :!pakman
12) 15    grim7reaper
14) 10    sakul
14) 10    THS`
16) 8    helly
17) 6    Lagierl
18) 4    \\Ouranos//
19) 1    ArzhurBZH

Rolinh · Le 18/05/2011, à 09:55

@Pylade:

Glib Reference Manual a écrit :

g_file_get_contents
#define g_file_get_contents
Reads an entire file into allocated memory, with good error checking.
If the call was successful, it returns TRUE and sets contents to the file contents and length to the length of the file contents in bytes. The string stored in contents will be nul-terminated, so for text files you can pass NULL for the length argument. If the call was not successful, it returns FALSE and sets error. The error domain is G_FILE_ERROR. Possible error codes are those in the GFileError enumeration. In the error case, contents is set to NULL and length is set to zero.
Returns :
TRUE on success, FALSE if an error occurred

GIO Reference Manual a écrit :

g_file_info_get_content_type ()
const char * g_file_info_get_content_type (GFileInfo *info);
Gets the file's content type.
info :
a GFileInfo.
Returns :
a string containing the file's content type.

Il y a quelque chose qui te manque?

Pylades · Le 18/05/2011, à 15:28

Ben ouais, il manque la description des arguments (enfin, le prototype au moins), ce que l’on doit faire en cas d’erreur, et les destructeurs à appliquer dans la premier cas ; et les destructeurs à appliquer dans le second cas. Sans ça, c’est un poil difficile de coder proprement…

Rolinh · Le 18/05/2011, à 15:43

Nan mais GTK + code propre c'est un truc à oublier...

(enfin, c'est à la conclusion à laquelle je suis arrivée...)

Pylades · Le 18/05/2011, à 15:49

Mais je veux être propre. En plus, je n’utilise pas GTK+, mais juste GIO.

Ce qui est marrant c’est qu’ici ils répètent des évidences pendant trois plombes, en insistant bien sur le fait que la doc doit être propre ; mais qu’à côté c’est du n’importe quoi. Je préfère quand même cette doc trop verbeuse, au moins rien n’est laissé de côté et il y a des exemples de code. Ils ne pourraient pas faire pareil sur les autres pages ?

C’est quand même pas croyable qu’il n’y ait pas de doc valable sur un truc aussi utilisé…

Dernière modification par Pylade (Le 18/05/2011, à 15:50)

xapantu · Le 18/05/2011, à 16:14

@Pylade : le prototype :

gboolean
g_file_get_contents (const gchar  *filename,
                     gchar       **contents,
                     gsize        *length,
                     GError      **error)

Dernière modification par xapantu (Le 18/05/2011, à 16:15)

Pylades · Le 18/05/2011, à 16:25

Merci ! \o/

Bon, c’est déjà ça, même si ça ne parle pas des destructeurs. T’as trouvé ça où ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2001 Le 17/05/2011, à 17:38

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

#2002 Le 17/05/2011, à 17:42

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

#2003 Le 17/05/2011, à 20:52

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

#2004 Le 17/05/2011, à 20:57

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

#2005 Le 17/05/2011, à 21:08

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

#2006 Le 17/05/2011, à 21:11

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

#2007 Le 17/05/2011, à 21:36

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

#2008 Le 17/05/2011, à 22:56

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

#2009 Le 17/05/2011, à 23:21

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

#2010 Le 17/05/2011, à 23:37

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

#2011 Le 17/05/2011, à 23:42

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

#2012 Le 18/05/2011, à 01:08

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

#2013 Le 18/05/2011, à 01:09

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

#2014 Le 18/05/2011, à 01:38

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

#2015 Le 18/05/2011, à 02:30

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

#2016 Le 18/05/2011, à 03:24

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

#2017 Le 18/05/2011, à 03:54

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

#2018 Le 18/05/2011, à 07:42

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

#2019 Le 18/05/2011, à 07:42

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

#2020 Le 18/05/2011, à 09:55

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

#2021 Le 18/05/2011, à 15:28

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

#2022 Le 18/05/2011, à 15:43

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

#2023 Le 18/05/2011, à 15:49

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

#2024 Le 18/05/2011, à 16:14

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

#2025 Le 18/05/2011, à 16:25

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

Pied de page des forums