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

Powered by Cro and the Raku® Programming Language.

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

Thank you!