www.parrot.org | Parrot 1.6.0 "half-pie" released: PCC branch hackathon all $localtime Saturday | Testing priorities: pcc_reapply branch
Set by moderator on 30 September 2009.
bacek allison: should PCC do auto-casting from PMC to STRING? 00:02
allison Tene: just added a comment about the multi sub failure to the wiki
bacek: yes, it should and does
bacek allison: not in branch... 00:03
t/pmc/string.........................1/171 Unable to set PMC value, the pointer is not a PMC
dalek tracwiki: v8 | allison++ | CallingConventionsOverview
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqb6f
bacek t/pmc/resizablestringarray...........1/261 Unable to set PMC value, the pointer is not a PMC
current instr.: 'method_pop_string' pc 6072 (t/pmc/resizablestringarray.t:1529)
called from Sub 'main' pc 362 (t/pmc/resizablestringarray.t:77)
allison Tene: I'm working my way through the tests to triage the failures
bacek this one
purl it has been said that this one is bugged too now
Tene allison: that information would be very nice to have on the wiki 00:04
allison bacek: the code does auto box/unbox, so these are different than the general case
kid51 r 41653 cleared up 26 tests; 652 to go! 00:08
dalek tracwiki: v9 | allison++ | CallingConventionsOverview 00:09
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff 00:10
shorten dalek's url is at xrl.us/bfqb6y
allison bacek: those failures might be in the return handling code rather than the calling code, it is more primitive
Tene Oh, I was working on return arg processing the last time I looked at PCC... I think I was trying to figure out a way to generalize the processing between the different functions to avoid code duplication. 00:11
kid51 93 tests more passing by r41658; 559 to go
smolder at r41658: smolder.plusthree.com/app/public_pr...ails/28498 00:12
shorten kid51's url is at xrl.us/bfqb64
bacek kid51: can you Configure parrot with --buildframes=0? 00:14
kurahaupo Build failure for i386 trunk r41658: ļ»æWhen making PGE/builtins_gen.pir segfaults on ../../parrot -o PGE.pbc --output-pbc PGE.pir
../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg
bacek kurahaupo: r41658 isn't trunk...
kurahaupo (That's just my output from "svn up") 00:15
bacek: shall we just say "svn HEAD as of 30 seconds ago" 00:16
bacek kurahaupo: you sure that your svn checkout is trunk, not pcc_reapply branch? 00:17
kid51 I am seeing this message in several failing test files: src/call/pcc.c:722: failed assertion '(st->dest.sig & PARROT_ARG_TYPE_MASK) == PARROT_ARG_PMC' 00:18
kurahaupo bacek: ļ»æWhen making PGE/builtins_gen.pir it dies on the second step ../../parrot -o PGE.pbc --output-pbc PGE.pir
kid51 t/pmc/nci.t; t/pmc/float.t; t/pmc/bigint.t
kurahaupo bacek: sorry, cut-and-paste error
bacek: svn info . says URL: svn.parrot.org/parrot/trunk 00:19
kid51 kurahaupo: In pcc_reapply branch, we're only currently concerned with 'make corevm' and 'make coretest'
bacek kurahaupo: strange... Last commit was in trunk 7 hours ago. And it's pretty stable... 00:20
Tene Yeah, the first PGE failure looks like a return_args issue, iirc
kid51 t/pmc/objects.t also has that 722 src/call/pcc.c error
kurahaupo AFAIK svn will report the highest revision in any branch
00:21 Wolong_ joined
kid51 t/pmc/packfileconstanttable.t also 00:21
kurahaupo Is there anything stronger than "make realclean" ? Short of deleting my entire working copy (which I'd rather not do while I have pending changes)
dalek tracwiki: v10 | allison++ | CallingConventionsOverview 00:22
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqb77
kid51 t/pmc/threads.t also 00:23
allison kid51: anytime you see a reference to 'st->' anything, it means some piece of code is still calling the old functions
kid51 kurahaupo: No, make realclean is as strong as it gets
purl okay, kid51.
Tene allison: would you rather have me work on the mmd issues, or set_returns? 00:25
kid51 allison: 'st->': Are you referring to .t files? .pmc? .c? 00:26
Another frequently observed error message in the TAP is: Unable to set PMC value, the pointer is not a PMC 00:27
kurahaupo crawls under a rock... build problem has vanished 00:31
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: '.c' files still holding 'st->'" (25 lines) at nopaste.snit.ch/18196 00:32
allison Tene: whichever you'd rather work on 00:37
Tene: I've put a full triage of all remaining failing tests up on the wiki trac.parrot.org/parrot/wiki/Callin...nsOverview 00:38
shorten allison's url is at xrl.us/bfqb9p
Whiteknight backlogs
dalek tracwiki: v11 | allison++ | CallingConventionsOverview 00:39
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqb9r
dalek tracwiki: v12 | jkeenan++ | CallingConventionsOverview
tracwiki: minor spelling correction
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqb9t
allison kid51: yikes, that's a lot of scatter. I'm hoping a lot of those are some other struct named st, and not poking directly into the old calling convention's call state struct
kid51 Let me see if I can refine the grep 00:40
Your suspicions are correct.
allison okay, bigint.c is actually "bi_dest->"
00:41 quek left, payload joined
Whiteknight a lot of action in this branch today! That's what I wanted to see! 00:41
allison kid51: src/frame_builder.c is likely an accurate hit
dalek tracwiki: v13 | jkeenan++ | CallingConventionsOverview 00:42
tracwiki: Turn text into subhead
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqb97
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: Look for 'st->' in src/call/pcc.c and src/frame_builder.c" (209 lines) at nopaste.snit.ch/18197 00:45
"bacek" at 110.175.160.228 pasted "Improve CPointer." (24 lines) at nopaste.snit.ch/18198 00:46
kid51 paste 18197 should provide better guidance re st-> 00:47
bacek allison: can you check no paste? I added auto-casting in CPointer.set_pmc. I would like to add similar casting to all set/get methods
allison bacek: that's a good place to put the casting code 00:49
bacek: though, the translation isn't as obvious for string to int/num or int/num to string
bacek: we promise auto boxing/unboxing to pmc type, but not auto translations for all types 00:50
bacek allison: why don't just cast them?
allison bacek: you can't cast a string to a number 00:51
bacek: it translates to garbage
bacek allison: I mean Parrot_str_to_num
not "plain C cast"
allison bacek: yes, that's fine 00:52
bacek Ok. I'll go ahead and then simplify fill_returns functions 00:53
allison bacek: to see exactly what the old system did (which we want to duplicate) take a look at the convert_arg_from_* static functions in src/call/pcc.c in trunk
bacek allison: ok
allison bacek: putting the boxing/unboxing inside CPointer, you should be able to simplify the logic of the two fill_returns functions, because you won't have to check the item_sig on the return signature item 00:56
bacek allison: this is exactly what I mean by "and then simplify fill_returns functions" :)
allison bacek: you can just set it based on the return_flag type and let CPointer handle the rest 00:57
bacek: aye
Tene: do you have enough bits to work on from the wiki?
Tene: it's 2am here, so I'm headed off for some sleep
dalek tracwiki: v14 | whiteknight++ | CallingConventionsOverview 00:58
tracwiki: post outlines for argument processing algorithms, for reference.
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqccu
kurahaupo g'nite allison
Tene allison: goodnight 00:59
Whiteknight in that case, we should probably rename CPointer to something like ArgPointer
allison Whiteknight: it's still appropriate, CPointer was always intended to be a "drop in" variable that transparently pretends to be whatever is needed 01:00
allison sleeps 01:01
Whiteknight thats fine then, but if it's only being used to ferry arguments around, I see no reason not to call a spade a spade 01:02
but that's neither here nor there 01:03
01:03 TiMBuS joined
jrtayloriv Whiteknight, Did you notice that Peter Lobsinger was on earlier asking about his libJIT work? 01:04
01:04 rhr joined
jrtayloriv (Just making sure that he doesn't feel completely warnocked) 01:05
he popped in for a moment saying: 16:53 <plobsing> i am interested in adding the libjit nci changes I have at github.com/plobsing/parrot-libjit 01:06
And then no-one responded.
(because everyone was very busy at the time with the hack frenzy, they just might not have noticed) 01:07
dalek rrot: r41659 | mikehh++ | branches/pcc_reapply/src/extend.c:
codetest failure - trailing spaces
 01:09
kid51 jrtayloriv: Is there any way you could paste a patch of the important stuff in his work?
rrot: r41660 | bacek++ | branches/pcc_reapply/src/pmc/cpointer.pmc:
Revamp CPointer casting to DTRT.
TiMBuS i could probably write those NCI routines in C/asm whiteknight was talking about, if nobody ended up doing that..
jrtayloriv kid51_at_dinner, , I don't have any idea how it works -- I just noticed that nobody responded when he came in, and thought that perhaps someone that does understand it should message him (i.e. ask him to make a patch) 01:11
mikehh bacek: is it going to mess you up if I remove C++ style comments from src/frame_builder.c? (done but not commited) 01:16
Tene s/remove/change to C90/ oslt right?
mikehh Tene: yes if you like 01:17
aparently MS C don't like
Tene nodnod 01:18
mikehh altho' why any reasonably modern C compiler doesn't accept C++ style comments is beyond me 01:19
I mean C99 is 10 years ago 01:20
and c90 is nearly 20 01:21
may as well use K&R
Tene srsly 01:22
bacek mikehh: "C++ comments" are markers where I cut corners.
mikehh: and VS doesn't accept C++ comments in C code... 01:23
mikehh bacek: I thought that might be the case - will leave for the moment
bacek mikehh: you can replace comments but put some other easy-to-find marker.
mikehh ok will do - how about /*++ or /*-- any preferences? 01:25
bacek "/* XXX FIXME" :) 01:27
01:27 patspam joined
dalek rrot: r41661 | bacek++ | branches/pcc_reapply/src/call/args.c:
Simplify fill_returns functions values handling. CPointer will cast values by it self.
 01:28
mikehh and again how VS doesn't accept them is really beyond my understanding - as I remarked previously C99 is not new (1999 ha we are at 2009)
ok you will get it 01:29
nopaste "kurahaupo" at 118.92.107.41 pasted "rewrite tests for resizableintegerarray as PIR, plus add new tests, plus patch to make sure zero-fill always applies to new elements" (1073 lines) at nopaste.snit.ch/18199
dalek rrot: r41662 | bacek++ | branches/pcc_reapply/src/call/args.c:
Fix handling of null CallSignature and "returns"
 01:38
rrot: r41663 | mikehh++ | branches/pcc_reapply/src/frame_builder.c:
replace C++ style comments with /* XXX FIXME ... */
 01:41
TT #1089 created by kurahaupo++: rewrite tests for resizableintegerarray as PIR, plus add new tests
01:44 kurahaupo joined
kid51_at_dinner Between 41558 and 41660 we cleaned up another 79 tests 01:45
01:45 mokurai joined
kid51 seen plobsing? 01:47
purl plobsing was last seen on #parrot 4 hours, 56 minutes and 7 seconds ago, saying: i am interested in adding the libjit nci changes I have at github.com/plobsing/parrot-libjit
kid51 msg plobsing Re libjit nci changes: Can you prepare patch and open up a Trac ticket? 01:48
purl Message for plobsing stored.
bacek kid51: how many failing tests to you have?
kid51 There were 480 in branch at r41660 -- but I am re-testing with svn up now 01:49
r41660: smolder.plusthree.com/app/public_pr...ails/28500
shorten kid51's url is at xrl.us/bfqci2
kid51 r41663: still at 480 to go 01:51
smolder.plusthree.com/app/public_pr...ails/28501 01:52
shorten kid51's url is at xrl.us/bfqcje
bacek kid51: is it with --buildframes=0? 01:53
kid51 No. 01:55
Why should I add that? (Am trying to test exactly as I do in trunk)
dalek rrot: r41664 | mikehh++ | branches/pcc_reapply/src/call/args.c:
fix svn properties
 01:57
bacek kid51: framebuilder is badly broken. It's leftover from JIT... 01:59
dalek rrot: r41665 | mikehh++ | branches/pcc_reapply/src/pmc/cpointer.pmc:
codetest failure - trailing spaces
 02:04
Tene mmd isn't working out so well for me. Working on return args instead. 02:06
kid51 bacek: You are correct. with --buildframes=0 the number of failing tests falls to 160: smolder.plusthree.com/app/public_pr...ails/28503 02:07
shorten kid51's url is at xrl.us/bfqckw
bacek kid51: of course I am. I broke it :) 02:08
hmm... I can't connect to smolder...
dalek rrot: r41666 | bacek++ | branches/pcc_reapply/src/pmc/continuation.pmc:
Comment-out old-style param passing in Continuation.
 02:10
rrot: r41667 | bacek++ | branches/pcc_reapply/src/frame_builder.c:
Remove more old param passing stuff from frame_builder.
rrot: r41668 | bacek++ | branches/pcc_reapply/src/exceptions.c:
Remove unused pass_exception_ars function
rrot: r41669 | bacek++ | branches/pcc_reapply (2 files):
Rerun headerizer
rrot: r41670 | bacek++ | branches/pcc_reapply (2 files):
Old PCC is dead-dead-dead. Remove last functions.
bacek ok. 02:13
afk # have to make lunch for kids
02:27 quek joined
mikehh make world in pcc_reapply now fails at make: *** [src/glut_callbacks.o] Error 1 - 29x - error: ā€˜Parrot_runops_fromc_args_eventā€™ was not declared in this scope 02:27
kid51 mikehh: Given that in pcc_reapply branch we are not (yet) bothering with 'make', why would you expect to get anything out of 'make world'? 02:29
mikehh codetest - 1 error remaining - 1 unused assert macros found in total.
kid51: just checking and reportin' at the moment 02:30
kid51 ok
I was trying 'make' in this branch but only getting build failures. allison explained we can't test the libraries, PCT, etc yet 02:31
So now I'm doing 'make smolder_coretest'
mikehh kid51: sure - but I check every so often to see where we are - previously we got past src/glut_callbacks.c 02:32
kid51 t/pmc/threads.t is mostly failing with SIGNAL 11: SIGSEGV 11 Core Invalid memory reference (on linux) 02:35
mikehh for example at r41643 we got as far as PGE but at r41658 we started getting the above failure in src/glut/callbacks.c
and we still get it at r41670 - those were the last 3 make world runs I did (and logged) 02:36
kid51 So, although you were trying 'make world', it failed in the 'make' stage -- correct?
mikehh sure - it gets past the corevm stage and I see how much further it goes 02:38
kid51 k. (I was focusing too much on the 'world')
mikehh as part of my normal testing I run something like -> make world 2>&1 | tee make_world.41670.g++.amd64.log 02:39
dropping the g++ if I use gcc and of course i386 if I am on that platform
kid51 is not very familiar with 'make world' 02:41
02:41 cognominal joined
mikehh it does a normal make and adds the tools build 02:41
world: 'all' and 'parrot_utils'." 02:43
-> world : all parrot_utils -> parrot_utils : $(PDUMP) $(DIS) $(PDB) $(PBCMERGE) $(PBC_TO_EXE) $(PARROT_CONFIG) 02:45
02:48 janus joined
mikehh come to think of it I haven't tested trunk recently I think we have had 1 commit there - let me check 02:55
kid51 Well, in pcc_reapply branch, I am still not getting all the way through 'make'. 02:57
nopaste "kid51" at 70.85.31.226 pasted "Excerpt from 'make' failure in pcc_reapply branch" (31 lines) at nopaste.snit.ch/18201 02:59
kid51 must sleep 03:01
purl $kid51->sleep(8 * 3600);
dalek rrot: r41671 | bacek++ | branches/pcc_reapply/config/gen/opengl.pm:
Replace runops..._event with invoke_sub in glut callbacks.
 03:03
tracwiki: v15 | bacek++ | CallingConventionsOverview 03:07
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqcqv
mikehh The following applies to trunk 03:20
All tests PASS (pre/post-config, smoke (#28505), fulltest) at r41670 - Ubuntu 9.04 amd64
03:25 plobsing_ joined 03:31 plobsing joined
mikehh partcl r775 builds on parrot r41670 - make test PASS (smolder #28506) - ubuntu 9.04 amd64 03:32
rakudo (e976f23) builds on parrot r41670 - make test PASS / make spectest_smolder (up to r28584 -> #28507) FAIL - Ubuntu 9.04 amd64 03:43
rakudo - t/spec/S11-modules/nested.t - Parse errors: Bad plan. You planned 6 tests but ran 5
rakudo - t/spec/S32-num/rat.t - Parse errors: No plan found in TAP output
ok - one last run on the pcc_reapply branch 03:50
in pcc_reapply branch make gets past the previous src/glut_callbacks.c failure and now fails at make[1]: *** [PGE.pbc] Error 1 again 03:58
codetest ->
# unused assert macros found: 03:59
# /home/mhh/pcc_reapply/src/call/ops.c: runops_args
# 1 unused assert macros found in total.
passes the rest of codetest
mikehh seriously needs a nap or something 04:00
bbl
04:40 cconstantine joined
dalek rrot: r41672 | bacek++ | branches/pcc_reapply/src/call/args.c:
Generalise Parrot_pcc_fill_params functions:

   va_list
  - Create generic fill_params function.
  - Switch _from_op and _from_c_args functions to use generic one.		 04:47
bacek msg allison Please review r41672. I'm going to change other functions in the same way to reduce code size. 04:48
purl Message for allison stored.
05:20 kurahaupo joined 05:34 szabgab joined
japhb Tene: pushed another set of Plumage commits. I just left a stub of merge_tree_structures() there, and wrote the surrounding code that needs it. If you beat me to it, great, otherwise I'll hack it in myself in a day or two. 05:37
Tene japhb: great 06:15
06:29 bacek joined
Tene purl: msg bacek That's exactly what I planned to do with fill_params. Nice to see you got to it first. I'll build on that to get fill_returns using the same strategy. :) 06:34
purl Message for bacek stored.
06:46 Zak joined 07:02 allison joined
dalek TT #1090 created by kurahaupo++: Convert t/pmc/exporter.t to PIR 07:08
Tene allison: Hi. :)
allison: Check out the latest commit to pcc_reapply, by bacek. It's pretty good work. I'm just starting to look at doing the same thing to fill_returns. 07:09
Looks like it has some problems... causes a failure in t/oo/composition.t 07:19
allison Tene: hi 07:22
dukeleto hola
purl salut, dukeleto.
allison looking
dukeleto what can I do to help the pcc_reapply effort ? 07:23
allison dukeleto: failing tests are grouped by cause of failure on trac.parrot.org/parrot/wiki/Callin...nsOverview 07:24
shorten allison's url is at xrl.us/bfqb9p
allison dukeleto: looks like we've picked off the really obvious ones 07:25
Tene dukeleto: there are a couple of easy fixes... some error messages have updated and there are tests which check for that literal text... the tests need to be updated to match the new error text. 07:28
iirc 07:29
dukeleto ok, i will check out the tests 07:30
Tene There are a couple of things wrong with bacek's new fill_params... I can see a few tests failing in ways that they shouldn't. i can't quite tell why, though. 07:31
allison Tene: was trying to avoid function pointers, but we'll see if this makes it more maintainable 07:33
Tene allison: if I can figure out where this bug is, I should be able to get that same function used for fill_returns too.
allison Tene: will dig in and see if I can track down the failures
Tene and that should help a lot.
I'm seeing it demonstrated in t/oo/composition.t 07:34
allison yes
though, you'll have to use a different set of function pointers
nopaste "tene" at 24.10.252.130 pasted "minimal pir to reproduce problem for allison++" (10 lines) at nopaste.snit.ch/18202 07:38
dukeleto hmmm, miniparrot does not compile for me 07:42
Tene dukeleto: what failure?
purl failure is probably not an option
nopaste "dukeleto" at 69.64.235.54 pasted "miniparrot compile error" (7 lines) at nopaste.snit.ch/18203 07:43
dukeleto why does the miniparrot compilation have an -lparrot flag? 07:44
allison Tene: what failure are you getting?
Tene named parameters must follow all positional parameters
allison I was just going to paste that :) 07:45
ok
so, it's a logic problem, not a mysterious segfault, that's nice :)
Tene allison: specifically, it's the *second* named params must follow..., on line 848
Yeah, it shouldn't be too bad, I'm just... not all here right now. 07:47
Long weird day.
allison: looks like param_name is empty. 07:54
oh, nevermind.
That was a lie.
It happens when processing the second named optional. The first named optional goes through fine.
allison Tene: makes sense, I'm soaking in the new code at the moment 07:55
Tene Ah, okay, here we go. 07:56
When processing the second named optional that isn't present, it tries to fall back to positional.
07:56 kjeldahl joined
Tene So it just falls out of the 'else if' block that runs 807-843 and straight into the 'named must follow all positional' check. 07:57
allison Tene: it doesn't check when there are no more parameters 07:59
Tene: that is, it works just fine if you pass a 'doom' argument 08:00
Tene allison: that's right. it only fails when there's no argument to the named. 08:01
Ah, I know... 08:02
nopaste "tene" at 24.10.252.130 pasted "fixes the problem for allison++" (22 lines) at nopaste.snit.ch/18204 08:03
Tene lemme run a coretest, just to check...
dalek rrot: r41673 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Clean up some names in the new function pointers to make the code easier
 08:04
Tene Much nicer. :) 08:05
dalek rrot: r41674 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] Fix small logic bug in fill_params
 08:07
Tene allison: curious about why you wanted to avoid function pointers. 08:09
allison Tene: because they're a bear to maintain 08:11
Tene Huh, okay. I've never done much work with function pointers in C.
allison Tene: with that revised logic, it will only check for positional parameters in the middle of named parameters if param_name is not set
have you tested that it still catches an actual positional argument in the middle of named arguments? 08:12
Tene allison: allison that's already tested, and I've tested myself. param_name is set iff we're trying to fetch a named parameter. 08:13
so, yes, it works properly. Thank you for confirming, though. 08:14
allison Tene: Parrot traditionally used function pointers extensively, and it produced some of the nastiest and most difficult to debug code we've ever ripped out
Tene Ah. That's unfortunate.
Parrot is the only C codebase I've done any amount of work with.
I did some C back in school in like 2000 or so, and then not much until I came to Parrot. 08:15
allison Tene: but, that does leave me unfairly prejudiced 08:16
Tene: function pointers used with a limited and clear scope can be beneficial 08:17
dalek rrot: r41675 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] More naming cleanup for maintenance sanity.
Tene It would be *great* if we can get a single sane code path for params and returns filling. I'll trust your judgement on whatever I come up with, though. 08:19
allison Tene: eventually they'll be the same codepath 08:20
Tene: but at the moment, they're two different paths
Tene: because unfortunately, at some point someone reversed the order of the opcode calls
so, you call set_args then get_params 08:21
Tene ah
allison but on returns you call get_results then set_returns
instead of set_returns and then get_results 08:22
dukeleto oy vey
allison so, the logic is backwards
you're fetching before you've set
Tene Well, let me go see if it's possible to get set_returns using fill_params with a different set of function pointers, or if it would need changes to fill_params. 08:23
allison and have to do all these nutty games with CPointers
Tene when is it we're planning on changing that?
allison Tene: it looks like the function pointers are only accessing the register or vararg values, so you should be able to use them 08:24
dalek rrot: r41676 | dukeleto++ | trunk/t/pmc (2 files):
[t] Convert some exception tests to PIR
08:24 iblechbot joined
allison Tene: it changes interface, so needs a deprecation cycle 08:24
Tene allison: right... I was asking which deprecation cycle it's scheduled to happen in. After 2.0? 08:25
allison Tene: yes, as soon as possible
Tene: we might be able to use the function pointers in build_sig_object too 08:26
08:29 quek joined
dukeleto it seems that miniparrot requires an installed parrot on the pcc_reapply branch. how can I fix that? 08:30
are we creating TT's for pcc_reapply bugs?
allison dukeleto: no, they're in a branch 08:33
dukeleto: just add any reports to the wiki page
dukeleto allison: gotcha
allison Tene: ooh, here's the deeper problem, src/call/args.c:842 08:34
Tene allison: that's a problem?
allison Tene: when it doesn't find the coresponding named argument for the named parameter, it just drops through to positional handling
Tene: that's wrong
purl allison is channeling thoth!
Tene allison: it's not supposed to do that? 08:35
allison: I thought that "named arguments will fetch from extra positionals" was explicitly supposed to be part of how the calling conventions worked. 08:36
allison Named parameters can take positional arguments as a default
Tene "as a default"?
allison but only if no other named arguments have been used
Tene Ah... I never knew that part. 08:37
allison :named first checks for a named argument, and if it doesn't find one, tries to fill with a positional argument
Tene But if it's already filled one named param with a named arg, it should fail instead?
allison yes 08:38
going back to check the PDD to make sure we get the logic straight
dalek tracwiki: v16 | dukeleto++ | CallingConventionsOverview
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqddj
Tene if (named_count == 0) { param_name = NULL; continue; } else { Parrot_ex_throw_from_c_args(...) }
is what you want in that case. 08:39
Wait, hmm, no...
You also need to look at whether the named param was optional or not. 08:40
if it's not optional, die with the right message
Well, I'll wait for judgement from the PDD 08:41
allison Tene: the PDD is non-specific, will have to check current behavior and duplicate that
Tene dukeleto: does the miniparrot compile if you just copy/paste the command it's trying, but omit -lparrot ?
allison dukeleto: and does it compile if you run realclean and re-run Configure.pl?
Tene allison: if you determine it, please add a test for it.
allison Tene: Named targets can be filled with either positional or named values. 08:43
However, if a named target was already filled by a positional value, and
then a named value is also given, this is an overflow error.
Tene: (quote from the PDD)
Tene: so this says "try to fill it with a positional first, then try to fill it with a named" 08:44
Tene That sounds a little sketchy to me, but maybe I'm biased by reading the current impl. 08:45
allison Tene: while :lookahead would be "try to fill it with a named first, then try to fill it with a positional"
Tene: yes, it would require using the logic Whiteknight and I drafted last night instead of the current logic
Tene Ah, I missed that.
Oh, no, I saw it on the wiki. 08:46
allison: fill_params and fill_returns should have different error messages, too. 08:47
allison: advice on how you'd like that handled? "param" vs "return" passed in as a string argument, maybe? 08:48
allison Tene: for now, it means you'll need separate functions for fill_params and fill_returns 08:50
Tene: but you can use the same accessor function pointers inside each
Tene: (you'll need separate functions anyway, because the logic is entirely different)
Tene allison: fill_returns uses VTABLE_set_*_native, where fill_params has the accessors return a pointer, which fill_params assigns to. Should I modify the accessors to do the assignment directly? 08:52
dalek rrot: r41677 | dukeleto++ | branches/pcc_reapply/t/op/calling.t:
[pcc_reapply][t] Fix some tests in t/op/calling.t that now throw slightly different error messages
 08:53
allison Tene: that's what I mean about the logic being reversed, fill_returns only needs to fetch values from the accessors, while fill_params has to set values on the accessors
Tene: I wouldn't modify the accessors, though, just use them in their "getter" behavior instead of their "setter" behavior 08:54
Tene allison: if I make them setters, I can use the same logic, it seems.
allison: <sarcasm> Oh, I know! We just pass an additional function pointer encapsulating the relevant logic!</sarcasm> 08:55
allison Tene: they're already tetters and setters
getters
Tene: essentially, everywhere you see 'VTABLE_set_integer_native(interp, result_item, CTX_REG_INT(ctx, raw_index))'
Tene Vsin(i,r,accessor->integer(...)) 08:56
allison that changes to 'VTABLE_set_integer_native(interp, result_item, *accessor->intval(interp, arg_info, param_index))
Tene yeah
allison Tene: that way we don't need a custom set of function pointers for fill_returns 08:57
Tene: better to use the same ones
Tene: I see some macros coming on here
Tene allison: &REG_INT is the same thing as CTX_REG_INT ? 08:58
allison PCC_SET_INTVAL, or something like that
Tene: yes, one is a macro, the other is a pointer
Tene Ah.
Ah, they're the identical, except the version that only takes an interp fetches the ctx from the interp. 09:00
and the version that only takes a context just assumes the interp is named 'interp'
Okay, I get it now.
My other suggestion is a bit more serious, then. If we add one more function pointer, I think we can get away with only one function. I'll try it your way first, though. 09:02
allison Tene: aye, get it working first, then we can refactor it down 09:03
Tene Ew, I feel dirty, copying and pasting a huge function.
;) 09:04
allison Tene: fair warning that the logic in fill_params is currently wrong, so copying it may not be the best place to start 09:07
Tene: but, you can fix it as you go 09:08
Tene allison: in the way that we just talked about?
allison Tene: yes
I'm about to flip the logic of fill_params to iterate over arguments, as on the wiki page
Tene allison: it will keep the same API? 09:09
allison Tene: but, here's the kicker, if you do a direct copy of fill_params to fill_returns, it's already using the "iterate over arguments" logic
(because the logic is reversed in the two)
Tene: yes, I'll keep the same arguments to fill_params 09:10
Tene allison: returns is supposed to use 'iterate over arguments' ?
allison Tene: return arguments
Tene right
allison Tene: that is, what's passed in from 'set_returns' 09:11
Tene I've been using arg:param::return:result
allison Tene: that's what the code currently uses too
(will likely continue using) 09:12
but, when we finally merge the two, args and returns are the same, and params and results are the same 09:13
basically, filler and filled
09:22 bacek joined
dukeleto a patch status on trac of "review" would be pretty useful 09:32
allison dukeleto: it's been suggested 09:34
09:34 kurahaupo joined
dalek tracwiki: v17 | allison++ | CallingConventionsOverview 09:34
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqdf2
Tene allison: looks like I'm going to sleep now. You say that fill_returns *should* use the current fill_params algorithm, even though you're changing the fill_params algorithm? 09:35
allison dukeleto: the semantic difference between 'new' and 'review' was pretty thin
Tene: yes, at least as a starting point
Tene allison: Okay. I'll finish it in the morning. Goodnight.
allison Tene: though you'll have to make changes to it 09:36
Tene: night
dukeleto allison: perhaps "qa" ? i just want something to denote "the current patch has been looked at and is being reworked". none of the current categories seem to convey that
Tene allison: Sure. If there are any changes that you don't think will be obvious, feel free to mention them, otherwise I'll just diagnose from test failures.
allison Tene: I'll leave the fill_returns parts for you and work on the fill_params parts
Tene allison: great
allison Tene: thanks for the help! 09:37
dukeleto: so, something shy of 'rejected'
dukeleto: that's not really 'review', it's more of 'changes requested'
dukeleto: mmmm... a good single word for that 09:38
dukeleto: it really seems like 'rejected', then reset to 'new' when the new patch is attached 09:39
dukeleto: maybe 'revision' 09:41
dukeleto: or 'updated'
09:42 spankme joined
kurahaupo allison: "abeyant"? 09:45
09:45 janus joined
allison kurahaupo: points for aptness, minus on "obvious to the casual ticket wrangler" 09:46
kurahaupo :-)
"Stuck" >-)
bacek o hai 09:47
allison held_for_changes
bacek allison: what is current status of branch? 09:50
allison bacek: 186 failing tests last I checked 09:52
bacek: I'm reworking fill_params for the "iterate by argument" algorithm Whiteknight and I worked out
bacek: good work on the function pointers, it simplifies a lot of code
bacek allison: good-good. Any chances to merge fill_params and fill_returns?
allison bacek: not at this point, no, the logic is reversed 09:53
bacek sigh
allison bacek: but they can both use the accessor function pointers
bacek Can we adjust imcc to produce ops in proper order?
allison bacek: actually, the build_sig_object code can use the accessor function pointers too
bacek: yes, we will after 2.0
bacek: but it's a substantial interface change, so requires a deprecation cycle 09:54
bacek allison: yeah. I've made accessors very generic to use across all specific functions.
allison: why it's "interface changes"?
allison because it changes the order the ops have to be called in
some ops are hidden behind syntactic sugar, but all ops are part of the public interface 09:55
bacek ok.
ok. I'm going to generalise build_sig_object. Any objections? 10:00
allison bacek: go ahead
bacek: but keep in mind that the varargs version gets calls and returns all in one call
bacek: while the _from_op version gets them in two calls 10:01
bacek: (one from set_args and one from get_returns)
get_results
10:03 kj joined
allison bacek: they can't really be collapsed at the moment, but they can be changed to use the function pointers 10:04
dalek rrot: r41678 | kjs++ | trunk/compilers/pirc/src (3 files):
[pirc] create STRINGs for labels and identifiers, store them in the temp. lexer->sval field, so the parser can them access them
 10:05
10:06 fperrad joined 10:10 masak joined
bacek allison: There is a string in build_sig_object_returns _from_op - string_sig = Parrot_str_append(interp, string_sig, CONST_STRING(interp, "->")); 10:11
allison bacek: yes
bacek allison: isn't it other way around? append("->", string_sig)?
allison bacek: the signature string goes args->returns 10:12
so P->S is one PMC argument and one string return
bacek that's why I'm asking
allison bacek: so that's appending an arrow onto the end of the string_sig 10:13
bacek but it's build_RETURNS...
allison yes, so it appends an arrow on to the end before it appends the return sigs 10:14
bacek ah, ok
kurahaupo General question: What is the usual process for someone to be granted svn-commit privileges? (I realise I'm new as a contributor, so I don't expect full access right now; I just want to know what to expect...) 10:18
10:19 quek joined
bacek kurahaupo: few good patches, 2+ votes on #ps to grant commit access, 1+ person to mentor, submit CLA. 10:22
kurahaupo Bacek: thanks. Preferred method of submitting patches in the meantime? ļ»æEmail? Trac ticket? Attached file? Inline? 10:24
bacek kurahaupo: trac ticket with attached patch for big ones. Just nopaste for small one (in case when channel is "alive")
kurahaupo worries that his suggested patch to exception.t may have broken the scoping semantics, since it reduces twelve compilation units to one. 10:26
bacek kurahaupo: did you mean "exporter.t"? 10:27
kurahaupo Yes
(It's 23:30 here; I should get some sleep.)
bacek kurahaupo: just attach your patch to ticket. Current variant is almost unreadable. And go to sleep than :) 10:29
mikehh kurahaupo: see docs/project/roles_responsibilities.pod
kurahaupo mikehh: thanks, will read it in the morning. 10:30
Goodnight all.
dalek rrot: r41679 | bacek++ | branches/pcc_reapply/src/call/context.c:
[cage] Init Context.current_sub to avoid dereferencing garbage pointer.
 11:03
rrot: r41680 | bacek++ | branches/pcc_reapply/src/pmc/callsignature.pmc:
Mark all attributes of CallSignature.
 11:06
tracwiki: v18 | bacek++ | CallingConventionsOverview
tracwiki: Claim few more passing tests
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqdjw
11:08 payload joined
dalek rrot: r41681 | kjs++ | trunk/compilers/pirc/src (4 files):
[pirc] add STRING * variants to all data structures that currently use C strings (char *) as preparation of making PIRC STRING-aware
 11:09
11:14 silug joined
dalek tracwiki: v19 | bacek++ | CallingConventionsOverview 11:45
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqdms
dalek rrot: r41682 | mikehh++ | branches/pcc_reapply/src/pmc/callsignature.pmc:
codetest failure - trailing spaces
 11:48
11:49 joeri joined
mikehh bacek: I am getting quite a few codetest failures with src/call/args.c - c_arg_assert.t and c_function_docs.t and also c_parens.t 11:53
11:53 kid51 joined
mikehh I tried a make headerizer and it gave some 40 warnings on src/call/args.c but no svn diff 11:54
I tried to fix the parens error but it don't make no sense to me 11:55
messages 11:59
dalek kudo: 809ca9b | masak++ | src/classes/Signature.pir:
[Signature.pir] fixed typo
 12:04
shorten dalek's url is at xrl.us/bfqdoh
kid51 pcc_reapply branch with --buildframes=0: latest Smolder: smolder.plusthree.com/app/public_pr...ails/28521 12:05
shorten kid51's url is at xrl.us/bfqdoj
kid51 132 failing tests (sans buildframes) 12:06
12:10 iblechbot joined 12:13 bacek joined
kid51 allison ping 12:16
mikehh: I've figured out the c_parens.t problem.
It's a weird one.
dalek rrot: r41683 | jkeenan++ | branches/pcc_reapply/src/call/args.c:
Temporarily fix failure of file to pass c_parens coding standard.
 12:17
12:19 Whiteknight joined
kid51 msg allison src/call/args.c lines 36-37: typedefs INTVAL and FLOATVAL: INTVAL and FLOATVAL are reserved words in t/codingstd/c_parens.t; may only be followed by a single space. Have applied bandaid to make codingstd pass. But we should either use different names for these typedefs or change the coding standard. 12:20
purl Message for allison stored.
bacek kid51: we can't use different name. They are return types from functions. 12:25
bacek vote for changing coding standard to s+ 12:26
allison kid51: those lines are the return signature of the typedef 12:32
Whiteknight how is pcc_reapply doing this morning? Any bugs get fixed?
allison Whiteknight: I'm nearly done overhauling fill_params for argument iteration
Whiteknight oh wow 12:33
I'm sorry I couldn't have done more of it yesterday
allison Whiteknight: bacek did a good job converting register and vararg access to function pointers and unifying the _from_op and _from_c_args versions of fill_params
Whiteknight yeah, I'm looking at that right now 12:34
bacek++
allison Whiteknight: he's currently working on converting the build_sig_object functions to use the same function pointers
bacek allison: not quite true actually.
allison kid51: that is, the typedef is the function pointer 12:35
bacek: well, last I heard that's what you were working on
bacek: what are you working on?
bacek allison: I can't figure out how to make this functions generic.
allison bacek: you can't
bacek I'm trying to fix other bugs atm.
allison but, you can use the function pointers
bacek: to clarify, you can't make them generic now, but will be able to after we fixing the ordering of get_results 12:36
bacek allison: but what the point?
purl i guess the point is that tom_g would prefer to have consistent coredumps than unpredictable ones :)
allison bacek: to make the ultimate merge easier
dalek rrot: r41684 | jkeenan++ | branches/pcc_reapply (2 files):
Better solution: Modify codingstd to allow more flexibility in lines
allison bacek: and to cut down on duplicated code
kid51 mikehh: I don't know how to fix the c_args_assert failures because the errors are occurring in zones that are marked "Don't make changes here; all your changes will be lost." 12:38
Whiteknight kid51: which zones?
allison bacek: and you can make them somewhat generic, it's just that the varargs version has to call both "build_sig_args" and "build_sig_returns" 12:40
bacek allison: yes. But I have figure out out best way to do it. And it's about midnight here, so I don't trust myself. 12:41
side question, why Parrot_find_pad iterate over Context.outer_ctx, not Sub.outer? 12:42
allison bacek: sensible
purl sensible is usually inappropriate, yes :)
allison bacek: i believe it's because the outer context may be set at runtime to something other than the sub was compiled to 12:43
bacek: but would need to look at the code
bacek allison: it can. But it uses Sub.set_outer which set... erm... Sub.outer as well 12:44
more generic question: why LexPad in Context at all? 12:45
should it be in Sub only?
kid51 Whiteknight: see lines 26-46 of src/call/ops.c
mikehh: As for the c_functions codingstd errors -- the non-TODOed ones are all found in src/call/args.c. 12:46
mikehh kid51: yes I know - I passed that on to bacek to look at :-} 12:47
kid51 src/call/args.c is also reporting "17 unused assert macros" when run through t/codingstd/c_args_assert.t
allison bacek: Context stores all the information unique to a particular execution of a Sub
Whiteknight kid51: I don't see anyting out of place there, what's the codestd error there?
allison bacek: Sub is the same for all executions
bacek mikehh: just add PARROT_ASSERT_ARGS and POD docs :)
Whiteknight Context is like a stack frame in C, only better 12:48
and Sub is like the executable machine code
allison bacek: so, if you run the same sub twice, each time will have its own unique LexPad
mikehh kid51: the stuff between the HEADERIZER tags should be fixed by make headerizer - but it does not seem to work properly in the branch
bacek allison: hm... I have to sleep on it to understand fully.
kid51 Whiteknight: Try: perl t/codingstd/c_arg_assert.t src/call/ops.c 12:49
mikehh: Verified. 12:50
Whiteknight Oh, I can fix that. one second
done 12:52
allison Whiteknight: there's a problem in the second half of our pseudocode, in that it assumes that named parameters and named args will come in the same order 12:55
dalek rrot: r41685 | whiteknight++ | branches/pcc_reapply/src/call/ops.c:
[pcc] fix headerizer problem. This file doesn't have any static functions anymore so no need to have a static forward declaration section
 12:56
rrot: r41686 | whiteknight++ | branches/pcc_reapply/src/call/args.c:
[pcc] small aesthetic fixes
allison Whiteknight: so have to iterate over parameters, then iterate over the hash to make sure we caught all of the arguments
12:57 einstein joined
kid51 Uh oh. I just got a build failure -- even with --buildframes=0 12:57
12:58 wknight8111 joined
kid51 Let me try that again. 12:59
wknight8111 stupid router is stupid 13:00
kid51 Now Whiteknight has multiple identities
wknight8111 tell me about it 13:01
purl rumour has it it is sad I recognize Jon's laptop/keyboard combo
dalek rrot: r41687 | bacek++ | branches/pcc_reapply/src/pmc/sub.pmc:
[core] Fix strange shortcut in setting Sub.outer_ctx with normal loop.
 13:04
rrot: r41688 | bacek++ | branches/pcc_reapply/src/pmc/sub.pmc:
[cage] Remove unused variable in Sub.set_outer
wknight8111 allison: I was figuring a two-way lookup: Get the name of the argumet from the iterator and then use that to look up the appropriate parameter slot 13:05
allison Whiteknight: has to go the other way around, because the parameters *are* ordered
Whiteknight: but, yes, essentially 13:06
wknight8111 urg, the test results still aren't looking much better 13:22
kid51 With --buildframes=0, we have 131 tests still failing
smolder.plusthree.com/app/public_pr...ails/28526 13:23
shorten kid51's url is at xrl.us/bfqdt7
wknight8111 is that in the pcc_reapply branch? 13:24
actually, the list is shorter then the last time i looked
13:25 PacoLinux joined
allison wknight8111: yesterday it went down from 414 to 200-something 13:25
kid51 Yes. Note the 'branch' and "Configure_args' lines in the test report's header
allison today it's down below 200
wknight8111 yay! hackathon++
kid51 Note that totals are much different without --buildframes=0 13:26
I'll have those totals in a few minutes
wknight8111 t/pmc/sub.t test 37 looks strange to me 13:30
it expects an :immediate :postcomp sub to be called twice
is that the case?
bacek there is some shenanigans with :slurpy :named. t/oo/metamodel failing because args aren't filled. 13:38
kid51 Hmm, without --buildframes=0 t/op/gc.t hangs
Yesterday, we were getting thru 'make test' with buildframes, albeit with > 400 errors. 13:39
but now, I'm hanging on test 118 in that file 13:40
wknight8111 bacek: yeah, :slurpy :named is a problm 13:41
I don't see any :named :slurpy parameters in t/oo/metamodel.t 13:44
dalek rrot: r41689 | rblasch++ | trunk/docs/book/pir (4 files):
[book] Fixed typos.
 13:55
14:03 bacek joined
bacek hi again 14:03
purl oh, you're back!
bacek wknight8111: check Class.new.
it uses "bare" :named :slurpy and receives empty hash instead of params 14:04
kid51 pcc_reapply branch without --buildframes=0: t/op/gc.t hangs indefinitely before it gets to test at line 235 14:06
dalek rrot: r41690 | jkeenan++ | branches/pcc_reapply/t/op/gc.t:
Add a test description to help debugging.
 14:08
bacek kid51: all tests successful in t/op/gc.t on my box...
wknight8111 t/pmc/coroutine.t:8 is failing because of lack of :optional and :opt_flag on returns
dalek rrot: r41691 | rblasch++ | trunk/docs/book/pir (4 files):
[book] Reverted r41689, committed too much.
 14:12
bacek ok. we definitely need smarter fill_returns... 14:13
mikehh++ # really good fix for codetest failures 14:14
dalek rrot: r41692 | mikehh++ | branches/pcc_reapply/src/call/args.c:
attempt to fix codetest problems with src/call/args.c - codetest passes
 14:15
rrot: r41693 | rblasch++ | trunk/docs/book/pir/ch09_exceptions.pod:
[book] Fixed typos.
rrot: r41694 | jkeenan++ | branches/pcc_reapply/t/op/gc.t:
Add more test descriptions.
 14:21
14:22 Psyche^ joined 14:33 cognominal joined 14:36 cognominal joined 14:38 AndyA joined
mikehh well codetest and manifest_tests PASS in pcc_reapply branch 14:44
kid51 Building without --buildframes=0, t/op/gc.t hangs during 'make coretest' for me. It's been hung 20 minutes! 14:59
When I run it with prove, it stops after 117 tests -- but at least I can get the test summary report. 15:01
15:03 theory joined 15:06 Maddingue joined
kid51 With --buildframes=0, t/op/gc.t just sails right through -- no failures at all. 15:07
bacek kid51: it's "expected"... 15:11
mikehh it completes for me - waiting to send to smolder 15:14
dalek rrot: r41695 | bacek++ | branches/pcc_reapply/tools/build/nativecall.pl:
Fix handling /B/ in nci nativecall builder. Claim one more passing test.
 15:16
rrot: r41696 | bacek++ | branches/pcc_reapply/src/nci_test.c:
Trade last test from t/pmc/nci.t into compiler warning.
bacek holy sh... 15:17
clock?
purl bacek: LAX: Sun 8:17am PDT / CHI: Sun 10:17am CDT / NYC: Sun 11:17am EDT / LON: Sun 4:17pm BST / BER: Sun 5:17pm CEST / IND: Sun 8:47pm IST / TOK: Mon 12:17am JST / SYD: Mon 2:17am EST /
bacek must sleep
purl $bacek->sleep(8 * 3600);
mikehh still waiting - doesn't seem to want to connect 15:19
15:30 jan joined 15:45 iblechbot joined
mikehh managed to get it smolder on the second attempt - smolder.plusthree.com/app/public_pr...ails/28535 15:46
shorten mikehh's url is at xrl.us/bfqd7t
16:05 particle joined
allison bacek: ping 16:13
ah, bacek sleep, unping 16:14
16:20 nopaste joined
dalek rrot: r41697 | pmichaud++ | branches/pct-rx/t/compilers/pct/regex/06-p6regex.t:
[pct-rx]: Move p6regex test a bit later in sequence.
 16:27
allison Whiteknight: ping 16:28
mikehh bacek's last commit's cause a build failure 16:29
allison mikehh: yes, that's what I was pinging him about, we can revert for now
mikehh: I'm not sure if it's just the last commit or the last two commits 16:30
mikehh: svn update -r41694 works
mikehh: haven't tried -r41695 16:31
mikehh: -r41696 is definitely broken
mikehh alison: yes at r41694 amd64 I get 6,434 ok, 125 failed, 100 todo, 162 skipped and 1 unexpectedly succeeded 16:32
I updated to r41696 and got a failure with src/nci_test.c 16:34
allison mikehh: that looks right, how about -r414695?
mikehh: that looks right, how about -r41695?
mikehh let's see
r41695 builds 16:35
I did svn update -r41695, make corevm (didn't clean or anything) 16:36
allison does it fail a lot of tests? 16:38
mikehh: (I ask because bacek's comment on r41696 implies that it was fixing test failures) 16:39
mikehh I am running smolder_codetest at the moment - will see 16:42
it will probably indicate r41696 because that is where I configured 16:43
but I reverted to r41695 16:44
it just reverted the test
src/nci_test.c
smolder.plusthree.com/app/public_pr...ails/28540 16:45
shorten mikehh's url is at xrl.us/bfqedg
allison mikehh: great, thanks!
mikehh looks the same as #28535 16:48
wknight8111 allison: pong
mikehh bear in mind that it is actually at r41695 nor r41696 as indicated 16:49
not
allison whiteknight: I've got a diff for code review 16:56
Whiteknight: or I can check it in
whiteknight check it in
we can roll it back if it stinks (unlikely) or build on it to make it better in place 16:57
allison whiteknight: committed 16:58
whiteknight w00t 16:59
build is broken
whiteknight backlogs
allison whiteknight: at the moment I'm tracking down a failure in t/oo/composition.t
whiteknight okay, I'll track down the build failure
allison whiteknight: mikehh said he reverted the build failure 17:00
dalek rrot: r41698 | allison++ | branches/pcc_reapply/src (2 files):
[pcc] Reworking fill_params as an iterator over arguments rather than
purl parameters are definitely in the scope of the callee
whiteknight oh. realclean, rebuilding
allison whiteknight: nope, looks like mikehh didn't commit 17:01
whiteknight gotcha 17:03
17:03 szabgab joined
allison whiteknight: commited revert 17:05
whiteknight awesome
allison whiteknight: was at 165 test failures after adding my patch 17:06
dalek rrot: r41699 | allison++ | branches/pcc_reapply/src/nci_test.c:
[pcc] Reverting r41696 as it caused a build failure.
whiteknight great! The number is getting very low 17:07
and many, I'm certain, are just the result of not handing options on return arguments and not properly handling them on parameters 17:08
both of which can be tracked down and fixed
allison whiteknight: aye 17:09
I'm gettin "too few named arguments: no argument for required parameter 'exclude_method'" 17:10
but the parameter is marked :optional
whiteknight urg. I was seeing problems with :named :optional the other day
allison (stranger still, the version of the method on that class doesn't even have that parameter at all)
whiteknight what test is this?
purl tested ok
allison t/oo/composition.t 17:11
17:11 masak joined
moritz re 17:11
mikehh alison: sorry - I aqm having a few problems with my internet connection - I commited but it did not connect properly to the server - apologies - I was checking something else 17:12
allison mikehh: no worries, I figured I had misread your IRC comment
mikehh: (that you had just reverted it locally for the smoke test run, or something like that)
dalek kudo: a796cf1 | moritz++ | src/setting/Operators.pm:
add another &infix:<...> multi to handle the case 3 ... $+2, $max
 17:13
shorten dalek's url is at xrl.us/bfqei2
dalek kudo: db7c668 | moritz++ | src/setting/Complex.pm:
Complex.ACCEPTS
shorten dalek's url is at xrl.us/bfqei4
mikehh I did but then when everything was ok I did an svn commit but as I said it did not connect properly to the server 17:14
allison mikehh: oh well
mikehh: hopefully it didn't get completely confused at merging my commit into your uncommitted change 17:15
mikehh I was also doing some tests on trunk and only looked at it a couple of minutes ago
whiteknight allison: I dont see anywhere that you set un-passed opt_flags to false 17:16
oh wait, I found it
allison yeah, it's the next 'else' 17:17
mikehh All tests PASS (pre/post-config, smoke (#28541), fulltest) at r41696 - Ubuntu 9.04 amd64 17:18
dalek rrot: r41700 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Don't declare variable until limited scope where it's used.
 17:23
17:33 ilbot2 joined
moderator www.parrot.org | Parrot 1.6.0 "half-pie" released: PCC branch hackathon all $localtime Saturday | Testing priorities: pcc_reapply branch
mikehh What's with CONST_STRING - it breaks the compiler if THE STATEMENT with it in is split across lines 17:34
whiteknight if I add printf statements into the named arguments loop for debugging, Parrot fails an assertion inside do_thaw 17:37
mikehh: yeah, it's stupid 17:42
17:42 kid51 joined
dalek rrot: r41701 | whiteknight++ | branches/pcc_reapply/src/call/args.c:
[pcc] fix CONST_STRING spread across multiple lines
 17:42
tracwiki: v104 | jkeenan++ | WikiStart 17:43
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
shorten dalek's url is at xrl.us/bfqeoe
17:45 tetragon joined
dalek rrot: r41702 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Better checking on named argument passing counts.
 17:45
kid51 pcc_reapply branch: r 41701: with --buildframes=0: smolder.plusthree.com/app/public_pr...ails/28543 17:52
shorten kid51's url is at xrl.us/bfqepj
kid51 Hmm: that's 33 more test failures than at r41694, under the same conditions 17:55
17:56 kurahaupo joined
fperrad ping bacek 17:56
purl I can't find bacek in the DNS.
kurahaupo Bacek's in UTC+10 so he'll be asleep
kid51 Hmm, I notice that at r41694, all tests in t/pmc/class.t were SKIPped; at r41701 they are unSKIPped and failing 17:57
kid51: wrong; it's the other way around 17:58
In more recent report, am getting failures in t/pmc/exporter.t that were not there in earlier. 17:59
The new failures in t/pmc/exporter.t are of these types: "too few named arguments: no argument for required parameter"; "named parameters must follow all positional parameters". See smolder.plusthree.com/app/public_pr...m/28543/97 18:01
shorten kid51's url is at xrl.us/bfqeq3
allison kid51: the logic for argument handling has been expanded, working on fixing up the incidental damage 18:05
kid51 k 18:06
t/oo/composition.t also blew up in the later revision: for same "too few named arguments" reason: smolder.plusthree.com/app/public_pr.../28543/180 18:07
shorten kid51's url is at xrl.us/bfqerw
dalek rrot: r41703 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Add checking for a named parameter that doesn't have a string name.
 18:08
allison kid51: thanks for the reports, very helpful 18:09
moritz wow, the pcc_reapply branch looks much better than it did last week 18:13
whiteknight named parameter that doesn't have a string name? 18:16
ah okay, we don't support it 18:17
that's good
18:17 whoppix joined
allison whiteknight: funny, I didn't notice before that slurpy hashes weren't actually collecting any arguments (they were just returning an empty hash) 18:23
whiteknight: I guess that means the new code is more maintainable, even if it's still monolithic 18:24
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply branch: --buildframes=0: current failures verbose output" (1893 lines) at nopaste.snit.ch/18213
allison whiteknight: (it's also easier to refactor it down to smaller routines)
dalek rrot: r41704 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Actually collect named args into the slurpy hash.
whiteknight haha, that's funny 18:25
I didn't notice it either
allison whiteknight: is parameter count checking supposed to be on by default? I remember it being of by default 18:29
off
whiteknight i thought it was on by default?
allison whiteknight: it is on by default now
whiteknight: just surprised me when I was working on a test case just now 18:30
whiteknight oh, okay
allison whiteknight: ah yeah, running the same code against trunk produces the same error 18:31
(or a similar error, slight text differences)
kurahaupo I was about to redo t/pmc/exception.t in PIR; should I leave it while you're re-doing parameter handling? 18:32
allison neat, another 44 tests passing
kurahaupo Never mind, someone beat me to it. 18:34
dalek rrot: r41705 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Also mark the named argument as used when its pulled into the slurpy,
whiteknight very few test files are aborting early now, that's a great sign 18:36
dalek rrot: r41706 | allison++ | branches/pcc_reapply/t/op/calling.t:
[pcc] PIR test for slurpy named arguments.
 18:37
18:40 payload joined
whiteknight okay, the test I was just debugging works now after r41704 18:40
so it was the slurpy hash that was the problem
allison whiteknight: hmmmm.... with :optional :named('foo')... does the :optional flag end up on the string parameter 'foo', or on the actual parameter? 18:41
whiteknight you know what? I have absolutely no idea
allison whiteknight: I've been assuming it shows up on the string name
whiteknight I've sort of assumed it was the other way around
we could switch it around and see if more or fewer tests pass 18:42
allison whiteknight: I'll try it
checking specifically t/pmc/class.t, where an optional parameter is being mishandled as required 18:43
whiteknight: alrighty then, that made the test pass 18:47
whiteknight: I guess the optional gets marked on the actual param, not on the param name
whiteknight sounds like we need some documentation about that
All the tests I was debugging are passing now. I need to look for new tests
can I get your opinion on t/pmc/sub_37.pir? 18:49
we can "fix" it if that is the desired behavior
the question is whether an :immediate :postcomp sub should be executed twice or not 18:50
allison whiteknight: whoah! down to 63 failing tests!
18:51 s1n joined
allison whiteknight: (re :postcomp and :immediate) we should preserve the existing behavior now, even if we decide to change it later 18:51
whiteknight where do we see the number of tests failed? I never see that number 18:52
kid51 r41706 cleared about 42 tests: smolder.plusthree.com/app/public_pr...ails/28551 18:53
shorten kid51's url is at xrl.us/bfqewa
allison whiteknight: when you run 'make coretest' it should give you a summary at the end 18:54
kid51 whiteknight: smolder.plusthree.com/app/public_pr...reports/8: I've been reporting results of make corevm makecoretest in pcc_reapply branch with --buildframes=0 in configuration
shorten kid51's url is at xrl.us/bfqewi
dalek rrot: r41707 | mikehh++ | branches/pcc_reapply/src/call/args.c:
codetest fixes - assert args, function docs, linelength
rrot: r41708 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] The :optional flag is marked on the named parameter itself, not on the
allison kid51: try 41708 :)
Tene allison: src/call/args.c +811, ISO C90 forbids mixed declarations and code
kid51 allison: You're too fast for me! 18:55
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply branch: --buildframes=0: current failures verbose output" (1816 lines) at nopaste.snit.ch/18214
allison Tene: thanks, fixing
whiteknight allison++ is kicking ass 18:58
dalek rrot: r41709 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Fix C90 compiler warning about mixed declarations and code.
 19:01
moritz it seems some of the failures stem from too strict checks for error messages
'too few positional arguments: 1 passed, 2 (or more) expected 19:02
...
doesn't match '/too (many|few) arguments passed .*
Tene moritz: yes, the tests need to be fixed.
allison moritz: yes, those are the old error messages 19:03
kid51 41708 gets us down to 58 19:05
allison kid51: excellent, the finish line is in sight
Tene: I suspect return argument handling is about half of what's left 19:06
Tene allison: fortunately, that's what I'm just about to start on.
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply branch: --buildframes=0: current failures verbose output" (1731 lines) at nopaste.snit.ch/18215
allison Tene: I'm going off to make some dinner, but I'll check in in case you have any questions
kid51 Of course, the results aren't going to be so pretty when we omit '--buildframes=0' from Configure.pl 19:07
but at least we have partialized the problems
Tene allison: just confirmation that you want me to use the old algorithm from fill_params for fill_returns
allison: which you already gave last night.
mikehh I get 6,502 ok, 58 failed, 101 todo, 162 skipped and 1 unexpectedly succeeded with normal parameters on amd64 - smolder #28553
allison Tene: I'd start there, it's closest to what you'll want
Tene: but you can take a look at the new fill_params too 19:08
Tene: see if there's anything helpful there
kid51: funny, I'm not using --buildframes=0, but perhaps buildframes only works on x86 19:09
mikehh well my normal configure parameters - see the smolder test - smolder.plusthree.com/app/public_pr...ails/28553
shorten mikehh's url is at xrl.us/bfqeyi
mikehh that's at r41708 - codetest also passes 19:10
kid51 allison: See scrollback a couple of hours re my build problems on Linux 86 without --buildframes=0; compare mikehh's results 19:11
I fear we're going to encounter some platform-specific differences;
mikehh showed 58 failures at r41708; I showed 63. Why did I get more *with* --buildframes=0 and on 32 bit? 19:12
I don't know -- but I gotta book.
mikehh I have spent far too many hours on this - I was going to try out the Ubuntu 9.10 beta but never got around to it 19:15
but it has been fun anyway 19:16
whiteknight urg, imcc is such a damn mess
Tene srsly 19:17
mikehh bring on pirc, or something - there were a couple of commits by kjs on it, but I haven't looked yet
whiteknight I'm trying to chase down that t/pmc/sub.t failure, and it's leading me into the abyss
dalek rrot: r41710 | moritz++ | branches/pcc_reapply/t/op/cc_params.t:
adapt testing regex to new error messages in t/op/cc_params.t
 19:18
ose: r171 | Austin++ | trunk/ (50 files):
NOT WORKING: Commit before directory moves.
 19:22
ose: r172 | Austin++ | trunk/src/close/ (2 files):
Renamed Compiler->Slam
 19:27
ose: r173 | Austin++ | trunk/src/ (2 files):
Moved src/close/Slam -> src/Slam
ose: r174 | Austin++ | trunk/build/Makefile.in:
Updated Makefile.in
 19:46
19:47 s1n joined 19:55 joeri left 20:07 s1n joined 20:11 cconstantine joined
mikehh pcc_reaply branch - smolder_coretest - smolder.plusthree.com/app/public_pr...ails/28557 at r41710 20:19
shorten mikehh's url is at xrl.us/bfqe9u
mikehh 6,521 ok, 39 failed, 101 todo, 162 skipped and 1 unexpectedly succeeded - Ubuntu 9.04 amd64 20:20
that's down to 39 failures from 58 at r41708 20:21
of course kid51 was getting more on i386 but hey :-} 20:22
20:22 bacek joined 20:23 fperrad_ joined
mikehh oh and codetest and manifest_tests also PASS 20:26
and pre/post-config tests
mikehh need a break, a nap, mabe some sleep 20:28
bbl
20:37 s1n joined
allison full of enough pancakes to explode an elephant, and looking at the frame_builder 20:40
20:41 mokurai joined
whiteknight allison: did you see the libJIT-based framebuilder that plobsinger made? 20:43
he has it up on git
allison whiteknight: I didn't
whiteknight github.com/plobsing/parrot-libjit
allison whiteknight: or, I saw his IRC message go by, but had my nose buried in pcc at the time
whiteknight no hurry, but it's a very cool project
allison whiteknight: cool, I'll take a look 20:44
whiteknight awesome
Tene allison: I've managed to get myself a little bit confused here. Can you explain the 'returns' attribute of the callsignature pmc to me?
allison Tene: 'returns' is only positional returns 20:45
Tene Where are named returns stored?
allison Tene: and, because Parrot's return handling is currently backward...
Tene: named returns aren't currently stored at all 20:46
Tene: ...backward, each return set by 'get_results' is actually a storage location where 'set_returns' will store the return value
Tene: it's stupid, and will change after 2.0 20:47
Tene allison: also, afaict, the raw_sig passed to fill_returns is the signature of the returns, not the signature of the results, right?
allison Tene: but at the moment it has to work that way
Tene nodnod
allison Tene: yes
fill_returns is called from 'set_returns'
the raw signature of the results is passed to 'build_sig_object' 20:48
(in vararg and op variants)
whiteknight that reminds me, my list post about sub-based exception handlers got warnocked. I'm going to put in the deprecation notice for that now 20:52
Tene allison: so we pull items from wherever and store them in the 'returns' attribute of the callsignature?
allison Tene: yes 20:53
Ryan52 allison: so...what's happening with getting a newer parrot in Debian? :)
allison Tene: first we fill 'returns' with CPointers to the destinations, then we set the values of those CPointers to the actual return values
Ryan52: I've been a bit busy 20:54
Ryan52: I did get your message though
Ryan52 allison: willing to let me do it? (just the upload to experimental)
allison Ryan52: go for it
Ryan52: but check with me if you have to make any packaging changes beyond version number 20:55
Ryan52: the packaging files are all in ports/debian in the repository
Tene allison: so how do we deal with, say, :slurpy results?
allison Ryan52: and please build from the tarball of the most recent release, rather than from svn
Tene allison: I don't see where I can find out that a given result is supposed to be :slurpy
allison Tene: that's the tricky part of the reversed logic 20:56
Tene stated another way, where can I find out about the results sig?
allison Tene: you have to check the return string signature
Ryan52 allison: okay, thanks!
allison where it will have the original marking for 'slurpy'
Tene Where can I find that? 20:57
purl that is how it does it.
allison Ryan52: thank you!
Tene: it's stored in the call_object
Tene Is it the short_sig?
allison Tene: or, if the signature was set up from an op, the FIA signature is stored in return_flags 20:58
Tene: yes, the short_sig is the string signature
Tene Okay.
allison Tene: short_sig is both args and returns, so jump ahead to everything after '->'
Tene: if that proves a headache, we can just generate the return_flags from the varargs version 20:59
Tene and it ends up being set in the return_flags attribute of the callsignature.
allison Tene: so the op and varargs version are consistent
Tene Okay.
Ryan52 allison: hm, what do you mean when you szy the files are in ports/debian?
*say
Tene I think I understand what's going on now.
Ryan52 oh, nevermind, found it. 21:00
allison Ryan52: if you checkout the Parrot repository, there's a directory that isn't included in the tarball
Ryan52: okay
Tene I'll go back for another try at this.
allison Ryan52: the step-by-step guide on how we build the parrot packages is in docs/project/debian_packaging_guide.pod 21:01
Ryan52: (I know you already know all about debian packages, but that'll give you the Parrot specifics)
Tene: cool 21:02
dalek TT #1091 created by whiteknight++: ExceptionHandlers should be Subs
Tene allison: just to confirm, the "returns" attribute holds the pointers to the *results*, and the "return_flags" attribute has the signature of the *results*, right? 21:03
allison Tene: yes, feel free to change the names
Tene Let me just say, those names are very confusing. :P
allison Tene: I've been mixing up returns and results in my usage as badly as whiteknight mixes up args and params :)
Tene: agreed, if you have any better ideas I'm open to them :) 21:04
Tene: maybe 'return args' and 'return params', just so we only have to deal with one set of confusion
whiteknight I think allison is full of crap if she thinks args and params are different things
:)
allison whiteknight: :)
Tene whiteknight: I disagree. args and params are very different.
allison whiteknight: I can say the same about returns and results
whiteknight Tene: That can't be! if they were different, I wouldn't be confusing the two words 21:05
dalek rrot: r41711 | whiteknight++ | trunk/DEPRECATED.pod:
[DEPRECATED] Continuation-based ExceptionHandlers are on the chopping block after 2.0 TT #1091
allison whiteknight: it's like a bus that changes route numbers depending on whether it's leaving or arriving
"leaving the station it's 403, but returning it's 546. Of course that makes sense!" 21:06
Tene allison: all I'd ask is that the API uses "return" and "result" consistently.
allison Tene: agreed, that would help
21:06 diakopter left
allison Tene: please to fix it where you find inconsistencies 21:06
do
Tene Well, i"ll look into it after I get this working.
Maybe add it to the tasklist? 21:07
allison Tene: sure
Tene afk working
allison: just to confirm, fill_results should be iterating over returns, or over results? 21:11
allison Tene: it should be iterating over returns
whiteknight ...which one is which?
Tene Okay.
allison Tene: parallel to fill_params which iterates over args
Tene whiteknight: returns are the ones you specify with .return ()
dalek tracwiki: v20 | allison++ | CallingConventionsOverview
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqff6
allison whiteknight: returns==args, results==params 21:12
Tene allison: new fill_params or old fill_params? ;)
allison whiteknight: returns/args=="what you dump in" and results/params=="what you get out"
whiteknight gotcha
allison Tene: the new fill_params is the one that iterates over args 21:13
Tene: it's saner that way
Tene s/what you get out/where they end up/
whiteknight I'm thinking that maybe we should find a way to store strings like error messages externally to the code
allison Tene: easier to check
Tene allison: Okay. I somehow got a bit confused last night.
allison whiteknight: yes, we have to for internationalization
whiteknight exactly.
also could help to make error-checking tests more sane 21:14
allison whiteknight: there are plenty of examples out there of people who have already done this
Tene strongly recommends something like Locale::MakeText over gettext
allison Tene: what's the linux kernel use?
Tene allison: enoclue
allison looks like gettext 21:15
Tene allison: getting things like pluralization right over n languages tends to hugely explode the string count, I'm told.
21:15 kurahaupo joined
Tene it's worth reading the POd for Locale::MakeText. It was very persuasive to me. I have no experience here, though. 21:16
allison Tene: I think Ubuntu has tools that make the pluralization problem easier
Rosetta? 21:17
purl rumour has it Rosetta is at bhami.com/rosetta.html or what happens when you have a military level budget and get paid by lines of code or dduncan's thingy or a dual perl 6 effort
allison Tene: but it's pretty much unexplored territory for me too 21:20
whiteknight allison: I do some MediaWiki hacking too, and everything they do is i18n compatible 21:22
what is 'f' in a signature, :flat? 21:23
Ryan52 allison: here's my "svn diff" slexy.org/raw/s2juysTJm9 . the standards version, homepage, and passive ftp changes should probably be caried over into future debian packages of parrot. 21:24
allison: okay for me to upload it?
whiteknight yeah, 'f' is :flat (answered my own question) 21:25
bacek Good morning 21:27
GeJ G'Day bacek
bacek G'Day GeJ 21:28
whiteknight good morning GeJ
and hello again, bacek
GeJ Heya whiteknight
purl whiteknight is mailto:wknight8111@gmail.com or the grand master funk or wknight8111.blogspot.com/
whiteknight allison: issue in multidispatch. an incoming :flat array has a signature "Pf" instead of signatures of each of it's component objects 21:29
dalek rrot: r41712 | bacek++ | branches/pcc_reapply/src/nci_test.c:
[cage] Properly fix nci_test.
 21:31
whiteknight has to look into trunk to see how it's handled there 21:34
21:35 kid51 joined
allison whiteknight: yes, I saw that failing test 21:37
dalek TT #1058 closed by jkeenan++: auto::funcptr: config step not needed if 'jitcapable' is never true 21:38
allison whiteknight: I'm hesitant to change the signature string stored in the CallSignature, it seems like it's losing information
whiteknight it's losing information because we're marking "Pf" or because we arent? 21:39
allison whiteknight: but then, I suppose it doesn't really matter that the positional or named arguments originally came from a flat argument, since they're regular positional and named arguments in the call signature
whiteknight: losing information because we replace the Pf with the individual signatures of the elements it's flattened into 21:40
whiteknight I'm fine either way, the only issue is whether we dissect out the signature in the CallSignature element, or whether we only do it when mutidispatching
allison whiteknight: so we lose track of the fact that it was originally a :flatten argument
whiteknight: it's easy to do it in the call signature, we re-write it as we flatten 21:41
whiteknight allison: What if instead of having "Pf" for the flattened array, we add an "f" to every inner argument that was part of that array?
allison whiteknight: it's hard to do it in multidispatch, because we've lost the information about what it flattened into
whiteknight so "Pf" -> "IfSnfPf"
allison whiteknight: it does keep some information, but there would be no way to tell when multiple args were flattened 21:42
whiteknight actually it would only flatten to "PfPfPf..."
allison: working backwards, what's the benefit to having that information in the first place?
allison whiteknight: PfPf might flatten to any number of args 21:43
whiteknight what do you mean?
allison whiteknight: very little benefit
whiteknight: you can pass in more than one flattening argument
so, two arrays, or 4 arrays and 5 hashes
an infinite number of flattening arguments 21:44
whiteknight allison: okay, but still ignores the question: Why would a callee ever need to know that it was called with a flattened array instead of a regular arglist
allison they're all steamrolled
whiteknight is this information that is worth keeping?
allison whiteknight: not really, no
whiteknight: it's just a packrat principle
whiteknight: go ahead and rewrite
whiteknight: we can always find some way to retain the information of we need it someday 21:45
whiteknight: but no reason to keep it at the moment
whiteknight something like "Pf{...}" would do the trick
but yes, something for the future
allison whiteknight: yeah, there are ways to do it, if we find we do need the information
whiteknight what does the arglist flatten to, all Ps? 21:48
(for arrays)
Ryan52 allison: ?? 21:50
Tene allison: The returns aren't stored in the call_object, like they are for args, so i can't use vtable_elements to get the number of positional params... should I just loop over the returns_sig and count the number of non_named returns? 21:51
allison Tene: just grab the returns array out of the call object 21:53
Tene allison: the 'returns' attribute of the call object is the *results* 21:54
allison Tene: oh, yes, for the iteration in fill_returns, loop over the signature
the return signature
i.e. the fixed integer array
Ryan52: yes?
Ryan52 14:24 < Ryan52> allison: here's my "svn diff" slexy.org/raw/s2juysTJm9 . the standards version, homepage, and passive ftp changes should probably be caried over into future debian packages of parrot.
14:24 < Ryan52> allison: okay for me to upload it? 21:55
allison: u never answered or acknowledged that I asked.
allison Ryan52: looks good, go ahead 21:56
Ryan52: (I didn't see the earlier message)
Ryan52 kk, thanks.
whiteknight make headerizer spits out a lot of warnings in the branch 21:59
allison whiteknight: it's all the function pointer definitions 22:00
whiteknight: they don't have the standard declarations 22:01
dalek rrot: r41713 | whiteknight++ | branches/pcc_reapply (3 files):
[pcc] change handling of :flat args in the CallSignature so that the contents of the :flat array are reprsented in the signature, instead of just saying 'Pf'. t/pmc/multisub.t passes completely now, don't know if anything else got fixed
allison whiteknight: that is src/call/args.c
whiteknight what is? 22:03
allison whiteknight: the headerizer complaints are about src/call/args.c
whiteknight oh, okay
allison sleeps 22:06
dalek ose: r175 | Austin++ | trunk/ (3 files):
Moved src/parser -> src/Slam/parser
 22:18
kudo: 42ed85a | (Lanny Ripple)++ | src/setting/Num.pm:
add a cast for Num to Rat with optional error
 22:20
kudo: 1ca164a | (Solomon Foster)++ | src/setting/Num.pm:
Change Num._modf to "my" to make it private.
shorten dalek's url is at xrl.us/bfqfoj
purl dalek: that doesn't look right
shorten dalek's url is at xrl.us/bfqfom
dalek rrot: r41714 | bacek++ | branches/pcc_reapply/src/call/pcc.c:
Runops for Eval PMC in invoke_from_sig_object. Fixes t/src/embed.t
 22:24
ose: r176 | Austin++ | trunk/ (23 files):
Moved *Visitors into subdir, fixed Makefile.in
 22:32
whiteknight this weekend has been very productive 22:33
bacek Anyone working on fill_returns? 22:36
whiteknight Tene was, I think
bacek Tene: any luck? 22:37
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply branch: --buildframes=0: current failures verbose output" (1474 lines) at nopaste.snit.ch/18217 22:39
dalek rrot: r41715 | whiteknight++ | branches/pcc_reapply/src/call/args.c:
[pcc] add PARROT_CAN[NOT]_RETURN_NULL to some functions in src/call/args.c. This shuts up some warnings in headerizer
 22:40
whiteknight why does stringhandle.t take so damn long to run? 22:41
Tene bacek: yes, making progress 22:43
bacek: I have nomral positional returns and slurpy returns working.
bacek Tene: good.
Tene bacek: I probably have to stop working soon... will you be around to finish it? 22:44
bacek Tene: I can try. It's public holiday in Australia. 22:45
whiteknight Tene: commit what you have when you leave, we will carry on 22:47
dalek rrot: r41716 | jkeenan++ | branches/library_files/config (2 files):
Make lists of tests defined in Parrot::Harness::DefaultTests available to Makefile. Add them to Parrot::Configure object in config/init/defaults.pm, then modify make targets in config/gen/makefiles/root.in. Cf.: trac.parrot.org/parrot/ticket/1061.
nopaste "tene" at 24.10.252.130 pasted "The work so far on fill_params, fwiw" (662 lines) at nopaste.snit.ch/18218
whiteknight wow, that's a lot 22:48
once we get slurpy and named returns working, I have very high hopes that PCT will build
Tene whiteknight: yes, PGE is failing on slurpy returns ATM 22:49
kid51 pcc_reapply branch: *Without* --buildframes=0, t/op/gc.t continues to hang indefinitely for me during 'make coretest', thereby preventing me from submitting Smolder. This is on Linux/i386.
Running it with 'prove -v', I end up with: 22:50
ok 115 - end vanishing_return_continuation
ok 116
ok 117
Failed 23/140 subtests
Test Summary Report
-------------------
t/op/gc.t (Wstat: 11 Tests: 117 Failed: 0)
Non-zero wait status: 11
Parse errors: Bad plan. You planned 140 tests but ran 117.
Files=1, Tests=117, 4 wallclock secs ( 0.06 usr 0.00 sys + 1.09 cusr 0.06 csys = 1.21 CPU) 22:51
Result: FAIL
perl t/harness t/op/gc.t fails at test 118, but the harness completes as intended.
So why should 'make smolder_coretest' -- which just wraps around t/harness -- cause t/op/gc.t to hang? 22:54
whiteknight that's weird 22:57
GeJ bacek: r41712 says "Properly fix nci_test." Should I remove it from CallingConventionsOverview's "Known Issues" list? 22:58
22:58 patspam joined
bacek GeJ: look like yes 22:58
dalek tracwiki: v21 | geraud++ | CallingConventionsOverview 23:01
tracwiki: With bacek's confirmation on IRC, remove nci known issue.
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqfsw
GeJ bacek++
cotto I see there's been a bunch of pcc hacking. How much closer is the pcc_reapply branch to being mergeable? 23:06
dalek rrot: r41717 | bacek++ | branches/pcc_reapply/src/call/args.c:
Clone Key args in fill_params. Stolen from old PCC.
 23:07
kid51 $ ps aux | grep 't/op/gc.t'
jimk 6453 8.2 71.5 457704 254884 pts/0 D+ 19:03 0:14 parrot t/op/gc.t
It's eating up memory, I guess.
bacek cotto: before Christmas :) 23:08
whiteknight cotto: we've fixed A LOT of failing tests
still a handfull, but a lot less then there was
and Tene is doing some work on returns that should get us most of the way down to 0 23:09
bacek bloody headerizer... 23:10
cotto I'm disappointed not to have had the free time, but you all committed some serious pwnage.
Tene Looks like I'm getting an assertion failure in Parrot_pcc_build_sig_object_returns_from_op when I try to define named returns.
(a :named('a'), b :named('b')) = foo() 23:11
cotto Whatever else is true, that code has a much better bus number now. 23:12
Tene So I'm having trouble testing if fill_results handles named returns
cotto afk
dalek rrot: r41718 | bacek++ | branches/pcc_reapply/src/call/args.c:
Make headerizer happy.
 23:13
rrot: r41719 | jkeenan++ | branches/library_files/config/gen/makefiles/root.in:
Correct trailing whitespace codingstd error.
rrot: r41720 | bacek++ | branches/pcc_reapply (2 files):
Fix ARGMOD guard in fill_returns_from_op
whiteknight Tene: commit it and let us do some debuggering 23:14
kid51 pwnage? 23:15
whiteknight kid51: pwnage is when we kick ass and take names. 23:16
kid51 Having looked up pwnage on urbandictionary.com .. 23:19
kid51 vows never to use it.
23:20 theory joined
Tene whiteknight: okay, about to commit. Then I need to go grocery shopping. 23:21
kid51 How strange! Something in the last two commits to pcc_reapply cleared up that hang in t/op/gc.t for me!
23:21 payload joined
whiteknight Tene: awesome 23:22
kid51: probably some weird heisenbug thing
or something that is dependent on memory layout
kid51 No, I take that back.
I configured with --buildframes=0. 23:23
Tene Yay, headerizer conflicts when trying to update so I can commit.
kid51 In fact, the situation has gotten worse. r41714: 37 tests failed; r41720: 78 failures!
many failures in \t t/pmc/exporter.t (again) 23:25
And new failures in t/pmc/key.t
whiteknight urg 23:26
kid51 and new failures in t/pmc/packfile.t
smolder.plusthree.com/app/public_pr...ails/28565 23:27
shorten kid51's url is at xrl.us/bfqfvc
Tene kid51: the commit I'm about to make is going to break a *lot* of things. It's still in-progress, but I need to leave for the night.
whiteknight yeah, it's a work in progress 23:28
nopaste "kid51" at 70.85.31.226 pasted "diff of last 3 commits -- which caused more tests to fail" (536 lines) at nopaste.snit.ch/18219 23:29
dalek rrot: r41721 | tene++ | branches/pcc_reapply/src/call/args.c:
[pcc] The start of the fill_results refactor. Doesn't work well yet.
kid51 throws up his hands and goes for beer. 23:30
Tene whiteknight: the next item that I noticed was broken was that when returning int constants, the int is stored directly in the raw_params array, so the intval_constant_from_op that' sused for fill_params doesn't work for fill_returns. We need an intval_constant_from_op_for_results.
if you look at icfo, you see it fetches a raw_index and then calls some pcc function? in the _results version, just return the raw_index. 23:31
whiteknight ok
holy crap Tene! You said it would break a lot of tests, not ALL of them 23:34
23:35 davidfetter joined
Tene whiteknight: what do you expect for a half-implemented fill_returns? 23:35
whiteknight haha, nice!
Tene afk 23:36
I would have put it in a branch, but... 23:40
bacek finally lost in over-complicated logic of fill_foo... 23:44
23:52 TonyC joined 23:59 rhr joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!