Camelia, the Perl 6 bug

IRC log for #parrot, 2008-11-21

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 Infinoid pmichaud: thanks for taking that patch and running with it, sorry it wasn't very compatible to start with
00:00 jonathan pmichaud: I'm still concious.
00:00 pmichaud Infinoid: hey, it's great.
00:00 jonathan Let me try it on Win32 for you.
00:00 pmichaud jonathan: thanks.
00:01 pmichaud I get an infinite loop in stm/running.t, though.
00:01 jonathan pmichaud: I thought you just said it passes all tests?
00:01 pmichaud ...except that one.
00:01 jonathan lol
00:01 pmichaud which I'm thinking we'll deprecate.
00:02 pmichaud I'm not at all sure how to handle contexts and threads.
00:02 jonathan Where's it inf-looping, or is it hard to tell?
00:02 pmichaud test #4
00:02 jonathan Probably with difficulty, but that's a 1.5 problem..
00:03 pmichaud pmichaud@orange:~/parrot/lex4$ ./parrot --gc-debug t/stm/runtime_4.pir
00:03 pmichaud Bug: Attempting to mark dead context 8122988
00:03 pmichaud current instr.: 'parrot;STMQueue;main' pc 508 (t/stm/runtime_4.pir:228)
00:03 pmichaud if I run it with -t1 I get different results.
00:04 pmichaud if run from gdb and then I hit interrupt, it's in __kernel_vsyscall
00:04 jonathan And a step down from that?
00:04 jonathan bt
00:05 * jonathan is curious
00:05 nopaste "Infinoid" at 96.238.213.50 pasted "Regardless of whether the refcounting is right or not, if you're gonna take a reference here, might as well get a debug statement for your trouble." (17 lines) at http://nopaste.snit.ch/14657
00:05 nopaste "pmichaud" at 72.181.176.220 pasted "bt of t/stm/running_4.pir" (48 lines) at http://nopaste.snit.ch/14658
00:06 Infinoid ooh, deadlock
00:06 purl deadlock is the big difficulty with open2 (or with doing this in any other way.)
00:06 pmichaud Infinoid: I didn't want to change the ordering until I understood the logic a bit better.
00:06 jonathan pmichaud: Looks like a deadlock.
00:06 Infinoid ordering?  oh.
00:06 pmichaud but I will make it into a context_ref call.
00:06 Limbic_Region joined #parrot
00:06 Infinoid well, that's fine, I can just move it down
00:06 jonathan pmichaud: And it hits it in destruction.
00:06 jonathan It may be the more general destruction ordering issues we have.
00:07 pmichaud note that it *did* run into a dead context exception, though.
00:07 pmichaud #9
00:07 pmichaud that probably shouldn't have happened in the first place.
00:07 chromatic Yeah, it doesn't feel like destruction ordering.
00:07 jonathan Yes, it's exiting as a result of the exception.
00:07 Infinoid on my box, lex4 has test failures in t/compilers/pge/06-grammar.t, t/compilers/pge/pge_examples.t, t/compilers/tge/grammar.t, t/library/coroutine.t
00:08 pmichaud Infinoid: your box is...?
00:08 dalek r32968 | fperrad++ | trunk:
00:08 dalek : [Lua]
00:08 dalek : - update syntax, see RT #57428
00:08 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32968
00:08 bacek_ joined #parrot
00:08 Infinoid gentoo linux x86-64
00:08 pmichaud ah, 64-bit.
00:08 Infinoid all dead context bugs
00:08 pmichaud could very well be.
00:08 pmichaud yes.
00:09 Infinoid so that's one fewer failure than this morning... t/compilers/tge/basic.t seems to work now
00:09 pmichaud I think they're still somewhat "floating"
00:09 AndyA joined #parrot
00:10 chromatic Crazy talk: because all vtable entries written in C are written in pre-processed C, we could make them all take parameters from the current context.
00:10 chromatic Then the VTABLE_ macros just marshall the arguments into a new context.
00:12 Infinoid hmm...  should I do a similar hack to Parrot_free_context to see what's calling that?
00:13 pmichaud ...what's calling what?
00:13 Infinoid what's freeing the context too many times
00:13 pmichaud I'm just setting a breakpoint on Parrot_free_context
00:13 Infinoid that's too easy. :)
00:13 jonathan pmichaud: Tests running on Win32, results in a bit.
00:14 pmichaud I get a lot of __Parrot_context_ref  defined but not used warnings -- how to suppress?
00:14 Aisling joined #parrot
00:15 pmichaud maybe I'll just make it Parrot_context_ref_debug
00:15 pmichaud and then the macro can call it.
00:15 pmichaud that sounds good.
00:15 Coke fperrad++ # cleanup up my deprecation hackage.
00:16 Infinoid make it inline, or -Wno-unused-function
00:16 Infinoid ok :)
00:16 pmichaud and we can breakpoint it.
00:16 Infinoid sounds great
00:17 dalek r32969 | pmichaud++ | lex4:
00:17 dalek : Missed a ref_count increment (Infinoid++)
00:17 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32969
00:18 nopaste "jonathan" at 85.216.157.73 pasted "win32 test results in lex4" (8 lines) at http://nopaste.snit.ch/14659
00:19 pmichaud okay, not too bad.
00:19 pmichaud I wonder if t/pmc/complex.t segfaults.
00:19 jonathan It does give Bug: Attempting to mark dead context 654268
00:20 pmichaud okay, so it's throwing an exception.
00:20 pmichaud (sigh)
00:20 jonathan Works with -G, as you may expect.
00:21 pmichaud so.... why would we get dead contexts in some environments and not in others?
00:21 pmichaud that seems... odd
00:21 jonathan 64-bit vs 32-bit would seem understandable.
00:21 jonathan Or at least you could guess some dodgy pointer stuff.
00:21 jonathan But hmmm.
00:21 pmichaud maybe, but even there I don't know why.
00:22 jonathan pmichaud: Does that complex.t not fail for you?
00:22 pmichaud no, it does not.
00:23 pmichaud it seems to me like we should be getting the same context allocations and deallocations, yes?
00:23 jonathan Yes
00:23 jonathan Hmm
00:23 pmichaud that's really dependent only on execution.
00:23 pmichaud whether the dead context is detected would depend on when the gc sweeps are run.
00:23 jonathan --gc-debug does what? GC run after eahc op?
00:23 pmichaud I don't know exactly what --gc-debug does.
00:23 pmichaud but I tried it without --gc-debug and it ran fine also.
00:24 jonathan Turn on GC (Garbage Collection) debugging. This imposes some stress on the GC
00:24 jonathan subsystem and can slow down execution considerably.
00:24 jonathan OK, this one is interesting.
00:24 jonathan Becuase it shows up with parrot t/pmc/complex.t
00:24 jonathan but goes away with --gc-debug
00:25 pmichaud chromatic has a magic runcore that does a gc after every op -- I forget the option, though.
00:25 chromatic --runcore=gc-debug
00:25 pmichaud that's different from --gc-debug?
00:25 Coke yes
00:25 chromatic Sadly.
00:25 pmichaud Understood.
00:25 purl Understood. are you on schedule?
00:25 Coke no, understood is <reply>Roger Roger.
00:26 pmichaud pmichaud@orange:~/parrot/lex4$ ./parrot --runcore=gc-debug t/pmc/complex.t
00:26 pmichaud main: Unrecognized runcore 'gc-debug' specified.
00:26 jonathan main: Unrecognized runcore 'gc-debug' specified.
00:26 jonathan oh, dupe fail
00:26 jonathan pmichaud: it's gcdebug
00:26 jonathan no extra -
00:26 Coke I blame chromatic.
00:26 jonathan My wob it's slow.
00:26 Coke ... hell yes.
00:26 Coke it's INSANELY slow.
00:26 pmichaud 150 tests....
00:27 pmichaud 180 tests...
00:27 jonathan It's this slow with virtually nothing to collect?!
00:27 jonathan oh arse
00:27 jonathan We run to completion with that too.
00:27 jonathan So something gets collected that would reference a context when it's OK to mark it...
00:27 pmichaud then I'm suspicious of whatever --gc-debug does.
00:28 pmichaud or what you just said.
00:28 jonathan ...but lasts longer normally at which point it becomes un-OK to reference that context.
00:29 pmichaud oh, so perhaps my dead context detector is broken.
00:29 pmichaud no, that can't be it.
00:29 pmichaud "lasts longer normally" would mean that it still wouldn't mark its pointers as live, or follow them.
00:29 jonathan No, I don't think so.
00:30 jonathan Moment, will try and debug
00:30 pmichaud okay.
00:32 jonathan OH PLEASE NO
00:32 jonathan It runs to completion under the C debugger too.
00:32 pmichaud I suspect --gc-debug.
00:32 jonathan Yes, but that hid it.
00:32 jonathan Oh, you mean you think that'd flag would be enabled?
00:32 jonathan Shouldn't be.
00:33 pmichaud no, I just mean that whatever --gc-debug does is changing things somehow...  what does --gc-debug do, internally?
00:33 jonathan No idea.
00:33 chromatic I think it mostly turns off garbage collection.
00:33 jonathan But it didn't fail with --runcore=gcdebug either
00:34 pmichaud turning off gc stresses the gc subsystem?
00:34 pmichaud is --gc-debug a separate runcore, or ...?
00:34 chromatic Never recycling any memory stresses the system.
00:34 jonathan pmichaud: No, --runcore=gcdebug
00:35 jonathan Is the separate runcore.
00:35 pmichaud stresses the system, yes, but stress the gc subsystem?
00:35 jonathan Yes, because without recycling of stuff there's more to collect.
00:41 Infinoid is it likely that a context's lex_pad pointer would point to a Null PMC?
00:41 pmichaud yes.
00:41 pmichaud if the sub doesn't declare any lexicals.
00:41 Infinoid I'm looking at a dead context crash in gdb, and trying to make sure the ctx is at least a valid ctx, and not some other random pmc
00:41 Infinoid ok, thanks
00:43 Infinoid this is strange.  the context's ref_count is -1 (hence the dead context crash), yet when I put a conditional breakpoint on the ref_count decrement, I don't find the smoking gun.
00:43 Infinoid telling gdb to "break src/gc/register.c:534 if ctxp->ref_count <= 0" should work.  And it does trigger, if I omit the condition.
00:44 pmichaud there are two refcount decrements
00:44 pmichaud be sure to hit the second.
00:45 Infinoid well, that would explain it.
00:45 Infinoid I've done this just enough times to cringe whenever I see IMCC in the backtrace...
00:47 Infinoid ok, so this hit the "force the reference count negative to indicate a dead context so mark_context (src/sub.c) can report it" sanity check.  yet the context is apparently still around, somewhere
00:48 pmichaud yes.
00:50 dalek r32970 | pmichaud++ | lex4:
00:50 dalek : Suppress __Parrot_context_ref unused warnings
00:50 dalek : (cleans things up a fair bit overall, too).
00:50 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32970
00:51 TiMBuS joined #parrot
00:53 * Infinoid sets a bunch of read-watchpoints in hopes of finding out where else the context lives.
00:55 Alias joined #parrot
00:56 chromatic Instead of recycling contexts onto a free list, you could temporarily add code to malloc/free them, and catch the segfault.
00:57 pmichaud they're already malloced, so it's just a matter of freeing them I suppose.  :-)
00:58 jonathan There's so memory corruption at play somewhere, I fear.
00:58 chromatic Yeah, free them instead of putting them on the free list.
00:58 chromatic Good for debugging.
00:58 jonathan When adding one line of C that just follows a pointer to try and get a segfault then makes this test run to completion...I get suspicious.
00:59 chromatic Hm, I would too.
01:01 davidfetter joined #parrot
01:01 Infinoid there's a Sub that still has a reference to this (now freed) context
01:02 pmichaud what pointer?
01:02 purl pointer is, like, NULL :-)
01:02 pmichaud purl, forget ointer
01:02 purl pmichaud, I didn't have anything matching ointer
01:02 pmichaud purl, forget pointer
01:02 purl pmichaud: I forgot pointer
01:02 Infinoid #3  0x00007f4da50d184d in Parrot_Sub_mark (interp=0x185d080, pmc=0x193e3d8)
01:02 Infinoid at ./src/pmc/sub.pmc:443
01:02 Infinoid 443                 mark_context(interp, sub->ctx);
01:02 pmichaud which test is this, the stm one or...?
01:03 Infinoid no, this is just trying to compile PGE after adding chromatic's free() (which is a great idea).
01:04 Infinoid though I saw something very similar a little while ago, by breaking on the dead context exception and doing a backtrace there
01:04 Infinoid (though I guess that doesn't mean much, since every sub has a context)
01:04 jonathan Go Microsoft. The latest version of Visual Studio won't even let me open the EXE for debugging.
01:05 Infinoid debugging is far too boring, and doesn't appeal to middle management
01:06 Alias :)
01:07 Alias And have you ever tried to develop a PKI for debugging so that it can appear on the BIS status dashboard? It doesn't deserve to be considered by any modern CIO
01:08 * Infinoid goes into TLA overdose
01:09 chromatic It's worse to realize you understand the whole thing, and you don't even write business software.
01:09 jonathan Debugging mode seems to do something different with memory allocations somehow. Which makes the problem vanish.
01:09 jonathan Which makes me suspect memory corruption all the more, but gives little aid with finding it.
01:11 jonathan in mark_context
01:12 jonathan This is maybe unrelated but obj = (PObj *)interp->current_cont;
01:12 pmichaud mark_context really only helps us detect that something went awry; it doesn't really pinpoint the problem.
01:12 jonathan That is, we mark something in the interp data structure every call to mark_context?!
01:12 jonathan Shouldn't we be doing that once per DOD?
01:12 chromatic I would think so.
01:12 jonathan Won't be this bug, but it looks so wrong.
01:16 pmichaud I think mark_context might've originally designed when contexts were always a stack.
01:17 pmichaud but yes, it looks wrong.
01:23 Alias OK, me test failure
01:23 Alias my
01:24 Alias Inside the Perl::Dist build chain, on XP current service pack, I see t/pmc/complex failing
01:24 Alias This is the 0.8.1 release
01:24 jonathan Alias: That's due to floating point errors, I guess?
01:24 Alias uuuum
01:24 pmichaud ...the release, not the trunk?
01:25 Alias The release, yes
01:25 Alias 0.8.1 release
01:25 jonathan OK, by making contexts just always malloc some memory rather than take from the pool, I can get the problem to trigger in the debugger.
01:25 Alias There's 2 subtests failing
01:25 Alias I can't tell you which, no output
01:25 jonathan Alias: Aha. We're debugging a new problem in a branch at the moment, which gives a different, unrelated failure here.
01:26 pmichaud ...is it unrelated, though?
01:26 jonathan But I do know and have seen the failures.
01:26 pmichaud interesting that they both show up in complex. :-)
01:26 jonathan pmichaud: Yes, I've seen the failures that I think Alias mentions. They were -0.0 vs 0.0 related.
01:26 pmichaud okay.
01:26 jonathan That test has failed for me with those on Win32 for quite a while.
01:26 Alias STDERR dump says, "Have: 0.000000-0.909297i\nWant: -0.000000-0.909297i"
01:26 jonathan Aha.
01:26 jonathan Yes.
01:26 pmichaud yes, that's it.
01:26 Alias And another similar pair
01:27 Alias With the centre "-" replaced with "+"
01:27 Alias So whatever those two are...
01:27 jonathan pmichaud: Ugh. The thing calling the mark_context I get this in is the mark routine in RetContinuation.
01:28 Alias jonathon: Anyways
01:28 Alias Am I right to leave that with you guys and come back next release? :)
01:29 chromatic Not unless you also leave with us a Windows programmer who knows how to fix transcendental math on Windows.
01:29 jonathan Alias: The problem you're seeing is actually still a problem.
01:29 Alias Oh, and one you can't fix?
01:29 jonathan I'll bet once this issue is fixed, that one is still there.
01:29 Alias (trivially)
01:29 jonathan Alias: I don't, myself, know how to fix that floating point one.
01:29 chromatic Not trivially, no.
01:30 jonathan If you do know about that area, help welcome! :-)
01:30 Alias I don't know C, alas
01:30 jonathan You lucky thing!
01:30 Alias I just know how to take everyone else's knowledge and automate them into build systems
01:31 Alias (Because as I see it, the problem with most build systems is they are created by sysadmins) :)
01:32 jonathan aha
01:32 jonathan /*
01:32 jonathan * XXX when reusing SUPER.destroy() RetContinuations
01:32 jonathan *     have to set ref_count initially to 1
01:32 jonathan */
01:32 Alias Later today I might try to add force support to my parrot build
01:32 jonathan In RetContinuation PMC
01:32 Alias And then I'll just continue to the install step
01:32 Alias And see if I can at least produce a real .exe installer
01:32 jonathan oh, but we don't call that :-|
01:32 Alias Will get back to you once I have a package
01:32 jonathan Alias++ # packaging
01:32 Alias ARe you guys happy with just something that installs to C:\parrot
01:34 chromatic Alias, that suits me for now.
01:34 Alias And now I go back to $work fighting with rpmbuild
01:34 Alias chromatic: OK
01:34 Alias I'm not sure wtf to do with the environment stuff, but we can deal with next next iteration
01:36 jonathan pmichaud: Is Parrot_free_context a macro?
01:37 pmichaud yes
01:37 pmichaud no.
01:37 pmichaud no.
01:37 pmichaud no.
01:37 pmichaud (sorry, was thinking Parrot_context_ref)
01:37 pmichaud Parrot_free_context is in src/gc/register.c
01:38 Alias BTW
01:38 Alias If you wanted to fix that math issue
01:38 Alias What, PRECISELY, would you need
01:38 Alias I can mention it to my Microsoft OSL contact, and see if they can help
01:39 Alias Assuming that the problem is really deep Windows-specific stuff
01:39 jonathan ah, we're hitting
01:39 jonathan /* force the reference count negative to indicate a dead context
01:39 jonathan * so mark_context (src/sub.c) can report it */
01:39 jonathan ctxp->ref_count--;
01:40 chromatic We would need a Windows-specific way to detect negative floating point zero and always force output of that value to appear with a leading -.
01:40 jonathan pmichaud: Aha
01:40 jonathan Parrot_free_context(PARROT_INTERP, ARGMOD(Parrot_Context *ctxp), int deref)
01:40 jonathan We do
01:40 jonathan if (ctxp->ref_count <= 0) {
01:41 Alias erk
01:41 jonathan oh, ah
01:41 Alias chromatic: Can you fire me off an email with the details and anything you think might be useful for someone on the inside?
01:41 jonathan false alarm
01:41 pmichaud jonathan: right.
01:41 pmichaud :-)
01:41 Alias chromatic: And I'll forward it through
01:42 jonathan Gah, how is this one happening...
01:42 chromatic Will do.
01:42 Alias Thanks
01:42 Alias No promises, but it's worth just lobbing it over the wall and seeing
01:42 chromatic That might get us a better fix than hoping someone will show up with a patch.
01:43 Alias Did you ask the mingw people?
01:43 chromatic Don't know any.
01:43 Alias I guess I don't know enough about how numbers relate to OS
01:44 Alias Cause it sounds like a compiler thing to me, not so much OS
01:44 chromatic I think it's a libc issue.
01:46 davidfetter joined #parrot
01:46 Alias So that makes it more of a MinGW thing?
01:47 Alias BTW, after make test, I should just make install it?
01:47 chromatic Whatever the standard math functions in the standard C library do, that's what we have to work with.
01:47 Alias hrm
01:48 Alias ok, I might try pushing to a newer version of MinGW than I use for Perl 5
01:48 chromatic We're talking about the representation of newer values.
01:48 chromatic I mean "numeric" values.
01:48 Alias ok
01:48 chromatic I'll try to make it clear in the mail.
01:48 Alias Thanks
01:48 Alias I'm good at chasing people down for stuff, so I'll see what I can do
01:48 Alias And in the mean time, will upgrade my C toolchain more aggressively for parrot builds
01:51 chromatic_suppertim Alias, if you're bundling 0.8.1, you might add in r32929.
01:51 Alias My setup isn't really able to support patches
01:52 Alias Because it's designed for building production-grade releases, so it mostly insists on sticking to only what comes in the tarball
01:52 Alias Which is the result of one of the original design choices for Strawberry
01:52 Alias I can just pick up the next one in a month
01:53 chromatic_suppertim Fair enough.  If you did ever pick up a patch though, that's the top on my list.
01:54 Alias I only allocate budget to hack on the Perl::Dist code itself once every 3 months
01:54 Alias time budget...
01:55 Alias If something comes up in January, I'll see :)
01:55 Alias But then I expect a new monthly release by then
02:15 confound supertim
02:15 chromatic_suppertim suppertime
02:15 Whiteknight suppertime!!
02:15 Whiteknight (you have to say it with more gusto
02:16 davidfetter bon appetit, chromatic_suppertim
02:20 jonathan pmichaud: Mighta found something.
02:20 jonathan Something that isn't my bed.
02:21 jonathan Yes. It fixes t/pmc/complex.t here
02:22 jonathan pmichaud: Testing, then will ci
02:22 jonathan Then will sleep.
02:22 * jonathan wonders if he might as well just stay living on PDT...
02:32 jonathan 2 hours for a one damm line patch.
02:32 dalek r32971 | jonathan++ | lex4:
02:32 dalek : [core] We weren't ref-counting contexts created in PMCs that had methods using the Parrot Calling Conventions the same way as with normal Parrot sub calls. Bring the two inline. Clears up a failure on Windows.
02:32 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32971
02:33 Alias jonathon: That is the way of things...
02:33 Alias The reason it took 2 hours to find was BECAUSE it was so small
02:35 * pmichaud looks at jonathan++'s patch
02:36 * jonathan hopes it's sane
02:36 pmichaud I have no way of truly knowing.  But yes, you're correct that it doesn't match Parrot_PCCINVOKE
02:37 pmichaud or Parrot_pcc_invoke_sub_from_sig_object
02:37 jonathan Right.
02:37 pmichaud so if those work, then that one must need to be there as well.
02:37 pmichaud I'll test on my box
02:37 pmichaud w/realclean
02:37 jonathan I followed what they did side by side, once I got to the point of being pretty sure it was to do with both ret continuations and PCC methods.
02:37 jonathan And realized this was the messing step.
02:38 jonathan One of the STM failures went away.
02:38 pmichaud oh, yay!
02:38 jonathan The other one that fails I think normally fails on Win32.
02:38 pmichaud I'll be able to tell in just a bit.
02:39 jonathan Cool
02:39 * jonathan crosses his fingers
02:41 pmichaud if this is it, in some sense it's amazing we hadn't noticed problems before now.
02:41 pmichaud (running 'make test' now.)
02:42 pmichaud sometimes, though, adding a refcount actually hides a problem instead of solving it (by turning it into a context leak)
02:42 jonathan Well, it might always be one of a number of issues.
02:42 pmichaud but hopefully this will allow me to get rid of my known leak.
02:42 pmichaud (which, when I remove it, causes PGE to stop building.)
02:43 pmichaud so far all is well.
02:45 * jonathan figures he's stayed up late enough that waiting for the make test results won't hurt any more
02:46 pmichaud all tests passed.
02:46 pmichaud _including_ the stm one that was hanging before.
02:46 jonathan OK
02:46 jonathan That sounds like good news.
02:47 pmichaud indeed, it does.  Now let's see what happens when I get rid of my context leak.
02:48 pmichaud FAIL.
02:49 jonathan Damm.
02:49 jonathan So are we better off without the patch, or better with it, or...?
02:49 pmichaud with it.
02:49 jonathan OK
02:49 jonathan So it's fixed one problem but we still have another?
02:49 Infinoid lex4 passes tests on x86-64
02:49 pmichaud yes, there's a memory leak somewhere.
02:49 Infinoid jonathan++ pmichaud++
02:50 pmichaud Infinoid: excellent.
02:50 jonathan pmichaud: A merge-blocking one?
02:50 jonathan Or a minor one?
02:50 pmichaud well, I'm not a fan of leaking contexts.
02:50 jonathan Sure.
02:50 pmichaud and we haven't tried rakudo in the lex4 branch yet.
02:50 jonathan Ah.
02:50 pmichaud (trying that now.)
02:50 Infinoid oh, we still leak
02:50 Infinoid valgrind time.
02:51 Infinoid (that's like hammer time, but a bigger hammer.)
02:51 pmichaud yes, the noop.pir test leaks again.
02:51 pmichaud that one is...tricky
02:51 jonathan It didn't leak before the patch?
02:51 jonathan Or again, related to the other problem?
02:51 pmichaud before your patch?  it leaked _also_
02:51 jonathan OK.
02:51 pmichaud so I think the leak is unrelated to your patch.
02:51 jonathan Yes.
02:52 jonathan Seems so.
02:52 pmichaud I think it's related to the from_ctx pointer.
02:52 jonathan What's noop.pir?
02:52 pmichaud .sub main
02:52 pmichaud noop
02:52 pmichaud .end
02:52 jonathan Ah.
02:52 pmichaud leaks 112 bytes on my system (one context, I think)
02:52 pmichaud tracing shows two references made, only one pop
02:52 jonathan OK, and if you do many calls of such a sub, do we leak per call?
02:52 pmichaud er, only one free
02:52 pmichaud haven't tried that yet.
02:52 jonathan OK, that'd answer a lot.
02:53 pmichaud rakudo passes "make test"
02:53 pmichaud (trying "make spectest" now)
02:53 chromatic_suppertim Interested in Parrot: http://matt.might.net/
02:53 jonathan Yes, same here.
02:53 jonathan (make test)
02:53 Infinoid oh.  these things are never freed, they're just put in a reuse pool, right?
02:53 pmichaud correct, they're in a re-use pool.
02:54 * Infinoid explicitly frees them again, to make valgrind work better
02:54 pmichaud I've taken to calling it "the recycle pool".
02:55 jonathan OK folks, I really should sleep.
02:55 pmichaud yes, you should.  It's even getting late-ish here.
02:55 Infinoid t/compilers/pge/06-grammar.t is a pretty good test for this
02:55 jonathan Will hack more stuff tomorrow.
02:56 Infinoid goodnight jonathan
02:56 pmichaud Thanks for taking the time to track down that one bug.
02:56 jonathan night
02:56 Infinoid ==27842== 1,062,696 (519,792 direct, 542,904 indirect) bytes in 2,012 blocks are definitely lost in loss record 1,262 of 1,262
02:56 Infinoid ==27842==    at 0x4C21FAB: calloc (vg_replace_malloc.c:279)
02:56 Infinoid that's gotta be the leak.
02:56 jonathan np, I want to see this branch merged as soon as anyone
02:56 Infinoid ==27842==    by 0x510F689: mem_sys_allocate_zeroed (memory.c:102)
02:56 Infinoid ==27842==    by 0x510FFFA: Parrot_alloc_context (register.c:447)
02:56 jonathan ouch
02:56 * jonathan sleeps
02:57 Infinoid valgrind has all kinds of leaks, categorized by the functions on the stack
02:57 jimmy joined #parrot
02:57 Infinoid the biggest source of unfreed contexts comes from Parrot_callmethodcc_p_sc, via Parrot_Sub_invoke
02:57 pmichaud ...callmethodcc ?
02:58 pmichaud you mean Parrot_sub_invoke is calling callmethodcc ?
02:58 nopaste "Infinoid" at 75.28.77.95 pasted "Biggest source of unfreed contexts, according to valgrind" (16 lines) at http://nopaste.snit.ch/14661
02:59 pmichaud oh, callmethodcc is invoking Parrot_Sub_invoke
02:59 Infinoid of course, valgrind doesn't tell us why they aren't being cleaned up
03:00 pmichaud I still think it's something to do with from_ctx (in Parrot_Sub_invoke)
03:00 Infinoid is that the same from_ctx that I was staring at earlier, in the continuation pmcs?
03:04 pmichaud no, this one is in src/pmc/sub.pmc
03:04 pmichaud currently I give it a context_ref..... but I can't see that it's ever freed.
03:04 pmichaud if you run the noop test, you'll see that only two references are made, and that's the one that isn't freed.
03:06 pmichaud (but if I take that ref out, then other things go kaboom.)
03:08 Infinoid ok, you're right, the vast majority of leak traces go through Parrot_Sub_invoke
03:08 nopaste "pmichaud" at 72.181.176.220 pasted "easy to see leaking script" (14 lines) at http://nopaste.snit.ch/14662
03:08 pmichaud that script leaks 100 contexts.  :-)
03:08 pmichaud or maybe 102.
03:08 Infinoid the other big leaker seems to be count_signature_elements, but the numbers for that one aren't quite as big
03:11 pmichaud here's the line I'm talking about:   src/pmc/sub.pmc:264
03:12 pmichaud I can take that out and then PGE doesn't build.
03:12 pmichaud (but we don't get the leak.)
03:14 Infinoid hmm... if Parrot_free_context is never being called, why would the refcount matter?
03:14 pmichaud it's called once, but there are two references.
03:14 pmichaud and it should be called at the end of the program when everything gets cleaned.
03:14 pmichaud (apparently that's not happening, which is why we end up with leaks)
03:15 Infinoid (for the record, I added one at the end of the invoke method, and it broke PGE.)
03:15 pmichaud (two references means it should be called at least twice)
03:15 Infinoid yeah... I only saw the one
03:15 Infinoid and I thought ref_count was initialized to 0
03:15 Infinoid I'm probably wrong about that.
03:15 pmichaud it is initialized to zero to begin with.
03:16 pmichaud anyway, my updated noop.pir script that runs 100 invokes definitely shows we have a leak somewhere.
03:17 Infinoid anyway, PGE is segfaulting because of a dangling pointer to garbage, after an 18-context marking chain in a DOD run
03:17 Infinoid yes, definitely
03:18 pmichaud a-ha
03:19 pmichaud src/pmc/retcontinuation.pmc:94
03:19 pmichaud , 0)  should probably be , 1)
03:20 pmichaud although that also causes the PGE build failure.
03:20 Infinoid hum.
03:20 pmichaud for background:  in trunk the from_ctx pointer does not appear to increase ref_count
03:20 Infinoid 12:52 <@particle> and retcontinuations are single-use, so never incremented/decremented
03:20 Infinoid 12:52 <@particle> right?
03:20 Infinoid 12:52 <@Infinoid> is new_continuation aware of that, so it never takes the reference?
03:21 Infinoid 12:52 <@chromatic> Yes and I don't know, respectively.
03:21 Infinoid that exchange led me to believe the refcounting was right
03:21 pmichaud however, in trunk  that Parrot_free_context *does* decrement the refcount pointer.
03:21 Andy joined #parrot
03:21 Infinoid oh.
03:22 Psyche^ joined #parrot
03:23 * Infinoid works on hunting down the details of the segfault
03:23 pmichaud so, at first I was going with "don't refcount the from_ctx", but got the segfault.
03:24 pmichaud then I tried "okay, de-refcount the from_ctx in retcontinuation", and that segfaults.
03:24 pmichaud I lean towards not refcounting from_ctx, but....
03:24 Infinoid yeah... I'm not sure the segfault is directly caused by this yet
03:25 pmichaud I need a break for a bit -- bbi30
03:35 Theory joined #parrot
03:48 pmichaud well, looks like it's going to be closer to an hour :-(
04:24 * Coke notes that jonathan, pmichaud, and Infinoid all have the same # of letters in their nicks, so they all line up.
04:32 Infinoid It's Super Fun.
04:37 pmichaud particle too.  :-)
04:38 pmichaud okay, it's time for me to learn "Everything You Ever Wanted to Know About Parrot Continuations and Probably Shouldn't Have Asked".
04:46 pmichaud a-ha!
04:46 pmichaud the from_ctx pointers of continuations are refcounted.  the from_ctx pointers of ret_continuations are not.
04:46 chromatic Do ReturnContinuations return to from_ctx?
04:46 pmichaud checking
04:47 pmichaud yes, it appears so.
04:47 pmichaud oh, maybe not.
04:47 pmichaud I need to check further.
04:47 pmichaud but in invalidate_retc_context, we convert all of the retcontinuations into continuations *and* update the refcounts for from_ctx
04:48 * Coke is scared by the new star trek trailer.
04:49 chromatic Spock has The Hunger.
04:50 pmichaud invoking a RetContinuation switches back to the context given by to_ctx  (Parrot_continuation_rewind_environment)
04:50 pmichaud I suspect it doesn't need a from_ctx after that, which is why it's not refcounted.
04:51 pmichaud also, Continuation's destroy frees its from_ctx pointer, while RetContinuation's does not (unless there's an implied SUPER that I'm not aware of)
04:52 pmichaud (I'm looking in trunk for all of this information.)
04:54 chromatic There should be no implied SUPER; it has to be explicit.
04:54 pmichaud okay, good.  This confirms what I'm thinking then.
04:55 pmichaud so, why do Continuation's need to refcount their from_ctx, I wonder?
04:57 pmichaud that seems backward.  I would expect that we would need to refcount the to_ctx
04:59 pmichaud oh, it appears to do with argument passing.
05:06 Coke chromatic: did a callgrind run on a simple tclsh program.
05:07 Coke backs up my previous -p attempt on a different file: lots of time in gc. :|
05:07 nopaste "coke" at 193.200.132.135 pasted "cg.out" (779 lines) at http://nopaste.snit.ch/14664
05:08 nopaste "coke" at 193.200.132.135 pasted "foo.tcl" (5 lines) at http://nopaste.snit.ch/14665
05:12 Coke looks like hash is another big use of time.
05:12 Coke has anyone investigated eliminating our hand rolled hash library and using an OS one?
05:13 chromatic No.  That might be nice.
05:13 Coke I figure we are unlikely to do better at a standard hash than someone who's been concentrating on that.
05:16 chromatic Agreed.
05:25 Theory joined #parrot
05:56 Theory joined #parrot
06:09 * chromatic has a naive MMD caching patch.  It's ugly, but it does appear to speed things up.
06:12 chromatic I saw a paper somewhere about type lattices doing even better, but this is a start.
06:22 GeJ Ok, well... time to get my feet wet. I'm thinking about writing a series of blog posts about a "Extremely Beginner's Guide to Parrot". The basic idea would be to start at the PIR level as an introductionary language and climb the layers up to NQP.
06:23 chromatic That would be great!
06:23 GeJ Does the general audience here think that such a series would make sense? is this a duplication of an already existing effort?
06:25 GeJ Actually, it came to me when I realized that besides running the tests and reporting failures I have done zilch for the project.
06:26 GeJ So I see this series as a way for me to learn Parrot and hopefully do something useful in the future.
06:31 GeJ Christian Aperghis-Tramoni has made a series of articles for a French magazine, but he did that at the PASM level IIRC.
06:32 GeJ It was last year I believe. I was thinking about doing something similar but starting with PIR and including all the changes that happened since then.
06:52 Theory joined #parrot
07:08 uniejo joined #parrot
07:13 lathos Starting with p
07:13 lathos PIR would be better, yes.
07:44 chromatic Hm, that cache doubled the speed.  Nice.
07:45 moritz chromatic: there's another speed task coming ;) Rakudo's 'make spectest' seems awefully slow in the lex4 branch
07:49 moritz after 7 minutes it just reachec S05
07:51 chromatic This MMD cache will speed that up too.
07:51 apeiron joined #parrot
07:51 elmex joined #parrot
07:51 moritz I hope so.
08:02 chromatic Looks like the naive cache is about 33% faster.
08:02 chromatic Maybe 35%.
08:04 moritz that won't account for the factor 3 (or larger) slowdown in the lex4 branch
08:07 chromatic No, but it's a very naive cache and I'm sure we can get vtable performance much higher with some clever thinking.
08:07 chromatic I might be able to squeeze another 5-7% out of it by freeing one of my temporaries.
08:08 moritz it still feels like there's something smelly going on in lex4 + perl6
08:10 chromatic Wouldn't surprise me.
08:21 tomyan joined #parrot
08:22 tomyan1 joined #parrot
08:27 apeiron joined #parrot
08:57 alvar joined #parrot
08:57 alvar joined #parrot
09:35 barney joined #parrot
09:37 iblechbot joined #parrot
09:37 Hadi joined #parrot
09:43 samlh joined #parrot
09:48 ff-wonko joined #parrot
10:01 mberends joined #parrot
10:03 ff-wonko joined #parrot
10:20 Hadi left #parrot
10:23 Theory joined #parrot
10:36 ff-wonko joined #parrot
10:56 cotto barney, I think you're right about a proper Pipp grammar having to use variables to keep track of how tags need to match.
10:56 cotto I'm working on a test language to make sure I know how to make it work.
10:57 cotto I was hoping to avoid dropping down to PIR, but I can't really expect elegance in a PHP parser, can I? ;)
11:08 Theory joined #parrot
11:12 cotto PCT is surprisingly easy.  pmichaud++
11:16 barney cotto: It would be nice to avoid keeping track of tags, but I fear so
11:17 moritz what's different in the case of tags then, say, parsing quotes as "..." and '...'?
11:17 barney when you have a consise example, you could add it to t/compilers/pct/complete_workflow.t
11:17 moritz s/then/than/
11:19 barney moritz: Inlined HTML is treated as a single echo statement. This effectively changes the tag style
11:19 moritz ouch
11:20 cotto s/HTML/text/
11:20 cotto (which means that we at least don't have to care about html parsing)
11:21 cotto barney, why would an example in complete_workflow.t be useful?
11:21 barney We might have to care about HTML parsing, for things like session management
11:21 cotto I don't see the connection.
11:22 barney Just for reference. Or as an early indicator when a PCT feature, that Pipp needs, is broken
11:22 moritz (for the record) a few hours earlier I reported a huge slowdown in the lex4 branch. Now I can't reproduce it anymore, I guess there was something wrong with my laptop instead
11:23 barney I started complete_workflow.t because I thought that I had run into a PCT bug
11:23 moritz barney: why does session management needs HTML parsing? Usually it's done through cookies, which are transported in the HTTP header
11:23 cotto barney, I don't think a working example will need anything other than inline PIR, which I wouldn't expect to be particularly buggy.
11:25 barney moritz: The PHP session extension checks the availability of cookies. When cookies are turned off, than a session id is inserted in all internal links
11:25 * barney likes simple examples
11:25 Theory joined #parrot
11:26 cotto barney, where's that documented?
11:26 cotto I hadn't heard of that before.
11:30 barney http://de.php.net/manual/cs/ref.session.php
11:30 barney Probably a filter hook for extensions will suffice
11:34 Ademan joined #parrot
11:35 kj joined #parrot
11:52 Theory joined #parrot
11:54 Ademan joined #parrot
11:56 dalek r32972 | bernhard++ | trunk:
11:56 dalek : RT#60682: [PATCH] rewrite of subclass.t to PIR
11:56 dalek : Courtesy of Bruce Stockwell.
11:56 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32972
12:02 gaz joined #parrot
12:14 ff-wonko joined #parrot
12:15 dalek r32973 | bernhard++ | trunk:
12:15 dalek : [Pipp] Rewrite rule 'singlelinecomment'
12:15 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32973
12:27 jimmy joined #parrot
12:31 dalek r32974 | bernhard++ | trunk:
12:31 dalek : [Pipp] add some comments in grammar.pg
12:31 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32974
12:31 davidfetter joined #parrot
12:35 cotto barney++ #"in most cases broken HTML'
12:35 cotto ok.  When I can't match quotes it's time for bed.
12:35 cotto night
12:36 ff-wonko joined #parrot
12:46 rkw joined #parrot
12:52 Theory joined #parrot
12:56 ff-wonko joined #parrot
13:05 cout joined #parrot
13:07 Lorn joined #parrot
13:15 dalek r32975 | bernhard++ | trunk:
13:15 dalek : [t] Simplify t/examples/namespace.t
13:15 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32975
13:16 dalek r32976 | pmichaud++ | lex4:
13:16 dalek : Nothing else refcounts the from_ctx for retcontinuations, so we
13:16 dalek : probably shouldn't either.  This eliminates at least one memory
13:16 dalek : leak but means that PGE doesn't compile, so we need to track that
13:16 dalek : down.
13:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32976
13:18 pmichaud (slowness of perl6 in lex4 branch) -- I suspect that's because of memory stress due to context leaks.
13:19 pmichaud every subroutine call was eating up an extra 100 bytes or so.
13:20 moritz I've tested it again a few hours ago, and had only 10% slowdown or something
13:20 moritz (which could be the MMD speedup in trunk by chromatic++, actually)
13:20 ff-wonko joined #parrot
13:26 pmichaud did chromatic commit his speedup?  I didn't see it above
13:27 moritz I think not the MMD cache, but a different, smaller one
13:28 moritz r32963 "This gives a modest 5% speedup on very MMD heavy code"
13:29 pmichaud ah.  That is probably not in the branch yet.
13:30 jonathan Ah, chromatic did an MMD cache?
13:30 * jonathan was going to hack on that today...
13:30 pmichaud whatever r32963 says
13:31 moritz jonathan: I don't know, but he didn't commit a cache yet
13:31 pmichaud lex4 branch has another segfault/dead context issue
13:31 jonathan No, that's not a cache, that's just temporary PMCs being used.
13:31 jonathan The same one being hunted last night? Or a new one?
13:31 pmichaud new one.
13:31 purl it has been said that new one is generated.
13:32 pmichaud it would be interesting to see what failures others get.  PGE doesn't build on my system, but more usefully some of the tests in t/op fail now.
13:33 pmichaud ...including   t/pmc/complex.t  :-) :=)
13:34 jonathan pmichaud: With context related issues?
13:34 jonathan Are just floating point ones?
13:34 moritz t/op/debuginfo.t seems to hang
13:34 pmichaud undoubtedly context-related
13:35 pmichaud yes, I get hangs if I leave the normal context recycling in place.  I'll commit the 'free' patch.
13:36 dalek r32977 | pmichaud++ | lex4:
13:36 dalek : Free contexts instead of recycling them in a pool.  This makes it easier
13:36 dalek : to catch some segfaults.
13:36 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32977
13:39 nopaste "pmichaud" at 72.181.176.220 pasted "prove -r t/pmc in lex4 branch r32797" (12 lines) at http://nopaste.snit.ch/14668
13:41 nopaste "pmichaud" at 72.181.176.220 pasted "prove -r t/op in lex4 branch r32797" (7 lines) at http://nopaste.snit.ch/14669
13:41 jonathan We fail to build PGE on Win32 too.
13:41 pmichaud right
13:42 pmichaud I let it build to the PGE failure, and then run prove directly
13:42 jonathan I need to do some non-Parrot stuff for a bit
13:42 pmichaud okay.
13:42 jonathan But will post results of the tests when they've run
13:45 Coke ~/always look on the bright side of life /~
13:46 davidfetter i love the smell of monty python quotes in the morning
13:46 * Coke has just found the monty python channel on youtube.
13:47 Coke we should definitely link to this on our website:
13:47 Coke http://www.youtube.com/watch?v=​4vuW6tQ0218&amp;feature=related
13:47 Coke parrot?
13:47 purl it has been said that parrot is our teacher, our mother, our secret lover or the reason Dan started or the reason Dan left or pretty onionish:)
13:47 Coke parrot is also http://www.youtube.com/watch?v=​4vuW6tQ0218&amp;feature=related
13:47 purl okay, Coke.
13:52 jonathan pmichaud: Here, lexicals.t hangs
13:52 pmichaud did you try 32977 instead?
13:52 jonathan I svn up'd sicne the last commit, I think
13:52 pmichaud (It actually mem_sys_free's the contexts instead of recycling them in pool)
13:54 pmichaud ah, object-meths.t #26 is nice and short.
13:54 pmichaud ...and it segfaults.
13:55 pmichaud that looks traceable.
13:56 nopaste "jonathan" at 85.216.157.73 pasted "epic fail" (51 lines) at http://nopaste.snit.ch/14670
13:56 pmichaud well, the t/compilers/pge tests are pretty obviously going to fail.  :-)
13:58 jonathan True
13:58 pmichaud oooh, object-meths.t fails after only two iterations.  This is even better.
13:59 pmichaud ...and it fails without the tailcall.  even better.
14:02 pmichaud it always bugs me that turning on tracing (-t1) changes the results so substantially.
14:07 pmichaud I wish I understood the rationale behind RetContinuations
14:11 pmichaud oh.
14:13 mj41_ joined #parrot
14:14 Coke -t1 changes things? like -t4 used to?
14:15 pmichaud I had a program -- running without -t1 segfaulted after two iterations, running with -t1 segfaulted after 87.
14:15 Coke if was a GC related segfault that doesn't surprise me at all.
14:16 Coke if it was not, then, yah, that's bad.
14:16 * Coke kicks off a tcl spectest run to see if chromatic's fix helps.
14:16 Coke s/fix/5% speedup in some cases/
14:17 pmichaud gc related, yes.
14:19 Coke well, the stuff in -t1 has to take up GC resources; unfortunate, but inevitable.
14:19 Coke but if your program has a GC bug (goes away with -G) you have other debug options.
14:20 Coke I've had pretty good luck using chromatic's posts... moment.
14:20 pmichaud tis okay, I'm past that one now.
14:20 Coke http://www.oreillynet.com/onlamp/blog/200​7/10/how_to_debug_a_gc_problem_in_p.html
14:20 pmichaud I now know _what_ is causing the gc error, but I don't know what to do to fix it
14:21 Coke wozzit?
14:21 pmichaud retcontinuations don't increase the reference count on their context
14:21 pmichaud as a result if anything else releases the context, it gets freed immediately (even though the retcontinuation still needs it)
14:22 jonathan pmichaud: We can make RetContinuations increment the count too, I guess, so long as they also dec it when they go away.
14:22 Coke now, without looking at the code, wouldn't the fix be for retcons to .... right.
14:22 Coke no?
14:22 pmichaud I don't understand why they don't in the first place.
14:22 jonathan pmichaud: Probably a stupid attempt to be "optimal"
14:22 Coke bug?
14:22 purl i heard bug was http://www.cbttape.org/funny/bug3.jpg
14:23 Coke purl, you funny.
14:23 purl Coke: what?
14:23 pmichaud but yes, we can have retcons increment the count, and we have to remove the fact that the refcount increments when a retcon is promoted to a continuation
14:23 jonathan Yes
14:23 pmichaud (and I don't quite understand why we have retcons in the first place -- another attempt to be "optimal"?)
14:23 pmichaud I'll try incrementing the refcount
14:23 pmichaud this also explains why jonathan needed the fix he did last night
14:25 pmichaud well, having retcons increment the count causes lots more failures.  :-(
14:25 Coke if chromatic's fix gives me 5% improvement in speed, it'll shave -10 minutes- off the spec test run.
14:32 Coke if someone with IMCC-fu makes a patch for #36283, I can fix the build/make test/languages.
14:33 kj Coke: that ticket can't be fixed easily
14:33 kj hello, btw :-)
14:36 kj mmm, maybe it can...
14:36 kj ah I think it mightn't be hard after all :-)
14:38 pmichaud theory:  retcontinuations assume that nothing else will reference their from_ctx, and that if anything does reference the from_ctx then the retcontinuation gets converted to a continuation
14:40 pmichaud bbiab
14:50 gryphon joined #parrot
14:51 Coke kj: i was able to get a patch that errored out whenever the = was used, but couldn't quite find the generated C code that kept track of what was inout.
14:51 Coke kj: (might not be) excellent.
14:51 Coke if you can do the delicate work there, I can do all the grunt work of editing PIR code.
14:51 kj Coke: working on something
14:51 kj Coke: should only IN operands be disallowed
14:52 kj so is OUT, and INOUT fine?
14:52 kj or only OUT operands?
14:52 kj nopaste?
14:52 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
14:52 purl nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others)
14:52 nopaste "kjs" at 193.1.104.8 pasted "disallow IN operands before '='" (22 lines) at http://nopaste.snit.ch/14671
14:52 kj Coke: check out the nopaste
14:55 kj if you compile with this, then the make process won't finish, because apparently some libs that are compiled (to pbc I'd say) as part of the make process have cases with some misuse
14:56 kj specifically: runtime/parrot/library/Crow.pir:16    getopts = push 'type|t=s'
14:57 kj and indeed, I wouldn't write that like that: push is done on getopts (a PMC), so that's not an OUT operand
14:58 Coke kj: we need to disallow INOUT also.
14:58 Coke can we change that line to != PARROT_ARGDIR_OUT ?
14:58 Coke (does that do what I want?)
14:59 kj exactly
14:59 Coke SPIF.
14:59 kj then it should work, but when applying, some library code should be updated, as I mentioned above
15:00 Coke ayup. I'll make sure 'make test' works before committing, at least.
15:01 Coke kj++
15:01 Coke ayup. I'll make sure 'make test' works before committing, at least.
15:01 Coke er,
15:01 Coke kj++
15:01 kj Coke++ # cleaning up tickets
15:01 kj you've been working hard the last 2 weeks!
15:02 Coke almost like I'm avoiding studying for a final.
15:02 rindolf joined #parrot
15:02 rindolf Hi all.
15:03 kj Coke: there's another deprecated thingy in IMCC, it's in DEPRECATED.pod, but not sure if there's a ticket. It's the functions iINDEX{SET,FETCH}
15:04 kj they make indexing strings work  and convert them into substr with a slice size of 1.
15:04 kj around line 403
15:04 Andy joined #parrot
15:05 kj the parts with the 'S' test can be removed I think, but again, there might be some library code that uses this, which should be updated (but ISTR I did some of those conversions few months back)
15:05 Coke if you want to make patches for them (just against imcc.y and I can regen things), I can do the actual PIR cleanup.
15:05 kj I'm kinda working a bit now, but I can do that later today, otherwise tomorrow.
15:05 pmichaud I know that I've seen a few cases where people use indexing on strings.
15:06 pmichaud might even be some in the rakudo libraries :-(
15:06 kj ah what, the heck. I'll make the patch now, it's easy enough (but then I should get back to work! :-)
15:07 Coke kj: slight bug in patch?
15:08 nopaste "coke" at 193.200.132.135 pasted "slightly modified" (35 lines) at http://nopaste.snit.ch/14672
15:08 Coke JSON = compreg "JSON"
15:09 Coke 1298:=item B<compreg>(out PMC, in STR)
15:09 Coke 1306:=item B<compreg>(in STR, invar PMC)
15:09 kj ah I know
15:09 kj that's what I was afraid of...
15:09 Coke (I also added in the name of the opcode in the error message)
15:09 kj I basically assumed that all variants have at least the same direction on the first operand
15:10 kj the trouble is, if you really want to have the opinfo object of the instruction that is actually used, then you need to know its full signature
15:10 Coke ok, but we can get that with the opinfo, neh?
15:10 kj now you just get the opinfo object of a random member of the opcode "family"
15:10 kj well, no.
15:10 kj now we apparently got the opinfo of the in STR, invar PMC variant
15:11 kj because we take the short name of the opcode
15:11 Coke right, but the func_ins call has to know what opcode is getting inserted, no?
15:11 kj and retreive the opcode of that
15:11 kj and use that as an index in the op_info_table
15:11 kj only when generating bytecode is the final opcode calculated
15:12 kj by generating _s, _p, _i etc on the short opname
15:12 kj so that's what I meant by "not easily fixed" as my first reaction :-(
15:12 kj so, the op_info_table has all the opinfo objects
15:13 kj and when doing a check whether a certain string is an opcode (like "print") it will return one member of the print_* family of opcodes
15:13 kj but you don't know which (it's probably the first one in the op_info_table)
15:13 kj so it can be print_s, print_i or any other
15:14 Coke where is that table defined?
15:14 kj so you might retrieve compreg_s_p, while you actually want compreg_p_p (or whatever)
15:14 kj op_info_table? I don't know
15:14 Coke core_ops.c ?
15:14 purl hmmm... core_ops.c is o.k.
15:14 kj never checked it. Check out the structure of the op_info object in include/op.h
15:14 kj s/object/struct/
15:15 kj so basically, the problem is, the check (of operand direction) MUST be done in the parser, because there you know whether '=' is used
15:15 kj but you don't know the full signature name yet. To calculate it in the parser is a bit of a waste of cycles
15:15 kj because it's already done in the backend (pbc.c i think)
15:16 kj so, of course you could change IMCC so that it will do it in the parser, but the phrase "good luck" would be applicable...
15:16 Coke do we have to make it a parse time error?
15:17 kj is there an option to make it a runtime error?
15:17 Coke if we know the direction when we're generating the bytecode..
15:18 kj you can't do the check anymore when doing bytecode generation, because we don't "remember" whether the user used PIR sugar ('='), as opposed to PASM style
15:18 Coke (we don't know then that we had the = syntax, though. we'd have to pass that along too, which smells evil.)
15:18 kj exactly
15:18 Coke so, good luck it is. hurm.
15:18 kj so, we can close the ticket in version 1.5 (or 2.0? I have to check ROADMAP)
15:19 kj (if s/imcc/pirc/ :-)
15:20 Coke is pirc going to make this any easier?
15:20 kj it's implemented in pirc ;-)
15:20 jhorwitz joined #parrot
15:20 kj pirc compiles well now on linux I think, so you could check it :-)
15:21 kj (but probably I only check for ARGDIR_IN, which should be ARGDIR_INOUT, but that's easily fixed)
15:21 * jhorwitz crawls out from under a rock
15:21 * Coke moves the rock and drops it back on jhorwitz.
15:22 kj Coke: I'll send you the substr patch, but you'll have to recreate it, as I don't properly invoke bison (i'm on windows+cygwin here)
15:23 Coke can you attach it to the ticket?
15:23 kj so I'll just send the imcc patch, and you can regenerate imcparser.c from that, is that ok?
15:23 kj sure
15:23 kj will do
15:23 particle WHO BROKE PARROT?
15:23 kj eh, just the imcc.y patch I mean
15:23 Coke yes. sending patches for -just- imcc.[yl] is preferred, I think.
15:23 jimmy its self
15:23 Coke particle: Could you be more specific?
15:24 rindolf In file included from src/pmc/default.c:17:
15:24 rindolf src/pmc/pmc_default.h:18: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PMC’
15:24 rindolf Should I run make clean first?
15:24 particle compilers\imcc\pcc.c(232) : error C2057: expected constant expression
15:24 particle compilers\imcc\pcc.c(232) : error C2466: cannot allocate an array of constant size 0
15:24 particle char bufcache[lenpref + lenitem * PCC_GET_ARGS_LIMIT + lensubf];
15:24 particle not c89-friendly
15:25 Coke rindolf: is that in the lex4 branch?
15:25 rindolf Coke: no, trunk
15:26 Coke realclean can't hurt.
15:26 * particle fixes and rebuilds
15:27 kj Coke: the $S0[1] => substr X, 1, Y mapping doesn't seem to be in DEPRECATED
15:27 kj ISTR it was there..
15:27 pmichaud I don't remember the $S0[1] deprecated note, but I  might've just missed it.
15:28 kj pmichaud: maybe it's no longer deprecated. I'm quite sure it was at some point.
15:30 apeiron joined #parrot
15:30 jimmy there were some errors in src/string.c?
15:31 pmichaud it'd be fine with me if it was deprecated.  :-)
15:39 dalek r32978 | bernhard++ | trunk:
15:39 dalek : [Pipp] Try to add support for class constants,
15:39 dalek : but do not succeed yet.
15:39 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32978
15:40 jimmy bernhard++
15:41 barney I need to take a fresh look at $?INIT later
15:55 jimmy i think pipp will support thread.
15:56 jimmy expect it.
15:56 jonathan Not until Parrot 1.5...
15:57 jonathan ...probably...
15:57 rindolf Coke: now it compiles.
16:01 * jonathan starts some MMD and type related Rakudo hacking
16:02 pmichaud please don't say "not until Parrot 1.5" -- I think it's misleading.
16:02 pmichaud some things might happen sooner than that.
16:02 jonathan OK, they *may*.
16:02 pmichaud no, I'm thinking in the other direction.
16:02 jonathan Like, they likely will?
16:02 pmichaud the point of the roadmap was to identify the _latest_ release in which something would be available, not the earliest.
16:02 jonathan Ah, true.
16:03 jonathan OK, by Parrot 1.5 at the latest.
16:03 cognominal compiling the last svn after a make realclean , and got an error in io.h:248
16:03 cognominal apparently PARROT_API  is not know anymore
16:04 jonathan cognominal: Maybe try a make realclean?
16:04 Infinoid good morning.  how's lex4 today?
16:04 jonathan If you didn't already.
16:04 pmichaud still working on lex4
16:04 pmichaud I understand a bit more about continuations this morning.
16:04 kj cognominal: PARROT_API is now PARROT_EXPORT
16:05 Infinoid still refcounting woes?
16:05 pmichaud right now it appears there's a problem with :vtable
16:06 cognominal trying to remove the io.h, before doing the svn update.
16:06 pmichaud I think I'm going to add our refcount traces to trunk, so I can see what's happening there.
16:06 pmichaud (by way of comparison)
16:07 * pmichaud does that now.
16:07 Infinoid cool
16:07 cognominal apparently a glitch with svn...
16:07 pmichaud it looks to me as though contexts for PCCINVOKE are never reclaimed.
16:09 jonathan The bug I fixed last night was a discrepancy in PCCINVOKE stuff. It wouldn't surprise me if there were more there...
16:09 pmichaud actually, I need to revert that.
16:09 pmichaud (based on my current understanding of retcontinuations)
16:09 workbench joined #parrot
16:11 pmichaud my current working theory is that retcontinuations do not refcount their from context
16:13 pmichaud and that it's the ->ctx refcount in Sub that is causing such contexts to be prematurely recycled.
16:15 jonathan compilers\imcc\pcc.c(232) : error C2057: expected constant expression
16:15 jonathan (In trunk, latest revision)
16:15 jonathan compilers\imcc\pcc.c(232) : error C2466: cannot allocate an array of constant size 0
16:16 particle jonathan: yep, that's chromatic's fault
16:16 pmichaud 15:24 <particle> compilers\imcc\pcc.c(232) : error C2057: expected constant expression
16:16 particle i've been dealing with $job, so haven't fixed
16:16 pmichaud 15:24 <particle> compilers\imcc\pcc.c(232) : error C2466: cannot allocate an array of constant size 0
16:16 pmichaud 15:24 <particle>     char bufcache[lenpref + lenitem * PCC_GET_ARGS_LIMIT + lensubf];
16:16 pmichaud 15:24 <particle> not c89-friendly
16:16 jonathan OK, not just windows...
16:16 pmichaud no, just c89
16:16 pmichaud so probably just msvc
16:16 particle gcc--
16:16 pmichaud depends on what other compilers allow.
16:17 particle how the heck are we supposed to keep to c89 if most of the developers don't  have a compiler that enforces it?
16:17 particle gcc--
16:17 jonathan By having Windows developers with compilers that don't suck? ;-)
16:18 Infinoid or, at least, suck differently enough to let us map out the intersection
16:22 jonathan Patched it.
16:22 dalek r32979 | jonathan++ | trunk:
16:22 dalek : [imcc] Fix broken build for MSVC++. This may not be the ideal fix, but a better one doesn't come to mind right away.
16:22 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32979
16:22 moritz karma MSVC
16:22 purl msvc has karma of 121
16:23 jonathan hah
16:23 jonathan karma C
16:23 purl c has karma of 7300
16:24 moritz karma C++
16:24 purl c++ has karma of -80
16:24 Infinoid karma gcc
16:24 purl gcc has karma of -30
16:24 Infinoid poor gcc.
16:24 Coke part of the problem is that gcc may be warning about it, but no one is keeping on top of the warnings.
16:24 Coke also, newer versions of gcc allow you to turn those into errors.
16:24 particle that warning should be fatal
16:24 Infinoid I check warnings on my platform once a week or so
16:25 Coke ... have you fixed them all, because I have a TON of them. =-)
16:25 particle but, gcc doesn't allow only c89 warnings to become fatal
16:25 Coke particle: newer versions do< I think.
16:25 particle it's all warnings or none
16:25 particle ok, that's news to me
16:25 Coke I had opened a ticket about it.
16:26 Infinoid Coke: how long have those warnings been there?  things were looking pretty good last sunday, there were a few files that had known warnings that I can't fix, which have been there forever
16:27 Coke Infinoid: some time.
16:27 Coke particle: I can't find my ticket. it was about gcc 4.mumble.
16:28 Coke particle: -Werror=<specific wnaring>
16:28 Coke http://gcc.gnu.org/onlinedo​cs/gcc/Warning-Options.html
16:28 Coke Infinoid: once I finish the tcl spec test run, I can see if I can clean any of them up.
16:29 particle coke: seems hints or warnings.pm needs an update
16:30 Coke there was, as I say, a ticket. ISTR I thought we needed to tie it to the config probe for gcc version. I also STR that someone else thought we could just shove it in.
16:31 particle depends on the min supported gcc i suppose
16:31 Coke I think that was in the ticket. =-)
16:32 Coke http://rt.perl.org/rt3/Tic​ket/Display.html?id=50908
16:32 Coke cotto said it was resolved.
16:32 Coke it is possible that no one with a sufficient recent gcc tried to build between that commit and your build.
16:33 nopaste "Infinoid" at 96.238.213.50 pasted "warnings on x86-64" (26 lines) at http://nopaste.snit.ch/14673
16:33 Infinoid those have all been there for a while, and I think they all rely on fixing either system headers, bison/flex, or the headerizer.
16:34 Coke Infinoid: yah. be nice if we could disable warnings when run on certain files.
16:34 Infinoid I take it you're seeing more?
16:35 Coke I will have to check.
16:35 particle coke: we can, there's a cflags file for that
16:36 Coke particle: gcc on feather catches 'statement after declaration' as an error.
16:36 Coke so if there are other gcc warnings that should be errors, we can add them.
16:36 particle i think you meant declaration after statement. good!
16:37 Coke yaya.
16:38 Coke OH.
16:38 Coke no, it doesn't fail. hurm.
16:38 rdice joined #parrot
16:38 Coke (I built one file that warned; the file was still created.)
16:39 * pmichaud makes another stab at lex4
16:40 Infinoid current lex4 doesn't build for me, segfault in PGE, known issue or specific to my box?
16:40 moritz known
16:40 pmichaud known.
16:43 Coke particle: reopened ticket.
16:47 particle coke++
16:48 Coke best part? ticket was still assigned to cotto. Muahahah.
16:49 * Coke wonders how many tests would pass if he got bigint support working.
16:51 Coke how do I check to see if a $N0 is NaN?
16:52 Coke there doesn't seem to be an opcode for it.
16:53 * Infinoid goes and figures out how to disable stack randomization, to make debugging easier.
16:54 Coke we are relying on isnan from math.h ?
16:55 Coke :q
16:55 particle coke: EDOM and ERANGE in errno.h signify domain and range errors
16:55 particle EDOM signifies Inf and ERANGE NaN iirc
16:57 particle i'm not sure isnan is c89
16:57 particle it's worth probing for, if it's not
16:58 tomyan left #parrot
16:59 Coke so if I have a $P1 == Float, how do I check for nan-ness?
16:59 Coke do I just -use- it and check the error?
17:01 particle you can check to see if it equals itself
17:01 Infinoid hmm.  the problem with freeing the context is that the system just turns around and allocates it again.  that doesn't help us find any dangling pointers to the old context, which are now pointing at the new one, or possibly pointing somewhere in the middle of something else.
17:01 pmichaud r32980 in lex4 passes all parrot tests and rakudo 'make test' on my system.
17:01 Coke particle: that's evil.
17:01 Infinoid I'm going to try catching this with efence.
17:01 particle isnan(Float x) { return x != x }
17:02 pmichaud and, afaict, it doesn't leak.
17:02 Coke particle: that's C. =-)
17:02 dalek r32980 | pmichaud++ | lex4:
17:02 dalek : Return to the original Parrot_pop_context semantics
17:02 dalek : (although I'm not entirely sure why it works).
17:02 dalek : Also, Sub VTABLE_invoke creates retcontinuations by default
17:02 dalek : for normal subs, but outer subs convert this to a normal
17:02 dalek : continuation and set a sub->ctx reference.
17:02 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32980
17:03 * Infinoid tests that instead :)
17:03 particle coke: an isnan op may be desired, but yeah
17:04 jonathan pmichaud: Does that want testing on Win32 now?
17:04 pmichaud jonathan: yes.
17:04 jonathan pmichaud: OK, doing
17:04 dalek r32981 | pmichaud++ | lex4:
17:04 dalek : Remove a spurious comment left over from debugging.
17:04 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32981
17:04 pmichaud I'm heading for lunch -- bbi45
17:05 pmichaud reports on lex4 very welcomed.
17:05 Infinoid I still get a dead context exception trying to build PGE
17:05 Infinoid but at least it doesn't segfault.
17:05 pmichaud Infinoid: maybe make realclean, just to be sure?
17:05 Infinoid I did, doing it again just in case
17:05 pmichaud and make sure you don't have any local changes?
17:06 Infinoid I don't.
17:06 pmichaud okay./
17:06 TimToady you just need to invent undead contexts and then keep the silver bullets handy
17:06 Infinoid I have high hopes that efence will turn something up.
17:07 Infinoid (turning the undead is acceptable, too.)
17:07 pmichaud I think it's very likely that this (or something very close to it) will be what merges back to trunk.  It's very close to the original trunk code.
17:08 jonathan pmichaud: lex4 builds here
17:08 jonathan smokin'
17:09 Infinoid ok, maybe my problem is something 64-bit related.
17:09 dalek r32982 | jonathan++ | trunk:
17:09 dalek : [rakudo] Refactor subtypes. The subset class that should never have been is gone, and we can now find out quickly what real, non-subset type was refined.
17:09 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32982
17:10 Infinoid TimToady: aren't the undead another kind of memory leak? :)
17:10 pmichaud I think our problem is that the undead have been supporting us for a while, but they're not first-class citizens in our world.
17:11 pmichaud -D80 gives some pretty interesting diagnostics now, also.
17:12 pmichaud as in, it shows when we "force" recycling of a context in Parrot_pop_context.
17:12 jonathan pmichaud: Bad news - at least one fail.
17:12 jonathan (In make test)
17:12 pmichaud okay.
17:13 pmichaud I'll get lunch, then return.
17:13 pmichaud details on failures welcomed.
17:14 pmichaud Infinoid: even if PGE doesn't build, what does   "prove -r t/op"  and "prove -r t/pmc" give?
17:15 rindolf Can anyone help with http://sial.org/pbot/33299 ?
17:15 nopaste "jonathan" at 85.216.157.73 pasted "lex4 on win32 make test" (7 lines) at http://nopaste.snit.ch/14674
17:16 jonathan rindolf: Ouch! That's...quite a big test case. :-)
17:17 rindolf jonathan: why isn't there a line number?
17:17 jonathan Because we haven't got the stuff in place to show one yet.
17:17 jonathan But that's failing quite far down...
17:17 jonathan Hmm.
17:17 jonathan Oh, no
17:17 jonathan Only in PAST;compiler
17:18 jonathan rindolf: Will need to narrow down exactly what causes the compilation error.
17:18 jonathan It's not making it to runtime.
17:20 nopaste "Infinoid" at 96.238.213.50 pasted "results of t/op and t/pmc on linux/x86-64" (227 lines) at http://nopaste.snit.ch/14675
17:20 Infinoid pmichaud: ^^
17:24 rindolf jonathan: it's the portion starting from my $start = int(@*ARGS.shift);
17:26 jonathan Ah.
17:26 jonathan I suspect that it's because we haven't got type coercions working yet.
17:26 jonathan (e.g. the int(...)
17:27 jonathan rindolf: Try it with my $start = +@^ARGS.shift;
17:27 jonathan erm
17:28 jonathan my $start = +@*ARGS.shift;
17:28 jonathan + numifies it
17:28 jonathan And is implemented.
17:28 rindolf jonathan: no, it's my ($g_val, $composition) = Graham($n);
17:28 rindolf jonathan: list assignment.
17:28 purl list assignment is default in perl 6, but don't know about a 'default' in PAST. probably better to specify either list or scalar
17:28 Coke particle: your equality trick works in PIR, even.
17:29 Coke it does seem to just be a trick, though.
17:29 jonathan rindolf: Aha.
17:29 Coke particle: what about inf?
17:29 jonathan List assignment is todo. Being done soonish, I believe.
17:29 rindolf jonathan: ah.
17:34 rindolf jonathan: OK, now I'm getting a few run-time errors.
17:34 rindolf Without line numbers. <sigh />
17:34 nopaste "jonathan" at 85.216.157.73 pasted "pmichaud - lex4 results for Rakudo spectest" (8 lines) at http://nopaste.snit.ch/14676
17:35 jonathan rindolf: Yes, there's some work to do before we can show those, I'm afraid. :-(
17:35 rindolf jonathan: OK.
17:42 dalek r32983 | jonathan++ | trunk:
17:42 dalek : [rakudo] Pull refined real type out of subtypes when constructing a signature, so multiple dispatch handles subtypes more correctly (possibly even completely correctly now).
17:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32983
17:49 Infinoid pmichaud: I hate to keep giving you bad news... but http://nopaste.snit.ch/14662 still leaks in r32981.
17:49 nopaste "Infinoid" at 96.238.213.50 pasted "valgrind leak summaries" (121 lines) at http://nopaste.snit.ch/14677
17:55 pmichaud Infinoid: ... that's odd.
17:55 pmichaud I don't get at all the same results with valgrind.
17:55 pmichaud oh wait, yes I do now.
17:56 pmichaud okay, I'll look into that first.
17:59 pmichaud another strategy I thought of at lunch is to have Parrot_free_context "poison" the freed contexts, but don't mem_sys_free them or place them on the recycle pool.  Then if anything tries to use them after poisoning, we'll know what it is.
17:59 Coke if it's like GC, isn't the problem that something is freeing it, not that something is using a freed one?
17:59 Infinoid that's exactly the reason why I tried going the efence route.  unfortunately, other issues prevented me from getting far enough to test that
18:00 pmichaud Coke: it's a bit of both.
18:00 Infinoid pmichaud: valgrind's --freelist-vol option looks useful for that.
18:00 pmichaud Coke: contexts use a refcount approach for management, instead of marking
18:00 pmichaud so it's entirely possible for something to refer to an otherwise-freed context
18:01 chromatic joined #parrot
18:01 chromatic left #parrot
18:01 chromatic joined #parrot
18:01 Infinoid I've also tried doing an rwatch on the contents of the freed context
18:03 pmichaud sub/pmc/sub.pmc:284
18:03 pmichaud /* XXX: Why is this reference needed...? */
18:03 pmichaud Parrot_context_ref(interp, context);
18:03 pmichaud I don't like those lines.
18:04 pmichaud it bugs me that I have a Parrot_context_ref with no corresponding free.
18:04 dalek r32984 | jonathan++ | trunk:
18:04 dalek : [rakudo] Another spectest that we now pass much of.
18:04 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32984
18:05 pmichaud I'm going to try the context poisoning approach, I think.
18:08 pmichaud is there a better value to use besides "NULL" to force a segfault if dereferenced?
18:08 particle 0xdeadbeef ?
18:08 particle 0x5afecafe ?
18:08 pmichaud I know we use that to indicate freed stuff in gc; I'm not sure I want to re-use it for contexts.
18:08 pmichaud (0xdeadbeef)
18:09 pmichaud it might lead people to look at the wrong gc
18:09 particle it'd be nice to have a unique one
18:10 chromatic 0xbeefcafe
18:10 pmichaud okay.
18:10 pmichaud that it is.
18:10 chromatic Because we can't spell 0xmmmbrisket
18:10 chromatic ... without base-22 compilers.
18:15 Infinoid oh, great... PGE/builtins_gen.pir is built just fine when I run parrot under valgrind
18:15 sjansen joined #parrot
18:19 integral joined #parrot
18:21 Infinoid oh, this is interesting.  building TGE, I caught Parrot_Continuation_mark calling mark_context on a freed context
18:21 jonathan Infinoid: Is it a RetContinuation or a Continuation?
18:22 jonathan (check vtable->base_type)
18:22 Infinoid that was under valgrind, I'll try gdb
18:24 Coke 0xdeadabba
18:24 Infinoid its a enum_class_RetContinuation
18:25 jonathan Hmm. A RetContinuation that didn't get invoked yet, then.
18:26 Infinoid well, according to valgrind, its context has been freed
18:27 Infinoid when I ran it under gdb, the freed buffer was probably immediately reallocated, so it died a couple of calls later.
18:27 pmichaud that's why I like the poisoning approach (about finished)
18:27 pmichaud it can prevent reallocation of contexts.
18:28 Infinoid yes, valgrind does that automatically, but your way would help the gdb case too
18:29 jonathan So are we giving ref counts to contexts when RetContinuation references them or not?
18:29 pmichaud no.
18:29 pmichaud (for now.)
18:29 nopaste "Infinoid" at 96.238.213.50 pasted "here's what valgrind had to say." (96 lines) at http://nopaste.snit.ch/14678
18:29 pmichaud right now I'm pretty closely following what trunk does in this respect.
18:29 jonathan It seems in some cases the RetContinuation outlives whatever was the thing that did have the ref count.
18:29 Infinoid so that tells us where it was freed, and also where it was accessed
18:30 jonathan I guess you don't invoke the retcontinuation if you throw an exception and leave a sub that way, for example.
18:30 Infinoid isn't this an argument for the retcontinuation holding a reference on the context?
18:31 pmichaud I don't understand the whole retcontinuation approach yet.
18:31 Infinoid you guys understand it a lot better than I do. :)
18:31 jonathan If we have cases when a RetContinuation (correctly) outlives anything else holding a reference to a context, that'd suggest that yes.
18:32 pmichaud my working theory is that retcontinations are things that have no other references to them
18:32 Coke 0xdeafabba
18:32 Infinoid if not, then it just slows things down and doesn't provide a benefit (except, er, not crashing), right?
18:32 pmichaud and if something takes a reference, then the retcontinuation is supposed to be converted to a continuation
18:32 pmichaud (and the reference count is increased)
18:32 Infinoid Coke: ouch.
18:33 jonathan pmichaud: OK, I think here the case here may be along the lines of, we never invoke the retcont, so it keeps a pointer to the context.
18:33 pmichaud jonathan: and the retcont has to still be a live.
18:33 jonathan But in the meantime, the other thing that did reference it has freed it.
18:33 pmichaud "alive"
18:34 pmichaud oh.
18:34 * Infinoid goes and reads docs/pmc/subs.pod
18:34 pmichaud jonathan: if what you're saying is correct, then that means something is taking a reference to a retcont that shouldn't be.
18:34 pmichaud (to the context that a retcont is using)
18:35 pmichaud and I still haven't completely figured out why it's the "from" pointer we keep track of and not the "to" pointer.
18:36 Infinoid cc->to_ctx is the one that got freed
18:38 pmichaud right.
18:38 Infinoid you're talking about the refcounting done in new_continuation(), right?
18:39 pmichaud in a variety of places.
18:39 pmichaud invalidate_retc_context is another.
18:39 Infinoid is there an assumption that to_ctx is somewhere in the current context's caller_ctx chain, and is protected by that?
18:39 pmichaud there may be.
18:40 pmichaud I do know that contexts were viewed as a stack for quite a long time.
18:40 pmichaud so returning to a point higher in the stack was the same as "releasing" all of the contexts on top of it.
18:40 pmichaud (I think.)
18:40 Infinoid which makes sense, coming from a C background
18:41 pmichaud (I know that it was viewed as a stack... I don't know that the release implementation was made that way.)
18:47 chromatic That sounds right to me.  I kept thinking "That won't work; this is a call *graph*."
18:48 pmichaud a-ha.
18:48 pmichaud this might be a problem:
18:48 pmichaud if a RetContinuation is cloned, that produces a Continuation
18:48 pmichaud the Continuation holds a reference to the context
18:49 pmichaud if that Continuation is then destroyed, it releases its reference
18:49 jonathan pmichaud: I'm starting to think we really should just refcount RetContinuations.
18:50 pmichaud oh... never mind -- what I was thinking of is okay
18:50 jonathan Lying about not having a reference when we have one seems to be causing trouble.
18:50 pmichaud jonathan: (1) I've gone that approach, without too much success
18:50 Infinoid ...and relying on nothing else calling Parrot_free_context in the meantime (holding a reference or not)
18:50 dalek r32985 | kjs++ | trunk:
18:50 dalek : [docs] update PIR articles.
18:50 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32985
18:50 pmichaud (2) I'm still wondering _why_ we need RetContinuations in the first place
18:51 kj joined #parrot
18:51 jonathan pmichaud: I think the idea is that we have a kind of "one shot" continuation, that is cheap and doesn't need us to make a real continuation.
18:51 jonathan Just for the purpose of doing a return.
18:51 pmichaud I can't tell that it's any more/less cheaper than a normal continuation.
18:51 pmichaud certainly that's not the case if we're refcounting them.
18:52 dalek r32986 | kjs++ | trunk:
18:52 dalek : [pirc] tests, documentation and fixes.
18:52 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32986
18:52 pmichaud (well, it may still be the case ... but I haven't seen it.)
18:52 jonathan Because you don't have to "capture" (wrong word...I know) the whole call chain, which I guess you'd need to do if you had a real continuation. Or something liek that.
18:52 jonathan *like
18:52 pmichaud real continuations don't really capture the whole call chain
18:52 jonathan I always had a hard time following those areas of the code, though.
18:53 pmichaud they do make sure that all of their callers are continuations
18:53 pmichaud but that sounds like a circular argument.
18:54 pmichaud again, it might've been the case that retcons were cheaper when we had a stack, but that's no longer the case.
18:54 pmichaud or if it is, I haven't seen how.
18:58 tewk_ Yeah, continuations need to capture the whole call chain or at minimum mark contexts as COW.
19:04 pmichaud okay, here's the other piece that bothers me.  Currently a sub that is an outer sub changes its retcontinuation into a full continuation
19:04 pmichaud presumably this is because its context may need to live beyond the completion of the sub
19:05 pmichaud but in other locations when we convert a retcontinuation into a full continuation, we also convert all of its callers as well (see  invalidate_retc_context)
19:06 pmichaud I'm thinking that Sub.invoke should call invalidate_retc_context instead of converting the retcont directly...
19:06 pmichaud but...
19:06 pmichaud in what situations are we going to have the case that everything doesn't just end up being a continuation ?
19:06 pmichaud I suppose for deeply nested chains of non-outer subs we'd have retcontinuations
19:07 pmichaud but I suspect that doesn't happen all that often in most of our target languages.
19:08 Coke why not try ripping out retcons and see what happens?
19:08 chromatic +1 here
19:08 barney joined #parrot
19:09 Coke chromatic can always speed things up later. :|
19:09 pmichaud that's a bit more significant a change than I was wanting for the branch (more)
19:09 pmichaud I guess I'd also like to hear from allison if she things we need retcons, and why.
19:09 pmichaud *thinks
19:11 pmichaud okay, I'm curious what people get with r32987.  I added context poisoning to the mix.
19:12 dalek r32987 | pmichaud++ | lex4:
19:12 dalek : "Poison" contexts whenever they're released to the recycle pool.
19:12 dalek : If anything then tries to use a poisoned context, we should get
19:12 dalek : some sort of segfault or error.  There's also a "slot = 0" line
19:12 dalek : (commented out by default) that prevents contexts from ever
19:12 dalek : being re-used but that doesn't show up as a memory leak in
19:12 dalek : valgrind.
19:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32987
19:12 pmichaud uncomment src/gc/register.c:605 to prevent contexts from being reused.  Then anything that has a reference to a freed context will have a reference to a poisoned context (and hopefully we can find out what it is).
19:13 pmichaud s/reference/pointer/g
19:13 pmichaud I have to run a couple of errands -- back in 30  :-|
19:16 stockwellb joined #parrot
19:16 stockwellb init::manifest -      Check MANIFEST...No such file: languages/perl6/src/classes/Subset.pir
19:16 stockwellb oops I didn't no pasting would do that. I'm sorry.
19:17 stockwellb Anyway. I got this a Configure error after I cleaned and svn updated.
19:19 jonathan oh, shite...manifest
19:19 barney fixed
19:20 Coke manifest? I hateses it.
19:20 stockwellb I didn't think that was worth a bug entry. Hope that's alright.
19:20 nopaste "chromatic" at 69.64.234.10 pasted "Coke: Naive MMD Caching; does this help Partcl?" (427 lines) at http://nopaste.snit.ch/14679
19:20 dalek r32988 | bernhard++ | trunk:
19:20 dalek : Regenerating MANIFEST
19:20 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32988
19:21 masak joined #parrot
19:21 stockwellb Is it safe to kill a make in progress?
19:21 Coke don't see why not.
19:22 barney famous last words
19:22 purl No, I am certain it takes a 7D bolt.
19:22 nopaste "particle" at 98.232.28.49 pasted "test timings for perl .t files with pasm_* functions" (74 lines) at http://nopaste.snit.ch/14680
19:22 particle stockwellb: some of those tests could use conversion to pir
19:22 particle those with the longest time would give the greatest benefit
19:23 particle the first three probably shouldn't be converted, though
19:23 stockwellb I'm going to run make with the timer on and see which is the biggest hog.
19:24 particle ok, i did an ack -al pasm_
19:24 particle to get the list of files that had pasm in them
19:24 stockwellb Oh damn thats what the nopaste is...
19:24 particle yes, it's a few days old, though
19:25 stockwellb gc sounds scary, maybe string?
19:25 particle sure
19:25 stockwellb dang, my first assignment as a Parrot secret agent!
19:26 Infinoid is it a bad sign when you rip context refcounting out entirely, and suddenly parrot builds again, and passes all core tests?
19:26 particle check for leaks
19:26 chromatic Only if you like memory leaks!
19:27 tewk_ so subs today are more like blocks than subs right.
19:27 particle the basic hll block in parrot is a pir sub
19:27 Infinoid oh, I'm sure it will leak like crazy :)
19:28 Infinoid when I get back, I'll see how hard it is to fix that up
19:28 Infinoid lunch &
19:30 dalek r32989 | bernhard++ | trunk:
19:30 dalek : [codingstd] satisfy trailing_spaces.t and c_parens.t
19:30 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32989
19:30 dalek r32990 | jonathan++ | trunk:
19:30 dalek : [rakudo] Put something in to make traits on routines work for now. The whole traits thing needs a good refactor to eliminate the duplication here and elsewhere - will attend to that in the not too distant future.
19:30 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32990
19:37 sjansen joined #parrot
19:41 kj Coke: I'm looking quickly into the disallowing of PASM registers in PIR mode
19:43 kj there's something weird going on. For instance, runtime/library/parrot/Digest/MD5.pir, line 157, an error message (after applying your patch in the rt queue) indicates that no PASM register is allowed. Pasm_file variable is 0, and the matched text is "I0". But that's stragne, because it's clearly $I10. I think it might have to do with the order of the rules in the .l file; I'll move it *after* the rules for $[SNIP]{DIGITS}... that should help.
19:43 dalek r32991 | pmichaud++ | lex4:
19:43 dalek : I've convinced myself that this spurious increment of a context
19:43 dalek : reference is wrong -- it causes context leaks when present, and
19:44 * stockwellb is amazed at the total lines of code in string.t (over 2900).
19:44 dalek : there's no obvious place where it gets released.  So, out it goes.
19:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32991
19:44 chromatic joined #parrot
19:44 cotto pmichaud, ping
19:44 pmichaud pong
19:45 nopaste "cotto" at 96.26.202.243 pasted "almost-working grammar example" (77 lines) at http://nopaste.snit.ch/14681
19:45 cotto can you tell me what's wrong with that grammar?
19:45 jonathan chromatic: In the backscroll I think I read that you had written an MMD cache.
19:46 jonathan chromatic: But didn't see it ci'd...
19:46 cotto It's a simplification something I'm doing for pipp.
19:46 pmichaud cotto: what are you matching it against?
19:46 cotto example:
19:46 cotto <x> foo </x> foo <y> foo </y>
19:47 pmichaud and what do you get when matching?
19:48 dalek r32992 | jonathan++ | trunk:
19:48 dalek : [rakudo] Implement is default trait and use it as a final tie-breaker in multiple dispatch.
19:48 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32992
19:48 * jonathan needs nom - tests for is default afterwards
19:48 chromatic jonathan, it's a (messy) proof of concept that I nopasted for Coke to test.
19:49 chromatic http://nopaste.snit.ch/14679
19:49 jonathan Oh, I missed seeing the nopaste
19:49 chromatic It's very naive, but it's a start.
19:49 pmichaud cotto: I don't think that .return(0) means "fail"
19:49 nopaste "cotto" at 96.26.202.243 pasted "example of how the grammar doesn't work" (17 lines) at http://nopaste.snit.ch/14682
19:51 pmichaud PGE still implements an old version of S05 where returning a value (any value) meant something special -- but didn't necessarily mean "fail".
19:51 cotto ok.  So how would I do match/fail?
19:51 gmansi joined #parrot
19:52 pmichaud if $S0 != $S1 goto fail
19:52 pmichaud .return(1)   # succeed
19:52 pmichaud fail:
19:52 pmichaud }}
19:52 pmichaud <.fail>
19:53 pmichaud hmmm.
19:53 pmichaud maybe not.
19:53 jonathan chromatic: OK, not quite what I had in mind, but looks like it'd work.
19:53 pmichaud I would actually reverse the regex, though
19:53 pmichaud check for '</x>' first, and then make sure that you were wanting to match a <x>
19:53 jonathan chromatic: I wanted really though to attatch the cache to the MultiSub (or some other place for the ops)
19:54 chromatic jonathan, I think we need a different approach for multi-vtables.
19:54 jonathan Since lexical multis or multis in anonymous classes won't last forever, but references to them would in a global cache like this, IIUC.
19:54 pmichaud of course, if you're certain that every open has a close, it could be done all in one rule with:
19:54 chromatic Hm, the MultiSub would be nice.  I thought of that this morning, but I hadn't realized how nicely it makes cache invalidation.
19:55 jonathan Yes, that too.
19:55 jonathan I wasn't going for strings either.
19:55 jonathan I was going to chase down the type IDs of the parameters and cache on those.
19:55 Coke kj: that's why i didn't apply the patch. =-)
19:55 chromatic You'd be surprised how performance-sensitive this is.  I used a naive sprintf to generate the type strings before, and it cost 5%.
19:55 pmichaud token  { '<' (x) '>' <name>? '</' $1 '>' }
19:55 pmichaud er, change that $1 to $0
19:56 jonathan Wow, I'd not have guessed that.
19:56 kj Coke: I did some moves in the lexer of rules, now make process finishes properly, but now the tests fail. maybe because .t files won't make the pasm_file variable set to 1
19:56 kj not sure, have to look into what it is.
19:56 jonathan I did also ponder trying to factor out the adding stuff to an MMD cache and so on.
19:56 jonathan So other MMD implementations can use it.
19:57 jonathan Perl6MultiSub won't always want to cache every result if computes, for example. Like if they're dependent on values than just types.
19:57 jonathan *it computes
19:58 jonathan Also, I'm confused why the name interp->gc_generation?
19:58 jonathan Were you pondering a more general mechanism other than MMD caching?
19:58 chromatic jonathan, I reused an unused interpreter slot because I didn't want to rebuild the whole system by changing interpreter.h
20:00 stockwellb left #parrot
20:00 cotto pmichaud, the actual matching I need to do is more complex, e.g. "<?" -> "?>", "<?=" -> "?>", "<script langauge='php'>" -> "</script>"
20:00 jonathan chromatic: lol!
20:00 jonathan :-)
20:01 chromatic There's another reason I didn't check it in.
20:01 jonathan OK
20:01 jonathan What shall we do?
20:01 jonathan Should I also prototype what I was thinking of too?
20:02 jonathan And then we can compare their performance wins/fails etc?
20:02 pmichaud cotto: okay.  Anyway, .return(1) will currently mark a rule as succeeding (and abort the remainder of the match)
20:03 chromatic I think we need two different things.
20:03 chromatic Making op-to-vtable dispatch go through the marshalling/demarshalling is crazy.
20:03 dalek r32993 | kjs++ | trunk:
20:03 dalek : [t] change a PASM register in a PIR sub into a PIR register. PASM register bad!
20:03 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32993
20:04 cotto pmichaud, thanks.  I'll see how far I can get with that.
20:04 chromatic We have fixed signature types at that point.  Why throw them away by grabbing known-values out of registers, stuffing them in varargs, pulling them out, counting them, getting their types, and stuffing them into registers in a new context?
20:04 jonathan ouch!
20:04 jonathan OK, I need to eat. I'll spend some time looking at exactly what we're doing after I get back.
20:04 chromatic Adding a cache to MultiSub makes sense though.
20:05 jonathan Sure. We may have to keep them as two separate things, but we may be able to squeeze enough re-use out of it to not have to.
20:06 jonathan Anyway, bbiab
20:06 nopaste "pmichaud" at 72.181.176.220 pasted "I find this truly frightening..." (18 lines) at http://nopaste.snit.ch/14683
20:07 pmichaud okay, I'm less frightened.  I didn't realize that Test::More had a 'like' function that depends on PGE
20:08 pmichaud and since pge isn't currently building in the branch, that probably explains why it fails.
20:09 Lorn joined #parrot
20:10 cotto pmichaud, can a PIR macro be defined. then used in inline PIR chunks in a grammar?
20:11 dalek r32994 | kjs++ | trunk:
20:11 dalek : [t] update PASM regs into PIR regs
20:11 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32994
20:11 Coke pmichaud: that makes me think we need to think about our testing strategy.
20:18 pmichaud current lex4 branch passes all tests for me except those that are PGE based.
20:18 pmichaud and think I know what's happening there
20:18 pmichaud (PGE based or otherwise rely on PGE)
20:23 Lorn_ joined #parrot
20:24 bacek pmichaud: rakudo is slightly broken in lex4
20:24 bacek is it expected?
20:24 pmichaud 20:18 <pmichaud> current lex4 branch passes all tests for me except those that are PGE based.
20:25 pmichaud that would certainly include rakudo.
20:25 bacek pmichaud: ah, ok.
20:25 bacek All tests successful.
20:25 purl ship that bitch
20:25 bacek Files=395, Tests=11643, 259 wallclock secs ( 3.41 usr  0.62 sys + 109.33 cusr 28.79 csys = 142.15 CPU)
20:25 bacek Result: PASS
20:26 bacek it's 'make test' in parrot.
20:26 bacek looks good :)
20:28 pmichaud have to go pick up kids from school, back in 30
20:29 pmichaud bacek: how about 32995 ?
20:29 pmichaud (back in 30)
20:29 dalek r32995 | pmichaud++ | lex4:
20:29 dalek : oops -- previous commit left poisoning commented out from earlier debug.
20:29 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32995
20:30 bacek pmichaud: rebuilding...
20:35 bacek pmichaud: ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir  --output=PGE/builtins_gen.pir PGE/builtins.pg
20:35 bacek make[1]: *** [PGE.pbc] Segmentation fault
20:36 particle that's better
20:37 chromatic "better"
20:37 purl i heard "better" was *always* subjective.
20:37 particle thanks, purl
20:38 jonathan I get that on Win32 also.
20:40 nopaste "bacek" at 123.243.38.218 pasted "spoiled context segfault for pmichaud" (51 lines) at http://nopaste.snit.ch/14684
20:43 nopaste "bacek" at 123.243.38.218 pasted "result of bisect for pmichaud" (14 lines) at http://nopaste.snit.ch/14685
20:43 bacek "git bisect run make" rule the World! :)
20:44 particle bacek: it's failing *on purpose*
20:44 bacek afk # breakfast
20:44 bacek particle: yes, I understand.
20:44 particle so bisect isn't helpful
20:49 Coke who is tak?
20:49 purl hmmm... tak is yes, nye is no
21:00 pmichaud segfault is occuring during load_bytecode
21:00 pmichaud of P6object.pbc
21:00 pmichaud that's early.
21:00 Coke that sounds familiar. =-)
21:01 pmichaud looks like it's occuring upon return from that.
21:04 chromatic . o O { Don't say IMCC.  Don't say IMCC, }
21:05 Coke IMCC!
21:07 chromatic That's it, I'm checking in code to make Partcl *slower*.
21:08 Coke ... how will I noticeE?
21:09 chromatic Did you try that MMD patch?
21:11 Coke I ended up doing something about 2.5 hours in that broke the spec test run.
21:12 Coke 5% of 3.N hours is about 10 minutes.
21:12 Coke so it's not going to help much. =-)
21:12 Coke I'll run it overnight.
21:13 chromatic That patch should give you 40%.
21:13 Coke you say patch; is it not committed to trunk?
21:13 Coke I wasn't seeing a 40% speedup.
21:13 chromatic Yes.
21:13 chromatic I nopasted it for you.
21:13 Coke lost in the mists of time. can you do so again?
21:14 davidfetter joined #parrot
21:14 chromatic http://nopaste.snit.ch/14679
21:15 Coke we have a STREQ macro, btw.
21:16 particle skoold!
21:16 chromatic I thought it was STR_EQ
21:16 chromatic No wonder I didn't find it.
21:17 Tene We could just s/_// everything in parrot.
21:17 Coke our choices of when to use and not use hyphens was made by a dyslexic ferret.
21:17 Coke ... and underscores are worse.
21:17 Coke Infinoid: "is declared static and never used..."
21:18 Coke (3*60*60*0.4)/60
21:18 purl 72
21:18 masak dyslexic ferrets seldom get appreciation for their work.
21:20 Coke (3.5*60*60*0.4)/60
21:20 purl 84
21:23 Coke chromatic: I've started the test run with a fresh parrot with your patch and a fresh tcl. I'll let you know what I find.
21:23 pmichaud a-ha!
21:24 pmichaud src/inter_run.c:204
21:24 pmichaud er, 304
21:24 pmichaud ctx = runops_args(interp, sub, PMCNULL, NULL, sig, args);
21:24 pmichaud ...I bet that by the time runops_args is done, that context is already freed.
21:25 chromatic Makes sense why you'd see it from load_bytecode.
21:27 jhorwitz masak: ping
21:27 masak jhorwitz: pong
21:27 masak good evening, sir.
21:28 jhorwitz evenin'.  :)  was poking around november's CGI.pm last week.  would you be interested in (eventually) helping out with a shiny new mod_perl6-aware CGI.pm?
21:29 masak jhorwitz: sure, why not?
21:29 masak sounds interesting.
21:29 masak I still intend for CGI.pm to go away eventually, though.
21:29 masak say, on a three-month time scale.
21:29 jhorwitz excellent!  i'd love to have a bare-bones version w/o all the HTML crap.
21:29 jhorwitz (from the p5 version)
21:29 masak aye.
21:30 masak that's the idea.
21:30 pmichaud amen to that.
21:30 jhorwitz november works great under mod_perl6, but lots of tweaks to CGI.pm to make that happen.
21:30 masak jhorwitz: I suppose you've read Juerd's two emails about it from long ago.
21:30 jhorwitz hm, maybe, maybe not.
21:30 masak jhorwitz: I'd be very happy to collaborate.
21:30 jhorwitz masak++
21:30 masak jhorwitz: let me see if I can find the links.
21:30 Tene masak: I've been wanting to work on that for a long time
21:31 Tene Juerd's posts.
21:31 Tene There are copies in the pugs tree, I think.
21:31 masak Tene: I applied for a Perl 6 microgrant, but didn't get it
21:31 chromatic pmichaud, increment the refcount in src/inter_run.c:238?
21:31 masak Tene: will probably apply for a Perl microgrant in December.
21:31 pmichaud chromatic: exactly what I was looking at.  :-)
21:32 masak Tene: maybe we should apply together.
21:32 pmichaud just got there.
21:32 masak jhorwitz: ah, here: http://groups.google.com/group/perl.perl6.users/br​owse_thread/thread/845b10b8ed7266/a209deddfadad19b
21:32 * jhorwitz clicks
21:32 pmichaud we then have to be sure to free the context after each call to runops_args
21:33 Coke chromatic: -feels- faster, anyway.
21:33 pmichaud or have the setval's do it :-(
21:34 Tene masak: sure.  sounds great to me.
21:35 masak Tene: great. I'll make up a draft and get back to you.
21:35 jhorwitz masak: i agree with most of that
21:36 jhorwitz a bit shaky on the Web::Toolkit bit, but i haven't really thought about it much
21:36 masak jhorwitz: goodie. there will have to be _lots_ of discussion about the details when we create the new Web.pm module
21:36 masak or whatever it's to be called
21:37 jhorwitz *this*one should be CGI, as it will implement CGI, and only  CGI.  but like Juerd suggests, it should probably live under a namespace.
21:38 masak that can be arranged
21:39 jhorwitz or instead of a mod_perl6-aware CGI.pm, a common front end that's aware of both.
21:39 Coke chromatic: going to have to kill this and run it later; one of the kids is chewing up 80% of my CPU with his flash games.
21:40 * jhorwitz smells smoke from his brain working hard
21:41 masak jhorwitz: are you on the November mailing list? would be good to have this type of discussion there.
21:41 jhorwitz URL?
21:41 masak hold on.
21:41 masak http://groups.google.com/group/november-wiki
21:42 jhorwitz danke
21:42 nopaste "pmichaud" at 72.181.176.220 pasted "This really looks like it deserves a refactor (src/inter_run.c)" (201 lines) at http://nopaste.snit.ch/14686
21:43 chromatic I'd like to see most of those go away, actually.
21:43 pmichaud well, me too.
21:43 pmichaud but not this patch.
21:47 jhorwitz masak: joined.  i'm planning on doing a lot of mod_perl6 work this weekend, so i'll try to start up a discussion while it's fresh in my mind.
21:47 pmichaud okay, another segfault.  Let's see where this one is.
21:47 masak jhorwitz: excellent.
21:47 masak jhorwitz: I'll probably be doing quite a bit of November hacking this weeken.
21:48 masak s/weeken/weekend/
21:48 masak the only cap is put by the studying I have to get done
21:49 jhorwitz studying--
21:49 masak yes, but (knowing stuff)++
21:50 jhorwitz :)
21:52 pmichaud hey, PGE built!
21:52 pmichaud now TGE fails.  :-(
21:53 moritz "water bed theory of parrot building"
21:53 pmichaud sounds like the title of my next use.perl post.
21:54 moritz feel free ;)
22:02 apeiron joined #parrot
22:03 dalek r32996 | pmichaud++ | lex4:
22:03 dalek : runops_args() returns a context to its caller (for return
22:03 dalek : values), but the context it returns has often been
22:03 dalek : reclaimed.  So, we add a refcount to it and have all of
22:03 dalek : its callers release the context.
22:03 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32996
22:03 dalek r32997 | pmichaud++ | lex4:
22:03 dalek : If we clone a Coroutine, we need to add a refcount
22:03 dalek : for its ->ctx reference as well.
22:03 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32997
22:10 Hadi joined #parrot
22:14 Hadi left #parrot
22:19 pmichaud okay, now the problem appears to be that a coroutine is holding onto a context that has a caller_ctx that has been freed.
22:19 * jhorwitz wonders what other phantom bugs r23996 has fixed
22:20 jonathan jhorwitz: I don't know, but I'm sure I've seen issues around that area... :-|
22:21 pmichaud well, we always did have some oddities with load_bytecode from time to time, so perhaps this is why.
22:21 jonathan . o O ( My word, no wonder MMD on ops got slow... )
22:21 pmichaud so, I guess I need to refcount the caller_ctx pointers as well?
22:22 jonathan If something holds a pointer to a context, it would seem to me that this should increment the refcount.
22:22 pmichaud it doesn't do so in trunk.  :-(
22:22 pmichaud but yes, I guess that's what will have to happen.
22:22 jonathan :-(
22:23 jonathan Yeah, but I don't know that trunk is a shining example of getting context ref counting right...
22:23 pmichaud fortunately it doesn't look like there are too many of them.
22:23 pmichaud this will all be much easier when context's participate in the normal gc
22:23 jonathan If we can take any performance hit arising from it...
22:23 pmichaud well, that's why we need a better gc first
22:23 * jonathan is specifically doing the MMD cache to avoid creating any more GCable objects.
22:24 pmichaud but even if we don't put the contexts into the standard gc, we'll start to see a performance hit as contexts live longer than they did before.
22:24 pmichaud (as well as the ones they point to)
22:24 chromatic I don't think that'll really be a hit.
22:24 pmichaud and unlike the standard gc mechanism, there's not really a mechanism to say "we've already marked this context on this pass -- no need to mark it or its children again"
22:25 pmichaud so, if a context marks its caller_ctx and its outer_ctx, and they're both the same, we end up doing the work twice.
22:25 jonathan chromatic: I think I'm going to hit the cache first right in the *ops* to avoid the marshalling. Think I'll be forgiven for this? ;-)
22:25 pmichaud (and outer_ctx == caller_ctx is common, which is why I made a special case for it.)
22:26 pmichaud anyway, let's see what happens if we refcount caller_ctx
22:26 chromatic jonathan, are you concentrating on the vtable cache right now?
22:27 jonathan chromatic: I'm doing something that is generic enough we'll be able to use for vtables, as well as from multisubs.
22:28 chromatic Very nice.
22:28 jonathan If I can make it work. ;-)
22:29 * jonathan wishes the names of the typed memory allocation macros would stay in his head
22:31 jonathan chromatic: Is there a mem_allocate_n_typed that promises zeroed?
22:31 jonathan Or does that one promise that?
22:31 jonathan Oh, don't need it here...but curious anyway...
22:33 chromatic mem_allocate_n_zeroed_typed, I believe.
22:33 chromatic I usually vi -t mem_allocate_typed and read the header.
22:33 jonathan OK
22:34 Tene ^]++
22:34 Tene particle: progress on reimbursements?
22:37 bacek joined #parrot
22:37 Whiteknight joined #parrot
22:45 apeiron joined #parrot
23:02 Limbic_Region joined #parrot
23:02 * Coke restarts the tcl spec test.
23:03 Coke chromatic: just kicked off the spec test again.
23:04 Coke Tene: Oh, I'd definitely hit up the -treasurer- for that!
23:11 davidfetter joined #parrot
23:15 * Coke upgrades his iphone.
23:16 Coke chromatic: I appear to be hung on a test; wish I had finer-grained timings so I could know if this one test was slower.
23:16 Coke (my parrot is up to 1.2G...)
23:23 Hadi joined #parrot
23:23 pmichaud first attempt at refcounting caller_ctx:  FAIL
23:23 pmichaud will try again a bit later.
23:24 Hadi left #parrot
23:24 TimToady pmichaud: have you got the svnadmin stuff yet?  I just did some spec changes...
23:24 pmichaud yes, I did.  But I'll repatch.
23:24 pmichaud (I did get the svnadmin stuff)
23:25 pmichaud I'll see about moving it to pugscode late tonight or early tomorrow -- any patches you make I'll do individually once I get things moved.
23:25 pmichaud (not hard to manage, of course.  There's this little handy utility called "patch" that I use... :-)
23:25 masak are all the synopses going to the Pugs repo?
23:26 pmichaud that's the current plan.
23:26 TimToady I've heard of it...
23:26 masak TimToady: you should try it, it's quite useful :)
23:26 TimToady I hear it's obslete now that we have revision control systems though...
23:27 masak if so, then I'm using the revision control systems the wrong way.
23:28 chromatic Hm, someone should interview TimToady about writing patch.
23:28 chromatic OH WAIT
23:30 masak :)
23:31 apeiron joined #parrot
23:35 jonathan OK, I just did a dumb benchmark after getting Perl6MultiSub using the MMD cache I've hacked up.
23:35 jonathan Runs 3 times faster with the cache.
23:35 masak "3 times faster" is the kind of speed we like around here.
23:39 TimToady but does it run 3 times correcter?  :)
23:40 jonathan TimToady: In this case, only 1 times as correct. Damm.
23:41 masak better than nothing :P
23:53 tak joined #parrot
23:56 jonathan Damm. The way these MMD'd ops have been done makes it a pain to refactor it to work efficiently!
23:59 kid51 joined #parrot

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

Parrot | source cross referenced