Version instantanée du 8 septembre 2012 PANORAMIC V 0.9.24i1

@ Klaus,

Comme quoi, le fait que la variable soit globale ou locale,
on a grand intérêt à ne pas leurs donner les mêmes noms
sous peine de grand foutoir, les programmes deviendraient vite
illisibles pour quelqu'un d'autre que le concepteur et encore,
celui ci pourrait s' y perdre aussi.

Jack a écrit:

Si tu n'as de paramètres, il n'y a pas de parenthèses.
La définition est alors:
sub sspg
- - -
end_sub

et l'appel se fait par le nom donné, ici sspg

Je viens de constater que la déclaration et l’appel de SUB sans paramètres NE MARCHENT PAS !
Il faut absolument au moins un paramètre, même bidon, entre parenthèses.

Code:

dim titre$ : titre$ = "L'esthétique polaire"
dim pi : pi = 4*atn(1)
dim a,b,x,y,xc,yc,n,p,r,x0,y0

init(a) : go(a) : ' supprimer le paramètre (a) et ça ne marche pas
end
' ***************************************************
sub init(a)    : ' supprimer le paramètre (a) et ça ne marche pas
  width 0,700 : height 0,700
  caption 0,"Papydall vous présente        " + titre$
  n = 24 : xc = 350 : yc = 350 : r = 300 : p = 2*pi/n
  print "    LE NAPPERON DE DENTELLE"
end_sub
' ***************************************************
sub go(a)      : ' supprimer le paramètre (a) et ça ne marche pas
for a = 0 to 2*pi step p
  x0 = xc + r*cos(a) : y0 = yc + r* sin(a)
  for b = a+p to 2*pi-p step p
      x = xc + r * cos(b) : y = yc + r * sin(b)
      2d_pen_color x/3, 30+y/4, x/y : 2d_line x0,y0,x,y
  next b
next a
end_sub
' *****************************************************

@ygeronimi

Si les variables sont locales, tu ne te soucies absolument pas de leurs identificateurs.
Dans ton programme principal, tu peux déclarer tes variables comme bon te semble.
Tu peux, par exemple charger un autre programmeur pour t’écrire des procédures qui réalisent telle ou telle choses, sans connaitre les noms des variables qu’il a utilisé. Ça c’est l’une des qualités des variables locales.

Tu peux coder une fois pour toute différentes procédures réalisant des tâches précises et les intégrer dans n’importe quel autre programme et ça MARCHE.
N’est pas beau ça ?

J'en suis pas encore à télécharger, j'ai autre chose à faire.
Qu'est-ce que ça donne free dans la procédure? ça marche? Ne deviennent-elles pas locales à partir de là? (en dépannage)

Les testes je les ferais bien plus tard, d'ailleur je vous lis.

Chez moi ça marche sans paramètre avec le code suivant:

Code:

dim titre$ : titre$ = "L'esthétique polaire"
dim pi : pi = 4*atn(1)
dim a,b,x,y,xc,yc,n,p,r,x0,y0

init() : go()
end
' ***************************************************
sub init()
  width 0,700 : height 0,700
  caption 0,"Papydall vous présente        " + titre$
  n = 24 : xc = 350 : yc = 350 : r = 300 : p = 2*pi/n
  print "    LE NAPPERON DE DENTELLE"
end_sub
' ***************************************************
sub go()
for a = 0 to 2*pi step p
  x0 = xc + r*cos(a) : y0 = yc + r* sin(a)
  for b = a+p to 2*pi-p step p
      x = xc + r * cos(b) : y = yc + r * sin(b)
      2d_pen_color x/3, 30+y/4, x/y : 2d_line x0,y0,x,y
  next b
next a
end_sub
' *****************************************************

@papydall

Citation :

Tu peux, par exemple charger un autre programmeur pour t’écrire des
procédures qui réalisent telle ou telle choses, sans connaitre les noms
des variables qu’il a utilisé. Ça c’est l’une des qualités des variables
locales.

Si j'ai bien compris, les variables utilisées à l'intérieur de la SUB ne sont pas locales mais globales, c'est à dire qu'elles doivent être déclarées:
- soit par un DIM dans le programme principal
- soit par un DIM dans le SUB lui-même, auquel cas il faut les libérer par FREE avant le END_SUB, sous peine d'avoir une double déclaration à l'appel suivant.
Finalement ça ne change rien par rapport aux s/p actuels, sauf pour les variables qui sont entre parenthèses de la ligne SUB, qui elles ne sont pas déclarées (donc locales)

Et donc l'autre programmeur ne peut pas coder dans son coin sans tenir compte des variables déjà utilisées dans le programme principal, sous peine de collisions (double déclarations, etc.).
Les variables locales, ce sera pour une autre fois.

C'est avec une grande joie que je découvre à l'instant une nouvelle version de Panoramic , et vu les commentaires il semble que çà usine dur dur chez les panoramiciens.

Je ne pourrais pas tester avant lundi, mais je suis déjà impatient d'y aller....

Merci Jack pour le boulot que tu fournis (même si pour toi c'est un plaisir, ce que je crois)...



PS: c'est très exceptionnel que j'intervienne à une heure aussi tardive, c'est un signe.... Dieu (je veux dire le dieu Panoramic) est avec nous..........

bon maintenant

Par contre Papydall, pour "l'esprit" de procédures, j'aurais plutôt écrit le programme comme ça:

Code:

dim titre$ : titre$ = "L'esthétique polaire"
dim pi : pi = 4*atn(1)
dim xc,yc  : xc = 350 : yc = 350  : ' Décalage en x et en y
dim n,p : n = 10                  : ' Valeur de départ pour le nombre de points de la figure
dim r  : r = 300                  : ' Rayon du tracé

width 0,700 : height 0,700
while n < 40
  cls : p = 2*pi/n : go(p,r,xc,yc) : n=n+2 : wait 1000
end_while
caption 0,"Papydall vous présente        " + titre$ + "        terminé"
wait 2000
end

sub go(pas,rayon,x_c,y_c)
dim x0, y0, a, b, x, y
for a = 0 to 2*pi step pas
  caption 0,"Papydall vous présente        " + titre$ + "        n="+str$(n)
  x0 = x_c + rayon*cos(a) : y0 = y_c + rayon* sin(a)
  for b = a+pas to 2*pi-pas step pas
      x = x_c + rayon * cos(b) : y = y_c + rayon * sin(b)
      2d_pen_color x/3, 30+y/4, x/y : 2d_line x0,y0,x,y
  next b
next a
free x0: free y0 : free a : free b : free x : free y
end_sub

Et puis je rajoute car je ne sais même pas si je l'ais fait: Bravo et merci Jack. C'est je pense une grande avancée

@JL35
J’ai écris :

papydall a écrit:

Si les variables sont locales, tu ne te soucies absolument pas de leurs identificateurs.
Dans ton programme principal, tu peux déclarer tes variables comme bon te semble.
Tu peux, par exemple charger un autre programmeur pour t’écrire des procédures qui réalisent telle ou telle choses, sans connaitre les noms des variables qu’il a utilisé. Ça c’est l’une des qualités des variables locales.

Or actuellement ce n’est pas le cas, hélas ! Les variables ne sont pas locales

@Jcehel
Bien vu : mais les parenthèses sont obligatoires !
Pour la modification du programme, c’est bien.
Pour l’esthétique, les polygones doivent être pairs, donc modifie n à la ligne 9 : n = n + 2 au lieu de n = n + 1



Voici un petit exemple pour illustrer ce qui est globale de ce qui est locale

Code:

dim a,bidon1 , result
bidon1 = 5 : ' variable globale
test(a) :' l'appel de la procédure se réalise,magré la non concordance des paramètres
message "resultat = " + str$(result):' on recupère ici le resultat calculé dans la procédure
' la variable bidon1 retrouve sa valeur initiale à la sortie de la procédure
message "bidon1 en dehors de la procédure = " + str$(bidon1)
' la variable bidon2(locale à la procédure test) provoque une erreur en dehors
' de la procédure.
message "bidon2 en dehors de la procédure = " + str$(bidon2)
end
' ***************
sub test(bidon1,bidon2,bidon3)
 bidon1 = 1 : bidon2 = 2 : bidon3 = 3 : ' ces 3 variables sont locales
 ' toute modification de leurs valeurs ne se repercute pas en dehors de la procédure
 message "bidon1 dans la procédure = " + str$(bidon1)
 message "bidon2 dans la procédure = " + str$(bidon2)
 message "bidon3 dans la procédure = " + str$(bidon3)
 result = bidon1 + bidon2 + bidon3
end_sub
' ***************

Il sera souhaitable voir très utile de pouvoir déclarer dans la procédure SUB (et ultérieurement dans la fonction FUNC ou FUNCTION ou quelque chose d’approchant) des variables par DIM (ou autre) qui soient réellement locales : donc leurs ‘visibilités’ ne soient actives qu’à l’intérieur de ces procédures/fonctions.

Tout à fait d'accord, une directive qui fasse un free automatique de cette variable quand on arrive au end_sub. Je pense qu'un LOCAL NomDeLaVariable serait assez explicite ?
Ce local remplacerait le DIM NomDeLaVariable ....
mais le Free NomDeLaVariable serait automatique

Je rêve d’une procédure et d’une fonction à peu près comme ceci :
On déclare une procédure par le mot réservé SUB, suivi du nom de la procédure suivi entre parenthèses des arguments formels transmis par valeur et/ou par adresse.
A l’intérieur de la procédure, on déclare, en premier les variables locales. Ces variables peuvent avoir ou non les mêmes noms d’autres variables déclarées globales ou locales dans une autre procédure. La déclaration au sein de la procédure se fait par un mot réservé (exemple LOCAL ou PRIVATE ou VAR ou autre chose.
Viennent ensuite les instructions, et on termine par END_SUB.
L’appel de la procédure se fait par : Identificateur (….)
On doit rigoureusement transmettre le même nombre avec les mêmes types d’arguments.
Lorsque la procédure arrive à END_SUB, elle libère automatiquement les variables locales.

Code:

SUB Identificateur(Arg1,Arg2,Arg3,…,Adr(Arg01),Adr(Arg02),Adr(Arg03),...)
LOCAL ou PRIVATE ou VAR  V1,V2,V3,…
.....
.....
END_SUB

Pour la fonction, (FUNCTION ou FUNC ou simplement FN) la déclaration se fait à peu près comme la procédure avec la différence fondamentale qu’une fonction doit OBLIGATOIREMENT retourner une valeur, ce qui n’est pas systématique pour une procédure.
Le retour de la valeur se fait par le nom même de la fonction.

Code:

FUNCTION Identificateur(Arg1,Arg2,Arg3,…,Adr(Arg01),Adr(Arg02),Adr(Arg03),...)
LOCAL ou PRIVATE ou VAR  V1,V2,V3,…
....
....
Identificateur = .....
END_FUNCTION

@ Jack,

Je pensais que j'allais tant bien que mal finir par comprendre quelque chose
à cette nouvelle mouture mais je m' aperçois avec regret que c'est un vrai pastis
de type de variables. Que je ne sais plus qui est où et qui fait quoi, parfois j'ai même
l'impression que nous ne parlons pas le même français tellement l'histoire
est brouillonne. Je n' ai aucune formation en programmation et tout ce que sais à ce jours
je le dois à des lectures fastidieuses et à la générosité dans le partage de leur savoir
des panoramiciens .
Je crois que tant qu'une doc clair, net et précise, comme tu en as le secret, n' est pas disponible,
je vais m'en tenir à la version précédente avec nos bon vieux gosub qui avait l'avantage d'être
simple.
Je vais me faire des ennemis en disant çà mais si les demandes d' améliorations consistent à
cloner des langages devenus compliqués à force de simplifications en tout genre, je les invites à ce
servir de ceux ci mais de grâce laissez Panoramic abordable aux néophytes .



Edit : Il parait que nous sommes 175 inscrits...Nous sommes seulement 10 ou 12 à faire vivre ce forum.
Il n'est pas interdit au 165 autres de donner une fois de temps en temps leur avis...

j’ai fait un petit tour chez mon ami GOOGLE, j’ai revu mes anciens cours et voici le résultat.

Les variables globales

Avantages
Les variables globales pouvant être utilisées partout dans un programme sans avoir été transmises préalablement en paramètres de fonction, leur utilisation simplifie la conception et l'écriture de programme.

Inconvénients
L'utilisation de ces variables rend plus difficile la compréhension d'un programme ainsi que son débuggage et sa modification ultérieure.
Lors de la recherche d'erreurs de programmation, lorsqu'une variable globale contient une information erronée, il est plus difficile de trouver la source de l'erreur, car la variable a pu être modifiée dans n'importe quelle partie du programme.
Lors des modifications apportées à un programme, il est complexe de modifier le traitement d'une variable globale parce qu'il faut comprendre tout le programme pour savoir comment la variable était traitée dans le programme originel, étant donné que la variable peut être modifiée depuis n'importe quelle fonction.

Lors de l'écriture de bibliothèques logicielles, les variables globales empêchent la réentrance si elles sont mal utilisées. C'est pourquoi il est recommandé de ne pas les utiliser pour l'écriture de bibliothèques.

Recommandations
Les inconvénients des variables globales étant plus grands que ses avantages, il est déconseillé d'utiliser ce type de variables dans la conception de programmes, et de leur préférer l'utilisation de variables locales

Malheureusement, certains programmeurs ont recours à ces variables globales pour accélérer les premières phases du développement d'un programme. Ils en paient souvent le prix lorsque vient le temps de corriger leur programme ou de le modifier pour l'adapter aux nouveaux besoins.

Portée des variables locales
Les variables locales ne sont connues qu’à l’intérieur des procédures/fonctions où elles sont déclarées. Leur portée est donc limitée à cette procédure/fonction.
Les variables locales n’ont aucun lien avec des variables globales de même nom ou avec d’autres variables locales à d’autres fonctions.

LA NOTION DE FONCTION

Dans beaucoup de langages, on trouve deux sortes de modules :
• Les “fonctions”, assez proches de la notion mathématique correspondante. Notamment, une fonction dispose d’arguments qui correspondent à des informations qui lui sont transmises et elle fournit un unique résultat scalaire simple désigné par le nom même de la fonction, ce dernier peut apparaître dans une expression.
• Les “procédures” (terme Pascal) ou “sous-programme” qui élargissent la notion de fonction. La procédure ne possède pas de valeur et son appel ne peut pas apparaître au sein d’une expression quelconque. Par contre, elle dispose d’argument. Parmi ces derniers certains peuvent, comme pour la fonction, correspondre à des informations qui lui sont transmises. Mais d’autres, contrairement à ce qui se passe pour les fonctions correspondent à des informations qu’elle produit en retour de son appel.

@ygeronimi

Pouvoir déclarer des procédures et des fonctions et disposer de variables locales est une vraie (r)évolution dans PANORAMIC.
Alors ne t’affoles pas, ne crains rien. Tout sera infiniment plus simple.
Tu regretteras simplement de n’avoir pas connu cette souplesse de programmation plus tôt !

@ papydall,

Pour l'heure, j'ai envie de pleurer la perte du dernier langage simple de programmation

et j' ai presque envie de me passer de la dernière récréation gratuite que je pouvais me permettre.
Car aller voir ailleurs, vu que tous sont aussi clair que du pastis...

@ygeronimi

Supposons la situation imaginaire suivante :
Tu désires écrire un programme pour calculer la surface et le périmètre d’un cercle.
Tu analyses ton projet et tu conclus qu’il te faut un programme principal et 2 routines de calcul : l’une calcule la surface et l’autre le périmètre.
Mais ce programme est trop complexe et toi, tu n’as pas assez de temps.
Tu fais appel à papydall pour t’écrire les 2 sous-programmes.
Tu lui donnes comme information : les 2 sous-programmes doivent s’appeler SURFACE_CERCLE et PERIMETRE_CERCLE et je veux les appeler en leur transmettant un paramètre RAYON. L’appel doit être SURFACE_CERCLE (rayon) et PERIMETRE_CERCLE (rayon).
Papydall, obéissant, écrit ce que tu lui as demandé. Toi-même tu as finis ton programme principal sans te soucier des noms de variables que papydall va employer. Tu assembles les 2 morceaux et tu exécute le programme : miracle, ça marche !

Ygeronimi junior, veut lui aussi utiliser le programme de papa mais ne veut pas utiliser la variable RAYON.
Il veut utiliser une variable RAY.
Pas de soucis : il n’a qu’à modifier le nom de la variable globale RAYON (en la changeant par RAY) déclarée dans le programme principal sans toucher à rien aux 2 sous-programmes.
Il lance le programme : il s’exécute correctement.
Sa sœur arrive en courant : moi je veux calculer aussi la surface et le périmètre d’un cercle : j’utilise R pour la variable RAYON.
Une fois encore, tu n’as qu’a modifier dans le programme principal la variable qui deviendra R.
Ton programme marche toujours correctement !

Code:

' *** ON suppose que cette partie est écrite par Ygeronimi
' programme principal
dim pi
pi = 4*atn(1)
dim rayon : rayon = 10 :' rayon sera modifié par ygeronimi junior en ray et par sa soeur en r
surface_cercle(rayon)  :' rayon sera modifié par ygeronimi junior en ray et par sa soeur en r
perimetre_cercle(rayon):' rayon sera modifié par ygeronimi junior en ray et par sa soeur en r


end
' *** fin du programme principal
' ==============================================================================
' on suppose que ces 2 routines sont écrites par papydall
' ils ne seront plus changées
sub surface_cercle(r)
message "La surface du cercle de rayon " +str$(r) + " est"+chr$(10)+chr$(13)+ str$(pi*r*r)
end_sub

sub perimetre_cercle(r)
message "Le perimètre du cercle de rayon "+ str$(r)+ " est"+chr$(10)+chr$(13)+str$(2*pi*r)
end_sub
' *** fin des routines

Actuellement ce sont seulement les paramètres qui sont locaux, mais lorsqu’on puisse déclarer des variables locales ça sera plus souple encore.
Il n’y a pas de difficulté : le tout est de comprendre le fonctionnement de cette évolution.

!!!! Et ça sera facile !!!!

Merci Jack !!!!
Enfin la version avec procedure !!!
Tout comme Jean-Claude, des imperatifs familiaux m’empêche d'essayer cette nouvelle version ce week-end...
je ronge mon frein et Dieu (Jack) sait que je l'attendai cette version !....

Grand merci Jack!!!
A cette allure, je crois que PANORAMIC sera dans les rangs des grands mais avec un avantage précieux : "LA SIMPLICITE DU LANGAGE" QUI EST UNIQUE AU MONDE et destiné tant aux petits amateurs qu'aux grands programmateurs. Bravo Jack!!!

@ygeronimi

Moi personnellement, je veux bien participer mais comme étant amateur en programmation et en informatique je pense être inutile aux débats et désolé si je n'arrive pas à donner même une petite suggestion.

Mais t'en fais pas, je ferais un effort sur ce point là. Bon week end les amis A+

@ papydall,

Le but du jeu c'est que papa ygeronimi puisse lui même créer ses programmes,
que sa grand mère puisse créer des sous programmes ne lui apportera rien si il
n' est plus capable de comprendre le langage et créer les socles.

Tout cela fonctionnait très bien et là on se tourne vers les structures java, C+ et compagnie.
Si j'avais voulu un langage comme ceux ci je serai aller vers eux et c'est ce que je reproche un peu
à toutes les demandes en ce sens. Panoramic n'est plus Panoramic, un langage simple avec
des explications clairs et à la porté de tous.

Je pense qu' il y avait d'autres choses à simplifier et plus facile à comprendre, notamment Les déclarations d'objet
sont parfois longues,répétitives, avant çà.

@ Topmozika,

Moi aussi je ne suis qu' un amateur et je défends mon bout de gras d'amateur.
Je ne pense pas que Jack crée un langage pour lui tout seul et si on est qu'une
dizaine à donner nos sentiments...

Ps: Je l'ai dit, J'attends la doc et après j'envisagerai mon avenir avec ce langage.

Essaye un peu avant ygeronimi, c'est plus simple même qu'avant ... Je ne vois pas ce qu'il y a de difficile. Peux-tu développer la difficulté que tu rencontres ? le fait de mettre end_sub à la place de return ?
le fait de mettre un () après le nom à la place de mettre un gosub ?
le fait de mettre un sub devant le nom à la place de mettre un ":" après
le fait de ne plus avoir à faire de déclaration de label avant ?
Je n'arrive pas à comprendre la difficulté que tu y vois. Peux-tu nous expliquer pourquoi cela t'inquiète ou complique les choses ?

@ Jicehel,

ce sont vos histoires de variables et de paramètres qui sont incompréhensibles
un coup je te déclare par Dim, un coup je te fout entre deux parenthèses
un coup je suis globale, un coup je suis locale
un coup je te passe des paramètres un coup je t'en passe pas

C EST LE BORDEL !


Voilà, je le dis et répète j'attends une doc clair net et précise après j'aviserai
et pour l'instant je reste sur la version précédente.

A les varaibles. Ne t'en sert pas pour le moment, c'est un usage facultatif.
Pour ne pas t’embêter si tu as peur de ça, utilise les variables globales et les sub sans paramètres.
Tu verra l'usage des variables locales, en lisant les programmes des autres tu comprendra en 5mn quand tu seras prêt

Salut ygeronimi

Je te propose d’utiliser cette nouvelle version : elle comporte également des nouvelles commandes pour le GRID qu’on a peut-être délaissé au profit de SUB
Continue d’utiliser GOSUB, si tu veux et laisse SUB pour plus tard.
GOSUB fonctionne comme avant.

Code:

label hello
gosub hello : ' appel du sous-programme par GOSUB
wait 3000  : ' attente de 3s pour lire le texte
salut()    : ' appel du sous-programme pas son nom
wait 3000
message "aucune différence!"+ chr$(10)+chr$(13)+ "entre GOSUB et SUB"
end

hello:
 cls
 print_locate 100,100 : print "Salut tout le monde!"
 print_locate 100,150 : print "Je suis appelé par GOSUB"
return

SUB salut()
 cls
 print_locate 100,100 : print "Salut tout le monde!"
 print_locate 100,150 : print "Je suis appelé par SUB"
END_SUB

Je confirme. Même l'outil de connexion sur Mydrive avec l'utilisation de KGF.dll pour envoyer des touches fonctionne dans cette version, à l'identique par rapport à la pversion V0.1.23.