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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!