Les bookmarks de Clem
2390 shaares
244 results
tagged
informatique
Tiens, ya des outils de compet pour la lecture de gros jeux de données sous R
De l'importance de la licence GNU. Bizarre quand même le gars...
Autre explication pour un live usb Debiian
Une explication claire...
Sous debian: gpg --keyserver hkp://pgp.mit.edu --recv-keys 98AB5139
Sous debian: gpg --keyserver hkp://pgp.mit.edu --recv-keys 98AB5139
Approche pour faire une live usb personnalisée.
À lire ça m'a l'air intéressant.
Idem, à garder sous le coude pour les cas d'énervements sur mailing list...
À retenir:
find . -name "toto.*"
cherche les fichiers toto.* récursivement dans le répertoire courant.
find . -name "toto.*"
cherche les fichiers toto.* récursivement dans le répertoire courant.
Conseils pour stocker efficacement des tableaux sur un ordi.
"Once the current honeymoon period of data science comes to an end - the statistician will again come to the fore. This was due in part to the importance of experiment design and the fact that probability theory is the best way of dealing with uncertainty"
Tiens? une police conçue pour coder... À essayer.
À lire (ya une vidéo). L'analyse de décision revient en force...
A lire... Je ne sais pas trop dans quelle mesure l'analyse de décision peut vraiment aider à résoudre des pbs vraiment complexes...
Tiens, ben ya même un article qui reprends les points des bonnes pratiques de programmation.
Très intéressant, je résume:
1. Il faut écrire du code pour les gens, pas pour les ordis (programmes courts, noms consistents, prog cohérente)
2. Laisser l'ordinateur faire le travail (faire des macros pour tout)
3. Avancer de façon incrémentale (on avance petits pas par petits pas, on ne cherche pas à atteindre l'objectif final d'un coup, utiliser git)
4. Ne jamais se répéter dans le code (en particulier, chaque jeu de données ne doit avoir qu'une seule représentation de référence dans le code, modulariser le code plutôt que copier collé, réutiliser le code des autres plutôt que le réécrire)
5. Prévoir la présence d'erreurs (mauvaise utilisation, tester le code dans toutes les config possibles, etc.)
6. Optimiser seulement une fois que ça marche (en particulier, commencer par programmer en haut niveau avant de passer au bas niveau)
7. On documente le design et l'objectif, pas le fonctionnement du code (en particulier, il faut documenter ce que le code ne dit pas, pas résumerr ce qu'il fait).
8. Collaborer (partager le code; le gars recommande le version control à tour de bras + issue tracking tool)
1. Il faut écrire du code pour les gens, pas pour les ordis (programmes courts, noms consistents, prog cohérente)
2. Laisser l'ordinateur faire le travail (faire des macros pour tout)
3. Avancer de façon incrémentale (on avance petits pas par petits pas, on ne cherche pas à atteindre l'objectif final d'un coup, utiliser git)
4. Ne jamais se répéter dans le code (en particulier, chaque jeu de données ne doit avoir qu'une seule représentation de référence dans le code, modulariser le code plutôt que copier collé, réutiliser le code des autres plutôt que le réécrire)
5. Prévoir la présence d'erreurs (mauvaise utilisation, tester le code dans toutes les config possibles, etc.)
6. Optimiser seulement une fois que ça marche (en particulier, commencer par programmer en haut niveau avant de passer au bas niveau)
7. On documente le design et l'objectif, pas le fonctionnement du code (en particulier, il faut documenter ce que le code ne dit pas, pas résumerr ce qu'il fait).
8. Collaborer (partager le code; le gars recommande le version control à tour de bras + issue tracking tool)
Bon à savoir.
Google commence à poser des brevets sur des idées en machine learning. Ça sent vraiment le roussi... Comme l'indique le commentateur sur reddit:
"I am afraid that Google has just started an arms race, which could do significant damage to academic research in machine learning. Now it's likely that other companies using machine learning will rush to patent every research idea that was developed in part by their employees. We have all been in a prisoner's dilemma situation, and Google just defected. Now researchers will guard their ideas much more combatively, given that it's now fair game to patent these ideas, and big money is at stake."
"I am afraid that Google has just started an arms race, which could do significant damage to academic research in machine learning. Now it's likely that other companies using machine learning will rush to patent every research idea that was developed in part by their employees. We have all been in a prisoner's dilemma situation, and Google just defected. Now researchers will guard their ideas much more combatively, given that it's now fair game to patent these ideas, and big money is at stake."
J'avais déjà vu passer ça...
Ben putain, c'est bon à savoir:
some-command <(another-command)
va exécuter "another-command" -- il faut que cette autre commande écrive le résultat dans stdout -- et va passer le résultat à some-command (avec some-command une commande qui prend un nom de fichier comme argument). Donc pas besoin de stocker dans les fichiers, on passe directement le résultat du l'une à l'autre. Comme un pipe, sauf que (i) on peut substituer autant de commande qu'on veut, par exemple:
diff <(curl http://somesite/file1) <(curl http://somesite/file2)
va substituer les deux curl et les passer à diff; et (ii) les commandes substituées sont lancées en parallèle et pas à la suite.
some-command <(another-command)
va exécuter "another-command" -- il faut que cette autre commande écrive le résultat dans stdout -- et va passer le résultat à some-command (avec some-command une commande qui prend un nom de fichier comme argument). Donc pas besoin de stocker dans les fichiers, on passe directement le résultat du l'une à l'autre. Comme un pipe, sauf que (i) on peut substituer autant de commande qu'on veut, par exemple:
diff <(curl http://somesite/file1) <(curl http://somesite/file2)
va substituer les deux curl et les passer à diff; et (ii) les commandes substituées sont lancées en parallèle et pas à la suite.
Ah ben tiens, je connaissais pas: pour se créer des adresses bidons, jetables, et personnalisées.
Peut être pratique, je me garde ça sous le coude.
Peut être pratique, je me garde ça sous le coude.
Et le package R qui fait l'interface vers le service web.
Un service web pour dire aux gens d'aller se faire foutre. Multilangage implémenté.
Intéressant. L'UEFI est déjà un système merdique quand on veut utiliser un système linux. Je l'avais toujours compris comme un moyen coercitif de Microsoft de décourager l'utilisateur de se tourner vers un autre système. En fait, c'est pire que ça: même si l'on choisit de rester sous windows, si la carte mère plante, les données sont perdues puisque le disque dur est associé à une carte mère.
Enfin, comme il l'indique, ya toujours moyen d'utiliser linux pour récupérer les données, mais bon: (i) pour l'utilisateur moyen, c'est mort, (ii) dans tous les cas, le disque dur est foutu (puisque lié à la carte mère).
Et les constructeurs laissent faire...
Enfin, comme il l'indique, ya toujours moyen d'utiliser linux pour récupérer les données, mais bon: (i) pour l'utilisateur moyen, c'est mort, (ii) dans tous les cas, le disque dur est foutu (puisque lié à la carte mère).
Et les constructeurs laissent faire...
Très bonne description de l'utilisation du DOM dans conkeror
Énormément de webinaires sur plein de sujets, autour de R.
On oublie le HTML5. Si je fais un mooc, ce sera celui-ci.
J'ai déjà fait plein de tutos, mais je veux vraiment tenter ça.
J'ai déjà fait plein de tutos, mais je veux vraiment tenter ça.
Un joli comparatif comparant R et Python. Avantages et inconvénients de chacun. Sur le long-terme, python pourrait bien passer premier. Pour le moment, on en est encore loin...
Un tutoriel super intéressant sur chroot (via sebsauvage)
Ah tiens, je connaissais pas: xmpp permet de faire du chat, un genre de msn libre.
Yen a des zoulis, j'ai pas tout compris, par exemple
while :;do printf "\e[%d;%dH\e[48;5;%dm \e[0m" $(($RANDOM%$LINES)) $(($RANDOM%$COLUMNS)) $(($RANDOM%216 )); done
while :;do printf "\e[%d;%dH\e[48;5;%dm \e[0m" $(($RANDOM%$LINES)) $(($RANDOM%$COLUMNS)) $(($RANDOM%216 )); done
Sur le big data: on est vraiment sur des pbs d'informaticiens dans ce cas. Le problème de ces histoires de "data scientists", c'est que chacun y met un peu ce qu'il veut. Pour certains, il s'agit de stats exploratoires (originellement, le terme vient d'un papier de Cleveland quand même). Pour d'autre, c'est l'évolution logique de l'approche informaticienne de l'analyse de données, celle qui passe outre les questions statistiques. Là, on est dans le dernier cas. Alors? ben la question n'est pas simple, la tendance "data science and big data" existe indéniablement, comme le dit très bien le gars.
Une appli shiny pour voir l'évolution des téléchargements de packages grâce aux cranlogs de Rstudio
L'autorité de certification libre pour la délivrance de certificats SSL.
Dans cette idée du https généralisé imposé par mozilla et google...
Dans cette idée du https généralisé imposé par mozilla et google...
Profitons bien des derniers instants des navigateurs mozilla based avant de passer à autre chose. Mozilla est en train de se tirer une balle dans le pied...
ah oui, m'a l'air sympa...
eg, un programme à essayer
eg, un programme à essayer
Ben putain, ça ça serait une révolution.
(via sebsauvage)
(via sebsauvage)
Très bon article, qui met bien les choses au point. Je me le garde sous le coude pour m'y référer dans mes réponses aux solliciteurs.
En ce qui me concerne, je n'aime pas bien le "pull-request welcome" dans mes projets perso (je n'ai pas mis mes projets sur github précisément pour éviter ça -- je suis sous git, mais en local sur ma machine).
En ce qui me concerne, je n'aime pas bien le "pull-request welcome" dans mes projets perso (je n'ai pas mis mes projets sur github précisément pour éviter ça -- je suis sous git, mais en local sur ma machine).
Alors ça, ça m'intéresse!
Ah? à trouver et à lire. L'idée d'interfacer SIG et R pour ce type de calcul me paraît effectivement une idée à suivre.
À voir...
À voir...
Bon, au final, utiliser docker, c'est pas encore au point. Ça a planté au bout d'une heure, genre "exec error" sans explications.
Mais j'ai une solution définitive pour implémenter l'UBSAN pour le check des packages R (examen des comportements non définis dans le code C, e.g. quand on passe un vecteur contenant des données manquantes à un programme qui ne les gère pas, quand on divise par zéro, etc.).
Approche laborieuse, mais ça marche. C'est une mise à jour et une version plus stable de ce que je disais ici:
http://caloine.ouvaton.org/shaarli/?rTZF_g
Plus stable parce qu'elle n'implique pas de bidouiller le compilateur du système d'exploitation que j'utilise pour le reste de mon boulot. Il faut installer une machine virtuelle virtualbox sous ubuntu (host), en définissant un ubuntu guest (64 bits, comme ça la machine servira aussi à faire tourner des programmes 64bits, autant rentabiliser le boulot). Une fois ubuntu installé, on installe le compilateur clang, version 3.6 mini (gaffe, ya des dépôts à mettre dans le source.list). En pratique, voir les instructions ici:
http://llvm.org/apt/
on installe toutes les dépendances nécessaires pour construire R:
sudo apt-get install r-base-dev
sudo apt-get build-dep r-base
On télécharge les sources de R (devel ou base), on les décompresse, et on édite le config.site. Dans le config.site, on édite les variables suivantes:
CC="clang-3.6 -std=gnu99 -fsanitize=undefined"
CFLAGS="-fno-omit-frame-pointer -02 -Wall -pedantic -mtune=native"
CCXX="clang++-3.6 -std=gnu99 -fsanitize=undefined"
CXXFLAGS="-fno-omit-frame-pointer -02 -Wall -pedantic -mtune=native"
Gaffe, il faut pas oublier les guillemets.
Dans le home, on crée un répertoire .R, et dedans, on crée un fichier Makevars, et dedans on met
CC=clang-3.6 -std=gnu99 -fsanitize=undefined -fno-omit-frame-pointer
Gaffe, là pour le coup, faut surtout pas mettre de guillemets sinon ça plante.
Ensuite, on configure
./configure --enable-R-shlib --enable-memory-profiling --with-tcl-config=/usr/lib/tcl8.5/tclConfig.sh --with-tk-config=/usr/lib/tk8.5/tkConfig.sh
Gaffe aux versions de tcl et tk vérifier la version et localisation des config.sh avec un locate (après sudo updatedb). Ensuite, classiquement,
make
sudo make install
Gaffe, c'est super long sur certains fichiers (mais ça, c'est documenté dans le writing R extensions: ça dure des plombes, mais c'est normal: deux heures de compilation au total, avec pas loin de trois quart d'heures sur certains fichiers).
Ensuite, on installe adehabitat et ses dépendances sous R:
install.packages(c("adehabitatHS", "tkrplot","maptools","rgeos"))
Pareil, la compilation dure des plombes à cause de l'UBSAN.
Après, dans la machine virtuelle, installer les additions invitées, et créer un répertoire partagé entre les deux machines. Redémarrer, Et zou, le système est opérationnel.
À noter, sur les dernières versions de virtualbox, il est possible de copier coller du système hôte vers l'invité.
Par contre, gaffe, s'il y a des "runtime errors", elles ne sont pas renvoyées au niveau du check. Il est nécessaire, après le check, d'aller dans le répertoire ".Rcheck", et de faire un grep:
grep error *
Mais sinon ça marche bien. Autre mise à jour, l'UBSAN ne nécessite pas l'utilisation de valgrind. C'est juste le compilateur clang qui gère.
Mais j'ai une solution définitive pour implémenter l'UBSAN pour le check des packages R (examen des comportements non définis dans le code C, e.g. quand on passe un vecteur contenant des données manquantes à un programme qui ne les gère pas, quand on divise par zéro, etc.).
Approche laborieuse, mais ça marche. C'est une mise à jour et une version plus stable de ce que je disais ici:
http://caloine.ouvaton.org/shaarli/?rTZF_g
Plus stable parce qu'elle n'implique pas de bidouiller le compilateur du système d'exploitation que j'utilise pour le reste de mon boulot. Il faut installer une machine virtuelle virtualbox sous ubuntu (host), en définissant un ubuntu guest (64 bits, comme ça la machine servira aussi à faire tourner des programmes 64bits, autant rentabiliser le boulot). Une fois ubuntu installé, on installe le compilateur clang, version 3.6 mini (gaffe, ya des dépôts à mettre dans le source.list). En pratique, voir les instructions ici:
http://llvm.org/apt/
on installe toutes les dépendances nécessaires pour construire R:
sudo apt-get install r-base-dev
sudo apt-get build-dep r-base
On télécharge les sources de R (devel ou base), on les décompresse, et on édite le config.site. Dans le config.site, on édite les variables suivantes:
CC="clang-3.6 -std=gnu99 -fsanitize=undefined"
CFLAGS="-fno-omit-frame-pointer -02 -Wall -pedantic -mtune=native"
CCXX="clang++-3.6 -std=gnu99 -fsanitize=undefined"
CXXFLAGS="-fno-omit-frame-pointer -02 -Wall -pedantic -mtune=native"
Gaffe, il faut pas oublier les guillemets.
Dans le home, on crée un répertoire .R, et dedans, on crée un fichier Makevars, et dedans on met
CC=clang-3.6 -std=gnu99 -fsanitize=undefined -fno-omit-frame-pointer
Gaffe, là pour le coup, faut surtout pas mettre de guillemets sinon ça plante.
Ensuite, on configure
./configure --enable-R-shlib --enable-memory-profiling --with-tcl-config=/usr/lib/tcl8.5/tclConfig.sh --with-tk-config=/usr/lib/tk8.5/tkConfig.sh
Gaffe aux versions de tcl et tk vérifier la version et localisation des config.sh avec un locate (après sudo updatedb). Ensuite, classiquement,
make
sudo make install
Gaffe, c'est super long sur certains fichiers (mais ça, c'est documenté dans le writing R extensions: ça dure des plombes, mais c'est normal: deux heures de compilation au total, avec pas loin de trois quart d'heures sur certains fichiers).
Ensuite, on installe adehabitat et ses dépendances sous R:
install.packages(c("adehabitatHS", "tkrplot","maptools","rgeos"))
Pareil, la compilation dure des plombes à cause de l'UBSAN.
Après, dans la machine virtuelle, installer les additions invitées, et créer un répertoire partagé entre les deux machines. Redémarrer, Et zou, le système est opérationnel.
À noter, sur les dernières versions de virtualbox, il est possible de copier coller du système hôte vers l'invité.
Par contre, gaffe, s'il y a des "runtime errors", elles ne sont pas renvoyées au niveau du check. Il est nécessaire, après le check, d'aller dans le répertoire ".Rcheck", et de faire un grep:
grep error *
Mais sinon ça marche bien. Autre mise à jour, l'UBSAN ne nécessite pas l'utilisation de valgrind. C'est juste le compilateur clang qui gère.
plus de détails
Alors ça ça a l'air pas mal. Je misère comme un malheureux en ce moment pour essayer de compiler R-devel avec un compilateur llvm/clang pour pouvoir vérifier le code C de mes packages R selon les nouvelles pratiques de R. Installation de machine virtuelle, installation de debian, installation de clang depuis les dépots et tout le merdier qui va avec. Et une compilation interminable.
Ces gars là utilisent docker, un service qui va fournir juste l'environnement nécessaire d'un R-devel compilé et clang pour pouvoir checker le code avec l'UBSAN. En clair, il semblerait qu'il faille juste récupérer le container, et boum, c'est prêt à l'usage.
Bon, par contre, ça marche pas sous 32 bits et comme j'ai fait le choix de rester sous 32 bits rapport que ya des applis qui ne sont pas encore passé à 64bits, je ne ferai pas l'économie d'une machine virtuelle.
Ces gars là utilisent docker, un service qui va fournir juste l'environnement nécessaire d'un R-devel compilé et clang pour pouvoir checker le code avec l'UBSAN. En clair, il semblerait qu'il faille juste récupérer le container, et boum, c'est prêt à l'usage.
Bon, par contre, ça marche pas sous 32 bits et comme j'ai fait le choix de rester sous 32 bits rapport que ya des applis qui ne sont pas encore passé à 64bits, je ne ferai pas l'économie d'une machine virtuelle.
Bon à partir de maintenant, je vais utiliser des messages de commit pertinents et arrêter d'écrire n'importe quoi...
Du coup, je me mets de côté le raccourcisseur d'URL
Très intéressant, les sources sont données.
La vache, c'est pas mal ça: pour injecter un code txt présent dans un fichier séparé dans un document latex.
Oui, ça va être bien utile..
Oui, ça va être bien utile..
Intéressant.
Putain, ils s'arrêtent jamais les mecs de chez Rstudio. J'avais vu passer ça, mais j'avais pas percuté à quel point ça déchirait...
Je vais quand même me garder ça sous le coude, j'ai le sentiment que c'est un outil rigolo pour communiquer des résultats via une page web...
Je vais quand même me garder ça sous le coude, j'ai le sentiment que c'est un outil rigolo pour communiquer des résultats via une page web...
C'est TRÈS intéressant!
Faute d'un stockage à long terme, les données scientifiques se perdent à un rythme de 17% par an!
Comme quoi, réfléchir aux bases de données, hein...
Faute d'un stockage à long terme, les données scientifiques se perdent à un rythme de 17% par an!
Comme quoi, réfléchir aux bases de données, hein...
TRÈS intéressant! Plein de stratégies, le plus souvent très simples, pour accélérer du code R