JamyGourmand:
Comment tu fais pour accéder à ton bios avec notre carte mère buguée?
Parce que même en me branchant en VGA ça passe pas ...
Dark_Chouhartem > Pour le coup je trouve que faire du JS natif (ou avec de simples préprocesseurs comme CoffeeScript) est plus raisonnable. Écrire du JS avec du Ruby/Python/Clojure/C++/Foo ça implique de savoir parfaitement ce que fait le compilateur à tout moment, et y'a pas mal de 'cool tricks' qu'on doit réinventer parfois difficilement dans le langage proxy.
Enfin ça reste pratique, mais j'ai du mal à donner toute ma confiance à ces outils (ou plutôt, confiance en ma capacité à utiliser ces outils sans faute). Surtout que généralement, quand le projet est de taille conséquente, on vérifie pas rigoureusement tout le code généré...
@Caletlog Je te donne l'exemple précis qui m'a dérangé : https://github.com/welldan97/assemble-jade/blob/ae0d7211f2256b2f4e650c086cab449a2370b7a7/src/assemble-jade.coffee#L44-L48
Je suis désolé mais quand la fonction fait plus de 3 lignes (et encore, je dirais presque une ligne), ne pas mettre le `return` nuit pas mal à la compréhension du code, du moins ça oblige à réfléchir, voir remonter l'indentation pour voir qu'on est à la fin d'une fonction.
Et puis dans le même code :
init = ->
Juste ça. Pour définir une fonction vide. Mais on le voit pas au premier coup d'oeil, faut vérifier l'indentation des lignes suivantes d'abord. En Python on aurait au moins eu un `pass` qui dit clairement que la fonction ne fait rien, et ça aide beaucoup à comprendre.
@Dark_Chouhartem Je suis d'accord avec Caletlog, faut quand même avoir une certaine confiance dans le compilateur pour commencer à compiler n'importe quoi vers du JS. Même si on a pour la plupart pas envie de faire du JS natif, c'est souvent la solution la plus sérieuse pour avoir un minimum de contrôle sur son code. Pas de mauvaises surprises sur les "hacks" utilisés pour émuler certines fonctionnalités. Par contre, pas de bonnes surprises sur certaines optimisations que peut faire le compilateur non plus.
Ah ouais il se passe quoi? T'as bien qu'un seul écran vga de branché?
Si tu peux accéder à q flash essaye de mettre à jour le firmware
Y'a un sourd ici ?
Je vais voir de le mettre à jour
J'ai essayé de pleins de manières différentes, avec un seul écran à chaque fois oui
J'ai même enlever la CG
Et quand je vais sur le bios j'ai en haut marqué un truc du style 'gigabyte uefi dual bios', mais rien d'autre, je peux rien faire à part reboot
Eviklovesyou il ne me semble pas, mais pourquoi cette question ?
vava > ah oui je vois. Dans ce cas-là, c'est effectivement stupide. Les simples accolades de l'objet auraient rendu le tout beaucoup plus clair. Et dans ces cas-là, je pense pas qu'on ait besoin d'un return : à partir du moment où on sait que la dernière expression évaluée est renvoyée, c'est plutôt naturel (sauf dans ton cas, mais c'est clairement un abus sur la souplesse des hashes/objets, pas sur le return. Je pense d'ailleurs pas que le return eut été possible en cumul de l'objet sans accolades, mais pas sûr).
Enfin en soit le return est pas particulièrement chiant à mettre, mais je trouve que son absence répond à un 'problème' assez logique : pourquoi considérer par défaut qu'une fonction ne renvoie rien (donc 100% effets de bord), et le renvoi de quelque chose considéré comme un cas spécial (puisqu'on doit utiliser explicitement un return), alors qu'en pratique, les propensions à utiliser ces cas sont inversées ?
Avec le renvoi auto de la dernière expression évaluée, on a la situation inverse, plus 'proche' de la réalité : on renvoie par défaut toujours quelque chose, et il faut spécifier explicitement si on ne veut rien renvoyer.
+ ça encourage à faire des méthodes compatibles avec le chaînage, mais ça c'est encore autre chose
Pour les fonctions vides, c'est comme de partout : mieux vaut mettre un commentaire sur la même ligne ou dans un bloc vide pour dire qu'on est conscient qu'elle est vide, et que c'est pas une erreur. C'est toujours plus lisible.
JamyGourmand :
J'arrive à accéder à un menu (via la touche Fin), mais je peux rien faire là
Reboot obligé
Je testerai ça plus tard sans CG/avec un autre écran
@Caletlog
« Enfin en soit le return est pas particulièrement chiant à mettre, mais je trouve que son absence répond à un 'problème' assez logique : pourquoi considérer par défaut qu'une fonction ne renvoie rien (donc 100% effets de bord), et le renvoi de quelque chose considéré comme un cas spécial »
J'avais jamais vu les choses sous cet angle, c'est vrai que ça a l'air assez logique comme ça.
Reste le fait que quasiment personne ne met un `return` vide quand il ne veut rien retourner.
Mais bon, la plupart du temps ça ne pose pas de problème.
vava740 & Caletlog Mais ça fait peur le js
Pas avec les bons outils
EmberJS
Pas avec les bons outils
jQuery
mv foo/* .
rmdir foo
-- Directory not empty
mv foo/.* .
rmdir foo
La seule et unique raison pour laquelle j'utilise rmdir et pas rm dans ces cas là.
tu peut aussi juste faire "mv foo" et ça fera le couper/coller que tu demande quoi
Et si il reste des trucs t'utilise rm -rf, des outils simples pour une solution simple
Toujours impossible d'accéder à ce foutu bios
Pareil pour le menu qflash
C'est rageant
@ChiageDeLuna Je voulais déplacer tout le contenu de `foo` dans le dossier courant, je vois pas comment tu fais ça avec `mv foo`.
Bah -rf là justement j'évite, j'aurais perdu mon .git.
Caletlog Ember.js a quoi de plus que les autres (par exemple
Angular ou Backbone) ? Je pose cette question parce que j'aimerais bien apprendre à me servir d'un framework javascript front-end, mais je sais pas trop lequel choisir...
Les gars, vous auriez pas un lecteur de musique graphique, en GTK+, et qui soit pas trop bloaté ?
http://www.commentcamarche.net/news/5865167-mozilla-firefox-la-publicite-arrive
90% des revenus de Mozilla viennent de google?