version instantanée V 0.9.28i17 du 08/04/2018

La version instantanée V 0.9.28i17 du 08/04/2018 est disponible au téléchargement.

Elle apporte 2 améliorations:
- il est possible d'utiliser des tableaux à 3 dimensions
- l'ordre des octets de PEEK16() et PEEK32() a été inversé

Un grand merci Jack !

Je télécharge de suite !

Bonsoir Jack !

Le caption 0 par défaut, indique l'ancienne version i16 de Panoramic.

Oups...
Il y a eu un petit problème à la génération.
J'ai corrigé. C'est la bonne version qui est maintenant disponible.

Merci Jack !

1er test effectué avec succès !

Par contre il y a toujours le même bug au démarrage. Est ce que tu as réussi à voir d'où cela provient ?

Pour info si cela peut aider à trouver le problème :
- Lorsque je modifie le code et que j'exécute directement, 9 fois sur 10 j'ai le plantage.
- Mais si je prends le temps de sauvegarder avant et que j'exécute ensuite, je n'ai quasiment plus le plantage !

Je ne sais pas si tout le monde rencontre ce problème ?

Bonjour à tous !

Minibug a écrit:

Je ne sais pas si tout le monde rencontre ce problème ?

Oui, Minibug, j'ai constaté le même problème qui perdure depuis plusieurs générations de Panoramic.

Je valide le message du plantage et je continue mon travail comme si de rien n'était.

Bonne programmation !

Ca fonctionne parfaitement pour PEEK16/32, mais le problème subsiste pour POKE16/32

Des tableaux à 3 dimensions, génial !
Merci, Jack !

Bonnes nouvelles. Bravo et merci Jack

Ce code affiche une erreur (30)Array index overflow or underflow. Line : 7 sur un tableau déclaré en local.

Par contre, il  fonctionne parfaitement sur les versions antérieures à la 28i17.

Code:

test()
end
rem ============================================================================
SUB test()
    dim_local a(10),i
    for i = 0 to 10
        a(i) = rnd(100)
    next i
    for i = 0 to 10 : print a(i) : next i
END_SUB
rem ============================================================================

Edité suite à l'humour de maître Klaus posantérieures

Citation :

Par contre, il fonctionne parfaitement sur les versions postérieures à la 28i17.

Super ! Tu as déjà les versions postérieures ! Tu es un privillégié, ou un voyageur dans le temps !

Maître Klaus, réflexion faite, je reviens du post vers l’ant : je dispose des versions postantérieures; quant aux postérieurs , mon voyage dans le temps s’est soldé par un échec !

Bon, j’ai rectifié mon tir dans mon précédant post.
Ceci dit (et écrit) cela n’empêche pas qu’il y ait un bug dans cette version (la 28i17).

silverman a écrit:

Ca fonctionne parfaitement pour PEEK16/32, mais le problème subsiste pour POKE16/32

Pour mettre tout le monde d'accord, je vais coder 4 commandes:
POKE_NORMAL : après cette commande, POKE16 A,V écrira aux adresses A (poids fort) et A+1, et POKE32 A,V écrira aux adresses A (poids fort) et A+1, A+2, A+3.
POKE_REVERSE : après cette commande, POKE16 A,V écrira aux adresses A (poids faible) et A+1, et POKE32 A,V écrira aux adresses A (poids faible) et A+1, A+2, A+3.
PEEK_NORMAL : après cette commande, PEEK16(A) retournera 256*(contenu de A) + (contenu de A+1), et PEEK32(A) retournera 16777216*(contenu de A) + 65536*(contenu de A+1) + 256*(contenu de A+2) + (contenu de A+3).
PEEK_REVERSE : après cette commande, PEEK16(A) retournera 256*(contenu de A+1) + (contenu de A), et PEEK32(A) retournera 16777216*(contenu de A+3) + 65536*(contenu de A+2) + 256*(contenu de A+1) + (contenu de A).

Jack a écrit:

Pour mettre tout le monde d'accord, je vais coder 4 commandes:
POKE_NORMAL : après cette commande, POKE16 A,V écrira aux adresses A (poids fort) et A+1, et POKE32 A,V écrira aux adresses A (poids fort) et A+1, A+2, A+3.
POKE_REVERSE : après cette commande, POKE16 A,V écrira aux adresses A (poids faible) et A+1, et POKE32 A,V écrira aux adresses A (poids faible) et A+1, A+2, A+3.
PEEK_NORMAL : après cette commande, PEEK16(A) retournera 256*(contenu de A) + (contenu de A+1), et PEEK32(A) retournera 16777216*(contenu de A) + 65536*(contenu de A+1) + 256*(contenu de A+2) + (contenu de A+3).
PEEK_REVERSE : après cette commande, PEEK16(A) retournera 256*(contenu de A+1) + (contenu de A), et PEEK32(A) retournera 16777216*(contenu de A+3) + 65536*(contenu de A+2) + 256*(contenu de A+1) + (contenu de A).

Et pourquoi pas POKE / POKER et PEEK / PEEKR pour simplifier la saisie ?

et l'erreur sur un tableau déclaré en local ?

Je trouve que vous pressez beaucoup Jack qui n'a que son temps libre à consacrer à Panoramic, et encore... à supposer que Panoramic remplisse tout son temps libre ce que je ne lui souhaite pas.

Je pense qu'un peu de patience et de retenue serait de mise.

Le codage des tableaux à 3 dimensions a provoqué effectivement un effet de bord: si on déclare un tableau dans un SUB par DIM_LOCAL, il y a une erreur à l'utilisation de ce tableau.
Je regarde ce problème dès que possible et je le corrige.

@Klaus: c'est vrai qu'il y a une avalanche de nouvelles demandes ces derniers jours. Je vais faire le tri dans tout ça et coder ce qui me parait important. C'est toujours intéressant d'avoir des nouveaux utilisateurs qui font des demandes car elles sont fondées pour la plupart.

Coder la famille des PEEK/POKE_REVERSE est une très bonne idée, j'y voit là un moyen de rapide de "crypter" des fichiers, ou tout du moins rendre leur lecture plus difficile.