BORDEL DE CACHE DE MERDE, J'AVAIS POURTANT VÉRIFIÉ POUR NE PAS POSTER EN DOUBLE ! _o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
J'invoque la cabale et m'auto-moinsse virtuellement.
...
Et pour le peine (ahah), je suicide mon compte (un de plus) !
Je connais pas grand chose au montage audio/vidéo ou au multimedia en général, mais n'y a-t-il pas certaines contraintes particulières plutôt incompatibles avec un OS grand public "normal"[0] ?
Par exemple, le fameux patch temps réel d'Ingo Molnar n'est-il pas nécessaire, et si oui n'a-t-il pas des effets néfastes sur une utilisation plus classique ?
[0] : reste la question : "comment font les autres ?"
Le chargement de code je n'en ai pas la moindre idée.
En ce qui concerne un éventuel GC concurrent, un fil de discussion relativement récent sur la liste de diffusion dédiée au langage[0] a fourni une réponse intéressante de la part de Damien Doligez, "GC wizard" de la team OCaml :
Il semble que l'obstacle soit plus philosophique que technique tout compte fait (bien que les difficultés d'implantation soient réelles), et que l'équipe attende d'avoir quelque chose de plus propre et élégant que threads et mémoire partagée pour offrir cette possibilité.
Le mail se terminant par "In summary, you shouldn't hold your breath.", ça ne semble pas être pour tout de suite.
<hypothèses>
Il y a d'autres projets liés à la concurrence et la distributivité à l'INRIA, certains assez liés à OCaml, comme JoCaml. Peut-être que l'équipe Gallium attend quelque chose de ce coté, et préfère se concentrer sur d'autres aspects pour l'instant ?
</hypothèse>
Tu pointes (à mon avis) les deux plus gros défauts d'OCaml à l'heure actuelle.
À l'image des implantations actuelles de Ruby ou Python, les threads d'OCaml ne tirent pas partie du multi-coeur : il me semble que c'est lié au glaneur de cellules (GC) et aux difficultés liées à la mise en oeuvre d'une version concurrente de ce dernier.
certaines structures sont abscons (obligé de mettre +. au lieu de + pour une addition flottante, c'est du jamais vu)
Ça veut dire quoi, "certaines structures sont absconses" ?
Et merci de ne pas généraliser à tous les langages fonctionnels une spécificité (un défaut ?) d'OCaml, ils ne sont pas tous typés statiquement et tous ne haïssent pas le polymorphisme ad-hoc (cf. typeclasses en Haskell).
l'environnement de devel est pitoyable
De quoi parles tu ? Emacs ? Vim ? Emacs + Caml-mode ? Emacs + Tuareg ? Camlwin (bwahahah) ?
Mais je suis d'accord, il n'y a rien de très évolué... Toutefois ce n'est pas le seul langage ou les libristes se contentent du triptyque éditeur de texte + shell + make.
C'est pas encore très organisé et je ne sais pas si ça correspond exactement à ta demande et tes besoins. Happs est celui qui a le plus le vent en poupe, récemment il a été utilisé pour écrire http://hpaste.org
Bon, déjà, ca troll à mort pour dire que comparer à Compiz, Metisse est vraiment utile lui...
Bon, je répondrais la dessus que David Raveman se fout du "eye candy" dans compiz,[...]
Euh, c'est moi ou Metisse c'est un projet de recherche de Paris 11 (Orsay) sur les interfaces graphiques à la base ?
Donc un truc/framework avec de grosses possibilités mais actuellement pas trop prévu pour le grand public et surtout pas pour le "eye candy" ?
jDAO, mapping objet-relationnel reposant sur le design pattern DAO (Data Access Object), se basant sur des fichiers déclaratifs en XML et prenant en charge la génération automatique des requêtes SQL, des problématiques de sécurité (SQL injection etc...)
Pourquoi cet emploi de "problématique" à la place de "problème" ?
Je tente une réponse (c'est pas mon domaine alors je vais peut-être dire des conneries, je préviens) :
lguest/lhype[0] est un hyperviseur permettant d'exécuter plusieurs instances du noyal Linux en parralèle.
Je ne sais pas dans quelle mesure c'est comparable à UML, ou au travail récent sur les vkernel de DragonFly BSD.
paravirt_ops est une interface écrite par Rusty Russel, également un des auteurs de lguest, permettant simplement l'ajout "propre" d'un hyperviseur dans un noyau Linux.
Je crois que c'est une structure C de pointeurs de fonctions, ces dernières représentant des opérations très bas niveau, et sert donc d'interface avec la machine pour le reste du noyau.
Si un noyau classique va prendre une structure contenant les fonctions avec "vraies opérations" et s'exécuter directement sur le hardware, un hyperviseur peut fournir des fonctions arbitraires (par exemple appeller un autre OS "au dessus") : en ajoutant une couche d'indirection au noyau, on peut supporter de façon transparente des "modes d'exécution" potentiellement très différents.
VMWare avait proposé une autre interface (ptet un poil plus élégante), VMI, ou une ROM binaire fournissait les services virtualisés, mais ça n'avait pas plu aux devs (binaire pas libre dans le noyau toussa).
Encore une fois, c'est *juste* ce que j'ai compris, y a ptet des erreurs ou approximations.
[^] # Re: .
Posté par mouftard . En réponse au journal [mavie] Je refuse de monter dans l'ascenceur.... Évalué à -6.
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
_o/* BLAM ! Double post will die !
J'invoque la cabale et m'auto-moinsse virtuellement.
...
Et pour le peine (ahah), je suicide mon compte (un de plus) !
# .
Posté par mouftard . En réponse au journal [mavie] Je refuse de monter dans l'ascenceur.... Évalué à -8.
AHAH, OWNED !
# .
Posté par mouftard . En réponse au journal [mavie] Je refuse de monter dans l'ascenceur.... Évalué à 10.
[^] # Re: bof
Posté par mouftard . En réponse au journal Ubuntu Studio. Évalué à 4.
Par exemple, le fameux patch temps réel d'Ingo Molnar n'est-il pas nécessaire, et si oui n'a-t-il pas des effets néfastes sur une utilisation plus classique ?
[0] : reste la question : "comment font les autres ?"
# ...
Posté par mouftard . En réponse au journal un post a partir de n800 :). Évalué à 5.
[^] # Re: Fin d'XP
Posté par mouftard . En réponse au journal [News] [vente liée] c'est fini !. Évalué à 9.
[^] # Re: Bémol !?
Posté par mouftard . En réponse à la dépêche OCaml summer project. Évalué à 2.
En ce qui concerne un éventuel GC concurrent, un fil de discussion relativement récent sur la liste de diffusion dédiée au langage[0] a fourni une réponse intéressante de la part de Damien Doligez, "GC wizard" de la team OCaml :
http://caml.inria.fr/pub/ml-archives/caml-list/2006/09/7fbdc(...)
Il semble que l'obstacle soit plus philosophique que technique tout compte fait (bien que les difficultés d'implantation soient réelles), et que l'équipe attende d'avoir quelque chose de plus propre et élégant que threads et mémoire partagée pour offrir cette possibilité.
Le mail se terminant par "In summary, you shouldn't hold your breath.", ça ne semble pas être pour tout de suite.
<hypothèses>
Il y a d'autres projets liés à la concurrence et la distributivité à l'INRIA, certains assez liés à OCaml, comme JoCaml. Peut-être que l'équipe Gallium attend quelque chose de ce coté, et préfère se concentrer sur d'autres aspects pour l'instant ?
</hypothèse>
[^] # Re: Bémol !?
Posté par mouftard . En réponse à la dépêche OCaml summer project. Évalué à 2.
À l'image des implantations actuelles de Ruby ou Python, les threads d'OCaml ne tirent pas partie du multi-coeur : il me semble que c'est lié au glaneur de cellules (GC) et aux difficultés liées à la mise en oeuvre d'une version concurrente de ce dernier.
Pour le chargement de code dynamique, en effet le module http://caml.inria.fr/pub/docs/manual-ocaml/libref/Dynlink.ht(...) ne gère que le chargement de bytecode, et ne peut donc pas ètre utilisé dans un programme compilé vers du code natif.
[^] # Re: Tout bon!
Posté par mouftard . En réponse à la dépêche OCaml summer project. Évalué à 2.
Prouve le.
Idem.
C'est pas ce qu'en dit http://www.ffconsultancy.com/free/ray_tracer/comparison.html par exemple.
Ça veut dire quoi, "certaines structures sont absconses" ?
Et merci de ne pas généraliser à tous les langages fonctionnels une spécificité (un défaut ?) d'OCaml, ils ne sont pas tous typés statiquement et tous ne haïssent pas le polymorphisme ad-hoc (cf. typeclasses en Haskell).
De quoi parles tu ? Emacs ? Vim ? Emacs + Caml-mode ? Emacs + Tuareg ? Camlwin (bwahahah) ?
Mais je suis d'accord, il n'y a rien de très évolué... Toutefois ce n'est pas le seul langage ou les libristes se contentent du triptyque éditeur de texte + shell + make.
As-tu essayé Cameleon2 (moi pas) http://gna.org/projects/cameleon/ ?
[^] # Re: Et ?
Posté par mouftard . En réponse au journal Windows Vista Internals. Évalué à 6.
[^] # Re: t'es fou
Posté par mouftard . En réponse au journal Vous pouvez maintenant éteindre Internet et reprendre une activité normale. Évalué à 10.
[^] # Re: Convivialite, j'écris ton nom
Posté par mouftard . En réponse au journal L'appel au spam de Ségolène Royal. Évalué à 8.
# Ahahah
Posté par mouftard . En réponse au journal L'appel au spam de Ségolène Royal. Évalué à 9.
1/ de respecter "la charte nethique" (c'était nécessaire de refaire une netiquette ?) qui affirme "Prenez garde aux trolls."
2/ de poster des commentaires pro-socialistes sur le blog de Loïc Le Meur
C'est d'une cohérence...
Sinon, Eolas va surement apprécier.
# .
Posté par mouftard . En réponse au journal Naissance de la LiMo Foundation. Évalué à 10.
~ 95% des PC ?
[^] # Re: Seaside et squeak :-)
Posté par mouftard . En réponse au journal J2EE vs RoR vs Python. Évalué à 4.
Hmmm, y a rien d'aussi "sexy" que RoR/Django/... actuellement, mais on peut quand même noter l'existence de :
http://happs.org
http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH(...)
http://www.cs.chalmers.se/~d00nibro/hsp/
http://darcs.haskell.org/~lemmih/hasp/
C'est pas encore très organisé et je ne sais pas si ça correspond exactement à ta demande et tes besoins. Happs est celui qui a le plus le vent en poupe, récemment il a été utilisé pour écrire http://hpaste.org
# Euh
Posté par mouftard . En réponse au journal Metisse dans mandriva!. Évalué à 7.
Euh, c'est moi ou Metisse c'est un projet de recherche de Paris 11 (Orsay) sur les interfaces graphiques à la base ?
Donc un truc/framework avec de grosses possibilités mais actuellement pas trop prévu pour le grand public et surtout pas pour le "eye candy" ?
[^] # Re: typo?
Posté par mouftard . En réponse au journal Mac-Fuse on the road. Évalué à 6.
[^] # Re: Quel est l'intérêt de passer à Vista?
Posté par mouftard . En réponse au journal Vista : trop cher ?. Évalué à 10.
Plus intéressants que les jeux DirectX 10 qui ne sont pas encore sortis ?
[^] # Re: errata
Posté par mouftard . En réponse au journal Test de la Slackware 11.0. Évalué à 4.
[^] # Re: errata
Posté par mouftard . En réponse au journal Test de la Slackware 11.0. Évalué à 4.
[^] # Re: anti-racisme = racisme
Posté par mouftard . En réponse au journal La Cnil dérive.... Évalué à 2.
Sublime.
"Il faut que les historiens travaillent et continuent à travailler."
Pierre Vidal-Nacquet serait-il un fiéffé révisionniste ?
http://www.anti-rev.org/textes/VidalNaquet96a/body.html
[^] # Re: halala...
Posté par mouftard . En réponse au journal Sauvez nous, voyageurs de la ligne 13. Évalué à 10.
/me qui gagne tous les jours 24h de repos en étant mort
# [HS]Question vocabulaire
Posté par mouftard . En réponse au journal Jelix 1.0 beta 1. Évalué à 2.
Pourquoi cet emploi de "problématique" à la place de "problème" ?
[^] # Re: Par l'absurde
Posté par mouftard . En réponse au journal KDE4 sous Mac, Windows et ... Linux ;). Évalué à 2.
N'est-ce pas l'inverse ?
[^] # Re: Questions en passant : lhype/lguest
Posté par mouftard . En réponse à la dépêche VirtualBox passe son code en OpenSource. Évalué à 6.
lguest/lhype[0] est un hyperviseur permettant d'exécuter plusieurs instances du noyal Linux en parralèle.
Je ne sais pas dans quelle mesure c'est comparable à UML, ou au travail récent sur les vkernel de DragonFly BSD.
paravirt_ops est une interface écrite par Rusty Russel, également un des auteurs de lguest, permettant simplement l'ajout "propre" d'un hyperviseur dans un noyau Linux.
Je crois que c'est une structure C de pointeurs de fonctions, ces dernières représentant des opérations très bas niveau, et sert donc d'interface avec la machine pour le reste du noyau.
Si un noyau classique va prendre une structure contenant les fonctions avec "vraies opérations" et s'exécuter directement sur le hardware, un hyperviseur peut fournir des fonctions arbitraires (par exemple appeller un autre OS "au dessus") : en ajoutant une couche d'indirection au noyau, on peut supporter de façon transparente des "modes d'exécution" potentiellement très différents.
VMWare avait proposé une autre interface (ptet un poil plus élégante), VMI, ou une ROM binaire fournissait les services virtualisés, mais ça n'avait pas plu aux devs (binaire pas libre dans le noyau toussa).
Encore une fois, c'est *juste* ce que j'ai compris, y a ptet des erreurs ou approximations.