PpHd Le 09/02/2003 à 20:43 Nouveautes:
+ 2 bugs corriges.
+ Les fonctions basics peuvent utiliser les instructions reservees seulement aux programmes (besoin d'un testeur basic pour tester la stabilite, normalement c'est pil poil). Autre chose, la fonction tokenise sera executable sur une calc sans preos...
Link Le 09/02/2003 à 21:14 Je le prendrais plus pour retourner une valeur avec un programme que pour modifier une var dans une fonction...
C'est débile qu'un prog de puisse rien retourner, surtout à l'époque du C...
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
> Je le prendrais plus pour retourner une valeur avec un programme que pour modifier une var dans une fonction...
> C'est débile qu'un prog de puisse rien retourner, surtout à l'époque du C...
Malheureusement je pense que ça va être activé systématiquement... Ce serait pas mieux de faire un preos(true)/preos(false) ?
« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)
Link Le 09/02/2003 à 21:40 t'inquète pas je sais ce qui se passera si l'on détokenise la fonction:
AMS refusera simplement de la retokéniser, donc il n'y aura d'autre moyen de l'exécuter à nouveau que de retransférer la fonction tokénisée ou d'installer PreOS 0.65...
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
ou de changer l'extension par une extension perso FUNC (au lieu de celle par défaut dont je me souviens plus le nom), nan ???
Membre fondateur de la Ligue Anti-MacIntoc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins
de choses, jusqu'à ce qu'il connaisse absolument tout à propos de rien.
> J'ai teste les variables globales. Ca marche niquel ! Il n'y a vraiment AUCUNE raison technique pour qu'une fonction basic ne puisse pas utiliser les instructions.
> Le test de distinction des tokens entre fonction/programme se fait a la tokenisation, pas a l'execution
Je ne parle pas de raisons techniques. Evidemment qu'une fonction peut modifier des vars globales, mais le problème c qu'on peut avoir des bugs sans s'en rendre compte (oubli d'un Local).
Et sinon si c juste une protection à la tokenization et pas à l'exécution (hmm ça me paraît qd même bizarre puisque j'avais essayé y a qques temps de faire un util qui transformait un prog en fonction, et il me mettait une erreur d'exécution), pourquoi ne pas faire un prog séparé? Ce serait assez chiant que PreOS nous force à enlever cette protection contre les erreurs.
« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)
PpHd Le 10/02/2003 à 17:56 >mais le problème c qu'on peut avoir des bugs sans s'en rendre compte (oubli d'un Local).
Ca me parait un peu limite comme risque d'erreur, non ?
>pourquoi ne pas faire un prog séparé?
Parce que ca prend juste 6 octets dans PreOs. contre beaucoup plus dans un autre prog.
Ce que je propose, je le mets. Et si apres l'avoir longuement essaye, ca vous enerve je l'enleve.
(Et je ferais une directive de compilation pour l'enlever).
Uther Le 10/02/2003 à 18:03 >> Parce que ca prend juste 6 octets dans PreOs. contre beaucoup plus dans un autre prog.
>Moui, mais en même temps seuls les programmeurs basic l'utilisent
Pour 6 octets, je ne pense pas que ca gène les non utilisateur de Basic
Je parlais du "beaucoup plus", pas du 6 octets. La seule chose que je reproche à l'intégration dans PreOS c qu'on ne peut pas le désactiver, pas que ça prendrait de la place.
« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)
PpHd Le 10/02/2003 à 18:31 Mais faire une telle chose on-calc augmenterait de bien plus la taille. Tu ne preferes pas faire une version personnalisee ?
Uther Le 10/02/2003 à 18:34 On peut toujours recompiler preOS avec les option que l'on veut
)
)
.
