jeudi 24 juillet

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Articles précédents : Logiciel

Liens connexes

Communiqué de presse (256 hits)
Article sur sur xulfr.org (659 hits)
L'annonce de Franck Heicker, Directeur Exécutif de la fondation Mozilla (175 hits)
Projet Tamarin (386 hits)

Dépêche modérée par

jerome_misc

Dépêche éditée par

Logiciel : Adobe libère sa machine virtuelle ActionScript 3

Posté par Laurent J (page perso, ). Modéré le 07 novembre 2006.

La machine virtuelle d'ActionScript 3 qui est actuellement incluse dans Flash 9, vient d'être libérée par Adobe et intégrée dans le code de Mozilla, sous les trois licences habituelles de Mozilla : MPL/GPL/LGPL

Adobe et Mozilla vont donc travailler ensemble sur cette machine virtuelle, afin de profiter chacun d'une implémentation complète et performante des futures versions d'Ecmascript (en particulier Ecmascript 2 édition 4), ce qui est l'objectif du projet Tamarin de Mozilla.

Concrètement, le projet Tamarin permettra d'avoir des performances accrues sur l'exécution des scripts javascript dans les pages web, dans les extensions, dans les applications XUL, et donc dans le futur Firefox 3.

Communiqué de presse (256 hits)
Article sur sur xulfr.org (659 hits)
L'annonce de Franck Heicker, Directeur Exécutif de la fondation Mozilla (175 hits)
Projet Tamarin (386 hits)

> Lire la dépêche (60 commentaires, moyenne: 3,5).

Pour rappel, ActionScript est l'implémentation dans Flash 9, du standard Ecmascript. Il s'agit d'un langage de script standardisé par l'organisation internationale ECMA sur lequel sont basés le javascript de Mozilla, et le javascript (plus ou moins complètement) des autres navigateurs. Brendan Heich, "directeur de la technologie" et membre du "board" à la fondation Mozilla, est l'inventeur de Ecmascript/Javascript.

Actuellement, dans Mozilla, le javascript est interprété à la volée. Ce qui veut dire qu'à chaque fois qu'une fonction est appelée, à chaque fois il y a un processus d'interprétation, ce qui est assez coûteux en terme de performance (et la plupart des implémentations de javascript dans les autres navigateurs fonctionnent sur ce principe).

À l'inverse, la machine virtuelle d'Adobe fonctionne sur le même principe que les autres machines virtuelles (Java, Mono...) : elle permet de générer du bytecode à partir des sources javascript, et d'exécuter ensuite ce bytecode autant de fois que nécessaire, opération qui est moins coûteuse que l'interprétation à la volée. Elle permet aussi de faire du JIT (Just In Time) et donc de transformer le bytecode directement en instructions machine.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Et shockwave ?

Posté par yoho (page perso, ) le 07/11/2006 à 15:22. (lien). Évalué à 4.

Il arrive à pied ? On l'attend depuis combien de temps ce plugin sous linux ? J'adorerais que le partenariat se prolonge par le développement d'un tel plugin.

[^]Re: Et shockwave ?

Posté par JoeBar () le 07/11/2006 à 15:29. (lien). Évalué à 10.
"Il arrive à pied ?"
Oui, par la Chine.
- [+] [^]Re: Et shockwave ?
  
  Posté par Pierre Jarillon (page perso, ) le 07/11/2006 à 18:30. (lien). Évalué à -2.
  "Il arrive à pied par la Chine ?" Pas possible, c'est pas un fakir :-)

[+] [^]Re: Et shockwave ?

Posté par omnikron () le 07/11/2006 à 15:37. (lien). Évalué à -5.
Encore un fan de http://www.isketch.net/ :o)

Rectificatif

Posté par Jean-Philippe (page perso, ) le 07/11/2006 à 15:24. (lien). Évalué à 9.

D'après http://www.mozilla.org/projects/tamarin/ et http://www.adobe.com/aboutadobe/pressroom/pressreleases/2006(...) c'est plutôt la version 4 de ECMAScript qui ets implémentée dans Tamarin, version à l'origine de AS 3 (soit flash 9) et Javascript 2, version encore à l'état de brouillon mais presque finie.

En tout cas c'est une bonne nouvelle pour la standardisation du langage Javascript et j'espère que le projet sera repris par les autres navigateurs libre comme konqueror.

Et, encore une note positive (j'ai perdu la source par contre), cette machine virtuelle est disponible pour les 64 bits ce qui voudrait donc dire qu'il y à de grandes chances de voir un flash 9 pour 64 bits

[^]Re: Rectificatif

Posté par Jean-Philippe (page perso, ) le 07/11/2006 à 15:28. (lien). Évalué à 8.
Arf, encore oublié, et perdu la source.
Malgré le fait que Adobe ait libéré (http://blogs.adobe.com/penguin.swf/2006/11/open_source_actio(...) 135000 lignes de code, ils n'ont pas libéré leur soft java qui génère le bytecode pour actionscript (pas bytecode pour javascript 2, ni de JIT pour mozilla donc il me semble)
- [^]Re: Rectificatif
  
  Posté par Laurent J (page perso, ) le 07/11/2006 à 15:45. (lien). Évalué à 5.
  Pourtant, http://lxr.mozilla.org/mozilla/source/js/tamarin/codegen/ ressemble furieusement à de la génération de code machine, donc d'un système JIT ;-)
  
  Je pige pas par contre ton histoire de soft Java ... Y a pas de java dans flash...
  
  Et puis je ne vois pas l'interet d'une machine virtuelle si elle ne génère pas du bytecode....
- [^]Re: Rectificatif
  
  Posté par Laurent J (page perso, ) le 07/11/2006 à 15:54. (lien). Évalué à 5.
  ah je crois comprendre : dans un flash, le code actionscript est déjà sous forme de bytecode, bytecode généré par les outils de dev flash ?
  
  Et il n'y aurait pas alors de parser javascript/générateur de bytecode dans ce qu'ils ont filé ?
  
  C'est probable en effet (je suis pas encore aller tout voir...)
  
  Cependant, spidermonkey sait parser du JS, et comme on a les sources de la machine virtuel, c'est assez "relativement" "aisé" alors de générer du byte code :
  
  parser (spidermonkey) -> génération de bytecode (générateur à développer ?) -> execution du byte code (la machine virtuelle d'adobe)
  - [^]Re: Rectificatif
    
    Posté par Mjules (page perso, ) le 07/11/2006 à 16:51. (lien). Évalué à 3.
    Il y mtasc qui est présenté comme un compilateur pour ActionSCript2 mais je sais pas si ça répond à la problématique :
    http://www.framasoft.net/article3536.html
    http://www.mtasc.org/
    - [^]Re: Rectificatif
      
      Posté par Antoine () le 07/11/2006 à 20:43. (lien). Évalué à 6.
      Il y a surtout haXe qui est le successeur de mtasc, qui permet la compilation d'un langage dédié (ressemblant à ECMAScript, mais avec typage strict, inférence de types...) vers Javascript ou SWF.
      http://haxe.org/
  - [^]Re: Rectificatif
    
    Posté par Jean-Philippe (page perso, ) le 07/11/2006 à 17:09. (lien). Évalué à 5.
    Bon, j'ai retrouvé ma source, je vais dire moins de bêtises :
    http://www.kaourantin.net/2006/11/spidermonkeys-relative-tam(...)
    
    Ce monsieur est ingénieur chez Adobe et travaille sur le flash player, il me semble qu'il travaille main dans la main avec le développeur principal de flash pour linux.
    
    Just the Verifier, JIT, core frameworks and the garbage collection engine are now open source.
    
    Il y aura donc un JIT pour mozilla.
    
    Par contre :
    
    Also important to note: The java based compiler which converts ECMAScript 4 to the byte code understood by Tamarin is not included in this agreement.
    
    Il y a bien du code java pour générer du bytecode ecmascript, code utilisé dans la plate-forme flex (et sûrement dans Flash pour créer les .swf).
    
    Mozilla might adopt the conservative garbage collector even for SpiderMonkey [...] This would be a huge boon for AJAX based applications [...]
    
    D'après ce que j'ai compris ils ont libéré du code qu'ils ont écrit il y a peu pour leur garbage collector (ramasse-miettes), ce qui amène un gros gain de performances rien que pour leur player. On peut donc imaginer la même chose pour mozilla, ce qui ne présage que de bonnes choses :-)
    - [^]Re: Rectificatif
      
      Posté par Olivier Faurax (Jabber id, page perso, ) le 08/11/2006 à 09:21. (lien). Évalué à 3.
      En gros, si j'ai bien compris, le principe, c'est ça :
      ECMAScript --> Bytecode pour Tamarin (compilé) --> execution sur le processeur
      
      Pour l'instant, sur Firefox, on a :
      ECMAScript --> interprétation par SpiderMonkey --> exécution
      
      La compilation est presque tout le temps beaucoup plus efficace que l'interprétation.
      Avec Tamarin, les 2 fonctions principales qui accélèrent sont le JIT (compilatio à la volée) et le ramasse-miette (gestion/récupération de la mémoire à la volée).
      
      Ce qui n'a pa été libéré, c'est la partie :
      ECMAScript --> Bytecode pour Tamarin
      
      Donc, le futur boulot, c'est de mettre Tamarin dans SpiderMonkey pour que SpiderMonkey compile pour Tamarin.
      En gros, c'est :
      ECMAScript --> SpiderMonkey --> Bytecode Tamarin --> exécution
      
      Pour les puristes (ceux qui aiment la purée ;) ), la page Tamarin indique qu'en fait Tamarin sera DANS SpiderMonkey, c'est à dire que c'est le même bidule qui interprète/compile/exécute l'ECMAScript.
      
      Et au final, ils sont pas fous chez Adobe, ils gardent leur avantage concurrentiel, c'est-à-dire l'outil qui génère le code Tamarin depuis des bibliothèques (optimisées) de gestion audio/video.
      
      --
      xmpp:ofaurax@jabber.fr
      - [^]Re: Rectificatif
        
        Posté par Antoine () le 08/11/2006 à 09:29. (lien). Évalué à 5.
        c'est-à-dire l'outil qui génère le code Tamarin depuis des bibliothèques (optimisées) de gestion audio/video.
        
        Pardon ? Tu ne crois pas que le moteur de rendu du lecteur Flash est écrit en ActionScript quand même ?
        
        [^]Re: Rectificatif
        
        Posté par Olivier Faurax (Jabber id, page perso, ) le 08/11/2006 à 10:35. (lien). Évalué à 1.
        T'as raison.
        Je connais pas assez bien Flash.
        
        Mais alors là, je comprends pas pourquoi ils ont par libéré leur compilateur d'ECMAScript vers Tamarin.
        Ça leur permettait d'ouvrir complètement la chaîne de compilation et de proposer une valeur ajoutée en fournissant des bibliothèques audio/video/pdf/etc.
        
        Je sais, on s'en fout, on a SpiderMonkey, mais bon...
        
        --
        xmpp:ofaurax@jabber.fr
        
        [^]Re: Rectificatif
        
        Posté par herodiade () le 08/11/2006 à 13:30. (lien). Évalué à 3.
        Mais alors là, je comprends pas pourquoi ils ont par libéré leur compilateur d'ECMAScript vers Tamarin.
        
        Timic Uro (le chef de proj. Flash chez Adobe) l'explique : parce qu'il n'est de toutes façons pas utilisable pour FF :
        
        * Il est en java (donc déjà, ça le fait pas)
        * Son architecture ne permet pas de gérer l'instruction eval() (donc impossible de le rendre totalement compatible avec le standard ECMAScript 4).
        
        Si je comprend bien le but est maintenant d'écrire le compilateur Ecmascript ... en Ecmascript !
        
        Ref. http://www.kaourantin.net/2006/11/spidermonkeys-relative-tam(...)
- [+] [^]ils n'ont pas libéré ...
  
  Posté par salvaire () le 07/11/2006 à 22:03. (lien). Évalué à -2.
  Perl, Python, Parrot ... sont totalement libérés depuis longtemps eux!
  - [^]Re: ils n'ont pas libéré ...
    
    Posté par Jean-Philippe (page perso, ) le 07/11/2006 à 22:23. (lien). Évalué à 0.
    ECMAScript est totalement libre... la preuve on en a fait javascript, implémenté dans firefox (et surement konqueror)
    - [^]Re: ils n'ont pas libéré ...
      
      Posté par Jebediah Tramo () le 08/11/2006 à 10:06. (lien). Évalué à 5.
      ECMAScript est totalement libre... la preuve on en a fait javascript
      
      Euh non c'est l'inverse, ECMAScript est le descendant normalisé du JavaScript créé par Netscape et de JScript, sa variante microsoftienne.

[^]Autre rectificatif

Posté par alung () le 08/11/2006 à 09:55. (lien). Évalué à 2.
Chez mozilla, ils prévoient plutôt d'implémenter Tamarin dans Firefox 4 et non pas 3.

Cf http://www.mozilla.org/projects/tamarin/faq.html#when

When will Tamarin appear in SpiderMonkey and Firefox?

The Mozilla engineering team currently estimates that Tamarin will be incorporated into shipping versions of SpiderMonkey and Firefox in 2008.

et http://www.hecker.org/mozilla/adobe-mozilla-and-tamarin

The Mozilla project will use Tamarin as part of future versions of SpiderMonkey, the C-based JavaScript engine used in Firefox and other applications, and will include it in future versions of Firefox (beyond Firefox 3) that are built using Mozilla 2 technology.

Penguin.SWF

Posté par faden () le 07/11/2006 à 15:36. (lien). Évalué à 3.

Pour avoir des nouvelles sur le nouveau flash player pour linux :

http://blogs.adobe.com/penguin.swf/

J'ai installé la béta 9 du flash player sur mon linux et ça fonctionne déjà incroyablement mieux que l'ancien flash player 7, en terme de performance et de fonctionnalitées.

[^]Re: Penguin.SWF

Posté par Pascal (page perso, ) le 07/11/2006 à 15:45. (lien). Évalué à 0.
On en a rien à foutre du plugin propriétaire Flash.....

http://www.gnu.org/software/gnash/
- [^]Re: Penguin.SWF
  
  Posté par gentildemon () le 07/11/2006 à 15:58. (lien). Évalué à 6.
  Si on en a rien à faire de cette techno, quelle est l'intérêt d'en développer une implémentation libre ??
  
  A priori, Adobe contrôlant la techno, le but de gnash est d'arriver au même niveau de fonctionnalités que le plugin proprio. Plus le plugin proprio est avancé, plus il y a de boulot pour gnash...
  
  J'ai donc du mal à voir comment on peut s'intéresser à gnash et dire qu'on se moque du plugin proprio flash.
  - [^]Re: Penguin.SWF
    
    Posté par TeraHertZ () le 07/11/2006 à 16:16. (lien). Évalué à 9.
    
    Si on en a rien à faire de cette techno, quelle est l'intérêt d'en développer une implémentation libre ??
    
    On en a pas rien à foutre de cette techno, mais du greffon propriétaire et limitatif! d'où l'implémentation libre d'une alternative.
    
    Maintenant question: est-ce que ça va retarder/faire perdre l'intérêt du SVG?
    
    Il est clair que l'hégémonie dont jouie Flash™ va être difficile à "déstabiliser".
    
    Je persiste à dire que ce qui fait le succès de Flash™ c'est sa platforme de developement, et non le format en soit.
    Bon en effet, il est vrai que les performances sans au rendez-vous comparées à du SVG animé, à ce sujet, il se pourrait bien que la réponse à ma question influe sur les performances des futures "application SVG.
    
    enfin..
    - [^]Re: Penguin.SWF
      
      Posté par Larry Cow () le 07/11/2006 à 17:51. (lien). Évalué à 6.
      On en a pas rien à foutre de cette techno, mais du greffon propriétaire et limitatif! d'où l'implémentation libre d'une alternative.
      
      A contrario, Gnash n'est pas limitatif du tout. Ce qu'on lit, de nos jours, quand même...
      
      Je préfère également une solution libre à une pas libre, mais de là à prétendre qu'une copie incomplète (mais libre) d'un truc propriétaire est _techniquement_ plus accompli que l'original, faut peut-être pas mousser pépé.
      - [^]Re: Penguin.SWF
        
        Posté par TeraHertZ () le 07/11/2006 à 18:07. (lien). Évalué à 7.
        Je n'ai jamais parlé de Gnash, même si il sagit là du prétendant principal, j'ai parlé de la nécessité à en faire une alternative libre car tu as intérpêté le "on en a rien à foutre de ce plugin proprio..." de manière "amalgamante".
        
        En outre, le côté limitatif ce n'est pas trop la capacité qu'a le logiciel à traiter ce genre d'infos mais plutôt le déploiement de celui-ci.
        Par limitatif je voulais donc parler de: du fiat de sa nature proprio, ce qui déjà pue©, cela induit une disponibilité réduite selon O.S. et architecture. Le comble pour un techno qui se veut interopérable ou du moin utilise un media intéropérable, non?
        
        En clair, tu me fais dire ce que je n'ai pas dit.
- [+] [^]Re: Penguin.SWF
  
  Posté par pasBill pasGates () le 07/11/2006 à 23:26. (lien). Évalué à -2.
  T'es gentil mais je ne t'ai pas autorise a parler en mon nom que je sache.
  
  _TU_ n'en as rien a foutre.
  - [^]Re: Penguin.SWF
    
    Posté par atlexx () le 08/11/2006 à 13:48. (lien). Évalué à 4.
    <complètement HS>
    "on",e en français est indeterminé . "on" ne signifie pas "nous" . _TU_ n'as donc pas de raisons de te sentir concerné. Peut être l'auteur de ce commentaire, que je n'approuve pas, connait d'autres personnes inclues dans "on".
    </complètement HS>

[^]Re: Penguin.SWF

Posté par Narishma Jahar () le 07/11/2006 à 15:46. (lien). Évalué à 2.
Par contre en termes de stabilité c'est pas encore ça. Je suis revenu à flash 7 tant ça plantait une fois sur deux...
- [^]Re: Penguin.SWF
  
  Posté par Frédéric COIFFIER () le 07/11/2006 à 16:20. (lien). Évalué à 3.
  Je pense que ces problèmes sont liés à ta configuration.
  Sans faire de ma configuration une référence, je n'ai eu aucun plantage Flash 9 depuis que je l'ai installé... (et pourtant, j'utilise Konqueror sous Gentoo)
  - [^]Re: Penguin.SWF
    
    Posté par Farvardin (page perso, ) le 07/11/2006 à 16:40. (lien). Évalué à 3.
    moi je n'ai pas eu de son, alors je l'ai désinstallé aussi.
    
    --
    Tous ensemble contre l'esclavitude des logiciels privateurs !
    - [^]Re: Penguin.SWF
      
      Posté par Mathieu Pillard (page perso, ) le 08/11/2006 à 08:26. (lien). Évalué à 5.
      C'est vrai que le fait qu'il utilise alsa uniquement sans possibilité de changer le device ca n'aide pas... Ils ont libéré un petit bout de truc qui devrait permettre d'améliorer ca: http://blogs.adobe.com/penguin.swf/2006/10/not_completely_op(...)
      
      Par ailleurs, ils disent qu'il ya des problemes connus avec l'audio:
      http://blogs.adobe.com/penguin.swf/2006/11/chart_toppers.htm(...)
      
      Mais pas de son du tout, ca ressemble plus à un probleme de dmix non présent, et la version 7 devait utiliser oss ou esd...
      
      Sinon, moi j'attends toujours un support pulseaudio mais je dois etre le seul :-)
- [^]Re: Penguin.SWF
  
  Posté par olebrun () le 07/11/2006 à 21:50. (lien). Évalué à 1.
  Aucun problème ici sous archlinux. Et pourtant je l'utilise de longue heure pour un projet nécessitant flash 9.

[^]Re: Penguin.SWF

Posté par ploum (page perso, ) le 07/11/2006 à 20:18. (lien). Évalué à 6.
ah ben chez moi ça freeze tout le temps et le son disparait.

Je vais tenter de reproduire le bug après avoir recompilé la version de debug et faire tourner le tout dans gdb. Je pourrais poster une trace sur le bugzilla.

Ah tiens non, c'est proprio.

Tant pis.
- [^]Re: Penguin.SWF
  
  Posté par Mathieu Pillard (page perso, ) le 08/11/2006 à 08:28. (lien). Évalué à 3.
  Tu peux quand meme reporter le bug (apparamment il faut une inscription, enfin jetable.org / bugmenot sont la pour ca :-)
  
  http://www.adobe.com/cfusion/mmform/index.cfm?name=fp_beta_f(...)

Une pièce du puzzle

Posté par Ontologia (page perso, ) le 07/11/2006 à 15:46. (lien). Évalué à 10.

La dépèche tombe à point car est récemment tombé sur les téléscripteurs et en particulier le magazine "décision informatique" la nouvelle du lancement d'Applo par Adobe qui se veut rien de moins que le concurent de .Net et Java.

Apollo est une plateforme constituant un environnement d'exécution basé sur les technologies Flex/Flash, Html/Ajax ainsi qu'un moteur PDF.
Des fonctionnalités permettant de gérer le mode déconnecté sont inclus dans la plateforme.

Avec cette technologie, plus besoin de navigateur, en effet, ils utilisent carrément WebKit, l'évolution Made by Apple de KHTML avec un moteur JavaScript.

Avec tout cela, on aura des applications Ajax/Flex/PDF sur le poste de travail qu'il sera difficile de différencier d'une application standard. Le socle pèsera de 5 à 9 Mo, soit sensiblement moins que Java ou .Net

Côté performances, JIT+Webkit en sus des autres technologies assez éprouvées (Flash, Flex, Html, CSS, Javascript, Ajax), on devrait avoir de très bon résultats.

Une belle bataille en perspective, et un concurent de plus poussant vers l'ouverture...

[^]Re: Une pièce du puzzle

Posté par Laurent J (page perso, ) le 07/11/2006 à 15:59. (lien). Évalué à 8.

lancement d'Applo par Adobe qui se veut rien de moins que le concurent de .Net et Java.

et concurrent de Mozilla avec Xulrunner !!

XulRunner permet de faire ce que fait Appollo (d'ailleurs Flex est une copie de XUL). http://xulfr.org/wiki/XulRunner

Bref, XulRunner permet de lancer des applis faites avec XUL / HTML / SVG / XBL / Javascript / python / Ajax et toutes l'api XPCOM de gecko
- [^]Re: Une pièce du puzzle
  
  Posté par spotty () le 07/11/2006 à 16:17. (lien). Évalué à 1.
  Appolo : une machine virtuel dont tous les outils seront proprio et qui ne supporteront que Windows.
  
  Quelle est la différence entre Appolo et ActionScript ? Les objectifs ont l'air similaire
  
  http://linuxfr.org/~spotty/23027.html
  - [^]Re: Une pièce du puzzle
    
    Posté par Ontologia (page perso, ) le 07/11/2006 à 16:30. (lien). Évalué à 6.
    Non leur objectif est clairement d'être multi plateforme : comme beaucoup ils parient sur l'hétérogénéité croissante des plateformes, Linux y compris.
    
    Ca sera surement pas mal propriétaire malheureusement, mais ça sera multi plateforme, sinon ça n'a aucun intérêt. C'est le discours de Kevin Lynch, le vice-président d'Adobe.
- [^]Re: Une pièce du puzzle
  
  Posté par Clément varaldi (page perso, ) le 08/11/2006 à 09:02. (lien). Évalué à 4.
  Sauf que pour maitriser Xulrunner et faire avec ce machin quelque chose qui ressemble à une application, il faut comme tu le dis maitriser (et pas bidouiller) beaucoup plus de langages que ce que pourrait proposer Apollo.
  
  C'est d'ailleurs cette multiplicité de composants a tambouiller ensemble, qui m'a fait abandonner l'idee de regarder plus avant le xul & tout ce qui traine autour.
  - [^]Re: Une pièce du puzzle
    
    Posté par golum () le 08/11/2006 à 12:14. (lien). Évalué à 3.
    Il me semblait que la technologie Flex était propriétaire et fermée
    S'il est de bon ton de critiquer Java et ses techno associées pour leur aspect proprio et leur hypothétique ouverture. Que doit-on alors penser de Flex
    Ne serait-ce donc pas plus profitable d'améliorer Xulrunner que de le critiquer.
    - [^]Re: Une pièce du puzzle
      
      Posté par Clément varaldi (page perso, ) le 08/11/2006 à 13:18. (lien). Évalué à 3.
      Hola, moi, le bon ton... :) Tu sais, la critique, ça peut aussi être constructif, et loin de moi l'idée de dire que Flex c'est génial et qu'on devrait abandonner Xulrunner :)
      
      Améliorer Xulrunner ? J'en serais bien incapable.
      
      Améliorer Xulrunner dans le "bon" sens, pour moi, reviendrait à mon avis proposer un IDE capable d'ajouter une abstraction (gigantesque) capable de masquer l'usage du plus grand nombre de techno possibles.
      Prenons la liste de Laurent :
      
      XUL / HTML / SVG / XBL / Javascript / python / Ajax et toutes l'api XPCOM de gecko
      
      Un IDE+framework devrait être capable, pour rendre xulrunner "technologiquement accessible" de supprimer la nécessité de connaître XUL+SVG+XBL+Ajax, et de n'avoir plus qu'une interface pour faire tout ça.
      
      Un parallèle tout bête : ruby on rails, qui est vachement à la mode, te permet de faire de l'Ajax sans toucher à une ligne de javascript. Tu dois connaître le ruby et le HTML. J'aime développer les parties utiles d'une application avant toute chose. XUL me donne l'impression de devoir passer un temps fou sur les détails, avant de pouvoir commencer à coder la partie rellement utile.
      
      Donc, dans notre cas, l'Ajax serait interfacé dans le framework avec des appels simples à des routines. Le XUL serait plutôt à comparer à une sorte d'interface builder (Mac) ou son équivalent GNUStep dont j'ai oublié le nom.
      
      Typiquement, tout ce qui est interface devrait être wysywygable : si je veux faire une application efficace, rapidement, avec xulrunner, je n'ai pas envie de m'agacer avec les détails. Quitte à retoucher un chouilla le code derrière si j'en ai vraiment besoin et que j'ai quelques notions.
      
      Le XUL et xulrunner sont une formidable idée, mais l'accès est réellement rébarbatif. Et améliorer Xulrunner et l'environnement qui tourne autour nécessite une connaissance poussée de tous les domaines qui y touchent, et donc il faut y toucher un jour, ce que je me refuse plus ou moins à faire.
      Je préfère très largement me faire une interface à l'ancienne, qui n'utilisera qu'un seul langage, mais que je maitrise, plutot que d'essayer de devoir jongler avec une dizaine de technologies juste pour avoir une fenêtre de texte dans une frame qui se rafraichit toutes les 10 secondes, une barre d'url et un bouton de rafraichissement manuel.
      
      La plus grande avancée pour moi, que pourrait avoir XUL, et qui pourrait me faire changer d'avis, serait d'avoir un interface builder pour XUL.
      - [^]Re: Une pièce du puzzle
        
        Posté par Laurent J (page perso, ) le 08/11/2006 à 13:52. (lien). Évalué à 3.
        
        Et améliorer Xulrunner et l'environnement qui tourne autour nécessite une connaissance poussée de tous les domaines qui y touchent, et donc il faut y toucher un jour, ce que je me refuse plus ou moins à faire.
        
        Ouai alors là, tu exagère pas mal. Les milliers d'extensions qui existent pour Firefox montre qu'il ne faut pas des connaissances aussi poussées que ça.
        
        Et puis tu parles de X langages à apprendre.
        
        Mais tu oublie de dire que dans ton langage avec X libraries, il faut bien apprendre aussi les apis de tes X libraries.
        
        Franchement, pour faire du dessin 2D par exemple, je ne vois pas de différence entre apprendre une api Java et apprendre une API XML (SVG).
        
        C'est une illusion "d'optique" que de voir en un ruby, un java ou autre, que c'est plus simple parce qu'il y a soit disant qu'un langage.
        
        XML = un langage. Et chaque "API" est représenté par une grammaire.
        
        [^]Re: Une pièce du puzzle
        
        Posté par Clément varaldi (page perso, ) le 08/11/2006 à 16:05. (lien). Évalué à 5.
        Si je ne peux pas exagérer, comment veux-tu que je lance un troll dans des conditions décentes ?
        
        Moi, pour ce que j'ai vu : j'ai voulu faire une page en XUL. Il a fallu pour ça, du XML, du js, du css, du html, du rdf. La meme chose avec une structure plus "classique" de page web : js, css, html. J'ai deux éléments, XML certes, mais dont il faut connaître le schéma (faire des aller retour vers la doc pour comprendre comment qu'on actualise un Tree -par exemple- n'est pas une option : je veux que ma page marche, et qu'elle soit prête à temps). D'ailleurs à la même époque, j'en connais qui avaient fait une interface web en XUL. Ça date de 2 ans. L'interface n'est plus accessible avec les dernières versions de Firefox -du moins sous windows, cad la cible visée, et solaris- (la 1.5 plantait déjà, la 2.0 aussi, avec un pourcentage d'occupation mémoire assez important). Mon appli web js/css/html classique, elle, tient toujours.
        
        X langages : oui, tous ou presque se résument à du XML, du js, et 2/3 trucs. Mettons que je maîtrise le XML. Il faut que j'apprenne toutes les grammaires liées à chaque XML, et celles-ci ne sont pas toujours intuitives (pour moi, et c'est purement subjectif).
        
        Imaginons : je veux faire une visionneuse d'images png :
        avec Xulrunner&Co, il faut que j'installe Xulrunner (facile, quoique mon dernier essai sous mac os, qui remonte à un peu plus d'un an, n'avait pas du tout été concluant, mais je crois savoir que ça a fortement progressé de ce côté là). Il me faut ensuite comprendre/connaître toutes les grammaires, apprendre au minimum le js, css, html. Il y a au minimum 2 langages (js, XML), et plusieurs API/grammaires.
        Avec un bon vieux perl, je dois installer perl (soit), tk (par exemple). Ensuite, je dois apprendre perl, et comprendre/connaître juste l'api de base de tk. Il n'y a qu'un langage, et une api.
        
        Pour moi, y'a pas photo : je connais assez de js, css, html, et assez de perl, pour penser aller plus vite à faire mon appli en perl/tk qu'en xul. Et il existe des perl2exe.
        Chacun a ses avantages, et ses inconvénients. C'est pour ça que je dis que XUL est une idée formidable, mais ça ne me convient absolument pas. D'autant que j'ai dans de nombreux langages des générateurs qui me permettent de construire la base de mes sources plus rapidement.
        C'est aussi en ça que je dis que XUL pêche par son absence de combinaison IDE/Framework.
        
        Pour finir : je persiste : si je veux améliorer Xulrunner en réalisant par exemple une sorte d'IB à la XCode/GNUStep, il faut quand même avoir plus que de sérieuses bases dans l'ensemble des technos mises en oeuvre. Et ça, ce n'est clairement pas accessible à tout le monde.
        
        Conclusion : collaborer à des projets comme XUL, c'est une super méthode d'apprentissage pluri-disciplinaire avant de pouvoir maîtriser l'engin.
  - [^]Re: Une pièce du puzzle
    
    Posté par Laurent J (page perso, ) le 08/11/2006 à 13:46. (lien). Évalué à 3.
    
    il faut comme tu le dis maitriser (et pas bidouiller) beaucoup plus de langages que ce que pourrait proposer Apollo.
    
    Pour maitriser le minimum, il faut pas plus que dans apollo :
    
    apollo propose Flash, Flex, Html, CSS, Javascript, Ajax
    xulrunner propose SVG, XUL, Html, CSS, Javascript, Ajax (et d'autres choses mais tout n'est pas obligatoire).
    
    Sachant que Flex = XUL like, et que flash, faut l'apprendre aussi au même titre que SVG.
    
    Donc je vois pas bien en quoi ce sera plus compliqué d'apprendre les langages en question dans xulrunner...
    
    (reste le manque d'un environnement de dev wysiwyg, mais y a dejà des plugins eclipse pour faciliter le dev d'appli xulrunner.)
    - [^]Re: Une pièce du puzzle
      
      Posté par Clément varaldi (page perso, ) le 08/11/2006 à 16:22. (lien). Évalué à 2.
      Sauf que Apollo a un avantage énorme : il dispose d'un environnement de développement plutôt complet et éprouvé. Entre faire une animation flash toute conne et faire une animation SVG toute conne, chacun avec les outils existants... J'en trouve un plus simple et intuitif que l'autre. Flex a aussi son environnement de dev, je ne sais par contre pas ce qu'il vaut. Pour le HTML/CSS, on peut utiliser dans les deux cas des éditeurs très bien (NVu par exemple). L'intégration d'un élément flash dans une page HTML n'est pas corcée. Dans l'autre sens, j'y crois moins. L'Ajax, avec xulrunner, on va utiliser un truc genre openrico, on va donc écrire ses requêtes à la mimine en js dans le html.
      
      Alors oui, bon, apollo, je n'ai jamais pu tester, mais je suis d'accord avec l'un des commentaires d'avant : c'est excessivement prometteur en terme de fonctionnalités.
      
      Ça me donne toujours l'impression que le libre a de nombreux outils puissants. Tres puissants. Efficaces. Mais mis bout à bout, ça devient beaucoup moins fun. Quand je vois l'environnement de développement proposé par apple (xcode) et microsoft (visual), je me dis qu'on n'a pas encore atteint ce niveau. Peut-être est-ce du a la multiplicité des langages et technologies : là où apple se concentre sur objective-c et cocoa/carbon, on se retrouve avec un nombre infini de langages, d'api, toutes différentes. Qu'il faut réussir à interconnecter.
      
      (et voilà, je pars encore en live... Faudra un jour que j'apprenne à ne pas écrire au fil de ma pensée :D)
      - [^]Re: Une pièce du puzzle
        
        Posté par Ontologia (page perso, ) le 09/11/2006 à 08:58. (lien). Évalué à 5.
        Je pense aussi qu'un des grands désavantage du monde libre est le manque criant d'IDE de développement vraiment à la hauteur.
        Les gens restent coincés sur vi/emacs.
        Ces deux logiciels sont très puissant, mais c'est pas un AGL où je peux gérer la base de données, dessiner l'IUH, couplé à une doc véritablement claire, aidé d'assistants d'écriture de code.
        
        Bon oui, ya Eclipse, mais ça va pas aussi loin quand même.
        
        Et j'ai pas d'équivalent à Flash pour faire du Svg.
        
        [^]Re: Une pièce du puzzle
        
        Posté par boubou (page perso, ) le 10/11/2006 à 08:39. (lien). Évalué à 2.
        
        Bon oui, ya Eclipse, mais ça va pas aussi loin quand même.
        
        Aussi loin que quoi ? Eclipse a quelques défauts (on se perd dans l'interface et il faut bien 1Go de mémoire pour être à l'aise), mais j'ai du mal à voir ce qu'il ne fait pas...
- [^]Re: Une pièce du puzzle
  
  Posté par Olivier Faurax (Jabber id, page perso, ) le 08/11/2006 à 10:15. (lien). Évalué à 3.
  Bien vu !
  Mais Xulrunner utilisera aussi Tamarin.
  
  En fait, Mozilla et Adobe mettent en commun leurs efforts pour créer une VM pour concurrencer Java et .Net.
  
  A mon avis, leur principal avantage sera que cette VM servira en même temps pour les applis "web (n+1).0" et pour les applis locales.
  
  Java avait essayé ça, mais la partie web (applet) n'a pas bien marché (on en voit plus tellement).
  A mon avis, voici quelques raisons :
  - il faut installer le plugin
  - il faut tout le JRE pour que le plugin fonctionne
  - la JVM Microsoft arrange pas la perception de la technologie ("Tu as Java ?" "Oui, mais ça marche pas bien", alors que le Java en question était celui de MS, j'ai eu le cas il y a 2 jours)
  
  Là, on a plus de chances que ça marche : la VM est installé avec le navigateur dans la cas de Firefox, ou avec le player Flash pour les autres.
  
  --
  xmpp:ofaurax@jabber.fr

[^]Re: Une pièce du puzzle

Posté par Yannick (page perso, ) le 07/11/2006 à 17:25. (lien). Évalué à 1.
> Le socle pèsera de 5 à 9 Mo, soit sensiblement moins que Java ou .Net

L'environnement d'éxecution Java (JRE) pèse moins de 16 Mo, programme d'installation compris. A ne pas confondre avec l'environnement de développement (JDK) (50Mo).
Certe, c'est plus gros que 9 Mo, mais ça reste petit.
- [^]Re: Une pièce du puzzle
  
  Posté par wismerhill (page perso, ) le 07/11/2006 à 20:22. (lien). Évalué à 3.
  Et ça m'étonnerais qu'appollo propose une API aussi complète que celle de java (je ne connais pas .net), en tout cas pour les premières versions. Et le JRE 1.2 (pour windows) ne pesait que 5Mo.
  
  D'ailleurs, appollo sera-t-il seulement destiné au développement d'autre chose que des applications graphiques?
- [^]Re: Une pièce du puzzle
  
  Posté par Gniarf () le 07/11/2006 à 21:43. (lien). Évalué à 1.
  ou pas.
  
  --
  Windows has no users. It has hostages.

impémentation ou implantation ?

Posté par Mathieu () le 07/11/2006 à 17:49. (lien). Évalué à 0.

Pour rappel, ActionScript est l'implémentation dans Flash 9, du standard Ecmascript.

Doit-on utiliser le terme "implanter" ou "implémenter" ?

D'après http://linux-france.unixtech.be/prj/jargonf/I/impleacmentati(...) il y a une différence mais "implémenter" ne serait pas juste un angliscisme? :-s

[^]Re: impémentation ou implantation ?

Posté par Joël SCHAAL () le 07/11/2006 à 18:12. (lien). Évalué à 4.
Dans mon idée, tu implantes un complexe indutriel mais tu implémentes une factory.
- [^]Re: impémentation ou implantation ?
  
  Posté par boubou (page perso, ) le 10/11/2006 à 08:42. (lien). Évalué à 2.
  Voilà exactement. C'est ce que dit le Grand Robert. Peut être que les vieux croutons de l'académie et les nazes des commissions terminologiques ont inventé autre chose, mais implémenter est passé depuis suffisamment longtemps dans la langue courante pour que le Grand Robert, référence assez incontestable, ne le considère pas (ou plus) comme un anglicisme...

[^]Re: impémentation ou implantation ?

Posté par plic () le 07/11/2006 à 21:25. (lien). Évalué à 4.
mais "implémenter" ne serait pas juste un angliscisme? :-s

Si. Comme "mature".

--
«La faculté de citer est un substitut commode à l'intelligence» — Sommerset Maugham

[^]Re: impémentation ou implantation ?

Posté par Gohar () le 08/11/2006 à 14:13. (lien). Évalué à 2.
Et comme "consistant" pour "consistent" (au lieu de "cohérent"). C'est agaçant, voici un mot qui a perdu toute signification: même dans un texte non traduit de l'anglais, on ne sait plus si celui qui l'utilise veut dire "cohérent" ou "consistant". (Sur le sujet, voir Politics and the English language d'Orwell, http://www.mtholyoke.edu/acad/intrel/orwell46.htm )

Pour "to implement", on peut utiliser "mettre en oeuvre".

[+] Une seule réponse :

Posté par ギヨム () le 07/11/2006 à 21:37. (lien). Évalué à -1.

noscript! (^^)

Moi j'ai pas confiance

Posté par Zakath (page perso, ) le 07/11/2006 à 23:29. (lien). Évalué à 9.

Les langages basés sur ecmascript, on sait ce que ça vaut. Je leur préfère largement leurs bien meilleures alternatives vmiscript.

-->[ ]

--
Vous devriez vraiment visiter Aperture First !

[^]Re: Moi j'ai pas confiance

Posté par gnujsa () le 08/11/2006 à 00:52. (lien). Évalué à 2.
Moi aussi !
http://www.vim.org/scripts/

Nouveau langage

Posté par espace () le 10/11/2006 à 20:12. (lien). Évalué à 1.

D'ailleurs (je sais pas si ça a déjà été dit), mais la VM d'Adobe c'est pas seulement du JIT en plus, c'est surtout une VM pour JavaScript2, un nouveau langage qui apporte le typage statique au précédent, et c'est surtout ça qui explique les meilleurs performances à mon avis ! (par contre vu qu'actuellement tout est fait en JS1, pas encore trop d'intérêt ... )

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Adobe libère sa machine virtuelle ActionScript 3

Et shockwave ?

[^]Re: Et shockwave ?

[+] [^]Re: Et shockwave ?

[+] [^]Re: Et shockwave ?

Rectificatif

[^]Re: Rectificatif

[^]Re: Rectificatif

[^]Re: Rectificatif

[^]Re: Rectificatif

[^]Re: Rectificatif

[^]Re: Rectificatif

[^]Re: Rectificatif

[^]Re: Rectificatif

[^]Re: Rectificatif

[^]Re: Rectificatif

[+] [^]ils n'ont pas libéré ...

[^]Re: ils n'ont pas libéré ...

[^]Re: ils n'ont pas libéré ...

[^]Autre rectificatif

Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[+] [^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

[^]Re: Penguin.SWF

Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

[^]Re: Une pièce du puzzle

impémentation ou implantation ?

[^]Re: impémentation ou implantation ?

[^]Re: impémentation ou implantation ?

[^]Re: impémentation ou implantation ?

[^]Re: impémentation ou implantation ?

[+] Une seule réponse :

Moi j'ai pas confiance

[^]Re: Moi j'ai pas confiance

Nouveau langage