Camelia, the Perl 6 bug

IRC log for #parrot, 2008-11-22

Parrot | source cross referenced

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

All times shown according to UTC.

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

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

Parrot | source cross referenced