juste comme ca ...

Ma petite experience

• [^]Re: Ma petite experience

  Posté par Ontologia (page perso, ) le 20/06/2005 à 15:19. (lien). Évalué à 3.

  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.

Encore

• [^]Re: Encore

  Posté par Ontologia (page perso, ) le 20/06/2005 à 12:12. (lien). Évalué à 2.

  >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.

  • [^]Re: Encore

    Posté par RodZilla () le 20/06/2005 à 15:36. (lien). Évalué à 10.

    De toutes façons, on code 15 fois plus vite en lisaac qu'en C++
    
    C'est génial ça. Tu vas pouvoir aller coder en Pologne pour venger nos plombiers.

• [^]Re: Encore

  Posté par Obsidian () le 20/06/2005 à 12:15. (lien). Évalué à 10.

  Sans compter l'avance déjà prise par l'omnipotent MultideskOS ...

Bindings

• [^]Re: Bindings

  Posté par Ontologia (page perso, ) le 20/06/2005 à 14:50. (lien). Évalué à 2.

  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 :)

  • [^]Re: Bindings

    Posté par bobefrei () le 21/06/2005 à 09:03. (lien). Évalué à 2.

    Tu seras obligé de passer par les bindings d'OpenGL et SDL pour accéder au matériel. A moins que tu veuilles réécrire tous les drivers du monde?
    
    Je pense qu'il faut placer ta librairie à un plus haut niveau, cad proposer des fonctionnalités telles qu'un scenegraph, un moteur physique, la gestion des ressources (textures, sons, objets 3D, scripts...), du jeu en réseau,etc.
    
    A bas niveau, il ne reste qu'un domaine qui est mal couvert (par le libre en tout cas): les calculs "vectoriels" utilisant MMX, SSE et co.
    
    

    • [^]Re: Bindings

      Posté par Ontologia (page perso, ) le 21/06/2005 à 10:51. (lien). Évalué à 1.

      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.

En tout cas merci

• [^]Re: En tout cas merci

  Posté par Ontologia (page perso, ) le 20/06/2005 à 19:40. (lien). Évalué à 1.

  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 :)

Pourquoi Lisaac ?

• [^]Re: Pourquoi Lisaac ?

  Posté par Ontologia (page perso, ) le 20/06/2005 à 20:42. (lien). Évalué à 1.

  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 :(

  • [^]Re: Pourquoi Lisaac ?

    Posté par Miguel Moquillon (Jabber id, page perso, ) le 21/06/2005 à 09:12. (lien). Évalué à 2.

    Effectivement, l'aspect compilation/VM m'avait échapée :)
    
    Sinon, les langages objet à VM ne sont pas tous peu performant. En fait, il n'y en a qu'un dont les perfs sont lamentables : Java.
    Ceci est dû en partie à une différence de conception mais aussi d'approche. Dans Java, la VM est juste une machine à exécuter une application. Dans Smalltalk ou slate par exemple, la VM est plus un conteneur à objets ; en fait c'est bien une véritable machine dédiée à la gestion du cycle de vie des objets (c'est donc un véritable environnement d'exécution objet).
    
    A part ceci, effectivement je n'ai pas très bien évalué les possibilités de Lisaac. Je me suis juste amusé un peu comme ça. Il y a un petit truc qui me dérange dedans, c'est son orientation "structure des objets". Avec io ou slate, le dév est orienté plus sur les objets eux-mêmes en tant que tel que sur leur structuration sous forme de prototype ; c'est une approche plus "dynamique" (ce que sont les objets, des entités avant tout dynamique).

    • [^]Re: Pourquoi Lisaac ?

      Posté par Ontologia (page perso, ) le 22/06/2005 à 17:21. (lien). Évalué à 1.

      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 ?

      • [^]Re: Pourquoi Lisaac ?

        Posté par Miguel Moquillon (Jabber id, page perso, ) le 23/06/2005 à 09:01. (lien). Évalué à 1.

        Toutes les VM ne sont pas codées en C directement.
        Par exemple, la VM de Squeak a été codée directement en Smalltalk. Un traducteur, toujours en Smalltalk, se charge en ligne de le traduire en du code C mathématiquement correct. Ce qui signifie que la VM peut-être modifiée en directe dans l'environnement Squeak.
        
        Il y a des projets intéressant de construire un OS objet au vrai sens du terme : un environnement dans lequel vivent des objets. IsaacOS en est un et j'attend qu'il soit suffisamment avancé avant de l'essayer. Il y en a d'autre, comme Unununium qui est écrit en Python.
        
        Sinon, je suis d'accord avec toi sur le fait qu'avec une VM on ajoute juste une couche "applatie" au-dessus souvent d'un micro-noyau. C'est le cas par exemple de L4io (un OS construit avec io au-dessus de L4k)