Si tu me dis exactement ce que tu souhaites faire comme suite pour gérer les tests, je peux peut-être te le faire en Perl, c'est tout de même un langage bien adapté pour ça.
--
Jedaï
Version imprimable
Si tu me dis exactement ce que tu souhaites faire comme suite pour gérer les tests, je peux peut-être te le faire en Perl, c'est tout de même un langage bien adapté pour ça.
--
Jedaï
Perl oui super! (Python/shell/batch aussi)
Mais besoin de l' interpréteur qui n'est pas installé par défaut sous win.
L'avantage de faire la suite d' outils en C ANSI est sa portabilité, pour l'arbitre qui mesurera sur Win32. Pas forcémement moi. Et par extension on pourrait distribuer ces outils pour quiconque désire faire les tests sur sa propre machine.
Qu'en penses-tu?
Trois étapes distinctes:
La première étape (préparation) consiste, pour chaque fichier C du dossier à:
- extraire les infos, les formater et les ajouter à un fichier CSV,
- compiler le prog
- transformer le fichier source en fichier HTML (<- cet outil est prêt)
La deuxième étape (mesure): pour chaque entrée du CSV,
- identifier le nom de l' exécutable
- lancer et mesurer 100 fois, isoler le temps le +lent et le + rapide
- faire la moyenne des 100 et compléter la ligne du CSV en lui ajoutant |moyenne|+rapide|+lent|CPU|Mem
La troisième étape (présentation)(cet outil est prêt): transformer le CSV en HTML. A cet effet, parcourir le CSV pour:
- identifier les maximas et minimas qui apparaitront en vert ou en rouge dans le tableau final
- Formater les données CSV en cellule de table HTML
- Créer un graphique sous forme d' image jpg
Bon, ca y est pour le programme en C.Citation:
Envoyé par Lunixinclar
Par contre une chose m'a chagriné, c'est le commentaire //, tout le monde n'a pas de compilateur C99 aware, donc j'ai pris en compte le commentaire simple ligne C90 (enfin, la fin) (ca marche aussi avec // de toutes façons) :
/* Auteur:aaa */
/* Plateforme:bbb */
/* Compilateur/version:ccc/ddd */
A+
Il suffirait simplement de l'auteur non ?
Car si le programme est recompiler sur une plateforme X avec un compilateur X au final....
Non ?
Beau boulot Foobar1329.Citation:
Envoyé par Foobar1329
C'est noté pour les commentaires /* */.
Ca te dit d'ajouter une fonction qui lance un process sur GCC ou VC++ ? Si tu veux pas c'est pas grave 8-)
on ne sais toujours pas comment soumettre le code :aie:
-un commit sur un svn ... ce serait ptetre un peu du luxe (j'ai un repos SVN a la maison mais bon ... faut pas trop lui en demander) ... :oops:
-mettre des pieces jointes sur le forum ... c'est ptetre pas tres pratique pour l'organisateur.
-un acces ftp quelque part histoire de deposer nos sources, c'est ptetre la solution a court terme la plus envisageable.
alors? comment on fait?
Pour déposer les sources, le forum est bon, transparent: on sait qui a fait quoi et quand. Facile à télécharger ou à éditer. C'est mieux que par mail non?
Youpi. C'est tout bon. Un double-clic et tada! Le premier vrai test donne ... <traaaaadadadadraaa tambours> RESULTATS
Maintenant que la moulinette est terminée, je passe du temps à analyser vos codes, faut dire que ya des pros.
On peut accueillir 2000 participants à présent :mrgreen: Sans limite de temps oki?
C'est vraiment génial. Chapeau les gars.
Bonjour ! Je voulais justement participer mais c'est déja fini et j'ai pas DU TOUT le niveau !
Alors je demande svp a Dark Ebola de m'expliquer son code si il veut bien please !
merci d'avance a+
Ce n'est pas fini :)
On est la pour le fun ;)
Tente un truc !
haben c'etait juste pour dire que j'ai un deuxieme 'jet' (qui gere les a href et les img src), je pense pas l'ameliorer de si tot, donc je submit (et puis on avait dis une semaine :P).
-par contre, j'utilise dans cette nouvelle version un bit field (histoire de rentre le code un peu plus clair ...), je sais que ça peux poser des problemes de portabilité ... si jamais ça pose un probleme je peux arranger ça. (mais du coup c'est moins lisible)
sinon lapras, mon code est tres simple, je vais tacher de commenter la nouvelle version.
rapidement:
-la variable counter sert a compter les lettres dans un mot, la variable wcounter me permet de savoir quelle est la position du mot dans la balise.
-refs me permet de faire des comparaisons pour les chaines de char a reconnaitre
dans ma structure:
balise : compte le nombre de balises ouvertes
quote : etat "dans un commentaire" ou pas. (0 pas de commentaire, 1 commentaires)
type: permet d'identifier le type de balise: 0: type indeterminé 1: balise <IMG 2: balise <A
href: as-t'on reperé le chaine href? (0: non 1: oui)
src: as-t'on reperé la chaine src (0: non 1: oui)
print: doit on afficher le caractere courant? (0: non 1: oui)
avantage de ce code: fonctionne char par char, aucune limite liée a un buffer ou a la memoire.
inconveniant: peut etre long, traitement de chaque char individuellement, pas de "saut" a la prochaine balise possible
mon conseil: je debute en C (suis un etudiant passioné par l'informatique, pas un pro), attend de voir d'autres submissions comme celles de David.Schris
Oula ! Non, pas moi malheureux ! (faut pas vendre la peau de l'ours avant de l'avoir tué !)Citation:
Envoyé par Dark_Ebola
Bon avant que j'oublie, je poste mon code ;)
Par contre, un truc bizarre dans le constest, c'est qu'on suppose qu'on lance un exe pour parser chaque page....
Alors que dans un vrai moteur, seul la fonction parse serait appelée pour chaque page. Donc on pourrait optimiser niveau mémoire le tout. Et juste compter le temps réel de traitement de la page, sans inclure le temps d’allocation mémoire des divers éléments.
J’ai commenté StartQuantify() et StopQuantifyWindows() ainsi que l’affichage du nombre de liens.
Je pense pourvoir encore optimiser le tout, mais bon, cela serait de l’ordre du ridicule… je pense 1 ou 2 ms sur wblnks.html
[EDIT]
Limitation:
Ne tiens pas compte de balise "script"
Cas fonctionnel
Cas non fonctionnelCode:
2<A href="
[/EDIT]Code:
2
3
4
[EDIT2]
Ce n'est sûrement pas le plus propre des codes (toutes les erreurs ne sont pas gérées), mais je voulais quelque chose de rapide, avec quelque chose d'élégant (de mon point de vu, tout est relatif ;) ) via appel de fonction.
[/EDIT2]
Hello,
Citation:
Envoyé par Lunixinclar
Bouh, j'suis dernier !
:mouarf: :mouarf:
A+
J'ai légèrement modifié le code de mon parser (il y avait quelques erreurs graves...), il ne devrait plus louper grand chose désormais, et il ne devrait plus détecter les liens dans les scripts. (A vrai dire il y a encore des documents qu'il n'arrive pas bien à parser, par exemple avec des CDATA, mais il est déjà bien meilleur qu'il ne l'a été).
Par ailleurs ça serait bien également que les parsers donnent des résultats corrects sur un maximum de pages. Le plus simple ce serait d'utiliser un parser HTML bien établi pour générer une liste des liens correspondant à nos critères, trier les listes de liens des deux côtés (parce que les "vrais" parsers donnent parfois les liens dans l'ordre de fermeture des éléments) et faire un diff. C'est ce que je me suis fait pour tester chez moi, et ça permet de vite repérer les problèmes.
Je mets mon parser "officiel" Perl juste pour donner une idée (parce que je suppose que vous voudrez le refaire en C... ;) ) :
[EDIT] J'ai encore corrigé une erreur (du coup les CDATA passe un peu mieux, bien que ce soit juste de la récupération d'erreur...)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
--
Jedaï
J'ai essayé les derniers codes des participants sur un certain nombre d'exemples du "monde réel" (principalement ceux donnés par David.Schris), et les résultats sont assez divers. Le plus proche d'un sans faute est Foobar1329, mais il y a encore quelques petits problèmes. Ensuite vient Ti-R, pas très loin de Foobar1329. Puis Dark_Ebola, qui manque beaucoup plus de lien, entre autre sans doute parce qu'il se limite à une seule casse, qui n'est d'ailleurs probablement pas la plus répandue sur internet.
En résumé, il serait préférable que tous les parsers détectent à peu près la même quantité de liens avant qu'on compare leur vitesse parce que comparer la vitesse de deux logiciels ne faisant pas la même chose n'est pas très intéressant...
--
Jedaï
Je suis d'accord, mais Lunixinclar à posé des règles sur son concours :p
Faut lui demander....
Jedai si tu peux t'occuper de la validité des algos c'est super. Dès qu'un code est validé par toi je l'ajoute aux autres et relance les mesures.
Notez que plus la page de test est grande, plus les écarts se creusent entre les algos.
Alors c'est reparti pour la discussion sans fin:
Prendre en compte une multitude de cas va alourdir les algos, ils seront durs à comparer entre eux. C'est LePras qui veut écrire un bot. Nous on veut comparer des algos. Les mesures passent après. Sinon télécharger la source de Firefox ou Lynx copier/coller ce qui va bien et basta vive l' Open-Source!Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
La seule chose qu' impose le bon sens pour le défi est de repérer le <A HREF="url"> et rien d' autre. En majuscules et avec espaces entre le '=', et rien qu'avec des guillemets.
Pratique: c'est ce qu'exporte Firefox. Faites-moi passer pour un dictateur.
Si on ne réussit pas à s'accorder là-dessus, chacun va écrire son bot perso avec au final le néant commun, un tableau final assez vide, des temps de développement incroyables, des algos de 1000 lignes de code, des contraintes si dures que personne ne participera, et des mesures faussées.
Ca serait bien d'accorder nos violons assez rapidement pour faire une annonce dans un forum général. Une chose est sûre: les outils de mesure sont OK et ils sont portables.
Je suis pas d'accord avec les espaces.. je suis pas sur, mais meme les navigateurs super laxistent ne le blaireraient pas, c'est comme le coup du <(espace)a href.Citation:
Envoyé par Lunixinclar
Autant j'ai deja vu des <a href=url> autant j'ai jamais vu de <a href = url>
Moi j'ai déjà vu des <a href=\n"url"> ... Les navigateurs gèrent ça sans problème, et je ne suis même pas sûr que la norme l'interdise.Citation:
Envoyé par Gruik
Eh, c'est pas vrai, mon algo fais moins de 300 lignes de code et gère pratiquement tous les cas (j'ai pas encore réussi à le mettre en défaut, je parle de la dernière version bien sûr) !Citation:
Prendre en compte une multitude de cas va alourdir les algos, ils seront durs à comparer entre eux. C'est LePras qui veut écrire un bot. Nous on veut comparer des algos. Les mesures passent après. Sinon télécharger la source de Firefox ou Lynx copier/coller ce qui va bien et basta vive l' Open-Source!
La seule chose qu' impose le bon sens pour le défi est de repérer le <A HREF = "url"> et rien d' autre. En majuscules et avec espaces entre le '=', et rien qu'avec des guillemets.
Pratique: c'est ce qu'exporte Firefox. Faites-moi passer pour un dictateur.
Si on ne réussit pas à s'accorder là-dessus, chacun va écrire son bot perso avec au final le néant commun, un tableau final assez vide, des temps de développement incroyables, des algos de 1000 lignes de code, des contraintes si dures que personne ne participera, et des mesures faussées.
Bon je suis d'accord que ça risque de restreindre le nombre d'entrée si on oblige à prendre en compte trop de cas, mais on pourrait tout de même rajouter un bref descriptif des capacités de son parser, non ?
Je peux me charger de vérifier cela de mon côté (j'ai les scripts qu'il faut pour ça).:P
Et si je dis ça c'est pas juste parce que le parser de Ti-R nous atomise tous (2 fois plus rapide que le mien !), nonnon... :roll:
(Et pis c'est encore mieux si le parser est utilisable non ?)
--
Jedaï
Oui, mais j'ai bien précisé que mon parser était taillé pour la vitesse, spécialement pour le concours...
Il fera des débordements de mémoire sur des urls plus grande que 512.
Et comme précisé avant, les balises « script » sont inconnus au bataillon.... :aie: :mouarf:
Oui il cartonne. Erreur de compil "attention : array subscript has type `char'"
Mais ça marche avec -Wno-char-subscripts, une question de char signé je crois.
Tiens essayes celui-là :mouarf:
Bizarre aucun warning sous devcpp.....:?Citation:
Erreur de compil "attention : array subscript has type `char'"
Mais je pense que cela doit venir de
Oui c'est pas très propre :PCode:pt_functions[**_s]
Sympa ton code Lunixinclar, mais mettre les lettres en hexa, cela ne permet pas d'aller plus vite, et cela peut se révéler non portable.
En tout cas, c'est super court comme code :)
L'hexa c'est vraiment obligatoire ou c'est pour faire joli ? :mrgreen:Citation:
Envoyé par Lunixinclar
Si j'ai bien vu, quitte à comparer comme tu le fais, tu gagnerais probablement en rapidité en faisant une comparaison avec un uint64_t ou 2 uint32_t (une ou deux comparaisons au lieu de 7 ou 8 + comparaison d'entiers de 32 ou 64 bits au lieu de comparaisons, plus lentes, sur des char)...Enfin, c'est juste une idée...
devcpp ne doit pas compiler avec -Wall. De toute façon c'est vraiment acceptable comme construction à mon avis : ce n'est pas comme si utiliser un char comme indice risquait de provoquer des débordements en soi... :aie:Citation:
Envoyé par Ti-R
D'ailleurs ce n'est qu'un warning, pas une erreur.
Par ailleurs utiliser les valeurs hexa pour les lettres c'est presque de l'obfuscation... Le code est ultra-court, mais il faut dire qu'il s'en tient au minimum demandé ! En tout cas dans mes benchmark il est légèrement plus lent que celui de Ti-R (c'est infime).
--
Jedaï
Je viens d'essayer en modifiant son code pour que ça utilise deux uint32_t, mais ça l'a plutôt ralenti... Peut-être m'y suis-je mal pris.Citation:
Envoyé par David.Schris
--
Jedaï
J'avoue, l'idée m'est venue et je l'ai partagée sans vraiment y réfléchir avant, donc...ça vaut ce que ça vaut...Citation:
Envoyé par Jedai
Hypothèse : le ralentissement (ou le non-gain) est peut-être dû au fait que les données ne sont pas alignées...?...
Bonsoir,
Voilà, j'ai fait mon parser. Il supporte pas mal de cas de figures :
À part ça le code est assez laid, je prendrais le temps de le rendre plus lisible et de le fractionner un peu ...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Pour le fun j'ai fait une version de mon code en UINT32
Suivant l'idée de David.Schris
Bon l'inconvénient de la méthode, c'est que maintenant hReF ne passe plus, juste href et HREF et IMG= et img= :?
C'est juste pour le fun :mouarf: et il y a plein de jolie warning car c'est pas très propre ;)
Et j'ai mis une "contest_html_v0.2.c", qui empêche un buffer overflow si l'url fait plus de 1024, c'est juste le premier code corrigé, avec un changement de la taille du buffer pour le chargement des données.
[EDIT]
Dans la version fun, modifier
Sinon les images ne seront pas prise en compte... oups :aie:Code:
2
[/EDIT]
Il y a des failles dans ton code Lunixinclar
Si le dernier caractère des 8ko du début de la page est '=', que tu recharges le reste de ta page via fread et que tu tests ensuite avec n=0 -> buf[n-1] donc buf[-1] donc -> problème :)
Si b supérieur à 1023 -> problème aussi ;)
Je dois avoir aussi des erreurs et j’ai eu exactement les mêmes problèmes. :aie:
Bonjour,
J'ai modifié mon code pour supporté plus de cas et gagné quelques nanos par-ci, par-là.
Bon je poste une version speed... qui a les mêmes limitation que Lunixinclar
Pour le fun :)
Salut, :( ça compile plus :( :oops:
Ti-R-3.c:31: error: erreur de syntaxe before "uint32_t"
Ti-R-3.c: Dans la fonction « ParseLink »:
Ti-R-3.c:35: error: `_s' undeclared (first use in this function)
Ti-R-3.c:35: error: (Each undeclared identifier is reported only once
Ti-R-3.c:35: error: for each function it appears in.)
Ti-R-3.c:49: error: `_low_case_name' undeclared (first use in this function)
Ti-R-3.c:49: error: `uint32_t' undeclared (first use in this function)
Ti-R-3.c:49: error: erreur de syntaxe before ')' token
Ti-R-3.c:49: error: `_up_case_name' undeclared (first use in this function)
Tchetch oki http://2007.perso.orange.fr/resultats.htm
Ben il va falloir optimiser encore un peu tout ça ... (si jamais il compile sur Win32 si tu enlèves les redéfinitions de getc et putc (mais il sera plus lent))
Sinon ne serait-il pas intéressant de faire aussi un petit test sur les cas qui peuvent être traités par ces parsers ?
On fait une liste de liens des plus simples aux plus complexes et on compte combien le parser en trouve à la fin ...
Si si Lunixinclar met le minimum en option de compil :)
Sans passer les warning en errors.
Enlève -Wall
ps: J'ai remis à jour le fichier "contest_html_v0.3_speed.c" pour enlever des warnings et corriger 2 trucs.
Ta page HTML est super Tchetch. Pour un webbot.
- 8-) Et sinon t'as fait quoi cet été?
- :mrgreen: Bah j'ai fait la course aux micro-secondes c'est super excitant! :mrgreen:
:cry: Avec ou sans Wall veut pas comp :oops: :aie:
(fausse joie sur le 13ms joie désolé mon algo était foireux :mouarf: c'est corrigé)
Allez Ti-R faut que ça compile faut que tu repasses devant 8-)
:aie: Moi je compil le truc...
Je run cela fonctionne...
Sous DevCpp
Citation:
Compiler: Default compiler
Building Makefile: "C:\Dev\C-Cpp\DevCpp\projet\Makefile.win"
Executing make clean
rm -f main.o test_html.exe
gcc.exe -c main.c -o main.o -I"C:/Dev/C-Cpp/DevCpp/include" -fexpensive-optimizations -O3
gcc.exe main.o -o "test_html.exe" -L"C:/Dev/C-Cpp/DevCpp/lib" -s
Execution terminated
Compilation successful
essaye avec un tit batch pour voir
Si ça marche pas bienvenue dans les joies de la portabilité :aie: :mouarf:Code:
2
3
Le problème vient plutôt du fait que uint32_t n'est pas dans la même librairie sous Windows(Mingw) et sous Linux... Il suffit de remplacer uint32_t par unsigned int sur la plupart des plateformes (et nous ne cherchons pas à faire un parser pour l'embarqué, donc...). Un petit coup de sed et il n'y paraîtra plus.
(NB : dans mes benchs il n'est pas plus rapide que ton premier essai)
--
Jedaï
La v0.3 semble buggué, sur wblnks.html elle trouve plus de 10000 liens...
Donc faut laisser tomber...:?