/* Topic des codeurs [7] */

Elzen · Le 26/03/2012, à 00:00

tshirtman a écrit :

Par ce que en toute logique, quasiment personne de fait du vrai xhtml-qui-crash-à-la-moindre-faute (le doctype ne suffit pas). Et donc que ça ne sert pas a grand chose (surtout qu'en cas de crash le site est inutilisable, trop utile pour le mec qui le consulte quoi) donc on s'est rendu compte que c'était pus une vrai bonne idée. C'était le même type d'idée que de préférer le beshrell a Appolinaire.

D'un autre côté, si tu colles une erreur du genre de celles qui font crasher le moteur DOM dans un programme ou dans un document LaTeX, il ne compile pas, et en général on ne s'en plaint pas autant.
Alors certes, le code du programme ou du document LaTeX, on a tendance à le faire à la main, alors que le HTML on le fait souvent générer par autre chose, d'accord. Mais bon, est-ce que Inkscape fait des erreurs dans le SVG qui feraient crasher un lecteur XML ? Est-ce que n'importe quelle bibli qui produit du PDF fait des erreurs de ce genre ?

Qu'on fasse du HTML 5 non-XML ne me dérange pas outre mesure, mais justifier ça comme ça n'est à mon sens pas très pertinent : une bonne page est une page valide, de toute façon, et si le truc crashe quand on ne respecte pas la norme, c'est de notre faute, pas de celle de la norme.

Quant au « ça ne sert pas à grand chose » : ça sert à ce que le truc soit lisible par n'importe quelle bibliothèque de lecture du XML, ce qui n'est peut-être qu'un point de détail, mais un détail énorme. Tous les langages proposent par exemple une implémentation du DOM, et quand tu développes une appli qui va devoir lire plusieurs sortes de XML, c'est quand même sacrément mieux de ne pas avoir un truc complètement différent à faire quand tu vas devoir lire du HTML.

Tiens, un exemple tout bête et qui reste dans le navigateur : l'AJAX (dont le X est là pour XML, justement ^^).
Quand tu fais un chargement de page en arrière-plan (pour recharger, récupérer des infos, ou quoi que ce soit d'autres), si le serveur te renvoie une page valide XHTML, bah tu peux utiliser les méthodes DOM sur xhr.responseXML et récupérer ce qui t'intéresse facilement. Sinon, t'es obligé de te débrouiller avec xhr.responseText, soit toute la page comme une chaîne de caractère, et là, tu souffres.

Vu de ma fenêtre, donc, faire un document valide XHTML n'est pas plus compliqué, et par contre, ça peut te simplifier grandement la vie quand tu as besoin de faire d'autres choses avec. Donc je n'dis pas que je détiens la vérité absolue, mais quand même.

Dr Le Rouge · Le 26/03/2012, à 12:43

ArkSeth a écrit :

Donc je n'dis pas que je détiens la vérité absolue, mais quand même.

Que voilà un bon résumé d'une part non négligeable de tes posts

edit : soyons constructifs : google crée son propre langage.

Dernière modification par Dr Le Rouge (Le 26/03/2012, à 14:53)

Rolinh · Le 26/03/2012, à 17:02

Hop, pour toi Grim, le human-readable dans dfc

Elzen · Le 26/03/2012, à 17:08

Le Rouge a écrit :

ArkSeth a écrit :
Donc je n'dis pas que je détiens la vérité absolue, mais quand même.
Que voilà un bon résumé d'une part non négligeable de tes posts

Étant donné que le « mais quand même » signifiait ici à peu près « mais là pour le coup, j'estime quand même que ma position est suffisamment appuyée pour être un peu plus que seulement vaguement recevable », je n'suis pas sûr que ça puisse s'appliquer à tellement de mes posts, en fait ^^"

Kanor · Le 26/03/2012, à 17:22

Rolinh a écrit :

Hop, pour toi Grim, le human-readable dans dfc

Pas mal tu va remplacer df comme htop remplace top.
Je ne sais pas si c'est le but de ton programme mais est ce que ça ne devrait pas gérer aussi les disque lvm ?

Kanor · Le 26/03/2012, à 17:24

Le Rouge a écrit :

ArkSeth a écrit :
Donc je n'dis pas que je détiens la vérité absolue, mais quand même.
Que voilà un bon résumé d'une part non négligeable de tes posts http://smilies.xserver-x.org/smilies/me … llface.png
edit : soyons constructifs : google crée son propre langage.

euh Apparu en 11 novembre 2009

Rolinh · Le 26/03/2012, à 17:32

Kanor a écrit :

Pas mal tu va remplacer df comme htop remplace top.

Merci pour le compliment mais je pense qu'il y a encore du chemin à faire :-)

Kanor a écrit :

Je ne sais pas si c'est le but de ton programme mais est ce que ça ne devrait pas gérer aussi les disque lvm ?

A la base je l'ai écrit pour le fun afin de remplacer un script bash que je trouvais affreux. Pis finalement, j'y trouve toujours une option à ajouter ou un bug à corriger et comme je trouve ça fun je continue. :-)
Oui, ça devrait gérer les disques lvm normalement bien que je n'ai pas pu tester. Il y a un problème avec ça? Si oui, tu pourrais m'expliquer?

EDIT: ah ben tiens, faut que je m'occupe du lvmtab pour ça? Bon, faudra que j'apporte des changements alors.
EDIT2: en fait nan, je crois bien que c'est OK simplement en lisant le mtab donc ça devrait fonctionner.

Dernière modification par Rolinh (Le 26/03/2012, à 17:58)

Dr Le Rouge · Le 26/03/2012, à 17:35

Kanor a écrit :

euh Apparu en 11 novembre 2009

Mais j'en avais pas entendu parler

Rolinh · Le 26/03/2012, à 17:37

On en a parler sur ce topic même si mes souvenirs sont bons pourtant.

Pylades · Le 26/03/2012, à 17:41

Le Rouge, pose ce paquet de chiantos tout de suite… -_-'

Dr Le Rouge · Le 26/03/2012, à 17:42

Mais c'est trop bon

Jules Petibidon · Le 26/03/2012, à 18:30

Sinon dans les langages à Google, y'a aussi Dart dans ses tuyaux
http://www.dartlang.org/
Je sais pas trop si ça sert déjà à quelque chose.

Kanor · Le 26/03/2012, à 18:51

Sur mon systéme 100% lvm je me prend une erreur

kanor@babylone:~/Source/dfc-1.2.0$ ./dfc 
Error using statvfs on /proc/16855/net
with this error code : No such file or directory

Pas de probléme sur un autre ordi sans lvm

Dernière modification par Kanor (Le 26/03/2012, à 18:51)

Rolinh · Le 26/03/2012, à 19:02

Ah ouais tiens. Je pourrais voir le contenu de ton mtab histoire que je puisse essayer de comprendre d'où peut venir l'erreur?

Kanor · Le 26/03/2012, à 19:06

Voila mon petit mtab

/dev/mapper/babylone-root / ext4 rw,errors=remount-ro,commit=0 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
none /sys/kernel/debug debugfs rw 0 0
none /sys/kernel/security securityfs rw 0 0
udev /dev devtmpfs rw,mode=0755 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=0620 0 0
tmpfs /run tmpfs rw,noexec,nosuid,size=10%,mode=0755 0 0
none /run/lock tmpfs rw,noexec,nosuid,nodev,size=5242880 0 0
none /run/shm tmpfs rw,nosuid,nodev 0 0
cgroup /sys/fs/cgroup tmpfs rw 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu cgroup rw,relatime,cpu 0 0
cgroup /sys/fs/cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,relatime,blkio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,relatime,perf_event 0 0
/dev/sda1 /boot ext2 rw 0 0
/dev/mapper/babylone-lv_lxc /var/lib/lxc ext4 rw,commit=0 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,noexec,nosuid,nodev 0 0
/dev/sdb2 /media/f19f0267-105c-4126-98b0-d7f45203c079 ext4 rw,nosuid,nodev,uhelper=udisks 0 0
/dev/sdb1 /media/40f9678f-2430-4060-924f-0ea56cd09052 ext4 rw,nosuid,nodev,uhelper=udisks 0 0
/proc/16138/net /proc/16855/net none rw,bind 0 0
/dev/mapper/babylone-datas /datas ext4 rw 0 0

Au final c'est peut étre le cgroup qui fait planter le programme.

Dernière modification par Kanor (Le 26/03/2012, à 19:06)

grim7reaper · Le 26/03/2012, à 19:11

Rolinh a écrit :

Hop, pour toi Grim, le human-readable dans dfc

\o/
Au fait, tu as de nouvelles pistes pour ta différence avec df ?

Rolinh · Le 26/03/2012, à 19:13

Je ne pense pas que ce soit cgroup le problème puisque cela semble venir de ceci:

/proc/16138/net /proc/16855/net none rw,bind 0 0

Apparemment, il y a un soucis avec /proc/16855/net qu'il ne trouve pas.

Que donnes ceci?

ls -lh /proc/16855/net

Rolinh · Le 26/03/2012, à 19:15

grim7reaper a écrit :

Au fait, tu as de nouvelles pistes pour ta différence avec df ?

Non, pas vraiment. Tout ce que j'ai pu constaté c'est que di donne la même chose que dfc. Faudrait que j'investigue encore un peu.

Kanor · Le 26/03/2012, à 19:18

Ah oui tient j'avais pas vu cette ligne

kanor@babylone:~/Source/dfc-1.2.0$ ls -lh /proc/16855/net
ls: impossible d'accéder à /proc/16855/net: Aucun fichier ou dossier de ce type

étrange comme genre de montage.

Rolinh · Le 26/03/2012, à 19:27

Oui, c'est vraiment curieux.
Sans ça, dfc devrait fonctionner mais je pense que le soucis est chez toi pour le coup.

Kanor · Le 26/03/2012, à 19:58

ça marche mieux

Rolinh · Le 26/03/2012, à 20:32

Ok. Il y a encore des bugs?

tshirtman · Le 26/03/2012, à 21:12

ArkSeth a écrit :

D'un autre côté, si tu colles une erreur du genre de celles qui font crasher le moteur DOM dans un programme ou dans un document LaTeX, il ne compile pas, et en général on ne s'en plaint pas autant.

C'est vrai que les gens surfent sur des documents LaTeX tout le temps, ils trouvent ça trop fort que leur navigateur le compile a la volée pour leur afficher…

Alors certes, le code du programme ou du document LaTeX, on a tendance à le faire à la main, alors que le HTML on le fait souvent générer par autre chose, d'accord. Mais bon, est-ce que Inkscape fait des erreurs dans le SVG qui feraient crasher un lecteur XML ? Est-ce que n'importe quelle bibli qui produit du PDF fait des erreurs de ce genre ?

Et surtout en général tu distribue quoi? un pdf, que tu a compilé toi même, que tu a regardé le résultat et vérifié qu'il correspond à tes attentes, tu sais que le lecteur pdf ne crashera pas et fera de son mieux pour l'afficher, lui, il vomira pas une insulte au pauvre client si TON document ne respecte pas la norme… et au pire, si té génère du LaTeX, que tu compile a la volée avant d'envoyer le pdf au client, et que ça crashe, ça crashe sur ton serveur et tu es au courant, alors que si tu délivre un doc xhtml foireux, le client est le seul qui prend une erreur dans la gueule, et c'est difficile pour toi de le savoir… et lui, il voulait une info, et tu interdit a SON navigateur d'afficher l'info à cause de TON erreur? pour moi ça mérite juste des coups de battes dans les genoux, c'est le summum du gramar-nazisme-décomplexé-sauf-de-l'anus.

Toutes les libs xml ont des modes de récupération d'erreurs, par ce que le monde n'est pas parfait, sauf dans les rèves humides des fanacistes de comptoirs.

Qu'on fasse du HTML 5 non-XML ne me dérange pas outre mesure, mais justifier ça comme ça n'est à mon sens pas très pertinent : une bonne page est une page valide, de toute façon, et si le truc crashe quand on ne respecte pas la norme, c'est de notre faute, pas de celle de la norme.

Et quand on fais de son mieux pour faire un truc qui respecte la norme c'est pour que ce soit utile aux autres, quitte à ce que ça nous emmerde un peu, s'il n'y a pas mort d'homme en cas d'erreur, c'est pas la peine de dégommer le client de la crémière.

Quant au « ça ne sert pas à grand chose » : ça sert à ce que le truc soit lisible par n'importe quelle bibliothèque de lecture du XML, ce qui n'est peut-être qu'un point de détail, mais un détail énorme. Tous les langages proposent par exemple une implémentation du DOM, et quand tu développes une appli qui va devoir lire plusieurs sortes de XML, c'est quand même sacrément mieux de ne pas avoir un truc complètement différent à faire quand tu vas devoir lire du HTML.

Et le fait que la page crash préventivement, que tu ais besoin de l'api DOM ou pas n'apporte rien. si tu veux être au courant quand une page que TU sert (le seul cas utile donc), tu fais un controle coté serveur, et tu te remonte l'erreur, mais tu ne fait pas exploser la page dans la gueule du béotien qui passait par là, s'il trouve que la page est pas jolie, et que c'est grave, il te le diras, tu n'as pas besoin de l'emmerder préventivement pour le prévenir d'un moindre mal! immagine que tu va a un resto moule-fritte, t'as la dalle, et ils ont plus de moules, et qu'ils refusent catégoriquement de te servir quoi que ce soit tant qu'ils seront pas refourni en moules! T'es super content hein? ils t'on évité la tragédie de manger des frittes toutes seules! Tu reviendras jamais chez eux, pourtant, quel professionnalisme de leur part! Ils préfèrent te voir mourir de faim que de donner autre chose que le meilleurs qu'ils puissent faire!

Ben quand mes recherches me conduisent à une page xhtml qui plante, et qui parait-il (d'après $SEARCH_ENGINE ou un lien quelconque), contenait la précieuse info que je cherche, et que mon navigateur, stoïque, refuse de me donner l'info… j'ai des envie de meurtre au sécateur rouillé et émoussé.

Tiens, un exemple tout bête et qui reste dans le navigateur : l'AJAX (dont le X est là pour XML, justement ^^).
Quand tu fais un chargement de page en arrière-plan (pour recharger, récupérer des infos, ou quoi que ce soit d'autres), si le serveur te renvoie une page valide XHTML, bah tu peux utiliser les méthodes DOM sur xhr.responseXML et récupérer ce qui t'intéresse facilement. Sinon, t'es obligé de te débrouiller avec xhr.responseText, soit toute la page comme une chaîne de caractère, et là, tu souffres.

Your fucking problem!

Vu de ma fenêtre, donc, faire un document valide XHTML n'est pas plus compliqué, et par contre, ça peut te simplifier grandement la vie quand tu as besoin de faire d'autres choses avec. Donc je n'dis pas que je détiens la vérité absolue, mais quand même.

Et quand ça pète, je fais manger un chaton a un bébé phoque, de force, et j'y met le feu, OK?

Dernière modification par tshirtman (Le 26/03/2012, à 21:15)

Rolinh · Le 26/03/2012, à 23:11

Bon, j'étais motivé aujourd'hui...
Voici la version 2.0.0 de dfc (annonce)

Maintenant on a droit à un joli output en couleur et une nouvelle option qui permet de voir les mount flags.

The Uploader · Le 26/03/2012, à 23:16

Mis à jour du paquet AUR reçue.

(ça remplace déjà df -h chez moi, déjà rien que parce que je n'ai pas à aller à l'autre bout du clavier pour mettre un tiret d f et c sont tous côte à côte et en bas du clavier sur mon azerty)

edit : Nice les couleurs!

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#351 Le 26/03/2012, à 00:00

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

#352 Le 26/03/2012, à 12:43

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

#353 Le 26/03/2012, à 17:02

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

#354 Le 26/03/2012, à 17:08

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

#355 Le 26/03/2012, à 17:22

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

#356 Le 26/03/2012, à 17:24

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

#357 Le 26/03/2012, à 17:32

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

#358 Le 26/03/2012, à 17:35

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

#359 Le 26/03/2012, à 17:37

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

#360 Le 26/03/2012, à 17:41

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

#361 Le 26/03/2012, à 17:42

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

#362 Le 26/03/2012, à 18:30

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

#363 Le 26/03/2012, à 18:51

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

#364 Le 26/03/2012, à 19:02

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

#365 Le 26/03/2012, à 19:06

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

#366 Le 26/03/2012, à 19:11

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

#367 Le 26/03/2012, à 19:13

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

#368 Le 26/03/2012, à 19:15

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

#369 Le 26/03/2012, à 19:18

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

#370 Le 26/03/2012, à 19:27

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

#371 Le 26/03/2012, à 19:58

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

#372 Le 26/03/2012, à 20:32

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

#373 Le 26/03/2012, à 21:12

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

#374 Le 26/03/2012, à 23:11

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

#375 Le 26/03/2012, à 23:16

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

Pied de page des forums