Ontologia a écrit 2119 commentaires

On remarquera que le héros du comics en question à l'air maigre, musclé, bien formé. Ce qui est anormal pour un vrai geek qui passe son temps à manger des pizzas ou des chips devant son kernel en 25éme recompilation de la journée.

ok je -> []

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

je ne pensais pas au graphe de dépendance pour faire de la parralélisation automatique, je sais bien que c'est plus complexe que ça. J'y pensais pour éviter de recourir à des OoO...

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Et de toutes façon, ordonner les instructions dans le bon sens, c'est le boulot du compilateur. Si on est obligé de faire des processeurs OoO, c'est parce que la science des compilateurs n'a pas assez avancé pour générer du code ultra optimisé.

Cela dit, la grammaire du C faisant deux pages, je comprend très bien que ce n'est pas simple.
Mais j'ai toujours été fasciné par le nombre de 10^6 transistors qu'on sacrifie à faire des incantations vaudou sur le code, tout ça parce que le compilo est pas foutu de faire un graphe de dépendance.

Il y a un trou dans la reccherche théorique j'ai l'impression.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Qu'il y ait des VMs performantes est une chose, mais c'est la nécessité d'une VM qui me dérange. Elle a de grande chance d'être codée en C.
L'objectif (entre autre)de lisaac est de rendre le C inutile (pour les non réfractaires à l'objet bien sûr).

Quand au conteneur à objet, IsaacOS en est un, par nature, mais natif lui. Le système est intrinsèquement et intégralement un système objet, tandis qu'avec une VM tu "applati" ton modèle mémoire en utilisant de la pagination classique.

Slate et Io ne me semblent pas offrir les possibilités d'héritages dynamique de lisaac, mais j'ai du le louper.


La morale de tout cela est pour moi la suivante : Les auteurs de Slate et Io qui ont commencé leur travail à peu près en même temps que Benoit, ne se sont pas concentrés sur le compilateur, mais sur le langage, il n'est donc pas étonnant que les résultats soient aussi intéressant.
Lisaac, lui est avant tout un compilateur qui résout la problématique d'un code "haut niveau pour le système aussi rapide que du C". Cela signifie que plus 90 % du travail s'est concentré sur le compilateur et comment supprimer la liaison dynamique, sans oublier la spécialisation de code et l'inlining ultra poussé.

Après, c'est très stimulant, il y a d'autres langages de ce genre ?

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Ya pas que le pc dans la vie...

Cette librairie a vocation à être multiplateforme : Lisaac est le langage qui permet d'écrire l'OS Isaac. Isaac tourne d'ors et déjà sur cinq architectures différentes.

Comme c'est un OS, il faudra réécrire les drivers.

Sur PC effectivement, on se reposera sur des bindings, mais c'est un cas particulier.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Alors tout d'abord merci beaucoup Miguel pour ces liens. C'est très stimulant :)

A première vu je remarque :

1. Ils sont plus avancés que Lisaac sur certains points, mais il est prévu de les implémenter dans le langage. Tu connais le système de recherche français, et tu peux aisément imaginer que l'auteur du compilateur est englué dans la paperasse depuis pas mal de temps alors que ses collègues travaillent et construisent.
Ce n'est qu'une question de temps :)
Et ca va venir vite ( la 0.2 est pour bientot)...

2. Sauf erreur de ma part ces deux langages sont chacuns basés sur une VM, le fervent utilisateur de Squeak que tu es n'est pas dérangé par cet aspect. Nous on ne veut pas de VM, ou tout au moins la possibilité de ne pas avoir à s'en servir.

3. Et c'est lié avec 2, lisaac est un langage objet à prototype compilé ce qui n'est pas le cas de io et slate sauf erreur de ma part. Faire un langage hyper puissant est bel et bon mais si ça rame autant que Java c'est beaucoup moins intéressant déjà...

4. A part le design "acteur" dans io et les librairies beaucoup plus étoffées (c'est facile, c'est une VM...) je vois pas en quoi il y a plus de choses en Lisaac (on peut faire beaucoup de camlrie en lisaac). Es-tu sûr d'avoir bien évalué tout ce qu'est capable de faire Lisaac ? Son auteur m'a confié plusieurs fois que le compilateur était loin d'être totalement exploité dans les possibilités offertes.

Note : j'arrive pas à compiler slate :(

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Eh bien si tu veux participer à l'aventure, tu es le bienvenu :)

Il ya plein de choses à faires, du code, faire avancer l'OS, le compilo, les nouveaux concepts, tout ça... ;o)

Donc n'hésite pas :)

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Donc, tu veux un objet sprite, donc la possibilité de gérer des collections de sprites, avec quelques méthodes comme HitTest, changement de gamma ou des choses de ce genre.

Attention, lisaac n'est pas un langage objet à classe : tu n'instancie pas un objet, tu le clone. Donc pas besoin de définir un héritage, etc...
Tu le clone, tu lui met ses octets de bitmap dedans et terminé.
Quand au pointeur, tu fait ma_liste_de_sprite : LINKED_LIST[SPRITE];

et ensuite tu y accède avec des opérations du style

(ma_liste_de_sprite.item i.hitTest).if {"Touché\n".print;};



Pour la problématique du niveau d'abstraction,

1) Chacun pourra se contenter de se servir des briques de bases et de manipuler des bits si ça lui chante
2) Lisaac est un langage haut niveau conçu pour le système, il est très à l'aise avec ça
3) Le compilateur est le compilo objet le plus optimisé à l'heure actuel : il produit du code dont les performances atteignent celles du C.
4) Le haut niveau d'abstraction n'est là que pour simplifier la vie à ceux qui ne veulent pas rentrer dans les détails.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Ce n'est pas l'objectif.

L'objectif est de concevoir une nouvelle bibliothèque, conceptuellement.

Si tel était mon intention, je n'aurai pas posté ce journal :)

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

>Ton projet me semble énorme, déjà. Combien d'années te seront nécessaires pour arriver à un niveau de fonctionnalités voisin de Directx ou SDL+ OpenGL+OpenAL ?

Je parle de spécification. Pour le code, on verra. De toutes façons, on code 15 fois plus vite en lisaac qu'en C++

Ensuite, je me concentrerais sur les fonctionnalités de base au début, reprenant des remarques intéressantes du style de celle d' Adrien Bustany là haut. Pour concurrencer SDL, on verra plus tard.

> Et partir sur un langage peu utilisé voir inconnu ne risque pas de t'amener beaucoup de développeurs tiers...

Ce langage est inconnu pour l'instant, mais ça va changer.

> Sans compter les bindings supplémentaires à faire pour que ta lib soit utilisable par d'autres langages plus populaires...

Ils se débrouilleront avec les sources C que le compilateur cracheras.
Cela dit, on pourra trouver d'autres solutions. Je ne cherche qu'à spécifier une librairie pour ce langage.

De toutes façon, importer une librairie construite dans un logique d'objet à prototype dans un langage à classe risque de poser quelques problème à la marge.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Cela dit je ne sais pas si tu as déjà rencontré le rédac' chef de PLPL, il est intéressant mais assez illuminé, et pas mal marxiste non plus...

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

ce sont des littéraires, ils ne savent pas raisonner !

ok je -> [ ]

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

C'est codé à l'arache, c'est la première fois que je fais du java...

Merci :)

Petit problème, il me dit que this ne connait pas addKeyListener( ds la doc, il est dit que AddKeyListener est une méthode de JComponent), donc j'ai fait descendre Main de JPanel

Ce qui me donne le code suivant :

package testuih2;

import java.awt.Color;
import java.awt.Dimension;
import java.awt.Point;
import java.awt.event.KeyListener;
import java.awt.event.KeyEvent;
import javax.swing.JPanel;

import testuih2.GUIHelper;
import testuih2.IDrawable;
import testuih2.JCanvas;
import testuih2.RectangleDrawable;

import testuih2.IMovableDrawable;
import testuih2.FormDrawable;
/**
*
* @author montaigne
*/
public class Main extends JPanel implements KeyListener {
//private EcouteurClavier machin = new EcouteurClavier();
/** Creates a new instance of Main */

private JCanvas jc;

private FormDrawable rect,rect2;
//EcouteurClavier clav = new EcouteurClavier(jc);

public Main () {
//String[] truc = new String[2];
//m.main(truc);
jc = new JCanvas();
System.out.print ("Test Sortie out");

jc.setBackground(Color.WHITE);
jc.setPreferredSize(new Dimension(400,200));
Dimension dim =new Dimension(40,60);
rect = new RectangleDrawable(Color.RED,new Point(10,10),dim);

//jc.addKeyListener(clav);
jc.addDrawable(rect);

this.addKeyListener(this);
GUIHelper.showOnFrame(jc,"test JCanvas");

for (int i = 1 ; i<35 ; i += 5)
{
int b;
rect.setPosition (new Point(rect.getPosition ().x+i,rect.getPosition ().y+i));

jc.repaint ();
}

}

/**
* @param args the command line arguments
*/
public static void main (String[] args) {
// TODO code application logic here


Main main = new Main();



}//main

public void keyTyped(KeyEvent e) {

System.out.print ("Event clavier trouvé");
System.out.print (e.getKeyChar ());

}

public void keyPressed(KeyEvent e) {
System.out.print ("KEY PRESSED: ");
System.out.print (e.getKeyChar ());
}

/** Handle the key released event from the text field. */
public void keyReleased(KeyEvent e) {
System.out.print ("KEY RELEASED: ");
System.out.print (e.getKeyChar ());
}
}


Qui ne marche pas :(

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Je viens aussi d'essayer de modifier

public EcouteurClavier () {

}

en

public EcouteurClavier (JCanvas j) {
j.addKeyListener (this);
}

Ca compile mais ça donne rien.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Marche pas :(

Je suis allé voir la doc sur le addKeyListener, et je me suis rendu compte qu'il prenait un KeyListener l en argument.

J'ai donc repris mon objet ecouteurclavier

public class EcouteurClavier implements KeyListener{

/** Creates a new instance of EcouteurClavier */
public EcouteurClavier () {
}

public void keyTyped(KeyEvent e) {

System.out.print ("Event clavier trouvé");
System.out.print (e.getKeyChar ());

}

public void keyPressed(KeyEvent e) {
System.out.print ("KEY PRESSED: ");
System.out.print (e.getKeyChar ());
}

/** Handle the key released event from the text field. */
public void keyReleased(KeyEvent e) {
System.out.print ("KEY RELEASED: ");
System.out.print (e.getKeyChar ());
}
}

Je l'ai ensuite déclaré dans main

EcouteurClavier clav = new EcouteurClavier();
et mis jc.addKeyListener(clav);

Bam, même erreur :
Compiling 1 source file to
/home/montaigne/Developpement/Java/TestUIH2/src/testuih2/Main.java:52: non-static variable clav cannot be referenced from a static context
jc.addKeyListener(clav);
1 error

je remet donc static devant
static EcouteurClavier clav = new EcouteurClavier();

Ca compile mais ça donne rien.

Et moi qui doit présenter àça à un oral dans deux jours...

Merci pour tout quand même :) !

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

J'ai une erreur :

/home/montaigne/Developpement/Java/TestUIH2/src/testuih2/Main.java:47: non-static variable this cannot be referenced from a static context
jc.addKeyListener(this);
1 error

Là je vois pas, faut que je fasse une classe à part ?

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Je vais me faire moinsser mais tant pis...

Je pense que Hurd est un OS conceptuellement très interessant sur plein de points, notamment la fin du noyau monolithique qui permet de modulariser a peu près tout et n'importe quoi.

La gestion des droits d'utilisateurs par exemple est très interessante, en ce qu'elle permet de se dépatouiller de n'importe quel situation en permettant de changer n'importes quels droits d'un processus.

Je ne liste pas les avancées conceptuels de Hurd, vous les connaissez mieux que moi.


Néanmoins, et pour rejoindre le titre provoquant que j'ai choisi, je pense AMHA que le Hurd a pour gros défaut d'être écrit en C.

Le C était un langage vraiment génial pour l'époque et l'est encore aujourd'hui. Mais son approche trop bas niveau, la nécessité de gérer les pointeurs, bref de tout faire à la main, implique que tous projet d'une certaine envergure atteint très vite ses limites et que l'on tombe très vite sur des bugs classique, stupide de surcroit.

Windows en est un bon exemple, et l'étude de ses sources (celle de Windows 2000 qui circulèrent sur le net) achève la preuve (ie. On se trouve devant un code très bien écrit, très bien commenté, où l'on se rend compte que c'est la complexité intrinsèque du projet qui est le problème majeur)

Je crois que les recherches récentes sur les compilateurs, et en particulier
http://smarteiffel.loria.fr/(...)
http://www.loria.fr/~zendra/publications/oopsla97.ps(...)

et surtout http://fr.wikipedia.org/wiki/Lisaac(...) (qui intègre des fonctionnalités étendues de programmation système) permettent maintenant de concevoir des systèmes d'exploitation objet écrit dans un langage de haut niveau, avec de très bonne performances.

L'absence de pointeurs dans ces langages, leurs librairies évoluées (collections, tables de hashages, types chaîne évolué, etc...), le multi héritage, etc... permettent de faciliter le développement et la maintenance.

Bref, Hurd bien que très intéressant et plus moderne que les OS installés est déjà dépassé.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

C'est ce que les adultes autour d'eux ont pensés, et pour ceux qui faisaient partis de l'encadrement, leur ont expliqué.

Mais que veux-tu, à 20 ans maintenant certains ont un age mentale de 15...

Tu as beaucoup de développeurs comme ça. Ils font leur 35 h, ils se satisfassent de VB ou Windev, et ils ne veulent pas aller plus loin.

Le pire c'est que par leur nombre, ils sont une force économique de poids, on doit s'adapter à eux. Bien que je pense que fasse à la concurrence cette espèce devra disparaître..

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Je suis déjà tombé sur du code en Caml de 3 lignes en passant 10 minutes à comprendre.

Une fois compris, j'ai effectivement réalisé que cela prendreait 10 fois plus de code en langage impératif classique. Mais je pense que j'aurai compris avant.

Après c'est jutse une question d'habitudes

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Voilà, tu vis avec gens qui savent ce qu'est un compilateur. Mes camarades ne savaient pas ce que c'est (à part quelques uns heureusement).

Tout ce qu'il veulent savoir, c'est sur quel bouton cliquer....

Je pense que 50 % des devs sont à ce niveau, et sachant que les jeunes de 20 ans qu'on forme maintenant sont des "enfants de win95" ils n'ont jamais été confronté à un pc bien frustre, où il fallait tapper en basic, ou en ligne de commande.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Cependant, je doute qu'il soit vraiment plus facile d'apprendre les pointeurs en C.

C'est marrant tu met exactement le doigt sur un autre problème ;-)

Nous avons eu un projet C à rendre, le prof nous a demandé, en 3 semaines, d'écrire un mini interpréteur basic.

Sur 15 élèves de la promo (bts en alternance), seul 4 l'ont rendus. Les autres ont protestés, arguant que c'était "trop difficile, on ne comprend rien".

Je pense qu'un Caml habillé d'un bon environnement de développement avec la possibilité de le coupler avec pas mal de technos existante serait interessant. Il serait interessant que cet environnement de dev soit multi-langage de sorte à utilser caml sur des choses vraiment interessantes (traitement de données) et de laisser la tuyauterie technique (iUH) pour des langages plus conventionnels.
Après c'est une question de goût.

Un visual caml, j'acheterais.
Mais j'utilise caml quand je peux. En fait j'attend de récupérer le bouquin de Weiss et Leroy dont une nouvelle édition va peut être sortir afin de m'y mettre une seconde et dernière fois pour toute :)

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

C'est vrai...
... Mais on peut difficilement remplacer un développeur chef de projet qui, au contact de l'entreprise cliente, peut analyser complètement et avec compétence les besoins, l'organisation, le métier de l'entreprise.

Pour moi un Indien fera surtout de l'écriture de composants.

Qui serviront aux troufions pour écrire leur logiciels.
Ou alors ils nous feront le codage de la fonction toto...

Ya donc des chance que ça se complémente à peu près

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Je crois que tu vie dans un monde d'universitaires et/ou d'ingénieurs.

Je suis en train de terminer un BTS (honte à moi, oui), et j'ai eu autour de moi des élèves de niveau BTS pendant deux ans. Je peux te dire qu'ils ne seront jamais capable, à moins d'un miracle, de comprendre Ocaml. Enfin si, ils seraient "cérébralement "capables, mais ils sont incapable de faire l'effort, ça les interessera jamais.

Ce sont des gens qui ont du mal à maîtriser le concept de fonction, au niveau théorique. Ils ont beaucoup de mal à appréhender la programmation objet.
Ils ont déjà beaucoup de mal en algorithmique. C'est le seul point que leur expérience professionnelle améliorera.

La récursivité, c'est beaucoup trop difficile pour eux, ça les décourage.

Je n'ai pas cotoyé des gens stupide, loin de là, mais ils ne sont absolument pas curieux du tout.
Donc il feront du VB.net et des trucs de ce genre, ils vont mettre des années à comprendre l'objet.

Un bon langage pour eux, c'est VB6 et windev, voire Delphi pour l'élite (ya des pointeurs en delphi attention, et puis c'est objet Delphi !!)
Evidemment, Linux ils ne veulent pas en entendre parler. La ligne de commande leur fait peur et ça les obligerai à comprendre le système.

Mais déjà leur faire un avaler un truc du genre

let rec fact = function n -> if n=0 then 1 else n*fact(n-1);;

désolé, mais j'y crois pas.

Pour te donner une idée du niveau, ils ont mis deux jours à comprendre comment programmer une pile avec des pointeurs, dans un langage algorithmique style Pascal en français.
Deux jours plein, deux jours à 7 heures de cours par jour (!!!).
En deuxième année qui plus est, donc avec 1 ans de programmation derrière eux...

Des gens comme ça, il y en a plein, je ne suis pas certain que le développement soit leur point fort, ils sont surement plus compétent dans d'autres domaines.

Mais je répète ma conviction : Ocaml est réservé à un élite.

Pour le reste, je suis totalement d'accord avec toi : Des gens ouvert et capable d'appréhender l'embryon de théorie absolument nécessaire et motivé pour s'y mettre peuvent très bien le faire.

Mais quand tu sais qu'il y a plein d'entreprises qui choississent de ne pas utiliser J2EE parce que leur dev ne maîtrisent pas l'objet, tu te demande qui il reste poua apprendre un tel langage.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Comme je l'ai dit plus haut, les indéniables avantages de Ocaml sont ce qu'ils sont, mais moins 10 % des développeurs sont capable de le maitriser, alors que des langages comme Lisaac ou Eiffel, tu en as 30 % peut être.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Tu as ça : http://isaacos.loria.fr/language/tools.pdf(...)

Mais la publi qui répond à oopsla97 est en préparation.

Oui ça date, et personne dans l'industrie, ne semble l'utiliser

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker