et à côté de ça il n'est même pas capable de géré l'encapsulation des classes ....
Aie, j'ai beau avoir relu ces derniers mois des pages de C++, il m'aura fallu ce bon vieux wikipedia pour me remémorer ce qu'est l'Encapsulation_des_données. Alors effectivement, Python ne protège aucune donnée. Mais objectivement ça ne m'a jamais gêné : une règle tacite du python est que toute donnée précédée d'un '_' est interne à la classe. Si le programmeur y touche, il ne doit pas venir pleurer si un futur changement de version cassera son code.
Par contre, j'aimerais plus d'explication concernant :
cette fausse impression de sécurité que le langage te donne en te forçant à tout spécifier
Spécifier quoi ? Alors que justement mon principal reproche envers Python est qu' on n'y déclare rien et que tout y est implicite.
Python est trop dangereux pour les étourdis chroniques : trop de libertés, trop de possibilités d'erreur, trop de canards enrubannés (et parfois même, comme avec GTK+2, des bogues entre les bindings C et la machine virtuelle un peu trop subtiles à mon goût).
Des langages fortement typés comme Haskell ou C/C++ et leurs descendants (Java, Vala?) ne conviendraient-ils pas mieux ? (je ne connais pas Ruby, je ne sais pas ce qu'il en est pour lui). Tant pis pour les fioritures et autres "boilerplate". On a des éditeurs de textes suffisamment puissants aujourd'hui pour ne plus s'en soucier. Tant pis également pour ce méchant compilateur qui n'arrête pas de nous taper sur les doigts. Il faut persévérer, on est tous passé par là et on finit par s'y faire.
S'il le faut, on peut même rajouter une p'tite bibliothèque de tests unitaires. Avec tout ça, on devrait bien réussir à vaincre cette «malédiction» !
En fait, ce n'est pas forcément très long à réaliser. Il suffit de trouver les tables de correspondance "bash magie" -> "couleur" et d'utiliser ton éditeur de texte préféré. Indice : VIM qq @q est ton ami :)
Ça fait longtemps que je me suis amusé à ce p'tit jeu de compilation croisée alors prend ce qui suit avec des pincettes :
Installer le binaire pré-construit sur la cible, ça c'est bon, mais je ne peux pas installer ce même bianire pour ARM sur la debian x86 ?
Tu ne pourras pas exécuter le binaire ARM su la debian x86 (processeur incompatible), donc il n'y a pratiquement aucun intérêt de l'y installer. (sauf si tu aimes t'amuser à configurer des chroot et à faire joujou avec Qemu dedans, mais ceci est une autre histoire).
Par contre, tu peux te créer des dossiers sur ta debian x86 concernant les en-têtes et les bibliothèques dynamiques de tes applications ARM pour ensuite les utiliser avec ton compilateur croisé arm-linux-gcc. Le hic, c'est qu'il ne faut pas mélanger ces bibliothèques avec celle de ta debianx86 et qu'il faut configurer ta "toolchain" (compilateur, linker, ...) pour qu'elle parte chercher ces en-têtes et bibliothèques ARM au bon endroit (-L, -I, manpages, ...). Je n'en connais pas plus sur ce point, désolé.
Il y a un truc qui m'échappe : Google Chrome, Safari et Midori ne sont-ils pas tous basés sur WebKit (à plus ou moins ça près) ?
Alors pourquoi mon joli Midori fait la grimace ? C'est déprimant de voir qu'avec le temps, le support des standards W3C chez certain semble plus se dégrader qu'autre chose ...
L'U-Boot que j'utilise est configuré pour démarrer soit à partir d'une carte
SD, soit à partir de la flash NAND interne. Bon le pseudo dual-boot ne
t'intéresse probablement pas mais les variables type "bootcmd_sd" oui :
# Common variables
setenv bootargs_console '...'
# Configuration 0 : booting on SDIO
setenv bootargs_sd 'ro root=/dev/mmcblk0p2 rootdelay=1'
setenv bootcmd_sd 'setenv bootargs $(bootargs_console) $(bootargs_sd); mmcinit; ext2load mmc 0 0x800000 /uImage; bootm 0x800000'
# Configuration 1 : booting on native NAND
setenv bootcmd_nand '...'
# ... one variable to bring them all and in the darkness boot them ...
setenv bootcmd 'run bootcmd_sd; run bootcmd_nand'
### saveenv
### reset
Je suppose que si tu adaptes le setenv bootcmd_sd à chacun de tes noyaux, tu pourras ensuite joyeusement choisir lequel lancer au démarrage d'U-Boot en tapant run bootcmd_linux2.6.30 ou run bootcmd_linux2.6.32.
Merci au wiki plugcomputer.org pour tous leurs exemples :)
Posté par Johands .
En réponse au message Haskell.
Évalué à 1.
De trois chose l'une :
1 - comme écrit dans la réponse précédente, quand tu joues avec la monad IO, tu ne peux plus en sortir. C'est un des fondements de Haskell : une fonction utilisant des données externes (IO) est impure et doit être confinée à l'écart du code restant. Autrement formulé : il est impossible de convertir un "IO a" en "a".
2 - il est peut-être possible d'éviter la monad IO pour l'instant en préférant randomR et randomRs à randomRIO cf l'API Haskell pour plus de détails.
3 - c'est pas joli de faire des postes en doubles !!
Posté par Johands .
En réponse au message Haskell.
Évalué à 2.
Vu le cas d'école que représente la question, l'idée que l'énoncé soit en effet tiré d'un exercice ma traversé le vide qui sépare mes deux oreilles.
Le hic, c'est que j'ai encore du mal à imaginer une université enseignant l'Haskell en France (ou dans les pays francophones), vu la faible notoriété du langage et l'héritage du Caml.
Posté par Johands .
En réponse au message Haskell.
Évalué à 2.
Donc au hasard, parce que je suis encore un bleu, je proposerais deux versions
: l'une reprenant le message parent et une deuxième que je trouve plus propre.
(je laisse la version avec State monad en exo :o)
l1 = [ [ 1, 0, 4]
, [ 0, 2, 0]
, [ 1, 0, 3]
] :: Int
diag1 :: [ [Int] ] -> Int -> Int
diag1 [] _ = 0
diag1 (x:xs) i = (x !! i) + (diag1 xs (i+1))
sommeDiag1 :: [ [Int] ] -> Int
sommeDiag1 l = diag1 l 0
diag2 :: [ [Int] ] -> Int -> Int
diag2 [] _ = 0
diag2 (x:xs) i = (x !! i) + (diag2 xs (i-1))
sommeDiag2 :: [ [Int] ] -> Int
sommeDiag2 l = diag2 l (length l - 1)
-- one liners
sommeDiag1' :: (Num a) => [ [a] ] -> a
sommeDiag1' l = sum $ zipWith (!!) l [0..]
sommeDiag2' :: (Num a) => [ [a] ] -> a
sommeDiag2' l = sum $ zipWith (!!) (reverse l) [0..]
Toute critique est la bienvenue !
P.S.: j'ai vraiment de gros problème pour insérer du code sur ce site, notamment les '<', '>' et les '[ [ ] ] '. Quelqu'un connaît-il une solution ?
(... 48h plus tard, mais ça peut toujours servir ...)
Sur la partie VirtualBox, je n'y connais rien, je ne peux pas aider. Désolé.
Sur la partie udev : j'ai bien coucou qui s'affiche dans coucoulog...cependant il s'affiche une bonne dizaine de fois est-ce normal ??
Oui c'est normal !
[ C'est la première fois que je vois la règle udev 'IMPORT{program}' et je ne connais pas le programme `usb_id`, donc je zappe ce détail. ]
Autrement, tu peux debugger avec le script suivant pour mieux comprendre les variables qu'udev injecte dans l'environnement (comme ID_VENDOR_ENC, ID_MODEL_ID ou DEVPATH -- où usbX et hostX semblent correspondre au bus/device USB)
#!/bin/bash
attach_storage() {
# vbox script goes here #
}
{
echo "Starting $0"
id
env
echo ""
[[ "$DEVNAME" =~ "/dev/sd[a-z][0-9]" ]] && attach_storage
echo ""
} 2>&1 >>/tmp/toto.log
La redirection devrait inclure les éventuels messages d'erreur de 'attach_storage' dans /tmp/toto.log. Au pire, ils seront lisibles dans le (sys)log d'udev (/var/log/messages sous Fedora).
Bon et puis pour finir, je doute que la fonction attach_storage() soit correcte. Elle est trop complexe à mon goût : `su - root -c ...' semble inutile (udev lance déjà le script en tant que root, non ?) et l'appel à VBoxManage dans attach_storage est un peu foireux ($address ne sert pas ?).
Un `VBoxManage list runningvms` préalable pourrait permettre d'avoir les UUID des machines virtuelles afin de l'utiliser dans `VBoxManage controlvm $MYUUID usbattach $USBUUID|$USBADDRESS`.
Quelques tests manuels en shell sur attach_storage() ne seraient pas de trop.
shell@toto $> export DEVPATH="titototo" DEVNAME="/dev/sda1" (...)
shell@toto $> bash -x /tmp/toto.sh
La règle a l'air correcte. Pense bien à faire un /etc/init.d/udev reload et à vérifier que ton /var/log/{messages,syslog} n'affiche aucun message d'insulte.
Mais ce qui me semble le plus probable, c'est une erreur de permissions : udev ne peut pas lancer d'applications graphiques, ré-essaie avec un simple script shell et non kate.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Johands . En réponse au journal Lamentations ou les remords d'un geek. Évalué à 2.
Aie, j'ai beau avoir relu ces derniers mois des pages de C++, il m'aura fallu ce bon vieux wikipedia pour me remémorer ce qu'est l'Encapsulation_des_données. Alors effectivement, Python ne protège aucune donnée. Mais objectivement ça ne m'a jamais gêné : une règle tacite du python est que toute donnée précédée d'un '_' est interne à la classe. Si le programmeur y touche, il ne doit pas venir pleurer si un futur changement de version cassera son code.
Par contre, j'aimerais plus d'explication concernant :
cette fausse impression de sécurité que le langage te donne en te forçant à tout spécifier
Spécifier quoi ? Alors que justement mon principal reproche envers Python est qu' on n'y déclare rien et que tout y est implicite.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Johands . En réponse au journal Lamentations ou les remords d'un geek. Évalué à 5.
Python est trop dangereux pour les étourdis chroniques : trop de libertés, trop de possibilités d'erreur, trop de canards enrubannés (et parfois même, comme avec GTK+2, des bogues entre les bindings C et la machine virtuelle un peu trop subtiles à mon goût).
Des langages fortement typés comme Haskell ou C/C++ et leurs descendants (Java, Vala?) ne conviendraient-ils pas mieux ? (je ne connais pas Ruby, je ne sais pas ce qu'il en est pour lui). Tant pis pour les fioritures et autres "boilerplate". On a des éditeurs de textes suffisamment puissants aujourd'hui pour ne plus s'en soucier. Tant pis également pour ce méchant compilateur qui n'arrête pas de nous taper sur les doigts. Il faut persévérer, on est tous passé par là et on finit par s'y faire.
S'il le faut, on peut même rajouter une p'tite bibliothèque de tests unitaires. Avec tout ça, on devrait bien réussir à vaincre cette «malédiction» !
[^] # Re: sed/awk
Posté par Johands . En réponse au message Convertir tag bash (couleur) en html ?. Évalué à 2.
On peut par exemple arriver à ceci: http://pastebin.com/M1fVXiLA
/alors Nadal ou Soderling ?
[^] # Re: Toolchain et bibliothèques
Posté par Johands . En réponse au message Cross compilation ARM. Évalué à 2.
Installer le binaire pré-construit sur la cible, ça c'est bon, mais je ne peux pas installer ce même bianire pour ARM sur la debian x86 ?
Tu ne pourras pas exécuter le binaire ARM su la debian x86 (processeur incompatible), donc il n'y a pratiquement aucun intérêt de l'y installer. (sauf si tu aimes t'amuser à configurer des chroot et à faire joujou avec Qemu dedans, mais ceci est une autre histoire).
Par contre, tu peux te créer des dossiers sur ta debian x86 concernant les en-têtes et les bibliothèques dynamiques de tes applications ARM pour ensuite les utiliser avec ton compilateur croisé arm-linux-gcc. Le hic, c'est qu'il ne faut pas mélanger ces bibliothèques avec celle de ta debianx86 et qu'il faut configurer ta "toolchain" (compilateur, linker, ...) pour qu'elle parte chercher ces en-têtes et bibliothèques ARM au bon endroit (-L, -I, manpages, ...). Je n'en connais pas plus sur ce point, désolé.
[^] # Re: C'est moche
Posté par Johands . En réponse au journal Google: Que pasa ?. Évalué à 3.
Il y a un truc qui m'échappe : Google Chrome, Safari et Midori ne sont-ils pas tous basés sur WebKit (à plus ou moins ça près) ?
Alors pourquoi mon joli Midori fait la grimace ? C'est déprimant de voir qu'avec le temps, le support des standards W3C chez certain semble plus se dégrader qu'autre chose ...
# À tout hasard
Posté par Johands . En réponse au message Script U-boot. Évalué à 1.
# BeautifulSoup
Posté par Johands . En réponse au message Analyser un fichier html. Évalué à 6.
You didn't write that awful page. You're just trying to get some data out of it. Right now, you don't really care what HTML is supposed to look like.
Neither does this parser.
[http://www.crummy.com/software/BeautifulSoup/]
Bibliothèque en Python donc idéal pour faire un p'tit script crade et rapidement.
[^] # Re: Autre petit problème
Posté par Johands . En réponse au message Haskell. Évalué à 1.
1 - comme écrit dans la réponse précédente, quand tu joues avec la monad IO, tu ne peux plus en sortir. C'est un des fondements de Haskell : une fonction utilisant des données externes (IO) est impure et doit être confinée à l'écart du code restant. Autrement formulé : il est impossible de convertir un "IO a" en "a".
2 - il est peut-être possible d'éviter la monad IO pour l'instant en préférant randomR et randomRs à randomRIO cf l'API Haskell pour plus de détails.
3 - c'est pas joli de faire des postes en doubles !!
[^] # Re: Indice
Posté par Johands . En réponse au message Haskell. Évalué à 2.
Le hic, c'est que j'ai encore du mal à imaginer une université enseignant l'Haskell en France (ou dans les pays francophones), vu la faible notoriété du langage et l'héritage du Caml.
# Chouette du Haskell !
Posté par Johands . En réponse au message Haskell. Évalué à 2.
[^] # Re: Serveur X
Posté par Johands . En réponse au message problème règle udev. Évalué à 1.
Sur la partie VirtualBox, je n'y connais rien, je ne peux pas aider. Désolé.
Sur la partie udev :
Oui c'est normal !
[ C'est la première fois que je vois la règle udev 'IMPORT{program}' et je ne connais pas le programme `usb_id`, donc je zappe ce détail. ]
Autrement, tu peux debugger avec le script suivant pour mieux comprendre les variables qu'udev injecte dans l'environnement (comme ID_VENDOR_ENC, ID_MODEL_ID ou DEVPATH -- où usbX et hostX semblent correspondre au bus/device USB)
#!/bin/bash
attach_storage() {
# vbox script goes here #
}
{
echo "Starting $0"
id
env
echo ""
[[ "$DEVNAME" =~ "/dev/sd[a-z][0-9]" ]] && attach_storage
echo ""
} 2>&1 >>/tmp/toto.log
La redirection devrait inclure les éventuels messages d'erreur de 'attach_storage' dans /tmp/toto.log. Au pire, ils seront lisibles dans le (sys)log d'udev (/var/log/messages sous Fedora).
Bon et puis pour finir, je doute que la fonction attach_storage() soit correcte. Elle est trop complexe à mon goût : `su - root -c ...' semble inutile (udev lance déjà le script en tant que root, non ?) et l'appel à VBoxManage dans attach_storage est un peu foireux ($address ne sert pas ?).
Un `VBoxManage list runningvms` préalable pourrait permettre d'avoir les UUID des machines virtuelles afin de l'utiliser dans `VBoxManage controlvm $MYUUID usbattach $USBUUID|$USBADDRESS`.
Quelques tests manuels en shell sur attach_storage() ne seraient pas de trop.
shell@toto $> export DEVPATH="titototo" DEVNAME="/dev/sda1" (...)
shell@toto $> bash -x /tmp/toto.sh
Courage !
# Serveur X
Posté par Johands . En réponse au message problème règle udev. Évalué à 5.
La règle a l'air correcte. Pense bien à faire un /etc/init.d/udev reload et à vérifier que ton /var/log/{messages,syslog} n'affiche aucun message d'insulte.
Mais ce qui me semble le plus probable, c'est une erreur de permissions : udev ne peut pas lancer d'applications graphiques, ré-essaie avec un simple script shell et non kate.