FORUM DE DISCUSSION SUR LE LANGAGE PANORAMIC

Développement d'applications avec le langage Panoramic
 
AccueilAccueil  FAQFAQ  RechercherRechercher  S'enregistrerS'enregistrer  MembresMembres  GroupesGroupes  Connexion  
Derniers sujets
» quel est ce comportement de Panoramic_editor
par Oscaribout Aujourd'hui à 3:02

» bug BORDER_HIDE : bloque la commande full_space
par silverman Aujourd'hui à 1:19

» Découpe dans une image
par JL35 Hier à 22:00

» FNC IsDateValide(d$) pour vérifier la validité d'une date
par papydall Hier à 18:57

» Pour faire plaisir à jjn4.
par Pedro Alvarez Hier à 8:13

» Pour faire plaisir à Marc37.
par Marc Jeu 22 Fév 2018 - 21:46

» Couleur d'une variable qui n'est pas un mot-clé
par bignono Jeu 22 Fév 2018 - 14:03

» Un catalogue de photos de fleurs, avec KBDD, affichage HTML
par Klaus Mer 21 Fév 2018 - 22:44

» KGF_dll - nouvelles versions
par Klaus Mer 21 Fév 2018 - 22:30

» Mah-Jong anglais
par jjn4 Mer 21 Fév 2018 - 14:22

» Partie fractionnaire d'un flottant
par silverman Mer 21 Fév 2018 - 14:19

» bug CREATE_HIDE : corruption de form
par silverman Mer 21 Fév 2018 - 13:32

» Racine carrée d’un nombre par l’algorithme de Héron
par Ouf_ca_passe Mer 21 Fév 2018 - 9:52

» Méthode manuelle d'extraction de la racine carrée
par pascal10000 Mer 21 Fév 2018 - 7:47

» [annulé]ON_MOVE n,l ne fonctionne que sur le form 0
par silverman Mar 20 Fév 2018 - 16:52

Navigation
 Portail
 Index
 Membres
 Profil
 FAQ
 Rechercher
Rechercher
 
 

Résultats par :
 
Rechercher Recherche avancée
Février 2018
LunMarMerJeuVenSamDim
   1234
567891011
12131415161718
19202122232425
262728    
CalendrierCalendrier

Partagez | 
 

 ALIAS quoi en penser

Aller en bas 
AuteurMessage
Oscaribout



Nombre de messages : 117
Date d'inscription : 29/12/2016

MessageSujet: ALIAS quoi en penser   Ven 9 Fév 2018 - 15:11

Bonjour,

Je suis un peu gêné de postuler ici, vu ma position qui n'est pas très clair. Je me veux d'être en dehors du forum autant que possible et je pose des questions. Mais j'assume toutes les critiques.

Voila! lorsqu'on veut faire par exemple une SUB  qui serait appelé entant #include, il y a le problème des variables. Si la sub est partagée ou récupérée on ne sait pas quelles sont les variables qui ont étés définies, ce qui pose le problème de la dénomination a avoir.

Il y a la fonction VARIABLE("variable") qui existe, mais on ne peut pas faire un programme pour dire par exemple:
if variable("var") = 0 then dim var : else : dim vari
Il faut encore vérifier alors que vari n'existe pas. Ensuite pour le programme, on ne va pas le faire en double, un qui utilise var, et l'autre qui utilise vari.

La solution que l'on emploi est plutôt ceci: dim variable_a_rallonge, pour un tableau variable_a_rallonge(100)

Peut-être que j'entrevois mal les choses mais par exemple si je pouvais écrire:

dim variable_a_rallonge$(100)
corps du programme
end
' =====================
SUB traitement()
  ' et là ce serait pratique d'écrire:
  variable_a_rallonge$() ALIAS n$ :' où tout autre définition.
  et ensuite au lieu d'écrire
  variable_a_rallonge(1) = left$(variable_a_rallonge(1),instr(variable_a_rallonge(1),"|)-1)+right_pos$(variable_a_rallonge(1),5) :' n'importe quoi...
  ' et bien on écrirait alors:
  n$ = left$(n$,instr(n$)-1)+right_pos$(n$,5)


Peut-être on pourrait dire que alias serait toujours local dans une sub. Je n'entre pas d'avantage pour les raisons indiquées, mais votre avis pourrait être important, même si elle m'est très critique. Je l'assume.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
silverman

avatar

Nombre de messages : 528
Age : 45
Localisation : Picardie
Date d'inscription : 18/03/2015

MessageSujet: Re: ALIAS quoi en penser   Ven 9 Fév 2018 - 17:59

C'est un sujet interressant que tu as ouvert, mais je ne comprend pas ce que tu veux dire.
Je part du principe qu'un ALIAS est local à une sub
Si "variable_a_rallonge$() ALIAS n$" est posé dans une sub, la sub doit savoir si la variable globale "variable_a_rallonge$()" existe.
Si elle n'existe pas tu es obligé de la créer. Dans ce cas l'alias ne sert à rien
Si elle existe tu l'ALIAS, donc ton alias qui est local va te servir à manipuler une variable globale.
Quel est l'intérèt de manipuler une variable gobale via un alias si tu as déterminé auparavant que cette variable globale existe? Autant manipuler la variable gobale directement scratch scratch scratch
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Klaus

avatar

Nombre de messages : 10576
Age : 68
Localisation : Ile de France
Date d'inscription : 29/12/2009

MessageSujet: Re: ALIAS quoi en penser   Ven 9 Fév 2018 - 18:06

Citation :
Autant manipuler la variable gobale directement
Certes, mais Oscaribout ne raisonnait pas sur l'accessibilité de la variable. Il avait en tête la facilité décriture poiur utiliser ces noms de variables très courts, déclarés en synonyme sur des noms de variables (longs ou courts, d'ailleurs) définis de dans le programme principal.

Personnellement, je n'ai pas d'opinion particulière à ce sujet. En général, j'utilise des noms très courts (i%, s$, ...) pour des variables technique qui peuvent parfaitement être redéfinies en DIM_LOCAL dans une SUB. Et pour des variables globales, j'utilise volontiers des noms assez longs, de sorte que le nom de la variable en explique l'usage. Et j'utilisre ctrl.C - ctrl/V pour reproduire ces noms lors de l'écriture de nouvelles sections de code.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://klauspanoramic.comxa.com/index.html
Oscaribout



Nombre de messages : 117
Date d'inscription : 29/12/2016

MessageSujet: Re: ALIAS quoi en penser   Ven 9 Fév 2018 - 18:52

Silverman a écrit:
cette variable globale existe? Autant manipuler la variable gobale directement
A quoi peut servir un Alias en variable globale? A rien je pense. Le but est d'avoir un nom facile à écrire. Si on considère l'ALIAS en global, alors il ne sert à rien. Lorsqu'on écrit une sub  générale qui puisse servir à tout le monde, on ne sait pas dans quel programme elle va servir, donc on ne connait pas les variables utilisées, ce qui veut dire qu'il faut utiliser une variable avec un nom complexe. Pour une variable normale, on peut dire à un moment que n$ = machin_truc_chouette$, que n$ soit local ou non, peut importe, par contre pour un tableau c'est différent. Dans une sub, on va pas dire : dim_local n$(100) et faire ensuite: for x%=1 to 100:n$(x%) = truc_machin_chouette$(x%): next%
Et dans toute la sub traiter avec n$, puis faire l'inverse pour que le tavleau truc_machin_chouette$(...) reprenne le tableau transformé.

En réalité, quand je parle de variable locale, c'est juste la transposition du nom, en pensant que dans la sub ALIAS n'est pas la définition d'une variable, mais seulement mettre un nom provisoire, valable jusqu'à la sortie de la sub. Personnellement je trouve l'idée intéressante. Je sais que copie/coller permet une écriture rapide, mais il est des fois où celà devient barbant. J'ai déjà constaté que lire un programme avec des mots à rallonge, c'est plus complexe à lire que de lire avec des mots simples, surtout lorsque que l'on met une racine complexe qui sert à une série de variables à compléter. Je m'explique: truc_machin_chouette_n% truc_machin_chouette_nb%,  truc_machin_chouette_txt$. A la longue ça devient compliqué. Peut-être que j'ai un cerveau diminué, et que pour vous autres c'est plus facile. Je pense que mon explication est plus claire. Je ne cherche pas la définition d'une variable, mais un nom de remplacement, un surnom par exemple. Peut-être faudrait-il un suplément comme OFF_ALIAS n$?

Bon je rêve, cela m'étonnerai que Jack soit d'accord. Sad
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Klaus

avatar

Nombre de messages : 10576
Age : 68
Localisation : Ile de France
Date d'inscription : 29/12/2009

MessageSujet: Re: ALIAS quoi en penser   Ven 9 Fév 2018 - 19:02

Tu peux aussi passer tes variables globales à la SUB en tant que paramètres. Et dans la SUB, tu leur donnes le nom que tu veux (et qui peut être très court). Et le problème a disparu. D'autant que le nombre de paramètres à une SUB n'est pas limité.

Bien sûr, cette technique a des limites: on ne peut passer que des valeurs en entrée. On peut certes modifier ces valeurs dans la SUB, mais on ne retrouve pas ces modifications en-dehors de la SUB. Là, le problème reste entier...
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://klauspanoramic.comxa.com/index.html
papydall

avatar

Nombre de messages : 5746
Age : 67
Localisation : Moknine (Tunisie) Entre la chaise et le clavier
Date d'inscription : 03/03/2012

MessageSujet: Re: ALIAS quoi en penser   Ven 9 Fév 2018 - 19:18

Les sous-programmes (procédures et fonctions) sont utilisés pour découper  un gros programme en morceaux plus petits.
Ça devient plus simple à coder, à comprendre et éventuellement à modifier ultérieurement.
Comme un programme, un sous-programme possède un nom, des variables, des instructions, un début et une fin.
Contrairement à un programme, un sous-programme ne peut pas s’exécuter indépendamment d’un autre programme.
C’est le programme principal (ou un autre sous-programme) qui se charge de demander l’exécution des instructions se trouvant dans les sous-programmes.
On distingue des sous-programmes particuliers (les procédures événementielles) qui sont exécutés à la suite d’un événement (clic sur un bouton, choix dans un menu, etc.)

Selon mon point de vue :
Un sous-programme (procédure ou fonction) est une partie INDEPENDANTE de tout programme (ou sous-programme) qui pourrait l’utiliser. Il peut être écrit par une autre personne, autre que le programmeur qui utiliserait ce sous-programme.
Le programmeur qui utiliserait ce sous-programme n’est pas sensé connaitre quelles variables locales sont utilisées au sein du sous-programme.
La seule et unique information que l’utilisateur du sous-programme doit connaitre c’est que fait ce sous-programme et comment l’appeler ?
Autrement dit, le nom du sous-programme, les paramètres formels et leur type à transmettre au sous-programme.
Il n’a pas à se soucier des variables locales que le sous-programme manipule.

Toujours selon mon point de vue, un sous-programme doit éviter autant que faire se peut d’utiliser des variables globales.
Il gagnera ainsi de plus de portabilité.
Il doit aussi être aussi court que possible (une page écran, tout au plus une page imprimé).
Il sera ainsi plus simple à déboguer et modifier.

J’ai donné mon point de vue et à chacun le sien.
Puisse ce post donner plus d’interventions des autres panoramiciens pour enrichir le débat et faire germer d’autres idées de conception de programme.
Je note que Oscaribout à souvent des idées très intéressantes, voire même rénovatrices.
Le problème, selon moi, c’est sa manière d’expliquer son point de vue que certains (moi, le 1er) ne comprennent pas toujours le fond de ses idées.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://papydall-panoramic.forumarabia.com/
Jean Claude

avatar

Nombre de messages : 5180
Age : 63
Localisation : 83 Var
Date d'inscription : 07/05/2009

MessageSujet: Re: ALIAS quoi en penser   Ven 9 Fév 2018 - 20:26

Je viens de lire ce sujet avec intérêt,

Oscaribout a écrit:
Voila! lorsqu'on veut faire par exemple une SUB  qui serait appelé entant #include, il y a le problème des variables. Si la sub est partagée ou récupérée on ne sait pas quelles sont les variables qui ont étés définies, ce qui pose le problème de la dénomination a avoir.

Ce que je connais de Panoramic, c'est que les variables locales à une SUB n'interfèrent aucunement au programme principal, donc si on les appelle (les SUBs) par #include le cas devrait être valable, car (sauf erreur de ma part) #include insert un code dans le code.

Par contre, si la SUB doit retourner un résultat, alors il faut une variable globale qui stocke ce résultat.

Donc, pourquoi un allias ???

Je n'ai peut-être pas compris ce que veut dire Oscaribout.....

A+,
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Klaus

avatar

Nombre de messages : 10576
Age : 68
Localisation : Ile de France
Date d'inscription : 29/12/2009

MessageSujet: Re: ALIAS quoi en penser   Ven 9 Fév 2018 - 21:12

En fait, le problème ne se pose que si l'on veut programmer un peu "en-dehors" des règles de la bonne gestion de la modularité.

Normalement, aucune SUB ne devrait dépendre d'une variable globale quelconque, dès l'instant qu'elle a vocation à être incluse dans des programmes divers, via #INCLUDE ou un autre moyen quelconque. Dans ce contexte, elle devrait être considérée comme une "boite noire", avec comme pilotage les paramètres avec lesquels on l'appelle.

Or, ce que semble suggérer notre ami Oscaribout, c'est tout à fait autre chose. En fait, il s'agirait plutôt d'estraire des parties d'un code plus vaste, peut-être parce que c'est réutilisé à plusieurs endroits, que sais-je. Mais le point clé, c'est que ce code utilise apparemment plusieurs variables globales, peut-être même beaucoup, et peut-être même des tableaux qui sont de toutes facons impossibles à passer en paramètres. Et, probablement, la section en question effectue également des modifications dans ces variables globales.

Tout ceci est bien entendu en-dehors des pratiques de programmation modulaire que je recommanderais. Mais chacun programme à sa manière, et il ne m'appartient pas de juger les techniques des uns et des autres. Tout ce que je sais, c'est qu'Oscaribout a raison de dire que ceci pose problème actuellement, et il demande simplement un moyen de faciliter l'écriture dans un tel contexte. C'est une demande légitime et on peut l'entendre.

Maiintenant, techniquement, ça sera très compliqué à implémenter. Je ne suis pas Jack, et ne ne suis pas au courant des sources de Panoramic. Cependant, j'ai "fouiné" suffisamment dans la mémoire d'un programme Panoramic en cours d'exécution pour savoir que cela pose de vrais problèmes techniques, à supposer ce ce soit réalisable ce qui n'est pas sûr du tout. Prenons le simple fait que les variables en Panoramic sont "dynamiques". En effet, on peut les créer (DIM, DIM_LOCAL, et paramètres formels des SIB et maintenant des fonctions), mais on peut également les supprimer (DELETE, EXIIt_SUB, END_SUB, EXITè_FNC, END_FNC). Une variable du même nom peut avoir des dimensions ou non (DIM a$, dim a%(10) etc). Et une variable d'un nom quelconque peut être supprimée et recréée, avec des dimensions différentes, et bien sûr l'adresse en mémoire des données change.

Bien entendu, le dernier mot en revient à Jack. Mais pour ma part, je conseillerais fortement à notre ami Oscaribout de revoir ses techniques de programmation, afin d'y introduire une plus grande modularité, meilleure séparation des unités logiques de code et surtout une méthode rigoureuse de nommage des variables, ceci en toute amitié et avec tout le respect devant des habitudes personnelles de réalisation.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://klauspanoramic.comxa.com/index.html
JL35



Nombre de messages : 6152
Localisation : 77
Date d'inscription : 29/11/2007

MessageSujet: Re: ALIAS quoi en penser   Ven 9 Fév 2018 - 21:15

Moi on plus je ne vois pas trop ce qu'on entend par ALIAS...
Une variable passée en paramètre à une SUB devient locale à l'intérieur de la sub, on ne donc pas lui passer en paramètre la variable qui doit contenir le résultat éventuel.
Ce résultat peut être passé dans une variable globale, que la sub doit connaître d'avance, ce qui est un peu gênant.

En ce qui me concerne, dans 99% des cas, je renvoie le résultat éventuel dans le presse-papier, (je sais qu'il y a des détracteurs), mais comme ça au moins la sub est indépendante du programme appelant, et je n'ai jamais eu de problème en opérant de cette façon.

J'ai croisé Klaus, au passage... entièrement d'accord avec ton premier paragraphe.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Oscaribout



Nombre de messages : 117
Date d'inscription : 29/12/2016

MessageSujet: Re: ALIAS quoi en penser   Ven 9 Fév 2018 - 23:57

Bien, je vous remercie pour vos réactions.

L'idée m'était venu par rapport à un programme que je créé. En le composant, je me suis dis combien ce serait bien de pouvoir avoir une liste qu'on est obligé d'y mettre un mot long (liste=tableau). Et j'ai employé le mot variable en pensant à tableau vu qu'en Panoramic, on ne peut donner le même nom pour les deux. D'ailleurs les exemples que j'ai donné font appel à un tableau. Comme dit Klaus, on ne peut pas passer comme paramètre un tableau.

J'ai employé le mot alias, mais peut-être sur_nom aurait été mieux mais ça ne change rien. Moi-même je me suis posé la question de savoir si mettre un surnom à un nom de variable était possible. Donc je crois qu'on peut clore le sujet.

Je suis en train petit à petit de faire une sorte de RichEdit en Panoramic. J'ai regardé ce que propose Klaus avec sa dll, mais moi le plus important est de pouvoir faire des sortes de rapport avec du style par programmation. J'ai décortiqué le code émis d'un richedit, et c'est bien compliqué, il faut pouvoir dans le texte écrit faire une sélection par programme pour pouvoir y mettre le style. Cela demande beaucoup travail pour chaque ligne. De plus dans les premières lignes, c'est un peu du charabia. Donc mon but est de pouvoir écrire directement dans le texte comme on ne peut le faire avec du htlm, et pouvoir aussi faire des fiches, des rapports avec des données stylées par programme.

C'est un problème personnel, et je regrette le temps ancien, où on pouvait le faire facilement avec les basics en 8bits. Je pouvais imprimer avec différents styles, en normal ou condensé sur une ligne. J'ai même eu une imprimante couleur à impacts avec ruban. Je pouvais complètement programmer les couleurs. Aujourd'hui c'est plus possible à moins d'utiliser  certains programmes du commerce, mais très difficilement en Panoramic.
Pour ce programme je n'utilise qu'une seule variable globale tout le reste c'est du locale, et ça a été un casse tête pour n'avoir que celle-là. Je réfléchi pour savoir si je peux me servir d'un tableau, et je ne vois pas comment ce dernier peut-être local Question , mais bon je cherche le moyen de l'éviter. Attention je ne demande pas la commande que je propose. Il est évident que si j'attends aujourd'hui pour l'avoir, je peux arrêter tout de suite. Le programme en cours est en rapport à une demande qu'on m'a faite, et pour moi même ça serait bien pratique.

J'ai ouvert le sujet pour savoir ce que vous en pensiez, donc je sais maintenant qu'on peut arrêter là, d'autant que la majorité ne comprend pas l'utilité.

Merci beaucoup.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Klaus

avatar

Nombre de messages : 10576
Age : 68
Localisation : Ile de France
Date d'inscription : 29/12/2009

MessageSujet: Re: ALIAS quoi en penser   Sam 10 Fév 2018 - 0:14

Juste une petite info, Oscaribout. As-tu regardé le fonctionnment de l'objet DLIST de Panoramic ? C'est comme un objet LIST, sauf que c'est invisible. Tu peux passer le numéro d'objet en paramètre à une SUB. Et dans une DLIST, tu peux mettre autant de lignes que tu veux. Elles sont toutes des chaînes de caractères.

Alors, tu peux décider d'utiliserune DLIST pour passer tes paramètres à une SUB. Su tu places chaque valeur ou variable au bon endroit, ta SUB peut lire, disons la ligne 17, avec la fonction GET_ITEM$ et avoir accès à ton 17ème paramètre. Mais, mieux: ta SUB peut modifier ce paramètre dans la DLIST, en le supprimant par ITEM_DELETE, puis en insérant la nouvelle valeur à la même position avec ITEM_INSERT. Ainsi, le programme principal, à la sortie de ta SUB, retrouvera les valeurs modifiées, chose que tu ne peux pas faire avec un paramètre normal. Pour passer une valeur numérique dans la DLIST, tu fais ITEM_ADD avec STR$(valeur). Pour lire une valeur numérique, tu fais VAL(ITEM_READ$(...)).

Je pense que, techniquement, c'est ce qui pourrait se rapprocher le plus de l'idée initiale que tu proposais. Bien sûr, dans ce cas, dans la SUB, tu déclares tes variables avec DIM_LOCAL, même avec des noms courts, car en réalité, tu les charges par des lectures dans la DLIST en les identifiant par le numéro de leur position et non plus par leur nom initial. Ainsi, la SUB n'a plus aucun lien avec le programme principal, et il peut être utilisé librement, même par #INCLUDE, dans n'importe quel programme. Seul compte l'ordre dans lequel les données sont rangées dans la DLIST avant l'appel de la SUB.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://klauspanoramic.comxa.com/index.html
Oscaribout



Nombre de messages : 117
Date d'inscription : 29/12/2016

MessageSujet: Re: ALIAS quoi en penser   Sam 10 Fév 2018 - 1:04

Klaus c'est ce que je fais. Pour l'instant tous mes dlist sont des listes pour contrôle mais c'est provisoire. Un dlist est plus rapide car il n'y a pas d'écriture.
Je ne crois pas que GET_item$ existe, tu veux dire item_read$() erreur de jeunesse Very Happy .
L'inconvénient du list est qu'il faut le remplir, et qu'il n'a qu'une seule donnée par ligne. Où alors il faut y mettre des repères, cela augmente le temps de calcul.Avec un tableau, on a accès directement à un N° même si tout est vide au départ. Ensuite et ça je l'ai remarqué pour les list Panoramic: lorsque le nombre d'élément est élevé, le temps de traitement est long. Je pense qu'on départ il y a une programmation de X éléments, et que lorsqu'on dépasse, il se créé de la place. Quand il y a beaucoup d'éléments un item_delete suivi d'un item_insert devient très long. Jack ne dit rien là dessus, mais il serait bon de faire une série de teste pour savoir à partir de quand cela se produit.

Je ne sais pas si tu as vu le passage où je proposais de me servir d'un sous-programme pour passer les paramètres des variables locales, c'est déjà une bonne solution.

Ensuite j'aurai voulu passer les paramètres avec des datas, mais encore faut-il savoir si dèja  il n'y a pas une série de data en cours avant ou arrière. Il y a Restore. Il me semblait avoir lu quelque part qu'il y avait un problème mais peut-être est-il résolu. Les Datas aurait été bien pour une partie du programme, mais c'est un problème si on ne sait pas comment c'est utilisé dans un programme qui appelle la sub.

Je réfléchi a un GRID, par contre il faut faire des essais si en écrivant à un certain niveau en dehors des réglages si il n'y a pas une erreur comme on le voit avec count() pour un dépassement. Je verrai à la suite.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Klaus

avatar

Nombre de messages : 10576
Age : 68
Localisation : Ile de France
Date d'inscription : 29/12/2009

MessageSujet: Re: ALIAS quoi en penser   Sam 10 Fév 2018 - 1:14

Je comprends ton argumentation. Dans ce cas, on en peut pas faire beaucoup plus.

Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://klauspanoramic.comxa.com/index.html
Contenu sponsorisé




MessageSujet: Re: ALIAS quoi en penser   

Revenir en haut Aller en bas
 
ALIAS quoi en penser
Revenir en haut 
Page 1 sur 1
 Sujets similaires
-
» que penser vous d' avast
» Décalage rvb = Décale quoi ?
» Wild Rasberry || Alias. Alison
» Kiowa Source Alias Flo
» Bitdefender QuickScan

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
FORUM DE DISCUSSION SUR LE LANGAGE PANORAMIC :: PANORAMIC :: Présentation et bavardage-
Sauter vers: