Mono Sortie de Moonlight 1.0

Posté par . Modéré par Mouns.
Tags :
4
13
fév.
2009
Mono
Moonlight est une implémentation open-source de Silverlight (le moteur de rendu vectoriel de Microsoft destiné au Web) pour Linux et systèmes d'exploitation Unix/X11. Cette première version est le résultat d'un effort conjoint entre Novell et Microsoft. Moonlight est distribué sous forme de greffon pour Firefox 2 et 3.

Cette version 1.0 implémente l'API Silverlight 1.0 (avec une compatibilité avec la pile multimédia 2.0 - moins le support DRM). L'implémentation passe toutes les suites de tests de régression de Microsoft et est distribuée avec les packs Multimédia de Microsoft pour architectures x86 et x86-64.

Moonlight 1.0 est écrit en C++ et ne contient pas l'environnement d'exécution ECMA CLI. L'interaction avec le greffon se fait en utilisant le moteur Javascript du navigateur. Moonlight est distribué sous la licence LGPL v2.

Avec Silverlight 2.0 (et dans le futur Moonlight 2.0), un nouveau modèle d'interaction est disponible sous la forme d'un environnement d'exécution .Net, permettant d'interagir avec le greffon en utilisant n'importe quel langage supporté par .Net (C#, VB#, Boo, IronRuby, IronPython, ...).
  • # Vendredi....OK, Target Locked ..... OK.... FIRE!

    Posté par (page perso) . Évalué à  10 .

    Je m'interroge sur Mono et sa popularité.
    Ok, la technologie est ouverte, apparemment il ne plane plus ou peu de menaces en ce qui concerne les brevets (suis pas tout-à-fait au point là dessus cela dit), certes, why not. Et techniquement c'est costaud.
    Cela dit, programmer dans le libre, c'est essentiellement une question d'envie, d'appétence, et pas seulement une question technique. Comment attirer une communauté, dont la philosophie générale compte lors de l'adoption d'une techno, pour un produit qui est une implémentation d'un truc venant d'une des sociétés les plus méprisante vis à vis du libre ?
    J'ai fait personnellement du C# il y a quelques années et j'ai techniquement apprécié. Ce qui m'a fait arrêter c'est cette drôle de sensation. Un peu comme si on mangeait un excellent filet de perche du Nil. L'impression de participer à quelque chose dont l'origine me gêne...
    Vous me répondrez "bin lis pas la news et passe ton chemin" et vous auriez raison. Mais c'est vendredi et ma maman a dit que je pouvais :)

    Chippeur, arrête de chipper !

    • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

      Posté par (page perso) . Évalué à  8 .

      Non non je suis d'accord avec toi. Pourtant, n'étant pas développeur, le sentiment que j'ai se situe plus du côté utilisateur.

      Je sais pertinemment que je n'irai pas installer ce plugin... aussi parce que je ne vais pas me plier au caprice d'un géant qui arrive une fois la course terminée comme d'habitude, mais qui va, par tous les moyens, tenter d'imposer sa solution à coût de dollars vers quelques sites web clés.

    • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

      Posté par . Évalué à  4 .

      Cela dit, programmer dans le libre, c'est essentiellement une question d'envie, d'appétence, et pas seulement une question technique.

      D'un autre côté, vu le nombre de projets libres en Java, l'appétence n'est pas tant un problème que ça.
      • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

        Posté par . Évalué à  10 .

        * Sun a bien moins une réputation d'anti-libre que MS ;
        * Sun libère Java sous licence GPL (c'est pas fini, c'est pas complet mais y a déjà du concret) ;
        * Java a toujours été multi-plateforme, et c'est Sun qui a fait le travail. Pour C#/.Net/Silverlight/... MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).
        • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

          Posté par . Évalué à  4 .

          * Sun libère Java sous licence GPL (c'est pas fini, c'est pas complet mais y a déjà du concret) ;

          C'est assez récent, et les projets libres en Java ne sont pas un phénomène récent.

          * Sun a bien moins une réputation d'anti-libre que MS ;

          et

          * Java a toujours été multi-plateforme, et c'est Sun qui a fait le travail. Pour C#/.Net/Silverlight/... MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).

          Correct. Rien à redire. Si ce n'est que ce n'est pas tant sur l'aspect "libre" de Java que mon "appeal-detector" tiquait. J'étais plus sur le langage lui-même : sa syntaxe, les pratiques qui lui sont associées, etc.
          • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

            Posté par . Évalué à  3 .

            "J'étais plus sur le langage lui-même : sa syntaxe, les pratiques qui lui sont associées, etc. "
            Là par contre, j'ai pas compris...
            • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

              Posté par . Évalué à  7 .

              Vu que c'est vendredi, je me permettais de faire remarquer que Java, c'est l'antithèse du langage "attirant" : verbeux en diable, favorisant des cycles de développement poussifs, nécessitant un environnement de développement lourdingue, générant des applications mal intégrées à leur entourage, etc.
              • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                Posté par . Évalué à  7 .


                Vu que c'est vendredi, je me permettais de faire remarquer que Java, c'est l'antithèse du langage "attirant" : verbeux en diable, favorisant des cycles de développement poussifs, nécessitant un environnement de développement lourdingue, générant des applications mal intégrées à leur entourage, etc.

                Ayant eu aujourd'hui à maintenir un bout de code ruby pourtant pas crade, je peut te dire qu'il existe des langages bien pires que Java.
                J'avais oublié à quel point le duck typing ca faisait faire coin coin a ton programme quand il s'exécute et qu'il passe a l'endroit ou tu as oublié de changer le nom d'une fonction renommée, ou encore le bonheur de pas avoir une exception de levée lors d'un dépassement d'index dans un tableau
                Pour faire des scripts pas trop gros cela dit c'est sympa ruby
                • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                  Posté par . Évalué à  1 .

                  Ayant eu aujourd'hui à maintenir un bout de code ruby pourtant pas crade, je peut te dire qu'il existe des langages bien pires que Java.

                  Certes (brainfuck et goto++, c'est pas pour les chiens), mais Java est probablement le plus mauvais rapport "agrément/chance de tomber dessus".

                  J'avais oublié à quel point le duck typing ca faisait faire coin coin a ton programme quand il s'exécute et qu'il passe a l'endroit ou tu as oublié de changer le nom d'une fonction renommée,

                  Je connais très mal Ruby (voire pas du tout), mais quel rapport entre le duck-typing (ou fait de juger du type d'un "truc" en fonction de ses capacités/caractéristiques utiles plutôt que selon une déclaration préalable) et ton problème de symbole introuvable (qui si je ne m'abuse aurait été réglé tout seul par un "refactor" automatisé)?

                  ou encore le bonheur de pas avoir une exception de levée lors d'un dépassement d'index dans un tableau

                  Encore une fois, Ruby n'est pas tellement mon domaine, et je n'irais pas le défendre bec et ongles. M'enfin ça me paraît fou qu'il ne gère pas un truc pareil.

                  Mais bon, si on va par là, les langages qui imposent aux exceptions d'être des classes, alors que la plupart du temps une simple chaîne suffirait amplement...
                  • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                    Posté par . Évalué à  3 .

                    Le "refactor automatisé" est largement moins simple avec du Duck Typing, à priori, tu peux moins facilement t'appuyer sur les types pour détecter que telle méthode doit être refactorée parce qu'elle est dans la bonne classe, et pas une autre.
                  • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                    Posté par . Évalué à  4 .

                    Le duck typing c'est du typage dynamique, vérifié uniquement à l'exécution. Ca peut devenir tres pénible qand tu as des grosses modifs à faire parce qu'il faut exécuter le programme et le faire passer par chaque branche pour voir si il se vautre pas sur une stupide erreur. Le refactoring ca peut surement aider dans certains cas, mais rien ne vaut une moulinette qui détecte les erreurs de facon 100% fiable.

                    Pour le coup du tableau en ruby, je suis peut etre fou, mais pourtant ce code ne génère pas d'erreur :

                    #!/usr/bin/ruby
                    array=[1,2]
                    print array[999]


                    #./test.rb
                    nil


                    Quand aux exceptions qui sont des classes je vois pas trop le probleme.
                    Ca doit etre surement moins couteux à l'execution et ca permet de vérifier le type d'erreur de maniere efficace et maintenable (en cas de renommage de l'exception le compilo te gueule dessus).
                    Je n'arrive pas à y voir d'inconvénient évident.

                    Ca va paraitre trollesque, mais quand je dois coder un truc dans ce genre de langages, j'ai un peu l'impression de faire un grand retour dans le temps à la glorieuse époque du VB6, sans le "OPTION EXPLICIT" bien sur
                    • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                      Posté par . Évalué à  4 .

                      c'est normal que ton ruby ne génère pas d'erreur, ce n'en est pas une. Tu demandes d'afficher la 999 entrée d'un tableau. Cette entrée n'existe pas, il te renvoies nil (non initialized). Il te dit donc qu'elle est vide/n'existe pas, c'est un comportement correct selon moi. Je ne vois donc pas où est le problème. Mais bon je n'ai jamais codé en java, alors peut-être qu'un dev java voit des erreurs la ou il n'y en a pas.
                      • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                        Posté par . Évalué à  4 .

                        Non, c'est pas une erreur à proprement parler dans la sémantique de ruby, mais ce genre de comportement peut induire des erreurs difficiles à détecter.

                        En gros, en java, si tu fais un dépassement de capacité sur un tableau, le programme te plantera immédiatement à la gueule en te disant "eh ! t'as dépassé la capacité du tableau".


                        En ruby, ton programme continuera un moment de tourner, et plantera potentiellement (ou pas) plus loin, et l'erreur sera donc potentiellement nettement plus difficile à remonter.

                        Après bien sûr t'as des bonnes pratiques pour éviter ça, utiliser des collection et des iterateurs, tester des trucs, mais en cas d'erreur, ce qui arrive à tout le monde, tu vois la différence pour débugger ce genre de langages.
                      • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                        Posté par . Évalué à  4 .

                        Dans 99.99% des cas, un index qui dépasse est un comportement non voulu, donc un bug.

                        Java te renvoie une exception, tu vois qu'il y a eu dépassement (et ou il a eu lieu), tu te retrouves avec un bon point de départ pour corriger le bug.

                        Ruby fait planter le programme autre part à cause d'un nil (ou encore pire lui fait produire des résultats faux), tu peux passer du temps à chercher l'erreur.

                        Pour avoir codé dans les deux langages je peut dire que le comportement de java dans ce cas simplifie beaucoup plus la vie du développeur
                        • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                          Posté par . Évalué à  3 .

                          Je ne nie pas qu'envoyer une erreur ne simplifie pas la vie d'un dev, je dis juste que ce n'est pas une erreur en soit.

                          Quand je manipule un tableau sous ruby, je pars du principe qu'il n'a pas de taille finie. C'est effectivement bien plus compliqué à gérer.
                          • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                            Posté par . Évalué à  2 .

                            bon je me réponds à moi même car ce que je dis est faux, le tableau a une taille finie (mais pas figée), il convient surtout de garder en tête la méthode size pour éviter ce genre d'erreurs.
                            • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                              Posté par . Évalué à  1 .


                              il convient surtout de garder en tête la méthode size pour éviter ce genre d'erreurs.

                              Faut arreter, mettre une condition sur l'index a la main avant chaque acces a un tableau pour détecter une erreur de programmation, ca frole le ridicule.
                              Ou alors tu voulais dire autre chose ?
                              • [^] # Code le toi même

                                Posté par . Évalué à  2 .

                                a = []
                                puts a[42] #=> nil

                                class Array
                                def get!(index)
                                val = self[index]
                                raise IndexError if val.nil?
                                return val
                                end
                                end

                                puts a.get!(42) #=> IndexError
                                • [^] # Re: Code le toi même

                                  Posté par . Évalué à  3 .

                                  en somme, tu reimplementes qq chose qui devrait etre dans le langage par defaut...
                                  • [^] # Re: Code le toi même

                                    Posté par . Évalué à  2 .

                                    en somme, tu reimplementes qq chose qui devrait etre dans le langage par defaut...
                                    Oui, mais c'est justement AHMA la grande force de Ruby. Souvent dans les troll Python/Ruby (dieu sait qu'il y en a depuis l'événement de Django et Rails) un des arguments des Pythonistes (dont je fait partie) est que la librairie standard de Ruby est incomplète et je suis assez d'accord. Seulement avec cette possibilité de monkey_patching les builtins on peut corriger ça facilement, il n'y a qu'a voir le nombre de méthode que Rails rajoute.

                                    Quand je codais en PHP je souffrait du même comportement foireu mais je ne pouvais rien faire si ce n'est une moche fonction get_item($array, $index) ou un if a chaque accès.
                                    Idem en Python bien qu'il soit très complet j'ai souvent envie de rajouter quelque chose. Et la a part sous classer (ce qui est génant avec les objet litéraux) on ne peut pas modifier les builts-in et a mon grand regret Python3 ne le permet pas non plus.
                                  • [^] # Re: Code le toi même

                                    Posté par . Évalué à  3 .

                                    Bon les gars, là, vous n’avez pas compris les principes de Ruby.

                                    D’abord, cette fonction get! n’a pas à être dans le langage par défaut, ne serait-ce que parce que l’on peut très bien vouloir avoir des nil dans son Array. Ce n’est pas la valeur de l’élément qu’il faut tester mais si l’indice est ou non hors champ.

                                    Mais ce n’est pas le point principal. Ce qu’il faut comprendre, c’est qu’un Array n’est pas un tableau comme en C ou en Java.
                                    Un Array, c’est une structure de données de type collection, séquentielle et indexée, donc comme un tableau ou une liste. C’est comme un Hash mais les clefs sont des entiers et les éléments sont ordonnés dans une séquence, donc on peut récupérer des sous-séquences.

                                    Si l’on a un Hash qui ne possède pas de valeur pour une clef (disons :toto), que h[:toto] renvoie nil vous choque ? Bien sûr que non. C’est pareil en Java (on récupère null d’une Hashmap quand la clef n’y a pas de correspondant). C’est pareil en C++ avec les std::map (on récupère une référence sur une nouvelle place).
                                    Or on pourrait très bien vouloir que ça lance une exception IllegalKey ou autre.
                                    C’est un choix.

                                    En Ruby, il a été décidé que c’était pareil pour les Array : un indice hors taille renvoie nil.
                                    Vous pouvez aussi utiliser des indices négatifs : a[-1] renvoie le dernier élément, a[-2] l’avant-dernier, etc.
                                    Et des Range : a[1..5] donne la sous-séquence des éléments 2 à 6, ou a[1,4] qui donne la sous-séquence de 4 éléments à partir du 2e.

                                    On pourra aussi remarquer que, souvent, là où l’on utilise un Hash, on peut utiliser un Array ou une lambda : tous les trois répondent à l’opérateur [].

                                    Oui, c’est du Duck-Typing. Si vous voulez du typage fort, vous prenez C++ ou Java ou autre (Java, surtout si vous voulez des exceptions partout).
                                    • [^] # Re: Code le toi même

                                      Posté par . Évalué à  -1 .

                                      Donc le Array de ruby est en fait une HashMap, super ... ils auraient pu mettre un nom un peu plus explicite, les programmeurs sont pas tous des neuneus.

                                      Sinon les exceptions, oui j'en veut partout, j'aime bien que mon programme m'avertisse quand quelque chose va mal au lieu de continuer à tourner silencieusement et à produire des résultats faux.
                                    • [^] # Re: Code le toi même

                                      Posté par . Évalué à  2 .

                                      Un Array, c’est une structure de données de type collection, séquentielle et indexée, donc comme un tableau ou une liste. C’est comme un Hash mais les clefs sont des entiers et les éléments sont ordonnés dans une séquence, donc on peut récupérer des sous-séquences.

                                      Ce que tu me decrit la, c'est exactement la List de java.
                                      Et devines quoi? La liste de java te retourne une outofbounds exception quand tu fait un get qui pousse le bouchon un peu loin.

                                      Si tu ne peux pas faire un put(Object key, Object value), mais just un addItem(value) alors desole, mais c'est un tableau/liste et pas une hash map.
                                      Si tu peux le faire, c'est que j'ai mal compris ce que tu as mal explique.
                                      • [^] # Re: Code le toi même

                                        Posté par . Évalué à  3 .

                                        Ce que tu me decrit la, c'est exactement la List de java.
                                        Et devines quoi? La liste de java te retourne une outofbounds exception quand tu fait un get qui pousse le bouchon un peu loin.


                                        D'un autre côté, en C++, quand tu utilises un objet de classe vector, tu as deux accès possibles :

                                        1) v.at(i), où v renverra une exception si tu fais un dépassement, et
                                        2) v[i], où aucune exception ne sera levée, mais qui va bien plus vite en terme de latence d'accès aux éléments du vecteur.

                                        Il n'y a donc pas de réelle « bonne façon de faire » pour des tableaux dynamiques. Parce que les exceptions c'est très bien, c'est très pratique et tout, mais à en foutre partout, on finit par plomber les perfs à cause des indirections, de l'effet « goto » qui force à se référer plus ou moins constamment à la doc (« le "goto" c'est maaaaaaaaaaaaaaal, fais plutôt des exceptions ! »), etc.
                                        • [^] # Re: Code le toi même

                                          Posté par . Évalué à  6 .

                                          Parce que les exceptions c'est très bien, c'est très pratique et tout, mais à en foutre partout, on finit par plomber les perfs à cause des indirections, de l'effet « goto » qui force à se référer plus ou moins constamment à la doc (« le "goto" c'est maaaaaaaaaaaaaaal, fais plutôt des exceptions ! »), etc.

                                          Certes, ca va ralentir un peu les perfs.
                                          Apres, avoir un programme qui va vachement vite mais qui te retourne un resultat faux que tu sais meme pas qu'il l'est, a cause d'un bug de programmation, honnetement, ca m'avance pas des masses.

                                          Soyons honnete, un acces en dehors des bornes, que ca te plaise ou non, ca reste une grossiere erreur de programmation dans 99,9% des cas, tu tentes d'acceder a qq chose de pas defini et ca compromet tres fortement l'integrite du code qui suit.
                                          Tu doit etre capable de le savoir. Libre a toi d'en faire ce que tu veux apres.

                                          Tant qu'on y est, on pourrait aussi passer sous silence la null pointer exception, les programmes iraient vachement plus vite sans.
                                          • [^] # Re: Code le toi même

                                            Posté par . Évalué à  3 .

                                            Tout ce que je voulais dire, c'est que si (par exemple hein) en C++ on a décidé de proposer les deux méthodes, ce n'est pas pour rien. Il y a des fois où la performance *est* importante, et les exceptions se mettent en travers. Et au final, la réflexion concernait le fait qu'il n'y a pas de solution unique, et que le « tout exception » n'est pas forcément quelque chose de voulu ou de souhaitable. Tout dépend l'état d'esprit dans lequel on programme.

                                            [à propos des exceptions] Certes, ca va ralentir un peu les perfs.
                                            Non. Si tu fais un accès dans une boucle, ce n'est pas « un peu ». Alors c'est sûr, si tu comptes parcourir tout le tableau/la liste/le vecteur/etc, il vaudrait mieux utiliser un itérateur, mais parfois, on ne peut pas (la variable d'induction sert pour indexer d'autres structures, etc).

                                            Qu'on soit bien d'accord je suis à fond pour l'utilisation de langages de haut-niveau, avec tous les mécanismes modernes qu'ils peuvent procurer, et ce le plus souvent possible. Mais il y a des fois où ils se mettent en travers de la performance, car trop présents implicitement. Dans ces cas-là, j'aimerais pouvoir « désactiver » certaines fonctionnalités (par exemple en utilisant v[i] à la place de v.at(i) en C++ :-) ) qui font que mon programme ne va pas assez vite (après avoir fait du profiling, vérifié que je ne faisais pas de la micro-optimisation pour rien, etc, bien entendu). Avant de passer à du « pur C » ou encore pire, de l'assembleur, j'aimerais bien que le langage, ou plutôt l'environnement, me laisse désactiver certains mécanismes qui me semblent superflus dans une région de code bien précise.

                                            La façon de faire de Ruby pour l'accès aux tableaux est très semblable (identique ?) à ce que fait Perl. Quand je code en Perl, je suis conscient de ça, et c'est pour ça que j'ai les warnings à fond tout le temps, parce que l'implicite, c'est bien, mais je préfère avoir l'interpréteur qui continue de faire tourner mon code, mais qui m'avertit quand j'ai des valeurs indéfinies qui sont quand même utilisées. Ça ne bloque pas mon programme pour autant (même si souvent ça le rend "faux", ie le warning n'était pas prévu), mais parfois l'erreur que j'ai introduite n'est pas grave, au sens où le résultat que je recherche est quand même là. Bon évidemment, je finis toujours par tomber sur un cas où ça va sérieusement m'empêcher d'avancer dans mon boulot, et je dois bien arriver à faire taire ce #@! d'interpréteur qui m'avertit que je gruike un peu trop ... et donc changer mon code. :)

                                            Concernant les NullPointerException, la différence, c'est que même en C où un programme pourrait tout à fait continuer longtemps avant de planter tout en donnant un résultat erroné, avec un pointeur NULL, ton programme plante, et c'est tout (et en ce qui me concerne, je ne fais que du C ou presque, et si j'ai un segfault, au moins je sais qu'il y a une erreur, et j'ai un point de départ pour la trouver). On aura donc du mal à la capturer. :-)
                                            • [^] # Re: Code le toi même

                                              Posté par . Évalué à  1 .

                                              Donc en gros, t'es en train de justifier un choix conceptuel douteux applique a une portion critique du langage (donc pour l'integralite des programmes) pour

                                              - des cas tres particuliers. Comme tu le dit, l'iterateur est pas fait pour les chiens et largement preferable, le cas que tu decris, a savoir iteration sur un tableau et acces a un autre tableau a chaque iteration etant pas forcement tres courant, et tres certainement resolvable avec une structure adaptee, surtout si c'est du code qui est execute tres souvent (s'il ne l'etait pas, tu grapilles des pouillieme de poussieres de milisecondes et t'as certainement d'autres chats a fouetter).

                                              - une optimisation qui saute juste un pauvre if (donc negligeable si ton code est complexe dans la boucle, ce qui a l'air d'etre le cas, s'il ne l'est pas et que tu te contentes d'iterer sur les valeurs, c'est ptetre que ton choxi de structure est pas topmoumoute?).

                                              Sachant que meme si je me gourre dans mon assertion plus haut (probable :) )et que effectivement tu perds du temps dans tes boucles et que tu peux pas faire autrement, ruby est un langage interprete sans JIT (donc par nature pas franchement rapide ni meme fait pour aller un tant soit peu vite et ne laissant strictement aucune place aux optimisations du compilo), j'ai du mal a voir la pertinence de ton optimisation...

                                              T'as l'air d'avoir cherche en profondeur avant d'en arriver a cette conclusion, donc si tu peux etayer un peu plus l'argumentation, parce que la je reste tel la fosse, sceptique.

                                              Bref, je concois que dans un langage oriente ultra optimisation et maximum de controle a l'utlisateur (severement burne) on fasse ce genre de choses, dans un langage de script de haut niveau, c'est pour le moins etonnant et la justification me laisse sur ma faim.
                                              • [^] # Re: Code le toi même

                                                Posté par . Évalué à  2 .

                                                Il ne s'agit pas forcément de cas si particuliers que ça. Par exemple, les compilateurs sont très bons pour optimiser du code avec des accès réguliers à la mémoire (et le matériel aide aussi quand il peut). Si on doit y rajouter les indirections dues aux objets (accès aux méthodes et membres des classes), tout un tas de if, etc., on peut perdre le compilateur. Même si le branchement est prédit non pris au bout d'un moment, il y a un certain nombre limité de branches qu'il peut conserver en mémoire.

                                                De plus dans le cas de code scientifique par exemple, typiquement un solveur itératif, il n'est pas rare d'avoir des accès de type

                                                for (i=1; i<m ; ++i) {
                                                ____for (j = 1; j < n; ++j) {
                                                ________v1[i][j] += a + (v1[i][j-1] *v1[i][j+1]) + b + v1[i-1][j] * v1[i+1][j] + ...;
                                                }

                                                Bien entendu il s'agit d'un code factice, mais l'idée est là. On a même des cas où plusieurs vecteurs se mélangent. Dans ce cas précis j'ai pris un tableau 2D, donc le terme de « vecteur » n'est certes pas le meilleur, mais c'était pour illustrer mon propos.

                                                Concernant mon post précédent, je faisais 2 remarques, orthogonales l'une de l'autre :
                                                1/ Un langage n'est pas obligé d'imposer une seule façon de traiter les structures de données, pour tout un tas de raisons (et je prenais C++ en exemple, qui propose les deux mécanismes, à cause de certains problèmes de perf); de plus même si le langage n'impose qu'une seule façon (« Java »), il n'est pas dit que ce soit la seule bonne façon de faire, et la façon de gérer cela par d'autres langages n'est pas nécessairement moins mauvaise : tout dépend des objectifs qu'on se fixe.

                                                2/ Concernant Ruby spécifiquement, renvoyer nil (ou undef en Perl) n'est pas nécessairement une mauvaise chose, et je parlais du fait que parfois j'ai une sortie « imparfaite » de mes scripts Perl, mais « suffisamment bonne » pour que je puisse quand même me servir de ces résultats, ne serait-ce que partiellement (je me sers beaucoup de Perl pour analyser la sortie de fichiers au format CSV ou pas très loin du CSV dumpés par mes programmes, et adapter les données à mes besoins). Par exemple, à cause d'une erreur de ma part, le script peut avoir raté une ligne (je n'avais pas prévu un certain type de format de ligne, et du coup mon script ne sait pas le gérer), mais le calcul en lui-même n'est pas forcément faux pour le reste des autres lignes du fichier que je veux traiter. Dans ce cas je préfère un warning qui me dit que je divise par 0, que j'essaie de faire des trucs avec une variable non-définie, etc, mais que le programme continue de tourner pour pouvoir quand même espérer détecter une tendance par exemple, plutôt qu'avoir un programme qui s'arrête parce que euh, ben, « Y'a une exception, là, et je sais pas quoi en faire, donc je stoppe tout. ».
                                                • [^] # Re: Code le toi même

                                                  Posté par . Évalué à  0 .

                                                  1/ En java aussi tu as des tableaux à accès direct, j'ai eu hier un algo de calcul brute force à optimiser. Remplacer les "Vector" parcourus par des itérateurs par un simple tableau m'a fait gagner 15% de perfs sur un traitement de 40 minutes (bon les tableaux étaient à longueur fixe et étaient parcourus au total quelques miliards de fois ...).

                                                  2/ Pour coder un petit truc dans ton coin si tu veux, ca m'arrive de le faire moi aussi, mais imaginer faire un programme censé produire des résultats fiables pour d'autres personnes avec des outils comme ca ...
                                                  J'ai du mal a comprendre pourquoi tant de gens utilisent ces langages de script pour coder des trucs entiers. C'est pourtant assez évident que c'est un non sens.
                                                  • [^] # Re: Code le toi même

                                                    Posté par . Évalué à  1 .

                                                    D'un autre cote, les Vector sont synchronises, donc c'est un peu normal de voir les perfs s'ecrouler si tu ne fait pas d'acces concurrents a ta List, le mot cle synchronized etant un gros consommateur de ressource en java (lock puis unlock du vector).

                                                    ArrayList est la classe que tu veux utiliser.
                                                    Et je suis pas sur que t'y perdes quoi que ce soit en perfs par rapport a un tableau.

                                                    Entierement d'accord sur ton second point cela dit.
                                                    • [^] # Re: Code le toi même

                                                      Posté par . Évalué à  3 .

                                                      Entierement d'accord sur ton second point cela dit.

                                                      Et moi pas. :-)
                                                      Je me sers de langages de script pour prototyper pas mal de trucs. Pas forcément une grosse appli monstrueuse, mais le temps que je gagne à développer ces trucs (et parfois à faire de mes petits scripts des modules qui re-servent à mes collègues) fait gagner un temps fou en dév. Après, il y a aussi des fois où je fais un rapide prototype en Perl, et ensuite je code le truc pour de bon en C (parce que par exemple, j'aurai besoin d'avoir une bibliothèque qu'on puisse directement appeler).

                                                      Malgré tout, des langages comme Ruby ou Python, qui ont tout un tas de très bons mécanismes intégrés au langage, sont tout à fait viables pour faire des applis « sérieuses ». [1] Faut-il être plus vigilant du fait que ce sont des langages à typage dynamique (par exemple) ? Pas sûr, après tout, Python fait dans le typage fort, et renvoie des exceptions et tout ce qui va avec comme les autres langages de haut-niveau.

                                                      Après quelques mois de dév Java, j'ai eu au contraire l'impression inverse : le langage est tellement rigide qu'il force à faire des contorsions pas possible là où parfois il existerait des raccourcis tellement pratiques. Mais c'est le prix à payer pour un typage fort et statique, je suppose, et aussi au fait que je devenais aigri à devoir faire du Struts/Hibernate/JBoss/JSP/JSP/JSP. Surtout JSP en fait.

                                                      Quand je suis retourné à faire du Perl par la suite, tout un tas de choses compliquées en Java me semblaient quand même vachement plus simples à accomplir avec Perl.


                                                      [1] Perl aussi selon moi, mais j'avoue avoir beaucoup de mal avec la façon dont Perl gère la programmation orientée objet, du coup je ne programme que de bêtes modules pas OO.
                                    • [^] # Re: Code le toi même

                                      Posté par . Évalué à  2 .

                                      Oui, c’est du Duck-Typing. Si vous voulez du typage fort, vous prenez C++ ou Java ou autre

                                      Non ce que tu viens de décrire n'a rien a voir avec le concept de Duck Typing. Python qui a inventé la notion Duck typing te pète une erreur si tu demande un index trop grand ou te renvoie une valeur par défaut si explicitement demandé.
                                      La c'est un choix de Ruby de faire comme Perl et PHP de renvoyer nil plutôt que péter. Le programmeur doit donc tester sinon il risque d'appeler une méthode sur nil. C'est juste une question de gout.

                                      Et je te rappelle que Ruby que tu connais mieux que tout le monde apparemment, est un langage a typage fort tout comme Java.
                                      • [^] # Re: Code le toi même

                                        Posté par . Évalué à  2 .

                                        Oui, c’est du Duck-Typing. Si vous voulez du typage fort, vous prenez C++ ou Java ou autre

                                        Non ce que tu viens de décrire n'a rien a voir avec le concept de Duck Typing.


                                        Si. Pouvoir utiliser un Hash, une Lambda ou un Array parce que tous les trois répondent à l’opérateur [], c’est du Duck Typing.
                                        Et le fait que [] réponde nil quand la clef/l’indice n’a pas de correspondant pour un Hash ou un Array fait bien que le « coin » de l’Array est le même que celui du Hash. Même « coin », même canard.

                                        Python qui a inventé la notion Duck typing […]

                                        Pas vraiment. On faisait du Duck Typing avant. C’est juste que le terme a été utilisé pour décrire ce typage dans Python.

                                        L[à] c'est un choix de Ruby de faire comme Perl et PHP de renvoyer nil plutôt que péter. Le programmeur doit donc tester sinon il risque d'appeler une méthode sur nil. C'est juste une question de gout.

                                        C’est exactement ce que je dis : « En Ruby, il a été décidé que c’était pareil pour les Array : un indice hors taille renvoie nil. » C’est un choix.
                                        C’est pour cela que je réponds « Non. » à ceux qui sautent à pieds joints sur la table en répétant « C’est nul, ça doit être dans le langage ! ».

                                        Et je te rappelle que Ruby que tu connais mieux que tout le monde apparemment,

                                        En tout cas mieux que lesdits sauteurs…

                                        est un langage a typage fort tout comme Java.

                                        Oui, mea culpa, lapsus calami, je voulais écrire « typage statique ».
                                        • [^] # Re: Code le toi même

                                          Posté par . Évalué à  2 .

                                          Si. Pouvoir utiliser un Hash, une Lambda ou un Array ...
                                          Autant pour moi je t'avais mal compris. On a bien la même vision de la chose.

                                          Pas vraiment. On faisait du Duck Typing avant. C’est juste que le terme a été utilisé pour décrire ce typage dans Python.
                                          La encore je voulais parler de l'expression pas du concept. Mea culpa.
                                • [^] # Re: Code le toi même

                                  Posté par . Évalué à  1 .

                                  La souplesse de Ruby pour coder une verrue, c'est bien mais je considère quand même qu'il s'agit d'un comportement par défaut incorrect pour un tableau..

                                  Sinon pourquoi "get!" et pas "get" ?
                                  Il me semblait que le point d'exclamation est une convention de nommage pour les methodes qui modifie les objets..
                                  • [^] # Re: Code le toi même

                                    Posté par (page perso) . Évalué à  1 .

                                    A noter que python sort une erreur dans le cas de dépassement de tableau ce qui prouve irrémédiablement la supériorité de ce langage sur Ruby.

                                    Chippeur, arrête de chipper !

                                  • [^] # Re: Code le toi même

                                    Posté par . Évalué à  2 .

                                    La souplesse de Ruby pour coder une verrue, c'est bien mais je considère quand même qu'il s'agit d'un comportement par défaut incorrect pour un tableau..
                                    Pour être franc je suis du même avis. C'est typiquement un comportement Perlien/PHPien qui cache les problèmes. Je préfère les IndexError de Python et le .get a l'occasion.

                                    Sinon pourquoi "get!" et pas "get" ?
                                    Il me semblait que le point d'exclamation est une convention de nommage pour les methodes qui modifie les objets..

                                    Oui mais pas seulement. Exemple: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M0(...)
                                    Le bang est aussi utilisé pour signaler la possible levée d'exception.
        • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

          Posté par (page perso) . Évalué à  4 .

          ava a toujours été multi-plateforme
          .NET a toujours été multi-plateforme, MS l'a montré dès le début avec des implémentations sous mac et bsd. Ses implémentations sur périphériques embarqués le montre également.

          c'est Sun qui a fait le travail
          C'est effectivement la grosse différence.

          MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).
          Pour Silverlight , MS fourni l'implémentation des codecs. Niveau dev c'est le gros du boulot.
          Pour Silverlight 2.0, MS fourni la bibliothèque des widgets graphiques.
          Pour .NET, MS fourni la stack DLR, la bibliothèques javascript pour ASP.NET AJAX, le compilateur IronPython.
          Si ca c'est pas du dev, je sais pas ce que c'est !

          Mais bon de toute façon, MS participerait au développement du coeur de Mono que ca vous ferait au contraire une raison supplémentaire de râler.
          • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

            Posté par . Évalué à  2 .

            Ok, j'ignorais que MS participait autant. Mea culpa
          • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

            Posté par . Évalué à  6 .


            MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).
            Pour Silverlight , MS fourni l'implémentation des codecs. Niveau dev c'est le gros du boulot.
            Pour Silverlight 2.0, MS fourni la bibliothèque des widgets graphiques.
            Pour .NET, MS fourni la stack DLR, la bibliothèques javascript pour ASP.NET AJAX, le compilateur IronPython.
            Si ca c'est pas du dev, je sais pas ce que c'est !

            Hahaha tu parles des codecs binaires dont ils ont gracieusement autorisé l'utilisation et des bouts de code qu'ils ont publié sous leur propre licence open source ?
            Effectivement c'est une superbe contribution ! Permet moi de les applaudir chaudement.
            • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

              Posté par (page perso) . Évalué à  4 .

              des bouts de code qu'ils ont publié sous leur propre licence open source ?
              pourquoi tu gueules pas sur la fondation apache qui publie sous leur propre licence ?
              la licence utilisé par MS est libre au sens OSI et FSF, c'est le principal.
              • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                Posté par . Évalué à  2 .

                Je suis contre la la Microsoft Permissive Licence (MS-PL) et la Microsoft Community Licence car ce sont des copies de la licence Apache et CDDL. 70 licences libres approuvées par l'ODI; c'est trop en faudrait juste une vingtaine.
              • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                Posté par . Évalué à  2 .

                Oui d'ailleurs, si on va par là, les fameux dtrace et zfs de chez Sun que tout le monde loue tant ont une licence libre mais incompatible avec la GPL. Sun n'agit pas "mieux" que MS sur ce point. De plus, Pour obtenir une libération de java (pas encore tout à fait libre d'ailleurs, si ?), il aura fallu attendre plus de 10 ans. Pour C# et .Net, MS a quand même été plus rapide.
                • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                  Posté par Anonyme . Évalué à  2 .

                  Pour C# et .Net, MS a quand même été plus rapide.

                  Il existe une implémentation de C# et .NET multiplateforme (y compris pour linux), opensource et faite par Microsoft?
                • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                  Posté par (page perso) . Évalué à  1 .

                  avait t'il vraiment le choix?

                  java est maintenant un peu partout
                  • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                    Posté par Anonyme . Évalué à  2 .

                    Comme sous entendu dans la question au dessus (qui a été curieusement caché) Java et C# c'est totalement différent. L'équivalent du projet mono a existé mais pour les mêmes raisons (plus des developpeurs bien moin nombreux) a toujours été à la traine. La libération de java par SUN a accélérer les choses. Microsoft n'a absolument pas libéré C#. Comme pour java les specifications du langage ont été rendu public et, contrairement à SUN, Microsoft n'a JAMAIS fournit d'environnement C# natif sous linux, jamais. Ce n'est pas compliqué il n'existe aucun logiciel majeur estampillé Microsoft existant sous linux. Microsoft ne veut surtout pas de cela. Elle a les chocottes.
                • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                  Posté par . Évalué à  2 .

                  oui et Redhat, Linus et Stallman que tout le monde loue tant ont une licence libre mais incompatible avec la BSD. Ils n'agissent pas mieux que MS sur ce point. Avec des raisonnements pareil, on ne vas pas loin.
                  • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

                    Posté par . Évalué à  2 .

                    Il y a une grosse différence : Torvalds et Stallman ont décidé dès le départ de faire du logiciel libre. Red Hat (qui n'est pas à mettre sur le même niveau, vu qu'il ne s'agit pas d'une personne physique) aussi. On ne peut pas en dire autant de Sun. Combien de temps avant qu'ils ne se disent que ce serait finalement pas mal de libérer la jvm ? Et Solaris ? Bref, je ne vois pas trop le rapport. La GPL a ses spécificités, certes incompatibles avec la licence BSD (ou ses copines), mais il s'agit d'un problème « idéologique » sur la définition de liberté.

                    La CDDL a (selon moi bien sûr) été créée uniquement pour empêcher Linux (qui est clairement le plus sérieux concurrent à l'Unix de Sun) d'intégrer « en l'état » les softs qui l'utilisent. Je ne critique pas le choix de Sun, qui se tient d'un point de vue « stratégique » : ils n'empêchent pas les OS « mineurs » (à l'exception d'OS X, certes) de l'utiliser, mais seulement le plus gros concurrent en face.

                    Cela étant dit je ne critique pas le choix de Sun, et je compte bien installer OpenSolaris d'ici peu sur ma machine (j'ai tout un tas de trucs à tester sur certains réglages systèmes qu'il permet et que ne permet pas -- encore ? -- Linux). Mais quand quelqu'un se moque de MS parce qu'ils ont fait « leur propre licence », je me permets juste de rappeler que des boites qui jusqu'à il n'y a pas longtemps faisait tout autant de propriétaire que MS ont aussi les leurs.
        • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

          Posté par . Évalué à  2 .

          Je le dis à chaque fois, mais Java est multi-plateforme, mais pas tout non plus !

          Il y a tout un tas d'archi qui ne sont supporté, il y en a même plus qui ne sont pas supporté que d'archi supporté !
    • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

      Posté par . Évalué à  10 .

      "apparemment il ne plane plus ou peu de menaces en ce qui concerne les brevets":

      ça, c'est vrai pour Mono, mais pas pour Moonlight. cf le "covenant" de Microsoft et Novell, ça fout carrément les jetons ( http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...) ):

      1) la protection n'est que temporaire

      2) elle ne s'applique qu'à ceux qui téléchargent directement chez Novell. Les distros sont explicitement exclues (cf page de définitions)

      OK, la priorité, c'est de combattre les brevets logiciels en général, mais semble-t-il, Microsoft en particulier cherche à faire usage des siens pour pourrir l'écosystème Linux.
    • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

      Posté par . Évalué à  7 .

      > Ok, la technologie est ouverte, apparemment il ne plane plus ou peu de menaces en ce qui concerne les brevets

      Pour mono oui. Pour Silverlight (ou Moonlight) non :
      http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...)
      Il n'y a que MS et Novell qui peuvent distribuer. Bref, Moonlight n'est pas libre.
    • [^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!

      Posté par . Évalué à  2 .

      Très bien dit.

      Je suis exactement dans ce cas là : Des technologies intéressantes avec de sombres desseins derrière.

      Si tu as apprécié le C#, regardes de ce coté : http://live.gnome.org/Vala qui me semble une très bonne idée.
      Une plateforme de développement Gnome, avec un langage moderne.

      Etant développeur java avec une forte envie de développer des applis natives linux, j'hésite entre Vala(jeune) et le nouveau Qt (abouti mais quel choc pour un gnomiste ;)
  • # codec

    Posté par (page perso) . Évalué à  6 .

    J'ai installé moonlight par curiosité.
    Je me suis rendu sur le site de VIdeo.Show et comme je n'avais pas le plugin, on me propose de télécharge le plugin Microsoft Silverlight.
    Je suis naturellement redirigé vers la page de moonlight (c'est bien, je m'attendais à me retrouver sur la page windows).

    le plugin s'installe facilement (plantage de firefox mais rien de bien méchant).

    Je retourne à nouveau sur la page et il ne se passe rien.

    En réalité, il semble que je doive installer des codecs Microsoft :

    MICROSOFT SOFTWARE LICENSE TERMS

    MICROSOFT MEDIA PACK 1.0

    ONLY FOR USE WITH NOVELL'S MOONLIGHT 1.0 RUNNING IN AN INTERNET BROWSER

    J'ai donc un peu de mal à comprendre le but de moonlight...
    Est-il lié à microsoft ou peut on utiliser d'autres codecs à l'intérieur?
    Si oui on aurait donc une technologie proche de flash mais ouverte. Ce qui en un sens serait pas mal...
    (même si à mon avis le css, svg, et js sont beaucoup plus intéressant).


    (ps : je n'ai pas installé les codecs, donc pas vu les videos ;o)
    • [^] # Re: codec

      Posté par . Évalué à  9 .

      moonlight vs silverlight c'est un peu :

      bon écoute, t'es le bienvenue chez moi, enfin tu peux dormir dans le jardin quoi. Pour t'aider, on va te préter la tondeuse, ce sera plus confortable. Et vide les poubelles stp (il y a les restes de Cookie si t'as un pti creux, tu sais notre labradore), voilà, de rien.
    • [^] # Re: codec

      Posté par (page perso) . Évalué à  3 .

      Est-il lié à microsoft ou peut on utiliser d'autres codecs à l'intérieur?
      Tu peux compiler moonlight avec ffmpeg.
      Le seul avantage du pack Microsoft, c'est qu'il est "légal" d'un point de vue licence/brevet pour les codecs WMV et VC-1.
      Sinon effectivement ces codecs c'est du closed source pas bien du tout et bourrés de brevets.
  • # Une précision

    Posté par (page perso) . Évalué à  3 .

    Moonlight n'est pas distribué directement avec le pack de codecs de Microsoft. En tout cas pas par la page de téléchargement en lien ici. Ces derniers peuvent être téléchargés par l'utilisateur qui le souhaite, et c'est proposé à la première tentative de lecture d'un fichier qui pourrait avoir besoin de ces codecs.

    Il est aussi important de noter qu'il est toujours tout à fait possible de compiler son propre plugin en utilisant ffmpeg au lieu des codecs Microsoft.

    A voir aussi, un plugin Firefox pour lire les fichiers wmv et wma directement, et qui utilise en fait Moonlight pour lire ces fichiers: http://abock.org/2009/02/11/announcing-moonshine-the-project(...) : Moonshine. Très pratique pour ceux qui n'ont pas réussi comme moi à faire marcher le support de Totem, et qui ont Moonlight d'installé.

    (Et aussi c'est VB.NET, pas VB# :)
    • [^] # Re: Une précision

      Posté par . Évalué à  2 .

      Hum la honte :( C'est ca d'ecrire une news apres une nuit blanche. Merci pour les precisions!
  • # Un premier retour utilisateur

    Posté par (page perso) . Évalué à  10 .

    ... relativement déçu : http://harishpillay.livejournal.com/139376.html

    Je vous traduit vite-fait :
    Je l'ai installé sur ma Fedora 10, et j'ai essayé de visiter des sites qui sont censés fonctionner avec Moonlight/Silverlight. Et voilà, Moonlight est en version 1 alors que Silverlight est en version 2. Donc c'est comme avec le projet Mono, qui est perpétuellement en train de courir après .NET. Je désinstalle.
    • [^] # Re: Un premier retour utilisateur

      Posté par . Évalué à  2 .

      Pareil... Donc sans parler licences, morale ou philosophie, cela ne fonctionne pas pour un grand nombre de site. J'ai beaucoup aimé le message "Moonlight was compiled with 1.0 support only, this site required 2.0 support" et le petit lien en dessous de la page "Linux-compatible Silverlight Player" sur un site : l'air de dire, on a fait un effort pour vous, il vous reste une entrée au rabais parce que vous êtes utilisateur d'un système d'exploitation au rabais lui même.

      L'effort est louable mais on est loin du compte. Je préfère encore JavaFX ou Flash. On se fout moins de ma gueule.
      • [^] # Re: Un premier retour utilisateur

        Posté par (page perso) . Évalué à  3 .

        Est-ce que le projet n'aurait pas intéret à forker et de continuer sur la voie de l'alternative à adobe tout en restant open source et indépendant de silverlight?
        En gros, de créer sa propre technologie?
        Je trouve cela très intéressant de pouvoir utiliser ffmepg pour y intégrer les codecs que l'on souhaite.
  • # dans 1 an ou deux

    Posté par Anonyme . Évalué à  5 .

    moonlight sera au niveau de la version silverlight2 de Microsoft ce qui permettra de se servir, aux USA, de Netflix mais malheureusement ce dernier sera déjà à la version 4.0 totalement incompatible avec la version 2.

    Je ne vois vraiment pas en quoi il est intéressant de porter ce genre de technologie sous linux par la communauté et je remarque que encore une fois Microsoft ne fait pas elle même le travail pour notre OS. Elle supporte d'autre OS mais pour Linux il est clairement stipulé que cela doit être interdit de fournir un logiciel de la même génération que ceux disponibles sur les autres OS.
  • # oups

    Posté par Anonyme . Évalué à  -3 .

    il manque des mots...

    donc je disais Moonlight sera au niveau de silverlight2 dans 2 ans.
  • # Intéret de Silverlight ?

    Posté par . Évalué à  6 .

    Si j'ai bien suivi Silverlight c'est un concurrent de flash, qui lui-même concurrence les standards libres que sont html, svg, theora…

    D'où ma question : quel est l'intérêt de développer un truc avec Silverlight, ou Moonlight ?
    On va retomber dans tous les problèmes de flash, en pire puisque c'est loin d'être une norme de facto.

    Qu'apporte Silverlight par rapport à ces concurrents, notamment par rapport aux standards du web ?
    • [^] # Re: Intéret de Silverlight ?

      Posté par (page perso) . Évalué à  6 .

      Ça fait des pages super longues à charger avec des boutons qui clignotent partout.
      Sur internet, c'est Noël tous les jours.
    • [^] # Re: Intéret de Silverlight ?

      Posté par (page perso) . Évalué à  4 .

      Qu'apporte Silverlight par rapport à ces concurrents, notamment par rapport aux standards du web ?
      La même chose que Flash :
      - la possibilité pour le programmeur d'utiliser autre chose que les "standards" du W3C qui traînent des boulets derrière eux, à commencer par Javascript avec sa grammaire et ses perfs de merde (malgré tous les efforts des navigateurs).
      - la possibilité d'utiliser des bibliothèques multimédias : Vidéo, Audio, 2D, 3D, le tout de manière unifié et intégré. Même en aggrégant tous les standards du W3C ont obtient pas la même couverture fonctionnelle. Suffit de regarder les possibilités en matière de streaming vidéo qui arrive dans Flash10 ou Silverlight pour voir qu'en la matière ce que prévoit le W3C dans HTML5 est totalement à la ramasse.
      Évidemment y'a les lots d'inconvénients qui contre-balance largement ces avantages. Mais chacun utilise ce dont il a besoin hein.

      L'intérêt de Silverlight par rapport à Flash ?
      - la possibilité d'utiliser le javascript de merde si le programmeur en a encore envie (Silverlight 1.0) tout en ayant accès aux possibilités multimédias que n'offrent pas les standards W3C.
      - beaucoup plus naturelle pour l'ensemble des programmeurs MS qui retrouvent leurs langages, leurs outils avec toute l'intégration client/serveur qui va bien made-in-MS.
      Là encore, Flash a bien d'autres avantages : plus de fonctionnalités, support H264, déjà déployé, etc.

      PS : j'utilise pas Silverlight et j'utilise Flash que quand j'ai pas le choix, donc pas taper, j'essai juste d'expliquer.
      • [^] # Re: Intéret de Silverlight ?

        Posté par . Évalué à  9 .

        La même chose que Flash :
        - la possibilité pour le programmeur d'utiliser autre chose que les "standards" du W3C qui traînent des boulets derrière eux, à commencer par Javascript avec sa grammaire et ses perfs de merde (malgré tous les efforts des navigateurs).


        Je veux pas dire, mais flash, question perfs, c'est autant la merde (et pas seulement avec la version linux pourrie).
    • [^] # Re: Intéret de Silverlight ?

      Posté par . Évalué à  4 .

      On va retomber dans tous les problèmes de flash, en pire puisque c'est loin d'être une norme de facto.

      Je dirais pas "pire" mais "bien pire" en fait. Ce sont les mêmes problèmes, multipliés par autant de versions et de technologies différentes.

      Résumons.

      Au départ, y avait des standards HTML (caducs, oui sans doute) qui ne tenaient pas vraiment compte des possibilités technologiques. Ça a au moins permis une chose: l'avènement des anti-standardistes -- «les standards, c'est bon que si tout le monde s'en sert» et autres conneries du genre.

      Puis il y a eu Flash -- parce que Flash résolvait itou les problèmes de compatibilité des navigateurs. Mais à l'époque, il n'y en avait que deux! (Netscape et Internet Explorer.)

      Et il y eut aussi Java, multiplateforme.

      Puis il y a eu de vrais standards HTML, tenant compte des capacités technologiques des navigateurs. Il y a eu aussi du coup encore plus de navigateurs.

      Ensuite il y a eu encore plus de version de Flash.

      Ensuite il y a eu Silverlight.

      Puis il y aura encore plus de versions de Silverlight.

      --- Fin de l'histoire?

      J'ai un gros doute, là...

      Ça donne quoi, ce foutware?

      Maintenant qu'on n'a plus seulement un, ni deux mais au moins trois médias possibles (Java, Flash, Silverlight, tout aussi incompatibles entre eux, cela va de soi) en plus de HTML, on retrouve les mêmes problèmes de version mais en plus on divisera encore plus l'audience du Web. Le premier point me fait pisser de rire, rien qu'en songeant à tous ceux qui ont la mémoire courte. Je m'explique sur le deuxième point.

      Ce n'est pas Flash qui a incité à fournir des versions alternatives des sites «Flashisés», que du contraire. Ensuite il y a toujours eu des réfractaires à l'utilisation des standards (ouverts qui plus est) et il y en aura toujours. C'est juste dommage qu'ils se soient fait une place sur la toile et soient adulés. Bref.

      Par pure politesse, il convient de fournir une version alternative à tous ceux qui ne possèdent pas le lecteur du média approprié. Ne pas le faire revient à en léser certains. Maintenant, ça se complique davantage! Et quoi encore? On fait une version HTML, une version Flash, une version Java et une Silverlight? Ça va pas la tête?

      Surtout que si on fait une version fonctionnelle en HTML, conforme, les trois autres sont inutiles. Et HTML 5 est de nouveau là pour le démontrer. Tout ça sans [trop] se fatiguer: on contente 100% des visiteurs au lieu de faire une sélection purement subjective et sans pitié.

      Or on a accepté ce principe lorsqu'on parle de navigateurs! Pourquoi les utilisateurs de Firefox (et Mozilla et Safari et Konqueror et...) seraient-ils lésés par rapport à ceux de MSIE?

      Ben, non seulement c'est pas résolu pour les Flashistes mais ça continue et ça empire avec Silverlight. Les règles de bon sens finissent généralement aux oubliettes avec les fanatiques peu scrupuleux de ces technologies. Un peu comme de placer des contrôles sur une boîte sans se préoccuper de la séquence de sélection au clavier. Il y a ceux qui ne savent pas et ceux qui font autrement...

      Au pire, les sites seront d'une inaccessibilité totale... Les uns n'admettant pas faire des efforts pour les autres, un site sera soit (Silver|Moon)light soit Flash (et si t'as pas la bonne version, ben tant pis pour ta pomme) et basta. Moralité: encore plus de ségrégation numérique. Ça fait «ringard» de pouvoir modifier son code avec juste un éditeur de texte ou quoi? Du coup, j'ai décidé de rester «Has-Been»...

      Pondre du code HTML conforme c'est un peu comme s'ouvrir l'esprit. Pas besoin de regorger d'imagination pour trouver une solution qui soit acceptable pour tout le monde. C'est aussi se donner des limites raisonnables. Se creuser les méninges au lieu de céder à [ce qui se fait passer pour de] la facilité, c'est aussi faire preuve de jugeote.

      Je n'ai ni Flash, ni Gnash (je souhaite encore longue vie à ce projet malgré tout, merci d'exister) ni Silverlight. Je ne m'en porte pas plus mal. Je suis chez moi et j'ouvre ma porte à qui je veux, c'est encore mon droit.

      Voilà tout le bien que je pense de ces technologies ségrégationnistes et séparatistes. On ferait bien de foutre tout ça à la poubelle et de reprendre un peu ses esprits!

      Au moins, je ne suis plus tombé sur un seul site ayant besoin de Java. Faut croire qu'il a disparu des pages ou est en voie de disparition et c'est tant mieux. Un monstre se barre mais en voilà un autre, par contre...
      • [^] # Re: Intéret de Silverlight ?

        Posté par . Évalué à  0 .

        Quoi? Je me trompe, peut-être?
      • [^] # Re: Intéret de Silverlight ?

        Posté par . Évalué à  2 .

        OK ca c'est la théorie et en théorie je suis d'accord avec toi.

        Maintenant prend un développeur web qui veut foutre une animation vectorielle interactive sur son site, il a quoi comme choix ?
        SVG ? Ca ne marche pas par défaut sous IE, sous konqueror le rendu est mauvais, sous firefox ca marche mais ca se traine méchemment (pas testé avec les bétas de la version 3.1)
        Concrètement, il reste quoi comme alternative libre ?
  • # Moonlight est distribué sous la licence LGPL v2

    Posté par . Évalué à  5 .

    Mouaif.
    Petite précision, MS (avec Novell) utilise une faille de la GPL. Avec l'accord entre MS et Novell, même si Moonlight est LGPL, Moonlight n'est pas libre (pourré de brevets, comme Silverlight).

    Notons bien ça :
    http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...)
    Moonlight Implementation” means only those specific portions of Moonlight 1.0 or Moonlight 1.1 that run only as a plug-in to a browser on a Personal Computer and are not licensed under GPLv3 or a Similar License.

    La GPL v3 est notamment faite pour éviter le piège de l'accord entre MS et Novell. Et, "comme par hazard", il est interdit de mettre en oeuvre Silverlight avec la (L)GPL v3.

    Sacré MS, Sacré Novell.

    N'utilisez pas Silverlight, ni Moonlight.

    Il y a Flash. Certes il n'y a pas de mise en oeuvre libre et de bonne qualité (c'est discutable). A ma connaissance, ce qui est proprio dans Flash est la vidéo (flv), mais rien d'autre. On peut "réver" d'un flash libre avec support Theora.
    • [^] # Re: Moonlight est distribué sous la licence LGPL v2

      Posté par (page perso) . Évalué à  1 .

      T'aime bien accumuler les contre-vérités.

      l est interdit de mettre en oeuvre Silverlight avec la (L)GPL v3.
      N'importe quoi. Ce document dit uniquement que MS s'engage à ne pas attaquer Novell pour distribuer Moonlight, tant que ce ne sont pas des licences de type GPLv3. En imaginant un fork ou un changement de licence de la part de Novell, l'engage de MS ne tient plus, c'est tout. Et Moonlight devient aussi "nue" niveau protection que l'ensemble des autres logiciels libres. Ou que Flash, ou que n'importe quel logiciel non couvert par cet accord.

      A ma connaissance, ce qui est proprio dans Flash est la vidéo (flv), mais rien d'autre.
      Un peu comme moonlight quoi.

      On peut "réver" d'un flash libre avec support Theora.
      Et c'est bien connu, Flash et Theora sont des technos qui sont reconnus mondialement pour ne pas être sous l'épée de Damoclès d'un brevet enregistré quelque part dans le monde.

      PS : tu compiles moonlight avec ffmeg, ayé tu l'as ton support theora.
      • [^] # Re: Moonlight est distribué sous la licence LGPL v2

        Posté par . Évalué à  4 .

        « l'engage de MS ne tient plus »

        J'aime beaucoup la rhétorique Microsoft :
        « Moonlight c'est libre ?
        – Oui pas de soucis, c'est même Novell qui le fait !
        – Je peux faire un fork en GPLv3 ?
        – oui aucun soucis. Bon je pourrais t'attaquer après avec mes brevets, mais ce n'est pas grave. Tu me connais jamais je ne ferais une chose pareil :)
        – Merci beaucoup M. Microsoft, vous êtes trop bon avec les libristes. »

        Microsoft, l'art de la dissimulation et de la tromperie :)

        Une vraie question : quelle est la motivation des dev de Novell pour supporter Moonlight ? Idéologiquement les libristes ne peuvent que cracher dessus, Silverlight est quasiment inconnu de tous… C'est bizarre cette envie de Novell d'aider le déploiement de MS sous linux.
        • [^] # Re: Moonlight est distribué sous la licence LGPL v2

          Posté par (page perso) . Évalué à  4 .

          J'aime beaucoup la rhétorique Microsoft :
          Encore une fois, rien ne t'empêche d'ignorer tout simplement cet accord entre Novell et MS qui ne regarde que eux. Y'a pas de piège ou quoi que ce soit, tu regardes pas leurs accords, ca concerne uniquement MS, Novell, et leurs clients respectifs.

          quelle est la motivation des dev de Novell pour supporter Moonlight ?
          Ben c'est une alternative à Flash. Déjà rien que pour ca, ca mérite d'exister, parcque ca court pas les rues.
          Ensuite sinon Novell supporte Moonlight, c'est juste parcque la version suivante s'appui sur .NET, et donc Mono. Ca donne une légitimité supplémentaire au projet Mono (qui est reconnu officiellement par MS pour le coup).
          Je suppose que c'est également un pari sur l'avenir : Novell fait le pari que la techno Silverlight pourrait se démocratiser, et qu'il est donc important d'avoir une alternative libre sous linux comme ils ont fait le même pari pour Mono.

          Idéologiquement les libristes ne peuvent que cracher dessus,
          Juste les anti-MS, pas tous les libristes. On les entend beaucoup parcqu'ils gueulent tout le temps, mais ca veut pas dire qu'ils sont majoritaires.
          • [^] # Re: Moonlight est distribué sous la licence LGPL v2

            Posté par . Évalué à  5 .

            «Juste les anti-MS, pas tous les libristes. On les entend beaucoup parcqu'ils gueulent tout le temps, mais ca veut pas dire qu'ils sont majoritaires.»

            Et même s'ils l'étaient, je ne vois pas en quoi ils auraient raison :D
    • [^] # Re: Moonlight est distribué sous la licence LGPL v2

      Posté par . Évalué à  2 .

      Les specs de Flash viennent tout juste de sortir sans restrictions à la con. C'est donc "ouvert" depuis peu. Par contre, effectivement, niveau codec c'est la mort. Et vu qu'une bonne partie de l'utilisation de Flash c'est pour la vidéo ...
  • # Pendant ce temps là...

    Posté par . Évalué à  4 .

    À France Télévision, Silverlight est nécessaire pour profiter au mieux du contenu.

    http://info.francetelevisions.fr/

    Il y a un billet [1] à ce sujet sur le blog Formats Ouverts

    En tout cas j'ai découvert le billet aujourd'hui et quelques instants plus tard je vois la dépêche pour l'annonce de la sortie de Moonlight. C'est parfois drôle les coïncidences.


    [1] http://formats-ouverts.org/blog/2009/02/02/1862-l-autre-revo(...)
  • # Le sage montre la lune et l'idiot regarde le doigt

    Posté par . Évalué à  4 .

    Premièrement, j'aimerais rappeler que bon nombre de logiciels libres sont souvent des "clones" de logiciels privateurs, ou implémentent des spécifications non moins privatrices.
    Un exemple bien connu étant le projet GNU, GNU s'est inspiré d'Unix, le but étant de préserver une intéropérabilité avec l'existant, de faciliter le portage de logiciels (souvent de très bonne qualité), d'attirer les développeurs. Et GNU a réussi cela en apportant ses propres améliorations et en évitant le piège de la bête imitation. Les boites derrière les Unix propriétaires dans les années 80 n'étaient pas plus tendre que le Microsoft d'aujourd'hui.
    Mono/Moonlight a pour but d'implémenter certes des technologies Microsoft qui sont reconnaissons-le pas mal chiadés. Oui, Mono/Moonlight est légérement à la traine derrière l'implémentation de Microsoft [1] mais Mono ne se limite pas à "copier" .Net. Il y a d'abord les bibliothèques spécifiques qui permettent qu'on puisse écrire une application parfaitement intégré aux environnements GNOME, OS X (et bientôt KDE via Qyoto), d'autres qui n'ont aucun équivalent dans le framework .Net (MonoTorrent, Mono.Simd, etc ...). Mono va également nettement plus loin que .Net grâce à son côté multiplateforme.
    Il explose au niveau de l'embarqué (notamment sur iPhone grâce à la possibilité de compiler en natif), dans le domaine ludique (Second Life, des jeux sur Wii, etc ...), pour du développement multiplateforme ou spécifique, il est est plus attractif que .Net
    Bref, Mono a fait ses preuves en tant que plateforme indépendamment de .Net, la compatibilité avec celui-ci étant surtout un bonus. Mono offre des outils pour faciliter le portage des applications (l'excellent Gendarme), ça encourage les développeurs à s'intéresser aux plateformes libres.

    Quant à Moonlight, il ne se limite pas à une bête implémentation de Silverlight, il a même été conçu pour être utilisable en dehors de Mono comme l'a souligné l'auteur de la dépêche. On peut l'utiliser dans une application Gtk+ indépendamment de Mono, les deloppeurs de Novell ont même écrits un petit framework permettant l'écriture de desklets.
    http://tirania.org/blog/archive/2008/Apr-17.html


    Reste le problème des brevets logiciels.
    D'un côté, Microsoft collabore activement avec l'équipe Mono (même avant l'infâme accord avec Novell), de l'autre, ils entretiennent une certaine confusion autour de Mono.
    Sans rentrer dans les détails, Mono (et bon nombre de projets libres dont le noyau Linux) est protégé par le consortium OIN qui dispose d'un portefeuille de brevets conséquents. Microsoft n'a clairement pas intérêt à se frotter à OIN et leur stratégie consiste principalement à maintenir une longueur d'avance sur Mono.
    Après, reste à éclaircir le cas de Moonlight, est-il protégé par OIN ? est-il librement implémentable ? Quel est la légalité de l'utilisation des codecs microsoft ? y-a-t-il une alternative[2] ?

    En tant que framework RIA, Moonlight me laisse dubitatif, d'une part il y a des technologies standards qui n'attendent qu'un peu d'amour (html5, svg, etc ...), de l'autre, un marché fortement concurrentiel flex+flash (supaire -_-), JavaFX (pas encore libéré ?), un silverlight bardé de DRMs (et une politique Microsoft mal définie vis à vis de Moonlight).
    En revanche, c'est une technologie relativement sympa sur le bureau et la créativité des développeurs réussira surement à lui donner une place.
    Avant de troller, attendons de voir comment évoluera la situation (et Moonlight) !


    [1] Ce n'est pas systèmatiquement le cas, si je me souviens bien, Mono avait implémenté les generics avant Microsoft. Le modèle bazar de Mono lui permettant d'être un poil plus réactif que la cathédrale de Microsoft qui compense le fait que Mono c'est une dizaine de développeurs à temps pleins, .Net c'est probablement 10 à 50 fois plus.
    [2] la réponse rapide est oui, Moonlight utilisait ffmpeg à ses débuts mais Novell n'a pas le droit de redistribuer Moonlight + ffmpeg. Je ne me suis pas penché sur la question, mais il semblerait que cette possibilité ait été conservée dans le code de Moonlight.
    http://tirania.org/blog/archive/2007/Sep-05.html
    • [^] # Re: Le sage montre la lune et l'idiot regarde le doigt

      Posté par . Évalué à  2 .

      La plateforme JavaFX est en cours de libération, il cherche à stabiliser la SDK avant de libérer. C'est toujours la même rengaine chez Sun, ils ne sont pas contre l'open source mais il ne savent pas agréger une communauté dans leur travaux préliminaire.

      "The JavaFX compiler, parts of the graphics libraries and tools are available now from the OpenJFX (http://openjfx.org) web site, under the GPL 2.0 open source license."
  • # Au secours ! !! FranceTV s'y mets

    Posté par (page perso) . Évalué à  -1 .

    je viens de tomber la dessus.

    http://info.francetelevisions.fr/

    on touches vraiment le fond ......

    personne n'as de contact avec les developpeurs de ce portail ?

Suivre le flux des commentaires

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