Ecrire un compilateur VB pour TI - Page 2

Pollux
:

Kevin Kofler
:

Pollux
:

Et ce que tu n'as pas compris, c'est qu'on n'est pas obligé de garder les fonctions inutilisées, dans une lib dynamique.

Si, parce qu'on ne sait pas quelles fonctions sont inutilisées. L'utilisateur pourrait à tout moment envoyer un programme qui les utilise.

Et ? Le kernel pourrait envoyer les libs/fonctions qui sont utilisées par la même occasion, ce n'est pas un pb...

Si, parce que tu ne peux plus utiliser les logiciels de liaisons de TI, ni les fonctions de linking calculatrice à calculatrice de AMS, mais tu es obligé d'utiliser un logiciel de liaison spécialisé.

On peut toujours passer par le Var-link, si le kernel est bien fait...

Non. Arrête de raconter n'importe quoi. Il n'y a aucun hook prévu pour ça.

Et pour ce qui est des logiciels de liaisons côté PC, il n'y a pas de pb : il suffit que la calc affiche un msg demande de rajouter tel fichier, le logiciel envoie la grosse lib, et la calc filtre ce dont elle a besoin

C'est ça, on complique encore plus les choses pour l'utilisateur... Comme si les librairies dynamiques n'étaient pas déjà assez inutilisables!

Et puis implémente-moi tout ça au lieu de bavarder dans le vide (ta spécialité ) et on en reparlera. J'ai marre de discuter sur du vaporware pur et net, surtout quand il n'y a même pas une seule ligne de code écrite.

On peut tjs rajouter un test supplémentaire d'overflow si on a des comportements bizarres. Mais le coût est trop élevé pour qu'on le rajoute systématiquement...

D'où l'intérêt de programmer en C...
Mais modifier le BASIC pour qu'il se comporte comme du C est stupide. Le C avec une syntaxe BASIC ne sert qu'à irriter le programmeur, ça n'apporte strictement rien. Un langage de programmation n'est pas défini uniquement par sa syntaxe.

J'ai marre de discuter sur du vaporware pur et net, surtout quand il n'y a même pas une seule ligne de code écrite.

personne ne t'a obligé à en parler
et ça t'arrive souvent de te lancer dans un gros programme sans réfléchir ? moi pas.

Si, parce que tu ne peux plus utiliser les logiciels de liaisons de TI, ni les fonctions de linking calculatrice à calculatrice de AMS, mais tu es obligé d'utiliser un logiciel de liaison spécialisé.

je ne vois pas la différence avec un kernel classique

Tu peux envoyer un programme pour kernel avec les logiciels de liaison normaux (TI-GraphLink, TI-Connect, TiLP, ...). Tu ne peux pas le faire si l'envoi d'un programme implique la modification on-calc (même pas le simple envoi!) des librairies dynamiques qu'il utilise!

on devrait pouvoir intercepter les activités du link, non ?

Et pour ce qui est des logiciels de liaisons côté PC, il n'y a pas de pb : il suffit que la calc affiche un msg demande de rajouter tel fichier, le logiciel envoie la grosse lib, et la calc filtre ce dont elle a besoin

C'est ça, on complique encore plus les choses pour l'utilisateur... Comme si les librairies dynamiques n'étaient pas déjà assez inutilisables!

Euh, c pas plus compliqué, et c même plutôt plus simple : rien de spécial à faire en calc-calc, et pour les transferts PC-calc, soit on utilise un soft spécial, soit on envoie les libs comme avec des libs dynamiques classiques (mais le kernel peut afficher un message à l'utilisateur pour lui dire quoi envoyer, donc y a pas de risque d'oubli d'une lib).

Tu peux envoyer un programme pour kernel avec les logiciels de liaison normaux. Tu ne peux pas le faire si l'envoi d'un programme implique la modification on-calc (même pas le simple envoi!) des librairies dynamiques qu'il utilise!

Bien sûr que si

On peut tjs rajouter un test supplémentaire d'overflow si on a des comportements bizarres. Mais le coût est trop élevé pour qu'on le rajoute systématiquement...

D'où l'intérêt de programmer en C... Mais modifier le BASIC pour qu'il se comporte comme du C est stupide. Le C avec une syntaxe BASIC ne sert qu'à irriter le programmeur, ça n'apporte strictement rien. Un langage de programmation n'est pas défini uniquement par sa syntaxe.

Tu racontes vraiment des énormités
Va raconter que le C# ou le Java "se comporte comme du C" à n'importe qui qui a déjà programmé avec, il te rira au nez... D'autant plus qu'eux aussi font du wraparound en cas d'overflow.

Et cf mon benchmark, dans les cas où le C# ressemble au C, les résultats sont complètement équivalents en termes de performances. Dans les autres cas, on a généralement moins besoin de performance : affichage de résultats de calculs, entrées/sorties... Et c'est généralement là que le C est très chiant.

Pour ce qui est de la syntaxe Basic irritante, je suis plutôt d'accord (malgré le reste de la phrase qui est tordant ), et c'est pour ça que je parle de C#.

Flanker
: on devrait pouvoir intercepter les activités du link, non ?

Oui, par exemple, ou bien encore détecter après l'envoi des fichiers ce qu'il faut supprimer ou dire à l'utilisateur ce qu'il manque comme libs.

Pollux
:

Et pour ce qui est des logiciels de liaisons côté PC, il n'y a pas de pb : il suffit que la calc affiche un msg demande de rajouter tel fichier, le logiciel envoie la grosse lib, et la calc filtre ce dont elle a besoin

C'est ça, on complique encore plus les choses pour l'utilisateur... Comme si les librairies dynamiques n'étaient pas déjà assez inutilisables!

Euh, c pas plus compliqué, et c même plutôt plus simple : rien de spécial à faire en calc-calc,

Si.
Scénario: L'utilisateur 1 a un programme a qui nécessite le sous-ensemble A de la librairie vbrunlib. L'utilisateur 2 a un programme b qui nécessite le sous-ensemble B de la librairie vbrunlib. L'utilisateur 1 veut envoyer le programme a à l'utilisateur 2.
Résultat désiré: L'utilisateur 2 a les programmes a et b et le sous-ensemble A union B de vbrunlib.
Déroulement:
* L'utilisateur 1 envoie le programme a.
* L'utilisateur 2 lance le programme a.
* ERREUR: Il manque vbrunlib::A. (Déjà là, on voit que le système ne fonctionne pas correctement, parce que l'envoi d'un programme ne devrait pas nécessiter plus que ça. Mais la suite est pire!)
* L'utilisateur 1 envoie donc vbrunlib.
* Pour faire fonctionner le programme a, l'utilisateur 2 accepte d'écraser vbrunlib, et se retrouve donc avec vbrunlib::A à la place de vbrunlib::B.
* Du coup, c'est le programme b qui ne marche plus!
Résultat: échec.
Le seul moyen de résoudre ce problème est un logiciel de liaison on-calc spécialisé. Donc gaspillage de place.

et pour les transferts PC-calc, soit on utilise un soft spécial,

Et c'est exactement l'inconvénient duquel je parle!
Et d'ailleurs, même avec ça, il faut aussi un logiciel spécial du côté calculatrice (donc gaspillage de place).

soit on envoie les libs comme avec des libs dynamiques classiques (mais le kernel peut afficher un message à l'utilisateur pour lui dire quoi envoyer, donc y a pas de risque d'oubli d'une lib).

Tu veux envoyer les fonctions une à une???
Si c'est oui: Ça va te faire une centaine de fichiers à envoyer minimum pour un programme en VB (le sujet du topic), et (en plus du fait que retrouver et envoyer une centaine de fichiers soit totalement inacceptable pour l'utilisateur) chacun de ces fichiers portera l'overhead (headers etc.) d'une librairie dynamique.
Si c'est non: Le scénario d'en haut s'applique. Un sous-ensemble écrase l'autre au lieu de s'y unir.

Tu peux envoyer un programme pour kernel avec les logiciels de liaison normaux. Tu ne peux pas le faire si l'envoi d'un programme implique la modification on-calc (même pas le simple envoi!) des librairies dynamiques qu'il utilise!

Bien sûr que si

Et comment???
Tu racontes encore une fois n'importe quoi. Les logiciels TI ne gèrent pas la modification de fichiers.

Tu racontes vraiment des énormités

Et c'est toi qui dis ça??? Toi qui prétends qu'on peut modifier des fichiers on-the-fly avec les logiciels de liaison de TI???

Va raconter que le C# ou le Java "se comporte comme du C" à n'importe qui qui a déjà programmé avec, il te rira au nez...

En pas mal de domaines, oui! En d'autres non, et justement l'overflow en est un:

D'autant plus qu'eux aussi font du wraparound en cas d'overflow.

Non, pas "eux aussi", mais eux seulement! Le C fait absolument n'importe quoi en cas d'un overflow signé! Ça n'a rien à voir avec le Java qui préscrit un wraparound.

Pour ce qui est de la syntaxe Basic irritante, je suis plutôt d'accord (malgré le reste de la phrase qui est tordant )

Tu n'as même pas compris ce que j'ai dit! Ce n'est pas la syntaxe BASIC qui est irritante en elle-même (au contraire, elle est très pratique), mais le fait d'avoir un langage qui de par sa syntaxe prétend d'être du BASIC alors que le comportement est très loin de celui du BASIC.

Pollux
:

Flanker
: on devrait pouvoir intercepter les activités du link, non ?

Oui, par exemple, ou bien encore détecter après l'envoi des fichiers ce qu'il faut supprimer ou dire à l'utilisateur ce qu'il manque comme libs.

Toutes les solutions qui contiennent "dire à l'utilisateur" sont par définition mauvaises.
Quant à l'autre idée, elle n'est pas faisable non plus, parce qu'il faudrait savoir ce que nécessitent tous les programmes présents sur la calculatrice, programmes qui peuvent être compressés de manière arbitraire, voire cryptés, cachés etc. Et en plus, ça impliquerait de devoir à chaque fois réenvoyer la librairie entière (à la main), puis écraser ce qu'il y a de trop, ce qui n'est pas pratique non plus. "Envoyer avant et nettoyer après" est une solution sale et qui nécessite trop de mémoire au moment de l'envoi du programme.
Et pour finir, ton "ou" devrait être un "et". L'envoi se passera normalement comme ça:
* Envoi du programme.
* ERREUR: Il manque foolib::xxxx. ("dire à l'utilisateur") L'utilisateur se tape obligatoirement le message, parce qu'il n'a aucun moyen de savoir à l'avance si son sous-ensemble de foolib suffit ou s'il faut le compléter.
* L'utilisateur envoie foolib (toute entière, il n'a pas le choix), écrasant le sous-ensemble présent.
* La calculatrice doit maintenant ("après l'envoi des fichiers") "détecter" "ce qu'il faut supprimer".
Tu remarqueras que les 2 problèmes s'appliquent. Donc la solution est doublement mauvaise.

En résumé: Le problème des fonctions inutilisées est un problème inhérent des librairies dynamiques. Il n'y a pas de solution techniquement faisable en pratique autre que le linkage statique.

Rah t'abuses de lancer une discussion kilométrique Je vais essayer de répondre de manière concise, puisqu'il n'y a de tte façon pas gd chose à dire...

Kevin Kofler
:

Pollux
: Euh, c pas plus compliqué, et c même plutôt plus simple : rien de spécial à faire en calc-calc,

Si.
Scénario: L'utilisateur 1 a un programme a qui nécessite le sous-ensemble A de la librairie vbrunlib. L'utilisateur 2 a un programme b qui nécessite le sous-ensemble B de la librairie vbrunlib. L'utilisateur 1 veut envoyer le programme a à l'utilisateur 2.
Résultat désiré: L'utilisateur 2 a les programmes a et b et le sous-ensemble A union B de vbrunlib.
Déroulement:
* L'utilisateur 1 envoie le programme a.
* L'utilisateur 2 lance le programme a.
* ERREUR: Il manque vbrunlib::A. (Déjà là, on voit que le système ne fonctionne pas correctement, parce que l'envoi d'un programme ne devrait pas nécessiter plus que ça. Mais la suite est pire!)
* L'utilisateur 1 envoie donc vbrunlib.
* Pour faire fonctionner le programme a, l'utilisateur 2 accepte d'écraser vbrunlib, et se retrouve donc avec vbrunlib::A à la place de vbrunlib::B.
* Du coup, c'est le programme b qui ne marche plus!
Résultat: échec. Le seul moyen de résoudre ce problème est un logiciel de liaison on-calc spécialisé. Donc gaspillage de place.

Tu crois que je n'ai pas étudié la question? Comme dit plus haut, le kernel intercepte les créations de fichiers, et demande l'envoi de la lib de B, puis concatène les versions. Ca n'a rien de fondamentalement compliqué.

et pour les transferts PC-calc, soit on utilise un soft spécial,

Et c'est exactement l'inconvénient duquel je parle! Et d'ailleurs, même avec ça, il faut aussi un logiciel spécial du côté calculatrice (donc gaspillage de place).

Ce logiciel spécial s'appelle un kernel, oui.

soit on envoie les libs comme avec des libs dynamiques classiques (mais le kernel peut afficher un message à l'utilisateur pour lui dire quoi envoyer, donc y a pas de risque d'oubli d'une lib).

Tu veux envoyer les fonctions une à une???
Si c'est oui: Ça va te faire une centaine de fichiers à envoyer minimum pour un programme en VB (le sujet du topic), et (en plus du fait que retrouver et envoyer une centaine de fichiers soit totalement inacceptable pour l'utilisateur) chacun de ces fichiers portera l'overhead (headers etc.) d'une librairie dynamique. Si c'est non: Le scénario d'en haut s'applique. Un sous-ensemble écrase l'autre au lieu de s'y unir.

C'est non, donc le scénario d'en haut s'applique effectivement : c'est le kernel qui fait le boulot.

Tu peux envoyer un programme pour kernel avec les logiciels de liaison normaux. Tu ne peux pas le faire si l'envoi d'un programme implique la modification on-calc (même pas le simple envoi!) des librairies dynamiques qu'il utilise!

Bien sûr que si

Et comment???
Tu racontes encore une fois n'importe quoi. Les logiciels TI ne gèrent pas la modification de fichiers.

Le kernel le gère.

Tu racontes vraiment des énormités

Et c'est toi qui dis ça??? Toi qui prétends qu'on peut modifier des fichiers on-the-fly avec les logiciels de liaison de TI???

Oui, c'est moi qui dit ça. Le kernel gère les modifications (tiens, j'ai comme l'impression de dire la même chose 5 fois ^^)

Va raconter que le C# ou le Java "se comporte comme du C" à n'importe qui qui a déjà programmé avec, il te rira au nez...

En pas mal de domaines, oui! En d'autres non, et justement l'overflow en est un:

D'autant plus qu'eux aussi font du wraparound en cas d'overflow.

Non, pas "eux aussi", mais eux seulement! Le C fait absolument n'importe quoi en cas d'un overflow signé! Ça n'a rien à voir avec le Java qui préscrit un wraparound.

"Eux aussi" ne se rapportait pas au C, mais à ma proposition que tu jugeais complètement indécente (à savoir celle de faire un wraparound plutôt qu'un trap) et dont tu disais qu'elle reviendrait à faire un langage bas niveau genre C (et c'est effectivement une énormité, je maintiens)

Pour ce qui est de la syntaxe Basic irritante, je suis plutôt d'accord (malgré le reste de la phrase qui est tordant )

Tu n'as même pas compris ce que j'ai dit! Ce n'est pas la syntaxe BASIC qui est irritante en elle-même (au contraire, elle est très pratique), mais le fait d'avoir un langage qui de par sa syntaxe prétend d'être du BASIC alors que le comportement est très loin de celui du BASIC.

Et le C# ou le Java prétendent avoir un comportement comme le C ou le C++ ? Pourtant, ils utilisent une syntaxe proche... (et les différences sont souvent bien plus profondes :

string a="hello";
string b="hel"+"lo";
return a==b;

n'a pas du tout le même comportement en C#/Java et en C++)

Pollux
:

Flanker
: on devrait pouvoir intercepter les activités du link, non ?

Oui, par exemple, ou bien encore détecter après l'envoi des fichiers ce qu'il faut supprimer ou dire à l'utilisateur ce qu'il manque comme libs.

Toutes les solutions qui contiennent "dire à l'utilisateur" sont par définition mauvaises.[/cite]
Oui, d'où l'idée de faire un soft de transfert qui s'en occuperait. On peut même en faire un démon qui tourne en parallèle d'un autre soft de transfert (quelconque), et qui écouterait les demandes de libs du kernel... Le travail serait minimal et l'interaction avec l'utilisateur inexistante.

Quant à l'autre idée, elle n'est pas faisable non plus, parce qu'il faudrait savoir ce que nécessitent tous les programmes présents sur la calculatrice, programmes qui peuvent être compressés de manière arbitraire, voire cryptés, cachés etc. Et en plus, ça impliquerait de devoir à chaque fois réenvoyer la librairie entière (à la main), puis écraser ce qu'il y a de trop, ce qui n'est pas pratique non plus. "Envoyer avant et nettoyer après" est une solution sale et qui nécessite trop de mémoire au moment de l'envoi du programme.
Et pour finir, ton "ou" devrait être un "et". L'envoi se passera normalement comme ça:
* Envoi du programme.
* ERREUR: Il manque foolib::xxxx. ("dire à l'utilisateur") L'utilisateur se tape obligatoirement le message, parce qu'il n'a aucun moyen de savoir à l'avance si son sous-ensemble de foolib suffit ou s'il faut le compléter.
* L'utilisateur envoie foolib (toute entière, il n'a pas le choix), écrasant le sous-ensemble présent.
* La calculatrice doit maintenant ("après l'envoi des fichiers") "détecter" "ce qu'il faut supprimer". Tu remarqueras que les 2 problèmes s'appliquent. Donc la solution est doublement mauvaise.

Non, le principe est que les libs requises n'ont pas à être compressées (et ne seront de toute façon pas compressibles si elles sont représentées par un hash). Et l'utilisateur n'a a strictement rien à faire (ma proposition n'est qu'une rustine dans le cas où un psychorigide [hum] ne voudrait surtout pas changer de soft de transfert, mais ça n'est pas censé se passer comme ça).

mouais. Enfin pour peu que certaines fonctions soit souvent utilisées, on perd facilement de la place.
Exemple : mes TSR. Pour l'instant, ils sont potentiellement buggués vu qu'ils s'installent sans prendre en compte la limite des 24ko. J'ai 2 solutions pour résoudre :
* include h220xtsr dans chaque fichier
* les mettre en mode kernel
sachant que j'ai une plus d'une dizaine de TSR, où est la perte de place ?

Kevin Kofler
: En résumé: Le problème des fonctions inutilisées est un problème inhérent des librairies dynamiques. Il n'y a pas de solution techniquement faisable en pratique autre que le linkage statique.

En résumé : n'importe quoi. Il suffit d'upgrader les softs de transfert sur PC, et de mettre un message on-calc disant de le faire s'ils ne sont pas à jour. Et la solution "démon" permet à l'utilisateur de garder son prog préféré tout en bénificiant des libs dynamiques...

Flanker
: mouais. Enfin pour peu que certaines fonctions soit souvent utilisées, on perd facilement de la place.

Rien qu'avec les routines de gray et fopen&co, on doit pouvoir gagner facilement 10% de la taille des progs (sauf si l'utilisateur a seulement TI-Chess ^^)

Et le C# ou le Java prétendent avoir un comportement comme le C ou le C++ ? Pourtant, ils utilisent une syntaxe proche... (et les différences sont souvent bien plus profondes :

string a="hello";
string b="hel"+"lo";
return a==b;

n'a pas du tout le même comportement en C#/Java et en C++)

t fairestring b = string("hel")+"lo";Euh, en c++, tu voudrais plutô non ?

Oui, évidemment (et je trouve ça plus joli d'écrire (string)"hel"+"lo", ça n'introduit pas de dissymétrie)

Si, c'est quand-même dissymétrique, c'est juste que ça se voit moins.
Et en C++ moderne, il faut mettre static_cast<string>("hel")+"lo".

nitro (#26) > Merci

Kevin Kofler :
Si, c'est quand-même dissymétrique, c'est juste que ça se voit moins.

Oui, bien sûr... Mais la stdlib peut être conçue de telle sorte que ça se traduise en un truc purement symétrique

Et en C++ moderne, il faut mettre static_cast<string>("hel")+"lo".

? Ce que j'ai dit est interdit en C++ moderne

Les transtypages qui ne précisent pas le type de transtypage à effectuer sont dépréciés en C++.

");Bahstring b = string("hel")+string("lo c'est pas du transtypage, c'est une construction d'objets temporaires.

C'est vrai...
Moi et le C++... Vous pourrez apprécier ça quand vous verrez la source de KTIGCC.

Salut,
je suis en train d'écrire un compilateur basic pour les 68k, et c'est presque fini.
Et toi t'en est ou Golden?? tu peux me filer ton adresse e-mail pour qu'on s'ecrive??
Onur

^^ moi j'en suis au stade réflexion intensive (j'y pense presque tous les jours) et début de l'écriture du compilo (tokenizer fini, gestion des erreurs minimaliste, et la suite est juste commencée).
Mais vu que je dois coder les outils annexes (linker, assembleur pseudo-asm) avant, je vais pas y retoucher tout de suite.
Sinon, pour parler, je préfère les minimessages

Tu n'es pas obligé de recoder un linker et un assembleur... utilise as et ld-tigcc. Franchement, ce n'est pas le plus interessant (concevoir le langage l'est bien plus), et TIGCC le fait deja largement assez bien.

Tu veux pas qu'on s'y mette ensemble tant qu'à faire?? parce qu'il y a du boulot et c'est dommage de ne pas s'associer.. quoique c'est plus interessant de concevoir son propre langage.

nitro
: Tu n'es pas obligé de recoder un linker et un assembleur... utilise as et ld-tigcc. Franchement, ce n'est pas le plus interessant (concevoir le langage l'est bien plus), et TIGCC le fait deja largement assez bien.

il faut que j'en fasse un, mais vu que l'assembleur généré contient un certain nombre limité d'instruction, ca va pas poser bcp de probleme. j'ai aussi emprunté un bouquin sur 68k, pour savoir les opcodes ds instructions..
L'interet c'est de faire un prog autonome, si les utilisateur doivent a nouveau par TIGCC, c'est pas tres interessant non plus..

Onur
: si les utilisateur doivent a nouveau par TIGCC, c'est pas tres interessant non plus..

Si le but de ton projet est de nous faire ch**r, dis-le directement.
Je ne vois pas l'intérêt de réinventer la roue. Nos outils sont là pour être utilisés...

Pfff sans commentaire mais je n'en pense pas moins... mon pauvre...

Et toi, on t'a pas sonné.

Au fait Onur ton site fait très pro Et pkoi y a un lien vers SourceView ? Tu comptes t'en servir ?

Allez vous engueuler ailleurs. Si vous avez vraiment quelquechose à dire dans ce topic -> plaidez votre cause par minimessages.