#1076 Le 12/04/2013, à 18:13
- Rolinh
Re : /* Topic des codeurs [8] */
Je pense que ça aurait été plus judicieux de sortir d’autres formats au fur et à mesure, tout en gardant le support des anciens bien entendu.
Il y aurait eu certes plus de format, mais avec une complexité bien moindre. Et tant que tout les formats était supportés par l’utilisateur, ça aurait été transparent.
Le problème avec ça c'est qu'une version plus ancienne ne peut pas lire le format d'une version plus récente, ce qui implique une frustration de l'utilisateur de l'ancienne version. Déjà que la plupart des gens ont du mal à comprendre ce que sont les différents formats de fichier existants...
Hors ligne
#1077 Le 12/04/2013, à 18:16
- grim7reaper
Re : /* Topic des codeurs [8] */
C’est à double tranchant, l’avantage de « pousser » les utilisateurs à mettre à jour leur version (bien que là, étant un logiciel payant, c’est un peu chien de les pousser à évoluer) c’est que ça évite des trucs à le IE6 dont on a mis des années à se débarrasser (et je suis sûr qu’on a pas tout à fait terminer d’ailleurs…)
Hors ligne
#1078 Le 13/04/2013, à 08:21
- grim7reaper
Re : /* Topic des codeurs [8] */
Bon, depuis le FNV j’ai encore ajouté quelques algo :
/usr/bin/ruby1.9.1 -Ilib benchmark/bench.rb
FILE: benchmark/data/french.txt, LINES: 66010 , SIZE: 3.2 Mo
user system total real
djb2: 1.980000 0.000000 1.980000 ( 1.983007)
fnv1a_32: 6.060000 0.000000 6.060000 ( 6.073050)
fnv1a_64: 6.640000 0.000000 6.640000 ( 6.641833)
fnv1a_128: 7.310000 0.000000 7.310000 ( 7.313298)
fnv1a_256: 9.160000 0.010000 9.170000 ( 9.186536)
fnv1a_512: 13.780000 0.080000 13.860000 ( 13.874728)
fnv1a_1024: 22.970000 0.420000 23.390000 ( 23.410724)
super_fast_hash: 2.280000 0.000000 2.280000 ( 2.277807)
FILE: benchmark/data/chinese.txt, LINES: 21287 , SIZE: 1.8 Mo
user system total real
djb2: 1.210000 0.000000 1.210000 ( 1.213825)
fnv1a_32: 3.010000 0.000000 3.010000 ( 3.006826)
fnv1a_64: 3.290000 0.000000 3.290000 ( 3.289716)
fnv1a_128: 4.310000 0.000000 4.310000 ( 4.321252)
fnv1a_256: 5.950000 0.000000 5.950000 ( 5.950651)
fnv1a_512: 9.340000 0.000000 9.340000 ( 9.351028)
fnv1a_1024: 15.920000 0.000000 15.920000 ( 15.938454)
super_fast_hash: 1.100000 0.000000 1.100000 ( 1.100742)
FILE: benchmark/data/english.txt, LINES: 23031 , SIZE: 1.2 Mo
user system total real
djb2: 0.580000 0.000000 0.580000 ( 0.585222)
fnv1a_32: 1.990000 0.000000 1.990000 ( 1.987019)
fnv1a_64: 2.100000 0.000000 2.100000 ( 2.105138)
fnv1a_128: 2.320000 0.000000 2.320000 ( 2.320350)
fnv1a_256: 2.970000 0.000000 2.970000 ( 2.973979)
fnv1a_512: 4.270000 0.000000 4.270000 ( 4.277295)
fnv1a_1024: 6.970000 0.000000 6.970000 ( 6.977142)
super_fast_hash: 0.690000 0.000000 0.690000 ( 0.686896)
Bon sachant que c’est une version en pur Ruby et que j’ai vraiment codé à la naïf (i.e j’ai déjà une idée de modification très simple qui va me donner un boost x3 à x6 niveau vitesse, mais je l’implémenterais plus tard).
Édit : le script de bench :
#encoding: utf-8
require 'benchmark'
require 'fasthash'
Dir.glob('benchmark/data/*.txt') do |filename|
data = File.readlines(filename, encoding: 'UTF-8')
nb_lines = data.length
size = (File.size(filename) / (1000*1000.0)).round(1)
puts("FILE: #{filename}, LINES: #{nb_lines} , SIZE: #{size} Mo")
Benchmark.bm(15) do |x|
FastHash.singleton_methods.each do |hash|
x.report(hash.to_s + ':') { data.each { |l| FastHash.send(hash, l)} }
end
end
puts()
end
Dernière modification par grim7reaper (Le 13/04/2013, à 08:23)
Hors ligne
#1079 Le 14/04/2013, à 00:00
- tshirtman
Re : /* Topic des codeurs [8] */
Allez, un petit bout de code : implémentation de la fonction de hachage de Fowler–Noll–Vo (c’est une petite partie de ce qui va sûrement devenir mon prochain projet en Ruby), pour chaque taille supportée.
Utilisation de métaprog’ pour éviter la répétition de codemodule FastHash FNV_32_INIT = 2166136261 FNV_64_INIT = 14695981039346656037 FNV_128_INIT = 144066263297769815596495629667062367629 FNV_256_INIT = 100029257958052580907070968620625704837092796014241193945225284501741471925557 FNV_512_INIT = 9659303129496669498009435400716310466090418745672637896108374329434462657994582932197716438449813051892206539805784495328239340083876191928701583869517785 FNV_1024_INIT = 14197795064947621068722070641403218320880622795441933960878474914617582723252296732303717722150864096521202355549365628174669108571814760471015076148029755969804077320157692458563003215304957150157403644460363550505412711285966361610267868082893823963790439336411086884584107735010676915 FNV_32_PRIME = 16777619 FNV_64_PRIME = 1099511628211 FNV_128_PRIME = 309485009821345068724781371 FNV_256_PRIME = 374144419156711147060143317175368453031918731002211 FNV_512_PRIME = 35835915874844867368919076489095108449946327955754392558399825615420669938882575126094039892345713852759 FNV_1024_PRIME = 5016456510113118655434598811035278955030765345404790744303017523831112055108147451509157692220295382716162651878526895249385292291816524375083746691371804094271873160484737966720260389217684476157468082573 MASK_32 = 0xFFFFFFFF MASK_64 = 0xFFFFFFFFFFFFFFFF MASK_128 = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MASK_256 = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MASK_512 = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MASK_1024 = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Je ne comprends pas bien pourquoi tu met des valeurs aussi grande dans le code, et non pas la façon de les obtenir, si les premiers sont des nombres de Mersenne, par exemple, pourquoi ne pas donner leur formule? Pour les masques, c'est encore plus simple, 2 ** n - 1, ce serait plus clair je pense.
# Generates the different flavours (32, 64, 128, 256, 512 and 1024 bits) of # the FNV hashing algorithm. [32, 64, 128, 256, 512, 1024].each do |bit| # FNV1. define_singleton_method "fnv1_#{bit}".to_s do |key| hash = const_get("FNV_#{bit}_INIT") key.unpack('C'*key.length).each do |byte| hash *= const_get("FNV_#{bit}_PRIME") hash ^= byte end hash & const_get("MASK_#{bit}") end # FNV1a. define_singleton_method "fnv1a_#{bit}".to_s do |key| hash = const_get("FNV_#{bit}_INIT") key.unpack('C'*key.length).each do |byte| hash ^= byte hash *= const_get("FNV_#{bit}_PRIME") end hash & const_get("MASK_#{bit}") end end end
Vive Ruby
Certes, c'est cool, mais pas mal de magie, non? quand il suffirait d'un partial avec le premier paramètre passé dedans, (en pour l'avoir dans l'espace de nom en python, je l'ajouterais dans locals, mais j'aurais tendance à considérer ça comme de la magie noire.
Édit : petit exemple de sortie
[1] pry(main)> require 'fnv' => true [2] pry(main)> FastHash.fnv1_32("Hello World!").to_s(16) => "12a9a41c" [3] pry(main)> FastHash.fnv1a_32("Hello World!").to_s(16) => "b1ea4872" [4] pry(main)> FastHash.fnv1_64("Hello World!").to_s(16) => "8e59dd02f68c387c" [5] pry(main)> FastHash.fnv1a_64("Hello World!").to_s(16) => "8c0ec8d1fb9e6e32"
Bravo quand même
Sinon, ce vendredi/samedi, j'ai encadré un hackathon kivy dans une école, les étudiants étaient aussi débutants en python qu'en kivy, et ils n'avaient que 24h pour réaliser leur idée, donc c'était assez sport (et ils étaient tout mort à la fin ^^), mais ils s'en sont quand même pas trop mal sortis, avec la quantité de concepts qu'ils avaient besoin d'ingurgiter et d'utiliser dans ce temps. Les gagnants on fait un jeu scrolling 2d, ou il faut éviter des obstactes, avec une idée rigolote, puisque ça s'appel "boutin run", et que les obstacles sont des CRS, des grandes folles, et des femens (on perds toujours à la fin), bien rigolo, et le jeu marchait très bien en fin de compet', ce que je considère comme assez impressionnant (même si oui, ils ont eu des coups de mains). Les autres ont fait des applications plus classiques, et avaient des interfaces plus ou moins fonctionnelles, mais pas grand chose derrière (certaines étaient bien léchés en terme de présentation quand même, c'est assez plaisant à voir). Bien sympa .
Hors ligne
#1080 Le 14/04/2013, à 05:30
- grim7reaper
Re : /* Topic des codeurs [8] */
Je ne comprends pas bien pourquoi tu met des valeurs aussi grande dans le code, et non pas la façon de les obtenir, si les premiers sont des nombres de Mersenne, par exemple, pourquoi ne pas donner leur formule? Pour les masques, c'est encore plus simple, 2 ** n - 1, ce serait plus clair je pense.
Tout simplement parce que pour certaines, je n’ai aucune idée d’où elles sortent et comment elle sont calculées ^^'
Mais ouais, pour les masques et les nombre premiers j’ai passé en mode formule, par contre pour les valeurs d’init’ j’ai seulement réécrit en notation hexa (je peux pas faire plus court, aucune info à leur sujet).
Certes, c'est cool, mais pas mal de magie, non?
Non, pas du tout.
De la métaprog’ de base utilisé dans un cas d’école : éviter le code boilerplate. On peut pas vraiment appeler ça de la magie là, je ne fais pas de trucs alambiqués genre modification ou génération de code pendant l’exécution.
Je fais simplement en sorte que, lorsque mon module est chargé il définisse les méthodes pour chaque type de valeur (32, 64, etc).
C’est tout, une fois chargé le module ne change plus.
Et puis le code est relativement clair, donc c’est pas de la magie noire.
[32, 64, 128, 256, 512, 1024].each do |bit| # Pour chaque type
define_singleton_method "fnv1_#{bit}".to_s do |key| # définir une method
#code de la method
end
On a vu pire je pense.
quand il suffirait d'un partial avec le premier paramètre passé dedans, (en pour l'avoir dans l'espace de nom en python, je l'ajouterais dans locals, mais j'aurais tendance à considérer ça comme de la magie noire non plus.
Ouais mais non.
C’était ma première idée et c’est carrément moins bien.
Soit, je demande à l’utilisateur de me passer en paramètre 32, 64, 128, 256, 512 ou 1024 et après je choisis (avec des if/else ou un switch) les bonnes constantes. Soit je demande à l’utilisateur de me passer les trois paramètres (INIT, PRIME et MASK).
Dans le premier cas, je rajoute des tests (donc je ralentis ce qui est censé être une fonction de hash rapide).
Dans le second cas, je vais confiance à l’utilisateur pour ne pas me passer un mauvais jeux de paramètres et pour ne pas être blasé d’utiliser une fonction à quatre paramètres alors qu’un est suffisant.
Bravo quand même
Merci.
Sinon, ce vendredi/samedi, j'ai encadré un hackathon kivy dans une école, les étudiants étaient aussi débutants en python qu'en kivy, et ils n'avaient que 24h pour réaliser leur idée, donc c'était assez sport (et ils étaient tout mort à la fin ^^), mais ils s'en sont quand même pas trop mal sortis, avec la quantité de concepts qu'ils avaient besoin d'ingurgiter et d'utiliser dans ce temps. Les gagnants on fait un jeu scrolling 2d, ou il faut éviter des obstactes, avec une idée rigolote, puisque ça s'appel "boutin run", et que les obstacles sont des CRS, des grandes folles, et des femens (on perds toujours à la fin), bien rigolo, et le jeu marchait très bien en fin de compet', ce que je considère comme assez impressionnant (même si oui, ils ont eu des coups de mains). Les autres ont fait des applications plus classiques, et avaient des interfaces plus ou moins fonctionnelles, mais pas grand chose derrière (certaines étaient bien léchés en terme de présentation quand même, c'est assez plaisant à voir). Bien sympa .
Ça semble sympa
Tu étais retourné dans ton ancienne école pour faire ça ?
Hors ligne
#1081 Le 14/04/2013, à 08:39
- The Uploader
Re : /* Topic des codeurs [8] */
Non, pas du tout.
De la métaprog’ de base utilisé dans un cas d’école : éviter le code boilerplate. On peut pas vraiment appeler ça de la magie là, je ne fais pas de trucs alambiqués genre modification ou génération de code pendant l’exécution.
Je fais simplement en sorte que, lorsque mon module est chargé il définisse les méthodes pour chaque type de valeur (32, 64, etc).
C’est tout, une fois chargé le module ne change plus.
Et puis le code est relativement clair, donc c’est pas de la magie noire.
+1. Et puis éviter le code boilerplate, c'est DRY-compliant.
- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10
Hors ligne
#1082 Le 14/04/2013, à 10:56
- Pylades
Re : /* Topic des codeurs [8] */
Je me sens obligé de vous en faire profiter : http://www.pebkac.fr/pebkac/7555/.
“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
Linus Torvalds – 12 janvier 2003
Hors ligne
#1083 Le 14/04/2013, à 20:23
- tshirtman
Re : /* Topic des codeurs [8] */
tshirtman a écrit :Je ne comprends pas bien pourquoi tu met des valeurs aussi grande dans le code, et non pas la façon de les obtenir, si les premiers sont des nombres de Mersenne, par exemple, pourquoi ne pas donner leur formule? Pour les masques, c'est encore plus simple, 2 ** n - 1, ce serait plus clair je pense.
Tout simplement parce que pour certaines, je n’ai aucune idée d’où elles sortent et comment elle sont calculées ^^'
Mais ouais, pour les masques et les nombre premiers j’ai passé en mode formule, par contre pour les valeurs d’init’ j’ai seulement réécrit en notation hexa (je peux pas faire plus court, aucune info à leur sujet).
Ah oui, certes, si t'as pas les formules, c'est pas évident de les inventer :]
tshirtman a écrit :Certes, c'est cool, mais pas mal de magie, non?
Non, pas du tout.
De la métaprog’ de base utilisé dans un cas d’école : éviter le code boilerplate. On peut pas vraiment appeler ça de la magie là, je ne fais pas de trucs alambiqués genre modification ou génération de code pendant l’exécution.
Je fais simplement en sorte que, lorsque mon module est chargé il définisse les méthodes pour chaque type de valeur (32, 64, etc).
C’est tout, une fois chargé le module ne change plus.
Et puis le code est relativement clair, donc c’est pas de la magie noire.[32, 64, 128, 256, 512, 1024].each do |bit| # Pour chaque type define_singleton_method "fnv1_#{bit}".to_s do |key| # définir une method #code de la method end
On a vu pire je pense.
Oui, on a vu pire, mais ça m'aurais inquiété de voir de ta part un code pire que tout ce que j'ai pu voir .
tshirtman a écrit :quand il suffirait d'un partial avec le premier paramètre passé dedans, (en pour l'avoir dans l'espace de nom en python, je l'ajouterais dans locals, mais j'aurais tendance à considérer ça comme de la magie noire non plus.
Ouais mais non.
C’était ma première idée et c’est carrément moins bien.
Soit, je demande à l’utilisateur de me passer en paramètre 32, 64, 128, 256, 512 ou 1024 et après je choisis (avec des if/else ou un switch) les bonnes constantes. Soit je demande à l’utilisateur de me passer les trois paramètres (INIT, PRIME et MASK).
Dans le premier cas, je rajoute des tests (donc je ralentis ce qui est censé être une fonction de hash rapide).
Dans le second cas, je vais confiance à l’utilisateur pour ne pas me passer un mauvais jeux de paramètres et pour ne pas être blasé d’utiliser une fonction à quatre paramètres alors qu’un est suffisant.
Moi j'aurais mis les constantes dans une liste ou un hash, mais effectivement on peut supposer que ce serait un poil plus lent que ta solution (vu que tu ne fait le lookup qu'a la création de la fonction, pas à chaque appel), mais bon, si tu veux de la vitesse, prendre ruby, c'est peut être pas la meilleur idée .
tshirtman a écrit :Bravo quand même
Merci.
tshirtman a écrit :Sinon, ce vendredi/samedi, j'ai encadré un hackathon kivy dans une école, les étudiants étaient aussi débutants en python qu'en kivy, et ils n'avaient que 24h pour réaliser leur idée, donc c'était assez sport (et ils étaient tout mort à la fin ^^), mais ils s'en sont quand même pas trop mal sortis, avec la quantité de concepts qu'ils avaient besoin d'ingurgiter et d'utiliser dans ce temps. Les gagnants on fait un jeu scrolling 2d, ou il faut éviter des obstactes, avec une idée rigolote, puisque ça s'appel "boutin run", et que les obstacles sont des CRS, des grandes folles, et des femens (on perds toujours à la fin), bien rigolo, et le jeu marchait très bien en fin de compet', ce que je considère comme assez impressionnant (même si oui, ils ont eu des coups de mains). Les autres ont fait des applications plus classiques, et avaient des interfaces plus ou moins fonctionnelles, mais pas grand chose derrière (certaines étaient bien léchés en terme de présentation quand même, c'est assez plaisant à voir). Bien sympa .
Ça semble sympa
Tu étais retourné dans ton ancienne école pour faire ça ?
Non, c'est un élève d'une autre école qui nous a contacté pour organiser ça.
Hors ligne
#1084 Le 15/04/2013, à 19:54
- Rolinh
Re : /* Topic des codeurs [8] */
Bon, je viens d'utiliser l'analyseur statique de clang sur dfc et bien m'en a pris car j'ai pu fixé quelques memory leaks.
Par contre, il me reste une erreur que j'ai du mal à comprendre:
dfc/src/dfc.c:663:6: warning: Branch condition evaluates to a garbage value
if (sdisp->init)
^~~~~~~~~~~
1 warning generated.
En l’occurrence, le sdisp->init est un pointeur sur fonction. Donc j'ai un peu du mal à voir le problème. S'il est NULL, alors on ne rentre pas dans le if mais sinon oui (ce que je veux quoi). Vu l'erreur, j'ai l'impression que l'analyseur statique considère que sdisp->init n'est jamais initialisé. Il aurait du mal avec le (void*) ?
Hors ligne
#1085 Le 16/04/2013, à 03:58
- grim7reaper
Re : /* Topic des codeurs [8] */
clang ne te donne pas un possible chemin d’exécution fautif ?
Normalement il le fait.
Dernière modification par grim7reaper (Le 16/04/2013, à 04:01)
Hors ligne
#1086 Le 16/04/2013, à 07:48
- Rolinh
Re : /* Topic des codeurs [8] */
En l’occurrence, le chemin fautif consiste à ne pas prendre le if. Il n'y a pas vraiment d'autre choix.
Hors ligne
#1087 Le 16/04/2013, à 08:00
- grim7reaper
Re : /* Topic des codeurs [8] */
Je ne comprends pas.
Quand je dit que clang montre un chemin d’exécution je parle de chose comme sur les captures d’écran ici.
On parle bien de la même chose ?
J’ai bien essayé d’appliquer clang-analyser sur le code de dfc, mais je n‘ai rien eu (mais j’ai peut-être oublié de passer un paramètre, j’ai testé ça en vitesse ce matin).
Hors ligne
#1088 Le 16/04/2013, à 08:10
- Rolinh
Re : /* Topic des codeurs [8] */
Oui, on parle bien de la même chose je pense.
J'ai généré mon analyse comme ça, sans paramètre particulier donc:
mkdir build && cd build && cmake -DCMAKE_C_COMPILER=/usr/lib/clang-analyzer/scan-build/ccc-analyzer .. && scan-build -V make
Et si tu veux un screenshot:
http://www.rolinh.ch/msc/dfc-static-analysis.png
Dans la trace, c'est la seule erreur qui me reste:
-- The C compiler identification is GNU 4.8.0
-- Check for working C compiler: /usr/lib/clang-analyzer/scan-build/ccc-analyzer
-- Check for working C compiler: /usr/lib/clang-analyzer/scan-build/ccc-analyzer -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Looking for gettext
-- Looking for gettext - found
-- Found Libintl: /usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: /home/robin/Hacking/git/bor/dfc/build
scan-build: Using '/usr/bin/clang' for static analysis
Scanning dependencies of target dfc
[ 8%] Building C object CMakeFiles/dfc.dir/src/csv.c.o
[ 16%] Building C object CMakeFiles/dfc.dir/src/dotfile.c.o
[ 25%] Building C object CMakeFiles/dfc.dir/src/dfc.c.o
/home/robin/Hacking/git/bor/dfc/src/dfc.c:665:6: warning: Branch condition evaluates to a garbage value
if (sdisp->init)
^~~~~~~~~~~
1 warning generated.
[ 33%] Building C object CMakeFiles/dfc.dir/src/html.c.o
[ 41%] Building C object CMakeFiles/dfc.dir/src/list.c.o
[ 50%] Building C object CMakeFiles/dfc.dir/src/tex.c.o
[ 58%] Building C object CMakeFiles/dfc.dir/src/text.c.o
[ 66%] Building C object CMakeFiles/dfc.dir/src/util.c.o
Linking C executable bin/dfc
[ 66%] Built target dfc
Scanning dependencies of target dfc.pot-update
[ 75%] Built target dfc.pot-update
Scanning dependencies of target generate-dfc-fr-po
[ 91%] Built target generate-dfc-fr-po
Scanning dependencies of target generate-dfc-fr-gmo
[100%] Generating fr.gmo
/home/robin/Hacking/git/bor/dfc/po/fr.po: 67 translated messages.
[100%] Built target generate-dfc-fr-gmo
Scanning dependencies of target update-gmo
[100%] Built target update-gmo
scan-build: 1 bugs found.
scan-build: Run 'scan-view /tmp/scan-build-2013-04-16-8' to examine bug reports.
scan-build: Analysis run complete.
scan-build: Viewing analysis results in '/tmp/scan-build-2013-04-16-8' using scan-view.
Starting scan-view at: http://127.0.0.1:8181
Use Ctrl-C to exit.
EDIT: Ceci dit, je ne comprend pas vraiment. Ça pourrait être un faux positif.
Dernière modification par Rolinh (Le 16/04/2013, à 08:12)
Hors ligne
#1089 Le 16/04/2013, à 08:21
- Mindiell
Re : /* Topic des codeurs [8] */
Ça pourrait être un faux positif.
Ouaip, ça pourrait bien...
Hors ligne
#1090 Le 16/04/2013, à 10:42
- Rolinh
Re : /* Topic des codeurs [8] */
@Mindiell: ouep, on dirait bien que je tombe dans un cas similaire.
Je vais devoir faire un projet en binôme en R. Il se pourrait bien que de l'aide soit utile de tant à autre.
Ah bah finalement on a le choix du langage.
Je pense que python ça sera. C'est un projet de datamining et comme on a du natural language processing à faire (analyse de messages Twitter), je pense que nltk sera tout indiqué. Pour le reste des choses qu'on fait facilement en R, il parait qu'avec numpy et/ou pandas et/ou scipy ça passe tout seul. Quelqu'un peut me confirmer?
Hors ligne
#1091 Le 16/04/2013, à 10:57
- grim7reaper
Re : /* Topic des codeurs [8] */
Ouais, pour ma part je fais du Python 3/numpy/matplotlib et ça me suffit (mais bon je fais pas de stat‘ de ouf).
Sinon ouais, il paraît que pandas se veut le R du Python ^^.
Sinon au pire, tu fais directement du R en Python avec RPy2
Ça va être quoi votre projet ?
Ou c‘est encore un truc top secret dont tu ne peux pas trop parler ?
Dernière modification par grim7reaper (Le 16/04/2013, à 11:00)
Hors ligne
#1092 Le 16/04/2013, à 11:21
- Rolinh
Re : /* Topic des codeurs [8] */
Non non, c'est pas un projet top secret. C'est un petit projet de fin de semestre pour un cours de datamining où le but est de faire du machine learning. D'ailleurs, je pense qu'on publiera les sources parce que... il n'y a pas de raison (à part que je n'ai pas énormément d'expérience avec Python et que je pourrais produire du code pas hyper clean).
En gros, le but est d'analyser des tweets avec le hashtag #shampoo (parce que le dataset a été collecté à partir de tweet avec le hashtag #shampoo) et de faire de la classification par topic et de la novelty detection pour créer des nouveaux groupes de classification.
Sinon, pour l'autre projet (sur lequel je ne bosse pas, je rappelle), j'ai appris pourquoi il est "top secret": une startup a contribué à une partie du projet (sous mandat j'imagine) mais ne veut pas libérer les sources puisque le but est de sortir un produit basé dessus. Au vu de la contribution (Automatic Speech Processing), ça peut se comprendre mais c'est vraiment dommage car c'est quelque chose qu'on peut considérer quasi-inexistant dans le monde du libre. Les contributions des universités sont, elles, libres normalement (les contribution de la mienne sont sous GPLv2).
Hors ligne
#1093 Le 16/04/2013, à 12:08
- grim7reaper
Re : /* Topic des codeurs [8] */
Ok.
Pour le Python, tu peux lancer des coups de pylint sur ton code pour détecter les choses qui ne sont pas trop dans l’esprit Python (bien que je sois en désaccord avec pylint sur certains points, ça reste un bon point de départ). Sinon demande ici
Pour l’autre projet, je me doutais bien qu’il y avait une entreprise dans le coup.
Hors ligne
#1094 Le 16/04/2013, à 12:17
- Rolinh
Re : /* Topic des codeurs [8] */
Ok.
J'ai pas choisi hein, le projet m'est imposé.
Pour le Python, tu peux lancer des coups de pylint sur ton code pour détecter les choses qui ne sont pas trop dans l’esprit Python (bien que je sois en désaccord avec pylint sur certains points, ça reste un bon point de départ). Sinon demande ici
Ouep, j'y avais déjà pensé (car déjà entendu parlé ici). Sinon, je crois qu'il y a effectivement assez de pythonneux chevronnés par ici qui pourront me donner des conseils au cas où.
Hors ligne
#1095 Le 16/04/2013, à 12:43
- grim7reaper
Re : /* Topic des codeurs [8] */
grim7reaper a écrit :Ok.
J'ai pas choisi hein, le projet m'est imposé.
Je ne sais pas comment tu as pris mon « Ok » mais il n’y avait pas de sous-entendu ^^'
C’est juste que j’avais pas de commentaire particulier à faire sur le contenu du sujet.
Hors ligne
#1096 Le 16/04/2013, à 13:36
- Rolinh
Re : /* Topic des codeurs [8] */
Ouep, j'ai pensé mais ça pouvait aussi se comprendre comme un "ok, pas intéressant quoi" Du coup, j'ai voulu précisé. ^^
Il y en a par ici qui ont bossé avec la stack JEE6 ? On a un projet de groupe (5 personnes) pour lequel on doit faire un site web avec JEE6 et utilisation de toute une list d'outils (netbeans, git, jenkins, maven, sonar, mysql, glassfish, redmine pour résumer). Donc tests, intégration continue, etc.
Je suis pas fan de Java en général mais cette stack JEE6 me rend malade (et mes 4 autres comparses aussi). Le prof du cours a d'ailleurs mis un tuto JEE6 sur son blog avec sources de demo sur Github qui parle de ce qu'on doit utiliser pour notre projet, si quelqu'un souhaite se faire une idée.
Et ben, je pense que c'est une surprise pour personne mais... je n'ai jamais vu une telle usine à gaz. Et je vous épargne les configurations qu'on a du faire parce que ça doit faire 3 semaines qu'on configure des trucs (entre autres choses) et on a pas encore tout qui fonctionne comme on le veut...
Dernière modification par Rolinh (Le 16/04/2013, à 13:37)
Hors ligne
#1097 Le 16/04/2013, à 15:23
- grim7reaper
Re : /* Topic des codeurs [8] */
JEE j’en ai jamais fait personnellement, mais pour avoir aider un peu quelqu‘un c’est le sentiment que j’ai eu : la pire usine à gaz jamais inventé par l‘Homme…
Au passage, tu passes plus de temps à écrire de la configuration en XML pour que ça tombe en marche plutôt qu’a faire un code lisible (non, le XML brut ce n’est pas lisible de mon point vue).
Hors ligne
#1098 Le 16/04/2013, à 15:56
- The Uploader
Re : /* Topic des codeurs [8] */
Même sentiment lors de mes cours de JEE :
- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10
Hors ligne
#1099 Le 16/04/2013, à 16:43
- Rolinh
Re : /* Topic des codeurs [8] */
@grim7reaper et The Uploader: c'est exactement ça. Aujourd'hui on commence notre 7e milestone et c'est le premier jour ou le déploiement fonctionne (bon, avant ça on a bossé sur tout le reste du projet ie: les stories à implémenter, le DOM, le schéma BDD, la mise en place du serveur, etc).
Par contre je suis halluciné: notre serveur (Ubuntu 12.04 dans un VM) avait à la base 512Mo de ram. On a fait en demande pour passer à 1Go parce que ça ne passait pas. Résultat, aujourd'hui le serveur tombait toujours parce qu'il n'arrivait plus à allouer de mémoire lorsque l'on faisait un commit (ce qui déclenche build + test + analyse de code par sonar + déploiement sur glassfish): résultat: le serveur tombe... Bon, je vais voir l'admin sys, il m'alloue 2Go pour... le même résultat. On a du passer à 4Go pour que ça tourne. Glassfish + Sonar + Jenkins (3 grosses usines à gaz en Java) prennent 1.5-1.8Go de mémoire sur le serveur au repos (auquel on ajoute environ 300Mo pour le système + apache + redmine (et donc passenger) + mysql) ce qui fait 2Go de bouffé quand le serveur ne fait rien). Quand on commit, cela passe autour des 3Go... Et pour le moment, notre appli ne fait rien à par un login et affichage d'une page statique en html... (ouais, je vois venir la suite là...).
Et pour le reste, on passe effectivement notre temps dans des fichiers XML (et on est bien d'accord grim que xml n'est pas adapté à cette tâche) pour la configuration. Résultat, pour le moment on a qu'environ 400 lignes de Java... Ahem... Sincèrement, une stack pareille...
Un de l'équipe à fait en rails en 30 minutes hier soir ce qui nous a pris 3 semaines à mettre en place (et je n'exagère pas) ie: mise en place de tests, déploiement, gestion de session et login plus création de pages par rapport à notre projet. On est d'accord que dans le cas de Rails il n'y avait rien à apprendre, contrairement à la stack JEE6 mais tout de même...
Hors ligne
#1100 Le 16/04/2013, à 18:27
- grim7reaper
Re : /* Topic des codeurs [8] */
Ouais, ça ne m’étonne même pas
En fait, je me demande même si la réputation de lourdeur de Java (au niveau perf’) n’est pas due aux usines à gaz genre JEE & cie…
Parce que Java en lui-même, si on met de côté son manque de flexibilité et sa lourdeur syntaxique, est un langage plutôt décent, même au niveau perf’.
Bon faut aussi avouer que les implémentations des JVM actuelle sont de petits bijoux d’ingénierie informatique.
Tiens, quand je vois le bordel que c’est le déploiement d’un machin JEE je comprends pourquoi les marchands de viande en raffole. Si ça prends deux semaines pour faire le moindre truc, ça doit être rentable niveau facturation le déploiement de ce genre de techno’
Hors ligne