Connaissez-vous réellement le javascript? - Page 4

(pourquoi pas coder une VM Javascript pour TI? y'en a un qui a fait lua, alors pkoi pas)

le lua sur ti68k c'est efficace (sensiblement plus rapide que le basic) ou pas ?

jamais testé, honnêtement, mais pourquoi pas?

oui j'y ai pensé. y a un gars qui a porté spidermonkey sur 68k (atari) en plus, donc ca doit être faisable. Mais il l'a pas porté pour gcc il l'a porté pour un autre compilo.

bon, d'après ce vieux topic, lua89 serait plutôt lent, dommage.

squalyl (./91) :
(pourquoi pas coder une VM Javascript pour TI? y'en a un qui a fait lua, alors pkoi pas)

Avons-nous vraiment besoin d'un autre langage interprété qui rame? Le TI-BASIC ne suffit-il pas?

l'idée serait justement d'avoir un langague interprété puissan et qui ne rame pas trop. Avoir un autre langague qui rame c'est en effet avec peu d'interet.

boah, juste pour le fun

Le port pour amiga:
read me:
http://ftp.icm.edu.pl/packages/aminet/dev/lang/SpiderMonkey-js-os4-src.readme

l'archive:
http://ftp.icm.edu.pl/packages/aminet/dev/lang/SpiderMonkey-js-os4-src.lha

quelqu'un de motivé pour le compiler pour TI ? Kevin? squalyl?

perso, non (surtout que ça doit faire plus de 64 ko et que je sais pas dézipper un lha )

A vrai dire, je comprend toujours pas ton point de vu Kevin, POURQUOI un langage interprété devrai FORCEMENT ramer ? Que ça soit plus lent que de l'ASM/C je pent comprendre, mais bon, on peut faire LARGEMENT mieux que le TI-Basic...

js> function f(){ for(var i=0;i<45;i++){ print(i); } }

traduit en bytecode donne:

js> dis(f);
main:
00000:  zero
00001:  setvar 0
00004:  pop
00005:  getvar 0
00008:  uint16 45
00011:  lt
00012:  ifeq 33 (21)
00015:  name "print"
00018:  pushobj
00019:  getvar 0
00022:  call 1
00025:  pop
00026:  varinc 0
00029:  pop
00030:  goto 5 (-25)
00033:  stop

Source notes:
  0:     1 [   1] decl     offset 0
  2:     4 [   3] for      cond 7 update 21 tail 25
  6:    22 [  18] xdelta
  7:    22 [   0] pcbase   offset 7

edit: je poste ça pour dire qu'avec un VM correct, y a moyen d'avoir un interpreteur utilisable meme sur TI.

le plus dur étant de faire tenir le compilo dans la calcu

Uther (./97) :
l'idée serait justement d'avoir un langague interprété puissan et qui ne rame pas trop. Avoir un autre langague qui rame c'est en effet avec peu d'interet.

Ya déja le GFA-Basic.

il est encore plus rigide que le Ti-Basic, ça ne va vraiment pas dans le même sens que du JavaScript ou du LUA

eh ben, je pensais que le javascript pouvais bien plus que cela... si même l'héritage on est obligé de se le cogner à la main...
désolé, mais là il est pas à son avantage le js. (de mon point vu de codeur java).

+1

C'est parce que tu es trop dans la philosophie OO statique. En Js, chaque instance est mutable, ça te laisse plus de maniabilité. Tu peux simuler l'héritage, quand on connait l'héritage classique comme en java ou C++ ca peut choquer, mais dis toi que c'est plutot une méthode qui permet d'ajouter des attributs à plein d'objets.

Vous avez vraiment pas confiance en vous au point de vouloir que le compilo vérifie un max de choses...

c'est pas son but

ne programme jamais dans l'embarqué toi!

T'inquiete de tte facon je vais pas faire du script sur de l'embarqué... (sauf cas spécial: par exemple un moteur TileEngine qui balance des événements onCollide à des objets javascript pourrait fonctionner correctement sur TI)

Y'a un interpréteur JS sur TI

nop, mais si tu lis juste avant, y'a kékun qui a porté spidermonley sur amiga, donc onur pensait que c'était faisable sur ti

Bah "faisable", comme tu as dit, j'avais quand meme des doutes sur la taille du prog. Mais déjà le mec a réussi à compiler pour le processeur quoi.

Ceci dit, si c'était trop gros et qu'on ne pouvait plus dormir à cause de l'absence d'interpreteur js sur ti, on pourrait s'amuser à couper spidermonkey en 2, un compilateur et un vm (c'est le cas pour gfa-basic je crois).

elle ferait 64k la vm tu crois?

Oui... enfin vu la gueule du bytecode ca me semble pas abérrant qu'il fasse moins de 64k, si?

N'oublie pas les fonction externes genre "print", il va justement les binder avec ce que tu as défini en utilisant spidermonkey, ils font pas partie du VM.

aucune idée.

onur (./109) :
C'est parce que tu es trop dans la philosophie OO statique. En Js, chaque instance est mutable, ça te laisse plus de maniabilité. Tu peux simuler l'héritage, quand on connait l'héritage classique comme en java ou C++ ca peut choquer, mais dis toi que c'est plutot une méthode qui permet d'ajouter des attributs à plein d'objets.

c'est pas que ca me choque, c'est juste que le javascript ne support pas l'héritage. On peut le simuler, de la même manière qu'on peut aussi le similer en C. Mais c'est toujours plus chiant de le faire à la main.
De ce que je connais du javascript, je trouve que son seul avantage est l'access facile à la réflexion (du simple code javascript permet d'introspecter une structure de donnée javascript). Et pareil, on peut aussi être fait (simulé) en Java, mais c'est à la main, et c'est chiant.

Vous avez vraiment pas confiance en vous au point de vouloir que le compilo vérifie un max de choses...

genre quand tu codes jamais de bug ?
je préfère que ce soit le compilo plutot que moi ou l'utilisateur qui teste.

Suffit d'utiliser de vrai langages pour avoir l'héritage, l'introspection & co ^^

qui sont ?