Mildred a écrit 2248 commentaires

Path.li contrairement a ce que son nom indique n'est pas un fichier source Lisaac. Il est interprété à chaque fois.
Donc pas besoin de recompiler le compilateur :)

Mais un nouveau système pour la compilation est en route...

Sauf qu'en D je ne pense pas que tu puisse directement inclure des instructions assembleur, si ? J'ai un peu programmé avec ce langage et ça ressemblait un peu à un Java sans machine virtuelle et plus proche du C.

Lisaac, tu peux directement inclure du code C (via les backquotes ``), et tu maîtrise vraiment le résultat en C obtenu. Et si ton compilateur C permet d'écrire de l'assembleur, tu peux le faire directement depuis Lisaac

Comme le langage est très extensible, tu peux utiliser une syntaxe très proche du C.

par exemple un test peut très bien s'écrire

if (condition) then {...} else {...};

Ou encore tu peux faire un appel de fonction (grâce aux paramètres multiples de la version 0.2) ainsi:

mafonction(param, param);

On dirait presque du C. Après bien sûr de base tu ne peux pas le faire car les fonctions de la lib sont écrites autrement (avec des mots-clefs) ... Mais Lisaac a cette possibilité.

Enfin, s'approcher de cette syntaxe n'est pas le but de Lisaac. Mais c'est pour dire que Lisaac n'a pas une syntaxe si étrange que ça. Je me rappelle le jour ou j'ai commencé à programmer en Lisaac, avant je ne comprenant rien à la syntaxe, mais moins d'une heure après, j'avais tout compris.

En plus benoît m'a dit que la syntaxe de Lisaac a été étudiée pour être proche du C et être facilement compréhensible par n'importe qui.

Après, le problème, c'est que sur les court exemples, on a le mot clef Section qui peut perturber, mais c'est comme le public: du C++. le vrai code Lisaac est très joli.

En fait, du code Lisaac, ce n'est pas forcément moche ... C'est même joli si on a la bonne coloration syntaxique.

Tu veux voir du code Lisaac ? http://codebrowse.launchpad.net/~mildred/liworld/trunk/files(...) (dans le répertoire src)

Sinon, le code Lisaac ressemble fortement à du C, et est du même coup facile à apréhender. Il semblerait que Benoît l'ait étudiée pour. Par contre, le truc qui peut être déroutant, c'est que tu n'a ni mot clef break, ni continue. Du coup du dois te débrouiller autrement. C'est faisable facilement mais ça force a réfléchir souvent un peu plus.

Une question: Lisaac optimise-t-il les boucles du genre :

( + bool :BOOLEAN;
  ...
  1.to 20 do { i:INTEGER;
    bool.if {
      // Quelque chose
    }
  };
)

Ça permet de remplacer les Break et Continues facilement je trouve.

PS: à quand la possibilité de poster facilement du code sur DLFP ? Par exemple pouvoir utiliser la balise <p> ou <br/>

Il y a GTK, QT ou WxWidgets dans la lib Eiffel ?
Parce que pour le moment, je me demande comment coder une application graphique en Lisaac :( ... J'ai pensé porter GNUstep mais ça n'a pas l'air facile.

Ce qui serait bien je pense, c'est faie un binding Gobjects <-> Lisaac

Il serait possible éventuellement de faire d'autres backend pour Lisaac, c'est à dire qu'on pourrait cmpiler en C, mais on peut aussi très bien imaginer de compiler pour la JVM ou encore Parrot...

Seulement à l'heure actuelle, les structures C sont un peu partout dans le code du compilateur. Si on veut ajouter un langage ca risque d'être difficile.

Il n'y a pas vraiment de builtin en Lisaac, tout est pris de la lib standard.

mais c'est vrai que si tu fait un string du compilateur, tu va trouver des constructions C qui sont utilisés pour générer le code. Mais je ne pense pas que ce soit problématique.

Non, il n'y a pas d'espaces de noms. Actuellement, tous les prototypes du compilateur (l'équivalent des classes) doivent avoir un nom différent.

Je ravaille sur un patch du compilateur afin de pouvoir séparer la compilation en projets. Un projet contient des prototypes publics accessibles par les autres projets, et des prototypes privés réservés à lui seul.

Le gros avantage c'est de permettre d'avoir plusieurs prototypes de même nom dans la compilation. Et permet donc un cloisonnement minimal. Cela permet de créer des bibliothèques sans se soucier des noms des prototypes publics par exemple.

Par contre, il n'y a pas de possibilité de préfixer les noms des prototypes par le nom du projet (il faudrait changer le langage, je change juste le compilateur), et il n'y a pas de possibilité de faire des imports partiels ou de renommer des prototypes. Si le besoin est vraiment grand, c'est toujours possible de faire un import partiel/renommage en important un projet intermédiaire qui exporte juste les bons prototypes.

C'est vrai ... en fait j'utilise des fonctionnalités apache (négociation de contenu) qui semblent fragiles ... Et qui semblent ne plus marcher sur les serveurs de free :(
Domage

Non, ce n'est pas du tout un problème de DNS, c'est une redirection de ports:

$ nc 1.2.3.4 119
200 Bienvenue sur news.orange.fr, le serveur de news est disponible. - newsmaster@orange.fr (posting ok)

Et un nmap sur n'importe quelle Ip me donne invariablement les ports 25 et 119 ouverts, même si ce n'est pas le cas (car ce sont des IP que je connais).

$ nmap -P0 louve.dyndns.org
Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-23 23:33 CEST
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
Interesting ports on voi38-1-82-233-96-31.fbx.proxad.net (82.233.96.31):
Not shown: 1695 filtered ports
PORT STATE SERVICE
25/tcp open smtp
119/tcp open nntp

Nmap finished: 1 IP address (1 host up) scanned in 2956.068 seconds

Je n'aurais jamais du dire que c'était ArchLinux !

Donc en gros, pour être claire : J'ai modifié complètement le système de boot super rapide de ArchLinux pour le remplacer par upstart, on ne peux donc rien conclure sur la vitesse de boot de ArchLinux !

Et la suite : Sur un autre ordinateur (desktop), ArchLinux démarre sensiblement plus rapidement que Ubuntu ... C'est visible.

Certes une fois que j'ai rajouté un serveur http, un serveur jabber, et diverses autres joyeusetés, c'est moins sensible ... mais à nu, ça démarrait vite.

Je ne cherche pas vraiment à faire un test objectif, ni a chercher des conseils...

Pour ce que tu dis, c'est vrai. Je n'utilise pas du tout Mac OS X donc forcément, c'est une configuration par défaut, d'un OS tout neuf. Alors que j'ai déjà bidouillé énormément ArchLinux, et même remplacé son système d'init.

Par contre je maintiens que l'apparition du curseur de la souris est une bonne mesure... Du moins pour Linux or Mac OS. C'est à partir de ce moment que tu peux faire quelque chose.

Je me rappelle d'un article que j'avais du lire qui disait qu'un utilisateur préférait une application qui démarre lentement mais qui affiche directement un retour visuel (splash screen) qu'une application qui démarrait plus vite sans retour visuel. Pour le démarrage de l'OS, c'est un peu pareil.

Une fois l'OS démarré, en général je ne cherche pas à faire quelque chose directement. Je prend un peu de temps pour savoir ce que je vais faire ... Donc finalement ça ne me dérange pas que tous les services ne soient pas encore là.

Non, rien de particulier ... Je remarque juste que l'indicateur de remplissage de ma RAM et de ma swap augmentent toujours... Mais je ne remarque pas non plus vraiment de baisses de performances.

C'est peut être du a mon habitude de laisser 15 fenêtres epiphany ouvertes avec au moins 15 onglets dans chacune...

Ça a l'air pas mal, et comme c'est simple, ça me tente.

Upstart, sur le papier c'est bien. Sauf qu'en pratique il manque plein de choses. Les conditions pour lancer un service sont insuffisantes (par exemple il est possible de lancer un service si on a reçu l'évennement A ou B, mais pas si on a reçu A et B). Donc c'est gênant. Un service ne peux dépendre que d'un autre service, pas de deux à la fois.

Ensuite, le design est joli, mais cf les derniers messages de la mailing liste, ça pose des petits problèmes. Et si on veut faire quelque chose dans l'esprit d'upstart, il faudrait écrire plein de scripts udev ou autre pour transformer les evennements udev en evennements upstart.

Donc upstart c'est bien mais c'est pas encore ça. Sans compter qu'il est facile de le faire entrer dans une boucle infinie. Par exemple j'ai eu un service qui dépendant pour être démarré de lui même. Du coup j'ai un processeur qui tourne comme un fou et la seule solution, c'est de redémarrer.

Donc quelque chose de simple ça me tente. Seulement je crains un peu que les scripts bash plombent les performances du système d'init. Je me dis que si on base tout sur un langage de script très léger comme Lua [http://lua.org], ça peut améliorer les performances. Donc du coup j'ai commencé à écrire un truc.

L'avantage de lua, c'est qu'il est possible d'avoir plusieurs threads. Et ces threads sont gérés par la machine virtuelle et ne sont pas ordonnancés. C'est le programmeur qui va définir quand le thread va se stopper en faveur d'un autre. Donc du coup pas mal de problèmes de concurrence sont résolus (car il n'y a pas vraimment de concurrence).

Bon, je vais me coucher, bonne nuit :)

Je précise quand même que j'utilise upstart pour le démarrage et que j'ai l'impression que le driver de ma carte graphique est en cause pour le démarrage lent de xorg.

Avec le système de boot archlinux, c'est fort possible que ça aille plus vite. Seulement je préfère upstart car il me permet de configurer tout comme je le souhaite. Par exemple j'active tty2 au tout début, du coup c'est très pratique.

Non, justement, leur modèle de développement est meilleur. Comme ils n'intègrent pas les applications usuelles, on doit les chercher ailleurs. Et du coup on peut facilement avoir les dernières versions. Et l'utilisateur est content.

Après je ne dis pas qu'il n'y a pas d'autres problèmes ...

En gros, ce que tu me dis, c'est que debian ne convient pas pour mon desktop ... A vrai dire je le savais déjà, c'est pour ça que je l'ai rapidement quittée.

Parce que mon desktop, lui, il veut une distribution avec des logiciels récents (comprendre lorsque firefox sort une nouvelle version, je veux le voir au plus tard 2 jours après dans les dépôts). Et il veut aussi un truc où je n'ai pas envie de m'attendre à des anomalies de la debian unstable.

Après on se demande pourquoi ubuntu a eu tant de succès ... Pourtant ce n'est pas encore tout à fait ça. Mais au moins les versions stables sont un peu plus rapprochées dans le temps.

Et avoir une distribution stable en utilisant les derniers logiciels stables, ce n'est pas contradictoire. A ton avos, lorsque mozilla sort son nouveau firefox, il a quand même été bien testé avant. Si ils disent que c'est stable, c'est parce que ça l'est.

C'est pour ça que le développeur d'un soft crée des versions alpha, beta, ou autre pour permettre aux gens motivés de tester le soft. Et quand il le considère stable, il lui donne un numéro de version stable.

A ce moment là je ne vois pas l'interêt pour une distribution de faire encore attendre le logiciel avant de l'intégrer dans son système de paquets. Puisque le logiciel est reconnu stable par son développeur (qui n'aura sans doute pas oublié de le tester et de le faire tester par d'autres personnes).

Après, pour des systèmes comme RHEL, cela va de soi que les nouvelles versions des softs ne peuvent pas être intégrées. Mais pour une distribution faite pour être utilisée tous les jours, c'est en généal souhaitable de la mettre à jour.

Ça m'intéresse ce que tu dis à propos de Xorg ... Tu veux dire que le kernel et Xorg seront intégrés ? J'ai lu un jour un article qui disait que c'était ce qu'il fallait faire mais je ne savais pas que c'était en route.

Tu as des liens ?

Pour le suspend, c'est très pratique mais:
- le suspend to disk ne marche pas chez moi, il faut dire que je n'ai pas cherché à le faire fonctionner. Mais avec un clavier qui marche une fois sur vingt sur le prompt grub (bug du BIOS) ...
- et pour le suspend to ram, c'est bien mais ça continue de consommer un peu. Et surtout après quelques jours sans arrêter l'ordinateur tu finis par avoir une RAM pleine, et une SWAP pas loin des 100%. Après un redémarrage ça va un peu mieux.

Le mieux c'est ArchLinux, un système de packages simple où on peut facilement créer de nouveaux packages, mais toujours des dépôts de binaires pour éviter les recompilations.

Pour ce qui est de l'utilisation directe de Python dans les pages XUL/HTML, il y avait un travail en cours, mais je crois que ce n'est pas terminé (pas sûr que ce soit très actif en ce moment d'ailleurs). Il me semble que c'est prévu toutefois dans Mozilla 2.

Il faudrait d'about être capable de créer une sandbox en python ... d'ici que ma page web me fasse un open("/home/toto/document-important") ...

L'avantage, c'est pour moi, pas pour lui (en tout cas c'est moins évident).

Si je veux faire un papier particulier, je n'ai pas besoin de:
- savoir programmer en C++ (langage que je déteste)
- avoir tout l'environnement de dev qui peut être très lourd (surtout qi je n'aime pas les autotools)
- m'embêter à devoir débugger le truc avec gdb car j'ai un segfault obscur

et sûrement d'autres raisons. Du coup je peux faire mon papier spéciel en 2 minutes.

J'avais loupé ce thread mais puisque on en parle sur la ml Lisaac ...

Pour moi les langages de scripts sont une absolue nécessité car ils permettent de limiter les droits associés à un script. Enfin, pas tous les langages de scripts. Certains comme python n'en sont pas capable (du moins si on ne modifie pas le langage) alors que c'est une des fonctionnalités clefs de lua.

D'autre part, la recompilation en langage machine est nécessaire pour les plugins, alors que pour les langages de scripts n'en ont pas besoin.

Les problèmes des plugins, c'est:
- qu'il n'y a aucun moyen de limiter leurs droits au niveau utilisateur
- pas d'universalité du plugin sur différentes architectures materielles.

Donc par exemple, si je souhaite faire un logiciel qui chercheratout seul des plugins sur internet, c'est foutu si je n'utilise pas un langage de script. Car:
- avec du code machinne le plugin peut faire n'importe quoi
- à part qi j'embarque un compilateur, le plugin doit être un fichier objet ne fonctionnant que sur une architecture définie.

La solution, c'est la machinne virtuelle, style java ou lua. Pour moi, peu importe si c'est compilé comme java ou moins compilé comme lua, cela rempli les mêmes rôles. Je préfère juste lua pour sa simplicité.

C'est bête, je ne peux plus plusser... Pour quelle raison se faire la guerre entre OS libres ???