Power Basic - Page 3

Je crois que tu alloue à chaque variant (VARIANT_STRING_SIZE+double+2*pointeur) octets, ce qui doit faire 262 octets pour VARIANT_STRING_SIZE=256.

MacIntoc
: Je crois que tu alloue à chaque variant (VARIANT_STRING_SIZE+double+2*pointeur) octets, ce qui doit faire 262 octets pour VARIANT_STRING_SIZE=256.

En fait, j'alloue VARIANT_STRING_SIZE + sizeof (void*) + sizeof (Variant_Type) par variant. ça pourrait être réduit à VARIANT_STRING_SIZE + sizeof (Variant_Type) par variant en mettant le pointeur à l'intérieur de l'union. Je ne sais pas pourquoi je l'ai mis à l'extérieur, c'est sûrement un oubli.

MacIntoc
: Je crois que tu alloue à chaque variant (VARIANT_STRING_SIZE+double+2*pointeur) octets, ce qui doit faire 262 octets pour VARIANT_STRING_SIZE=256.

NON STOP

il utilise une UNION et pas une STRUCTURE

donc l'union est de la taille du plus grand element qu'elle contient.

Pour ce qui est du variant cela fait qu'il prendra TOUJOURS 256Octets quoi qu'il y ai a l'interieur, ce qui est un peu gros, pire si on utilise l'option pour agrandire les chaines..

Je te conseil plutot de t'inspirer de vb (et autres langages interprété) les chaines sont passé par reférences (cad via pointeurs) et pas directement

donc ton union devrait plutot etre :

/* Sa gicle ça :
#ifndef VARIANT_STRING_SIZE 
	#define VARIANT_STRING_SIZE 256 
#endif 
*/
 
typedef enum {VARIANT_UNDEFINED, VARIANT_NUMERIC, VARIANT_STRING, VARIANT_POINTER, VARIANT_ARRAY} Variant_Type; 
 
struct Variant_Struct; 
 
struct VariantArray_Struct; 
 
typedef struct Variant_Struct { 
	union { 
		double num; 
		char *str; // <----------------------    
		struct Variant_Struct * ptr; 
		void * voidp; 
	}; 
	struct VariantArray_Struct * array; 
	Variant_Type type; 
} Variant;

[cite]Godzil :

Je te conseil plutot de t'inspirer de vb (et autres langages interprété) les chaines sont passé par reférences (cad via pointeurs) et pas directement
[cite]

Je songe allouer dynamiquement les chaînes dans les variants, en effet. Mais c'est moins évident à gérer. Cependant je compte terminer la bibliothèque de fonctions et paufiner l'IDE avant.

Quesoft> si tu fais une liste d'entiers, elle fait bien 256 octets*nombre d'entiers, non?

void* ptr
unsigned char utype
ca suffit.

Pollux
: Quesoft> si tu fais une liste d'entiers, elle fait bien 256 octets*nombre d'entiers, non?

Oui, car les listes/matrices sont des arrays de Variant.
Dans l'exemple suivant, un handle est alloué statiquement et 256 * 10 octets sont alloués dynamiquement.

PName(str)
Prgm
NewList maMat, 10
'Ne compilera pas : l'utilisation de 'littéraux' de listes n'est pas encore supportée ...
[[1,2,3,4,5,6,7,8,9]]->maMat
EndPrgm

* avoir un char tout seul n'apporte rien à cause des histoires d'alignement... ça peut même réduire un peu la vitesse dans certains cas.
* si il alloue son truc séparément (ce qui serait presque indispensable dans le cas de listes ou de chaînes, on est d'accord), ça va ramer un max s'il ne fait pas ses routines d'alloc perso...

Quesoft
:

Kevin Kofler :
Je ne comprends pas trop l'intérêt: les programmes TI-BASIC ne seront pas utilisables avec Power Basic en vue de toutes les différences, donc ça sert à quoi?

Comme la syntaxe PB est identique à la syntaxe TI-BASIC, un programmeur basic pourra programmer sans avoir à apprendre un nouveau langage. C'est ça l'intérêt.

Ce n'est pas la syntaxe qui fait un langage! C'est surtout ça que tu n'as pas compris: tu nous ponds du C à la sauce Java et du C à la sauce BASIC, mais c'est toujours du C au fond. Ton langage est loin de se comporter comme du TI-BASIC. Il n'y a qu'à voir les matrices, gérées totalement différemment.

malheureusement, au vu de la gestion de la mémoire

>Ce n'est pas la syntaxe qui fait un langage!

Vrai, bien que si deux langages ont une syntaxe semblable, la courbe d'apprentissage est moins à pic. C'est justement pourquoi les programmeurs BASIC ne passe pas au C. Ce n'est pas la syntaxe qui les rebutent, mais la 'philosophie' de programmation. En basic, on n’a même pas à se soucier des types ou de la gestion de la mémoire. Power Basic conserve 'l'esprit' du TI-BASIC et c'est pourquoi un programmeur basic ne s'y sentirait pas dépaysé.

>C'est surtout ça que tu n'as pas compris: tu nous ponds du C à la sauce Java et du C à la sauce BASIC, [...]

En fait, c'est surtout vrai pour Moka, qui est un gros préprocesseur C. Mais PB fait abstraction de la logique de programmation du langage C en quelque sorte.

> [...] mais c'est toujours du C au fond.

Je ne vois pas en quoi c'est un problème. Je ne prétends pas que Moka et PB sont des langages révolutionnaire, ni même que ce sont des langages à part entière. Moka est en fait du C avec le support de certaines 'extensions' Java, comme les classes ou le polymorphisme. Ont peut alors programmer conformément au paradigme orienté objet en C en utilisant Moka. Quant à PB, il permet d'utiliser le langage C pour programmer de la même façon qu'en TI-BASIC.

> on langage est loin de se comporter comme du TI-BASIC. Il n'y a qu'à voir les matrices, gérées totalement différemment.

Je crois que le est loin de est en peu exagéré, ou tout le moins ne concerne que les matrices. Les programmes Power Basic se comportent comme des programmes basic qui utiliseraient beaucoup de fonctions des différentes librairies comme FLIB.

Ce que j'essaie d'expliquer, c'est que je ne prétends pas que PB soit préférable à l'ASM, le C ou Moka, au contraire. Je n'encouragerai jamais un programmeur ASM, C ou Moka (s'il y en a plus d'un ) à passer au Power Basic. Cependant, je crois que PB peut être intéressant pour un programmeur de TI-BASIC.

[EDIT]

Les différents basics sont loin d'êtres mes langages préférés. Au contraire, je trouve qu'il a les défauts du pascal sans en avoir les qualités. J'aimes les langages typés, avec une syntaxe brève (ce que ni le basic, ni le pascal n'a). Cependant, c'est le langage qu'une bonne partie des utilisateurs de calculatrices 'parlent'. Je croix que l'on doit leur donner les moyens d'obtenir des performances meilleures (côté vitesse) que celle qu'il obtiennent en faisant appel à des librairies.

Et mon post sur les entiers qui prennent 256 octets ? C'est dommage, parce que ça rend ton truc complètement inutilisable... Dis-toi bien que ça limite la taille d'une map de jeu à 16x16, au-delà on dépassera la limite des 64k... Et inversement, la limite de 256 octets pour les chaînes peut être très pénalisante...

(et le fait que cette limite soit variable n'arrange pas franchement le problème : on tape encore plus soit d'un côté, soit de l'autre...)

Les différents basics sont loin d'êtres mes langages préférés. Au contraire, je trouve qu'il a les défauts du pascal sans en avoir les qualités.

Euh non, j'ai encore une fois l'impression que tu fais l'impasse sur la gestion de la mémoire... Le Basic a qd même l'avantage de manipuler des listes/chaînes avec une facilité incomparable, que ça soit par rapport au C ou au Pascal...

J'aimes les langages typés, avec une syntaxe brève (ce que ni le basic, ni le pascal n'a).

Pollux>pkoi tu te focalise sur le type variant ??
Aprés tous, il est tous a fait possible de définir des variables de type spécifiques. Si kk1 veut faire une map, il fairat :
Dim map(128,128) As Integer.

Sinon, Quesoft, tu pourrait utilisé des listes chainés, ça te rajoutes 2 octets (pour les 2 pointeurs) par variable unitaire plus 2 octets pour la liste (pointeur de début et de fin de liste).

MacIntoc :
Pollux>pkoi tu te focalise sur le type variant ??
Aprés tous, il est tous a fait possible de définir des variables de type spécifiques. Si kk1 veut faire une map, il fairat :
Dim map(128,128) As Integer.

En effet (bien que les matrices de types spécifiques, tout comme les fonctions / sous programmes qui acceptent ou retournent des types spécifiques, ne sont pas encore implémentés).

MacIntoc
: Sinon, Quesoft, tu pourrait utilisé des listes chainés, ça te rajoutes 2 octets (pour les 2 pointeurs) par variable unitaire plus 2 octets pour la liste (pointeur de début et de fin de liste).

C'est toujours possible, mais avec beaucoup d'éléments on se butte au fait que le nombre de blocs pouvants être alloués est limité.

Et mon post sur les entiers qui prennent 256 octets ? C'est dommage, parce que ça rend ton truc complètement inutilisable... Dis-toi bien que ça limite la taille d'une map de jeu à 16x16, au-delà on dépassera la limite des 64k... Et inversement, la limite de 256 octets pour les chaînes peut être très pénalisante...

À ce moment là, on peut suivre la solution de MacIntoc. De toute façon, comme je l'ai déjà dit, l'idéal serait de réimplanter le type Variant différemment. Cependant, ça complexifierait sa gestion. En passant, seul le handle (8 octets) est alloué statiquement. PB fait l'allocation de l'array dynamiquement, lors de l'exécution (ça n'empêche pas qu'avec une map de 16x16 on dépasse la limite).

Les différents basics sont loin d'êtres mes langages préférés. Au contraire, je trouve qu'il a les défauts du pascal sans en avoir les qualités.

Euh non, j'ai encore une fois l'impression que tu fais l'impasse sur la gestion de la mémoire... Le Basic a qd même l'avantage de manipuler des listes/chaînes avec une facilité incomparable, que ça soit par rapport au C ou au Pascal...

Lorsque j'ai dit ça, je posait un jugement de valeur, je ne le nie pas. Ça reste mon opinion. Quand à la gestion de la mémoire, c'est vrai qu'elle est plus simple à gérer en basic, du moins pour le programmeur, qui n'a pas à s'en soucier. Cependant, à mes yeux, ce n'est pas automatiquement un avantage, car c'est moins performant. De plus, la manipulation des chaînes est tout aussi 'facile' en Pascal (du moins dans la version de delphi que j'utilise) qu'en basic. D'autres langages sont garbage collectés, comme le java, mais n'ont pas les autres 'plaies' du basic et c'est pourquoi ce n'est pas un langage que j'afectionne par dessus tout. Encore là, ça reste une opinion. Certaines personnes croient qu'un langage atypé - comme le basic ou le php - est plaisant (c'est pas mon cas, sauf que je peut vivre avec si c'est un langage batch ou de script). D'autres croient que les langages très proche des langages parlés - comme le basic, le pascall ou le cobol - est souhaitable (ce n'est pas mon cas non plus). Rendu là, c'est une question de préférence.

Il reste cependant le fait qu'à cause de la facilité incomparable avec laquelle le langage basic gère la mémoire est certainement responsable de son innéficience (côté vitesse).

Au fait, Pollux:
*surtout si le prog initial fait 50ko... *

Y'a peu de chances qu'une TI arrive à tokéniser un programme
de cette longueur si c'est en un fichier...
Et je crois pas que Quesoft va s'embêter à gérer des fichiers Basic
multiples....

Mais je vois ce que tu veux dire.

Kitsune :
Au fait, Pollux:
*surtout si le prog initial fait 50ko... *

Y'a peu de chances qu'une TI arrive à tokéniser un programme
de cette longueur si c'est en un fichier...
Et je crois pas que Quesoft va s'embêter à gérer des fichiers Basic
multiples....

Mais je vois ce que tu veux dire.

C'est pas encore implanté, mais ça serait une 'feature' assez utile, tout comme de pouvoir inclure des librairies statiques.

Kitsune :
Au fait, Pollux:
*surtout si le prog initial fait 50ko... *

Y'a peu de chances qu'une TI arrive à tokéniser un programme de cette longueur si c'est en un fichier...

On peut le tokéniser avec Tokens89.

Kevin>faut être sur de sont coup, comme en C, pasque si y a une erreur -> DTC

Quesoft>bien sur qu'il y a une limite, mais elles n'est pas tellement moins importantes qu'avec le systeme natif actuel.

Du VB5 ?
Je trouve carrément dangereux d'utiliser des OCX.
(J'ai eu pas mal de blèmes avec des vieux programmes
utilisant ces technologies antédiluviennes)

Bon faudra que je l'essaie sur mon PC...
Si ça marche et que ça me plait, je le convertirai
peut-être en VB .NET 2002.

euh... conversion auto ou manuel ??

Euh... je sais pas si j'ai le wizard de conversion dans ma version....
Si c'est le cas (et qu'il marche avec VB5, parceque c'est conçu pour VB6)
ben automatique, vu que je me fous de l'optimisation,
et puis sinon, ben manuel... (ce qui est probable).

Mais ça marchera plus par exemple sur Windows 95...

Mais je crois que c'est pas dramatique.

Kitsune :
Du VB5 ?
Je trouve carrément dangereux d'utiliser des OCX.
(J'ai eu pas mal de blèmes avec des vieux programmes
utilisant ces technologies antédiluviennes)

Bon faudra que je l'essaie sur mon PC...
Si ça marche et que ça me plait, je le convertirai peut-être en VB .NET 2002.

Bonne chance. Avec toutes les spécificités du VB5 que j'ai utilisées, ça ne va pas être facile à mon avis.
Et je ne vois pas trop l'intérêt... L'OCX marche très bien.

Kitsune :
Euh... je sais pas si j'ai le wizard de conversion dans ma version....
Si c'est le cas (et qu'il marche avec VB5, parceque c'est conçu pour VB6)
ben automatique, vu que je me fous de l'optimisation, et puis sinon, ben manuel... (ce qui est probable).

Le VB5 et le VB6 sont presque identiques, mon code compile très bien sous VB6, donc ce n'est pas ça qui posera problème avec le wizard.

Mais ça marchera plus par exemple sur Windows 95...
Mais je crois que c'est pas dramatique.

Mon avis est que c'est idiot d'abandonner la compatibilité avec les anciens Windows pour gagner... rien! Mais je ne peux pas t'empêcher de faire cette bêtise, la LGPL te permet de faire ça même sans me demander mon avis.

Kevin Kofler
: Mais je ne peux pas t'empêcher de faire cette bêtise, la LGPL te permet de faire ça même sans me demander mon avis.

C'est paradoxalement la beauté du code libre.

Une question importante, les indirections, elles sont gérées ??

MacIntoc
: Une question importante, les indirections, elles sont gérées ??

Oui. Mais c'est différent du basic :

Au lieu de déréférencer une chaîne de caractère, on doit utiliser l'opérateur at ('@').

Exemple :

5->vari

@vari->monPtr

'Assigner la valeur 10 à vari
10 -> #monPtr

En passant, vous pouvez consulter les derniers post pour télécharger la version pre alpha.
http://quesoft.dyndns.org:8080/dev/pbasicalpha.zip

* * En testant je me suis rendu compte que :
10 -> #monPtr
ne compile pas. C'est un bug qui devrait être corrigé dans le prochain build.

Et pour les truc du genre :

for t,1,10
t->#( "var" & string(t) )
endfor

ca serat toujours possible ??

MacIntoc :
Et pour les truc du genre :

for t,1,10
t->#( "var" & string(t) )
endfor
ca serat toujours possible ??

Non pas sous cette forme. Mais il y a souvent moyen de faire autrement. Exemple :

for t,1,10
t->var[t]
endfor

En théorie, l'<indirection> à la TI-BASIC n'est pas possible dans un langage compilé. Je présume que dans le code assembleur généré par TIGCC les variables ne sont pas accédés en regardant dans une table pour avoir leur déplacement (moi je trouverait ça innutilement lent, mais KK aurait probalement rejeté l'idée parce que ça prenait plus de place ! ). Elle doivent être accédées dirrectement, car c'est plus rapide. C'est plus rapide ainsi.

C'est domage que, malgré une syntaxe identique, le PB ne se programme pas 100% identiquement au TI-BASIC. Cendant c'est toutes ces petites différences limitant le langage, mais n'en augmentant pas la complexité, qui permettent un gain considérable au chapître de la rapidité d'exécution.

arf... c bien ce que je craignait
Donc en passant au PowerBasic, on abandonne l'adressage par string et on se limite à celle par nombre

Du coup, ce genre de truc marche pas non plus :

"tadata"->var
Archive #(var)

"programme"->var
#var()

c dommage