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 Anonyme . Évalué à 1.
[^] # Re: LUSH : Lisp Universal SHell
Posté par Troy McClure (site web personnel) . Évalué à 1.
Y'a quand même un truc relativement original, voire tordu, c'est la possibilité d'inliner du code C directement dans le lisp, celui-ci étant compilé à la volée ! http://lush.sourceforge.net/images/screendumps/helptool01.png(...)
# Pas convaincu
Posté par Jiba (site web personnel) . Évalué à 1.
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 Vaillant Jerome . Évalué à 1.
http://wuarchive.wustl.edu/languages/yorick/yorick-ad.html(...)
http://yorick-mb.sourceforge.net/(...)
[^] # Une news, une news, une news, ....
Posté par Jack . Évalué à 1.
Ca mérite une news en pleine page de linuxfr ce language.
Qui se lance ?
Jack
[^] # Re: Pas convaincu
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Tu es au courant que c'est de la mythologie chrétienne ?
# Un progrés évident.
Posté par E V . Évalué à 1.
[^] # Re: Un progrés évident.
Posté par Jack . Évalué à 1.
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 E V . Évalué à 1.
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 Troy McClure (site web personnel) . Évalué à 1.
[^] # Compatibilité ??? Pensez plus loin!
Posté par Jack . Évalué à 1.
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 E V . Évalué à 1.
Bref que penser ?
[^] # Re: Compatibilité ??? Pensez plus loin!
Posté par Vivi (site web personnel) . Évalué à 1.
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 E V . Évalué à 1.
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 daniel . Évalué à 1.
[^] # Re: Compatibilité ??? Pensez plus loin!
Posté par E V . Évalué à 1.
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 Vivi (site web personnel) . Évalué à 1.
C'est fait par l'équipe qui a fait DjVu http://djvu.sourceforge.net/(...)
[^] # Re: Cool
Posté par Marc Lavallée . Évalué à 1.
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.