Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
May 2013
- 103 participants
- 1562 messages
Re: [Pharo-dev] Reflectivity beta
by Marcus Denker
On May 31, 2013, at 9:04 AM, Norbert Hartl <norbert(a)hartl.name> wrote:
> Sounds great! What happens if a method is recompiled. All metalinks are gone then?
>
Yes, because they have no semantic knowledge other than the AST node.
Starting to match trees to put back links is difficult *and* does not work really, either.
E.g if I put a link
on
self foo.
and then add a second
self foo.
just in front, where will the retained link be?
And them, the new method could be completely different. Maybe the user putting the link did not want it
on all sends called foo, but on all self sends? No way to tell⦠they just do not carry the intention of the developer.
For that one needs higher levels to take care.
The idea is that the links are low-level, you always use them in a managed way. E.g. a line-based
breakpoint would be manage by the debugger, the links in an AOP system would be managed by the
PointCut (which declaratively specifies where to put links). Edit method --> level above puts links again.
In the *long* term I want Pharo to not manipulate text but ASTs directly, in this case it is easy to maintain the
links as the AST does not change. But this is Pharo5 or so ;-)
But even that does not remove then need of higher levels. Because if the user put links on all ivar accesses, the
code I add will not magically have those links even in this case, because the existing do not encode the intention
"I want links on all Ivar access".
Marcus
May 31, 2013
Re: [Pharo-dev] Reflectivity beta
by Camille Teruel
On 31 mai 2013, at 09:03, Norbert Hartl wrote:
> Sounds great! What happens if a method is recompiled. All metalinks are gone then?
Yes indeed. If you have the method:
foo
self bar
with a metalink on the message node and you recompile it to:
foo
self
qux;
bar;
bar.
then it is hard to tell which node(s) should adopt the metalink because there is no way to tell which #bar message of the second version is the one from the first version.
I would love to have an editor where you manipulates ast nodes directly.
With such an editor the developer would have feedback of where the metalinks are.
In the underlying model, AST nodes would have an equivalence relation to say whether two nodes are different versions the same or not.
This model could also be really useful for versioning and diff too.
>
> Norbert
>
> Am 30.05.2013 um 18:15 schrieb Camille Teruel <camille.teruel(a)gmail.com>:
>
>> Hello everyone,
>>
>> Reflectivity beta is out !
>>
>> Reflectivity is a tool that permit to annotate AST nodes with "metalinks".
>> You can put metalinks at different "positions":
>> before: the metalink is executed before the node
>> instead: the metalink is executed instead the node
>> after: the metalink is executed after the node
>> onError: the metalink is executed only if the execution of the node raises an error
>> onSuccess: the metalink is executed only if the execution of the node raises no error
>>
>> When you put metalinks on some node of a method's AST, a wrapper is installed in place of the method. When executed, this wrapper compiles an expanded version of the AST that takes metalinks into account and install the resulting compiled method.
>>
>> Examples:
>>
>> increaseAllNumbersIn: aCompiledMethod
>> "A method that increases all numbers in aCompiledMethod"
>> aCompiledMethod reflectiveAST
>> forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ]
>> putInstead: [ :node | RFMetalink fromExpression: (node value + 1) asString ].
>>
>> removeMetalinksIn: aCompiledMethod
>> aCompiledMethod reflectiveAST removeAllMetalinks
>>
>> In nautilus, you have a menu entry called 'Edit metalinks' that permit to edit the metalinks of the node corresponding to the selected piece of code.
>> As an example use case, another entry called 'Put breakpoint' adds a metalink that corresponds to 'Halt now' before the selected node.
>>
>> Remember that it is a beta, so you might find errors and things are likely to change.
>>
>> You can load Reflectivity with:
>>
>> Gofer it
>> smalltalkhubUser: 'RMoD' project: 'Reflectivity';
>> configuration;
>> loadDevelopment
>>
>> Or you can download it from RMoD's CI:
>> https://ci.inria.fr/rmod/job/Reflectivity/
>>
>> Camille
May 31, 2013
Re: [Pharo-dev] Running coverage breaks the VM
by Guillermo Polito
Actually, from CoInterpreter:
addNewMethodToCache: class
"Override to refuse to cache other than compiled methods.
This protects open PICs against having to test for compiled methods."
(objectMemory isOopCompiledMethod: newMethod) ifFalse:
[primitiveFunctionPointer := #primitiveInvokeObjectAsMethod.
^self].
super addNewMethodToCache: class
On Fri, May 31, 2013 at 9:20 AM, Guillermo Polito <guillermopolito(a)gmail.com
> wrote:
> Ahh, that's why the code in CoInterpreter I was looking didn't match the C
> code :D. Was looking at the wrong place, hehe.
>
> Igor, why do you say that this method should be reached only with vanilla
> compiled methods? From the comment I understand
>
> "For interpreter performance and to ease the objectAsMethod
> implementation eagerly
> evaluate the primtiive, i.e. if the method is cogged and has a
> primitive /do not/ evaluate
> the machine code primitive, just evaluate
> primitiveFunctionPointer directly."
>
> And in #addNewMethodToCache: there is as a first statement:
>
> [...]
> (objectMemory isOopCompiledMethod: newMethod)
> ifTrue:
> [primitiveIndex := self primitiveIndexOf: newMethod.
> primitiveFunctionPointer := self functionPointerFor: primitiveIndex
> inClass: class]
> ifFalse:
> [*primitiveFunctionPointer := #primitiveInvokeObjectAsMethod*].
> [...]
>
> So I'd say that both objects as methods and primitives are kind of handled
> in the same way after?
>
>
>
> On Fri, May 31, 2013 at 2:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote:
>
>> On 30 May 2013 20:06, Guillermo Polito <guillermopolito(a)gmail.com> wrote:
>> > Ok, I was playing with flushing caches and stuff... Its still a bit
>> obsure
>> > to me why the example in the workspace works and the code coverage
>> doesnot.
>> >
>> > However, I managed to hack the VM to make it work :).
>> >
>> > It looks like the VM is treating the objects as methods, as cog
>> methods. So
>> > I added the following validation in the commonSend:
>> >
>> > methodHeader2 = longAt((GIV(newMethod) + BaseHeaderSize) + (HeaderIndex
>> <<
>> > ShiftForWord));
>> >
>> > if (isCogMethodReference(methodHeader2) &&
>> > isCompiledMethodHeader(methodHeader2)) {
>> >
>> > /* begin externalizeIPandSP */
>> >
>> > assert((((usqInt)localIP)) != (ceReturnToInterpreterPC()));
>> >
>> > GIV(instructionPointer) = oopForPointer(localIP);
>> >
>> > GIV(stackPointer) = localSP;
>> >
>> > GIV(framePointer) = localFP;
>> >
>> > executeCoggedNewMethodmethodHeader(1, methodHeader2);
>> >
>> > }
>> >
>> >
>> > And it works :).
>> >
>> > I cc Eliot, so maybe he has an idea...
>> >
>> I touched this code.
>>
>> Original:
>>
>> CoInterpreter>>internalExecuteNewMethod
>> <inline: true>
>> "For interpreter performance and to ease the objectAsMethod
>> implementation eagerly
>> evaluate the primtiive, i.e. if the method is cogged and has a
>> primitive /do not/ evaluate
>> the machine code primitive, just evaluate
>> primitiveFunctionPointer directly."
>> primitiveFunctionPointer ~= 0 ifTrue:
>> [| succeeded |
>> self isPrimitiveFunctionPointerAnIndex ifTrue:
>> [^self internalQuickPrimitiveResponse].
>> "slowPrimitiveResponse may of course context-switch. If
>> so we must
>> reenter the
>> new process appropriately, returning only if we've
>> found an
>> interpreter frame."
>> self externalizeIPandSP.
>> succeeded := self slowPrimitiveResponse.
>> instructionPointer = cogit ceReturnToInterpreterPC
>> ifTrue:
>> [instructionPointer := self iframeSavedIP:
>> framePointer].
>> self internalizeIPandSP.
>> succeeded ifTrue:
>> [self return: self popStack toExecutive: true.
>> self browserPluginReturnIfNeeded.
>> ^nil]].
>> "if not primitive, or primitive failed, activate the method"
>> (self methodHasCogMethod: newMethod)
>> ifTrue: [self iframeSavedIP: localFP put: localIP
>> asInteger.
>> instructionPointer := cogit
>> ceReturnToInterpreterPC.
>> self externalizeFPandSP.
>> self activateCoggedNewMethod: true.
>> self internalizeIPandSP]
>> ifFalse: [self internalActivateNewMethod]
>>
>> Now in subclass (NBCoInterpreter)
>> i made this:
>>
>> internalExecuteNewMethod
>> <inline: true>
>> "For interpreter performance and to ease the objectAsMethod
>> implementation eagerly
>> evaluate the primtiive, i.e. if the method is cogged and has a
>> primitive /do not/ evaluate
>> the machine code primitive, just evaluate
>> primitiveFunctionPointer directly."
>>
>> | methodHeader |
>>
>> methodHeader := self rawHeaderOf: newMethod.
>>
>> (self isCogMethodReference: methodHeader) ifTrue: [
>> self externalizeIPandSP.
>> self executeCoggedNewMethod: true methodHeader:
>> methodHeader.
>> "we never reach here"
>> ].
>>
>> primitiveFunctionPointer ~= 0 ifTrue:
>> [| succeeded |
>> self isPrimitiveFunctionPointerAnIndex ifTrue:
>> [^self internalQuickPrimitiveResponse].
>> "slowPrimitiveResponse may of course context-switch. If
>> so we must
>> reenter the
>> new process appropriately, returning only if we've
>> found an
>> interpreter frame."
>> self externalizeIPandSP.
>> succeeded := self slowPrimitiveResponse.
>> instructionPointer = cogit ceReturnToInterpreterPC
>> ifTrue:
>> [instructionPointer := self iframeSavedIP:
>> framePointer].
>> self internalizeIPandSP.
>> succeeded ifTrue:
>> [self return: self popStack toExecutive: true.
>> self browserPluginReturnIfNeeded.
>> ^nil]].
>> "if not primitive, or primitive failed, activate the method"
>> (self methodHasCogMethod: newMethod)
>> ifTrue: [self iframeSavedIP: localFP put: localIP
>> asInteger.
>> instructionPointer := cogit
>> ceReturnToInterpreterPC.
>> self externalizeFPandSP.
>> self activateCoggedNewMethod: true.
>> self internalizeIPandSP]
>> ifFalse: [self internalActivateNewMethod]
>>
>> ===
>> The intent of change was:
>> - if method is cog method, execute it (the jited code takes care to
>> call primitive, if it there)
>>
>> The old code logic was:
>> - run primitive if it there
>> - and only then, if no prim/or prim failed, try to run a jited code
>> (but entry point is to the first bytecode of method,
>> not to its start)
>>
>> This (old) logic prevents from using primitive 220 properly, because
>> it is a "meta-primitive" - a marker
>> that says that given method should:
>> - always be jited
>> - actual primitive is taken by copying machine code from compiled
>> method trailer into CogMethod's primitive section.
>> Therefore executing prim 220 (a C function) ~~ invoking method's
>> primitive (a machine code generated by image).
>>
>> Still i cannot understand why code reaching this point, when a result
>> of lookup is not a compiled method, but arbitrary object, because
>> everything even in original code says: VM enters this method only if
>> it found 100% vanilla guaranteed CompiledMethod, and not something
>> which pretends to be it.
>> As i understand , the logic to handle object-as-method is in method
>> lookup.. but not in internalExecuteNewMethod, because VM can "execute"
>> the only thing it knows, and it is CompiledMethod.
>>
>> Your test says, that Cog does something extra (some magic, which i
>> failed to grasp) with object-as-method,
>> like generating special kind of CogMethod which sends #run:as:in: message
>> to it.
>>
>> I would like to hear Eliot's comments on this.
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>
>
May 31, 2013
Re: [Pharo-dev] Running coverage breaks the VM
by Guillermo Polito
Ahh, that's why the code in CoInterpreter I was looking didn't match the C
code :D. Was looking at the wrong place, hehe.
Igor, why do you say that this method should be reached only with vanilla
compiled methods? From the comment I understand
"For interpreter performance and to ease the objectAsMethod
implementation eagerly
evaluate the primtiive, i.e. if the method is cogged and has a
primitive /do not/ evaluate
the machine code primitive, just evaluate primitiveFunctionPointer
directly."
And in #addNewMethodToCache: there is as a first statement:
[...]
(objectMemory isOopCompiledMethod: newMethod)
ifTrue:
[primitiveIndex := self primitiveIndexOf: newMethod.
primitiveFunctionPointer := self functionPointerFor: primitiveIndex
inClass: class]
ifFalse:
[*primitiveFunctionPointer := #primitiveInvokeObjectAsMethod*].
[...]
So I'd say that both objects as methods and primitives are kind of handled
in the same way after?
On Fri, May 31, 2013 at 2:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote:
> On 30 May 2013 20:06, Guillermo Polito <guillermopolito(a)gmail.com> wrote:
> > Ok, I was playing with flushing caches and stuff... Its still a bit
> obsure
> > to me why the example in the workspace works and the code coverage
> doesnot.
> >
> > However, I managed to hack the VM to make it work :).
> >
> > It looks like the VM is treating the objects as methods, as cog methods.
> So
> > I added the following validation in the commonSend:
> >
> > methodHeader2 = longAt((GIV(newMethod) + BaseHeaderSize) + (HeaderIndex
> <<
> > ShiftForWord));
> >
> > if (isCogMethodReference(methodHeader2) &&
> > isCompiledMethodHeader(methodHeader2)) {
> >
> > /* begin externalizeIPandSP */
> >
> > assert((((usqInt)localIP)) != (ceReturnToInterpreterPC()));
> >
> > GIV(instructionPointer) = oopForPointer(localIP);
> >
> > GIV(stackPointer) = localSP;
> >
> > GIV(framePointer) = localFP;
> >
> > executeCoggedNewMethodmethodHeader(1, methodHeader2);
> >
> > }
> >
> >
> > And it works :).
> >
> > I cc Eliot, so maybe he has an idea...
> >
> I touched this code.
>
> Original:
>
> CoInterpreter>>internalExecuteNewMethod
> <inline: true>
> "For interpreter performance and to ease the objectAsMethod
> implementation eagerly
> evaluate the primtiive, i.e. if the method is cogged and has a
> primitive /do not/ evaluate
> the machine code primitive, just evaluate
> primitiveFunctionPointer directly."
> primitiveFunctionPointer ~= 0 ifTrue:
> [| succeeded |
> self isPrimitiveFunctionPointerAnIndex ifTrue:
> [^self internalQuickPrimitiveResponse].
> "slowPrimitiveResponse may of course context-switch. If
> so we must
> reenter the
> new process appropriately, returning only if we've found
> an
> interpreter frame."
> self externalizeIPandSP.
> succeeded := self slowPrimitiveResponse.
> instructionPointer = cogit ceReturnToInterpreterPC ifTrue:
> [instructionPointer := self iframeSavedIP:
> framePointer].
> self internalizeIPandSP.
> succeeded ifTrue:
> [self return: self popStack toExecutive: true.
> self browserPluginReturnIfNeeded.
> ^nil]].
> "if not primitive, or primitive failed, activate the method"
> (self methodHasCogMethod: newMethod)
> ifTrue: [self iframeSavedIP: localFP put: localIP
> asInteger.
> instructionPointer := cogit
> ceReturnToInterpreterPC.
> self externalizeFPandSP.
> self activateCoggedNewMethod: true.
> self internalizeIPandSP]
> ifFalse: [self internalActivateNewMethod]
>
> Now in subclass (NBCoInterpreter)
> i made this:
>
> internalExecuteNewMethod
> <inline: true>
> "For interpreter performance and to ease the objectAsMethod
> implementation eagerly
> evaluate the primtiive, i.e. if the method is cogged and has a
> primitive /do not/ evaluate
> the machine code primitive, just evaluate
> primitiveFunctionPointer directly."
>
> | methodHeader |
>
> methodHeader := self rawHeaderOf: newMethod.
>
> (self isCogMethodReference: methodHeader) ifTrue: [
> self externalizeIPandSP.
> self executeCoggedNewMethod: true methodHeader:
> methodHeader.
> "we never reach here"
> ].
>
> primitiveFunctionPointer ~= 0 ifTrue:
> [| succeeded |
> self isPrimitiveFunctionPointerAnIndex ifTrue:
> [^self internalQuickPrimitiveResponse].
> "slowPrimitiveResponse may of course context-switch. If
> so we must
> reenter the
> new process appropriately, returning only if we've found
> an
> interpreter frame."
> self externalizeIPandSP.
> succeeded := self slowPrimitiveResponse.
> instructionPointer = cogit ceReturnToInterpreterPC ifTrue:
> [instructionPointer := self iframeSavedIP:
> framePointer].
> self internalizeIPandSP.
> succeeded ifTrue:
> [self return: self popStack toExecutive: true.
> self browserPluginReturnIfNeeded.
> ^nil]].
> "if not primitive, or primitive failed, activate the method"
> (self methodHasCogMethod: newMethod)
> ifTrue: [self iframeSavedIP: localFP put: localIP
> asInteger.
> instructionPointer := cogit
> ceReturnToInterpreterPC.
> self externalizeFPandSP.
> self activateCoggedNewMethod: true.
> self internalizeIPandSP]
> ifFalse: [self internalActivateNewMethod]
>
> ===
> The intent of change was:
> - if method is cog method, execute it (the jited code takes care to
> call primitive, if it there)
>
> The old code logic was:
> - run primitive if it there
> - and only then, if no prim/or prim failed, try to run a jited code
> (but entry point is to the first bytecode of method,
> not to its start)
>
> This (old) logic prevents from using primitive 220 properly, because
> it is a "meta-primitive" - a marker
> that says that given method should:
> - always be jited
> - actual primitive is taken by copying machine code from compiled
> method trailer into CogMethod's primitive section.
> Therefore executing prim 220 (a C function) ~~ invoking method's
> primitive (a machine code generated by image).
>
> Still i cannot understand why code reaching this point, when a result
> of lookup is not a compiled method, but arbitrary object, because
> everything even in original code says: VM enters this method only if
> it found 100% vanilla guaranteed CompiledMethod, and not something
> which pretends to be it.
> As i understand , the logic to handle object-as-method is in method
> lookup.. but not in internalExecuteNewMethod, because VM can "execute"
> the only thing it knows, and it is CompiledMethod.
>
> Your test says, that Cog does something extra (some magic, which i
> failed to grasp) with object-as-method,
> like generating special kind of CogMethod which sends #run:as:in: message
> to it.
>
> I would like to hear Eliot's comments on this.
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
May 31, 2013
Re: [Pharo-dev] Reflectivity beta
by Norbert Hartl
Sounds great! What happens if a method is recompiled. All metalinks are gone then?
Norbert
Am 30.05.2013 um 18:15 schrieb Camille Teruel <camille.teruel(a)gmail.com>:
> Hello everyone,
>
> Reflectivity beta is out !
>
> Reflectivity is a tool that permit to annotate AST nodes with "metalinks".
> You can put metalinks at different "positions":
> before: the metalink is executed before the node
> instead: the metalink is executed instead the node
> after: the metalink is executed after the node
> onError: the metalink is executed only if the execution of the node raises an error
> onSuccess: the metalink is executed only if the execution of the node raises no error
>
> When you put metalinks on some node of a method's AST, a wrapper is installed in place of the method. When executed, this wrapper compiles an expanded version of the AST that takes metalinks into account and install the resulting compiled method.
>
> Examples:
>
> increaseAllNumbersIn: aCompiledMethod
> "A method that increases all numbers in aCompiledMethod"
> aCompiledMethod reflectiveAST
> forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ]
> putInstead: [ :node | RFMetalink fromExpression: (node value + 1) asString ].
>
> removeMetalinksIn: aCompiledMethod
> aCompiledMethod reflectiveAST removeAllMetalinks
>
> In nautilus, you have a menu entry called 'Edit metalinks' that permit to edit the metalinks of the node corresponding to the selected piece of code.
> As an example use case, another entry called 'Put breakpoint' adds a metalink that corresponds to 'Halt now' before the selected node.
>
> Remember that it is a beta, so you might find errors and things are likely to change.
>
> You can load Reflectivity with:
>
> Gofer it
> smalltalkhubUser: 'RMoD' project: 'Reflectivity';
> configuration;
> loadDevelopment
>
> Or you can download it from RMoD's CI:
> https://ci.inria.fr/rmod/job/Reflectivity/
>
> Camille
May 31, 2013
Re: [Pharo-dev] RPackage and overrides
by Norbert Hartl
Am 31.05.2013 um 02:56 schrieb Igor Stasenko <siguctua(a)gmail.com>:
> ohohoho.. selector namespaces.. sounds like using nuclear weapon to
> get rid of cockroaches:
You know that cockroaches are the ones that will survive a nuclear strike ? :)
Norbert
May 31, 2013
Re: [Pharo-dev] Reflectivity beta
by Marcus Denker
On May 31, 2013, at 8:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote:
> Amazing!
> Pharo 3.0 will be another big step forward
>
Yes! This is starting to be a lot of fun⦠:-)
Marcus
May 31, 2013
Re: [Pharo-dev] Reflectivity beta
by Camille Teruel
On 31 mai 2013, at 07:42, Clément Bera wrote:
> This is impressive !
>
> Does it work with Opal only or also with the old Compiler ?
It compiles with Opal. Opal also need to be the default compiler if you want to debug the generated methods.
>
>
> 2013/5/30 Camille Teruel <camille.teruel(a)gmail.com>
> Hello everyone,
>
> Reflectivity beta is out !
>
> Reflectivity is a tool that permit to annotate AST nodes with "metalinks".
> You can put metalinks at different "positions":
> before: the metalink is executed before the node
> instead: the metalink is executed instead the node
> after: the metalink is executed after the node
> onError: the metalink is executed only if the execution of the node raises an error
> onSuccess: the metalink is executed only if the execution of the node raises no error
>
> When you put metalinks on some node of a method's AST, a wrapper is installed in place of the method. When executed, this wrapper compiles an expanded version of the AST that takes metalinks into account and install the resulting compiled method.
>
> Examples:
>
> increaseAllNumbersIn: aCompiledMethod
> "A method that increases all numbers in aCompiledMethod"
> aCompiledMethod reflectiveAST
> forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ]
> putInstead: [ :node | RFMetalink fromExpression: (node value + 1) asString ].
>
> removeMetalinksIn: aCompiledMethod
> aCompiledMethod reflectiveAST removeAllMetalinks
>
> In nautilus, you have a menu entry called 'Edit metalinks' that permit to edit the metalinks of the node corresponding to the selected piece of code.
> As an example use case, another entry called 'Put breakpoint' adds a metalink that corresponds to 'Halt now' before the selected node.
>
> Remember that it is a beta, so you might find errors and things are likely to change.
>
> You can load Reflectivity with:
>
> Gofer it
> smalltalkhubUser: 'RMoD' project: 'Reflectivity';
> configuration;
> loadDevelopment
>
> Or you can download it from RMoD's CI:
> https://ci.inria.fr/rmod/job/Reflectivity/
>
> Camille
>
>
>
> --
> Clément Béra
> Mate Virtual Machine Engineer
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
May 31, 2013
Re: [Pharo-dev] Reflectivity beta
by Denis Kudriashov
Amazing!
Pharo 3.0 will be another big step forward
2013/5/30 Camille Teruel <camille.teruel(a)gmail.com>
> Hello everyone,
>
> Reflectivity beta is out !
>
> Reflectivity is a tool that permit to annotate AST nodes with "metalinks".
> You can put metalinks at different "positions":
>
> - before: the metalink is executed before the node
> - instead: the metalink is executed instead the node
> - after: the metalink is executed after the node
> - onError: the metalink is executed only if the execution of the node
> raises an error
> - onSuccess: the metalink is executed only if the execution of the
> node raises no error
>
>
> When you put metalinks on some node of a method's AST, a wrapper is
> installed in place of the method. When executed, this wrapper compiles an
> expanded version of the AST that takes metalinks into account and install
> the resulting compiled method.
>
> Examples:
>
> increaseAllNumbersIn: aCompiledMethod
> "A method that increases all numbers in aCompiledMethod"
> aCompiledMethod reflectiveAST
> forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ]
> putInstead: [ :node | RFMetalink fromExpression: (node value + 1)
> asString ].
>
> removeMetalinksIn: aCompiledMethod
> aCompiledMethod reflectiveAST removeAllMetalinks
>
> In nautilus, you have a menu entry called 'Edit metalinks' that permit to
> edit the metalinks of the node corresponding to the selected piece of code.
> As an example use case, another entry called 'Put breakpoint' adds a
> metalink that corresponds to 'Halt now' before the selected node.
>
> Remember that it is a beta, so you might find errors and things are likely
> to change.
>
> You can load Reflectivity with:
>
> Gofer it
> smalltalkhubUser: 'RMoD' project: 'Reflectivity';
> configuration;
> loadDevelopment
>
> Or you can download it from RMoD's CI:
> https://ci.inria.fr/rmod/job/Reflectivity/
>
> Camille
>
May 31, 2013
Re: [Pharo-dev] Reflectivity beta
by Clément Bera
This is impressive !
Does it work with Opal only or also with the old Compiler ?
2013/5/30 Camille Teruel <camille.teruel(a)gmail.com>
> Hello everyone,
>
> Reflectivity beta is out !
>
> Reflectivity is a tool that permit to annotate AST nodes with "metalinks".
> You can put metalinks at different "positions":
>
> - before: the metalink is executed before the node
> - instead: the metalink is executed instead the node
> - after: the metalink is executed after the node
> - onError: the metalink is executed only if the execution of the node
> raises an error
> - onSuccess: the metalink is executed only if the execution of the
> node raises no error
>
>
> When you put metalinks on some node of a method's AST, a wrapper is
> installed in place of the method. When executed, this wrapper compiles an
> expanded version of the AST that takes metalinks into account and install
> the resulting compiled method.
>
> Examples:
>
> increaseAllNumbersIn: aCompiledMethod
> "A method that increases all numbers in aCompiledMethod"
> aCompiledMethod reflectiveAST
> forAllNodes: [ :node | node isLiteral and: [ node value isNumber ] ]
> putInstead: [ :node | RFMetalink fromExpression: (node value + 1)
> asString ].
>
> removeMetalinksIn: aCompiledMethod
> aCompiledMethod reflectiveAST removeAllMetalinks
>
> In nautilus, you have a menu entry called 'Edit metalinks' that permit to
> edit the metalinks of the node corresponding to the selected piece of code.
> As an example use case, another entry called 'Put breakpoint' adds a
> metalink that corresponds to 'Halt now' before the selected node.
>
> Remember that it is a beta, so you might find errors and things are likely
> to change.
>
> You can load Reflectivity with:
>
> Gofer it
> smalltalkhubUser: 'RMoD' project: 'Reflectivity';
> configuration;
> loadDevelopment
>
> Or you can download it from RMoD's CI:
> https://ci.inria.fr/rmod/job/Reflectivity/
>
> Camille
>
--
Clément Béra
Mate Virtual Machine Engineer
Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
May 31, 2013