Camelia, the Perl 6 bug

IRC log for #parrot, 2009-10-18

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:04 chromatic Hm, I think we return the wrong values from closures.
00:05 chromatic I'm certain we do.
00:05 chromatic I wonder if that's a tailcall problem again.
00:07 chromatic Somehow I doubt it.
00:09 bacek chromatic: we don't pass params properly in Continutaion.invoke.
00:11 chromatic Is that the source of t/op/lexicals.t #28 failing?
00:12 bacek chromatic: yes.
00:12 chromatic I'll stop debugging then.
00:13 bacek why?
00:15 chromatic If we already know the source of the error, it's not where I've been looking for it.
00:17 patspam joined #parrot
00:20 bacek ah, ok
00:27 bacek actually, looks like Continuation.invoke got wrong call_obj from to_ctx.
00:29 chromatic Should it be to_ctx or caller_ctx?
00:29 bacek hm... I'm not quite sure.
00:30 bacek May be to_ctx->caller_ctx
00:31 bacek nope, doesn't work
00:33 bacek chromatic: if you uncomment debug prints in lexicals_28.pir; add debug print into new_fail just before calling continuation you will see what happening
00:33 chromatic I printed the value of y.  That showed me enough.
00:34 bacek "Chosen 1 from arr2"?
00:34 bacek but "new_fail" actually choose proper value.
00:34 dalek parrot: r41914 | chromatic++ | branches/pcc_reapply/src/pmc (2 files):
00:34 dalek parrot: [PMC] Removed current_results attribute from Continuation and RetContinuation,
00:34 dalek parrot: as it's unused now.
00:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41914/
00:41 Whiteknight joined #parrot
00:44 Whiteknight hello #parrot
00:44 chromatic bacek, on trunk it shows the correct value of y there.
00:44 bacek chromatic: indeed.
00:47 chromatic I wonder about that Parrot_pcc_get_pmc_constant call in Continuation.invoke
00:49 bacek chromatic: it's correct.
00:49 bacek it used only when you set_addr for Continuation
00:49 Whiteknight what did I miss today, anything good?
00:50 chromatic We're down to 7 failures in the branch.
00:50 Whiteknight awesome
00:51 Whiteknight the only coretest failure I didn't know how to fix was t/op/lexicals.t
00:51 Whiteknight the rest I think I have a handle on (barring tuits)
00:53 bacek chromatic: looks like I found problem.
00:54 bacek Continuation store only Context*, during execution Context.current_signature got overwriten by subsequent calls
00:54 bacek When we call Continuation.invoke it use wrong signature.
00:55 Whiteknight oh awesome, only one threads.t failure left
00:55 bacek Whiteknight: yeah, I fixed couple of then few hours ago :)
00:55 Whiteknight awesome. I'm looking through the commit logs now
00:57 Whiteknight r41912 is much simpler than what I was planning!
00:58 bacek Whiteknight: I'm too lazy to implement complex things
00:59 bacek YAY!!!!!!!!!!
00:59 bacek I fixed lexicals 28!!!
01:00 cotto so basically it's pony time minus a smop
01:01 cotto (and hll testing, but we don't really care about those)
01:01 Whiteknight no way! How did you fix it?
01:02 bacek r41915
01:02 bacek Store original CallSignature in Continuation. Claim last test in
01:02 bacek lexicals.t
01:03 Whiteknight fantastic
01:04 dalek parrot: r41915 | bacek++ | branches/pcc_reapply/src/pmc/continuation.pmc:
01:04 dalek parrot: Store original CallSignature in Continuation. Claim last test in
01:04 dalek parrot: lexicals.t
01:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41915/
01:06 bacek ho-ho-ho. Only one fail in threads and library/coroutine failing epically.
01:06 Whiteknight the threads test failure is a doozie
01:07 Whiteknight it's got a lot of sub-subtests
01:07 * Whiteknight really wishes some of these things could be rewritten in PIR soon
01:10 Whiteknight threads_13.pir is seriously like it's own separate test file
01:10 Whiteknight we should really just separate it
01:22 cotto threads2.t ?
01:28 chromatic +1 here
01:29 jsut_ joined #parrot
01:33 cotto yuck.  It'd be much better to have one pure-pir file.
01:35 cotto what about threads_perl.t and threads.t, the latter being pure pir?
01:36 cotto (making migration potentially less painful)
01:38 Whiteknight the current form of the test just makes debugging a little more difficult. However we go about fixing that is fine
01:42 bacek ok, Whiteknight threads_13 is final bug in branch
01:43 dalek parrot: r41916 | bacek++ | branches/pcc_reapply (2 files):
01:43 dalek parrot: Expose parse_singature_string. It will be required for fixing Continuation.invoke
01:43 bacek I fixed last bit in Continuation.invoke
01:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41916/
01:43 dalek parrot: r41917 | bacek++ | branches/pcc_reapply/src/pmc/continuation.pmc:
01:43 dalek parrot: Don't use stored arg_flags in Continuation.invoke. :flat args apparently are flatten, but arg_flags are not updated.
01:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41917/
01:44 bacek msg allison Please review r41916 & r41917. I would like to store proper arg_flags in CallSignature but not sure that it will not break other stuff.
01:44 purl Message for allison stored.
01:45 bacek Bah!
01:45 bacek I broke something badly.
01:45 Whiteknight humbug!
01:45 TiMBuS|Away joined #parrot
01:49 Whiteknight urg, lots of failures now
01:50 bacek fixed,
01:51 bacek I rerun make test to ensure that is't really fixed
01:51 bacek ETA: 2 minutes
01:57 Whiteknight ok
01:58 bacek done
01:59 dalek parrot: r41918 | bacek++ | branches/pcc_reapply/src (2 files):
01:59 dalek parrot: Fix previous commit. There is possible situations when no signature strings created.
01:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41918/
02:02 bacek http://smolder.plusthree.com/app/pu​blic_projects/report_details/29144
02:02 shorten bacek's url is at http://xrl.us/bfsvw6
02:02 bacek that's it. One test failure in branch.
02:02 Whiteknight confirmed.
02:02 Whiteknight and now I'm off to bed
02:02 Whiteknight later
02:03 bacek Whiteknight: come back! You have to fix last failure in threads!!!
02:03 Whiteknight if it's still here tomorrow morning, I will kill it
02:03 Whiteknight kill it dead
02:04 bacek It's tomorrow afternoon already!
02:05 Whiteknight then...the morning after tomorrow
02:05 * Whiteknight is very confused now, but apparently needs to travel time
02:05 cotto first sleep, then time travel
02:05 Whiteknight yes, I need my energy
02:05 Whiteknight goodnight
02:06 bacek goodnight
02:06 bacek Time for shopping/rl.
02:06 bacek see you!
02:06 TiMBuS|Away joined #parrot
02:16 On joined #parrot
02:16 On haaaaaaptchi
02:16 * On has a parrot flu
02:16 * On needs help
02:21 cotto Hmm.  Can that be transmitted over irc?
02:22 * cotto puts on gloves and a mask, just in case.
02:39 Austin joined #parrot
02:41 Austin Okay, WTF is Piper, and why do I need to get attacked by it when I show up in #parrot?
02:42 janus joined #parrot
02:44 cotto Feel free to ignore it.  I'm sure the fact that this channel is logged isn't surprising to you.
02:44 Austin Not surprising at all. The flurry of beeping when I joined was what surprised me. I didn't need any of that.
02:46 Austin cotto: How's your makefile mojo?
02:48 cotto Austin, moderate
02:50 Austin I need a trick. I have a script (perl) that can update some of my source files. I want to only do the update when there is something worth doing. So I can dump the list of classes (the tool dumps this) into a text file, and diff the "new" and "old" text files, but I need a make structure that won't force a rebuild each time.
02:50 Austin Hmm. Let's try to clarify that.
02:51 Austin The tool can dump in --list mode a list of class names. So I can do "class_hierarchy.pl --list > list-file.new" and then do a diff of list-file.new against list-file.old to see if anything has changed.
02:52 Austin I want to make some source files depend on this change, so I can run the tool against the source files. I only want the update to occur if the diff detects any changes.
02:52 Austin So I can't just have source files depending on a file with an empty dependency list - it either always builds or never does.
02:53 Austin Any ideas?
02:53 cotto I like the efficiency.
02:56 Austin Sadly, gnu make tries to be smart, so it "knows" that if a rule gets run, the dependent file was updated, and so everything on top of that file has to be rebuilt.
02:56 cotto Do you only want to rebuild some of the classes when the diff changes?
02:56 Austin I only want to update some of the class files. But then I need to recompile them, of course.
02:57 Austin Two files, in fact.
02:57 cotto Is your code in svn?
02:58 Austin Yeah
02:59 cotto I need to go soon, but that's an interesting problem.
03:00 Austin :)
03:01 cotto Make kinda breaks down when you want to do smart stuff with it.
03:01 Austin So my problem is: how to make a file depend on (x), but in such a way that I can run an x-rule and *not* cause the file to rebuild.
03:01 Austin Yeah.
03:01 Austin I'm thinking the answer might be "put the smarts in the perl script"
03:01 Austin Which I don't really want to do.
03:01 cotto just switch to rake
03:01 Austin :)
03:01 * cotto runs
03:02 Austin I know. I'll do it all in Ant.
03:02 dalek close: r182 | Austin++ | trunk/ (13 files):
03:02 dalek close: Added makefile changes for class_hierarchy.pl. They don't work quite right, yet.
03:02 dalek close: review: http://code.google.com/p/close/source/detail?r=182
03:02 Austin Then I won't feel so bad about having to add smarts to the perl script.
03:04 Austin I think I could do it with a :: rule, but that's not portable.
03:05 cotto I'll keep thinking, but I'm out.
03:05 plobsing marker file?
03:05 Austin bye
03:05 Austin plobsing?
03:05 purl rumour has it plobsing is trying to create a set of classes which have attributes with a 'label' attribute which can be mapped to and from the attribute name
03:06 plobsing here's my dumb solution
03:06 plobsing use a marker file with one value in it: 1 for remake, 0 for not
03:06 plobsing then use an if in a rule
03:06 plobsing crude but effective
03:06 Austin I don't see it.
03:07 Austin I get the if part, but if I'm in the rule, I'm already hosed, because gnu make now "knows" that I did a rebuild, and so it has to update everything that depends on this, etc.
03:07 plobsing oh right. nevermind then. I never much liked make.
03:08 Austin I always like it fine, right up to the point where I start to hate it.
03:32 mikehh pcc_reapply branch - make smoke #29146 at r41918 - 10,764 ok, 1 failed, 262 todo, 560 skipped and 0 unexpectedly succeeded
03:52 TiMBuS|Away joined #parrot
04:21 dalek parrot: r41919 | mikehh++ | branches/pcc_reapply/src/call/args.c:
04:21 dalek parrot: codetest failures - unused assert macro and missing function docs
04:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41919/
04:28 jsut joined #parrot
04:49 dalek nqp-rx: cafd369 | pmichaud++ | src/stage0/P6 (2 files):
04:49 dalek nqp-rx: Update stage-0 compilers.
04:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​afd369421da79127003c930519432548303ff54
04:49 dalek nqp-rx: 239e497 | pmichaud++ | build/PARROT_REVISION:
04:49 shorten dalek's url is at http://xrl.us/bfswcw
04:49 dalek nqp-rx: Bump PARROT_REVISION to get better subids.
04:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/2​39e497a0409682d0f26fe3aeb03675cef610601
04:49 shorten dalek's url is at http://xrl.us/bfswcy
04:49 dalek nqp-rx: 4dabcc0 | pmichaud++ | build/Makefile.in:
04:49 dalek nqp-rx: Add exe targets to Makefile.
04:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/4​dabcc0ac2cc36868ca941c4fcc374919d0bf7c0
04:49 shorten dalek's url is at http://xrl.us/bfswc2
04:49 dalek nqp-rx: 180f18e | pmichaud++ | src/Regex/P6Regex/Grammar.pm:
04:49 dalek nqp-rx: Regexes no longer need explicit action tokens at the end.
04:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/1​80f18e2e61ee0458d160450c9dc579fe0539d19
04:49 shorten dalek's url is at http://xrl.us/bfswc4
04:49 dalek nqp-rx: 73205a0 | pmichaud++ | src/Regex/P6Grammar/Grammar.pm:
04:49 dalek nqp-rx: Regexes no longer need explicit action markers at the end.
04:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/7​3205a09175ac736469bea563d93cec9576af710
04:49 shorten dalek's url is at http://xrl.us/bfswc6
05:27 rdice joined #parrot
05:30 mberends joined #parrot
05:40 dalek nqp-rx: 5699969 | pmichaud++ | build/Makefile.in:
05:40 dalek nqp-rx: Clean up Makefile a bit.
05:40 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/5​6999692a8bb054a8458dda744604f55ba1b0902
05:40 dalek nqp-rx: af458ca | pmichaud++ | src/Regex/P6Grammar/ (2 files):
05:40 dalek nqp-rx: Add parsing of proto regex statements to P6Grammar.
05:40 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​f458cad5dc74d4ba87248150e670899f39367a1
05:40 dalek nqp-rx: 9b7739d | pmichaud++ | src/Regex/P6Grammar/Actions.pm:
05:40 dalek nqp-rx: Oops, protoregex method should be !protoregex.
05:40 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/9​b7739dd7ed6f448df8601fcace923541b595d6f
05:40 dalek nqp-rx: 2408264 | pmichaud++ | src/ (4 files):
05:40 dalek nqp-rx: Eliminate protoregex cheats for P6Regex, place directly in grammar.
05:40 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/2​408264098d3fd58b19162ebcea5dabab8cd5c2c
05:40 shorten dalek's url is at http://xrl.us/bfswgw
05:40 shorten dalek's url is at http://xrl.us/bfswgy
05:41 shorten dalek's url is at http://xrl.us/bfswg2
05:41 shorten dalek's url is at http://xrl.us/bfswg4
05:45 mikehh ok I give up - still getting a codetest failure (t/codingstd/c_function_docs.t - src/call/args.c - 1 function(s) lacking documentation) it's there but it still fails
05:45 ZeroForce joined #parrot
05:46 mikehh I tried everything I could think of and it still fails - help!
05:46 mikehh that's in pcc_reapply branch
05:48 Austin I don't suppose it tells you what function?
05:49 mikehh of course - Parrot_pcc_merge_signature_​for_tailcall(PARROT_INTERP, ARGMOD(PMC * parent), ARGMOD(PMC * tailcall))
05:49 Austin I see no paragraph there, just a signature.
05:50 Austin Put in a "fnord." and see what happens.
05:50 mikehh # Want:
05:50 mikehh # =item C<void Parrot_pcc_merge_signature_​for_tailcall(PARROT_INTERP, PMC *
05:50 rdice joined #parrot
05:50 mikehh # parent, PMC * tailcall)>
05:50 mikehh and that's there
05:51 mikehh I tried deleting and re-entering and many other things and codetest still fails
05:52 mikehh including make headerizer
05:54 mikehh make realclean etc, etc
05:54 Austin Can you nopaste the failure?
05:55 mikehh I am probably missing something straightforward - but I probably need some sleep
05:57 Austin Maybe the space between * and parent?
05:59 nopaste "mikehh" at 81.149.189.7 pasted "codetest failure in pcc_reapply branch" (33 lines) at http://nopaste.snit.ch/18366
06:00 Austin Notice the (boilerplate only) gripe - that's from no paragraph
06:01 mikehh I have fixed those before - with no problems
06:03 Austin Well, that's what it thinks, per the perl in c_function_docs.t. It may well be that the space between * and parent is also confusing it (because in the documentation, there's a newline there - I don't remember if p5 matches \s with newlines in /sm mode.)
06:03 mikehh I tried dropping it to the next line as in:
06:04 mikehh =item C<void Parrot_pcc_merge_signature_​for_tailcall(PARROT_INTERP,
06:05 mikehh PMC * parent, PMC * tailcall)>
06:05 Austin Okay, so it generates the documentation signature somehow. That's $escaped_decl
06:05 mikehh still failed
06:05 Austin And that's the =item C<...> stuff.
06:06 Austin Although that doesn't seem very escaped to me.
06:06 Austin Then it tries to match it from start to end of line?
06:07 Austin On a single line, maybe?
06:07 Austin ^\Q$escaped_decl\E$
06:07 mikehh anyway better take a break (nap or something) before I do something really stoopid
06:08 Austin I'm using my (very old) version of the c_function_docs test file, so I might be out of date wrt yours.
06:09 mikehh there is loads of other documentation in src/call/args.c that have essentially similar docs/code that pass the test
06:10 mikehh I have spent a couple of hours or more on this and have had enough - I willl look at it later after some sleep - bbl
06:12 mikehh that's if nobody else fixes it :-} - cheers
06:12 Austin okay. I'm co'ing the branch now. I'll message you if I find anything.
06:12 mikehh thanks
06:18 Austin mikehh: I added "fnord." as the paragraph body and the test passed.
06:27 Austin purl, msg mikehh I added some text as the paragraph body, and the test passed. I found some other places, like Parrot_setenv in config/gen/platform/generic/env.c, where the same =item/=cut with no paragraph fails the c_func_docs test, so this seems a likely candidate.
06:27 purl Message for mikehh stored.
06:29 Austin Thanks, purl
06:29 Austin karma purl
06:29 purl purl has karma of 8748
06:29 Austin botsnack
06:29 purl thanks Austin :)
06:29 Austin karma purl
06:29 purl purl has karma of 8748
06:30 Austin hmm.
06:40 cotto karma botsnack
06:40 purl botsnack has neutral karma
07:02 Smushers- joined #parrot
07:21 fperrad joined #parrot
07:40 allison msg bacek Did you add  r41916 & r41917 to resolve a problem with continuation calls from C args? Agreed that storing arg_flags from C calls is a better way to handle that.
07:40 purl Message for bacek stored.
07:42 chromatic Hm, the thread isn't getting the slurpy PMC to flatten in threads #13.
07:42 chromatic The FPA is empty.
07:42 allison msg bacek: ah, I see, it's about the arg_flags not being updated when flattening is done.
07:42 purl Message for bacek stored.
07:43 chromatic I think there's an off-by-one bug in dissect_aggregate_arg as well.
07:44 allison chromatic: would it make more sense to do the flattening on the param side, instead of while building the call signature?
07:44 chromatic I don't know enough to offer a good opinion there.
07:45 chromatic The more I think about it, the more I like that idea though.
07:45 chromatic It does seem like a call-side operation.
07:45 chromatic caller, I mean
07:45 chromatic not callee
07:47 allison yes, and it's a lazy optimization
07:47 allison the args passed in the flatted array/hash may never actually be used
07:48 chromatic Okay, here's another problem.
07:48 chromatic In thread_func(), the RPA containing slurpy args to the thread sub is empty.
07:48 chromatic I'm looking at t/pmc/threads_13.pir
07:49 chromatic Specifically line 133.
07:49 * allison looking
07:50 allison chromatic: that file is only 128 lines long for me
07:50 chromatic I had debug code.  Line 126.
07:51 allison chromatic: curious, it doesn't look like there should be a slurpy involved in that call
07:52 chromatic Look at the run_clone method.
07:52 allison chromatic: it's taking a constant sub argument and returning no result
07:52 chromatic ParrotInterpreter PMC.
07:53 chromatic run_clone's NCI signature has a slurpy to box-and-capture all of the arguments passed to the function.
07:53 chromatic Hm, wait... let me read that again.
07:54 allison chromatic: it's compiling its own NCI method and inserting it directly
07:55 allison chromatic: It's possible that the NCI wrapper generator isn't handling slurpys properly
07:55 chromatic Return INTVAL, take interpreter, use object, take PMC (sub), then accept slurpy arguments to the sub.
07:55 chromatic Okay, so _check in that case is the Sub PMC and there are no slurpy arguments.
07:55 chromatic That part's right then.
07:56 allison signature IJOP@
07:56 chromatic Next crazy thought: do we need to clone CallSignatures?
07:56 allison chromatic: they aren't modified after creation
07:56 chromatic Threads.
07:56 purl threads is ithreads, Thread is 5.005 threads (older)
07:56 allison but should probably be marked read-only
07:57 allison is that the only failing test left?
07:58 allison I'm impressed
07:58 chromatic That's it.
07:58 allison I like this dogpile development technique :)
07:59 jsut_ joined #parrot
07:59 einstein joined #parrot
08:01 allison chromatic: okay, so the calling code looks correct... is it possible that the argument handling code isn't creating an empty RPA when there are no more arguments to fill it?
08:01 chromatic I think the argument handling is a red herring.
08:02 allison distracting from what other problem?
08:02 chromatic If I knew that, I could fix it.
08:03 allison okay, how small can we make a test case and duplicate the problem?
08:09 allison chromatic: I get the failure on line 98, if I comment out all the other calls in full_check
08:13 chromatic Which test number?
08:13 chromatic 49?
08:13 purl 49 is nice
08:14 allison chromatic: yes 49 is the first failure, I'm trying to track down which call in the test file is test # 49
08:15 chromatic The first test called from the thread's call to full_check.
08:15 chromatic The first test run in the thread.
08:15 chromatic The check_sanity call from line 93.
08:17 allison aye, and if I comment out everything from line 97 onward,  in 'full_check' I get no failures
08:17 chromatic That's because the parent interpreter hasn't changed any global values.
08:20 allison chromatic: does that mean it hasn't been cloned yet?
08:20 chromatic No, it means those calls you commented out modify the global values.
08:20 chromatic If you skip those modifications, the values will all be '1' and everything matches.
08:21 allison chromatic: well, I commented out all the rest of the tests
08:22 chromatic Sure.
08:22 chromatic I'm saying those tests test to see if the values of variables stored in various places all match.
08:22 chromatic You commented out the code that modifies the values, thus they always match.
08:24 dalek parrot: r41920 | chromatic++ | branches/pcc_reapply/t/pmc/threads.t:
08:24 dalek parrot: [t] Fixed numbering in the problematic threads test.  This doesn't fix the
08:24 dalek parrot: test, but it makes the failure output clearer.
08:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41920/
08:26 allison chromatic: yes, but there's some element of asynchronicity here, because when I uncomment line 97, *earlier* tests fail
08:27 allison comment out line 97-112, and I get all (24) tests pass
08:28 chromatic Which earlier tests fail?
08:28 allison uncomment line 97 and the first test failure is 13
08:28 allison also 14, 18, and 19
08:28 allison 20-24 don't even run
08:29 allison maybe we do need to be cloning CallSignature
08:30 allison or, at least copying it into the context of the called sub
08:30 allison right now, the call signature that's accessed to fill params or pass returns is pulled from an element of the caller's Context
08:31 allison but, that call signature changes as soon as the next call is made
08:31 chromatic Instead of the values 1 and 2, how about we pick something weird?
08:31 chromatic 99 and 444
08:31 purl 543
08:31 allison sounds like a good debugging strategy
08:32 allison (make sure we're not getting something strange like a count of the number of arguments)
08:32 chromatic No change.
08:32 chromatic I used 111 and 222, and it's trying to match 111 and 222.
08:34 chromatic Here's a funny one.
08:34 chromatic Move the _check() call in main until after 'join'.
08:34 chromatic On trunk, it runs ok 1 .. 48 twice.
08:35 chromatic On the branch, it runs ok 1 .. 48 once.
08:35 allison chromatic: blork, definitely asynchronicity
08:36 chromatic There's the spot to start debugging, I think.
08:38 allison the question is, is it running the thread _check or the local _check?
08:39 chromatic Let's print the TID and see.
08:40 allison commenting out either the thread or local _check gives 48 passing tests
08:40 JimmyZ joined #parrot
08:41 allison Could it be a fragile test?
08:41 chromatic I doubt it.
08:41 allison That is, is it depending on certain operations taking a certain amount of time?
08:41 chromatic No, there's nothing time-based here.
08:41 allison I wonder, because which tests fail keeps changing
08:42 chromatic If I move the _check call from the parent thread until after joining the child thread....
08:42 chromatic The child thread starts, but never runs any subs.
08:42 chromatic The parent thread runs all of its subs.
08:42 allison when the local _check is after the thread _check?
08:42 chromatic And after the join.
08:43 allison how about in the original order?
08:43 joeri joined #parrot
08:43 chromatic The parent runs and finishes and then the child runs and finishes.
08:43 chromatic There's no synchronous execution here.
08:44 allison and, that's the only case where we get the test errors
08:44 allison yes, agreed, it's not two threads modifying the same values at the same time
08:45 allison okay, so in the original order, are the failures only in the child, and all 48 pass in the parent?
08:46 allison yes, 48 tests pass
08:46 allison and the first test failure is 49, which is the first test run from the thread
08:47 chromatic Yes.
08:47 allison (which explains why the test numbers kept changing as I commented  out tests)
08:47 allison (it was passing the first 5 or 10 or whatever, then failing on the first test run from the thread)
08:47 chromatic If you update to r41920 they won't.
08:49 allison chromatic: won't what?
08:49 allison (after updating)
08:50 chromatic The test numbers should be saner.
08:52 allison I'm still getting 1-48 pass, first failure is #49
08:52 allison or, you mean if I comment out some tests?
08:53 chromatic If you comment out tests, the numbers will be different.  The numbers will all be 1 - 96 regardless of any passes or fails though.
08:55 mikehh messages
08:57 allison chromatic: gotcha
09:04 chromatic I have no other brilliant ideas.
09:04 allison chromatic: [mental review] so, the local _check passes all tests. The threaded _check fails the first test that it runs
09:04 allison chromatic: but, if I only run the first 12 tests, then both local and threaded pass all 12 tests
09:05 chromatic Right, because the variable we're checking for modification never gets modified in the first 12 tests.
09:05 allison chromatic: the 13th test is the first one with a modified value
09:05 allison right
09:05 chromatic I have a lot of confidence that the problem is that the thread expects the HLL global 'foo' to contain the value 1, when it contains the value 2.
09:06 allison what is the value of 'foo' between the local and threaded calls to _check?
09:07 allison it's 2
09:07 allison how about before the call to local _check?
09:07 chromatic Undef.
09:08 chromatic It gets created in setup().
09:08 allison aye
09:09 allison somehow, that setup isn't happening on the threaded version
09:12 allison setup only modifies get_global 'foo', not get_hll_global ['Foo'], 'foo'
09:12 allison in theory they're the same
09:12 chromatic In trunk they're the same.
09:14 chromatic I wonder if the clone separates them.
09:14 chromatic The clone for the thread.
09:14 allison setting set_hll_global [ 'Foo' ], 'foo', $P0 in setup gets me passing through test #63
09:15 allison doing the same in 'mutate' gets me passing through #73
09:16 chromatic Right, but they should both refer to the *same* PMC.
09:18 allison they should, yes
09:19 allison by calling set_hll_global after set_global, I'm making sure they are the same PMC
09:19 allison (which means they weren't before)
09:19 chromatic Are they the same PMC on trunk by accident?
09:21 allison well, the setup sub is declared in the Foo namespace
09:21 allison that is, under .namespace [ 'Foo' ]
09:22 allison so, when the PIR code is parsed, the "current namespace" is Foo
09:22 allison that's why they're the same in the local _check
09:23 iblechbot joined #parrot
09:24 allison it's possible that thread cloning is breaking the association between the "current namespace" for get_global
09:24 allison or, at least between the sub object and the namespace that it was declared in
09:26 allison it would be nice to know if it was the c_* versions or the g_* versions that were failing...
09:27 chromatic Looks like both.
09:29 allison yeah
09:31 allison I haven't found a third place where the two variables could be getting out of sync
09:31 chromatic I'll add some diagnostics to help you trace this, and then I will sleep.
09:31 allison (to explain the final test failures even when I force them to be the same PMC)
09:31 allison okay
09:45 dalek parrot: r41921 | chromatic++ | trunk/t/pmc/threads.t:
09:45 dalek parrot: [t] Reclaimed TODOed threads test #14.  See RT #41373, which may be closeable
09:45 dalek parrot: now.
09:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41921/
09:45 dalek parrot: r41922 | chromatic++ | branches/pcc_reapply/t/pmc/threads.t:
09:45 dalek parrot: [t] Added more diagnostic info to failing test #13 for t/pmc/threads.t.
09:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41922/
09:46 ptc joined #parrot
09:51 allison chromatic: helpful, thanks!
10:39 edgar joined #parrot
10:45 mokurai left #parrot
10:56 bacek joined #parrot
10:59 mikehh pcc_reapply branch - make smoke#29155 at r41922 - 10,764 ok, 1 failed, 262 todo, 560 skipped and 0 unexpectedly succeeded
11:07 bacek o hai
11:07 bacek allison: ping
11:13 masak joined #parrot
11:25 namsa_ joined #parrot
11:37 Whiteknight joined #parrot
11:42 Whiteknight good morning #parrot
11:44 * bacek checking time
11:44 bacek Good evening, Whiteknight
11:47 Whiteknight which evening is it there, Saturday?
11:51 bacek Sunday
11:51 bacek Future is somewhere already
11:51 Whiteknight urg, apparently I didn't travel enough time while I was sleepting
11:53 bacek On positive note: you are in the past and can prevent your future mistakes :)
11:56 Whiteknight more likely, I have the chance to make new mistakes
11:58 bacek Just make them good, shiny and unexpected.
12:00 dalek parrot: r41923 | mikehh++ | branches/pcc_reapply/t/cod​ingstd/c_function_docs.t:
12:00 dalek parrot: attempt to make failure messages a little clearer
12:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41923/
12:01 mikehh oops messed that up a bit
12:07 dalek parrot: r41924 | mikehh++ | branches/pcc_reapply/t/cod​ingstd/c_function_docs.t:
12:07 dalek parrot: fix the last commit making failure messages a little clearer
12:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41924/
12:20 Whiteknight this last threads failure is so weird
12:22 bacek especially because it's marked with "todo" on 3 running cores in trunk...
12:22 Whiteknight the test file runs two sequences: First it runs a bunch of subtests in the main thread, then it creates a child thread to run all the tests again
12:23 dalek parrot: r41925 | mikehh++ | branches/pcc_reapply/src/call/args.c:
12:23 dalek parrot: fix codetest failure - (boilerplate only) in missing function docs
12:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41925/
12:23 Whiteknight but if I comment out the first call to _check(), the thread throws an exception and terminates
12:26 mikehh I've fixed a lot of codetest failures in the documentation of src/call/args.c but I think the documentation needs a serious review before the merge
12:27 rdice joined #parrot
12:28 bacek We've got more serious failures than threads... make benchmark_test failing in oo\d.pir
12:50 Whiteknight urg
12:59 desertm4x joined #parrot
13:00 payload joined #parrot
13:13 nopaste "mikehh" at 81.149.189.7 pasted "pcc_reapply branch - summary of results of make fulltest at r41925" (29 lines) at http://nopaste.snit.ch/18367
13:14 kid51 joined #parrot
13:17 mikehh got to go out for a bit - bbl
13:21 dalek TT #1115 created by riffraff++: show results of expressions in HLLCompiler based repls (again)
13:29 masak ok, just got src/gc/api.c:248: failed assertion 'PObj_is_PMC_TEST(obj)'
13:30 Whiteknight masak: reproducible?
13:30 masak as usual, this happens in Parrot_gc_mark_PMC_alive_fun
13:30 masak Whiteknight: hm, possibly. but there's a lot of Perl 6 code involved.
13:30 Whiteknight the only thing I am interested in is the backtrace
13:30 masak I can give you that.
13:30 Whiteknight awesome
13:31 masak http://gist.github.com/212684
13:32 masak as to the 'reproducible' part, I've now run it twice and it blows up at exactly the same point.
13:33 * jonathan is curious about all the "Parrot_is_blocked_GC_sweep" in there
13:33 masak three times. fairly reproducible, in other words.
13:35 jonathan Anyway, it's quite different from a backtrace I was seeing that led to the same assertion fail and patched. So I think this is a different bug altogether.
13:35 masak I've had some like this during the week.
13:36 Whiteknight some parts of this backtrace are completely nonsensical
13:36 jonathan Whiteknight: Heh, it's not just me thinking "wtf" then...
13:37 masak I'm not creative enough to have made it up, I assure you. :P
13:37 Whiteknight I don't think there is a function Parrot_Capture_get_isa
13:37 jonathan .oO( April fools stacktrace )
13:37 Whiteknight i've never even heard of that
13:37 Whiteknight or Parrot_CodeString_get_isa
13:37 masak Rakudo-specific?
13:38 jonathan No, it's in libparrot
13:38 masak adding a meaningless print statement helped, it seems.
13:38 Whiteknight actually, i did find it. Weird
13:39 Whiteknight But Parrot_CodeString_get_isa definitely doesn't call any of the marking functions
13:39 jonathan Whiteknight: Well, we only end up in them through pmc_new
13:39 namsa_ joined #parrot
13:40 jonathan Why does Parrot_is_blocked_GC_sweep appear to have called itself recursively? Is that strange, or normal?
13:41 Whiteknight this is impossible. Half of these functions in this "backtrace" don't call the next function in the list
13:41 Whiteknight so I don't know where the hell this is coming from, but it's not accurate
13:42 jonathan It looks very, very odd.
13:43 Whiteknight Parrot_is_blocked_GC_sweep definitely doesn't call itself
13:43 Whiteknight much less call itself repeatedly
13:43 masak so, basically, you're saying I'm doing things to Rakudo so weird that they're causing Parrot to go insane?
13:44 masak for some reason, I like the thought of that. :)
13:46 Whiteknight something is definitely getting wildly corrupted
13:47 * masak adds 'wild corruptor' to his job description
13:47 Whiteknight nice
13:47 * Whiteknight has to leave for a bit. Later
14:04 dalek TT #1116 created by jkeenan++: documentation patches for ch04 and ch05 of PIR book
14:06 Psyche^ joined #parrot
14:23 dalek parrot: r41926 | jkeenan++ | trunk/t/steps/auto/frames-01.t:
14:23 dalek parrot: Add tests for previously untested branch.
14:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41926/
14:26 dalek TT #1117 created by rblasch++: PIR Book Typos
14:27 dalek parrot: r41927 | jkeenan++ | branches/auto_libjit/t/steps/auto/frames-01.t:
14:27 dalek parrot: Add tests for previously untested branch.
14:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41927/
14:43 dalek parrot: r41928 | jkeenan++ | trunk/docs/book/pir/ch06_subroutines.pod:
14:43 dalek parrot: Correcting spelling errors as suggested by rblasch++ in https://trac.parrot.org/parrot/ticket/1117.
14:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41928/
14:46 dalek parrot: r41929 | jkeenan++ | trunk/docs/book/pir/ch05_control_structures.pod:
14:46 dalek parrot: Correcting Pod formatting error as suggested by rblasch++ in https://trac.parrot.org/parrot/ticket/1117.
14:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41929/
14:53 payload joined #parrot
14:59 dalek parrot: r41930 | jkeenan++ | branches/auto_libjit/config/auto/libjit.pm:
14:59 dalek parrot: We're not doing anything with  inside _evaluate_cc_run(), so we don't need to pass it as an argument.
14:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41930/
15:14 desertm4x joined #parrot
15:33 s1n left #parrot
15:34 jan joined #parrot
15:38 dalek parrot: r41931 | jkeenan++ | branches/auto_libjit (4 files):
15:38 dalek parrot: Have SVN ignore src/frame_builder_libjit.c and src/frame_builder_libjit.h.
15:38 dalek parrot: Delete one unused variable.  Add tests for auto::libjit.
15:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41931/
15:39 kid51 Linux/i386:  make fulltest passes all tests at r 41925 ... but I think we've been papering over some failures with TODOs
15:42 mikehh kid51: even more so with skips
15:44 mikehh but yes - see my comment in TT #1102
15:52 jan joined #parrot
16:00 Whiteknight threads_13.t is horrible and evil
16:10 Whiteknight this test seems like it's supposed to fail
16:11 Whiteknight it's known to be broken with several cores
16:13 Whiteknight it looks like namespace "Foo" is not being shared between the two threads, and attempts to modify things in the namespace from the thread aren't working
16:14 mikehh I think all cores - it's TODOed in the cgoto and switch cores (and still failes - not ok)
16:16 mikehh allison and chromatic were looking at it earlier
16:17 Whiteknight yeah, I've been staring at it for a while too
16:17 mikehh me too
16:17 Whiteknight it really just seems that the namespace PMC was copied, not shared, and values are't matching up
16:17 Whiteknight the test runs the same sequence, first in the main thread and then in a child thread. If you comment out the first call to _check(), the thread throws an unhandled exception and terminates early
16:18 mikehh the shared space is remaining at 1 when it should be 2
16:18 Whiteknight exactly
16:18 Whiteknight and that all says to me that there is some kind of lazy initialization that happens when we execute the code in the main thread that is not being copied over when we create the child thread
16:20 mikehh last I looked the other failing tests (benchmakk_tests) all fail with set_attr_str() not implemented in class 'NameSpace'
16:20 rdice joined #parrot
16:21 mikehh benchmark
16:21 purl It seems faster
16:22 Whiteknight hmm... that's weird
16:22 Whiteknight I didn't think any changes were made to NameSpace in the branch
16:22 Whiteknight or, none that would be so substantial
16:24 Whiteknight yeah, no changes to it in branch
16:25 Whiteknight and no changes to Hash PMC, which NameSpace inherits from
16:28 dukeleto 'ello
16:29 dukeleto i can verify that threads.t test #13 is the last failing test on pcc_reapply on darwin/x86 (OS X 10.5)
16:29 Whiteknight awesome
16:29 dukeleto lucky 13
16:32 Whiteknight tell me about it
16:32 purl i guess it is _impossible_ to remove the host: header in LWP.  It's fucking hard coded. or worth noting that CPANPLUS will ask after failed tests if you want to just ignore the failure
16:32 Whiteknight ad this test is shittastic too
16:40 AndyA joined #parrot
16:44 nopaste "mikehh" at 81.149.189.7 pasted "pcc_reapply branch - benchmark_tests failure(s)" (21 lines) at http://nopaste.snit.ch/18368
16:53 dalek parrot: r41932 | jkeenan++ | branches/auto_libjit/config/auto/libjit.pm:
16:53 dalek parrot: Add a cc_clean to cleanup files created during probe.
16:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41932/
16:53 mikehh got to close down for the moment - bbiab
16:55 mberends joined #parrot
17:01 mikehh joined #parrot
17:02 chromatic joined #parrot
17:09 ash_ joined #parrot
17:20 Whiteknight chromatic: any ideas on threads_13.pir?
17:31 dalek parrot: r41933 | jkeenan++ | branches/auto_libjit (2 files):
17:31 dalek parrot: Refactor some code into _handle_has_libjit() and write tests for it.  Reduce the number of points at which runstep() returns to facilitate good test coverage.
17:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41933/
17:34 chromatic No good ideas.
17:36 chromatic All I can see is that cloning somehow breaks the association of the current namespace and the HLL namespace.
17:37 Psyche^ joined #parrot
17:37 chromatic I'm sure the appropriate check within the get_global and get_hll_global namespaces (or their backing functions) would confirm that.
17:38 allison chromatic: I'm working through debug prints in namespace and sub
17:39 allison bacek: you were looking for me?
17:39 chromatic If that's the case, than any changes in cloning (Sub?) will reveal something.
17:39 chromatic But I need to make a phone call.
17:39 allison I can verify that the sub stored in the thread is a different (cloned) object from the one stored in the parent
17:40 allison for some strange reason, the "foo" variable is set one additional time beyond what's in the tests
17:41 allison so, it's set 4 times (to a new PMC object with a different pointer address) in each test run, so 8 times overall
17:41 allison but then it's set one additional time after the second test run
17:41 allison working on peeking into the attributes of the sub now
17:52 payload joined #parrot
17:59 kid51 allison / whiteknight:  Can you take a glance at TT 1116 and 1117, both of which propose patches to docs/book/pir?  Thanks.
18:20 desertm4x_ joined #parrot
18:22 ash_ joined #parrot
18:25 davidfetter joined #parrot
18:29 allison joined #parrot
18:32 allison kid51: your fixes look good
18:33 allison kid51: (whiteknighte may have already answered for TT 1116 and 1117, my client dropped off for a bit)
18:33 allison kid51: the "support logical" should be deleted, rather than a comma added (it was a stray leftover from editing)
18:34 Psyche^ joined #parrot
18:34 allison kid51: I'll leave notes in the relevant tickets
18:41 kid51 PIR book page 15 (docs/book/pir/ch04_variables.pod):  discusses pow gcd and lcm opcodes -- but provides no examples of any of them
18:42 kid51 From poking around in tests, I have example of 'lcm'.  By analogy, I can write 'gcd'.
18:42 kid51 But I find no examples of 'pow' involving integers.
18:42 kid51 What is the syntax for 'pow' opcode.
18:42 kid51 ?
18:50 allison kid51: $N0 = $N1, $N2 is a = b^c
18:50 allison ($N1 is raised to the power of $N2 and the result stored in $N0)
18:51 allison kid51: but oddly, there is no I = pow I, I version of the op
18:51 allison (sorry, should have typed $N0 = pow $N1, $N2 above)
18:51 kid51 Then the book/docs is misleading here.
18:52 allison there should be an integer version, but there isn't
18:52 allison there is a PMC version
18:52 kid51 Should we add an integer version of 'pow'?  For consistency?
18:54 allison kid51: yes, but check if 'pow' is one of the ones being moved to a dynoplib
18:54 allison kid51: (if so, we can go ahead and add the new one as a dynop)
18:55 allison msg chromatic okay, the extra set op for 'foo' in the thread is before the tests, presumably it's the clone operation
18:55 purl Message for chromatic stored.
18:56 payload joined #parrot
19:06 szabgab joined #parrot
19:08 dukeleto msg kid51 i can help in adding dynops if you need
19:08 purl Message for kid51 stored.
19:09 kid51 dukeleto:  That would be helpful.  I don' know nuttin' about dynops.
19:09 dalek parrot: r41934 | jkeenan++ | trunk/t/op/arithmetics.t:
19:09 dalek parrot: Add 4 tests for 'gcd' for integers.  But how should we handle case where one argument is 0?
19:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41934/
19:09 kid51 I'm working my way through the PIR book and trying to learn PIR that way.
19:10 kid51 So anything I can't understand means noobs can't understand either.
19:11 allison msg chromatic the freaky thing is, printing out the pointers for accesses to the value of 'foo' through the 'get_global' op. Parent and thread each fetch 'foo' 12 times after each set. In parent, they're the same each time, but in thread fetches 1,2, 4, 7, 8, and 10 fetch one PMC from one namespace while fetches 3, 5, 6, 9, 11, and 12 fetch a different PMC from a different namespace.
19:11 purl Message for chromatic stored.
19:23 allison msg chromatic ooh, in the parent the namespace where 'foo' is looked up is always the same as the namespace associated with the sub. In the thread, it's the thread-copy namespace associated with the thread-copy sub half the time, and the other times it's the same as the *parent* namespace associated with the original sub in the parent
19:23 purl Message for chromatic stored.
19:23 dukeleto kid51: if the new dynops live in the same file as the others, it is pretty darn simple to add. if they are in a new file, there are some hidden levers to pull and a secret underground fortress
19:25 kid51 dukeleto:  My actual focus is a bit narrower.  I want the text in the book to be followed by working examples of what the text discusses.
19:25 allison kid51: in this case, could you use PMC examples?
19:26 kid51 Page 15 of book gives examples of '/' and '%' for Integers.
19:26 kid51 From that, I drew implication that gcd, lcm and pow would work the same way with integers -- but they don't.
19:27 kid51 From poking in tests, I now know how gcd and lcm work -- but pow apparently does not (with Integers).
19:28 pmichaud sorry to interupt: allison, I need an opinion on a change I'd like to make
19:28 allison pmichaud: yes?
19:28 pmichaud currently if I stringify a Sub PMC, it gives me back its name (good)
19:29 pmichaud if I stringify a MultiSub PMC, it gives me back the stringification of the number of candidates in the MultiSub (bad)
19:29 pmichaud this is because MultiSub isa ResizablePMCArray, and stringifying a ResizablePMCArray returns the number of elements in the array (also bad)
19:29 allison pmichaud: I imagine that it's just inheriting that behavior from the array
19:29 pmichaud I'd like to change MultiSub to stringify to its name
19:30 allison agreed on changing stringification on MultiSub
19:30 allison (call it a bug)
19:30 pmichaud okay, thanks.
19:30 allison there really isn't anything sensible for RPA to stringify to, so I'd leave it
19:30 pmichaud I don't have a good answer about what to do with stringifying RPA, but that's not an immediate goal...  right, exactly
19:30 pmichaud okay, thanks.
19:41 dalek rakudo: 827734a | pmichaud++ | src/ (3 files):
19:41 dalek rakudo: Fix bug with .push not creating copies of pushed values.  Fixes RT #69548.
19:42 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​27734a0071dfbae3ece77330bfd15cf6ef796de
19:42 dalek parrot: r41935 | jkeenan++ | trunk/docs/book/pir (2 files):
19:42 shorten dalek's url is at http://xrl.us/bfsxu4
19:42 dalek parrot: Applying patches to ch04 and ch05 submitted in https://trac.parrot.org/parrot/ticket/1116.
19:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41935/
19:43 dalek TT #1116 closed by jkeenan++: documentation patches for ch04 and ch05 of PIR book
19:46 dalek TT #1117 closed by jkeenan++: PIR Book Typos
20:02 mokurai joined #parrot
20:02 mokurai left #parrot
20:05 szabgab joined #parrot
20:15 mokurai1 joined #parrot
20:16 bacek joined #parrot
20:19 chromatic joined #parrot
20:25 chromatic Sounds like the clone *does* separate the namespaces.
20:26 pmichaud I don't know that it's related, but something that has bugged me for a long time is that Hash.clone is a deep clone
20:26 pmichaud unlike RPA clone, which is a shallow clone
20:26 chromatic That gives me a crazy idea.
20:27 pmichaud so if you cloned a namespace, you end up cloning everything in it.
20:27 pmichaud I'd prefer that Hash.clone be shallow
20:28 jonathan Me too.
20:29 jonathan I keep forgetting that and then Weird Things Happen.
20:29 chromatic If we need a Deep Clone, we have freeze/thaw.
20:29 chromatic Provided that they work.
20:29 jonathan The upshot of which is that I've written multiple times things to do shallow clones of hashes.
20:30 pmichaud same here
20:30 pmichaud and about to do it again, several times.
20:36 szabgab joined #parrot
20:48 bacek Good morning
20:52 japhb o/
20:57 japhb dukeleto, Where you the one working on the Plumage metadata for Matrixy, or was that darbelo?
20:58 cconstantine joined #parrot
20:59 AndyA joined #parrot
20:59 dalek parrot-plumage: c8ddb09 | japhb++ | :
20:59 dalek parrot-plumage: [BUILD] Makefile.in: Dependency and clean fixes
20:59 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/c8ddb09f023c5b9774571611a5b22af968e1362e
20:59 shorten dalek's url is at http://xrl.us/bfsx5e
21:32 AndyA joined #parrot
21:34 AndyA_ joined #parrot
21:55 cconstantine joined #parrot
22:01 cotto msg whiteknight From your blog: "This makes the code prettier, along with more maintainable and much prettier.".
22:01 purl Message for whiteknight stored.
22:02 jonathan but it's SO prettier!
22:15 dukeleto japhb: i think darbelo
22:17 theory joined #parrot
22:18 Austin joined #parrot
22:19 japhb dukeleto, thx
22:21 dalek parrot-plumage: b67465a | japhb++ | :
22:21 dalek parrot-plumage: [CORE] Util.nqp: Add POD docs
22:21 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/b67465a96e2f2703c675585a8f7b9169d55360e1
22:21 shorten dalek's url is at http://xrl.us/bfsyej
22:21 dalek parrot-plumage: 183e393 | japhb++ | :
22:21 dalek parrot-plumage: [CORE] Glue.pir POD: Add SYNOPSIS; add head1 DESCRIPTION, demoting other...
22:21 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/183e393a803213624910a863c1fae4020b408473
22:21 shorten dalek's url is at http://xrl.us/bfsyeo
22:22 dukeleto japhb: should we see if svn/git is installed at Configure-time or test-time ?
22:25 japhb dukeleto, we look for them when we need them (late binding, I guess).  We need to do that anyway, because we can't assume that Plumage is going to be reconfigured every time the user changes their system.
22:26 dalek parrot-plumage: d057e97 | japhb++ | :
22:26 dalek parrot-plumage: [CORE] Glue.pir: Add library load to SYNOPSIS
22:26 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/d057e97364ffee47538623b51f5f008f1cca0d80
22:26 shorten dalek's url is at http://xrl.us/bfsye6
22:35 jsut joined #parrot
22:35 dukeleto japhb: touche
22:52 Zak joined #parrot
22:53 KatrinaTheLamia joined #parrot
22:55 allison chromatic: ping
23:05 xenoterracide joined #parrot
23:15 mgrimes joined #parrot
23:15 mgrimes hi all
23:15 mgrimes is there an equiv of __END__ in pir?
23:16 Austin mgrimes: no
23:16 Austin Each sub has .end, but that's equivalent to '}'.
23:17 mgrimes darn. I'm working on converting some tests in perl to pir. __END__ would save a lot of commenting and uncommenting.
23:17 mgrimes thanks for the quick reply.
23:17 Austin What would it do?
23:18 mgrimes just stop parsing the file at __END__. same as in p5.
23:18 Austin So nothing with data afterwards, or any of that?
23:19 mgrimes nope.
23:19 NotFound hi
23:20 chromatic pong
23:21 Austin Yeah, there's no mention of it in imcc.l, which is where I assume it would be placed.
23:21 Austin It should be easy to add, if you'd like? :)
23:23 mgrimes it would be very convinient for my purposes
23:24 mgrimes I'd be happy to try to implement it, but I really wouldn't know where to start.
23:24 chromatic allison, pong.
23:25 Austin imcc.l is the file. I think the "easy" approach would be to lie, and tell the rest of the system you just saw EOF. Since there's already some EOF handling in imcc.l, I'm guessing it would be a copy/paste job.
23:26 mgrimes Ok. I'll take a look at it.
23:26 Austin mgrimes++
23:29 allison chromatic; do you want the diff of my internal debug prints before I take off to sleep for 8 hours?
23:30 jonathan mgrimes, Austin: Also I think remember to configure with iirc --maintainer otherwise the makefile won't have the lines to compile imcc.l in it.
23:30 jonathan Disclaimer: it probably is literally years since I changed that file.
23:30 Austin :)
23:30 jonathan oh, no...maybe last year...
23:31 chromatic allison, I'm unlikely to fix it tonight.  I figured out how to import LaTeX into LyX, so I'm working on that.
23:31 allison ah, excellent
23:31 allison chromatic: I'm very close to fixing it
23:31 chromatic Unless we can figure out exactly what semantics this test is supposed to test and if we want to support them, the fact that it behaves differently in trunk with different runcores makes me want to smack it.
23:31 hachi joined #parrot
23:31 patspam joined #parrot
23:32 allison chromatic: I can at least say what the problem is
23:32 chromatic Oh?
23:33 allison chromatic: some code paths on the thread are still pointing to namespace objects from the parent
23:33 allison chromatic: so, when it gets the wrong value, it's pulling it from the *parent's* namespace
23:33 chromatic Insufficient cloning?
23:33 jonathan allison: In the case where it was specified that they should have the namespaces cloned?
23:33 allison chromatic: (verified with pointer numbers)
23:34 allison jonathan/chromatic: the namespace is cloned
23:34 jonathan (I'm presuming it's an option...)
23:34 allison that's what's so weird
23:34 allison there's a clone of the namespace and a clone of the sub and a clone of the variable
23:34 jonathan allison: OK, but how was the namespace reached? I mean, if a sub's namespace pointer is looked at, and the sub wasn't cloned, for example...
23:34 jonathan allison: Yes, but was the sub's ns pointer updated?
23:35 allison yes, even that
23:35 purl hmmm... even that is goofy, nevermind
23:35 jonathan Hmm. Oddness.
23:35 patspam joined #parrot
23:35 * jonathan tries to think what else holds pointers to the NS
23:35 allison the fetches that are getting the right value are looking up in the cloned namespace (the same as the sub)
23:35 chromatic The subs don't get cloned.
23:35 allison chromatic: nope, they do
23:35 chromatic They shouldn't.
23:36 allison parent says:
23:36 allison The _check_sanity global sub is being set to 0x1011ac958,in namespace 0x1011c90b0
23:36 allison namespace_stash is 0x1011c90b0, with name parrot||Foo
23:36 allison The _check_value global sub is being set to 0x1011aca48,in namespace 0x1011c90b0
23:36 allison namespace_stash is 0x1011c90b0, with name parrot||Foo
23:36 purl i already had it that way, allison.
23:36 allison thread says:
23:36 allison The _check_sanity global sub is being set to 0x1011ac958,in namespace 0x1011c90b0
23:36 purl i already had it that way, allison.
23:36 allison namespace_stash is 0x1011c90b0, with name parrot||Foo
23:37 purl i already had it that way, allison.
23:37 allison The _check_value global sub is being set to 0x1011aca48,in namespace 0x1011c90b0
23:37 purl i already had it that way, allison.
23:37 allison namespace_stash is 0x1011c90b0, with name parrot||Foo
23:37 purl i already had it that way, allison.
23:38 allison nah, I just pasted the same one twice
23:39 jonathan worst spot the difference game ever!
23:39 allison parent is:
23:39 * jonathan was staring at that for a minute or two :-)
23:39 allison The _check_sanity global sub is being set to 0x1010aa8f0,in namespace 0x1010aa8a0
23:39 allison namespace_stash is 0x1010aa8a0, with name parrot||Foo
23:39 allison The _check_value global sub is being set to 0x1010aaaf8,in namespace 0x1010aa8a0
23:39 allison namespace_stash is 0x1010aa8a0, with name parrot||Foo
23:40 allison thread is as I posted before
23:40 allison (I was using screen scroll instead of less scroll)
23:40 jrtayloriv joined #parrot
23:41 allison so, the sub objects and namespace objects are different, but the sub name and namespace name are the same
23:41 mgrimes jonathan, thanks for the pointer... could have taken me a while to figure that one out
23:41 mgrimes a really, really long while :)
23:43 jonathan allison: It's not by any chance that the bytecode contains references into the constants table to sub PMC constants?
23:44 jonathan So ends up finding the subs that way, not via the namespace?
23:44 jonathan Or some other similar issue.
23:45 jonathan mgrimes: Heh, I hacked the makefile by hand the first time I changed the lexer/parser because I didn't know about that either. ;-)
23:51 dalek nqp-rx: 6d0e83e | pmichaud++ | src/Regex/P6Regex/Actions.pm:
23:51 dalek nqp-rx: Combined negated charclass should be zero-width.
23:51 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/6​d0e83ef7c24bb181a6983d647bc17d8a74d4ab2
23:51 dalek nqp-rx: 7b40261 | pmichaud++ |  (4 files):
23:51 dalek nqp-rx: Add initial version of NQP grammar and actions.
23:51 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/7​b402618be4a4cba638a5d85bf2d5797910e49ac
23:51 shorten dalek's url is at http://xrl.us/bfsyon
23:51 dalek nqp-rx: ca59b99 | pmichaud++ | build/Makefile.in:
23:51 dalek nqp-rx: Add nqp and nqp.pbc to "make clean".
23:51 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​a59b998fecf851287158e4fff9c53415766a1a3
23:51 shorten dalek's url is at http://xrl.us/bfsyop
23:51 dalek nqp-rx: 348a761 | pmichaud++ | src/NQP/ (2 files):
23:51 dalek nqp-rx: Add \x[...] and \o[...] quoted forms.
23:52 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/3​48a761fc25ec489762bcc8a5fc8b5b9cad0b2f2
23:52 shorten dalek's url is at http://xrl.us/bfsyor
23:52 shorten dalek's url is at http://xrl.us/bfsyot

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

Parrot | source cross referenced