LUSH : Lisp Universal SHell

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
2
nov.
2002
Linux
La version de 0.95 de Lush vient d'être annoncée sur Freshmeat (première annonce de ce projet, a priori). Il s'agit d'un langage qui se veut orienté objet et adapté au calcul numérique et aux applications graphiques, le but étant de remplacer l'immonde langage de Matlab. LUSH est défini par ses auteurs comme pouvant remplacer toute combinaison des langages suivants Matlab, Python, Perl, S+, BASIC, et C (tiens, y'a pas le Fortran ;-).. Des « bindings » pour de nombreuses bibliothèques sont disponibles.

La mascotte est une grenouille.

Aller plus loin

  • # Re: LUSH : Lisp Universal SHell

    Posté par  . Évalué à 1.

    Et par rapport à Guile, y'a du neuf ?
  • # Pas convaincu

    Posté par  (site web personnel) . Évalué à 1.

    Un langage UNIQUE ?

    Je crois que l'humanité est condamné à parler plusieurs langages depuis la tour de Babel. Et d'ailleurs, plusieurs langages => plusieurs cultures => c'est une richesse et non une malédiction !

    Au passage je me demande si ce n'est pas aussi cet aspect "langage unique" qui a un peu "tué" le LISP (Et pourtant, oui, j'aime bien ce langage !). Est-ce que Python n'est pas mieux adapté à la prog objet ? Et le C au calcul ? Et...

    Jiba
    • [^] # Re: Pas convaincu

      Posté par  . Évalué à 1.

      Pour ceux qui ont du mal a parler le lisp couramment, il y a Yorick. Un language interprete, avec une syntaxe proche du C, tres puissant au niveau traitement des matrices et des tableaux multidimensionnels (bien mieux que Matlab!). C'est tres bien adapte au traitment d'image genre deconvolution. Un certain nombre de bibliotheques de fonctions son disponible grace a la communaute des utislisateurs. Son seul point faible est l'interface graphique quelque peu rustique, mais David Munro est en train de l'ameliorer... A suivre...
      http://wuarchive.wustl.edu/languages/yorick/yorick-ad.html(...)
      http://yorick-mb.sourceforge.net/(...)
      • [^] # Une news, une news, une news, ....

        Posté par  . Évalué à 1.

        Pas mal du tout Yorick.
        Ca mérite une news en pleine page de linuxfr ce language.
        Qui se lance ?

        Jack
    • [^] # Re: Pas convaincu

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Je crois que l'humanité est condamné à parler plusieurs langages depuis la tour de Babel.
      Tu es au courant que c'est de la mythologie chrétienne ?
  • # Un progrés évident.

    Posté par  . Évalué à 1.

    Il est effectivement temps de remplacer Matlab. Or Scilab et Octave n'arrivent pas à la semelle de Matlab (désolé mais c'est quand même un peu vrai!). Lush me semble être vraiment capable de révolutionner la programmation scientifique. A tester absolument!
    • [^] # Re: Un progrés évident.

      Posté par  . Évalué à 1.

      Ce qui nuit à octave et scilab c'est le rendu graphique de matrices et de volume (je sais de quoi je parle, je travaille dans le traitement d'images).

      A part cela, ces derniers sont mieux conçus que matlab (gestion mémoire, principes de base, création de types, modularité... ).

      Le premier tente quelque peu de clôner matlab sans pour autant perdre sa philosophie et en oubliant les mauvaises solutions matlabiennes.

      Le second est un peu indépendant et offre des solutions très intéressantes par exemple pour la création de nouveaux types et d'opérateurs.

      Alors, faut pas décrier trop vite ces outils fort bien conçus.
      Matlab me fait ch... tous les jours par exemple avec ces nouveaux outils "java" qui n'ont apporter qu'une chose, des bugs supplémentaires et des arrêts brusques avec perte de données.
      En plus, j'ai jamais compris comment matlab gèrait la mémoire qu'il alloue à la création de matrices. C'est vraiment devenu une usine à gaz.

      En plus quand on est habitué au libre, c'est vraiment frustrant de voir le nombre de bibliothèques et toolbox payantes.

      Jack.
      • [^] # Re: Un progrés évident.

        Posté par  . Évalué à 1.

        Matlab c'est pas libre, c'est cher et c'est pas ideal pour tout. OK. Mais Scilab et Octave manquent de fonctionalités et cela freine enormement leur diffusion.
        En plus, Scilab et un langage très différent de Matlab. Certaine fonctionalités comme les sorties graphiques ne sont pas faciles à utiliser (par rapport à Matlab). Les parametres des fonctions sont souvent alambiqués et jamais compatibles avec Matlab. Meme un truc bete comme la fft n'est pas compatible avec Matlab.
        Personnellement c'est Scilab qui me fait ch... Si on utilise Matlab c'est quand même pour la simplicité. Octave, du fait de la compatibilité Matlab, j'aime mieux, mais ça manque de tout. C'est certainement bien pour les petits projets, genre, quand on a pas matlab sous la main.

        Avec lush, on peut espérer que la comunauté scientifique developpe de chouets outils pour LUSH et que ça finisse par devenir aussi intéressant que Matlab.
        • [^] # Re: Un progrés évident.

          Posté par  (site web personnel) . Évalué à 1.

          Je suis plutot d'accord, d'autant que <pincettes>je suis pas sûr sûr de moi, mais il me semble avoir entendu que scilab serait un projet plus ou moins à l'abandon à l'inria</pincettes>. Et octave a comme tu le dis beaucoup de lacunes.. D'autant que la compatibilité avec le langage matlab n'est finalement pas une bonne chose, surtout quand on voit la tournure que celui-ci prend: son nouvel aspect "orienté objet' me semble particulièrement crétin (faire un répertoire par type d'objet !?), l'introduction des types (uint32, single, char, ...) est incomplète et mal foutue, le nombre de fonctions intrinsèques devient astronomique (du coup c'est de moins en moins simple). Et je ne parle pas des javaneries.. Bref l'utilisation de matlab a le don de me foutre de mauvaise humeur.. Mais il reste incontournable, d'autant plus qu'il est souvent utilisé par des gens qui ne connaissent pas d'autre langages et qui n'ont aucune envie de changer leurs habitudes (ça rejoint ce que tu disais sur scilab, et c'est aussi pour cette raison que je n'ai jamais fait l'effort d'apprendre à m'en servir).
          • [^] # Compatibilité ??? Pensez plus loin!

            Posté par  . Évalué à 1.

            Vos discours sont quand même un peu paradoxales.
            Dans un sens vous critiquer matlab pour son manque de liberté et le fait qu'il soit propriétaire, et de l'autre vous trouvez que scilab et octave ne sont pas assez compatible avec matlab.

            Au début je pensais comme vous. Je voulais avoir un max de compatibilité entre ces langages. Par la suite, en discutant sur des forums spécialisés et aux travers de mails avec les développeurs de ces projets libres, je me suis rendu compte qu'il fallait quelque peu "oublier" matlab et voir ce que scilab et octave ont à offrir.

            Alors si vous trouvez que scilab est un peu trop "alambiqué" c'est que vous avez pas azssez creusé. Une fois que l'on passe au delà de ce style, on se rend compte des fonctionnalités qu'il offre. Pour Scilab, je vous conseille d'ailleurs les très bons articles parut dans Gnu Linux Magazine il y'a un peu moins d'un an.

            En outre, pour avoir manipuler la fft tous les jours, je peux vous assurer que celle de scilab fonctionne très bien et aussi rapidement que celle de matlab:
            --> x = rand(1,1024);
            --> y = fft(x,-1); %% pour la fft
            --> nx = fft(x, 1); %% pour la ifft


            Jack.
            • [^] # Re: Compatibilité ??? Pensez plus loin!

              Posté par  . Évalué à 1.

              Scilab est un langage à part (raison historique: avant c'etait un concurent propriétaire de matlab developpé par l'INRIA). Aujourd'hui Scilab est devenu libre parce que le retard accumulé par rapport à son concurrent est devnu trop grand et le logiciel était condamné à mourir sinon. Cela ne fait pas pour autant de Scilab un concurent sérieux à Matlab. Il vaudrait peut etre mieux privilégier des alternatives différentes et plus puissantes que Matlab. Flush semble avoir le potentiel et le lisp n'est pas trop difficile à apprendre. Malheureusement, après avoir examiné la question de près, il me semble que le choix des auteurs concernant la manipulation des matrices est douteux. Pourquoi passer par la notion de tenseurs pour multiplier deux matrices? De plus, il n'est pas clair que la mise en oeuvre garrantit des performances interessantes. Notamment il n'est pas précisé dans la présentation du logiciel que flush s'appuie sur des routines de type BLAS/ATLAS, ce qui pourrait être quand meme un argument vendeur. De plus, l'interface avec des matrices gsl me semble plus être une redondance qu'un atout. D'autant que gsl possède aussi a ce stade deux types de routines pour la manipulation de matrices (gsl natif et BLAS)

              Bref que penser ?
              • [^] # Re: Compatibilité ??? Pensez plus loin!

                Posté par  (site web personnel) . Évalué à 1.

                Bref que penser ?

                Déjà c'est lush, pas flush.

                Pour ce qui est de l'interface gsl, c'est pas vraiment une redondance. Les routines d'algèbre linéaire (qui ne sont pas aussi générales que celles de BLAS il est vrai) ne constituent qu'une petite partie de la GSL. J'imagine que ce sont toutes les autres routines qui les intéressaient (minimisation, fft, solveurs, ...).

                Je comprends pas trop quel est ton problème avec les tenseurs mais pour moi, il est clair que la mise en oeuvre garantit des performances interessantes. :)

                De toutes façons, je pense pas qu'avoir de la redondance soit un problème. Apparemment un des intérêts de lush, c'est l'interfacage facile avec les bibliothèques en C et la possibilité de compiler en C certaines fonctions tout en utilisant la même syntaxe. Une fois que tu maîtrises ça, c'est bien de pouvoir choisir parmi différentes bibliothèques de calcul.
                • [^] # Re: Compatibilité ??? Pensez plus loin!

                  Posté par  . Évalué à 1.

                  D'abord, le nouveau systeme d'archives de linuxfr est penible.
                  Ensuite flush ou lush on a le droit aux typos!
                  Plus sérieusement, le problème c'est que un matin je vais décider de commencer un projet avec gsl. Ensuite, le lendemain je m'aperçois que je dois utiliser une autre bibliothèque. et hop! je dois convertir toutes les vecteurs et matrices pour utiliser la nouvelle bibliothèque qui n'aura pas le m^eme format. Ca c'est vraiment pénible! Je ne comprends pas du tout la position qui consiste à dire que ce n'est pas un probleme. Pour moi, quand pour mon travail, ça l'est. Et si je veux faire de l'informatique de bas niveau, je ferai du C/C++, point, mais écrire un algorithme en C, ca prend du temps. Pourquoi les gens sont pret à payer 10kEUR une licence Matlab à votre avis?

                  Je veux que ce soit simple avant tout. et que je puisse écrire
                  y=A*x ou (* A x) peu importe mais que ce ne soit pas idx_machin1multmachin2transp puis gsl_matrix_mult, puis gsl_blas_dgemm. Voilà! Je suis pour "Un code simple et lisible"
                  • [^] # Re: Compatibilité ??? Pensez plus loin!

                    Posté par  . Évalué à 1.

                    et qu'est ce que vous pensez de python, en particulier en ce qui concerne numpy ?
                    • [^] # Re: Compatibilité ??? Pensez plus loin!

                      Posté par  . Évalué à 1.

                      Je remarque qu'il faut aller pecher la news de plus en plus loin dans les archives...
                      Je ne connais pas bien. Mais j'ai surtout l'impression que l'on ne peut pas faire grand chose d'intéressant avec pour le moment. Se limiter à wrapper les routines de bases LAPACK/BLAS c'est assez léger pour une utilisation intensive. Des tas (enfin ... moins de dix quand même) de bibliothèques C++ le font déjà avec plus ou moins de succés.
                      Le minimum de fonctionnalités pour qu'un logiciel scientifique prenne de l'essort c'est >= GSL à mon avis. Sinon ça ne vaut pas le coup et personne n'acceptera d'investir du temps là dedans.
  • # Cool

    Posté par  (site web personnel) . Évalué à 1.

    C'est vrai que ça a l'air bien. Mais apparemment ils ont merdé leur release sur sourceforge : pas de fichier à télécharger ...

    C'est fait par l'équipe qui a fait DjVu http://djvu.sourceforge.net/(...)
    • [^] # Re: Cool

      Posté par  . Évalué à 1.

      Je l'ai téléchargé à partir du CVS, que j'ai archivé dans un "tarball".
      J'ai aussi créé un fichier SPEC pour compiler un paquet rpm:
      ----------------------------------------------------------------------------------------
      Summary: Lisp Universal SHell
      Name: lush
      Version: 0.95CVS
      Release: 1
      Group: Applications/Scientific
      Copyright: GPL
      Source: lush-%{version}.tar.bz2
      BuildRoot: /tmp/lush-root
      URL: http://lush.sourceforge.net/(...)

      %description
      Lush is an object-oriented Lisp interpreter/compiler with features
      designed to please people who want to prototype large numerical
      applications. Lush includes an extensive library of
      vector/matrix/tensor manipulation, numerous numerical libraries
      (including GSL, LAPACK, and BLAS), a set of graphic functions, a
      simple GUI toolkit, and interfaces to various graphic and multimedia
      libraries such as OpenGL, SDL, Video4Linux, and ALSA (video/audio
      grabbing), and others. Lush is an ideal frontend script language for
      programming projects written in C or other languages.

      %prep
      %setup -n lush

      %build
      CFLAGS="$RPM_OPT_FLAGS" ./configure --prefix=%{_prefix}
      make

      %install
      mkdir -p $RPM_BUILD_ROOT%{_bindir}
      mkdir -p $RPM_BUILD_ROOT%{_prefix}/man/man1
      mkdir -p $RPM_BUILD_ROOT%{_datadir}
      make install prefix=$RPM_BUILD_ROOT%{_prefix}
      cp -r doc $RPM_BUILD_ROOT%{_datadir}/lush
      rm -rf $RPM_BUILD_ROOT%{_datadir}/lush/src

      %clean
      [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "$RPM_BUILD_ROOT"

      %files
      %defattr(-,root,root)
      %{_bindir}/lush
      %{_prefix}/man/man1/lush.1*
      %{_datadir}/lush
      %doc COPYING COPYRIGHT NOTES README
      ----------------------------------------------------------------------------------------

      Un des aspect les plus intéressant de Lush est 'intégration de plusieurs librairies, entre-autre pour la saisie vidéo et la reconnaissance de formes.
      --
      Marc

Suivre le flux des commentaires

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