Ti-Basic > On va voir ce que vous valez :) - Page 3

c'est tres souple.
ca gere la memoire de facon pratique pour le programmeur, on s'occupe de rien.

Et la plupart du temps, on evite l'usage des variables, ce qui accelere

bref...ttes les qualités...mais est-ce que c vraiment répandu comme langage?

Je pense pas...
Par contre, aucun accée à la mémoire, ça vas pas plaire, je pense

Arf la bonne blague!
Non c'est pas repandu mais alors pas du tout puisque ca a ete developpe par Hp pour les calc Hp et uniquement...

Mais c'est quand meme un langage tres proche du Forth, et qui est aussi apparente au Lisp, deux langages qui ont eu leur heure de gloire. En fin bref, c'est pas un langage de branlot, non plus. Pas du TiBasic... C'est un Forth modifie pour calculatrices.

Mais si c'est pas repandu, c'est parce que c'est concu tout specialement pour les calculatrices!

Y'a quand meme un max de potentiel pour cette idée...

En remplaçement du TI-basic, ça devrait pouvoir se faire. Met y a aussi un compilateur ASM qui à été dévelloppé pour les TI, donc se serait bien d'avoir les deux. Plus l'Azur (dérivé du C) de Thibault, ça pourrait faire 3 languge on-clac.

oui ca serait tip top. De toute facon tant qu'on a des compilos autant les rajouter! Chacun a ses qualites propres.

Mais le rpl est plus qu'un langage, c'est un os+ un langage.
C'est a dire qu'il gere de lui meme toutes les ressources de la calc..

Comme il est tolerant avec tout ce qui est code assembleur / code etranger, c'est un choix parfait a mon avis

Mais si ça plante quelque part, y a tous qui part en sucette.

ouaip. c'est un point a ameliorer sur une nouvelle implementation. Mais un proc avec un mode superviseur permet de controler c't'affaire, ce qu'on ne pouvait pas faire avec le saturn.

MAIS:
Un plantage en rpl ne signifie pas que toutes les donnees partent en couille. En principe, ca se solde par un reboot et la structure de fichier est intacte. (sauf bien sur si le programme foireux a ecrit dessus)

Miles se base sur un 68060, pour le moment. Donc je sais pas si y a un mode superviseur.

...
Bon je ne dit plus rien...

Heu si : le gettype(#l[1]) ça marche pas puisque gettype ne marche que sur des variables

Bon, ben alors c'est gettype(#(list[1]))
Et me dis pas que ça marche pas

heu suis desolé mais je vois mal comment gettype(#(list[1])) pourrais fonctionner...
l'indirection donne juste acces a la variable vdont le nom est contenu dans list[i]...
il faudrais que ce soit une string
enfin, je dis ca, a vrai dire j'en sais rien g pas essayé ^^

Quenalma > quand je lis tous ces posts sur les Hp, ca me laisse reveur...
(vais ptet m'acheter une hp moi ... )

Exactement, et je l'ai déjà dit :
gettype ne marche que sur une variable, et un élément de liste n'est pas une variable.

Donc ça marche pas.

(ouf on retourne un peu sur le sujet )

Fallait précisé dans le problème que ta liste ne contenait que des valeur !
Donc, faut faire :
gettype(#(string(list[1]))
Ca te renverra soit le type de fl[1] si il existe, soit NONE si fl[1] n'existe pas ou est une expression.

Je suis en train de réfléchir au proc pour voir dans la direction - quand même, j'ai changé d'avis - microcontrôleur. Et les 68000 ont tous un mode utilisateur et un autre superviseur. C'est la moindre des choses. Mais s'il faut protéger la structure des fichiers, alors ça change tout : plus d'accès direct à la VAT...
Au passage, la VAT de TI, elle est bien ou pas - je sais, je devrais mettre ça dans le topic en software, mais bon... -

Bob64>Bon, je me suis planter. J'ai utilisé des noms de variables sans faire exprés. Donc :
Try
gettype(#(string(liste[1])))->type (au cas où liste[1]est un nom de variable)
else
when(numerror=360,"STR","EXPR")->type
EndTry
Mais c'est pas meilleur

Miles>- je sais, je devrais mettre ça dans le topic en software, mais bon... -
C'est pas grave, Bob64 te cèdes le sien

MERCI BOB64!!
De toute façon, on va tous être des nouveaux newbies

faudrait aussi penser à du C On-calc...
Qd sortira GTC....

sinon, si je sais pas quoi faire une fois que j'aurai fini Krypton, et qu'il y a des gens pour m'aider (en particulier au niveau de l'ASM ), un compilo C ON-calc, ça serait marrant à développer...

Y a l'Azur de Thibault qui est trés proche du C

oui, je sais, mais il lui manque encore pas mal de trucs (les boucles notament, qui sont à la base de toute programmation structurée)
Il est certes proche du C, mais il est aussi différent...

Ah 3-4 instructions prés
Et il seras aidé par pas mal de monde, maintenant

Je penses aussi : son truc est rapide, pas mal foutu. (le seul truc qui me géne, c'est le '@' au lieu de '*' en C : le '@' est pas directement sur le clavier

Bah... 2nd+E au lieu de *
T'es vraiment un fainéant

et oui...
Le C est avant tout un language de fénéants !)

Il a été créé en se fiant àa ce point de vue, me semble-t'il...
(qd on voit certaines écritures de fou, super consises !)

Eh oui, c'est pour les fainéants, question de portabilité pour Unix à l'époque. Voir dans les labos de Berkeley.

c'est pour les fainéants, mais ça permet des écritures mortelles à écrire !
(mais moins à lire )

J'ai pas le contraire.

Des écritures comme: *(*(long**)0xc8+100)=*(long *)((void (*) (int,int))(*(void **)0xc8+1234)(2,3)); ...
( J'ai mis quelques nombres au hasard, donc n'essayez pas de compiler et exécuter cela.)
[edit]Edité par Kevin Kofler le 04-12-2001 à 22:46:40[/edit]

C'est mon topic

MacIntoc > Désolé... Mais ça peut pas marcher, car liste[1] n'est malheusement pas un nom de variable... En fait je voulais juste reconnaitre si liste[1] est un nombre ou une chaine

Et ne vous avisez pas de repartir sur des autres sujets