Parrot 0.8.1 "Tio Richie" Released! | www.parrot.org/
Set by moderator on 19 November 2008.
chromatic jonathan, is that Parrot or all MMD running faster? 00:01
jonathan chromatic: I tried out the cache in Rakudo's Perl6MultiSub first. 00:02
chromatic: That was in a dumb "do 50,000 dispatches" benchmark.
I'm looking at how best to do the ops.
I mean, in some senses it's easy to get the cache in somewhere. 00:03
But if we want to avoid all of the marshalling too - which is going to be a big cost too - it's harder.
Thing is, we don't know any more that we'll always be calling a C function from these. 00:04
There could be a PIR sub sat in the dispatch table too.
In which case we _do_ need to marshall 'em.
chromatic Yes, but the MULTI subs in PMCs are always autogenerated. 00:05
jonathan Actually...I wonder if the PMCs have code generated to marshall args through PCC always...
chromatic There's no reason they... exactly.
jonathan Damm.
It's like, optimized to be slow...
chromatic It's optimized to be interoperable.
jonathan True.
That too. 00:06
;-)
chromatic I'm not gonna dog the current design for that.
jonathan But it's hard to make fast.
chromatic Just for not being perfect, yet. Which is where we come in. Brothers from different mothers. And fathers. And motherlands.
jonathan OK, I'll stick the MMD cache in the easy place and see how that helps.
I have to say I'm pretty shocked reading the code and seeing how much work we're doing, though. :-S 00:07
Even if we did have a lightning fast GC.
It makes us wonderfully dynamic, yes, but there's some cost.
chromatic We just need to get it *) cleaner *) faster *) optimizable later. 00:08
Where "faster" means "sufficiently fast that people can build things with it".
jonathan OK, let me see what putting the cache a bit later than I first thought gets us.
00:09 TonyC joined
jonathan I can't avoid the marshalling, but I can avoid the MMD lookup, I think. 00:09
00:09 davidfetter joined
chromatic I think there are ways to avoid marshalling, but I haven't fully formed them in my head yet. 00:10
jonathan Yeah. It's not trivial. 00:11
I didn't realize quite how much things had changed.
And I think even with an MMD cache, that's going to keep costing us, notably.
chromatic Throwing away information to recalculate it later with multiple temporary GCables is expensive for us. 00:12
It'd be expensive even with a G1 GC.
jonathan Right.
chromatic It's like they say: all CS problems are solvable with another layer of cache.
00:12 nopaste joined
jonathan Except perhaps the halting problem. ;-) 00:13
chromatic There should be a G1G1 GC: takes twice as long to run, costs twice as much, and has a keyboard too small for adults to use comfortably.
00:15 cognominal joined 00:39 tak joined 00:43 apeiron joined
Coke chromatic: hurm . still running; something has let one of the tests complete, getting another 368 tests. 00:49
one of the test files, i.e. 00:50
chromatic Does it seem faster? 00:53
Coke yes but i dont trust me
is this patch "more temp pmcs"? 00:54
chromatic No. 00:59
I have another patch which recycles some non-temp PMCs though.
Coke anything holding up application of this patch? 01:06
chromatic I'm conflicted. 01:07
At best, it's a workaround for pervasive performance problems with frequently-recycled garbage in our current GC. 01:08
At worst, it's more code.
jonathan chromatic: Is that the temp PMCs patch you're talking about, or MMD caching?
chromatic It's short and non-intrusive, and you can speed up a hot spot 5 - 10% if you're clever and can find it.
jonathan, it's the non-temp PMCs patch. 01:09
It's also prone to mis-use, if you're not careful, causing subtle problems.
jonathan Ah, OK - I thought Coke was asking about the MMD caching one...not sure though. :-)
chromatic Of course, it also puts a nice friendly and searchable name on the technique, which makes it easier to find and diagnose.
... and we're not likely to have a GC which can cope with such rapid churn in the next few months. 01:10
jonathan Hmm. My cache is never getting hit.
jonathan wonders what he's doing wrong 01:11
chromatic Mine was always getting hit, until I realized that you need the name AND the signature as cache keys. 01:12
jonathan Yeah - yours was in a different place to mine too. :-) 01:13
Did primes2.pir hit yours a lot? 01:14
I'm looking at it and wondering where it does MMD...
oh, I see it
chromatic primes2 hit mine all the time. 01:15
jonathan yeah
I can see why
I thought all the op-based dispatches were through ops.
chromatic Would be nice.
jonathan A bunch go through default.pmc too
Or so it seems. 01:16
Hmm.
I have an array of MMD caches where the indexes are MMD op func numbers.
chromatic Makes me wonder "Do we need these to be vtable entries?"
jonathan Thus avoiding a named lookup... 01:17
It seemed like a good idea at the time. :-|
typedef enum { MMD_USER_FIRST 01:18
} parrot_mmd_func_enum;
Oh.
...so those all went away...
If that's the case, where on earth do the values for the infix ops in math.ops come from? :-S 01:19
chromatic Couldn't tell you. 01:20
That might be why you're not hitting the cache.
jonathan Yes. 01:21
Becuase they're all gone away. And we always call a v-table method. Which in turn does a multi dispatch.
meh
So fine, the array becomes a hash. 01:22
But not tonight.
I've had enough for one day.
chromatic We've learned a lot, had a few laughs. 01:24
jonathan The Rakudo improvements through the cache are a huge win.
I just hope to get a good win elsewhere too.
One slight issue is where to attach the cache to a Parrot MultiSub. 01:25
Since it inherits from ResizablePMCArray, so there's a lack of places to hang anything.
chromatic Maybe it shouldn't inherit from a RPA.
jonathan Perl6MultiSub didn't. 01:26
Well
It *does*
But only because it inherits from MultiSub.
Which I'm not even sure it needs to in order to work, I kinda made the assumption it did without checking.
But it doesn't use the storage slots like a RPA
chromatic MultiSub only does because it's lazy about managing storage space for CONSTANT PMCs. 01:27
jonathan Ah, yeah.
If we chance it, we have to worry about freezing...
*change
chromatic No biggie.
jonathan If you want to take that task, I'm happy to leave that one. ;-) 01:28
chromatic Sounds like we're getting ready to branch.
jonathan We could do this stuff in a branch.
It'd make me feel less awkward about throwing my patch in without huge amounts of testing, so we can spread the load on that. 01:29
chromatic Alright, I'll make a branch tomorrow morning.
jonathan Great.
I'll get the patch worked into a commitable state.
chromatic How compatible is your patch versus mine?
jonathan Given I have a cache per multisub (or name in the case of the ops), not so much. 01:30
chromatic Not a problem.
jonathan Yours may or may not work better for vtable ops. 01:31
OTOH, having one thing that works for all of them is less code.
And less code to maintain is a Good Thing.
chromatic The idea of taking those MMD-type vtable functions away really appeals to me. 01:32
jonathan Yeah.
Why don't we just dispatch right away in the op, is a little curious.
Unless the idea is that you can override the vtable to not multiply dispatch at all. 01:33
chromatic That's a curious inconsistency.
jonathan Indeed.
May be a good reason for it being the way it is. 01:34
chromatic I'll send mail to the list.
01:34 rdice joined
jonathan Good plan. 01:35
Don't want to undo something that's been carefully planned out.
I really hope some way of avoiding the marshalling can be figured out, though.
chromatic This doesn't have the lemony-fresh odor of a careful plan. 01:36
jonathan I can't remember if we hit the MMD straight in the ops before.
(Before the MMD branch)
chromatic I'm trying to get the diff to read, but I'm not sure. 01:42
01:45 AndyA joined
jonathan OK. I need to get some rest now. 01:47
jonathan sleeps
01:56 allison joined 02:02 Andy joined
dalek r32998 | Whiteknight++ | trunk: 02:18
: [Book] Update chapter 4 sections about namespaces and coroutines. Remove information that isn't covered till chapter 5, and foreshadowing about information that was already presented
diff: www.parrotvm.org/svn/parrot/revision?rev=32998
Coke chromatic: 02:25
"2008-11-19 12:51",159,"v0.8.1",57,4001,2341,1059,601,12550
+"2008-11-21 18:01",172,"r32995",58,4461,2709,1117,635,12099
so, it reclaimed a test file (yay!), and ran -slightly- faster.
12099/12550
purl 0.96406374501992
Coke about a 4% speedup
nothing to sneeze at 02:26
chromatic That's all? Hmm. 02:29
MMD isn't your problem the.
then
Andy waves from MilwaukeeDevHouse 02:36
02:50 tak joined 02:51 bacek_ joined
Coke no, I'm pretty sure GC is most of my problem. 03:14
chromatic Do you spend a lot of time in PGE? 03:15
03:21 Psyche^ joined 03:24 jimmy joined 03:34 bacek joined
Coke yes 03:44
1/4 GC, 1/4 PGE, quite a bit in hash buckets...
03:49 Jimmy joined 03:56 Jimmy left 04:02 elmex_ joined
tewk_ lathos: ping 04:07
nopaste "tewk" at 155.97.237.62 pasted "lathos: SQLite_without_C.diff" (105 lines) at nopaste.snit.ch/14687 04:32
pmichaud returns to hack on lex some more. 04:35
tewk_ We should get VMWare to donate some Workstation 6.5 licenses, Then with a bigger hard drive I could run *BSD 04:38
pmichaud yes. Although I already have Workstation 6.5. 04:40
I tried installing *BSD once but it was too painful. 04:41
Infinoid I had dragonflyBSD in qemu for a while. Parrot builds were nice and busted. 04:42
pmichaud .....why oh why do Coroutines have retcontinuations ?!? 04:46
04:52 particle1 joined, particle1 left 04:53 purl joined, Theory joined 04:54 apeiron joined
allison pmichaud: in answer to an earlier question: the only real difference between "full" continuations and retcons is that "full" continuations are expected to be long-lived, while retcons are expected to be short-lived and recycled quickly 04:55
pmichaud what's the advantage of retcons?
allison pmchaud: so, if we have generational GC with a very short-lived generation for call signatures, contexts and retcons, then we have no need for a "special" retcon 04:56
pmichaud: they would just be ordinary continuations in the "young" GC pool
pmichaud what's the advantage of retcons in the current implementation?
allison they're recycled immediately 04:57
pmichaud and that occurs... when they're invoked? What part takes care of that?
allison the invoke vtable function in retcontinuation.pmc 04:58
pmichaud I see a call to VTABLE_destroy there inside of #ifndef NDEBUG
NDEBUG means.... hm.
going to my next question... why do Coroutines have retcontinuations instead of full continuations? 05:01
that seems.... odd.
allison well, there's really no other significant difference between ret continuations and full continuations, so I would guess it's because they're expected to be short-lived 05:02
(retcontinuation could probably have been better named)
pmichaud except that they handle contexts quite differently.
allison really it's just another hackish attempt to avoid putting pressure on the GC system
(a problem that would be better handled by fixing the GC system)
pmichaud I'm fine with that for now. 05:03
I'm just trying to track down the places where I'm running into context leaks and context garbage.
allison what are retcons doing differently?
pmichaud they don't increment the refcount of their context.
or, if they do, they do it very inconsistently.
05:03 jimmy joined
allison ah, just nulling the context rather than reducing the refcount 05:03
welcome to the pain that is refcounting :) 05:04
pmichaud and Parrot_pop_context forces a context to be recycled even if its refcount is non-zero
jimmy When I try to write some pipp function, I alays should do some OS check. i.e if $S0 == 'MSWin32' goto L2
pmichaud right now the situation that I have in the lex4 branch is that I have a Coroutine that has a context where its ->caller_ctx has been recycled. 05:05
jimmy could compiler do optimization for it?
allison pmichaud: lovely... does it work if you replace the Coroutine's retcon with a fullcon? 05:06
pmichaud and I find it odd that a Coroutine holds a retcontinuation -- seems to me that it should've converted all of its callers to Continuations
jimmy When it is compiled .
allison or, is the Coroutine even creating the retcon?
pmichaud I haven't tried that yet because I'm trying to figure out why it wasn't done that way in the first place.
yes, the Coroutine creates the retcon.
allison so switch it, and see what happens
pmichaud will creating a continuation cause all callers to become continuations as well? 05:07
allison possibly yes
05:07 Andy joined
pmichaud (it should, otherwise this won't help. :-) 05:07
jimmy: we aren't ignoring you -- I'm just intensely doing something else at the moment. 05:08
okay, I'll try with a continuation.
allison pmichaud: you may have to take another step to make the retcon promotion happen up the chain
jimmy pmichaud: ok .
pmichaud invalidate_retc_context sounds about right there. 05:09
I'm thinking I'll end up doing that for outer subs, too.
allison pmichaud: yes, that would explicitly promote the whole chain
05:09 Andy joined
pmichaud ....which ultimately makes me wonder if there's a huge amount of advantage to retcons, because when we hit a sub with a lexical environment we just end up converting everything to continuations anyway :-) 05:10
allison pmichaud: it will put pressure on the GC system, but that's temporary
pmichaud: it's the same advantage as keeping contexts as non-PMCs, saving the GC, gaining an edge of speed
pmichaud okay. 05:11
allison only a small edge, though, so they're candidates for the chopping block
pmichaud that part makes some sense to me, definitely.
there's not an equivalent new_continuation_pmc() function that corresponds with new_ret_continuation_pmc. I guess I can just call new_pmc directly for that. 05:13
er, pmc_new
or I could let it create a retcon as it does now, and then call invalidate_retc_context after we switch the interpreter and let it take care of it. 05:14
(creating a continuation also calls invalidate_retc_context, so it's pretty equal.) 05:16
05:18 petdance joined
pmichaud okay, I'm a little confused: In a (ret)continuation, I know that ->to_ctx represents the context we jump to when the continuation is invoked. What's ->from_ctx ? 05:29
allison: ping 05:32
lu_zero pmichaud the context you come from?
(random and wild guess) 05:33
allison pmichaud: ?
pmichaud lu_zero: perhaps, but then invalidate_retc_context doesn't make any sense to me.
the comments for invalidate_retc_context say that we follow the caller chain, but it follows the ->from_ctx pointer at each step
in a retcontinuation, the from->ctx pointer points to the _called_ context, not the _caller_ context. Is that right? 05:34
(the to->ctx would point to the caller context, so that when we invoke the retcontinuation we're returned to the caller.)
allison from_ctx is the context of the thing that invoked the continuation 05:35
pmichaud allison: so, in a retcontinuation, that would be the context of the called function, yes?
allison to_ctx is the context that the continuation will return to
pmichaud: should be, since that's what invokes the retcon 05:36
pmichaud and to_ctx is the context that the continuation will return to
purl i already had it that way, pmichaud.
allison so, following from_ctx is following the caller chain
pmichaud sorry, and to_ctx is the context of the calling function
how is that following the caller chain?
assume I have subs A and B, A calls B
when I invoke B from context A, that constructs a new return continuation that will have from_ctx as B's context and to_ctx as A's context 05:37
so if I follow from_ctx, that just takes me back to B.
it's even that way in the sub.pmc code (more)
allison yes, but B's from_ctx takes you back to A
pmichaud ...how does B's from_ctx take me back to A? 05:38
allison because A invoked B, so B's from_ctx is A
pmichaud no, I'm talking about in the retcontinuation
allison right, but invalidating the ret cons is a chain
pmichaud I understand that it's _supposed_ to be a chain. 05:39
I'm saying we're following the wrong link.
allison and the start of the chain is whatever function invoked the retcon
no, it's the right link
pmichaud The code in sub.pmc is line 265:
PMC_cont(ccont)->from_ctx = context;
context is the context we just created for the called sub (B) in this case
allison in this one case either from_ctx or to_ctx would work, but as a general rule, from_ctx is what you want 05:40
pmichaud ccont is the return continuation we just constructed to stick into B's context
to_ctx points back to the caller context (A in this case)
because when we invoke ccont, we want to go back to A
allison so, you're invalidating the return continuation chain as soon as the sub's return continuation is created? Because at that point it hasn't been invoked, and so from_ctx doesn't make much sense 05:41
pmichaud I'm saying in the general case of normal subs. 05:42
at the point where we invalidate any return continuation chain 05:43
the chain back to the callers is defined by the to_ctx pointers, not the from_ctx pointers
because in each context, its return continuation will always have a from_ctx pointing to the current context
(this is what I read in the code as it's written now.) 05:44
allison pmichaud: what's the original question?
pmichaud my original question is simply this: how does invalidate_retc_context work?
because when I run it now, it's not converting the Coroutine's callers context into a full continuation. 05:45
allison It starts at whatever context is passed in, then loops pulling 'current_cont' from the context and then 'from_ctx' from the continuation 05:49
pmichaud ...but it's a retcontinuation.
(or, at least, it was originally a retcontinuation before we switched its vtable)
allison it then replaces the vtable of the RetContinuation with the vtable of a Continuation
05:49 johbar joined
pmichaud and as a retcontinuation, the from_ctx is the context of the called function. 05:49
allison the first time it encounters a real continuation it breaks the loop and doesn't go any further 05:50
pmichaud i.e., it's the context we're returning from
from_ctx is not the context of our caller
that's to_ctx -- the context we're returning to.
allison from_ctx is the context of B
pmichaud exactly. 05:51
allison right, so it traces up the chain through B to A
pmichaud how?
if from_ctx points to B's context, how do we get to A?
allison B's from_ctx is A
pmichaud B doesn't have a from_ctx
B has a continuation that has a from_ctx 05:52
and you just said that this was poing to B's context.
cont = ctx->current_cont;
ctx = PMC_cont(cont)->from_ctx;
"get the continuation from the current context"
"get the from_ctx pointer of that continuation"
allison you can understand why I'm tempted to unify contexts and continuations... 05:53
this is one of the nastiest parts of the current calling conventions 05:54
digging a bit...
pmichaud what's happening is that we then loop to the top, and since ctx hasn't changed (we're still in the same context) we still have the same value of cont that was just promoted to a full Continuation and so the loop breaks having never gone anywhere. 05:55
it doesn't actually follow the caller chain, it just converts the single context. 05:56
sorry, single continuation.
05:56 bacek joined
allison pmichaud: it follows the from_ctx chain 05:59
pmichaud allison: there is no from_ctx chain
from_ctx doesn't form a chain. 09:59
allison pmichaud: that's the entire point of from_ctx
pmichaud just a sec
allison (though, I'd be willing to accept that some part of the code isn't using from_ctx and to_ctx as it should)
pmichaud src/pmc/sub.pmc:239
ccont = new_ret_continuation_pmc(interp, (opcode_t *)next);
this is inside of Sub.invoke
when I call that function, I get back a new retcontinuation, yes?
src/pmc/sub.pmc:253
context = Parrot_alloc_context(INTERP, sub->n_regs_used);
this creates a new context for the invoked Sub
09:59 ilbot2 joined
moderator Parrot 0.8.1 "Tio Richie" Released! | www.parrot.org/
10:09 contingencyplan joined
dalek r33000 | cotto++ | trunk: 10:12
: [pipp] undo accidental commit in r32999
diff: www.parrotvm.org/svn/parrot/revision?rev=33000
10:13 nadim__ joined
moritz bacek: back online, but you'll see a few hours downtime today :( 10:13
10:17 chromatic joined 10:35 iblechbot joined 10:53 Hadi joined 11:14 Hadi left 11:42 contingencyplan joined 11:52 rdice joined
lathos tewk_: Rock. 11:57
21:48 ilbot2 joined
moderator Parrot 0.8.1 "Tio Richie" Released! | www.parrot.org/
chromatic Alright, I have my variant working. 21:49
Benchmarking now.
jonathan Nice
Even if it doesn't give much difference, it's likely a load cleaner.
21:50 moritz joined
bacek moritz!!! 21:50
purl well, moritz is right, there are a LOT of things like that.
chromatic Yeah, the code gets shorter.
allison jonathan: ok, typing...
purl rumour has it typing is overrated.. "I should get aronud to converting"
21:52 Aisling joined
chromatic Hm. If we have a working cache, avoiding the sort isn't very useful. 22:09
jonathan chromatic: True. ;-) 22:10
chromatic: It'll be a smaller win. 22:11
But still worth doing.
22:12 Limbic_Region joined
allison jonathan: should I expect a pile of compilation errors like: Parrot_mmd_cache_destroy? 22:23
pmichaud migrating to avoid the context pointers looks like it'll take longer than the 3 hours I was setting for myself as an upper limit.
dalek r33012 | fperrad++ | trunk:
: [WMLScript]
: - rewrite with keyed namespace
diff: www.parrotvm.org/svn/parrot/revision?rev=33012
allison jonathan: that is "warning: no previous prototype for ‘Parrot_mmd_cache_destroy’"
jonathan allison: No.
Where are you seeing that?
allison mmdcache branch
do you have a header file not committed? 22:24
chromatic I don't see that error. 22:25
jonathan svn diff shows no differences
pmichaud (trying mmdcache on my box, fresh checkout)
jonathan It's in multidispatch.h
and at the top of multidispatch.c
What file do are you compiling when you see that?
pmichaud mmdcache builds fine here. 22:28
allison tests the patch on trunk instead... 22:30
bacek managed to build mmdcache too
pmichaud ....maybe it'll be enough for me to just eliminate retcontinuation, and fix up the reference counts in continuation. 22:32
somehow I doubt that, though.
allison looks like it was a bizarre conflict between the changes I was making and the changes I 'svn up'd from the branch in the middle 22:38
jonathan oddness
allison pmichaud: I'm just waiting for you to get sick of chasing refcounting bugs and take the plunge to convert contexts to GCable elements. :) It's actually a very simple change, just a lot of annoying search and replace updates. 22:41
bacek pmichaud: let's kill refcount! 22:45
22:45 Coleoid joined
pmichaud fine, I can do that. Want me to eliminate retcontinuation while I'm at it, or keep it? 22:49
and I make no predictions as to what this does to our runtime performance (nor do I want to be blamed for it :-)
bacek make it, make it right, make it fast. 22:52
bacek vote for removing retcontinuation
Plugging Harmony's GC into Parrot is virtually impossible... 22:55
allison pmichaud: try killing refcount first, certainly, it may solve the current problem
bacek: (re Harmony) that was my impression, it just wasn't designed to be used outside its "home" codebase 22:56
bacek allison: yes... It's very coupled to JVM guts. 22:57
OTH, Parrot's GC isn't pluggable either.
allison bacek: pluggable in the sense that others can use it? no
bacek allison: no, in sense that we can replace one implementation with another easy. 22:58
allison bacek: it is pluggable in the sense the GC implementations are plugabble inside Parrot
bacek allison: not quite true.
allison bacek: it requires the plugins to obey a particular interface, yes 22:59
bacek: but most pluggable architectures do
bacek allison: there is a LOT #ifdef PARROT_GC_GMS and so on.
in e.g. pobject_lives.
allison bacek: organic growth hasn't been kind to the GC system, that's why it needs a cleanup (coming up next) 23:00
bacek allison: this "cleanup" looks almost "rewrite" from my point of view... 23:01
allison pmichaud: if you can skate by on the current problem without doing the context->PMC conversion that would be good, but the deeper you dig the more it sounds unavoidable
bacek: the difference between a cleanup and a rewrite is whether you improve existing code or chuck it and start over
bacek: we certainly aren't starting over from scratch
bacek: so it's a cleanup, but a substantial cleanup 23:02
bacek allison: not from scratch. But it will be something like rewriting 90% of code.
allison bacek: hardly 23:03
bacek: I mean, over the next 3 years, there's a good chance we'll replace 90% of the code, but it'll happen in small stages of refinement
23:03 leto_ joined
bacek allison: agreed 23:04
chromatic What should be the multi signature of this code? 23:10
.sub Integer_divide_Integer
.param pmc left
.param pmc right
.param pmc lhs
Is it "Integer,Integer" or "Integer,Integer,Integer"?
jonathan Depends if the third parameter participates in the dispatch or not. 23:11
I'm not sure whether it should or not.
allison may know :-)
chromatic The intent is to override the operation for $P1 = $P2 / $P3, where all three parameters are or derive from Integer.
allison that's Integer, Integer, Integer, because the vtable function takes 3 args 23:12
(the 3rd is the destination, so it has the option of modifying the destination rather than creating a new one)
chromatic Okay, look in t/pmc/multidispatch.t around line 228. 23:13
allison is that failing now or succeding?
chromatic Succeeding in trunk, failing with my sort avoidance. 23:14
jonathan chromatic: It was failing before your sort avoidance and when I "fixed" the element count in type_tuple too. 23:15
chromatic I could look at Parrot_quicksort to see if it's a stable sort and explain in that way, but I don't really want to rely on my degree in music to predict that.
On the other hand, Rock Band is a fun game... so I don't regret my education.
allison hah! fixing that fixes my two failing tests in my patch...
chromatic The "Integer,Integer" signature looked wrong to me. 23:16
allison chromatic: yes, it is wrong
23:16 apeiron joined
allison chromatic: now, can you magically predict why t/pmc/objects.t:194 is failing? 23:16
chromatic Same thing.
I fixed that one earlier.
See also the test on line 28 of t/pmc/multidispatch.t 23:17
allison 28 I just fixed
(that was my other failing test)
chromatic: trunk or branch?
chromatic .sub add :multi(MyInt1, MyInt1, MyInt1)
Locally in the branch.
jonathan Aha, so the code was right and the tests were wrong? 23:18
allison bingo!
jonathan: I'm committing this patch in trunk, because we need it in the calling conventions branch too (and because it's really small) 23:19
chromatic Thus we answer the common and dumb stupid objection to TDD: "Who has two thumbs and tests the tests?" "THIS GUY!"
allison jonathan: yes, the tests were wrong
chromatic Including objects.t?
allison chromatic: yes 23:20
jonathan OK, so with this fixed in the branch, it should pass all. Nice.
chromatic I'll commit the test fixes then. 23:21
dalek r33013 | chromatic++ | mmdcache: 23:23
: [t] Fixed some vtable MMD variant overloading tests. To wit:
: $P0 = $P1 / $P2
: ... needs a multi signature of "Type,Type,Type", not "Type,Type".
diff: www.parrotvm.org/svn/parrot/revision?rev=33013
jonathan does svn up and make test 23:24
allison jonathan/chromatic: committed in r33014 23:27
dalek r33014 | allison++ | trunk: 23:28
: [mmd] Refine the creation of type tuples for CallSignature PMCs, so they're not
: constructed unless the call is actually an MMD call. They're then cached inside
: the CallSignature in case they're needed again. Clean up some tests that were
: incorrectly specifying the MMD signature.
diff: www.parrotvm.org/svn/parrot/revision?rev=33014
allison (I committed on trunk, not mmdcache branch) 23:29
jonathan OK, the branch looks good to me now.
chromatic Why is SVN::Web so slow on parrotvm.org?
allison chromatic: because svn.perl.org is slow 23:30
jonathan We can haz svn.parrot.org?
chromatic Oh, I thought it was on parrot.org.
jonathan I guess yes, if we're going to use the trac integration...
allison I tried installing SVN::Web on my laptop, hoping to speed it up, but it wasn't any faster
jonathan I'm still working against svn.perl.org... 23:31
allison jonathan: we already have svn.parrot.org, it's just a matter of moving an svn dump to the new server
jonathan Aha, OK.
allison which is tricky, because people have to stop committing long enough to make the transfer
bacek Files=397, Tests=11711, 211 wallclock secs ( 3.08 usr 0.63 sys + 107.77 cusr 25.93 csys = 137.41 CPU)
Result: PASS
It's on mmdcache 23:32
chromatic What should get_pmc do on a MultiSub?
Right now it sorts the candidate list for the sub based on the current context's arguments and returns the sorted list.
allison chromatic: that's right 23:33
chromatic It needs to return the sorted list?
Not the best candidate?
jonathan allison: Is that a general interface for getting a candidate list?
e.g. I should follow the pattern in Perl6MultiSub?
allison chromatic: is the best candidate more useful than the candidate list? I mean, we need a way to get both, so it's only a question of which is more common 23:35
returning the list allows for more options
pmichaud "get candidate list" sounds method-y to me
allison (either invoke the first or do something with the list)
chromatic invoke invokes the best candidate.
allison pmichaud: yes, which we'll add anyway, because you want to be able to sort on a signature other than the current context signature 23:36
chromatic I have no strong preference either way. I just wanted to know if there was a specific decision besides "Oh, this is what it does." Expedience is fine, but I need to do something different in certain cases.
allison get_pmc isn't particuarly useful anyway, because it can't take an argument and so can only sort based on the current context's signature
chromatic Expedience then suggests that, right now, it return the best candidate :) 23:37
allison chromatic: there was, we through the list of alternatives that needed to be returned and set up vtable functions for the most common, but AFAIK no one is using them yet
jonathan I'm not even sure you can set that up easily from PIR...
Oh, I guess you can write a set_args... 23:38
allison chromatic: but if you do '$P1 = $P2' and $P2 is a multisub, do you really expect $P1 to be a single sub rather than a multisub? 23:39
pmichaud allison: is that set $P1, $P2 ?
allison chromatic: sorting is non-destructive, singling out is desructive
chromatic if you do that, $P1 won't be a multisub.
allison pmichaud: yes
chromatic On trunk, $P1 will be a RPA. 23:40
allison chromatic: currently it's probably returning an array, which is also probably wrong
pmichaud I'm sure it's part of the design, but as a PIR programmer I'd be very surprised when set $P1, $P2 causes $P1 to point to something *other* than the MultiSub itself. 23:41
allison pmichaud: not part of the design, the vtable functions aren't specified
pmichaud: they were randomly added
pmichaud I mean the design of PIR/Parrot in general. 23:42
it would be weird that set $P1, $P2 would do anything other than cause the two registers to point to the same PMC.
(Yes, I can see cases where we might want to overload this behavior. MultiSub isn't one of them, as you just said.)
chromatic It returns an RPA in trunk, and it returns a Sub with my patch. I can change it to do something else, but if we don't know what it should return now and nothing uses it, does it matter if I change what it returns now, especially if we might change it later? 23:43
allison pmichaud: ah, well that is part of the design (to have the option anyway)
chromatic: do you have a specific use for it returning a single sub?
chromatic No, just changed the sorting behavior.
cotto This is nice. OrderedHash's clone function segfaults if Parrot doesn't have the right hash seed. 23:44
allison changed the sorting behaviour for mmd?
as in, had it return a single candidate instead of a list?
chromatic Yes.
allison then how do you get the list?
or, how do you iterate if the first candidate isn't what you want? 23:45
chromatic Right now, nothing gets the sorted list of candidates, because nothing uses the sorted list of candidates.
allison yes, that's true, at least for mainline parrot
jonathan: were you using the candidate list for Rakudo?
pmichaud in the common case, we only need the best match. We don't have to do a full sort for that.
dalek r33015 | pmichaud++ | trunk:
: [core]: Add CTX_LEAK_DEBUG_FULL to turn on enhanced context leak debugging.
diff: www.parrotvm.org/svn/parrot/revision?rev=33015
allison chromatic: but it is speced to be able to do a "next" operation on the list
pmichaud and the 'next' operation is a good time to do the sort. 23:46
chromatic That's fine. I think it's great that we should be able to do that. I'm not preventing that at all.
allison chromatic: but then, in the grand scheme of things, that can wait
chromatic I just looked at all of the code and said "Wow, we always do the sort and throw away all of the information. Why are we doing the sort?"
allison the sort is to pull the top ranking candidate to the top 23:47
jonathan allison: I'm not using anything inside MultiSub PMC for Rakudo.
chromatic You don't need to sort to find the best fit.
pmichaud oops, I left CTX_LEAK_DEBUG_FULL enabled, which causes trunk to break. :-(
best fit can be found as distances are being computed
allison so, rather than tagging all the candidates and then sorting them after, you're capturing the best candidate as it passes, and then replacing it if you find a better candidate later? 23:49
chromatic Exactly.
pmichaud that would be quicker.
dalek r33016 | pmichaud++ | trunk:
: [core]: Oops, I left CTX_LEAK_DEBUG_FULL enabled, which breaks the build.
diff: www.parrotvm.org/svn/parrot/revision?rev=33016
allison certainly cheaper
chromatic It doesn't matter *much* right now for three reasons:
pmichaud we can do the sort only if someone needs more than best-fit.
allison chromatic: I say go ahead with it, we can re-add sorting later
chromatic * Most of the candidate lists have very few candidates
* Caching best candidates has a much larger impact 23:50
* We rarely invalidate the cache right now
However, it is cleaner.
The only reason I ask about this change is that it changes what MultiSub's get_pmc entry returns right now. I can fix that up, but if it's unused and not the right API, I don't care and I hope you don't either.
In summary, BEST DAY EVER.
It also makes the code a lot simpler and cleaner. 23:51
23:51 kj joined
allison chromatic: really, I think MultiSub's get_pmc entry should just return the MultiSub itself 23:51
pmichaud (please, yes.)
kj good evening
pmichaud $P0 = get_global 'my_multi'
kj it seems I'm banned when connecting from my usual irc client :-(
allison chromatic: which may mean simply deleting the get_pmc vtable function and letting it fall back to the inherited one
pmichaud $P1 = $P0 # eek?
kj anybody knows how that can be fixed? 23:52
chromatic I just looked in RPA, and deleting get_pmc will do it.
allison chromatic: excellent
chromatic kj, perhaps you should /msg one of the IRC admins.
kj chromatic: do you know who they are? 23:53
purl they are listening
pmichaud I think that's one of the first intelligent responses I've seen from purl.
chromatic kj, they're sungo, mst, and Robrt. 23:54
kj chromatic: thank you. I'll do that
pmichaud I don't think I'm up for converting contexts to PMC this weekend. I might re-try lexicals once more in a new branch, but setting the CTX_LEAK_DEBUG_FULL flag in src/gc/register.c will demonstrate where things are currently broken. 23:55
allison pmichaud: sounds sensible
pmichaud maybe someone else can take a look at it. I think if that problem is fixed then lexicals become easy.
well, easier, at any rate. 23:56
chromatic I'll take a look, but I have family visiting this week.
pmichaud (CTX_LEAK_DEBUG_FULL is in trunk, btw)
I'm leaving the current lex4 branch around for reference reasons (and in case I want to restart it), but new lexical stuff will be in another new branch from trunk.
allison: I figured out how to explain my approach to branch management concisely: 23:57
given that I have a branch I want to checkpoint with trunk
svn copy trunk branch_new
svn co branch_new
cd branch_new 23:58
svn merge branch_old
allison what's branch_old?
pmichaud the branch I'm merging from
allison that's the branch you want to checkpoint with trunk? or another branch? 23:59
pmichaud I'll start over. Given that I have a branch 'lex1' that I've been working in, and I want to bring in the latest trunk changes:
svn copy trunk lex2
svn checkout lex2
cd lex2
svn merge lex1

Powered by Cro and the Raku® Programming Language.

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

Thank you!