Sytoka Modon a écrit 4538 commentaires

Scilab est déjà mis en paquets pour pas mal de distributions. Je parlais évidement des toolboxes. Si vous avez un outil pour bien les packager, il devrait être possible d'encapsuler ses packages dans des .deb et des .rpm.

Personnellement, j'aime bien garder ma debian propre et donc je préfère installer sous forme de package .deb. Par ailleurs, mon parc machine est trop gros pour que je m'amuse à rajouter à la main un paquet ici ou là.

> mais c'est un gros boulot comme tu peux l'imaginer ...

Je sais mais c'est justement là ou Matlab est mauvais.

Au niveau graphisme, je ne suis pas utilisateur personnellement ni de matlab, ni de scilab mais c'est la première critique que me font les chercheurs.

Il me semble donc que ces deux points permettraient de refaire rentrer scilab dans les laboratoires ou matlab règne en maître. Surtout que nos chercheurs n'utilisent que quatre ou cinq fonctions de chaque toolbox matlab donc avec un site collaboratif, il devrait être possible (en tant cas, je l'espère), d'améliorer le partage de ces fonctions manquantes.

Si c'est prévu de faire le packaging dans votre roadmap, alors comme vous n'êtes pas l'utilisateur lambda, il ne doit pas être trop dur de transformer vos paquets en paquets debian ;-)

Au boulot ou je bosse (recherche publique dans les domaines de l'ingénerie), tout le monde bosse sur Matlab qui a deux points forts :

- toolbox adapté et qui coince l'utilisateur

- graphique performant

Je n'ai pas essayé la dernière version mais sur les graphiques, scilab était à la rue... C'est vraiment un point bloquant pour un utilisateur voulant passé de matlab à scilab.

Pour les toolbox, voir mon post précédent sur un vrai CPAN qui me semble une des voie possible.

Sinon, il y a aussi un point ou scilab pourrait sortir son épingle du jeu, matlab est à la rue sur le calcul parallèle. Il ne tourne pas ou très mal sur les machines SMP Itanium...

Il me semble qu'il y a un coup à jouer à avoir une version matlab qui pourrait tirer profit relativement facilement pour le programmeur des machines SMP (voir des cluster MPI mais c'est déjà moins facile à programmer). Pour cela, il faut paralléliser tout le coeur du produit... Je ne sais pas si la tâche est faisable.

Au niveau des contributions, il faut absolument éviter le piège de CAMEL et d'avoir juste une liste qui pointe vers différents site web. C'est un peu le cas pour ce que j'en ai vu du site de scilab.

Il faut que tout le code source des contributions soit sur un seul et même site, structurer et hierarchisé. Un vrai CPAN.

Il faut aussi que l'installation d'une contribution soit facile, encore une fois comme sur le CPAN de Perl.

Un autre point à mon sens important, il faut pouvoir générer très facilement un paquet deb pour la debian et un paquet rpm de toutes les contributions. Encore une fois, regarder du coté de debian ce qu'ils font pour les modules Perl.

C'est la qualité mais aussi la facilité d'étendre un scilab libre qui lui donnera une chance de succès.

Inutilisable en environnement multi-utilisateur ! Honnêtement, c'est fait pour l'embarqué.

J'utilise wmii qui est très bien sauf sur deux points : la gestion des des fenêtres flottantes est trop basique et on ne peut pas découper l'écran à l'horizontal comme sous ion. C'est gênant pour quelques applications.

Interne ou externe. En général, je sauve en double sur deux disques externe.

Attention, les CD et DVD ne sont pas fiables, enfin pas plus fiable qu'un disque... Leur durée de vie est relativement faible et leur capacité trop limité.

Pour mon programme de backup, c'est rsnapshot avec un méta script par dessus.

> Ubuntu est un mot africain très ancien signifiant "je n'arrive pas à
> configurer debian"

Cela prouve bien que debian est le berceau de l'humanité ;-)

D'un autre coté, je préfère un Lisaac 100% libre que la solution batarde de scilab. Au moins avec un Lisacc et un CLAN, on peut espérer voir quelque chose dans le monde libre alors que scilab a un réel problème à résoudre qui n'a toujours pas de solution.

Si on prends un autre langage que j'aime bien, perl, j'avoue que je n'ai vu que du perl libre la ou je suis passé.

J'ai cru comprendre que Lisaac était passé du coté du CNRS ? Serais L'INRIA le problème...

Ok, je -> []

Je ne sais pas mais globalement, j'ai l'impression que si les premiers jets ont été fait par des matheux, les versions suivantes ont été faites par des experts de génie logiciel. Par exemple, pour Fortran, qui est dans les organismes de normalisation ?

Si je prends l'exemple de Sather, l'équipe qui l'a conçu en partant d'Effeil à divergé sur un point de conception. Dans Effeil, Meyer essaye par tous les moyens d'unifier tous les concepts autour de sa notion d'objet alors que Sather est construit pour orthogonaliser un maximum les concepts afin que l'implémentation et la syntaxe de l'un n'intervienne que le moins possible sur l'autre. Je trouve que cette approche est du grand art de génie logiciel.

Dernier exemple pris exprès à contre courant de << l'approche francaise >>, Perl est un grand langage (pour moi) qui est piloté par un linguiste. En cela, Perl ouvre peut être la voie. Ce n'est peut être pas le premier dans ce cas là mais cela doit être l'un des plus utilisé.

Sur ce dernier langage, je ne suis pas d'accord avec Benoit et la manière dont il a critiqué les autres langages (même s'il ne cite pas Perl). Perl6 n'a pas la même ambition que Lisaac mais lorsque l'on connait la qualité des personnes qui travaillent dessus depuis pas mal d'année, la somme des concepts que ce langage va permettre d'utiliser, cela me donne un sentiment de profond respect.

Mais je suis aussi programmeur lorsque j'ai le temps. Et en admin système, tu programmes, certes du bash la plupart du temps...

La ou je veux en venir est qu'on n'est pas tous des dieux de l'informatique et je vois bien que mes programmes sont à cent lieux des optimisations que font pas mal de gens sur dlfp. Mais enfin, je code et je n'y connais rien au concept mathématique qui sont derrière l'informatique. Cela ne m'a pas empêché de faire à une époque un tout petit peu d'assembleur.

Je comprends que lorsqu'on fait un nouveau langage ou une nouvelle structure de données btree... On s'amuse à essayer de démontrer par A + B que ce que l'on fait est bien mais cela concerne combien d'informaticien en pratique. Très peu.

En plus, je me souviens que certain algo de convergence en calcul numérique converge super bien alors que mathématiquement, on n'arrive pas à le démontrer et que l'inverse arrive aussi (un super algo qui converge d'après le théorème mais qui ne marche pas en pratique). Il faut voir que la machine fait pas mal d'erreur et ne suis donc pas toujours les maths elle aussi.

> A la seconde : "même si on ne fait qu'appliquer des outils, il est
> souvent nécessaire de bien les comprendre, donc faut quand même
> comprendre un minimum les maths"

Je suis Administrateur Système et Réseau. je peux t'assurer que la plupart des copains qui le sont aussi ne sont pas des matheux pour un sous.

Il n'y a pas besoin d'être bon en math pour régler un serveur samba ou postfix. Pour faire ces choses là, il faut savoir faire du génie logiciel donc connaitre les limites de ceux-ci et les conséquences de telle ou telle action.

Je suis d'accord avec toi. J'ai un peu trop globalisé ;-) En gros, je voulais dire que l'informatique en france est globalement dans la sphère des maths (et je dirais globalement plutôt du coté math appli) alors que petit à petit, il va se passer la même chose que dans les autres discipline du SPI et le génie logiciel aura (ou a déjà) avoir sa place propre comme le génie électrique.

De ce que je vois, l'informatique à la fac ou dans les écoles d'ingenieurs est souvent proche soit des UFR de math, soit des écoles de math.

• As tu regardé les pages suivantes ?
• comment définir un iterator http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)
• quelques exemples avec plusieurs iterator et pas forcément entier http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)
• J'ai l'impression que ce que tu fait est à des lieux des iterators de Sather et ressemble fortement à ceux de Ruby.
• Il faut bien comprendre ceci. Un objet dans Sather peut avoir trois types d'objet qui lui sont rattaché : des attributs, des méthodes (jusque là, que du classique) et des iterators. Un itetator N'EST PAS une méthode et ne se comporte pas du tout pareil.
• Un iterator est une coroutine qui n'est valable que dans un block loop. Il peut y avoir plusieurs iterators dans un même block (ce qui n'est souvent pas le cas dans les autres langages qui n'ont pas d'iterator de bas niveau mais un truc simulé via des méthodes).
• Un iterator peut avoir des paramêtres de type IN, OUT et INOUT mais avec aussi la notion ONCE ou non. Si un paramêtre à l'adjectif ONCE, il n'est évalué que lors du PREMIER appel alors que sinon, il est évalué à chaque appel.
• Un iterator n'a pas de valeur de retour comme une fonction mais se suspend via l'instruction yield et renvoi provisoirement une valeur à ce moment là. Lors du prochain appel, c'est l'instruction qui suit yield qui est exécuté.
• S'il y a une boucle avec plusieurs iterators, c'est le premier iterator qui se termine (plus de yield) qui permet de quitter la boucle, que les autres iterators soit finis ou non. Par contre, le langage à ce moment termine tous les contextes des autres co-routine non finit et purge la mémoire (mais tout cela est complètement transparent).
• Les iterators de Sather ne sont pas du tout limité aux entiers. C'est juste un cas particulier. Il y a par exemple des ietrator sur les booléens qui permettent de faire les boucles while et until facilement. Il y a plein d'iterator sur les chaînes et aussi sur les réels.
• Je vais mettre deux exemples que j'aime bien mais la syntaxe de linuxfr est parfois casse-pied. On en trouve d'autres sur le web mieux rédigés.
• Il faut évidement définir x mais il n'y a pas besoin de l'initialisér, c'est l'iterator sum! qui s'en occupe. Dans cet exemple, trois itérators fonctionnent en parallèle et le code est particulièrement clair et sur (qui n'a pas oublié un jour de faire x:=0 avant la boucle ?).

loop
   x := sum!(a.elt! * b.elt!);
end;

• Un autre qui parle d'affichage qui permet d'imprimer "1,2,3" en mettant une virgule entre les éléments juste ou il faut.

a:ARRAY{INT} := |1,2,3|;
loop
   #OUT + ",".separate!(a.elt!.str);
end;

• L'iterator separate! est définit comme suit :

class STR is
   ...
   separate!(s: STR): STR is
      -- La premiere iteration, on retourne juste la chaine 's'
      -- Sur les suivantes, on retourne Self + 's'
      yield s.str;
      loop
         yield self + s.str;
      end;
   end;
   ...
end;

• On remarque qu'il y a une boucle infini dans l'itérator separate! Cette boucle ne s'arrête jamais, simplement, lorsque l'iterator separate! n'a plus rien à manger, la boucle au dessus s'arrête d'elle même et toutes les coroutines en cours de tout le contexte sont automatiquement nettoyé.
• On voit bien sur ces exemples que le block LOOP est particulier et permet de gérer les contextes des iterator. C'est le fait d'avoir ce block spécial qui donne toute la force à ces iterators. Les iterators ne peuvent être employés que dans les block loop avec une petite extension syntaxique avec 'parloop' pour la partie calcul parallèle de Sather
http://www.gnu.org/software/sather/docs-1.2/specification/pa(...)
• Un dernier lien qui donne les spécifications du langage, c'est pas le document le plus pédagogique que j'ai trouvé ;-)
http://www.gnu.org/software/sather/docs-1.2/specification/sa(...)

Et les espaces de Riemann, c'est pas des maths peut-être ? C'est pas pour cela qu'Einstein était un mathématicien !

Je trouve que pas mal de post ici confondent math et génie logiciel.

> Je n'ai pas l'impression que depuis elle soit devenue une science à
> part.

Justement, je me le demande parfois. Les maths se sont construites en même temps que les sciences pour l'ingénieur jusqu'en 1900 pour faire grossier. Depuis, c'est plus flou de savoir qui avance le premier les billes (par exemple, la notion de distribution était utilisé en SPI avant que Swartz ne formalise tout cela sous cette appellation).

Aujourd'hui, je ne suis pas sur que ce soit toujours des matheux qui portent les nouveaux langages. En france, l'informatique est rattaché aux maths appliquées donc le lien est fort et la france est forte en math ! Je ne sais pas si aux USA le lien est aussi fort, surtout que la bas il n'y a pas cette distinction math appli - math pure.

Donc, il y a l'effet INRIA en france donc on le voit sur les langages réalisés plus particulièrement en france.

Mais si je prends perl6 par exemple, je suis loin d'être aussi sur de ton affirmation. Que les concepteurs essayent de faire le plus logique possible, je veux bien le croire (normal) mais j'ai vraiment l'impression que de plus en plus de langage vont se faire sans que cela soit un groupe de matheux qui en soit à l'origine.

Les sciences pour l'ingénieur étant le plus possible cohérentes, elles ont besoin de preuve de type mathématiques pour justement démontrer cette cohérence.

Si je prends la théorie des éléments finis très utilisée en calcul de structure, elle a été mise au point par des mécaniciens, puis des matheux ont formalisé tout cela avec la notion de formulation faible et d'espace de Sobolev. Cela ne veut d'ailleurs pas dire que tout calcul éléments finis est mathématiquement juste car seul un petit bout de ce qu'utilise les mécaniciens est 'prouvé' mathématiquement.

Alors maintenant, on trouve des bouquins qui sont 'à cheval' entre les mthas et la mécanique et qui expose les éléments finis plutôt d'un point de vue ou plutôt de l'autre.

C'est pas pour cela qu'un ingénieur fait des maths lorsqu'il calcule un pont ! Il utilise des maths pour faire des Sciences Pour l'Ingénieur (le fameux SPI qu'on voit un peu partout maintenant).

C'est pas parce que que la théorie est cohérente mathématiquement que l'on fait des maths. Les sciences pour l'ingénieur, c'est quoi ?

Exemple, je fais du calcul de structure par élément finis, c'est des maths ? Et bien non. Lorsque je démontre que les éléments finis converge dans des cas précis, oui, là, je fais des maths. Mais pas lors d'une utilisation sur des cas réels.

Génial, je suis bien content que nos discutions est amené ce point là qui manque tant à OCaml et à Effeil.

En parlant du CLAN, la notion d'espace de nom a-t-elle été rajouté dans Lisaac ? Je sais que Benoit est contre mais comme il a été indiqué dans pas mal de post de cette nouvelle, l'aspect social est important dans la réussite d'un langage. Or je suis sur que pouvoir structurer l'arbre des classes dans des espaces de noms et donc pouvoir les ranger par thème dans le CLAN est très important. Au niveau du compilateur, vu qu'il y a une optimisation globale, la notion d'espace de nom n'a aucun intérêt. C'est cependant un des soucis d'Effeil de ne pas supporter cela car l'arbre des classes d'Effeil est un 'bordel' à mon sens car il y a 10000 classes à plat. Comment retrouver ses petits la dedans ?

Si on prends le CPAN de Perl, les choses sont classées dans des boites, ce qui est sous l'espace Apache:: concerne Apache et ainsi de suite... C'est hyper clair pour l'utilisateur et facilite grandement search.cpan.org !

Puisque je suis cité, j'en profites, c'est pas tous les jours ;-) Un autre de mes dadas était les iterator de Sather qui était implémenté sous forme de coroutine et qui était bien supérieur a tout ce que j'ai vu dans d'autres langages. Tu l'as dis toi-même dans un de tes posts ci-dessous, un GROS problème en programmation est le nombre d'erreur réalisé dans les bornes des boucles. C'est là ou les iterators de Sather était sublime car je ne me souviens plus avoir fait ce genre d'erreur dans ce langage ce qui n'a pas été le cas avec tous les autres langages que j'ai utilisé.

Pour ceux qui pense que les iterators de leur langage sont aussi bien que ceux de Sather, je conseille d'aller voir la page suivante et de prendre le temps d'aller au dela du premier exemple...

http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)

Ma question est donc : est-il possible de faire aussi bien en Lisaac ?

En premier, j'ai rédigé ma réponse l'autre jour beaucoup trop rapidement. Du coup mon post est quasiment illisble. Désolé.

> c'est difficile pour le noyeau de faire des traces..

Le daemon klogd, il est pas fait pour cela ?

Pour ce qui est de /var, le problème est que lorqu'il est plein, tu ne peux plus faire grand chose car tu n'arrives plus à te logguer sur la machine. Par exemple, ssh ne marche plus...

En général, tu doit plus ou moins faire un reboot pour en reprendre le controle. C'est très pénible.

Alors OK, un /var plein est signe d'une mauvaise gestion mais cela m'est déjà malheureusement arrivé.

Je ne dis pas qu'il faille forcément supprimer des fichiers sur /var au premier exécutable qui cherche à écrire mais j'ai pris cet exemple car c'est un peu ce que fait le noyau pour la mémoire.

Le noyau pourrait peut être aussi tuer un processus qui essaye d'écrire sur une partition pleine ? Je n'essaye pas ici de faire un critique à 100% négative du développement du noyau mais simplement de montrer le parallèle entre deux situations bloquantes et profiter de cela pour lancer le débat.

Etant un admirateur de Sather, je ne peux qu'être enchanté par cette annonce parfaitement rédigée.

Merci.

Encore une fois, c'est une option de compilation. Il est tout à fait possible d'avoir des fontes LaTeX propre avec la sortie PDF. Il suffit de rajouter le usepackage qui va bien au début du fichier LaTeX. Je ne vois pas en quoi DocBook change quoi que ce soit à ce problème puisque dans plein de cas, DocBook est formatté via TeX !

Ensuite, on dira ce que l'on voudra mais une présentation faite avec beamer, ca a une autre allure.

LaTeX est fait par défaut pour faire des poly si on prends le format book. Or un Poly, il faut le coller, le couper... Donc avoir des marges !

Ensuite, comme il a été dis, changer les marges est super facile. Pour être mauvaise langue, il est aussi super facile de faire un document XML avec de grande marge !

Au niveau Police de caractère, je suis désolé mais les polices LaTeX sont bien plus belles. Simplement, on est tous tellement habitués aux autres polices qu'un document LaTex pourrait 'choquer'. Personnellement, je préfère très largemenbt ces polices à celles par défaut de Firefox ou d'OpenOffice.

Enfin, pour la forme et le fond, c'est du FUD de chez FUD... Il a déjà été répondu plein de fois ici même que c'est faux. S'il n'y avait que 5% des ressources mis sur le HTML et dérivée (XHTML, DocBOOK...) qui était mis sur LaTeX, cela ferait longtemps que les quelques erreurs initiales qui restent auraient été corrigé.

Le XML dans un éditeur, c'est CHIANT. Un fichier de configuration en XML, c'est CHIANT... Le XML est un langage fait pour la machine et pour les interfaces graphiques, pas pour l'homme. Va écrire des équations méthématiques en XML et écrit les en LaTeX et tu changera ton opinion sur la qualité humaine du LaTeX.

J'ai vu très peu de thèse écrites en DocBook dans vi alors que je peux t'affirmer qu'il y en a plusieurs milliers qui ont été faites ainsi sous LaTeX.

Je suis d'accord avec toi. Les creative commons, la GFDL... c'est bien compliqué. Je ne comprends pas pourquoi il n'y a pas plus de texte qui sorte sous GPL tout court.

Malgré le nombre de page de la licence GPL, sa compréhension est claire pour un très grand nombre et elle a montré sa capacité à resisté au temps (et aux tribunaux !).

Pour avoir déjà eu le problème il y a deux ans, le deboguage lorsque l'on ne le sais pas est difficile...

Il n'y a aucune trace dans les log du processus killer et si le processus est lancé en ligne de commande, il disparait tout simplement sans laisser de trace. C'est cela qui est génant, le fait de n'avoir aucune trace.

Donc on ne sais pas à quelle heure le processus et mort et pourquoi.

De nos jours, un PC ne marche pas non plus si /var est plein et c'est pas pour cela que lorsque /var est plein que le noyau tue le processus qui écrit le plus dans /var !

Je ne dis pas que le problème /var est identique au problème de la mémoire mais les deux sont fondamentaux et lé réponse actuelle du système Linux n'est pas réellement satisfaisante dans lorsque ces sous parties sont saturées.