On Mar 6, 2013, at 8:25 AM, Gerhard R. <gerd.r.de...@googlemail.com> wrote:
> As requested by jkeenan, I'll outline my reasons for removing the > mentioned code from the sixparrot branch. > > First, anything that's not used by NQP or Rakudo can be ripped out in > principle - which of course doesn't mean that we necessarily should do > so: > > Things like 'vm-level' bindings like LLVM could prove useful in the > future and should be left alone. > > However, 'user-level' bindings like OpenGL and SDL need not be kept around: > > The idea behind Parrot linking against everything under the sun was > that if it does that, the language implementations on top of it need > not do so. > > But dynamic languages have moved on from compile-time bindings, and > Rakudo is a case in point here: It provides runtime bindings via > dyncall, which is shipped with NQP and does not depend on Parrot's > NCI. rakudo threw away our libffi binding because 1. libffi had troubles on windows (which is unfair. libfffi works on much more platforms than dyncall, is actively maintained together with gcc, and has an easier interface. the windows problem was a problem of a single dev. no one else has it), and 2. our nci interface was rotten in one of the latest rewrite/throw-away sessions. does rakudo really want to keep their suboptimal and hardly maintained dyncall library? And even if they prefer dyncall over libfii, why cannot we keep the better library and just fix the harm done (i.e. runtime signature parsing). if parrot throws away the ffi binding for no apparent reason, no single language besides rakudo will show interest. guaranteed. > Now for the DynLexPad PMC. > > Again, it's not used by NQP and Rakudo, and I believe even the > ordinary LexPad needs to go: > again technical concerns: our lexpad works, rakudos lexpad is broken with threads. your solution: throw away the ones which works. my iproposal: optimize our lexpad pmc in the same way rakudo did it, and rakudo does not need to maintain theirs. > If our main focus is no longer providing convenient hooks for > different HLLs but rather Rakudo performance, allocating a PMC *on* > *every* *call* just so we can stash a LexInfo pointer is pointless. > (The custom Perl6LexPad does a bit more, but the Parrot-provided > counterpart already resides in the CallContext and could be replaced > with the Perl6 version). _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
