bogue sur les espèces en tant qu'acteurs locaux.

Bonjour,

Suite à une remarque de Pat, j'ai corrigé un bogue dans Linotte qui ouvre pas mal de nouvelles portes...

On peut maintenant créer facilement en série des acteurs graphiques en utilisant un acteur local.

Par exemple, je veux créer 30 carrés sur mon écran :

par contre, il va falloir attendre la prochaine 0.6.1 bêta 4 pour tester ça... désolé...

Ronan

Vite fais en passant,
Bonsoir, alors c'était un bogue dans mon livre? (Je me doutais bien qu'il serait question d'acteur local et global),mais dans votre version de mon livre, je ne comprends plus pourquoi créer le grand rôle nommé "carré".
Je continue la version de mon livre et vous tiens au courant.
Salut, @+

Dans mon exemple, tu peux supprimer l'acteur carré. Il n'est plus utilisé.

Etant donné que tu avais déclaré cet acteur au niveau du livre, tu manipulais toujours le même acteur sur la toile.

L'avantage d'utiliser un acteur local, c'est que tu utilises un acteur visible qu'une fois dans le paragraphe. A chaque boucle dans la paragraphe "calculcellule2", Linotte créé un nouveau rectangle nommé "t" visible seulement dans le nouveau paragraphe. Ainsi, à chaque fois que tu retournes dans ce paragraphe, tu es sûr de travailler avec un acteur différent.

J'espère avoir été clair...

Bonsoir,
Il est vrai que j'ai du mal avec les acteurs locaux et globaux (il semble que ça ne fonctionne pas comme ca sous d'autres langages, j'ai peut-être pris de mauvaises habitudes);
quoi qu'il en soit il serait bien de pouvoir créer un acteur avec un comportement local en mémoire mais restant disponible tout au long du livre avec la dernière valeur qui lui a été affecté.

Ouf! j'espère avoir été clair...

Bon, je retourne à mon livre (linotte) " title="Smile" />

Il est théoriquement pas possible d'avoir un acteur local accessible dans tout le livre à part... garder un référence de cet acteur dans un casier.

Justement, avec cette gestion des acteurs, j'essaye d'avoir le même comportement en java (ou dans un langage fonctionnelle).
En quel langage programmais-tu avant ?

J’ai principalement découvert la programmation sur pc avec VBA sous Excel, plus récemment avec Linotte et Python ;
pour mieux faire comprendre mon idée précédemment exposée voici un petit exemple en python :
#liste

global a
a=0
def Listea(): #définition de la sous fonction Listea
liste=[]
global a
while a<
3:
a=a+1
liste.append(a)
print liste
#maintenant l'on est sorti de la sous fonction (pas d'intentation)
Listea() #exécution de la sous fonction Listea
#maintenant l'on est sorti de la sous fonction Listea
print a
Listea()
print a
Voilà l’affichage obtenu :
[1, 2, 3] #on obtient bien une liste avec chacune des valeurs de a successives
3 #malgré la sortie de la sous fonction on peut encore utilisé la variable a
[] #maintenant l’éxecution de la sous fonction Listea entraine une liste vide car la variable a n’est plus <
à 3 et la liste est définie localement à la fonction Listea donc reste vide
3 #la variable a est toujours disponible après cette nouvelle exécution de Listea

Bon, j’espère que c’est plus clair maintenant cette idée d’acteur local persitant.
Merci de votre compréhension @+

Je ne connais pas Python mais ton exemple est intéressant.

Linotte est un langage objet. Si tu créés l'acteur local "a" dans le paragraphe : il sera unique dans le contexte de ton paragraphe.
Dés tu appelles la variable "a", tu pointes toujours sur le même "a" en mémoire.

Exemple :

tu as "a" avec la valeur 2
Si tu fais : a vaut a + 2
tu as maintenant "a" avec la valeur 4

En python, a priori, quand tu fais append(a), il doit créer une nouvelle variable a :
la valeur de la variable doit être "passée en copie".
A vérifier car je ne connais pas python.

Pour comprendre, voici un extrait de wikipedia (http://fr.wikipedia.org/wiki/Param%C3%A8tre):

Un paramètre d'entrée est une donnée fournie par le code appelant au code appelé. Cette donnée peut être transmise de deux façons :

* passage par copie (aussi appelé par valeur) : le code appelé dispose d'une copie de la valeur. Il peut la modifier, l'information initiale dans le code appelant n'est pas affectée par ces modifications.
* passage par adresse (aussi appelé par référence): le code appelé dispose d'une information lui permettant d'accéder en mémoire à la valeur que le code appelant cherche à lui transmettre. Il peut alors modifier cette valeur là où elle se trouve, le code appelant aura accès aux modifications faites sur la valeur. Dans ce cas, le paramètre peut aussi être utilisé comme un paramètre de sortie.

Python fonctionne en "passage par copie" et Linotte en "passage par adresse"

Alors, comment faire cette boucle en Linotte ?

Voici une solution :


Ce débat est intéressant... Faut-il modifier le comportement de Linotte ? Moi, je pense que non. C'est plus long, je l'accorde mais je pense que c'est plus clair.


L'idéal serait d'avoir un fonctionnement comme cela :

Mais ce n'est pas possible en Linotte...

VBA Excel et Python fonctionne de la même manière sur ce point, alors comme j’ai pas mal programmé en VBA Excel, je suis plus habitué à ce type de fonctionnement. Au moins, Linotte m’a permis de connaitre autre chose, l’idéal serait de pouvoir choisir le type de passage.
Personnellement, je ne vois pas bien les avantages du passage par adresse, pourriez-vous poster un exemple montrant l’un de ces avantages.
Merci et @+

Un petite remarque en passant...
Il semble que l'on ne puisse pas faire ceci:
§a est un nombre depuis "C:\Documents and Settings\Administrateur.ORKAS\Mes documents\langage linotte\Linotte_0_6_1_b4\acteurs.txt"
avec linotte, pourtant ce pourrait être la solution pour reproduire l'exemple pré-cité.
Serait-il possible d'implenter une telle possibilité?
Merci @+

Bonjour,
Oui, c'est possible et ça fonctionne déjà. Regarde l'exemple pendu.liv.

Sinon, je propose une autre solution, c'est d'ajouter une notion de clonage... ou de passage par copie !

Voici un exemple


Le # avant l'acteur indique à Linotte qu'il doit faire une copie de l'acteur et donc travailler sur un nouveau qui sera bien sûr non visible au niveau de la mémoire globale.

Au moins, je vois que j'ai bien fait de poser la question à l'origine de cette discussion (/acteurs locaux persistant).
Bon, je n'est rien trouvé dans le livre pendu.
Alors, voici mon petit essai sous linotte, qui ne fonctionne pas ;
l'acteur a démarre toujours de 0.

Livre : Listea
(Spécification 0.6.1)(beta4)
Grands Rôles :
c est un nombre

Paragraphe : Liste
Rôles :

Actions:
c=c+1
Efface le tableau
pour chaque 3, Parcours ajout liste
Parcours liste neg

Paragraphe : ajout liste
Rôles :
liste est un casier de nombre vide
§a est un nombre depuis "C:\Documents and Settings\Administrateur.ORKAS\Mes documents\langage linotte\Linotte_0_6_1_b4\acteurs.txt"

Actions :
affiche "a"
affiche a

Ajoute a dans liste
affiche liste
Reviens

Paragraphe : liste neg
Rôles :
§a est un nombre depuis "C:\Documents and Settings\Administrateur.ORKAS\Mes documents\langage linotte\Linotte_0_6_1_b4\acteurs.txt"
Actions :
a=a-0.1
Attends 1 secondes
Si c est plus petit que 10 alors Parcours Liste
Termine

Sinon, dans votre exemple après la sortie du paragraphe "remplissage auto", #nombre sera-t-il toujours disponible?

Pour finir, j'ai encore des pbs dans mon livre damier, dont je ne vois pas la cause :/

Quand un acteur est créé dans la section Rôles d'un livre, il est stocké dans la mémoire 'globale' de Linotte.

Cette mémoire fonctionne comme un registre : la clef pour retrouver un acteur est son nom.

Par contre, un acteur local n'est visible que dans le paragraphe lors de son exécution (le contexte paragraphe). Il n'est donc pas visible dans la mémoire globale.

C'est le même principe pour les acteurs anonymes et les acteurs clonés. Ils existent mais ne sont pas présents dans la mémoire globale de Linotte.
Alors, comment les récupérer dans un autre paragraphe ?
Deux méthodes :
-Soit, d'appeler un autre paragraphe en les passant par paramètre :
tu parcours X avec A , B
-Soit, les ajouter dans un casier qui sera, lui, dans la mémoire globale.

La notion de clonage permet donc maintenant de passer des paramètres par copie (cf plus haut !).
C'est le # avant l'acteur qui l'indique.

Exemple : ajoute #a dans tableau.

Ce n'est pas 'a' qui va se retrouver dans la tableau mais un clone de 'a'. Si 'a' se trouve dans la mémoire globale, le clone de 'a' n'y sera pas ! Normal, car ils ont le même nom ! Il faut donc faire attention !

Ce système permet à Linotte d'être toujours un langage 100% objet car le clonage est un notion objet : http://fr.wikipedia.org/wiki/Clonage_(informatique)

Le clonage fonctionne avec Linotte 0.6.1 bêta 5.

En tout cas, merci pour tes questions... Linotte avance !

C’est presque ça, cependant il est fort regrettable que l’acteur clone et sa valeur ne soit pas conservé automatiquement à la sortie du paragraphe, cela enlève beaucoup de lors intérêt, il me semble?

C'est impossible, et c'est le même mécanisme dans tous les langages. Si tu clones, tu ne peux pas retrouver avec deux acteurs (ou variables) avec le même nom.

Euh ? Je m’excuse, je vois que je me suis emmêlé les pinceaux, à l’usage les acteurs clones apportent un vrai plus, notamment lors du remplissage de liste et de toute manière l’acteur globale (source du clone) reste toujours disponible lui !
Encore mille fois pardon ! Merci de votre compréhension.