Je viens de finir la traduction ci dessous :
http://community.ofset.org/wiki/Les_bases_de_la_syntaxe_Smalltalk
C'est encore brute de decoffrage, il y besoin de relecture.
Hilaire
Bonjour, tout d'abord merci pour cette traduction. La lecture de ce document est trés intéressante pour un débutant comme moi :o) Dans le document il y a une note concernant la version 3.9 indiquant qu'il y a des changements pour les fermetures lexicales. Ou peut on trouver la liste des changements prévus pour la version suivante de Squeak ? Concernant "whileTrue", dans le document on indique que l'implémentation de whileTrue est la suivante : BlockClosure>>whileTrue: aBlock ^ self value ifTrue: [ aBlock value. self whileTrue: aBlock ]
alors que dans l'image que j'ai (3.9alpha) c'est :
BlockClosure>>whileTrue: aBlock "Ordinarily compiled in-line, and therefore not overridable. This is in case the message is sent to other than a literal block. Evaluate the argument, aBlock, as long as the value of the receiver is true."
^ [self value] whileTrue: [aBlock value]
Autant je comprends le fonctionnement du whileTrue dans le document autant je n'arrive pas à comprendre son fonctionnement tel qu'il est implémenté. Est ce que qqu'un pourrait m'éclairer ? :)
Pour corriger les fautes, suffit-il de s'inscrire sur Ofset et de modifier le document ? (ou doit on vous prévenir ...)
Par avance merci.
Loïs
Le samedi 18 février 2006 à 15:06 +0100, Hilaire Fernandes a écrit :
Je viens de finir la traduction ci dessous :
http://community.ofset.org/wiki/Les_bases_de_la_syntaxe_Smalltalk
C'est encore brute de decoffrage, il y besoin de relecture.
Hilaire _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Bonjour, Pour le whileTrue: il me semble que dans certains Smalltalks , la methode n'est jamais appelee, elle est en fait optimise par la machine virtuelle. Il y a eu un poste la dessus il y a quelques temps sur comp.lang.smalltalk . Je pense que le whileTrue: est une des petites "feintes" du Smalltalk, ou on "triche" un peu pour que ca marche rapidement, sinon on risquerait de s'embourber dans des passages de messages a l'infini.
Corrigez moi si je me trompe, je ne suis pas certain de ce que j'avance.
Yann
On Feb 19, 2006, at 12:10 AM, Loïs Lherbier wrote:
Bonjour, tout d'abord merci pour cette traduction. La lecture de ce document est trés intéressante pour un débutant comme moi :o) Dans le document il y a une note concernant la version 3.9 indiquant qu'il y a des changements pour les fermetures lexicales. Ou peut on trouver la liste des changements prévus pour la version suivante de Squeak ? Concernant "whileTrue", dans le document on indique que l'implémentation de whileTrue est la suivante : BlockClosure>>whileTrue: aBlock ^ self value ifTrue: [ aBlock value. self whileTrue: aBlock ]
alors que dans l'image que j'ai (3.9alpha) c'est :
BlockClosure>>whileTrue: aBlock "Ordinarily compiled in-line, and therefore not overridable. This is in case the message is sent to other than a literal block. Evaluate the argument, aBlock, as long as the value of the receiver is true."
^ [self value] whileTrue: [aBlock value]
Autant je comprends le fonctionnement du whileTrue dans le document autant je n'arrive pas à comprendre son fonctionnement tel qu'il est implémenté. Est ce que qqu'un pourrait m'éclairer ? :)
Pour corriger les fautes, suffit-il de s'inscrire sur Ofset et de modifier le document ? (ou doit on vous prévenir ...)
Par avance merci.
Loïs
Le samedi 18 février 2006 à 15:06 +0100, Hilaire Fernandes a écrit :
Je viens de finir la traduction ci dessous :
http://community.ofset.org/wiki/Les_bases_de_la_syntaxe_Smalltalk
C'est encore brute de decoffrage, il y besoin de relecture.
Hilaire _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
-- Yann Monclair -- Email: yann@monclair.info 2 rue Camille Claudel -- Cell: +33 663 948092 29900 Concarneau -- Home: +33 298 979323 FRANCE -- WWW: http://yann.monclair.info
en VisualWorks
ils ont la definition suivante
whileTrue: aBlock "Evaluate the argument, aBlock, as long as the value of the receiver is true."
^self value ifTrue: [aBlock value. [self value] whileTrue: [aBlock value]]
"This method is inlined if both the receiver and the argument are literal blocks. In all other cases, the code above is run. Note that the code above is defined recursively. However, to avoid actually building an activation record each time this method is invoked recursively, we have used the '[...] whileTrue: [..]' form in the last line, rather than the more concise 'self whileTrue: aBlock'. Using literal blocks for both the receiver and the argument allows the compiler to inline #whileTrue:, which (in the absence of type inferencing) could not be done if we were to use 'self whileTrue: aBlock'."
Merci bien. Je trouve le commentaire qui explique comment le compilateur optimise le code trés intérressant (et cela explique aussi le commentaire dans le code de Squeak). Moi qui trouvait justement que la définition récursive du whileTrue était un peu barbare :) Mais cela ne m'explique toujours pas l'implémentation du whileTrue dans Squeak ?
Loïs
Le dimanche 19 février 2006 à 10:08 +0100, stéphane ducasse a écrit :
en VisualWorks
ils ont la definition suivante
whileTrue: aBlock "Evaluate the argument, aBlock, as long as the value of the receiver is true."
^self value ifTrue: [aBlock value. [self value] whileTrue: [aBlock value]]
"This method is inlined if both the receiver and the argument are literal blocks. In all other cases, the code above is run. Note that the code above is defined recursively. However, to avoid actually building an activation record each time this method is invoked recursively, we have used the '[...] whileTrue: [..]' form in the last line, rather than the more concise 'self whileTrue: aBlock'. Using literal blocks for both the receiver and the argument allows the compiler to inline #whileTrue:, which (in the absence of type inferencing) could not be done if we were to use 'self whileTrue: aBlock'." _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Exact Je pense (mais c'est une hypothese) qu'en sqeuak le code n'est jamais execute. J'ai demande dans la mailing-list. Il faudrait que je regarde le compilation mais je n'ai pas le temps de vraiment plonger dedans
Stef On 19 févr. 06, at 11:27, Loïs Lherbier wrote:
Merci bien. Je trouve le commentaire qui explique comment le compilateur optimise le code trés intérressant (et cela explique aussi le commentaire dans le code de Squeak). Moi qui trouvait justement que la définition récursive du whileTrue était un peu barbare :) Mais cela ne m'explique toujours pas l'implémentation du whileTrue dans Squeak ?
Loïs
Le dimanche 19 février 2006 à 10:08 +0100, stéphane ducasse a écrit :
en VisualWorks
ils ont la definition suivante
whileTrue: aBlock "Evaluate the argument, aBlock, as long as the value of the receiver is true."
^self value ifTrue: [aBlock value. [self value] whileTrue: [aBlock value]]
"This method is inlined if both the receiver and the argument are literal blocks. In all other cases, the code above is run. Note that the code above is defined recursively. However, to avoid actually building an activation record each time this method is invoked recursively, we have used the '[...] whileTrue: [..]' form in the last line, rather than the more concise 'self whileTrue: aBlock'. Using literal blocks for both the receiver and the argument allows the compiler to inline #whileTrue:, which (in the absence of type inferencing) could not be done if we were to use 'self whileTrue: aBlock'." _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
stéphane ducasse a écrit :
Exact Je pense (mais c'est une hypothese) qu'en sqeuak le code n'est jamais execute. J'ai demande dans la mailing-list. Il faudrait que je regarde le compilation mais je n'ai pas le temps de vraiment plonger dedans
Stef On 19 févr. 06, at 11:27, Loïs Lherbier wrote:
Merci bien. Je trouve le commentaire qui explique comment le compilateur optimise le code trés intérressant (et cela explique aussi le commentaire dans le code de Squeak). Moi qui trouvait justement que la définition récursive du whileTrue était un peu barbare :) Mais cela ne m'explique toujours pas l'implémentation du whileTrue dans Squeak ?
Loïs
Le dimanche 19 février 2006 à 10:08 +0100, stéphane ducasse a écrit :
en VisualWorks
ils ont la definition suivantewhileTrue: aBlock "Evaluate the argument, aBlock, as long as the value of the receiver is true."
^self value ifTrue: [aBlock value. [self value] whileTrue: [aBlock value]] "This method is inlined if both the receiver and the argument areliteral blocks. In all other cases, the code above is run. Note that the code above is defined recursively. However, to avoid actually building an activation record each time this method is invoked recursively, we have used the '[...] whileTrue: [..]' form in the last line, rather than the more concise 'self whileTrue: aBlock'. Using literal blocks for both the receiver and the argument allows the compiler to inline #whileTrue:, which (in the absence of type inferencing) could not be done if we were to use 'self whileTrue: aBlock'." _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
.
Les while, to:do: sont interceptés par le compilateur et traduits en sauts tout a fait classiques par le compilateur.
Comment on retrouve une méthode compilée dans une classe (VW):
Trucx methodDictionary at: #ahaha
Méthode de Trucx:
ahaha | x | x := 10. [x = 0] whileFalse: [x := x - 1. x = 5 ifTrue: [x := x - 2]]. ^x
Code désassemblé montrant la structure séquentielle:
normal CompiledMethod numArgs=0 numTemps=1 frameSize=12
literals: ()
1 <D8 0A> push 10 3 <4C> store local 0; pop 4 <67> loop head 5 <10> push local 0 6 <49> push 0 7 <A6> send = 8 <EC 0F> jump true 25 10 <10> push local 0 11 <4A> push 1 12 <A1> send - 13 <4C> store local 0; pop 14 <10> push local 0 15 <D8 05> push 5 17 <A6> send = 18 <C3> jump false 23 19 <10> push local 0 20 <4B> push 2 21 <A1> send - 22 <4C> store local 0; pop 23 <E3 EB> jump 4 25 <10> push local 0 26 <65> return
======================== b.
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
.
Le Dimanche 19 Février 2006 12:53, Bernard Pottier a écrit :
stéphane ducasse a écrit :
Exact Je pense (mais c'est une hypothese) qu'en sqeuak le code n'est jamais execute. J'ai demande dans la mailing-list. Il faudrait que je regarde le compilation mais je n'ai pas le temps de vraiment plonger dedans
Stef
En version 3.8, le code n'est effectivement pas exécuté car le compilateur transforme ces messages whileTrue: et autres en bytecode optimisé (avec des instructions de branchement).
Par conséquent, en Squeak, il n'est pas possible de redéfinir un certain nombre de messages (cf classe MessageNode et classVar MacroTransformers).
En VW, le code peut être exécuté pour plusieurs raisons: - la première expliquée en commentaire et déjà citée par Stef: on utilise une variable qui contient un bloc au lieu d'utiliser explicitement une construction [aBlock value]. la différence est entre ces deux constructions: conditionBlock whileTrue: actionBlock. [conditionBlock value] whileTrue: [actionBlock value]. dans la deuxième, on est sûr que ce sont des blocs de code, donc on peut utiliser une optimisation, dans la première, on envoie le message. - la seconde est plus subtile: si le bloc de code est trop long, l'optimisation du bytecode avec branchements ne peut plus être utilisée (le saut est limité car les instructions de branchement sont codées sur 1 ou 2 octets). Dans ce cas, le compilateur VW abandonne l'optimisation et revient à l'envoi simple de message.
J'aimerai que Squeak en vienne à ce mécanisme qui permet d'instrumenter le code (ajouter des points d'arrêt par exemple, ou autres instructions de déboggage) dans les cas où la limite peut être dépassée.
Notons que l'implémentation Squeak est parfaitement licite et fonctionnera si elle est réellement appelée, tant que l'optimisation du compilateur reste présente: whileTrue: aBlock ^ [self value] whileTrue: [aBlock value]
Il suffit d'exécuter ceci pour s'en convaincre: (BlockClosure>>#whileTrue:) inspect.
J'aimerai que Squeak en vienne à ce mécanisme qui permet d'instrumenter le code (ajouter des points d'arrêt par exemple, ou autres instructions de déboggage) dans les cas où la limite peut être dépassée.
Le truc positif avec Squeak est que tu peux directement l'influencer en proposant des changes
Stef
fait.
Juste une remarque, j'ai modifié dans la section "messages unaires" la phrase qui ne semblait pas claire (votre remarque XXX) car moi aussi au début je ne la comprenait pas.
Loïs
Le dimanche 19 février 2006 à 14:20 +0100, Hilaire Fernandes a écrit :
Loïs Lherbier a écrit :
Pour corriger les fautes, suffit-il de s'inscrire sur Ofset et de modifier le document ? (ou doit on vous prévenir ...)
S'inscrire sur le wiki oui, puis corriger directement.
Hilaire _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
squeak-fr@lists.squeakfoundation.org
-
Bernard Pottier -
Hilaire Fernandes -
Loïs Lherbier -
nicolas cellier -
stéphane ducasse -
Yann Monclair