Samos a écrit 26 commentaires

Salut l'ami !

Oui et non :) Il y a également teo tout court qui tourne sous Linux mais avec certaines limitations (pas de support joystick, pas de vrai plein écran, mapping clavier en dur, …).

DCMOTO marche ceci dit très bien avec Wine. Il y également un DC* libre qui est censé marcher sous Linux mais je ne l'ai pas testé.

Exact… Si quelqu'un peut modifier, je n'ai pas l'option (et je n'ai pas compris comment j'ai réussi un lien et raté l'autre…).

T'inquiète, ils feront bien attention de repasser par le même trou.

En réalité, c'est un peu plus compliqué que ça ;). La société soonweb d'aujourd'hui, même si elle a le même nom, n'a rien à voir avec celle de notre regretté Gilbert.

Voilà l'original, avant refonte, et après refonte.

Dommage qu'il n'y ai pas de fonction éditer (et/ou que je ne me sois pas relu). Il fallait lire le second dialogue comme:
- « Je comprends pas, j'ai un serveur FTP chez moi, et quand je suis a la maison ça marche très bien, mais d'ici j'arrive pas a l'avoir. »
- « Attends, on va essayer. C'est quoi l'adresse » ?
-« Heuu, 192.168... »

C'est vrai que cela peut paraître un peu déroutant pour les « outsiders ». Je vais essayer de résumer en quelques lignes :
Gilbert Stoyanov, c'est l'histoire d'un enfant à qui sa mère fait croire qu'il est un surdoué depuis qu'il est tout petit alors qu'il doit avoir un QI somme toute normal. C'est un professionnel du « dump » de certifications Microsoft. Les relations sociales ne sont pas son sujet de prédilection. Une fois ceci passé à la moulinette de M6, cela donne le stéréotype du petit génie incompris.

Le seul hic, c'est que ses compétences techniques sont loin d'être à la hauteur. Il a du tomber de très haut lorsque sa mère l'a fait rentrer successivement dans deux écoles. Ecoles dans lesquelles il n'est pas resté longtemps, tranches de vie :

Dans sa première école, en cours de maths :
-  «Madame, ce truc au tableau, c'est un moins ou un underscore ? »

Dans sa seconde école, monsieur Stoyanov ne va pas en cours de réseau, vu qu'il est déjà certifié MS et "qu'il y a du réseau dedans". Un jour, Gilbert a un problème et demande de l'aide à ses condisciples :
- « Je comprends pas, j'ai un serveur FTP chez moi, et quand je suis à la maison ça marche très bien, mais d'ici (depuis le réseau de l'école) j'arrive pas à y accéder. »
-« Heuu, 192.168... »

Le canular, c'est son statut de génie de l'informatique, et c'est drôle, enfin plutôt c'était drôle, parce que... je pense que tu as compris pourquoi.

Glibert, était vraiment une légende, et pas que sur le Web. Il est également passé par quelques écoles célèbres de la place parisienne. Je pensais qu'il aurait quand même fini par faire quelque chose de sa vie malgré sa mère.

Bon vent Gilbert !

Mais voyons, c'est Linuxfr ici ! Toi aussi, fais saigner ton coeur sur le traitement injuste subit par les pauvres terroristes. Quoi que le terme terroriste est peut être un peu fort, et risquerait de choquer la sensibilité de certains, disons plutôt "militants alterculturels".

Laisse tomber ;)

Ce dont j'ai l'impression, c'est qu'il s'agit d'une implémentation des API userland (comme CocoaTouch & co), mais sûrement pas d'un OS complet. Le restant des services fournis par l'OS étant fournis par MacOS. J'ai regardé dans la doc, et je n'ai rien trouvé qui infirme ça. Est-ce que tu as un lien qui indique clairement que le simulateur est une solution de virtualisation ? Jusque là, tout ce que j'ai pu trouver comme informations techniques me fait penser à un Wine pour iOS, c'est a dire une implémentation de l'API attendue par l'application.

D'autre part, si Apple avait crée une solution de virtualisation d'iDevice (pourquoi pas), cette solution serait plus une solution d'émulation et executerai directement l'iOS pour arm. Hors si je fais un file sur une application iOS compilée pour le simulateur, j'obtiens "Mach-O executable i386". J'ai franchement du mal a voir la logique derrière le fait de créer une solution de virtualisation x86 (donc très proche de Qemu/Bochs) pour exécuter une version spéciale de l'iOS compilée pour une architecture x86. Cela représente énormément plus de travail que d'implémenter les API spécifiques de iOS sur MacOS, la base de l'OS étant peu ou prou la même.

Dans ce cas, ce n'est pas vraiment iOS, ça ne peut pas booter. C'est plus proche de Wine que d'un OS.

Sinon, ios est gratuit, tu le telcharges gratos sur internet, de meme que sa version x86, disponible sans acheter d'iphone (sisi, elle existe, cherche un peu).

Est-ce que tu parles du simulateur fourni avec Xcode et le SDK iOS ? Parce que sinon, j'ai cherché (requête google +iOS +x86 sur google.com et google.fr), et je n'ai rien trouvé de concluant. Est-ce que tu peux détailler un tout petit peu plus ?

Effectivement. Sauf dans l'exemple cité, où la "console" en question n'est rien d'autre qu'un PC recarrossé. Certes avec un GPU NVidia custom, mais rien de transcendantal.

Il y a juste quelque chose qui me choque dans ce cette news: On parle d'une distribution orientée jeux, qui a pour but de faire une console de jeu avec du matériel un peu ancien. Hors, il la configuration minimale pour jouer à des jeux en 3D annoncée est:

un CPU >= 1Ghz et + de 128Mb de RAM

Ok, ce n'est pas explicitement mentionné comme minimal, mais l'auteur ne demande de lever un bug que dans ce cas, ce qui sous entend fortement que ne pas pouvoir faire tourner un jeu comme Tuxracer en dessous de cette config serait normal.

Cela me semble quand même beaucoup. Surtout pour une console, et d'autant plus si l'on regarde la qualité des jeux sous Linux. Pour mémoire, la Xbox première génération -Oui, c'est Microsoft, on en pensera ce que l'on voudra, mais personnellement, j'adore cette machine- Est équipée d'un processeur Celeron (!) à 733 de de seulement 64 MB de Ram -partagée entre le CPU et le GPU(!)- et d'une carte graphique que l'on peut comparer à une GForce 3/4. En réalité, c'est un chip NV2 modifié. Quoi qu'il en soit, aujourd'hui, ce genre de configuration dans un boîtier PC serait qualifié de ridicule par tout un chacun et réservé à un usage serveur. Pourtant, sur la mienne, je peux jouer à des jeux assez complexes, comme GTA San Andreas, sans ralentissement particulier.

A ma connaissance, les jeux sous Linux en sont à peu près à cette génération. Alors où est le problème ? Le kernel Linux est-il si lourd que ça en fin de compte ? Les devs de jeux qui targettent la plateforme Linux ne sont pas capable de rivaliser avec les studios pros en terme d'optimisation ? J'ai néanmoins la nette impression qu'une machine comparable à la Xbox devrait être capable de faire tourner la plupart des jeux disponibles pour Linux/x86; fussent-ils en « 3D ».

s/peut/peu/

Pour le moment, il n'y a absolument pas d'API de persistance intégrée. A ma connaissance, il existe Catalina, qui est une API de persistance pour GObject. Par contre je n'ai pas vraiment testé, et le peut de code d'exemple que j'ai regardé ne m'a pas spécialement enthousiasmé.

Depuis le début, Blitzen à été pensé comme un serveur d'application complet, avec une API de persistance. Je n'en ai jamais parlé jusque là, car je n'ai pas envie de créer une attente que je ne pourrai pas satisfaire. Blitzen est actuellement un one-man project et il ne grandira peut être jamais assez pour supporter tout ce que j'ai envie d'y implémenter. J'avance donc petit à petit, suivant le temps libre que je peux y consacrer. J'ai toujours vraiment envie d'écrire un moteur de persistance pour Blitzen, en C/GObject, et j'ai même commencé un draft. Mais ça ne sera pas disponible en release avant assez longtemps. Si cela sort un jour, ça s'appellera "dasher". C'est vraiment tout ce que je peux en dire pour le moment.

Je ne fréquente pas du tout la mailling-list de Vala, c'est la première fois que je poste dessus. En effet, j'ai préféré attendre d'avoir un feature set minimal avant de parler de Blitzen. Maintenant que j'ai presque fini de jeter les bases que le projet commence à ressembler à quelque chose, j'ai décidé qu'il était temps d'en parler aux devs de Vala themselves et également aux différentes personnes qui s'y intéressent, d'où le post sur la mailling list.

En ce qui concerne Gtkaml, je ne connaissais absolument pas. Je viens de regarder ce que c'est, et ça ne me semble pas convenir à ce que je souhaite mettre en place. Gtkaml mélange le code et l'UI. Ce n'est pas ce que je souhaite faire. D'autre part, c'est Vala-only alors que GtkBuilder est intégré à Gtk et utilisable dans tous les langages qui ont un binding Gtk. Gtkaml est un générateur de Vala à partir d'une syntaxe XML. Très franchement, mis à part pour du prototypage rapide, je trouve que c'est une très mauvaise idée. En plus, il faut régler le parseur avec un fichier ini, pour lui apprendre quelles sont les méthodes à utiliser. C'est à des années lumières de ce que je veux faire.

StkBuilder est beaucoup plus proche de GtkBuilder: C'est uniquement un moyen de décrire un interface. Ils différent seulement par quelques éléments de syntaxe, mais l'esprit est le même. La principale différence entre StkBuilder et GtkBuilder est que StkBuilder vise a automatiser le maximum de choses, et surtout construire un interface qui s'appuie sur une classe, en plaçant des pointeurs sur les objets construits dans les propriétés de cette classe, alors que GtkBuilder donne un pointeur sur une interface abstraite qu'il faut interroger pour récupérer un pointeur sur l'objet avec lequel on souhaite travailler.

D'autre part, StkBuilder n'est pas vraiment lié au XML. StkBuilder est coupé en deux: Une partie qui construit une représentation abstraite de l'interface et une autre partie qui utilise cette représentation abstraite pour instancier les objets à la demande. Seule la première partie "voit" le XML. Si passer à JSON ou tout autre chose intéressait quelqu'un, il lui serait tout à fait possible d'écrire un parseur JSON qui traduise le JSON dans la représentation abstraite utilisée par StkBuilder. Ceci dit, ce n'est vraiment pas une priorité ;)

Il y a une erreur dans le XML, il manque la fin: Les deux tags object et class ne sont pas refermés. Il fallait lire:


<class name="HelloView" parent-class="StkView" title="Hello View">
    <object class="StkFlowContainer" backed-on="flow" />
        <object class="StkLabel" text="Enter your name: " backed-on="txtLbl" />
        <object class="StkEntry" backed-on="nameEntry" />
        <object class="StkLabel" backed-on="welcomeLbl" />
        <object class="StkButton" backed-on="okBtn" label="Ok" navigate="false" mix-replace="false" />
    </object>
</class>


J'ai un forfait téléphonique qui arrive bientôt à expiration, et je ne vais sans doute pas repartir pour 1 an avec eux. J'ai donc fait passer mon forfait actuel vers un mobicarte (sera activé dans 1 mois environs, à la fin de mon contrat), si bien que je n'aurais plus d'engagement et je pourrais aller chez qui je veux ensuite, cela vous semble la meilleure option ou il y a un truc que j'aurais manqué ?

Normalement, tu peux garder ton forfait et ne rien faire de particulier : Ton contrat se s'achève pas lors de la fin de l'engagement. il te suffit de ne pas te ré-engager lorsqu'un gentil "conseiller" téléphonique te le proposera sous couvert de t'offrir une heure en plus ou autre. Tu gardera ainsi ton forfait(normalement plus avantageux que les tarifs prépayés), et tu sera libre de tout engagement. Tu pourra donc changer d'opérateur dès que bon te semblera.

Si tu parles de www.midgard-project.org, je ne connaissais pas du tout.

A ce que j'ai pu lire sur leur site web, il s'agit à la base d'un framework de persistance.

Il y a également un système de CMS en PHP nommé midCOM, mais je n'ai pas reussi à accéder à l'API reference donc je ne peux pas vraiment comparer son approche avec celle de Blitzen.

Corrigé aussi, merci.

Il y a plusieurs raisons à cela:

Premièrement, Blitzen a été conçu justement pour exécuter des applications natives et non pas des applications écrites en langage de script.
Deuxièmement, même si je n'ai rien contre cette idée, la mise en oeuvre pratique risque d'être moins triviale qu'il n'y paraît : Une fois compilées, les applications se présentent sous la forme de 'shared objects' (.so) qui sont chargés dynamiquement par Blitzen via un point d'entrée prédéfini qui est chargé de créer une instance d'un type dérivé de l'objet représentant une application( Exactement comme une application charge un plugin ).
Aussi pour être capable d'exécuter une application en langage de script il faudrai embarquer l'interpréteur du langage en question et sûrement écrire encore un peu de 'glue code'. Comme on le voit, même si cela ne semble pas vraiment 'impossible', c'est en tout cas un peu complexe pour ce stade du projet.

Cependant, même si ça ne m'intéresse pas de le faire pour l'instant, les contributions sont acceptés ;)

C'est corrigé, merci.

En effet, j'avais posté un journal pour parler de Blitzen l'année dernière.

Il n'y a pas vraiment d'activité sur sourceforge car je n'ai rien uploadé depuis un sacré bout de temps, mais le projet n'est pas du tout abandonné :
C'est un serveur d'applications en C/GObject qui peut exécuter des applications( sites webs ) elles-mêmes codées soit directement en C, soit en Vala(mais pas en C++).

Ces derniers mois je n'ai vraiment pas eu beaucoup de temps à lui consacrer, et durant ce peu de temps, j'ai travaillé sur un moteur de génération de documentation qui soit capable de générer d'un seul coup la doc pour l'API Plain-C et la doc pour l'API Vala.
En effet, actuellement, la documentation de référence est générée directement par gtk-doc( pour la partie Plain C), tandis que la doc Vala est «générée» à la main en éditant une copie de la doc Plain C ce qui est évidement loin d'être viable.
Pour résoudre ce problème, j'ai travaillé sur une petite «moulinette» capable de générer du docbook à la fois pour l'API Plain C comme le fait gtk-doc mais aussi pour l'API Vala.
Cette moulinette est fonctionne presque bien depuis aujourd'hui. D'ailleurs, comme j'ai quand même pu avancer un tout petit peu sur le code, je ne suis plus très loin de la première milestone qui consiste à avoir tous les widgets HTML de base implémentés, et je prévois de sortir une nouvelle pré-version avant la fin du mois.

Tout à fait, le COPYING est bon, et comme précisé dans le journal, Blitzen est en LGPL v2.

Ça me ferai très plaisir de voir Blitzen tourner sur autre chose que du Linux, cependant même si j'ai utilisé l'API de la glib au maximum et que je ne me souvienne pas avoir fait de Linuxismes, je n'ai jamais testé sur autre chose. En tout cas, n'hésite pas à remonter les bugs et/ou soucis de compilation soit à bugs@blitzen.org soit sur le tracker sourceforge si je l'ai mis en place d'ici là.( oui, tout est un peu frais là... )