> On 6 Mar 2018, at 16:04, ci-pharo-ci-jenki...@inria.fr wrote:
> There is a new Pharo build available!
> The status of the build #657 was: FAILURE.
> The Pull Request #1024 was integrated: "21491 Simplify
> #testAllButFirstNElements and #testAllButLastNElements"
> Pull request url: https://github.com/pharo-project/pharo/pull/1024
> Issue Url: https://pharo.fogbugz.com/f/cases/21491
> Build Url:
I restarted the build and it was now green!
This actually contains more PRs...
21478 Improve ThreadSafeTranscript isSelfEvaluating (detail / githubweb)
20258 Fix to make recursive links work Add test for 20258 (detail / githubweb)
21483 Cleanup romanNumber and add test (detail / githubweb)
21491 Simplify testAllButFirstNElements, testAllButLastNElements (detail /
21501 remove NautilusGroupAutoBuilder (detail / githubweb)
21506 add back two lost inspector extensions (detail / githubweb)
for 20258 Fix to make recursive links work:
This is work done with Benoit Verhaeghe to finally get meta-links work in deep
Imagine you want to do something even on methods like #new. But that something
for sure will call
#new again in the code that you call...
With the PR, now a link that calls #new can be installed on Behavior>>#new:
link := MetaLink new
metaObject: [ Object new ];
(Behavior>>#new) ast link: link.
... and it does not lead to a recursion.
The "level: 0" means that we are only interested in base-level execution. Every
time a link activates, the "level"
increases. E.g. if it is put to 1, the link would be active in the meta-level
You can inspect Behavior>>#new and see what kind of code we create at the
bytecode level. This is of course slower than
just calling a method, so one should only use this mechanism if really needed,
and we need to see if this can be optimised.
For now this does not take into account any process forking happening on the
Meta Level, this needs to be analyzed in
the future (past versions just made sure the state is inherited).
But that should be a rare case and should make the whole thing more usable