Howdy, This is a great level of detail! Please keep it up :)
Duke On Tue, Jul 23, 2013 at 11:40 AM, Paweł Murias <pawelmur...@gmail.com> wrote: > While trying to get QASTNode.nqp to compile I noticed a strange error > claiming that some code refs where missing from the serialization context. > By binarysecting the file (deleting line till the error goes away) it turned > out that roles in modules where causing problems. Serializing roles requires > serializing a closure, and modules are special that they require to be > compiled twice, both to JavaScript and PIR (that is untill we are fully > boostraped). > The thing that turned out to be causing trouble is that the JavaScript > backend is using a slightly different bootstraping procedure. > The way Jonathan did it was to compile a given file first to pir and > starting the compiler again and compiling to the JVM (or in our case > JavaScript). A special --stable-sc option is used to make sure the ids of > the serialization context match. > That means an object can be deserialized at compile time (for example when > it's loaded from the bytecode file containing the setting). The compiler can > then emit a reference to it (marking which serialization context it was > loaded from and under which index it's stored it). When we then load it at > runtime from an serialization context kept in a javascript file with the > identical id. We assume both the compiler runs where deterministic so the > both of the serialization context have identical content. If we do > nondeterministic things at compile time (like my $foo := BEGIN random()), > bad things will happen, so we don't. > The approach I have taken is to parse the code once, and pass the AST to two > different > backendshttps://github.com/pmurias/rakudo-js/blob/master/bin/compile-setting.nqp > . > The problem with that is both of the backends serialize the serialization > contexts. > And the context serialization code marks attaches some info onto closures. > It really makes sense to serialize the compilation context once (as it's > assumed to be immutable after serialization). > So I set to introduce some caching. > First I tried to but the caching inside > QAST::CompUnithttps://github.com/perl6/nqp/commits/cached-serialization. > Jonathan however felt that I was puting stuff into nodes which shouldn't > concern them. > So I planned a redesign of the serialization opcodes to implement it more > elegantly. Seeing that Jonathan explained that instead of pushing the > changes deeper and deeper I should hack this on without tangling it up with > the rest of the code. > For now I'm using a branch, but it seems to be possible to easily monkey > patch the compiler to introduce a contextual. > > To shake out bugs and find things to test I started writing some unit tests > for bits of qast > https://github.com/pmurias/rakudo-js/blob/master/t/qast-node.t > > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Jonathan "Duke" Leto <jonat...@leto.net> Leto Labs LLC http://letolabs.com 209.691.DUKE http://duke.leto.net @dukeleto _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
