Le ven. 30 nov. 2018 à 10:31, Marcus Denker <marcus.den...@inria.fr> a écrit : > > > > > On 29 Nov 2018, at 12:55, Thierry Goubier <thierry.goub...@gmail.com> wrote: > > > > Le jeu. 29 nov. 2018 à 11:15, Marcus Denker <marcus.den...@inria.fr> a > > écrit : > >> > >> > >> > >>> On 29 Nov 2018, at 10:45, Thierry Goubier <thierry.goub...@gmail.com> > >>> wrote: > >>> > >>> Hi Manuel, > >>> > >>> would that extend to testing what happens if you add many, many > >>> metalinks in a method? > >>> > >> > >> yes, it would be nice to test that. > >> > >> > >>> I tried to rewrite the automated code tracer I had to use metalinks, > >>> and I gave up once I discovered that going over a certain number of > >>> metalinks in a method would stop working. > >>> > >> > >> > >> If you add a lot of code, you need to use the new byte code set as the old > >> one is extremely limited for everything (number of temps, jump offset…) > > > > Well, it failed before that limit; once the context was complex > > enough, it would fail in various ways, such as being unable to bind to > > the proper temporary, writing incorrect byte sequences, and so on > > > > I think the changes we did will make that better… > > > As anyway, it was injecting the same code that my tracer was already > > doing, but in a less debuggable way, so I sort of gave up and kept > > MetaLink use to simpler things, such as a type checker that inject > > type checks on arguments based on the type inferred from arguments > > names. > > > > Now, when I see how you're improving metalinks in this thread, I'd be > > interested in a higher view (source-level) of the transformations > > you're doing for implementing metalinks: I think they then could be > > reused in different contexts (i.e. refactorings, for example), or > > generalised outside Smalltalk itself. It may probably already been > > expressed that way, but I haven't looked into the metalink code > > itself. > > > > For now it is implemented as a special compiler (with “self emitAfter: > aNode”) added in overriden methods of the main compiler. > > I made the mistake of doing some stuff (after links, for example) directly in > the IR level, that did not work. > > Now this is fixed for all but the links for Sequences (to be done later). > > Steven did a version that is based on AST transformation only, we will > explore that direction further in the future.
Interesting, so this would be the one I'd like to see (because I implemented with AST transforms). Would you have a link to his work? Mine is on github, and the version I did at UBO was on the VisualWorks AST. Thierry > Marcus
