Où j'en suis ...

On me demande par message privé où j'en suis du développement et quand les fonctions avec retour de paramètre seront disponibles.
Voici ma réponse, que je rends publique car elle concerne tous les utilisateurs de Panoramic.

Citation :

Panoramic est pour moi un loisir, sans plus. Et je l'ai souvent dit sur le forum.
Je n'ai pas de planning, je code pour mon plaisir et pendant mes temps libres.

Le codage des fonctions va me prendre beaucoup de temps car Panoramic n'a pas du tout été conçu à l'origine pour cela. Il y a donc beaucoup de choses à modifier et se sera long.
Je ferai ça petit à petit, et un jour, les fonctions seront disponibles. Je n'ai pas de date à proposer. Tout ce que je peux dire, c'est que ce n'est pas pour tout de suite car l'ampleur de la tâche me fait hésiter à franchir le pas. Pour parler franc, j'ai listé ce qu'il faudrait faire (et la liste est longue), mais je n'ai pas encore eu le courage de m'atteler à cette tâche.

Lorsque j'ai commencé Panoramic, je voulais en faire un logiciel de création de jeux vidéo pour débutants, pour "programmeurs du dimanche".
C'est pour cela que j'ai choisi le langage Basic comme support, car le Basic a été créé à l'origine pour des non-informaticiens.

Je n'imaginais pas une seule seconde qu'un jour sur le forum on me demanderait des choses aussi sophistiquées que les handles (HANDLE, HANDLE_CANVAS, HANDLE_FORM), les adresses de variables pour utiliser des DLLs (ADR), la libération des variables (FREE), la récursivité. Ou dans l'éditeur, le repliement du code, l'autocomplétion, et j'en passe.
Maintenant, on me réclame à cor et à cri les procédures, les variables locales, les variables formelles et les fonctions.

Je m'écarte de plus en plus de l'esprit initial de Panoramic.
Ce que j'aimerai implémenter, c'est vraiment des choses qui permettent de pouvoir construire un vrai jeu vidéo: la transparence des SPRITES, leur superposition (les faire passer les uns sur les autres), leurs collisions, les animations d'ACTORs, les effets de feu, la pluie, la gravité, le vent, ...
Et je suis en train de perdre mon temps et mon énergie sur les variables locales ou les fonctions...

Bref, ce petit moment de blues étant passé, je ne peux te donner une date pour l'implémentation des fonctions. Cela se fera, mais je ne sais pas quand.

Cordialement.

Jack, merci pour ces éclaircissements.
J’imagine un peu l’ampleur de l’enjeu.
Alors, fais ce que tu veux, quand tu peux.
Pour moi, les choses sont maintenant claires, et je me contenterais du PANORAMIC actuel.

Merci Jack et c'est bien de nous dire ce que toi tu souhaites
Tu es le patron et tu nous a toujours encouragés à dire ce que l'on souhaitait alors on le fait sans vergogne et souvent tu fais peu de retour sur ça.
C'est pour ça que ton retour est très positif. Certes il ne va pas dans le sens des demandes actuelles, mais on s'en fout. Ce qui compte c'est comme pour Klaus, que tu fasses ce que tu as envie, tout comme nous.
Si tu veux mettre en standby les fonctions, fait le. Ne va surtout pas perdre l'envie de te faire plaisir.
Tu nous a dit que pour avoir var=fct(paramètres) cela ne te prendrait que quelques heures et nous sommes nombreux à penser que c'est suffisant.
Si on a de la récursivité possible, ce sera tant mieux. Si tu n'as pas envie de le faire, c'est parfaitement légitime et on s'en passera.
Si tu veux implémenter tout le nécessaire pour faire des jeux vidéos, je te suis. En plus j'en crève d'envie et crois moi, on te soullera aussi pour avoir plein de trucs sympa pour le faire.
Klaus a fait une fonction par exemple sur ma demande initiale pour utiliser le SAPI et ça marche très bien sur XP. Sous W7 c'est galère. Si un jour tu arrive à faire un truc simple qui marche sur toute les plateforme pour le faire, ce sera nickel, mais c'est secondaire.
Par contre si tu faits encore des dev sur la 3D ACTORS, etc ... ce serait bien d'avoir la possibilité d'avoir de la "gravité". C'est à dire que l'on puisse déclarer qu'un objet tombe jusqu'à ce qu'il arrive sur l'objet d'en dessous. Par exemple, ça permettrait de faire marcher un personnage sur un sol non droit. Bon aller je ne vais pas te saôuler déjà avec des demandes.
Juste un conseil, faits ce qui te plait et fait nous des retours sur nos demandes et tes envies, projets. Plus tu nous en dis plus on peut aller dans ton sens. Enfin c'est ma façon de voir

Je signe entièrement les déclaration de Jicehel. Il a tout dit, et bien dit.

Bonsoir Jack,
Je suis content que tu nous rappelle ce pour quoi tu as créé Panoramic, et ce pour quoi j'aime Panoramic et ce pour quoi je voudrais qu'il devienne! Quand tu me parles d'effet de feu, de vent, de pluie, d'animation je suis tout excité. C'est ce que j'attend depuis plus d'1 an, depuis que j'ai découvert Panoramic!
Eh oui, faute de possibilité de développer des jeux avec de nouvelles instructions spécifiques, je me rabat sur des jeux plutôt classique et en 2d. Genre mon poker ou le jeu de tarot.
Allez, j'avoue mon désir caché: J'aimerai me lancer dans la création d'un dessin animé totalement fait avec des décors 3d et des personnages 3d le tout géré en Panoramic! Ce serait génial!
Mais c'est toi le patron Jack, tu fais comme tu veux, et surtout ce qui t'arrange et à ton rythme. Nous on a rien à t'imposer! Déjà, je suis ravi de tout ce que je peux faire avec Panoramic!
A+

Bonsoir Jack,

Merci de nous tenir au courant. Comme tous mes prédécesseurs
je pense qu'il est important de ne pas perdre l'envie et donc de se faire plaisir.
Pour les fonctions, y a pas le feux ( faut que je digère les procédures ).
Je pense que la "fiabilisation" des Dim_Local sera déjà un très gros plus
et servira aussi la conception de jeux, pour les fonctions on verra bien
quand elles seront là.

Surtout ne perd pas " l'envie d'avoir envie "

Ne pas pouvoir définir des fonctions par le programmeur n’est nullement une chose insurmontable !
Tant qu’on peut définir des procédures on peut se passer de la définition des fonctions.

En effet et par définition :

Une fonction DOIT retourner à l’appelant une valeur ET UNE SEULE.
Une procédure PEUT retourner à l’appelant ZERO, UNE OU PLUSIEURS valeurs.


CONCLUSION : une fonction peut être remplacée par une procédure, la réciproque n’est pas vraie.

"...Tout à fait Thierry !" heu... Papydall

Edit :
Plus je me familiarise avec les "Sub" plus je leur trouve un côté sympa...
En ce moment, je regroupe mes petits outils pour les images (DIC et Coloramic )
en une seule appli ( "Picture Tools " je sais c'est pas original mais bon...)
et je m' aperçois qu' il me sera assez simple de rajouter des programmes à ces
deux là grâce aux "Sub".

Je sais que j'ai fait un caca nerveux à leur apparition mais bon...
il parait qu'il n'y a que les c.. qui ne changent pas d'avis
et comme je ne veux pas être l'un d'entre eux...

Bonjour à tous !
Je rejoint Jicehel sur ce qu'il a écrit. Perso les procédures me suffisent, les fonctions peuvent en partie être simulées et l'état actuel de Panoramic me convient parfaitement.
L'essentiel Jack, c'est que tu gardes ton envie de faire vivre ton bébé et que cela reste un plaisir pour toi et non pas une tache imposée.
Le seul petit reproche que je peux faire c'est que l'on a pas souvent de retour sur ta façon de voir les choses... mais comme tu l'as déjà dis: si tu prends ton temps pour répondre sur le forum, c'est du temps "perdu" sur le développement de Panoramic... personnellement , cela ne me dérangerai pas et puis cela calmerai certainement nos ardeurs et nos délires sur les demandes incessantes que l'on peut faire...

Bonjour.
Je rejoinds ce que dis Jicehel.
Je pose une question: ne peut-on pas pour tout le monde définir 3 variables de retour que chacun accepterait au départ pour faire les retour de procédure: pour variable entière, variable string et ...
Une question pour Klaus ou Nardo. On définir au départ les 3 variables dans les dim, et tous les sub seront passe-partout.

Bonjour tout le monde, bonjour Jack.

Ne gâche pas ton plaisir, fait ce que tu as envi de faire, et tant pis pour les functions.

Ce point a le mérite de nous projeter dans l'avenir, je considère faire parti des programmeurs du dimanche et grâce à ce point je sais maintenant qu'il faut faire avec l'existant (qui est déjà très performant).

J'ai une question, (mes camarades peuvent répondre): Peut-on utiliser les SUB() avec la dernière version sans risque ?

A+


PS: Cosmos m'a encore doublé (quand même ). Ton idée Cosmos est bonne: "Bonjour le partage". Je signe.

cosmos70 a écrit:

Bonjour.
Je rejoinds ce que dis Jicehel.
Je pose une question: ne peut-on pas pour tout le monde définir 3 variables de retour que chacun accepterait au départ pour faire les retour de procédure: pour variable entière, variable string et ...
Une question pour Klaus ou Nardo. On définir au départ les 3 variables dans les dim, et tous les sub seront passe-partout.

Chacun fait comme il l'entend, a sa convenance...
pour ma part, pour la variable de retour, je l'a définie de cette manière:

Code:

SUB NomFonction(x)
  IF VARIABLE("NomFonction_retour")=0 THEN DIM NomFonction_retour
  ...
  NomFonction_retour = .....
END_SUB

Jette un coup d'oeil sur mon Webdav : Panoramic\Lib\LibStr.bas

Mais je suis toujours en train de chercher une autre solution:

Si je prend ma fonction "StrSplit", actuellement elle me renvoie un tableau de 2 valeurs.
StrPlit("Ma ligne|de test|final","|")
je me retrouve avec : "Ma ligne" et "de test|final"

dans ce cas un DLIST avec dedans :
"Ma ligne"
"de test"
"final"
serait peut être plus approprié...

bref je cherche encore une "manière" de coder les fonctions...

Bonjour,
Moi je vous laisse proposer. Je ne suis pas un spécialiste de la programmation, mais je pense qu'il y ait possible de définir pour tout le monde le même principe, que tout le monde accepterait.
Je pense qu'il faudrait aussi que le sub servant de fonction, ait un signe de reconnaissance dans le nom, comme sub F_ suivi du nom. Ainsi si un jour les fonctions apparaissent, on peut faire un programme de conversion pour transformer un sub en fonction.

Sur ce, je retourne dans mon coin.

Jean Claude a écrit:

...J'ai une question, (mes camarades peuvent répondre): Peut-on utiliser les SUB() avec la dernière version sans risque

Oui, mais tu n'est pas obligé, si les SUB() te gêne, tu peux continuer à programmer comme avant et aborder les SUB petit à petit...

Les sub ne sont pas encore vraiment au point, le plus simple c'est de procéder par tâtonnement et de vérifier si les SUB que tu écris font bien ce que tu leur demande...

Je pense qu'il ne faut pas chercher à imposer une règle de programmation ou un nommage des fonctions : cela dépendra des besoins.

par exemple une fonction peut renvoyer une valeur, un tableau, une DLIST, etc... comment définir dans ce cas une "règle" ?

Jack : ton langage est trop souple !!!

L'idée de Cosmos70 me parait bonne. En Delphi, à l'intérieur d'une fonction, il y a une variable définie implicitement qui s'appelle RESULT à laquelle on affecte le résultat. Alors, afin d'éviter à avoir des déclarations de variables globales à faire, je propose la variante suivante:

1. Une procédure qui doit servir de fonction, sera définie de la manière suivante:

Code:

sub test()
if variable("test_result")=0 then dim test_result
test_result = 1.23
end_sub

Ainsi, elle définit elle-même sa variable de résultat, et on peut l'appeler autant de fois que nécessaire sans conflit. A l'extérieur, la variable est disponible

2. On appelle la procédure comme d'habitude, sachant qu'immédiatement après, la variable de retour portant le nom de la procédure suivi de "_result" est disponible.

3. les noms des procédures peuvent être complétés par $ et % ce qui permet des variables de retour du même type !

Regardez ce petit code qui marche parfaitement:

Code:

test$()
print test_result$
test()
print test_result
test%()
print test_result%
end

sub test$()
if variable("test_result$")=0 then dim test_result$
test_result$ = "abs"
end_sub

sub test()
if variable("test_result")=0 then dim test_result
test_result = 1.23
end_sub

sub test%()
if variable("test_result%")=0 then dim test_result%
test_result% = 17
end_sub

C'est tout à fait génial de la part de Jack d'avoir permis des noms de procédure terminés par % ou $. Cela nous permet de créer des pseudo-fonctions correctement !

An employant cette technique, on pourra s'échanger des pseudo-fonctions sans avoir de déclarations à faire dans le programme principal et avoir accès à la valeur de retour dans des conditions claires.

Une dernière règle à respecter: tous les labels à l'intérieur d'une procédure ou pseudo-fonction devront être préfixés par le nom de la fonction, et déclarés à l'intérieur de la procédure par une commande label conditionnée par if label(...)=0 then . Plus de conflits.

Donc on est tous d'accord !
Ça change pour une fois !!
Je n'avais pas fait le test d'un nom de procédure suivi de son type ($,%) mais si tu dis que ça marche, c'est clair que l'on va gagner en lisibilité.

Ce qui me gêne en peu c'est que les parenthèses servent aussi bien pour les procédures que pour les tableaux...

Donc je ne sais pas par exemple comment jack va faire plus tard pour les fonctions :
print test(1)
- affichage de la valeur dans le tableau test
- affichage du résultat de la fonction test
????

Un vrai casse-tête...

Ca doit faire partie des raisons pour lesquelles il n'a pas envie de s'y mettre, entre autre.

Si Jack accepte d'implémenter la version basique
variable = fonction(paramètres)
alors ce problème ne se pose pas.

Si plus tard, Jack envisage d'implémenter les fonctions sous un aspect plus général, il faudrait définir des règles. Par exemple, interdire la définition d'une procédure test() si un tableau test() existe, et inversement. L'autre solution se situerait au niveau de la syntaxe, en remplaçant les parenthèses contre des [..], pour les procédures et fonctions. Ce serait plus logique de le faire pour les tableaux, mais on n'est plus dans l'esprit Basic et on n'est plus du tout compatible avec les programmes existants.

Je pense que des règles d'exclusivité permettent de gérer cela de façon satisfaisante. On procède alors de la manière suivante:

actuellement, si dans une expression, un terme du genre test(...) ne fait pas référence à une variable définie, il y a une erreur.

Il faudrait élargir cela de façon à chercher la procédure test(...) si le tableau test(...) n'est pas défini. Et si la procédure n'existe pas, alors il y a erreur.

Nardo a écrit:

Oui, mais tu n'est pas obligé, si les SUB() te gêne, tu peux continuer à programmer comme avant et aborder les SUB petit à petit...

Merci pour ta réponse, je suis rassuré. Dans un premier temps je compte utiliser SUB() pour limiter le nombre de label et dim, donc je vais m'y mettre....


@Klaus

Code:

test$()
print test_result$
test()
print test_result
test%()
print test_result%
end

sub test$()
if variable("test_result$")=0 then dim test_result$
test_result$ = "abs"
end_sub

sub test()
if variable("test_result")=0 then dim test_result
test_result = 1.23
end_sub

sub test%()
if variable("test_result%")=0 then dim test_result%
test_result% = 17
end_sub

ça me convient parfaitement, (Merci Cosmos pour cette bonne idée)

A+

@Jack:
Je pense avoir trouvé un bug avec cette version 0.24i2 !

On ne peut pas placer une procédure dans un fichier ajouté par #INCLUDE. Pas d'erreur sur le #INCLUDE, mais la procédure n'est ensuite pas reconnue. Peux-tu y faire quelque chose ? Ce serait quand-même important qu'un puisse inclure des procédures toutes faites de cette manière !

Klaus a écrit:

sub test()
if variable("test_result")=0 then dim test_result
test_result = 1.23
end_sub

Je suis d'accord pour test_result = ...
mais je pense que la procédure on devrait être reconnaissable en ajoutant un préfixe.
J'avais proposé F_ cela me parait le plus simple, mais vous pouvez avoir un autre avis.
En mettant un préfixe, on sait que c'est teste_result qui est attendu, sans aller plus loin, alors qu'autrement un lisant un vieux listing avec un appel à une pseudo-fonction, on ne le sait pas.

C'est une idée Pan59,
Ca fonctionne mais tu limites l'affectation de ta fonction en faisant un test sur le nom des variables (xx%,zz99% et kk%).
Par contre si tu définis par exemple une variable de retour de fonction, tu peux ensuite l'affecter par la suite à n'importe qu'elle variable.
Exemple :

Code:

I2(lower$(chaine$),"comme") : ' Appel à la procédure
xx% = I2_return% : ' et après tu récupères le résultat dans la variable qui sert de retour
' la suite.... ;)
I2(lower$(chaine$),"d'habitude")
kk% = I2_return%  : ' La variable de retour est toujours la même
END
SUB I2%(param1$, param2$)
  IF VARIABLE("I2_return%")= 0 THEN DIM I2_return%
  I2_return% = instr(param1$,param2$)-1
END_SUB

@cosmos :
Un truc dans ce genre ?

Code:

DIM EMail$ :  EMail$ = "nardo.26@truc.fr"

F_RINSTR%(Email$,".")
print RINSTR_return%
END
' ------------------------------------------------------------------------------
' Renvoie la position d'une occurrence de texte dans une autre en partant de la droite
' print INSTR(EMail$ , ".")  renvoie 6
' print RINSTR(EMail$ , ".") renvoie 14
' ------------------------------------------------------------------------------
SUB F_RINSTR%(A$,B$)
  IF VARIABLE("Rinstr_return%")=0 THEN DIM Rinstr_return%
  DIM_LOCAL i%:i%=0
  IF INSTR(A$,B$)<>0
    FOR i%=LEN(A$) TO 1 STEP -1
      IF INSTR(RIGHT$(A$,LEN(A$)-i%+1),B$)<> 0 THEN EXIT_FOR
    NEXT i%
  END_IF
  Rinstr_return% = i%
END_SUB

Bonjour Nardo.

OK pour l'affectation de la variable de retour après chaque appel.

J'y avais pensé, mais à ce moment là, il y a obligation d'ajouter cette ligne après chaque appel à la fonction.

Le fait d'ajouter l'affectation du résultat à l'intérieur de la procédure réduit énormément mon code.

Oui Pan59,
mais que tu rajoutes une ligne après l'appel ou que tu fasses le test dans la procedure, je ne vois pas de grande différence.
Il y en a une de taille quand même :
si tu utilises ta procedure par exemple 20 fois dans ton programme et à chaque fois pour des variables différentes (pas de bol hein ? )
tu va te retrouver avec 20 lignes de test dans la procédure...
Au final pour 2, 3 ligne de traitements, tu vas avoir XX lignes de test....
Je ne suis pas sûr que tu y gagnes en taille de code et en lisibilité...

EDIT : Je parle par exemple d'une procédure "fonction" généraliste comme RINSTR...