Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-07-19

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 colomon joined #moarvm
01:29 JimmyZ .tell FROGGS I'd like to s/MVM_get_bigint/get_bigint/g
01:36 FROGGS_ joined #moarvm
04:43 birdwindupbird joined #moarvm
06:10 FROGGS_ JimmyZ: yes, sure
06:10 JimmyZ FROGGS_: :P
06:11 FROGGS_ :o)
06:11 JimmyZ FROGGS_: what's your next?
06:11 FROGGS_ sprintf I think
06:11 FROGGS_ bbi15
06:12 JimmyZ \o/
06:35 FROGGS_ joined #moarvm
06:53 FROGGS JimmyZ: there are other candidates to rename I think, some C-functions in bigintops.c still start with nqp_
06:57 JimmyZ FROGGS: I thought I renamed
07:00 FROGGS JimmyZ: ahh yes, my editor window wasnt up-to-date
07:00 FROGGS awesoem!
07:00 JimmyZ :-)
08:44 jnthn by sprintf you mean, whatever is needed to get src/HLL/sprintf.nqp to build/work on Moar?
08:44 FROGGS jnthn: correct
08:53 JimmyZ exception!
08:55 jnthn Yes, getting 44-try-catch.t passing is my Moar goal for the next couple of days :)
08:55 JimmyZ it'd be very nice :P
08:56 jnthn $dayjob today is some fun...playing with reactive programming stuff :)
08:56 JimmyZ jnthn: fixing assgin should be LHF for you? :P
08:57 jnthn JimmyZ: yeah, want me to look at that?
08:57 JimmyZ jnthn: yes
08:57 JimmyZ fixing it should make 67-container.t pass
08:58 JimmyZ :P
09:02 * JimmyZ guesses jnthn++ play with Reactive programming stuff in a game
09:05 donaldh joined #moarvm
09:32 jnthn JimmyZ: nah, actually digging deeper into Rx.
09:34 * JimmyZ deson't know what is Rx :(
09:35 jnthn JimmyZ: http://msdn.microsoft.com/en-us/data/gg577609.aspx
09:35 JimmyZ oh,  LINQ
09:36 jnthn JimmyZ: It's like doing map and grep and so forth, but instead of pulling things from a data source iterator style, new data items get pushed through the query
09:37 jnthn JimmyZ: I went through how to build a very tiny subset of this stuff in Perl 6 in http://jnthn.net/papers/2013​-yapcna-grammar-generate.pdf
09:39 JimmyZ ah, I saw it, but I ignored the Rx part
09:40 JimmyZ or forgot ...
09:41 jnthn That talk contained quite a lot of ideas :)
09:41 JimmyZ yeah
10:03 arnsholt That talk was a bit scary, in general =)
10:06 jnthn It wasn't intended to be... ;)
10:07 jnthn But I guess lazy lists, combinators on observable streams, grammars, meta-programming, ASTs and backtracking are quite a lot in 40 minutes... :)
10:39 colomon joined #moarvm
11:08 colomon joined #moarvm
11:31 cognominal joined #moarvm
12:49 colomon joined #moarvm
13:09 colomon joined #moarvm
13:10 benabik joined #moarvm
15:25 colomon joined #moarvm
15:44 diakopter hi #moarvm crowd
15:49 colomon joined #moarvm
15:50 FROGGS hi diakopter
15:50 diakopter FROGGS: hi! how are you
15:52 FROGGS fine... $work is done for today :o)
15:52 FROGGS so, hunting home... see you in a bit
15:52 jnthn o/ diakopter
16:12 diakopter jnthn: howdy
16:26 FROGGS joined #moarvm
16:44 diakopter FROGGS: that was quick hunting
16:45 diakopter or... apparently a lot more time passed than I realized
16:45 diakopter o_O
16:47 FROGGS diakopter: I just need 10 minutes to walk home :o)
16:49 timotimo sounds like a nice place to work
16:49 FROGGS I like it, yes
16:51 FROGGS jnthn: when I put this in NQPHLL.nqp is isnt executed: nqp::bindcurhllsym('sprintf', -> $format, @arguments { nqp::say("something") });
16:51 timotimo there's a place with lots of bureaus and stuff very close to my home. i'm secretly hoping i'll find work there after my university so i can stay in my little apartment and not have to move far at all for work
16:52 jnthn FROGGS: When are you expecting it to be executing?
16:52 FROGGS but it gets executed when I put that in ModuleLoader.pm... why doesnt work the former?
16:52 jnthn FROGGS: Is anything doing a use NQPHLL?
16:52 FROGGS hmmm
16:52 FROGGS good point
16:52 FROGGS :D
17:22 FROGGS $ nqp nqp-moar-cc.nqp -e 'use NQPHLL'
17:22 FROGGS Merging GLOBAL symbols failed: duplicate definition of symbol CompileTimeValue
17:22 FROGGS <--- sad FROGGS is sad
17:23 FROGGS I guess it is from the "use QRegexMoar" ?
17:23 FROGGS brb
17:25 jnthn Hm.
17:25 jnthn Maybe as a hack shove it in the setting for now or something.
17:36 prammer joined #moarvm
18:19 FROGGS k, will try
18:32 diakopter jnthn: re part 3 of 3 "JIT compilation takes time"
18:32 diakopter not if you cache EVERYTHING! :)
19:23 diakopter <656chat>
19:24 diakopter jnthn: ahoy
19:25 diakopter lizmat: ahoy
19:25 lizmat diakopter /o
19:25 jnthn dobry vecer
19:26 diakopter heh /o
19:26 TimToady diakopter: but...cache coherency *is* an off-by-one error!  :P
19:27 jnthn so is cache coherency :P
19:27 TimToady the information is off by one level from where it should be...
19:27 TimToady caches are an off-by-one error :)
19:27 diakopter jnthn: I'm considering this a continuation [delimited? we'll never know!] of the previous discussion on the extension ops
19:28 jnthn ok
19:28 * jnthn recalls approving of some design, or something :)
19:28 diakopter heh
19:28 diakopter I pushed the written version
19:28 TimToady reminds me of the saying: The only problem with virtual memory is that it's not real memory.
19:28 diakopter we talked a bit about it
19:28 jnthn Yeah, it got merged, eys?
19:29 jnthn (the doc...)
19:29 colomon joined #moarvm
19:29 diakopter hm
19:29 diakopter I think so
19:29 diakopter so it's set in stone! no take-backs!
19:30 diakopter newaze
19:31 diakopter jnthn: so, there'd be a moarvm (well, nqp-mvm, as opposed to -pvm, -jvm, -clr) extension called p5embed or p5interop or something
19:31 * diakopter stops saying jnthn:
19:32 jnthn Living in the MoarVM repo?
19:32 diakopter initially I'm just thinking about interop with nqp
19:33 diakopter hm
19:33 jnthn Yes, starting with NQP can be a good idea. Especially as we have some of NQP running on Moar already.
19:33 diakopter well, ending up being a separate system-level package is the goal
19:33 diakopter (as opposed to two versions of the same moarvm binary)
19:34 jnthn *nod*
19:34 jnthn Some kinda so or dll
19:34 diakopter right, built against the local libperl [even statically bound, meh
19:34 diakopter []
19:34 diakopter ]
19:35 diakopter so the compiled form would be the .so or .dll, which could of course have a .moarvm embedded
19:35 diakopter (or not)
19:35 diakopter (doesn't matter, as I see it)
19:36 jnthn *nod*
19:36 jnthn We can probably find a way to not need that easily enough
19:36 diakopter depends how you want to have ModuleLoader work
19:36 jnthn but if we do I guess it's OK
19:36 jnthn *nod*
19:36 diakopter it can look for native libs too..
19:36 jnthn I think I'd prefer it to not need to do that.
19:36 diakopter which
19:36 jnthn I suspect that wants to be explicit
19:37 diakopter which would you prefer not to do what
19:37 jnthn But I can imagine loading a moarvm thing that is the "loader" for the P5 interop and has support code, etc.
19:37 jnthn Prefer not to embed MoarVM bytecode in a dll/so
19:37 diakopter ok; sgtm
19:37 jnthn nqp::loadbytecode should really just go looking for bytecode.
19:38 jnthn I think I'd like a loadmoremoar op for loading extensions...
19:38 diakopter so the .moarvm or .mvm or whatever (let's call its module moarp5 for now) has a dependency on the module NativeCall
19:38 diakopter oh
19:39 diakopter hm.
19:39 jnthn Oh, though you were pondering doing it with nativecall
19:39 diakopter well
19:39 jnthn I dont think full-blown Perl 6 NativeCall should be involved.
19:39 diakopter now that you mention it
19:39 jnthn We could do it with the NQP ops
19:39 diakopter yes, that's what I [shoudl have] meant
19:39 diakopter :)
19:39 jnthn But I could equally go with Moar extensions being things that declare a particular symbol
19:39 jnthn Like node extension modules do.
19:39 diakopter yeah
19:40 jnthn And we can give it a table of func pointers that let it install stuff.
19:40 diakopter I guess if it's going to be that low-level anyway..
19:40 jnthn REPRs, ops...
19:40 jnthn Yeah, that feels simpler to me than trying to wire it all through NativeCall.
19:41 diakopter k
19:41 diakopter sgtm
19:41 jnthn Though may cost us a binary compat policy at some point.
19:41 jnthn Though...we will have that anyway.
19:41 jnthn (simple design)++ anyway
19:42 diakopter well, as long as it *could* all still be done through NativeCall I'm happy
19:42 diakopter well, that'd be a special thing anyway. ergh.
19:42 diakopter whatevs.
19:43 jnthn Well, it means you don't have to block on native call stuff to work on p5interop too ;)
19:43 diakopter true.. if no function pointers actually need resolved
19:44 diakopter well anyway, dynload is there anyway
19:44 diakopter so that much is done
19:44 diakopter so, the source code of this would be an .nqp file
19:44 diakopter hm.
19:45 * diakopter wonders if all the C can be generated from some C/preprocessor hybrid.. maybe name it XS or something
19:45 diakopter <- kill kill kill
19:46 diakopter actually.
19:46 jnthn no no no no no
19:46 jnthn :P
19:47 diakopter maybe there could be a .build in addition to the .load and .enter frames
19:47 * diakopter goes all starry-eyed
19:48 * TimToady imagines diakopter imagining Van Gogh...
19:49 diakopter jnthn: actually I'm seeing that there could be a way to declaratively provide the stuff to generate the necessary C.. via NativeCall eventually, but there can be lower-level ones to start
19:49 jnthn .oO( almost emo enough to be a Van Goth... )
19:51 * TimToady pictures a moving van painted black and white, with maybe a bit of red if it's starting to recover
19:52 jnthn diakopter: Sure, let's not yak shave more than needed...
19:52 diakopter .. and you don't even need a C parser to look for the headers; you just assume all teh types are just plain right.
19:54 diakopter jnthn: I guess I'm looking for the "write code that runs stuff from C libraries in only one file" idea, like luajit's
19:54 diakopter except in this case, s/runs/compiles/
19:55 diakopter oh, I see how to do it
19:55 diakopter just make NativeCall compiler-aware, so if it runs at INIT/BEGIN time, but then notices it's being compiled, it injects/emits the proper stuff
19:56 diakopter but anyway that can come later. I'm happy with the state of the pipe-dream-in-the-pie-in-the-sky for now
19:57 diakopter s/it's/its outer module is/
19:58 TimToady I hear Ken Thompsen knows something about this technique. :)
19:59 * diakopter wants to know
19:59 diakopter [I'm sure I've heard/read it before a thousand times, but still forgot]
20:00 TimToady *son
20:00 TimToady http://c2.com/cgi/wiki?TheKenThompsonHack
20:01 diakopter ok yes
20:04 diakopter well, what I was suggesting wasn't trying to hide anything.. but I can see the resemblance, yes
20:07 diakopter jnthn: no comments?
20:08 jnthn diakopter: Not really, if you're happy enough doing the magic on-load C function approach for now and we explore more clever things later.
20:08 diakopter oh yes.
20:12 TimToady .oO(Do the simplest thing that could possibly break; then fix it.)
20:13 diakopter .. I mean, you might as well make quine() a built-in
20:14 TimToady .oO(Do the simplest thing that could possibly break; then teach it to fix itself.)
20:15 * diakopter watches TimToady's slightly-corrupted quine iterate
20:15 TimToady .oO(The rolling stone gets the worm.)
20:16 TimToady .o(A penny saved is a penny.)
20:19 jnthn diakopter: So, what next?
20:19 diakopter jnthn: :)
20:20 diakopter okay, so the bytecode extension does the things to load the shared/dynamic library and install the function pointers and their signatures as extension ops
20:20 diakopter so in this case, there's tons and tons of C that's not generated, of course
20:23 diakopter jnthn: so, where does the C that installs the reprs get installed
20:23 * diakopter suddenly realizes you could actually write entire REPRs in HLL code using that continuation trick wrapper
20:24 diakopter (against p6opaques that are their own reprs)
20:24 diakopter let's call that TIE
20:24 diakopter for no apparent reason
20:25 jnthn No, the continuation trick really needs you to be int eh runloop...
20:25 diakopter right, the invoke repr op is in the runloop ;)
20:25 diakopter (this would be a p6opaqueTIED or whatever ;)
20:25 jnthn I'm not sure on installation yet...
20:26 diakopter you'd need low-level thingies to wire it up
20:26 jnthn I'm not a good person to work on that.
20:26 diakopter :D :D :D okay, I get your point :P
20:27 diakopter actually yes.
20:27 diakopter this is absolutely needed.
20:28 diakopter anyway, back to non-dreamfantasyland
20:29 * TimToady realizes he's just been heckling, and wanders off to do something non-non-productive...
20:30 diakopter .oO( when you can't tell the difference between egging and egging on... )
20:30 diakopter *being egged and *being egged on
20:31 diakopter jnthn: I think I'll start with the refs table
20:32 diakopter each p5 interpreter needs a table [make it two-level doubling so it never needs realloc'd] of pointers to MVMObjects
20:33 diakopter these are the references the moar gc will update when moving stuff
20:34 diakopter there is a separate row for each reference held by a live p5 scalar
20:35 diakopter er.
20:35 diakopter actually no.
20:35 jnthn OK, so from p5 we never hold a direct object reference?
20:35 diakopter each row has a refcount, sorry, I forgot
20:36 diakopter er, hang on; lemme look at the notes from my discussion with nwc10 instead of trying to re-derive it all
20:41 * diakopter reads the notes, blinks, and re-derives it all anyway
20:47 cognominal joined #moarvm
20:52 diakopter jnthn: okay, I'm done thinking; u still there? :)
20:52 jnthn sure
20:54 diakopter okay, yes.
20:55 diakopter so anyway, each p5 interpreter has its own OS thread (and also its corresponding MVMThreadContext)
20:58 diakopter a pointer to the MVMThreadContext's corresponding MVMThread object (each has one currently; that could be changed somewhat when .. other stuff happens ;) is stored in that p5 interpreter globally somehow
20:58 diakopter either a pointer on a magic on a global, or a pointer represented as a p5 number in a global, or something equally dangerous
20:59 diakopter er.
20:59 diakopter nm, that's not necessary actually.
21:00 diakopter easier just to store it inside the row for the reference
21:00 diakopter no wait, I'm confusing myself.
21:01 diakopter yes, there is a p5 global that stores it
21:03 diakopter anyway, to create a reference in p5 to something in moarvm, we will always be inside code called from the moarvm interpreter/runloop
21:03 diakopter I mean.
21:03 diakopter ARGH
21:03 diakopter how embarrassing.
21:04 diakopter anyway, gimme a sec
21:04 diakopter yes, okay, that's right.
21:05 diakopter this is about passing an MVMObject to p5 land
21:06 jnthn Right, which implies we're coming from Moar
21:08 diakopter so at that point, we know in which p5 interpreter we're allocating an SV, so we do that by creating an svref to that global value storing the link to the threadcontext, then blessing that svref to a particular p5 package (more on this later), then adding a magic to that svref that stores the pointer to the reference row in that refs table for the object we're wrapping
21:09 diakopter in this manner, we'll always have a handle to the right threadcontext from an SV, and it knows how to find the moar referent
21:10 diakopter so the moar gc just assumes that if there's a value in that refs table, that pointer is live
21:10 jnthn Right, it's a root
21:12 diakopter so, the object has a DESTROY method/magic that decrements our refcount in this refs table when that svref is collected by p5
21:13 diakopter .. and if it gets decremented to zero, the row is erased (well, prepended to the freelist, but yes.
21:13 diakopter )
21:13 diakopter (obviously it's incremented when the ref is taken)
21:14 diakopter can also just have 1 row for every reference so you don't have to use a hash on each reference taking to find the row
21:14 diakopter that's probably easier and simpler.
21:14 diakopter sure, why not.
21:17 diakopter oh, you know what
21:18 diakopter a table's unnecessary
21:18 diakopter a doubly-linked list suffices, and is much better.
21:18 diakopter duh..
21:19 diakopter jnthn: okay, with me so far?
21:19 diakopter doubly-linked list of roots
21:22 jnthn Seems fine
21:22 diakopter jnthn: so, the p5 package into which this svref is blessed is VERY magical (in the p5 sense)
21:22 jnthn Doubly linked list saves a layer...
21:23 diakopter this thing has all the TIE methods implemented, all the overload.pm operations implemented, and AUTOLOAD
21:23 colomon joined #moarvm
21:24 jnthn magical indeed!
21:25 diakopter and there's a version of it for each 6model STable that's wrapped
21:25 diakopter we can worry about naming those packages later
21:26 diakopter there's only a separate version just so the names can be distinct and helpfully meaningful; there doesn't otherwise need to be separate ones, except for optimization potential
21:26 diakopter the packages don't need to expose the p6 meta object stuff as if it's a p5 metaobject api
21:27 diakopter I talked about this at length with stevan
21:27 diakopter he seemed to agree...
21:27 diakopter no need to try to present a unified metaobject api from both directions
21:28 jnthn *nod*
21:28 jnthn That probably is more easily bridged in Perl 5 / Perl 6 code.
21:28 jnthn At a guess.
21:28 diakopter *shrug*
21:29 diakopter at the least, it means you don't have to worry about universally replacing universal isa and such
21:29 diakopter but yeah.
21:30 diakopter so, since you'd be running them from p5 code, all the reserved all-uppercase names for the TIE methods (and DESTROY, CLONE, etc) are just that... reserved
21:31 diakopter if you want to try to run a 6model method with those names, prepend it with 6model_* and AUTOLOAD dtrt
21:31 diakopter (same for if you want run a method name starting with 6model_ ... )
21:32 diakopter (note, this AUTOLOAD is an xsub..)
21:32 diakopter AH YES
21:32 diakopter this is what we talked about before.
21:32 jnthn We may want to make it p6_ :)
21:33 diakopter how to map the various tied accessors and overload.pm operations to 6model metaobject
21:33 diakopter k
21:33 jnthn 6model is an implementation thing :)
21:33 diakopter the question is how magical do you want it
21:33 diakopter because you can always require everything to be explicitly implemented by special name
21:34 diakopter the example we talked about before was the "" stringification in overload.pm mapping to .Str on most objects
21:35 diakopter how did you want to do that?
21:36 diakopter have a "p5setup" method on each metaobject/type that sets up the mappings?
21:36 diakopter or something more declarative?
21:38 jnthn Hmm
21:39 * diakopter waits while you cogitate on that
21:39 jnthn Well, I guess it's associated with HLL config in some sense.
21:40 diakopter how? :)
21:40 jnthn But since we just care about P5/P6 here we can always just say "well, it calls .Str"
21:40 jnthn These days, all types get tagged with the HLL they belong to
21:40 diakopter yeah but, the 50 others?
21:40 jnthn Maybe that bit is not in Moar yet.
21:40 diakopter I dunno
21:40 jnthn But these days we know that an object declared in perl 6 is from Perl 6 and can find its HLL config.
21:41 diakopter yeah but not all the mappings to p6 are the same, are they?
21:42 donaldh joined #moarvm
21:43 diakopter afk 10 min
21:43 diakopter jnthn: we're about 15% through my notes
21:43 diakopter &
21:43 jnthn Can you point me at a list of the overloads?
21:45 diakopter 5.8.3 is as far back as I'm thinking this'll support http://search.cpan.org/~nwcla​rk/perl-5.8.3/lib/overload.pm
21:46 diakopter afk 15 min for real &
21:48 jnthn OK, but if we consider
21:48 jnthn "=="
21:48 jnthn Our current language is Perl 5, and operators are tied up with language.
21:48 jnthn So that's just .Num on each operand
21:49 jnthn And then the "normal" meaning of ==
21:49 jnthn 'bool' can go thorugh the boolificatin protocol
21:49 jnthn 0+ is just numeric
21:50 jnthn "<>" is, uh, harder...
21:50 jnthn And the deferenencing ones are kinda...weird ;)
21:51 diakopter jnthn: right, a lot of them can use the default implementation probably
22:20 diakopter jnthn: back
22:21 diakopter jnthn: I think the dereferencing ones would just return themselves, unless the object is truly a Scalar
22:21 diakopter (in which case it returns a wrapper of the thing it holds)
22:23 diakopter jnthn: can we try to work on talking through mroe before you get too sleepy
22:25 jnthn yeah...let's do a bit more, but I think if we were at 15% before it's gonna spill over to tomorrow :)
22:27 colomon joined #moarvm
22:30 diakopter jnthn: well, to finish up the p6 from p5,
22:33 diakopter for calls into moarvm from p5, it simply uses the same OS thread and MVMThreadContext as the one the p5 interpreter is on
22:33 diakopter HOWEVER
22:34 diakopter if that call then needs to call back into p5, it self-decapitates
22:34 diakopter sort of.
22:34 diakopter if it needs to call back into a different p5 interpreter, it simply blocks
22:34 diakopter (while callign the other thread)
22:35 diakopter if it needs to call back into the same one, it backs out of the moarvm runloop entirely, *and* *then* backs out of the xsub entirely using the CallAsOp extension from nothingmuch
22:35 diakopter creating a trampoline in the optree
22:36 diakopter so then when it returns from *that* p5 call, the trampoline undoes its thing
22:36 diakopter then the moar interpreter re-enters where it left off
22:36 diakopter seem ok so far?
22:37 jnthn Does this mean we can potentially get two MoarVM interpreters on the C stack?
22:37 diakopter no
22:37 diakopter that whole OS thread is just p5, then optionally moar
22:37 jnthn moarvm interp => call into p5 => calls...what?
22:37 jnthn Oh
22:37 jnthn got it
22:38 diakopter well there's some kind of event loop outside p5,
22:38 diakopter but that's an implementation detail not relevant to the interpreter really
22:39 diakopter so, there's that
22:39 diakopter need exception catching at those boundaries
22:39 diakopter in both languages
22:40 diakopter and the exception traversers need to know how to traverse those virtual callstacks
22:40 diakopter (including nested ones hidden by the CallAsOp trick)
22:41 jnthn *nod*
22:41 jnthn yeah, that'll be "fun" :)
22:41 diakopter jnthn: here's how you would handle the gather/take scenario of multiple co-recursive cross-vm calls
22:42 diakopter well.
22:42 diakopter I'm not sure how to handle that yet.
22:43 diakopter might need to spawn new threads for each cross-vm descent :(
22:43 diakopter anyway
22:44 diakopter I can explain the p6->p5 much more quickly and clearly; I've spent much more time on that
22:45 diakopter but there's also a lot more of it
22:45 * diakopter hurries
22:45 diakopter all there is is 1 extension op
22:45 diakopter mvmp5::code
22:46 diakopter mvmp5::code(str)
22:46 diakopter mvmp5::code w(obj) r(str) to be precise
22:46 diakopter there's a special case of it when the code is a single use statement (no args!)
22:46 diakopter i'll get to that
22:47 diakopter anyway, there are few REPRs
22:47 diakopter the main one is MVMP5Val
22:48 diakopter it holds a pointer to the SV and a pointer to the MVMThread of the p5 interpreter that owns the memory
22:48 diakopter that's all it needs
22:48 jnthn So it knows which p5 interpreter to run the thing on, if it's a code object, I guess?
22:49 diakopter yeah
22:49 diakopter and also whether to crap if you try to pass a wrapped p5 object from a different interpreter
22:49 diakopter also, carp
22:50 diakopter (as an arg to a code object I mean)
22:50 diakopter so, when wrapping an SV, it DOUBLE increments the refcount of the SV
22:51 diakopter why, you might ask? ;)
22:51 diakopter WINK WINK WINK
22:51 diakopter for safe freeing of the reference from the moar side
22:52 diakopter so moar can know for sure that it holds the last reference to the object when it decrements it
22:52 diakopter (the second time)
22:52 jnthn *nod*
22:52 jnthn Makes sense.
22:52 jnthn At least, feels sensible... :)
22:52 diakopter (so it can run any custom destructors during that gc run)
22:52 diakopter or however we do that
22:52 diakopter (more on that later)
22:53 diakopter so anyway, the mvmp5::code extop simply passes the string to p5 to eval to a CV
22:53 diakopter then wraps it in an MVMP5Val that knows it's invokable (repr invoke op) by the fact it's a CV
22:54 diakopter the repr invoke op on MVMP5Val is .... humongous
22:54 diakopter getting to that.
22:55 diakopter jnthn: oh I forgot
22:55 jnthn (STable invoke hook rathe than repr op, I guess...)
22:55 diakopter the p5 packages for wrapped moar objects do need an autoload for the case of static/class method calls)
22:56 diakopter I thought "repr op" was "Stable hook"
22:56 diakopter (but yes)
22:58 diakopter so, the metaobject of p5vals has a special find_method - instead of returning an MVMCode or whatever
22:59 diakopter it returns an MVMP5Val that wraps a PV
22:59 diakopter a string of the method name
22:59 diakopter so that when its invoke STable hook is run, it sends the method name to p5 that way, by sv_call_method or whatever
23:00 diakopter so the only check there in ->invoke is whether the SV pointer is null, a CV, or a PV
23:01 diakopter er, it won't be null
23:01 diakopter anyway..
23:02 diakopter actually the only other repr is MVMP5Package
23:03 diakopter which is a jacked-up 6model type object
23:03 * diakopter hand waves
23:03 diakopter you can guess the purpose of that
23:04 diakopter for importing symbols from p5 package names, it needs to install them to type objects
23:04 * diakopter reluctantly moves on to importing symbols and that mess
23:04 diakopter ok, so
23:04 jnthn What is the PV case of invoke?
23:05 diakopter a string of the method name
23:05 jnthn Not sure about MVMP5Package right off...
23:05 jnthn Remember type objects don't have any state.
23:06 diakopter right.. but they need to refer to some STable that has the name and such
23:06 diakopter why would I be thinking they needed state
23:07 jnthn Well, you don't need a representation then...just use Unintantiable or so.
23:07 jnthn *Uninstantiable
23:07 diakopter ah okay
23:07 diakopter sgtm
23:07 jnthn (which is what package/module in Perl 6 use, fwiw)
23:08 diakopter oh, heh
23:08 diakopter okay, so, the other special case of the PV case of MVMP5Val invoke
23:08 diakopter is "use PackageName"
23:09 diakopter if someone tries to use a p5 module, let's first talk about simply "require" (run-time)
23:09 diakopter and then generalize that to the run-time in teh compile-time of BEGIN blocks
23:10 diakopter so if someone does that, code is generated to create the args to the use statement
23:10 diakopter and pass them into the mvmp5::code("use PackageName")
23:11 diakopter however, it also passes in a special arg
23:11 diakopter prepended to the args
23:11 diakopter representing the "stash" (some view of teh currently-compiling World) of the outer symbol table
23:12 diakopter in this manner, special auditing code will track the state of the symbol table before it goes into the use statement and how it looks when it comes out
23:12 diakopter and make the corresponding changes, including declaring variables
23:13 jnthn wait, if we're considering runtime there's no currently compiling World?
23:13 diakopter er, oops, I jumped ahead, yes. :)
23:13 jnthn ok :)
23:13 diakopter well, let's just call that the general case then
23:13 jnthn The model so far is more that modules "return" the set of symbols they're exporting, fwiw.
23:14 jnthn And then they get installed back in World.
23:14 diakopter right, but you can't do that in p5
23:14 jnthn I don't know if such an arrangement can be done/faked up for p5?
23:14 jnthn OK, what's the reason, ooc?
23:14 diakopter that's effectively what it's doing
23:14 diakopter faking that up
23:14 diakopter okay, I didn't know about that retun
23:14 diakopter return
23:14 jnthn OK, but can we get away with faking up an empty pad?
23:14 diakopter so yeah, just have it do that. :)
23:14 jnthn Well, module loads return UNIT :)
23:15 jnthn Approximately-ish :)
23:15 jnthn It's a bit more involved than that.
23:15 diakopter sounds smoppy
23:15 jnthn yeah
23:15 diakopter (aka straightforward)
23:15 jnthn If we can get back something hashish of the symbols the p5 use is exporting to us, we're good.
23:15 diakopter actually there's not much more
23:16 jnthn What about arrays and hashes?
23:16 diakopter well we do need to pass in some state of teh current world
23:16 diakopter becaues sometimes EXPORT does different things depending on what's already there
23:16 diakopter <FROWN>
23:16 jnthn urgh!
23:17 diakopter lizmat or TimToady can confirm...
23:17 diakopter eh, it's probably a rare enough case to ignore or whatever
23:17 diakopter ok, you convinced me.
23:17 diakopter what about arrays and hashes?
23:18 diakopter last time we talked about having default types in teh hllconfig for those
23:18 diakopter (instead of just mapping the STable hooks directly)
23:20 jnthn *nod*
23:21 diakopter so..
23:21 diakopter we'll need to include a couple more things if you really want args to DTRT when passed to p5 stuff
23:22 diakopter (flatten like p5)
23:22 jnthn *nod*
23:22 diakopter I *do* think this is how it should be done
23:22 diakopter well.
23:22 jnthn Does that feel like something we can worry about once the basics work?
23:22 diakopter yeah
23:23 diakopter it's simply including some metadata accessible at runtime from teh compiler about ordering of args in case it ends up being a p5 invocation
23:24 diakopter jnthn: actually there's just one issue we haven't talked about that's not kindof obviously proceeding from the rest of what we discussed
23:24 diakopter according to my notes
23:25 diakopter oh wait.
23:25 diakopter yeah this brings up another issue actually
23:25 diakopter that I'd back-burnered
23:26 diakopter where to do the coercion of p5 args to p6 ones
23:27 diakopter can't do it where it is currently
23:27 diakopter well, maybe
23:27 jnthn hmmm
23:27 jnthn Where is it currently and why not?
23:28 * jnthn wonders if we're gonna hit the same problems smartmatch does in Perl 5 when trying to give things Perl 6 types...
23:29 diakopter well, you're passing in a blessed svref of an mvmobject with a '""' overload (.Str), and you need to invoke that during coercion
23:29 diakopter (or even just normal p5 stringification)
23:29 diakopter it breaks the no-nested runloop thing potentially
23:30 diakopter unless it fakes up another level of continuation stuff
23:30 diakopter .. which is fine I guess
23:31 diakopter yeah, I guess we were gonna have to do that anyway
23:32 diakopter so that's a little fiddly, but not too much
23:34 diakopter well
23:34 diakopter it could also emulate the CallAsOp trick, I suppose
23:35 diakopter and fallback to an external bytecode version of the arg flattening/coercion routine
23:35 diakopter which would also work and be cleaner
23:36 diakopter meh.
23:38 diakopter jnthn: well I think that's it
23:39 diakopter there's a whole 'nother layer of fanciness to be done when we start to consider inline p5 blocks
23:40 diakopter .. which are very different from simple p5 code->CV
23:41 jnthn yeah
23:41 jnthn But module level and eval would already be an awesome start.
23:41 diakopter what we'll end up needing are large swaths of scalars representing lexical slots, to which p5 STORE/FETCH tied methods are attached
23:42 diakopter (and then must have those scalars sync their values back to their corresonponding lexical slots right before p6 code is re-entered (in any thread!)
23:42 diakopter )
23:43 diakopter that's the only way to do it without changing p5 code
23:43 diakopter changing p5, I mean
23:43 diakopter changing perl, I mean
23:43 diakopter :D
23:44 diakopter but inline p5 code is certainly a showy luxury
23:44 diakopter you can always write your own accessors and such and eval your way through it
23:50 jnthn yeah
23:50 jnthn FROGGS++ work can probably tell us much about where the boundaries are even if we then hand the parsed code off to Perl 5 too.
23:55 diakopter exactly.
23:55 diakopter that's exactly what I was envisioning using that for

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary