hsyl20 a écrit 228 commentaires

À noter aussi que la version 2.0.1 de FFADO (pilotes pour les cartes sons FireWire) est sortie dimanche dernier. Je vous traduis la longue liste des changements :

* Passage de l'ancienne "pile" FireWire du noyau à la "nouvelle"

C'est une très bonne nouvelle car ça faisait un moment que quasiment tout le monde était passé à la nouvelle pile (qui date de 2007).

Tout à fait d'accord. Je suis dans le même cas (ie celui à qui on demande de venir dépanner) et XP+Internet dans les mains de néophytes est vraiment un combo fatal.

Entre les anti-virus/pare-feux (mises à jour, fin de période de validité...), les spywares/adwares/msn/virus, les drivers (imprimantes/*box/webcam/clés usb/...) qui installent tout et n'importe quoi, à moins de s'en occuper régulièrement, on finit toujours par avoir un tas de choses qui ne fonctionnent plus.

Bref, je compatis :)

L'inculte qui ne sait pas ce que signifie "germany" ? Quel bel exemple !

Finalement ils ont réinventé Edje qui existe dans E17 depuis un moment. C'est pas que c'est mal, mais ils auraient pu le faire plus tôt.

http://trac.enlightenment.org/e/wiki/Edje

Alors pourquoi ne pas le faire complètement en Java sans se baser sur un navigateur ?

Pas faux. ;-)

Oui mais je n'ai pas compris l'intérêt de cette question. Ce serait une vraie question sans propagande pour finir sur une note positive ?

Note : ils disent que 50% des médicaments vendus illégalement sur le web sont des faux. Ils ne parlent pas de ceux vendus légalement (si ça se trouve c'est pire).

Effectivement c'est de la grosse propagande ce quizz. Pour ceux qui n'auraient pas envie de le faire :

1) Produit le plus représenté dans les contrefaçons : évidemment ce sont les CD/DVDs

2) À partir de quand une oeuvre (sous-entendue non libre) peut-elle être reproduite librement en France : choix entre jamais, 150 et 70 ans... Pour bien montrer que finalement ça pourrait être pire et que 70 ans c'est pas si mal... Et la petite explication "on dit qu'elle tombe dans le domaine public" : comme dirait Sébastien Canevet ( http://domaine-public.net/ ), elle n'y tombe pas, elle s'y élève.

3) Les brevêts c'est bien. Exemple : la tour Eiffel !

4) Barack ce héros a aussi déposé son "Yes we can!".

Oui d'autant plus qu'on n'est pas limité au type Option. Si on veut ajouter la cause de l'échec, on peut utiliser le type Either par exemple :

def getMachinById(id:ID): Either[Machin, String] = {
  ...
  if (machinUnavailable) Right("Machin non disponible")
  else if (machinKaputt) Right("Machin cassé")
  else Left(machin)
}

getMachinById(id) match {
  case Left(a) => /* utiliser a (le machin renvoyé) */
  case Right(msg) => println("Echoued with error: "+msg)
}

Enfin bref, tout sauf null !

Je n'ai jamais dit que c'était sans bug/faille etc. Heureusement, en 2010 HTML/CSS/JavaScript est sûr : http://linuxfr.org/~Julien04/29612.html

Je ne parle pas d'applet (appliquette ? ;-) ) Java mais d'application Java. Donc je ne parle pas du cas où tu voudrais manipuler les éléments de ta page (quelle idée aussi) à partir de Java.

Ce que je voulais dire c'est qu'on est en train de réinventer, en se basant sur des technologies inadaptées, ce qui existe déjà et qui a été conçu pour. Quand on voit ce que prévoit HTML5, c'est du n'importe quoi :
* API for playing of video and audio which can be used with the new video and audio elements.
* An API that enables offline Web applications.
* An API that allows a Web application to register itself for certain protocols or media types.
* Editing API in combination with a new global contenteditable attribute.
* Drag & drop API in combination with a draggable attribute.
* API that exposes the history and allows pages to add to it to prevent breaking the back button.

Bref je suis pour qu'on sépare clairement le Web simple et statique (textes + images + vidéos, liens = document) des applications qui utilisent Internet. Le mélange des genres sans avoir préalablement réfléchi au problème devient une usine à gaz...

Je connais des gens qui sont réfractaires à l'idée d'installer la JVM parce qu'elle est trop grosse. Peut-être que la modularisation les fera changer d'avis.

Si ça pouvait améliorer la vitesse de démarrage de la JVM pour les applications WebStart, ce serait génial. Peut-être qu'on pourrait enfin avoir de vraies applications WebStart à la place des "applications web 2.0" écrites dans des langages en mousse non adaptés et pas vraiment portables (différences de rendus, différentes fonctions supportées...) et qui s'exécutent dans des VM navigateurs super lents car pas faits pour ça, qui en plus utilisent un protocole réseau non adapté (HTTP), sous-exploitent TCP, ignorent UDP, et réinventent la gestion des fenêtres/onglets et autres widgets alors que ça n'est pas leur rôle.

Bref tout ce qui fait qu'en 2010 on arrive à faire ramer un Core I7 en surfant sur ce qu'est devenu le Web (et oui une appli Java est au moins aussi rapide qu'un firefox exécutant du JavaScript, et sans parler de Flash).

À quand le support de la 3D accélérée directement dans HTML pour pouvoir faire des applications comme http://bytonic.de/html/jake2_webstart.html (qui existe depuis plus de 3 ans)...

Tu peux d'ores et déjà mixer des projets écrits en Java et en Scala. En particulier, le plugin Maven le supporte [1] et le plugin Eclipse aussi (pour le reste je ne sais pas, mais ça ne veut pas dire que ça n'est pas supporté).

Ça te permet d'avoir des classes écrites en Java ou en Scala dans un même projet et de migrer progressivement. Tu dois même pouvoir faire des choses un peu crade du type :
Tu as une classe A pour laquelle tu veux réécrire la méthode toto en Scala.
1) Tu renommes la classe A en A_Old (package private, tout ça) et tu la déclares abstraite
2) Tu rends la méthode toto abstraite
3) Tu crées une classe A en Scala qui hérite de A_Old et qui implémente la méthode toto.
Je ne sais pas si c'est recommandable, mais bon ça doit être possible.

[1] http://scala-tools.org/mvnsites/maven-scala-plugin/usage_jav(...)

L'intérêt de transformer du code source Java en code source Scala est assez limité (du code Scala écrit à la mode Java perd tout l'intérêt de Scala). À mon avis ça doit être possible et assez peu compliqué vu qu'il y a une correspondance (mais pas une bijection) entre les concepts Java et Scala. Ça pourrait être envisagé pour faciliter la migration de certains codes effectivement.

Par contre des travaux sont en cours pour passer du code Scala en code Java afin de rassurer les décideurs qui voudraient choisir Scala tout en conservant une porte de sortie.

http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerC(...)
http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerC(...)

En fait le fait d'utiliser Option te force à prendre en compte le cas null/None.

Vu autrement, quand tu as une variable de type A, tu es sûr que c'est bien un A et que tu peux appeler les méthodes de A sans craindre de NPE (Null-Pointer Exception).

Dans la sémantique Java, tu ne peux jamais être sûr qu'une fonction qui renvoie un A ne te renvoie pas null à un moment. Le seul moyen de le savoir est de regarder dans la doc ou de tester à l'exécution.

En Scala/Haskell, une fonction qui renvoie un A renvoie un A. Si jamais il se peut qu'elle ne puisse pas en renvoyer pour une raison quelconque, alors son type de retour est Option[A] et non A et les utilisateurs de la fonction doivent prendre en compte le cas None.

Ça peut servir aussi quand tu veux chaîner des fonctions. Exemple en Java :
a = getA()
if (a == null) abort else {
  b = a.getB()
  if (b == null) abort else {
    c = b.getC()
...
}

L'équivalent si les get renvoyaient des Option serait :
val v = getA().flatMap(_.getB()).flatMap(_.getC())
v match {
  case Some(c) => ...
  case None => abort
}

ce qui peut s'écrire aussi:
val v = for (a <- getA(), b <- a.getB(), c <- b.getC()) yield c
v match {
  case Some(c) => ...
  case None => abort
}

Et oui, null c'est mal :
http://www.infoq.com/presentations/Null-References-The-Billi(...)

D'où les types Maybe (en Haskell) ou Option (en Scala).
En Scala :
val a:Option[A] = uneFonctionQuiRenvoieUnAOuPas()

À partir de là on peut soit :
a match {
  case Some(x) => // c'est bien un A
  case None => //le cas "ou pas"
}

Ou alors :
val s = a.getOrElse(valeurSiPasUnA)

Voir aussi orElse, orNull, etc.

Finalement c'est que je disais il y a deux jours ;-)
http://linuxfr.org/comments/1120526.html#1120526

Personnellement, j'ai pris un lecteur/graveur DVD externe alimenté par deux prises USB. Pratique pour installer certains jeux et encoder des CDs audio. Pour le reste, c'est vrai que ça ne sert plus à grand chose (pour installer une distro maintenant avec une clé USB c'est encore mieux que par CD).

Même si on disait il y a 10 ans qu'il n'était pas sexy, il n'y avait pas vraiment d'alternative au _langage_ Java reposant sur le même socle technique (VM portable, garbage-collector, typage statique fort, bibliothèque standard très complète, etc.). En 2010 les alternatives existent (C#, F#, Scala...).

comparer bêtement point à point Java et scala, serait une erreur
Je ne pense pas. Les deux langages offrent effectivement des choses fort différentes mais avec l'un des deux il est possible de faire exactement ce que fait l'autre (avec le même style, les mêmes concepts, les mêmes bibliothèques) sans être cependant limité à ça. Donc on peut tout à fait les comparer.

Java est un bon choix pour les projets importants, qui ont besoin de stabilité, de pérennité, d'outillage et de compétences. C'est un langage de grosse entreprise ou de fournisseur de lib/framework.
Les développeurs de Scala essaient au maximum de conserver la stabilité de l'API et de l'ABI (au niveau du bytecode) avec quelques exceptions inévitables lors de certains changements majeurs. Pour la pérennité, Scala est sous license type BSD. Pour l'outillage, ça se développe (plugins pour Maven, Eclipse, NetBeans et autres IDE) mais ça n'est bien sûr pas au niveau de Java pour l'instant. À noter que le plugin Maven permet de mixer du code Java et Scala facilement. Pour les compétences, ça se développe petit à petit ;-)

Les libs/frameworks écrits en Scala sont utilisables à partir d'application Java, Clojure, Groovy ou autres...

Je ne sais pas ce qui caractérise un langage de grosse entreprise.

Mais en général ce ne sont pas la souplesse d'un langage ou tes préférences personnelles qui te feront choisir un langage. Tes contraintes vont déjà fortement élaguer les différentes possibilités.
Justement mes contraintes sont d'écrire un compilateur pour un DSL (Domain-Specific Language). Donc les options sont soit de le faire à l'ancienne (C/C++, Yacc, Bison, etc.) et d'y passer 10 ans, soit d'utiliser les facilités de certains autres _langages_ (parser combinator, embedded DSL...). J'ai vite choisi ! Mais effectivement je n'ai pas de contrainte provenant de clients.

Comparons avec Scala :

côté bibliothèque standard [...] au niveau de la VM (Open JDK) [...]

Scala a accès à la bibliothèque standard Java et utilise la JVM donc bonne nouvelle.

- Support des fermetures. Y'a eu tellement de discussions que j'ai meme pas cherché à suivre...

Scala les supporte. Exemple :
val maListe = List(1,8,34,74,785,16)
val uneValeur = 18
val maClosure = (a:Int) => a + uneValeur // <-- La closure est ici
val maListePlusUneValeur = maListe.map(maClosure)

On peut raccourcir :
val maListe = List(1,5,4,78,8)
val uneValeur = 17
val maListePlusUneValeur = maListe.map(_ + uneValeur)

- Nettoyage automatique des ressources à la sortie d'un bloc. On déclare en début de bloc les ressources que l'on utilise et quand on sort du bloc les méthodes de nettoyage sont automagiquement appelées. Le but est d'éviter le code relou de nettoyage dans les finally et d'éviter les leaks


La question a encore été posée aujourd'hui sur #scala :-) Ça s'implémente facilement sans modifier le langage.
http://stackoverflow.com/questions/2395984/scala-using-keywo(...)

- Extension des annotations pour pouvoir les placer un peu plus partout. Un des buts est de pouvoir placer des annotations pour aider les analyseurs statique (indiquer qu'un champ peut être nul ou pas par exemple)


En Scala il est préconisé de n'utiliser "null" que pour la compatibilité avec des classes écrites en Java. Sinon on utilise le type algébrique Option pour remplacer les types "nullables".

Pour les annotations, à priori ça doit être équivalent à celles de Java au moins.

- Inférence de type (ami du CAML pas la peine d'hurler :p ) plus besoin de doubler la déclaration des generics lors d'un new. Map<List, Integer> map = new Map<>(). Merci pour nos petits doigts !


Scala utilise massivement l'inférence de type (et surtout avec des types paramétrés qui peuvent être bien plus compliqués qu'en Java). Ton exemple donnerait :
val map = new Map[List, Integer]() (enfin il faudrait paramétrer List aussi, mais bon c'est un exemple)

- Possibilité de faire des switch/case sur des string


Scala supporte le pattern-matching. Par exemple avec le type Option cité plus haut :
val a:Option[Integer] = Some(5)
...
a match {
   case Some(x) => //code qui peut utiliser "x" qui vaut 5 ici
   case None => // cas où "a" serait "null" (enfin l'équivalent avec Option...)
}

Avec les strings ça fonctionne pareil :
str match {
   case "brol" => ...
   case "troll" => ...
}

Pour les exceptions, on utilise du pattern-matching aussi (comme en Java sauf qu'ils ne le disent pas explicitement). Du coup on peut faire du "multicatch" :
try {
   ...
} catch {
   case e:SQLException => println("Database error") //Comme en Java
   case e:MalformedURLException
   | case e2:URLenBois => println("Bad URL") //multicatch
   case e => { //catch par défaut
     println("Some other exception type:")
     e.printStackTrace()
   }
}

Pour la surcharge des opérateurs, en fait le concept d'opérateur n'existe pas en Scala, ce sont des méthodes de classe :
5 + 7 est équivalent à 5.+(7)
Du coup on peut définir les opérateurs qu'on veut (à quelques limitations près). Exemple :
monActeur !! monMessage
(envoie un message à l'acteur avec une syntaxe qui reprend celle d'Erlang).

Ça permet de faire des choses concises comme :
(0 /: maListe)(_ + _)
qui est plus lisible (une fois habitué...) que : maListe.foldLeft(0)((a:Int,b:Int) => a +b)

Voir aussi les parsers du type :
val parser = "void" ~ ident ~ "(" ~ repSep(param, ",") ~ ")" ~ ";" ^^^ {
   println("Déclaration de procédure parsée !!!")
}

Bref, Scala c'est bon, mangez en. Et c'est déjà dispo. En plus, la prochaine release (2.8) apportera les paramètres nommés, les valeurs par défaut, etc. Et la beta est assez stable :-) http://www.scala-lang.org/node/1564

http://www.codecommit.com/blog/scala/roundup-scala-for-java-(...)

Pour ceux que ça intéresse, j'ai traduit l'interface de Clementine en français hier.
Ça vient d'être committé dans le trunk. La version dans le trunk est stable et fonctionnelle actuellement donc pas de soucis pour l'utiliser.

De toutes façons Scala a été sélectionné, c'est bien ça le principal. ;-)

Parce que globalement un noyau real-time est un peu moins performant.

Par défaut le noyau ne peut pas être interrompu par un thread même si celui-ci a une haute priorité. On considère que de toutes façons le traitement effectué par le noyau ne va pas durer longtemps.. sauf que pour du real-time ça peut quand même être trop long.

L'idée c'est donc de faire en sorte que les threads de haute priorité puissent interrompre un traitement du noyau. Les mécanismes permettant ça (implémentation des spinlocks avec des rtmutexes) coûtent un peu plus cher.

À noter aussi qu'avec un noyau real-time il faut être plus prudent. Une application qui a les privilèges pour être exécutée en haute-priorité peut bloquer le noyau si elle est mal écrite (cf [2]).


[1] http://rt.wiki.kernel.org/index.php/Frequently_Asked_Questio(...)

[2] http://rt.wiki.kernel.org/index.php/RT_Watchdog

Pour ceux qui suivent ce journal (il y en a ?), une nouvelle version est disponible. Elle gère sommairement la collection locale (fichiers téléchargés) pour pouvoir les rejouer ou les supprimer.

Effectivement le prix moyen indiqué sur Audiofanzine est une erreur (29euros, le prix de l'alimentation en fait...).

Par contre pour 149 euros, on peut avoir une Fast Track Pro chez Thomann donc pour une audiophile c'est un peu cher :
http://www.thomann.de/fr/maudio_fast_track_pro.htm

En moins cher, il y a :
http://www.thomann.de/fr/maudio_transit_usb_audiointerface.h(...)

Apparemment ça fonctionne sous Linux aussi.