/* Topic des codeurs [6] */

Pylades · Le 18/09/2011, à 21:53

~/clfb (master)$ make CC=clang
clang -std=c90 -pedantic -Wall -Wextra -Winit-self -Wfloat-equal -Wstrict-prototypes -Wold-style-definition -Wredundant-decls -Wwrite-strings -Wcast-qual -Wconversion -Wbad-function-cast -Wformat=2 -march=native -O2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include     -c -o clfb.o clfb.c
In file included from clfb.c:21:
In file included from ./clfb.h:28:
In file included from /usr/include/errno.h:36:
In file included from /usr/include/bits/errno.h:25:
/usr/include/linux/errno.h:4:10: fatal error: 'asm/errno.h' file not found
#include <asm/errno.h>
         ^
1 error generated.
make: *** [clfb.o] Erreur 1

Clang ne supporte-t-il donc pas errno ? Faut-il ajuster CPATH ?

Hey, mais c’est dans /usr/include/x86_64-linux-gnu/, en fait. Comment se fait-il qu’il ne cherche pas dedans ?

Dernière modification par Πυλάδης (Le 18/09/2011, à 21:59)

The Uploader · Le 18/09/2011, à 23:03

grim7reaper a écrit :

Allez, le vieux préjugé à la con du libriste => ça ressemble à Windows c’est de la merde (comme KDE) -____-"
Sinon il y a aussi MINIX 3, Plan9 (le truc dont wmii reprend des bouts), FreeVMS (un peu jeune => qemu), MonaOS (jeune aussi, faut utilise qemu), O3ONE (attention les yeux >_<), HelenOS, Genode, House (Hum, du Haskell , cela dit il ne semble plus très à jour donc vaut peut-être mieux regarder du côté de Lighthouse)) et Syllable

AROS (version Broadway surtout). Libre. Et très exotique. Et c'est de l'Amiga pour x86! \o/

Plante dans VirtualBox, pas testé dans QEMU

vidéo(s) youtube AROS Broadway : http://www.youtube.com/watch?v=085wL6Rj8GY

Bon y'a aussi MorphOS et AmigaOS 4. Mais c'est pour PPC et pas libre.

grim7reaper · Le 19/09/2011, à 05:25

Πυλάδης a écrit :

Clang ne supporte-t-il donc pas errno ?

clang fonctionne très bien.
chezmoiçamarche…

J’ai pris pour exemple un ensemble de fichier qui inclus ça (il y a donc errno dans le lot, plus des trucs systèmes) :

#include <arpa/inet.h>
#include <errno.h>
#include <getopt.h>
#include <limits.h>
#include <math.h>
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>
#include "utils.h"

Dernière modification par grim7reaper (Le 19/09/2011, à 05:26)

tshirtman · Le 19/09/2011, à 10:28

pas tout à fait du code, mais une histoire sympatique :]
http://www.ibiblio.org/harris/500milemail.html

Ras' · Le 19/09/2011, à 10:39

kamui57 a écrit :

Ras' : réuploader http://kamui57.toile-libre.org/reuploadpic/
bon le code est pas encore commenté tout ça, alors il est pas encore dispo

Han !
Strou cool
Tu gères trop

helly · Le 19/09/2011, à 10:53

tshirtman a écrit :

pas tout à fait du code, mais une histoire sympatique :]
http://www.ibiblio.org/harris/500milemail.html

Marrant !
Mais en effet, sur le coup, tu dois te demander ce qu’il se passe !

tshirtman · Le 19/09/2011, à 11:17

C'est marrant que l'analyse statistique du truc, aussi bizarre que paraisse le résultat, ait été juste et utile (contrairement à la plupart des tentative d'analyse des utilisateurs ^^)

Pylades · Le 19/09/2011, à 12:59

Bon, encore une fois, c’est la faute d’Ubuntu…

Clang fonction très bien avec Arch. D’ailleurs j’en ai profité pour passer à Linux 3.

helly · Le 19/09/2011, à 13:19

Hey Pylade (ou autre).
En C, c’est mieux d’utiliser return EXIT_SUCCESS plutôt que return 0 non ?

Pylades · Le 19/09/2011, à 13:31

Je t’ai répondu (et la réponse est « non »).

helly · Le 19/09/2011, à 15:01

.

Pylades · Le 19/09/2011, à 15:57

Hey, quand on met Terminus, comme fonte dans la console, pourquoi choisir ter-v16b ? Ça veut dire quoi, v16b (j’ai su mais j’ai oublié) ?

grim7reaper · Le 19/09/2011, à 16:42

helly a écrit :

Hey Pylade (ou autre).
En C, c’est mieux d’utiliser return EXIT_SUCCESS plutôt que return 0 non ?

En théorie, EXIT_SUCCESS c’est mieux.
En pratique, jusqu’à aujourd’hui je n’ai vu aucune différence avec « return 0; ».
Déjà, il me semble (flemme de vérifier) que POSIX impose EXIT_SUCCESS == 0 donc ça ne change rien pour tout les OS qui respectent POSIX. Pour ce qui est du reste, jusqu’à maintenant je n’ai jamais entendu parler d’un système qui renvoie autre chose que zéro pour dire « OK tout va bien ».
Donc d’un point de vue pratique y’en a pas un meilleur, mais d’un point de vue théorique EXIT_SUCCESS est meilleur.

Personnellement, en général, j’utilise EXIT_SUCCESS.

Pylades · Le 19/09/2011, à 17:04

Ben EXIT_SUCCESS c’est pour quand tu veux faire un test portable ailleurs que sous POSIX, en gros. Sinon, t’es assez grand pour choisir tes codes de retour toi-même…

grim7reaper · Le 19/09/2011, à 17:12

Πυλάδης a écrit :

Sinon, t’es assez grand pour choisir tes codes de retour toi-même…

Oui et non, ton programme ne tourne pas tout seul.
L’OS (ou un script shell) peut interpréter ton code de retour et si l’OS considère que le code OK c’est 42 tu pourras bien décider autant que tu veux que c’est 0 le code OK bah l’OS considérera que si tu renvoies 0 c’est que t’as eu une merde et tu ne seras pas plus avancé.

Je parle là de retour de main(), c’est sûr que dans tes fonctions et ta mécanique interne tu définis tes codes de retour comme tu l’entends.

Dernière modification par grim7reaper (Le 19/09/2011, à 17:12)

Pylades · Le 19/09/2011, à 17:18

Si ton code de retour n’a pas vocation à être utilisé comme valeur de vérité, tu peu renvoyer ce que tu veux…

Et puis n’avoir droit qu’à deux codes de retour, c’est trop limité, je trouve. Donc je return 0; épicétouq !

Elzen · Le 19/09/2011, à 17:20

Πυλάδης a écrit :

Et puis n’avoir droit qu’à deux codes de retour, c’est trop limité, je trouve. Donc je return 0; épicétouq !

Deux codes de retour, c'est trop limité, alors tu n'en utilises qu'un ?

grim7reaper · Le 19/09/2011, à 17:22

Πυλάδης a écrit :

Si ton code de retour n’a pas vocation à être utilisé comme valeur de vérité, tu peu renvoyer ce que tu veux…

Non, encore une fois tu ne décides pas ce que fais l’OS.
Imagine un système qui gère une grille de calcul et qui loggue tout les programmes qui fail (pour les relancer, advertir l’admin, que-sais-je), bah si tu veux faire ton original tu vas foutre la merde.

Πυλάδης a écrit :

Et puis n’avoir droit qu’à deux codes de retour, c’est trop limité, je trouve.

Tu n’as pas que deux codes de retour, tu en as un pour OK et tous les autres pour décrire tes différentes erreurs.

Πυλάδης a écrit :

Donc je return 0; épicétouq !

Nan mais tu fais ce que tu veux, mon but n’est pas te faire changer d’avis (surtout qu’en pratique les deux se valent). Je dis juste qu’en théorie EXIT_SUCCESS est mieux, en pratique tu fais bien ce que tu veux.

Dernière modification par grim7reaper (Le 19/09/2011, à 17:24)

Pylades · Le 19/09/2011, à 17:34

ArkSeth a écrit :

Deux codes de retour, c'est trop limité, alors tu n'en utilises qu'un ?

J’en utilise plutôt quatre, en fait. Mais quand le programme se termine sur une erreur, c’est plutôt dû à un appel à exit.

grim7reaper a écrit :

Non, encore une fois tu ne décides pas ce que fais l’OS.
Imagine un système qui gère une grille de calcul et qui loggue tout les programmes qui fail (pour les relancer, advertir l’admin, que-sais-je), bah si tu veux faire ton original tu vas foutre la merde.

O_o'

grim7reaper a écrit :

Tu n’as pas que deux codes de retour, tu en as un pour OK et tous les autres pour décrire tes différentes erreurs.

Ben comment tu sais qu’un tel code n’est pas EXIT_SUCCESS ? On ne te fournit que EXIT_SUCCESS et EXIT_FAILURE…
Avec des #if ? On s’emmerde pour un résultat assez léger…

grim7reaper · Le 19/09/2011, à 17:49

Πυλάδης a écrit :

grim7reaper a écrit :
Non, encore une fois tu ne décides pas ce que fais l’OS.
Imagine un système qui gère une grille de calcul et qui loggue tout les programmes qui fail (pour les relancer, advertir l’admin, que-sais-je), bah si tu veux faire ton original tu vas foutre la merde.
O_o'

Développe.

Πυλάδης a écrit :

grim7reaper a écrit :
Tu n’as pas que deux codes de retour, tu en as un pour OK et tous les autres pour décrire tes différentes erreurs.
Ben comment tu sais qu’un tel code n’est pas EXIT_SUCCESS ?

En regardant la valeur d’EXIT_SUCCESS dans les sources

Πυλάδης a écrit :

On ne te fournit que EXIT_SUCCESS et EXIT_FAILURE…

Bah si tu veux un code absolument portable, même d’un point de vue purement théorique, bah oui tu es limité à deux codes.
La portabilité apporte toujours son lot de contrainte.

Πυλάδης a écrit :

On s’emmerde pour un résultat assez léger…

Je suis bien d’accord, vu qu’à l’heure actuelle ça n’apporte qu’une portabilité absolue d’un point de vue théorique.
Pour l’avoir en pratique ta méthode suffit.

Pylades · Le 19/09/2011, à 18:33

grim7reaper a écrit :

Développe.

Je trouve juste ça dingue…

Πυλάδης a écrit :

En regardant la valeur d’EXIT_SUCCESS dans les sources .

C’est une blague, hein ?

grim7reaper · Le 19/09/2011, à 18:40

Πυλάδης a écrit :

grim7reaper a écrit :
Développe.
Je trouve juste ça dingue…

Je ne vois pas en quoi.
Quand tu balances une tétrachiée de soft sur une grille c’est légitime de savoir lesquels ont foirés (je dis pas que c’est fait de cette manière, c’est un moyen parmi d’autre).

Πυλάδης a écrit :

grim7reaper a écrit :
En regardant la valeur d’EXIT_SUCCESS dans les sources .
C’est une blague, hein ?

À ton avis ?
(indice : le smiley à la fin de la phrase).

HP · Le 19/09/2011, à 20:21

J'aurais une ou deux questions à propos de ruby…
quelqu'un sait si il y a un équivalent à :

if __name__ == '__main__':

à part çà, quelqu'un sait si il existe des fonctions similaires à celles du module subprocess de python, à savoir qui pourraient recevoir une commande sous la forme de tableau/liste et en protéger les arguments avec des quotes si nécessaire…

grim7reaper · Le 19/09/2011, à 20:31

Tiens HP, tant que tu es là j’ai une question sur Emacs (vu que tu sembles le seul Emacs-user de ce topic).
J’ai remarqué que j’avais un rendu différent (i.e niveau couleur de la coloration syntaxique) en fonction du terminal que j’utilise (enfin en fonction de la valeur de la variable TERM en fait).
Le truc c’est que j’aime bien le rendu quand TERM vaut xterm mais j’utilise urxvt.
Pour le moment, je fais un truc bâtard (je positionne TERM à la main) mais je me doute qu’on doit pouvoir faire mieux.
Alors voilà ma question : ce rendu dépends de quelle(s) variable(s) ?

Une fois que je sais ça, je pourrais récupérer leurs valeurs, voire les adapter à mon goût. J’ai bien tenté un « C-h C-a color » mais à priori ça ne m’a rien renvoyé d’utile…

HP a écrit :

quelqu'un sait si il y a un équivalent à :
if __name__ == '__main__':

Apparemment oui.

Dernière modification par grim7reaper (Le 19/09/2011, à 20:37)

HP · Le 19/09/2011, à 20:37

grim7reaper a écrit :

Tiens HP, tant que tu es là j’ai une question sur Emacs (vu que tu sembles le seul Emacs-user de ce topic).
J’ai remarqué que j’avais un rendu différent (i.e niveau couleur de la coloration syntaxique) en fonction du terminal que j’utilise (enfin en fonction de la valeur de la variable TERM en fait).
Le truc c’est que j’aime bien le rendu quand TERM vaut xterm mais j’utilise urxvt.

Perso, j'utilise : TERM=screen-256color
C'est défini dans mon bashrc…
Après, faudrait savoir ce que tu utilises comme mode pour le terminal de emacs, parce que il y a le choix… j'utilise aussi urxvt .
Sinon, je sais pas si tu as vu, mais quand tu es dans le ansi-term de emacs tu as çà :

EMACS=24.0.50.8 (term:0.96)
INSIDE_EMACS=24.0.50.8,term:0.96

Ça pourrait être utile si tu veux modifier la valeur de TERM spécifiquement pour emacs.

Bon, pour le __main__ de ruby, je vais voir, et je reviens…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#251 Le 18/09/2011, à 21:53

Re : /* Topic des codeurs [6] */

#252 Le 18/09/2011, à 23:03

Re : /* Topic des codeurs [6] */

#253 Le 19/09/2011, à 05:25

Re : /* Topic des codeurs [6] */

#254 Le 19/09/2011, à 10:28

Re : /* Topic des codeurs [6] */

#255 Le 19/09/2011, à 10:39

Re : /* Topic des codeurs [6] */

#256 Le 19/09/2011, à 10:53

Re : /* Topic des codeurs [6] */

#257 Le 19/09/2011, à 11:17

Re : /* Topic des codeurs [6] */

#258 Le 19/09/2011, à 12:59

Re : /* Topic des codeurs [6] */

#259 Le 19/09/2011, à 13:19

Re : /* Topic des codeurs [6] */

#260 Le 19/09/2011, à 13:31

Re : /* Topic des codeurs [6] */

#261 Le 19/09/2011, à 15:01

Re : /* Topic des codeurs [6] */

#262 Le 19/09/2011, à 15:57

Re : /* Topic des codeurs [6] */

#263 Le 19/09/2011, à 16:42

Re : /* Topic des codeurs [6] */

#264 Le 19/09/2011, à 17:04

Re : /* Topic des codeurs [6] */

#265 Le 19/09/2011, à 17:12

Re : /* Topic des codeurs [6] */

#266 Le 19/09/2011, à 17:18

Re : /* Topic des codeurs [6] */

#267 Le 19/09/2011, à 17:20

Re : /* Topic des codeurs [6] */

#268 Le 19/09/2011, à 17:22

Re : /* Topic des codeurs [6] */

#269 Le 19/09/2011, à 17:34

Re : /* Topic des codeurs [6] */

#270 Le 19/09/2011, à 17:49

Re : /* Topic des codeurs [6] */

#271 Le 19/09/2011, à 18:33

Re : /* Topic des codeurs [6] */

#272 Le 19/09/2011, à 18:40

Re : /* Topic des codeurs [6] */

#273 Le 19/09/2011, à 20:21

Re : /* Topic des codeurs [6] */

#274 Le 19/09/2011, à 20:31

Re : /* Topic des codeurs [6] */

#275 Le 19/09/2011, à 20:37

Re : /* Topic des codeurs [6] */

Pied de page des forums