Posté le 26/03/2014 18:58
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 140 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 18/06/2014 16:29 | #
Ce projet est-il toujours en cours ? (Je demande car actuellement tu as énormément de projet (adaptation de stdlib, une lib pour GCC, une lib de niveau de gris, un moteur 3D, ...)
Citer : Posté le 18/06/2014 16:41 | #
Oui, j'ai beaucoup de choses à faire, mais je ne le dis que lorsque je suis sûr de le faire ou que j'ai besoin d'un coup de main.
En l'occurence, ce projet continue bien sûr. J'ai adapté la structure du DOM à mon modèle pour diminuer la masse de mémoire et améliorer la vitesse de calcul. Je sais également comment implémenter la plupart des fonctions, donc pas trop de problème... en revanche, je n'ai toujours pas les formules pour l'affichage, il y a plein de trucs à gérer (les inline, les block, les inline-block, les float...).
Et en ce moment, je bosse sur un "Space Invader II" qui m'avait été demandé, donc ça ralentit le travail. Surtout, comme il n'y a pas de résultat visible, je ne mets pas le topic à jour, car ça ne me semble pas très intéressant.
Citer : Posté le 18/06/2014 16:50 | #
En l'occurence, ce projet continue bien sûr.
Ok. Bonne nouvelle
Oui, je comprends. Tu as parfaitement raison, cela ne reviendrait qu'à surcharger le topic de message qui, au final, n'aurait pas tellement d'utilité
Citer : Posté le 08/07/2014 10:27 | #
Je repasse le projet sous un compilateur gcc.
J'ai actuellement terminé le portage, je vais reprendre l'ensemble des sources de l'interpréteur HTML qui n'étaient pas vraiment optimisées.
En revanche, je ne touche plus au fondements de l'interpréteur TeX.
Ajouté le 09/07/2014 à 09:45 :
J'ai un problème avec le modèle de l'interpréteur.
Pour faire court sur votre ordinateur, le contenu de chaque balise est stocké en texte dans les données de celle-ci, c.a.d que pour le code suivant :
<p>Texte<br />Autre texte</p>
</div>
Le contenu texte de la balise de type div est "<p>Texte<br />Autre texte</p>".
Le problème, c'est que je n'ai pas du tout assez de mémoire pour faire ça. Par conséquent, le contenu de texte n'existera que pour les balises qui contiennent du texte.
Là vient un autre problème. Il faut définir les balises qui seront suivies par du texte (p, h1, h2, textarea, input, br, ...) et celles qui ne le seront pas (toutes les autres). Et là, se pose le problème des balises qui peuvent ou pas être inline.
En gros dans mon modèle, il y aura des balises définies de type block, que l'on pourra passer en inline-block, et les balises de type inline, mais il n'y aura pas moyen de passer des block en inline. Du coup, je suis confronté au problème de balises telles que img, qui sont à l'origine inline, mais qui peuvent passer en block.
Notez que si une balise est définie inline, il ne sera pas possible de la mettre en-dehors d'un conteneur de texte.
Du coup... je sais pas trop ce qu'il y a de mieux à faire.
Une idée ?
Ajouté le 10/07/2014 à 10:46 :
Le modèle que je vais utiliser pour répondre à ce problème diffère de ce que j'aurais voulu avoir, mais au moins il ne ferme pas de possibilités (en fait il en ouvre trop...).
En gros, un noeud de texte ouvert par une balise ne pourra être fermé que par une balise fermante identique. Par exemple, tout ce qui sera en un <p> et un </p> sera du texte.
Néanmoins, toutes les balises block dans des noeuds de texte seront pour l'instant ignorées. <p><div></div></p> affichera donc le texte "<div></div>".
Ajouté le 23/07/2014 à 18:19 :
Beaucoup de nouvelles... je pense possible d'interpréter le code en inline mais cela se fera à l'affichage, donc risque de ralentir le programme... d'un autre côté, trop de balises utiliseront trop de RAM. Difficile de savoir du coup, mais je vais tenter de réduire au maximum la taille de mes structures. N'oublions pas que seront chargés dans la RAM :
→ Les propriétés de toutes les balises. Actuellement 75 octets par balise, plus 75 pour le style et environ 20 par attribut ;
→ Tout le texte affiché à l'écran, chargé en brut ;
→ Toutes les images affichées à l'écran, chargées dans la RAM (et peut-être aussi sur la mémoire des 3 SaveDisp()...).
Tout ça risque de faire monter vite le compteur, d'autant plus qu'un page complète fera au moins 100 à 200 balises.
Donc on peut définitivement tirer un trait sur la lecture des fichiers web classiques (rien que les scripts rempliraient la RAM...).
De plus, après avoir mit l'interpréteur au point sous Linux, je me suis retrouvé confronté à un énorme problème... ben oui, pas de lib standard, donc pas de STL. Pas de new, pas de déclarations d'objets en global. J'ai plus ou moins corrigé tout ça, mais je crains que du coup je me retrouve obligé de passer en C pour éviter un code horrible... à suivre.
De plus, l'inclusion de l'objet memory génère une erreur sans message à la sortie de ld.
[ironie]La compilation sous Linux n'est donc pas encore tout à fait au point... [/ironie]
Citer : Posté le 24/07/2014 00:15 | #
Désolé, je n'ai aucun conseil à te donner.
En tous cas, bonne chance pour ce projet.
Quand tu parles d'une page complète, tu veux parler de tous le document ?
Si oui, n'est-il pas possible de charger au fur et à mesure en fonction de ce qui est affiché, ou bien cela serait trop lent ?
Désolé si tu as déjà répondu à cette question ...
Citer : Posté le 24/07/2014 08:18 | #
Eh bien, le problème en général c'est la vitesse de lecture. Lire dans la mémoire principale ou dans la carte SD ne pose aucun problème, le premier est en RAM et le second très rapide.
Quant au troisième, c'est plus embêtant... la première version de mon programme le lisait caractère par caractère. C'était immédiat sur la carte mais est devenu d'une lenteur exaspérante sur la mémoire de stockage. Pour éviter les multiples accès, je l'ai lu par groupe de 100 octets... mais rien à faire, la lecture est mal codée aussi. Résultat, je n'ai gagné que peu en vitesse et conservé un temps de chargement de plusieurs secondes -- juste pour charger le fichier dans la mémoire !
La dernière solution est de tout charger d'un coup, mais c'est un double problème, car cela reviendrait à utiliser beaucoup de RAM dans le cas de gros fichiers, alors que ce sont bien avec eux qu'il faudrait l'économiser !
Charger au fur et à mesure de ce qui est affiché... ça nécéssite d'avoir tous les fichiers ouverts en même temps, ce qui me limite à 4. Avec les images et les feuilles de style, on n'est jamais trop sûrs... et puis la lecture est tellement lente, s'il faut lire à chaque frame ce sera une horreur de vitesse. De plus, on fait déjà à l'affichage tous les calculs pour les balises inline (ce qui au passage améliore le dynamisme de la page), ce qui risque de ralentir pas mal le programme, et il faut surveiller la souris, les widgets qu'elle survole et adapter les feuilles de style.
Feuilles de style que je n'ai pas encore trouvé le moyen de stocker en économisant la RAM...
J'espère pouvoir vous sortir un moteur HTML (sans CSS, donc) sur la fin du mois.
Ajouté le 24/07/2014 à 16:38 :
J'ai passé l'intégralité du code en C (j'aurais dû écouter Eiyeron... ou me souvenir que je n'avais pas droit à la STL).
Je vais pouvoir retenter la compilation pour calto avec le sh3eb-elf. Celle-ci plantait dans une erreur de linkage fantôme lorsque j'incluais memory, je vais donc commencer par là.
Ajouté le 25/07/2014 à 12:26 :
Je sais pas ce qui se passe avec fxlib, mais quand on compile sous Linux il semble que ça pose quelques problèmes.
J'ai droit à une superbe System ERROR quand je tente de créer un fichier, m'indiquant que le programme à l'adresse 0x8003E4FA (je ne dispose pas du mon add-in désassemblé, mais je sais que ça tombe sur le Bfile_CreateFile()), a déréférencé un pointeur NULL. Sauf que bien évidemment, je ne peux pas modifier ce morceau de code...
En gros je fais à peu près ça :
GetKey(&key);
Bfile_CreateFile(adr,10000);
GetKey(&key);
J'appuie une fois sur une touche et hop, System ERROR.
Si fxlib ne fonctionne pas, c'est peut-être aussi à cause de ma mauvaise conversion de l'objet lib en objet a... je vais voir avec le syscall.
Citer : Posté le 25/07/2014 13:36 | #
Ca peut pas venir de la taille du fichier ? 10ko, c'est peu courant comme taille, même si il me semble avoir déjà essayé avec succès
Citer : Posté le 25/07/2014 13:43 | #
10000 ? C'est rien du tout, on peut créer des fichiers de 1Mo dans la storage.
Je suis sur le point de tester avec le syscall -- qui bien évidemment prend en compte créations de dossiers et de fichiers, main et storage... pourquoi s'amusent-ils à créer tant de fonctions pour rien ? --, et je pense que ça fonctionnera. J'ai déjà pu tester avec GetKeyW.
Du coup, on va se refaire fxlib avec les syscalls.
Au fait pour libc, on doit pouvoir utiliser des syscalls ou extraire des trois trucs de fxlib.a -- il y a tout dedans, des allocations dynamiques aux fonctions mathématiques en passant par la gestion des fonctions callback...
Ajouté le 25/07/2014 à 13:56 :
On dirait que le syscall marche pas trop mal -- rien ne se passe à l'écran. Le problème, c'est que rien ne se passe dans la mémoire non plus.
Citer : Posté le 25/07/2014 15:58 | # |
Fichier joint
Puisque les gros projets ne sont pas là pour faire des expérimentations, je suis repassé sur un mode de compilation plus classique appelé fx-9869G SDK. C'est pas que ça me fait plaisir, mais il y a un Temps pour tout.
Bref, pour vous tenir au courant, voilà le code que je passe au programme :
<html>
<head>
<meta charset="utf-8" />
</head>
<body>
<h1>Page de test</h1>
<div id="Menu" style="display: inline-block;">
<h3>Menu</h3>
<ul>
<li>Element 1/3</li>
<li>Element 2/3</li>
<li>Element 3/3</li>
</ul>
</div>
<div id="Content" style="display: inline-block;">
<h2>Ceci est un titre de niveau 2</h2>
<img src="WebCalc.bmp" />
<p>Vous pouvez admirez le navigateur WebCalc, version alpha !</p>
</div>
</body>
</html>[/color]
Et voilà le log qui en ressort.
sizeof(DOMAttribute) = 12
sizeof(DOMElement) = 124
0x8802404c "html"
0x88024784 "head"
0x88024704 "meta"
0x88024684 "body"
0x88024604 "h1"
0x88024584 "div"
0x880244f8 "h3"
0x88024478 "ul"
0x88024b84 "li"
0x88024b04 "li"
0x88024a84 "li"
0x88024a04 "div"
0x88024984 "h2"
0x88024904 "img"
0x88024884 "p"[/color]
Je joins le log détaillé qui tient compte au fur et à mesure des différentes propriétés des objets créés.
Ajouté le 25/07/2014 à 22:54 :
Quelles merveilles ces champs de bits
Jusqu'ici la structure DOMStyle, qui existe pour chaque objet, pesait 96 octets. En retirant une ou deux propriétés à la réflexion pas très utiles et en optimisant avec des champs de bits (vu le nombre de propriétés qui ne peuvent prendre que 2 ou 4 valeurs pour lesquelles j'avais des uchar... 15), je suis tombé à 56 octets.
Au total, une balise pèse actuellement :
→ 44 octets de propriétés diverses, essentiellement des pointeurs ;
→ 56 octets de style ;
→ 8 octets par attribut ;
→ Et le nom de chaque attribut en texte, ainsi que la valeur en texte ou en entier.
Ce qui me laisse à juste 100 octets dans la plupart des cas, jusqu'à 200 selon les attributs (images...).
Ajouté le 26/07/2014 à 19:51 :
J'ai mis au point une fonction non récursive qui parcourt de manière linéaire l'arbre des objets. En gros elle lit l'arbre ci-dessus (voir le log réduit) de haut en bas et m'en donne les balises une par une. Ça me permettra de les afficher en me passant de la récursivité -- je voudrais éviter de trop l'utiliser quand même...
Citer : Posté le 27/07/2014 19:09 | # |
Fichier joint
Bon, je pense que j'en ai assez dit pour le peu de résultats que j'ai montré, alors voilà quelque chose de plus concret :
Tout simplement généré à partir d'une balise h1, une balise p et une balise center.
Citer : Posté le 28/07/2014 11:19 | # |
Fichier joint
Vous pouvez voir ici une liste basique ul. La balise ol se comportera de la même manière, mais les puces utilisées seront différentes (2,02,b,B,ii,II). J'ai aussi ajouté ce qui faisait principalement défaut à la version précédente du programme : la barre de scrolling (à droite) et la limitation du scroll. En revanche, j'ai dû (à ma plus grande déception) revenir sur un affichage récursif car l'affichage non-récursif ne permettait pas par exemple de mettre simplement une marge en-dessous de la balise ul car elle avait des enfants (li).
De toute manière, la pile fait 64ko alors que la heap n'en fait que 48, et je sais de par les essais que j'ai faits lorsque je bossais sur le moteur récursif TeX qu'on peut faire plusieurs centaines d'appels avant de faire planter le système, dans un exception d'adressage CPU ou une EBR.
Citer : Posté le 28/07/2014 11:23 | #
[HS] Ben ça promet d'être joli tous cela et très bon travail de ta part Lephenixnoir
Ca sera sous quelle forme ton projet ? add-in ? snippets ou lib ? Je n'ai pas bien compris
Citer : Posté le 28/07/2014 12:02 | #
Ce sera un add-in qui affichera un documment htm, comme le ferait un éditeur de texte.
En revanche je pense faire de l'interpréteur pseudo-TeX une lib si cela intéresse.
Citer : Posté le 28/07/2014 12:15 | #
Tu veux pas garder tes screens pour la revue des projets ?
Citer : Posté le 28/07/2014 12:25 | #
[HS] Ben ça promet d'être joli tous cela et très bon travail de ta part Lephenixnoir
Tu veux pas garder tes screens pour la revue des projets ?
En revanche je pense faire de l'interpréteur pseudo-TeX une lib si cela intéresse.
En tout cas beau boulot, j'ai hâte de pouvoir tester ça
Citer : Posté le 28/07/2014 12:27 | #
Au pire on remettra les screens dedans, t'as pas tord, puisque que la revue sert aussi à résumer l'avancement des projets pour quelqu'un qui n'a pas eu le temps d'aller voir sur tout les topics
Citer : Posté le 28/07/2014 12:51 | #
Et puis je ne mets pas tout ici.
Mais ne t'inquiète pas, je vous mettrai les toutes dernières nouveautés pour la revue des projets ; pas quelque chose que j'aurai dépassé depuis longtemps.
(Par contre comme je pars vendredi, vous devriez avoir tout ça jeudi.)
Citer : Posté le 21/09/2014 21:13 | # |
Fichier joint
J'avais dit que je voulais pas y revenir, mais il me semblait vraiment trop crade, donc j'ai repris l'interpréteur TeX, d'autant plus que l'ancien faisait parfois des erreurs d'interprétation et provoquait des System ERROR si on l'appelait trop de fois.
Le nouveau code, commenté et aéré, représente moins de volume que l'ancien, non commenté et bien condensé.
C'est l'intérêt de reprendre à zéro (je le fais tout le temps).
Voici un petit aperçu de la nouvelle version, avec quatre éléments implémentés.
On peut vraiment faire tout ce qu'on veut.
Comme le voulait Julese50, je rajoute mes sources et j'indique que je les colle sous licence GPL 3.0 pour l'instant.
Pour info, un fichier de log existe sur SDCard/TeX.log mais je crois que la version actuelle du programme n'y sort pas grand-chose.
Citer : Posté le 21/09/2014 21:22 | # |
Fichier joint
Ah oui, j'oubliais quelque chose.
Citer : Posté le 21/09/2014 23:38 | #
Une petite question bete et mechante : Tu te preocupais plus haut de la baluse img, pourquoi ?
Je ne doute pad que tu puisse faire lire les imgs a une calto mais bon
Et sinon, grace a k'arduino, on peut se connecter a internet...
Si ton programme envoie l'url au tool planetcasio qui vas avec, PC lui renvoies le code simplifié et tu gagnes un navigateur en prime
Aussi, le curseur ressemblerais a quoi ?
Je suis de l'autre coté de la manche maintenant. Yay.
Citer : Posté le 22/09/2014 06:27 | # |
Fichier joint
Pour tout ce qui est schémas dans les cours, par exemple. Bien souvent, un document sans image c'est moins attirant.
Mais du coup on a le problème du stockage... ben oui, on va pas mettre 36 fichiers pour la page web.
Enfin, j'ai plus ou moins résolu le problème depuis un certain temps déjà, donc ça va de ce côté-là.