2012/4/29 Angel Java Lopez <[email protected]>

> Hola gente!
>
> El anio pasado pude presentar en Smalltalks 2011 un compilador open source
> de .st a .js (Javascript). Ahora estoy trabajando en una VM open source
> directamente en Javascript, basada en bytecodes, que hasta ahora ejecuta
> tanto en el servidor (Node.js en mi caso) como en el browser. Ya estoy
> parseando y compilando a bytecodes gran parte de un fileOut de Pharo/Squeak
> (podria pasar a compilar a Javascript, como el anio pasado, creo, pero por
> ahora que sea bytecodes ;-)
>
> Todavia no tuve que usarlo, pero ya otras veces me encontre con codigo
> como este en Pharo:
>
> !ProtoObject methodsFor: 'apply primitives' stamp: 'ajh 1/31/2003 22:20'!
> tryNamedPrimitive
> "This method is a template that the Smalltalk simulator uses to
> execute primitives. See Object documentation whatIsAPrimitive."
>  <primitive:'' module:''>
> ^ ContextPart primitiveFailToken! !
>
> !ProtoObject methodsFor: 'apply primitives' stamp: 'ajh 1/31/2003 22:20'!
> tryNamedPrimitive: arg1
> "This method is a template that the Smalltalk simulator uses to
>  execute primitives. See Object documentation whatIsAPrimitive."
> <primitive:'' module:''>
>  ^ ContextPart primitiveFailToken! !
>
>
> No pude encontrar para que esta <primitive:'' module:''> y eso de que es
> un template. Entiendo lo que es <primitive: 110> es decir con nro, pero no
> se que es eso de arriba, por mas que encontre lo de Object documentation
> whatIsAPrimitive, no encontre como funciona eso de tener primitive con '' y
> module:.
>
>

Hola. ESOS metodos en particular tryNamedPrimitive*  son un hack para
solucionar un tema en particular. Basicamente, cuando se debuggean metodos
con named primitives (las primitivas de los plugins). Por mas mira:
http://marianopeck.wordpress.com/2011/07/06/named-primitives/

Justamente, yo arregle eso en Pharo 1.4 y las volé todas al carajo ;)
Agarra una imagen Pharo 1.4 o 2.0 y mira el metodo:

withoutPrimitiveTryNamedPrimitiveIn: aCompiledMethod for: aReceiver
withArgs: arguments
de hecho, mira que puse un gran comentario:

withoutPrimitiveTryNamedPrimitiveIn: aCompiledMethod for: aReceiver
withArgs: arguments
"When using the debugger we want to run a method step by step. What what
happens when we do a step into a CompiledMethod which has a primitive? If
such a method is executed form outside the Debugger (normal scenario) the
VM knows that such CompiledMethod has a primitive declaration and hence
executes it. If it fails then it continues executing all the bytecode of
the method. Otherwise, it just returns.

Now, what is the problem with the Debugger? The problem is that if the
primitive fail, we don't want that the VM directly executes all the
remaining bytecodes of the method. Instead, we would like to go step by
step witht he Debugger, just as happens with normal methods.

To solve the mentioned problem, we use the following trick: We have the
orignal compiled method (the one that has a primitive invokation), the
receiver and the arguments. So the idea is to use a template compiled
method that ONLY contains the primitive delcaration (it doesn't include all
the smalltalk code after the primitive). #tryNamedPrimitiveTemplateMethod
answers such a template method which looks like:

tryNamedPrimitive
    <primitive:'' module:''>
    ^ ContextPart primitiveFailToken'

 Since this method does not change its bytecodes for every invokation, we
can reuse it for all methods with primitives. There are only 2 things we
have to change in the template: the number of arguments and the primitive
declaration (to use the correct primitive name and module name).

Then what we do is to run that compiled method with the receiver and
arguments we have. The result is that we will be invoking almost the same
original method but a slighly different version that does not have the
smalltalk part after the primitive and that in contrast is sends
#primitiveFailToken. If this method invokation does not fail, then the
Debugger continues debugging the sender of the primitive method. In this
case, the step in is the same as step over. If the primitive fails, then
the debugger continues executing the smalltalk part after the primitive
method. In this case, step in is a real step in.  "


cualquier cosa chiflá

saludos


Ya que estoy, aprovecho y pregunto otra cosa: el formato de fileOut de
> Pharo/Squeak, es el mas "normal", aceptado en el mundo Smalltalk? Hoy vi al
> pasar que hay otros formatos, que parecen depender del dialecto (puede ser
> que Dolphin tiene otro formato de fileout?)
>
> Gracias por cualquier info!
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>  --
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
>
> http://www.clubSmalltalk.org




-- 
Mariano
http://marianopeck.wordpress.com

-- 
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]

http://www.clubSmalltalk.org

Responder a