Camelia, the Perl 6 bug

IRC log for #parrot, 2009-10-04

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:02 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
00:02 allison bacek: yes, it should and does
00:03 bacek allison: not in branch...
00:03 bacek t/pmc/string.........................1/171 Unable to set PMC value, the pointer is not a PMC
00:03 dalek tracwiki: v8 | allison++ | CallingConventionsOverview
00:03 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingC​onventionsOverview?version=8&action=diff
00:03 shorten dalek's url is at http://xrl.us/bfqb6f
00:03 bacek t/pmc/resizablestringarray...........1/261 Unable to set PMC value, the pointer is not a PMC
00:03 bacek current instr.: 'method_pop_string' pc 6072 (t/pmc/resizablestringarray.t:1529)
00:03 bacek called from Sub 'main' pc 362 (t/pmc/resizablestringarray.t:77)
00:03 allison Tene: I'm working my way through the tests to triage the failures
00:03 bacek this one
00:03 purl it has been said that this one is bugged too now
00:04 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
00:08 kid51 r 41653 cleared up 26 tests; 652 to go!
00:09 dalek tracwiki: v9 | allison++ | CallingConventionsOverview
00:10 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingC​onventionsOverview?version=9&action=diff
00:10 shorten dalek's url is at http://xrl.us/bfqb6y
00:10 allison bacek: those failures might be in the return handling code rather than the calling code, it is more primitive
00:11 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
00:12 kid51 smolder at r41658:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28498
00:12 shorten kid51's url is at http://xrl.us/bfqb64
00:14 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
00:14 kurahaupo ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir  --output=PGE/builtins_gen.pir PGE/builtins.pg
00:14 bacek kurahaupo: r41658 isn't trunk...
00:15 kurahaupo (That's just my output from "svn up")
00:16 kurahaupo bacek: shall we just say "svn HEAD as of 30 seconds ago"
00:17 bacek kurahaupo: you sure that your svn checkout is trunk, not pcc_reapply branch?
00:18 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
00:18 kid51 t/pmc/nci.t; t/pmc/float.t; t/pmc/bigint.t
00:18 kurahaupo bacek: sorry, cut-and-paste error
00:19 kurahaupo bacek: svn info . says URL: https://svn.parrot.org/parrot/trunk
00:19 kid51 kurahaupo:  In pcc_reapply branch, we're only currently concerned with 'make corevm' and 'make coretest'
00:20 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
00:20 kid51 t/pmc/objects.t also has that 722 src/call/pcc.c error
00:20 kurahaupo AFAIK svn will report the highest revision in any branch
00:21 Wolong_ joined #parrot
00:21 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)
00:22 dalek tracwiki: v10 | allison++ | CallingConventionsOverview
00:22 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=10&action=diff
00:22 shorten dalek's url is at http://xrl.us/bfqb77
00:23 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
00:23 kid51 kurahaupo:  No, make realclean is as strong as it gets
00:23 purl okay, kid51.
00:25 Tene allison: would you rather have me work on the mmd issues, or set_returns?
00:26 kid51 allison: 'st->':  Are you referring to .t files? .pmc? .c?
00:27 kid51 Another frequently observed error message in the TAP is:  Unable to set PMC value, the pointer is not a PMC
00:31 * kurahaupo crawls under a rock... build problem has vanished
00:32 nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: '.c' files still holding 'st->'" (25 lines) at http://nopaste.snit.ch/18196
00:37 allison Tene: whichever you'd rather work on
00:38 allison Tene: I've put a full triage of all remaining failing tests up on the wiki https://trac.parrot.org/parrot/​wiki/CallingConventionsOverview
00:38 shorten allison's url is at http://xrl.us/bfqb9p
00:38 * Whiteknight backlogs
00:39 dalek tracwiki: v11 | allison++ | CallingConventionsOverview
00:39 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=11&action=diff
00:39 shorten dalek's url is at http://xrl.us/bfqb9r
00:39 dalek tracwiki: v12 | jkeenan++ | CallingConventionsOverview
00:39 dalek tracwiki: minor spelling correction
00:39 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=12&action=diff
00:39 shorten dalek's url is at http://xrl.us/bfqb9t
00:39 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
00:40 kid51 Let me see if I can refine the grep
00:40 kid51 Your suspicions are correct.
00:40 allison okay, bigint.c is actually "bi_dest->"
00:41 quek left #parrot
00:41 payload joined #parrot
00:41 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
00:42 dalek tracwiki: v13 | jkeenan++ | CallingConventionsOverview
00:42 dalek tracwiki: Turn text into subhead
00:42 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=13&action=diff
00:42 shorten dalek's url is at http://xrl.us/bfqb97
00:45 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 http://nopaste.snit.ch/18197
00:46 nopaste "bacek" at 110.175.160.228 pasted "Improve CPointer." (24 lines) at http://nopaste.snit.ch/18198
00:47 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
00:49 allison bacek: that's a good place to put the casting code
00:49 allison bacek: though, the translation isn't as obvious for string to int/num or int/num to string
00:50 allison 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?
00:51 allison bacek: you can't cast a string to a number
00:51 allison bacek: it translates to garbage
00:51 bacek allison: I mean Parrot_str_to_num
00:51 bacek not "plain C cast"
00:52 allison bacek: yes, that's fine
00:53 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
00:53 bacek allison: ok
00:56 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" :)
00:57 allison bacek: you can just set it based on the return_flag type and let CPointer handle the rest
00:57 allison bacek: aye
00:57 allison Tene: do you have enough bits to work on from the wiki?
00:57 allison Tene: it's 2am here, so I'm headed off for some sleep
00:58 dalek tracwiki: v14 | whiteknight++ | CallingConventionsOverview
00:58 dalek tracwiki: post outlines for argument processing algorithms, for reference.
00:58 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=14&action=diff
00:58 shorten dalek's url is at http://xrl.us/bfqccu
00:58 kurahaupo g'nite allison
00:59 Tene allison: goodnight
00:59 Whiteknight in that case, we should probably rename CPointer to something like ArgPointer
01:00 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:01 * allison sleeps
01:02 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:03 Whiteknight but that's neither here nor there
01:03 TiMBuS joined #parrot
01:04 jrtayloriv Whiteknight, Did you notice that Peter Lobsinger was on earlier asking about his libJIT work?
01:04 rhr joined #parrot
01:05 jrtayloriv (Just making sure that he doesn't feel completely warnocked)
01:06 jrtayloriv he popped in for a moment saying: 16:53 <plobsing> i am interested in adding the libjit nci changes I have at http://github.com/plobsing/parrot-libjit
01:06 jrtayloriv And then no-one responded.
01:07 jrtayloriv (because everyone was very busy at the time with the hack frenzy, they just might not have noticed)
01:09 dalek parrot: r41659 | mikehh++ | branches/pcc_reapply/src/extend.c:
01:09 kid51 jrtayloriv:  Is there any way you could paste a patch of the important stuff in his work?
01:09 dalek parrot: codetest failure - trailing spaces
01:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41659/
01:09 dalek parrot: r41660 | bacek++ | branches/pcc_reapply/src/pmc/cpointer.pmc:
01:09 dalek parrot: Revamp CPointer casting to DTRT.
01:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41660/
01:09 TiMBuS i could probably write those NCI routines in C/asm whiteknight was talking about, if nobody ended up doing that..
01:11 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:16 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?
01:17 mikehh Tene: yes if you like
01:17 mikehh aparently MS C don't like
01:18 Tene nodnod
01:19 mikehh altho' why any reasonably modern C compiler doesn't accept C++ style comments is beyond me
01:20 mikehh I mean C99 is 10 years ago
01:21 mikehh and c90 is nearly 20
01:21 mikehh may as well use K&R
01:22 Tene srsly
01:22 bacek mikehh: "C++ comments" are markers where I cut corners.
01:23 bacek 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
01:23 bacek mikehh: you can replace comments but put some other easy-to-find marker.
01:25 mikehh ok will do - how about /*++ or /*-- any preferences?
01:27 bacek "/* XXX FIXME" :)
01:27 patspam joined #parrot
01:28 dalek parrot: r41661 | bacek++ | branches/pcc_reapply/src/call/args.c:
01:28 dalek parrot: Simplify fill_returns functions values handling. CPointer will cast values by it self.
01:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41661/
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)
01:29 mikehh 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 http://nopaste.snit.ch/18199
01:38 dalek parrot: r41662 | bacek++ | branches/pcc_reapply/src/call/args.c:
01:38 dalek parrot: Fix handling of null CallSignature and "returns"
01:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41662/
01:41 dalek parrot: r41663 | mikehh++ | branches/pcc_reapply/src/frame_builder.c:
01:41 dalek parrot: replace C++ style comments with /* XXX FIXME ... */
01:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41663/
01:41 dalek TT #1089 created by kurahaupo++: rewrite tests for resizableintegerarray as PIR, plus add new tests
01:44 kurahaupo joined #parrot
01:45 kid51_at_dinner Between 41558 and 41660 we cleaned up another 79 tests
01:45 mokurai joined #parrot
01:47 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 http://github.com/plobsing/parrot-libjit
01:48 kid51 msg plobsing Re libjit nci changes:  Can you prepare patch and open up a Trac ticket?
01:48 purl Message for plobsing stored.
01:48 bacek kid51: how many failing tests to you have?
01:49 kid51 There were 480 in branch at r41660 -- but I am re-testing with svn up now
01:49 kid51 r41660:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28500
01:49 shorten kid51's url is at http://xrl.us/bfqci2
01:51 kid51 r41663: still at 480 to go
01:52 kid51 http://smolder.plusthree.com/app/pu​blic_projects/report_details/28501
01:52 shorten kid51's url is at http://xrl.us/bfqcje
01:53 bacek kid51: is it with --buildframes=0?
01:55 kid51 No.
01:55 kid51 Why should I add that?  (Am trying to test exactly as I do in trunk)
01:57 dalek parrot: r41664 | mikehh++ | branches/pcc_reapply/src/call/args.c:
01:57 dalek parrot: fix svn properties
01:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41664/
01:59 bacek kid51: framebuilder is badly broken. It's leftover from JIT...
02:04 dalek parrot: r41665 | mikehh++ | branches/pcc_reapply/src/pmc/cpointer.pmc:
02:04 dalek parrot: codetest failure - trailing spaces
02:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41665/
02:06 Tene mmd isn't working out so well for me.  Working on return args instead.
02:07 kid51 bacek:  You are correct.  with --buildframes=0 the number of failing tests falls to 160:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28503
02:07 shorten kid51's url is at http://xrl.us/bfqckw
02:08 bacek kid51: of course I am. I broke it :)
02:08 bacek hmm... I can't connect to smolder...
02:10 dalek parrot: r41666 | bacek++ | branches/pcc_reapply/src/pmc/continuation.pmc:
02:11 dalek parrot: Comment-out old-style param passing in Continuation.
02:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41666/
02:11 dalek parrot: r41667 | bacek++ | branches/pcc_reapply/src/frame_builder.c:
02:11 dalek parrot: Remove more old param passing stuff from frame_builder.
02:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41667/
02:11 dalek parrot: r41668 | bacek++ | branches/pcc_reapply/src/exceptions.c:
02:11 dalek parrot: Remove unused pass_exception_ars function
02:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41668/
02:11 dalek parrot: r41669 | bacek++ | branches/pcc_reapply (2 files):
02:11 dalek parrot: Rerun headerizer
02:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41669/
02:11 dalek parrot: r41670 | bacek++ | branches/pcc_reapply (2 files):
02:11 dalek parrot: Old PCC is dead-dead-dead. Remove last functions.
02:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41670/
02:13 bacek ok.
02:13 bacek afk # have to make lunch for kids
02:27 quek joined #parrot
02:27 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:29 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.
02:30 mikehh kid51: just checking and reportin' at the moment
02:30 kid51 ok
02:31 kid51 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 kid51 So now I'm doing 'make smolder_coretest'
02:32 mikehh kid51: sure - but I check every so often to see where we are - previously we got past src/glut_callbacks.c
02:35 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
02:36 mikehh 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?
02:38 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')
02:39 mikehh as part of my normal testing I run something like -> make world 2>&1 | tee make_world.41670.g++.amd64.log
02:39 mikehh dropping the g++ if I use gcc and of course i386 if I am on that platform
02:41 * kid51 is not very familiar with 'make world'
02:41 cognominal joined #parrot
02:41 mikehh it does a normal make and adds the tools build
02:43 mikehh world:             'all' and 'parrot_utils'."
02:45 mikehh -> world : all parrot_utils -> parrot_utils : $(PDUMP) $(DIS) $(PDB) $(PBCMERGE) $(PBC_TO_EXE) $(PARROT_CONFIG)
02:48 janus joined #parrot
02:55 mikehh come to think of it I haven't tested trunk recently I think we have had 1 commit there - let me check
02:57 kid51 Well, in pcc_reapply branch, I am still not getting all the way through 'make'.
02:59 nopaste "kid51" at 70.85.31.226 pasted "Excerpt from 'make' failure in pcc_reapply branch" (31 lines) at http://nopaste.snit.ch/18201
03:01 * kid51 must sleep
03:01 purl $kid51->sleep(8 * 3600);
03:03 dalek parrot: r41671 | bacek++ | branches/pcc_reapply/config/gen/opengl.pm:
03:03 dalek parrot: Replace runops..._event with invoke_sub in glut callbacks.
03:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41671/
03:07 dalek tracwiki: v15 | bacek++ | CallingConventionsOverview
03:07 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=15&amp;action=diff
03:07 shorten dalek's url is at http://xrl.us/bfqcqv
03:20 mikehh The following applies to trunk
03:20 mikehh All tests PASS (pre/post-config, smoke (#28505), fulltest) at r41670 - Ubuntu 9.04 amd64
03:25 plobsing_ joined #parrot
03:31 plobsing joined #parrot
03:32 mikehh partcl r775 builds on parrot r41670 - make test PASS (smolder #28506) - ubuntu 9.04 amd64
03:43 mikehh rakudo (e976f23) builds on parrot r41670 - make test PASS / make spectest_smolder (up to r28584 -> #28507) FAIL - Ubuntu 9.04 amd64
03:43 mikehh rakudo - t/spec/S11-modules/nested.t - Parse errors: Bad plan.  You planned 6 tests but ran 5
03:43 mikehh rakudo - t/spec/S32-num/rat.t - Parse errors: No plan found in TAP output
03:50 mikehh ok - one last run on the pcc_reapply branch
03:58 mikehh 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 mikehh codetest ->
03:59 mikehh # unused assert macros found:
03:59 mikehh # /home/mhh/pcc_reapply/src/call/ops.c: runops_args
03:59 mikehh # 1 unused assert macros found in total.
03:59 mikehh passes the rest of codetest
04:00 * mikehh seriously needs a nap or something
04:00 mikehh bbl
04:40 cconstantine joined #parrot
04:47 dalek parrot: r41672 | bacek++ | branches/pcc_reapply/src/call/args.c:
04:47 dalek parrot: Generalise Parrot_pcc_fill_params functions:
04:47 dalek parrot: - Implement bunch of small helper functions to fetch values from op or
04:47 dalek parrot:   va_list
04:47 dalek parrot: - Create generic fill_params function.
04:47 dalek parrot: - Switch _from_op and _from_c_args functions to use generic one.
04:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41672/
04:48 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 #parrot
05:34 szabgab joined #parrot
05:37 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.
06:15 Tene japhb: great
06:29 bacek joined #parrot
06:34 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 #parrot
07:02 allison joined #parrot
07:08 dalek TT #1090 created by kurahaupo++: Convert t/pmc/exporter.t to PIR
07:08 Tene allison: Hi. :)
07:09 Tene 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:19 Tene Looks like it has some problems... causes a failure in t/oo/composition.t
07:22 allison Tene: hi
07:22 dukeleto hola
07:22 purl salut, dukeleto.
07:22 * allison looking
07:23 dukeleto what can I do to help the pcc_reapply effort ?
07:24 allison dukeleto: failing tests are grouped by cause of failure on https://trac.parrot.org/parrot/​wiki/CallingConventionsOverview
07:24 shorten allison's url is at http://xrl.us/bfqb9p
07:25 allison dukeleto: looks like we've picked off the really obvious ones
07:28 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:29 Tene iirc
07:30 dukeleto ok, i will check out the tests
07:31 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:33 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.
07:33 allison Tene: will dig in and see if I can track down the failures
07:33 Tene and that should help a lot.
07:34 Tene I'm seeing it demonstrated in t/oo/composition.t
07:34 allison yes
07:34 allison though, you'll have to use a different set of function pointers
07:38 nopaste "tene" at 24.10.252.130 pasted "minimal pir to reproduce problem for allison++" (10 lines) at http://nopaste.snit.ch/18202
07:42 dukeleto hmmm, miniparrot does not compile for me
07:42 Tene dukeleto: what failure?
07:42 purl failure is probably not an option
07:43 nopaste "dukeleto" at 69.64.235.54 pasted "miniparrot compile error" (7 lines) at http://nopaste.snit.ch/18203
07:44 dukeleto why does the miniparrot compilation have an -lparrot flag?
07:44 allison Tene: what failure are you getting?
07:44 Tene named parameters must follow all positional parameters
07:45 allison I was just going to paste that :)
07:45 allison ok
07:45 allison so, it's a logic problem, not a mysterious segfault, that's nice :)
07:45 Tene allison: specifically, it's the *second* named params must follow..., on line 848
07:47 Tene Yeah, it shouldn't be too bad, I'm just... not all here right now.
07:47 Tene Long weird day.
07:54 Tene allison: looks like param_name is empty.
07:54 Tene oh, nevermind.
07:54 Tene That was a lie.
07:54 Tene It happens when processing the second named optional.  The first named optional goes through fine.
07:55 allison Tene: makes sense, I'm soaking in the new code at the moment
07:56 Tene Ah, okay, here we go.
07:56 Tene When processing the second named optional that isn't present, it tries to fall back to positional.
07:56 kjeldahl joined #parrot
07:57 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:59 allison Tene: it doesn't check when there are no more parameters
08:00 allison Tene: that is, it works just fine if you pass a 'doom' argument
08:01 Tene allison: that's right.  it only fails when there's no argument to the named.
08:02 Tene Ah, I know...
08:03 nopaste "tene" at 24.10.252.130 pasted "fixes the problem for allison++" (22 lines) at http://nopaste.snit.ch/18204
08:03 Tene lemme run a coretest, just to check...
08:04 dalek parrot: r41673 | allison++ | branches/pcc_reapply/src/call/args.c:
08:04 dalek parrot: [pcc] Clean up some names in the new function pointers to make the code easier
08:04 dalek parrot: to follow.
08:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41673/
08:05 Tene Much nicer. :)
08:07 dalek parrot: r41674 | tene++ | branches/pcc_reapply/src/call/args.c:
08:07 dalek parrot: [pcc] Fix small logic bug in fill_params
08:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41674/
08:09 Tene allison: curious about why you wanted to avoid function pointers.
08:11 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.
08:11 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
08:12 allison have you tested that it still catches an actual positional argument in the middle of named arguments?
08:13 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:14 Tene 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
08:14 Tene Ah.  That's unfortunate.
08:14 Tene Parrot is the only C codebase I've done any amount of work with.
08:15 Tene I did some C back in school in like 2000 or so, and then not much until I came to Parrot.
08:16 allison Tene: but, that does leave me unfairly prejudiced
08:17 allison Tene: function pointers used with a limited and clear scope can be beneficial
08:17 dalek parrot: r41675 | allison++ | branches/pcc_reapply/src/call/args.c:
08:17 dalek parrot: [pcc] More naming cleanup for maintenance sanity.
08:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41675/
08:19 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:20 allison Tene: eventually they'll be the same codepath
08:20 allison Tene: but at the moment, they're two different paths
08:20 allison Tene: because unfortunately, at some point someone reversed the order of the opcode calls
08:21 allison so, you call set_args then get_params
08:21 Tene ah
08:21 allison but on returns you call get_results then set_returns
08:22 allison instead of set_returns and then get_results
08:22 dukeleto oy vey
08:22 allison so, the logic is backwards
08:22 allison you're fetching before you've set
08:23 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
08:23 Tene when is it we're planning on changing that?
08:24 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 parrot: r41676 | dukeleto++ | trunk/t/pmc (2 files):
08:24 dalek parrot: [t] Convert some exception tests to PIR
08:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41676/
08:24 iblechbot joined #parrot
08:24 allison Tene: it changes interface, so needs a deprecation cycle
08:25 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
08:26 allison Tene: we might be able to use the function pointers in build_sig_object too
08:29 quek joined #parrot
08:30 dukeleto it seems that miniparrot requires an installed parrot on the pcc_reapply branch. how can I fix that?
08:30 dukeleto are we creating TT's for pcc_reapply bugs?
08:33 allison dukeleto: no, they're in a branch
08:33 allison dukeleto: just add any reports to the wiki page
08:33 dukeleto allison: gotcha
08:34 allison Tene: ooh, here's the deeper problem, src/call/args.c:842
08:34 Tene allison: that's a problem?
08:34 allison Tene: when it doesn't find the coresponding named argument for the named parameter, it just drops through to positional handling
08:34 allison Tene: that's wrong
08:34 purl allison is channeling thoth!
08:35 Tene allison: it's not supposed to do that?
08:36 Tene 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
08:36 Tene "as a default"?
08:36 allison but only if no other named arguments have been used
08:37 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
08:37 Tene But if it's already filled one named param with a named arg, it should fail instead?
08:38 allison yes
08:38 allison going back to check the PDD to make sure we get the logic straight
08:38 dalek tracwiki: v16 | dukeleto++ | CallingConventionsOverview
08:38 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=16&amp;action=diff
08:38 shorten dalek's url is at http://xrl.us/bfqddj
08:38 Tene if (named_count == 0) { param_name = NULL; continue; } else { Parrot_ex_throw_from_c_args(...) }
08:39 Tene is what you want in that case.
08:39 Tene Wait, hmm, no...
08:40 Tene You also need to look at whether the named param was optional or not.
08:40 Tene if it's not optional, die with the right message
08:41 Tene 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
08:41 Tene dukeleto: does the miniparrot compile if you just copy/paste the command it's trying, but omit -lparrot ?
08:41 allison dukeleto: and does it compile if you run realclean and re-run Configure.pl?
08:41 Tene allison: if you determine it, please add a test for it.
08:43 allison Tene: Named targets can be filled with either positional or named values.
08:43 allison However, if a named target was already filled by a positional value, and
08:43 allison then a named value is also given, this is an overflow error.
08:43 allison Tene: (quote from the PDD)
08:44 allison Tene: so this says "try to fill it with a positional first, then try to fill it with a named"
08:45 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"
08:45 allison Tene: yes, it would require using the logic Whiteknight and I drafted last night instead of the current logic
08:45 Tene Ah, I missed that.
08:46 Tene Oh, no, I saw it on the wiki.
08:47 Tene allison: fill_params and fill_returns should have different error messages, too.
08:48 Tene allison: advice on how you'd like that handled?  "param" vs "return" passed in as a string argument, maybe?
08:50 allison Tene: for now, it means you'll need separate functions for fill_params and fill_returns
08:50 allison Tene: but you can use the same accessor function pointers inside each
08:50 allison Tene: (you'll need separate functions anyway, because the logic is entirely different)
08:52 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:53 dalek parrot: r41677 | dukeleto++ | branches/pcc_reapply/t/op/calling.t:
08:53 dalek parrot: [pcc_reapply][t] Fix some tests in t/op/calling.t that now throw slightly different error messages
08:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41677/
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
08:54 allison 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.
08:55 Tene 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
08:55 allison getters
08:55 allison Tene: essentially, everywhere you see 'VTABLE_set_integer_native(interp, result_item, CTX_REG_INT(ctx, raw_index))'
08:56 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))
08:56 Tene yeah
08:57 allison Tene: that way we don't need a custom set of function pointers for fill_returns
08:57 allison Tene: better to use the same ones
08:57 allison Tene: I see some macros coming on here
08:58 Tene allison: &REG_INT is the same thing as CTX_REG_INT ?
08:58 allison PCC_SET_INTVAL, or something like that
08:58 allison Tene: yes, one is a macro, the other is a pointer
08:58 Tene Ah.
09:00 Tene Ah, they're the identical, except the version that only takes an interp fetches the ctx from the interp.
09:00 Tene and the version that only takes a context just assumes the interp is named 'interp'
09:00 Tene Okay, I get it now.
09:02 Tene 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:03 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 Tene ;)
09:07 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:08 allison Tene: but, you can fix it as you go
09:08 Tene allison: in the way that we just talked about?
09:08 allison Tene: yes
09:08 allison I'm about to flip the logic of fill_params to iterate over arguments, as on the wiki page
09:09 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
09:09 allison (because the logic is reversed in the two)
09:10 allison Tene: yes, I'll keep the same arguments to fill_params
09:10 Tene allison: returns is supposed to use 'iterate over arguments' ?
09:10 allison Tene: return arguments
09:10 Tene right
09:11 allison Tene: that is, what's passed in from 'set_returns'
09:11 Tene I've been using arg:param::return:result
09:11 allison Tene: that's what the code currently uses too
09:12 allison (will likely continue using)
09:13 allison but, when we finally merge the two, args and returns are the same, and params and results are the same
09:13 allison basically, filler and filled
09:22 bacek joined #parrot
09:32 dukeleto a patch status on trac of "review" would be pretty useful
09:34 allison dukeleto: it's been suggested
09:34 kurahaupo joined #parrot
09:34 dalek tracwiki: v17 | allison++ | CallingConventionsOverview
09:34 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=17&amp;action=diff
09:34 shorten dalek's url is at http://xrl.us/bfqdf2
09:35 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
09:35 allison Tene: yes, at least as a starting point
09:35 Tene allison: Okay.  I'll finish it in the morning.  Goodnight.
09:36 allison Tene: though you'll have to make changes to it
09:36 allison Tene: night
09:36 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
09:36 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.
09:36 allison Tene: I'll leave the fill_returns parts for you and work on the fill_params parts
09:36 Tene allison: great
09:37 allison Tene: thanks for the help!
09:37 allison dukeleto: so, something shy of 'rejected'
09:37 allison dukeleto: that's not really 'review', it's more of 'changes requested'
09:38 allison dukeleto: mmmm... a good single word for that
09:39 allison dukeleto: it really seems like 'rejected', then reset to 'new' when the new patch is attached
09:41 allison dukeleto: maybe 'revision'
09:41 allison dukeleto: or 'updated'
09:42 spankme joined #parrot
09:45 kurahaupo allison: "abeyant"?
09:45 janus joined #parrot
09:46 allison kurahaupo: points for aptness, minus on "obvious to the casual ticket wrangler"
09:46 kurahaupo :-)
09:46 kurahaupo "Stuck" >-)
09:47 bacek o hai
09:47 allison held_for_changes
09:50 bacek allison: what is current status of branch?
09:52 allison bacek: 186 failing tests last I checked
09:52 allison bacek: I'm reworking fill_params for the "iterate by argument" algorithm Whiteknight and I worked out
09:52 allison bacek: good work on the function pointers, it simplifies a lot of code
09:52 bacek allison: good-good. Any chances to merge fill_params and fill_returns?
09:53 allison bacek: not at this point, no, the logic is reversed
09:53 bacek sigh
09:53 allison bacek: but they can both use the accessor function pointers
09:53 bacek Can we adjust imcc to produce ops in proper order?
09:53 allison bacek: actually, the build_sig_object code can use the accessor function pointers too
09:53 allison bacek: yes, we will after 2.0
09:54 allison 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.
09:54 bacek allison: why it's "interface changes"?
09:54 allison because it changes the order the ops have to be called in
09:55 allison some ops are hidden behind syntactic sugar, but all ops are part of the public interface
09:55 bacek ok.
10:00 bacek ok. I'm going to generalise build_sig_object. Any objections?
10:00 allison bacek: go ahead
10:00 allison bacek: but keep in mind that the varargs version gets calls and returns all in one call
10:01 allison bacek: while the _from_op version gets them in two calls
10:01 allison bacek: (one from set_args and one from get_returns)
10:01 allison get_results
10:03 kj joined #parrot
10:04 allison bacek: they can't really be collapsed at the moment, but they can be changed to use the function pointers
10:05 dalek parrot: r41678 | kjs++ | trunk/compilers/pirc/src (3 files):
10:05 dalek parrot: [pirc] create STRINGs for labels and identifiers, store them in the temp. lexer->sval field, so the parser can them access them
10:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41678/
10:06 fperrad joined #parrot
10:10 masak joined #parrot
10:11 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
10:11 bacek allison: isn't it other way around? append("->", string_sig)?
10:12 allison bacek: the signature string goes args->returns
10:12 allison so P->S is one PMC argument and one string return
10:12 bacek that's why I'm asking
10:13 allison bacek: so that's appending an arrow onto the end of the string_sig
10:13 bacek but it's build_RETURNS...
10:14 allison yes, so it appends an arrow on to the end before it appends the return sigs
10:14 bacek ah, ok
10:18 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:19 quek joined #parrot
10:22 bacek kurahaupo: few good patches, 2+ votes on #ps to grant commit access, 1+ person to mentor, submit CLA.
10:24 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")
10:26 * kurahaupo worries that his suggested patch to exception.t may have broken the scoping semantics, since it reduces twelve compilation units to one.
10:27 bacek kurahaupo: did you mean "exporter.t"?
10:27 kurahaupo Yes
10:27 kurahaupo (It's 23:30 here; I should get some sleep.)
10:29 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
10:30 kurahaupo mikehh: thanks, will read it in the morning.
10:30 kurahaupo Goodnight all.
11:03 dalek parrot: r41679 | bacek++ | branches/pcc_reapply/src/call/context.c:
11:03 dalek parrot: [cage] Init Context.current_sub to avoid dereferencing garbage pointer.
11:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41679/
11:06 dalek parrot: r41680 | bacek++ | branches/pcc_reapply/src/pmc/callsignature.pmc:
11:06 dalek parrot: Mark all attributes of CallSignature.
11:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41680/
11:06 dalek tracwiki: v18 | bacek++ | CallingConventionsOverview
11:06 dalek tracwiki: Claim few more passing tests
11:06 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=18&amp;action=diff
11:06 shorten dalek's url is at http://xrl.us/bfqdjw
11:08 payload joined #parrot
11:09 dalek parrot: r41681 | kjs++ | trunk/compilers/pirc/src (4 files):
11:09 dalek parrot: [pirc] add STRING * variants to all data structures that currently use C strings (char *) as preparation of making PIRC STRING-aware
11:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41681/
11:14 silug joined #parrot
11:45 dalek tracwiki: v19 | bacek++ | CallingConventionsOverview
11:45 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=19&amp;action=diff
11:45 shorten dalek's url is at http://xrl.us/bfqdms
11:48 dalek parrot: r41682 | mikehh++ | branches/pcc_reapply/src/pmc/callsignature.pmc:
11:48 dalek parrot: codetest failure - trailing spaces
11:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41682/
11:49 joeri joined #parrot
11:53 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 kid51 joined #parrot
11:54 mikehh I tried a make headerizer and it gave some 40 warnings on src/call/args.c but no svn diff
11:55 mikehh I tried to fix the parens error but it don't make no sense to me
11:59 mikehh messages
12:04 dalek rakudo: 809ca9b | masak++ | src/classes/Signature.pir:
12:04 dalek rakudo: [Signature.pir] fixed typo
12:04 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​09ca9be448d3a48eb153625967577d08d45d6cf
12:04 shorten dalek's url is at http://xrl.us/bfqdoh
12:05 kid51 pcc_reapply branch with --buildframes=0:  latest Smolder:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28521
12:05 shorten kid51's url is at http://xrl.us/bfqdoj
12:06 kid51 132 failing tests (sans buildframes)
12:10 iblechbot joined #parrot
12:13 bacek joined #parrot
12:16 kid51 allison ping
12:16 kid51 mikehh:  I've figured out the c_parens.t problem.
12:16 kid51 It's a weird one.
12:17 dalek parrot: r41683 | jkeenan++ | branches/pcc_reapply/src/call/args.c:
12:17 dalek parrot: Temporarily fix failure of file to pass c_parens coding standard.
12:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41683/
12:19 Whiteknight joined #parrot
12:20 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.
12:25 bacek kid51: we can't use different name. They are return types from functions.
12:26 * bacek vote for changing coding standard to s+
12:32 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?
12:32 allison Whiteknight: I'm nearly done overhauling fill_params for argument iteration
12:33 Whiteknight oh wow
12:33 Whiteknight I'm sorry I couldn't have done more of it yesterday
12:33 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
12:34 Whiteknight yeah, I'm looking at that right now
12:34 Whiteknight bacek++
12:34 allison Whiteknight: he's currently working on converting the build_sig_object functions to use the same function pointers
12:34 bacek allison: not quite true actually.
12:35 allison kid51: that is, the typedef is the function pointer
12:35 allison bacek: well, last I heard that's what you were working on
12:35 allison bacek: what are you working on?
12:35 bacek allison: I can't figure out how to make this functions generic.
12:35 allison bacek: you can't
12:35 bacek I'm trying to fix other bugs atm.
12:35 allison but, you can use the function pointers
12:36 allison 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?
12:36 purl i guess the point is that tom_g would prefer to have consistent coredumps than unpredictable ones :)
12:36 allison bacek: to make the ultimate merge easier
12:36 dalek parrot: r41684 | jkeenan++ | branches/pcc_reapply (2 files):
12:36 dalek parrot: Better solution:  Modify codingstd to allow more flexibility in lines
12:36 dalek parrot: beginning with 'typedef'.
12:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41684/
12:36 allison bacek: and to cut down on duplicated code
12:38 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?
12:40 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:41 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:42 bacek side question, why Parrot_find_pad iterate over Context.outer_ctx, not Sub.outer?
12:42 allison bacek: sensible
12:42 purl sensible is usually inappropriate, yes :)
12:43 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 allison bacek: but would need to look at the code
12:44 bacek allison: it can. But it uses Sub.set_outer which set... erm... Sub.outer as well
12:45 bacek more generic question: why LexPad in Context at all?
12:45 bacek should it be in Sub only?
12:45 kid51 Whiteknight:  see lines 26-46 of src/call/ops.c
12:46 kid51 mikehh:  As for the c_functions codingstd errors -- the non-TODOed ones are all found in src/call/args.c.
12:47 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
12:47 allison bacek: Context stores all the information unique to a particular execution of a Sub
12:47 Whiteknight kid51: I don't see anyting out of place there, what's the codestd error there?
12:47 allison bacek: Sub is the same for all executions
12:47 bacek mikehh: just add PARROT_ASSERT_ARGS and POD docs :)
12:48 Whiteknight Context is like a stack frame in C, only better
12:48 Whiteknight and Sub is like the executable machine code
12:48 allison bacek: so, if you run the same sub twice, each time will have its own unique LexPad
12:48 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
12:48 bacek allison: hm... I have to sleep on it to understand fully.
12:49 kid51 Whiteknight:  Try:  perl t/codingstd/c_arg_assert.t src/call/ops.c
12:50 kid51 mikehh:  Verified.
12:50 Whiteknight Oh, I can fix that. one second
12:52 Whiteknight done
12:55 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:56 dalek parrot: r41685 | whiteknight++ | branches/pcc_reapply/src/call/ops.c:
12:56 dalek parrot: [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 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41685/
12:56 dalek parrot: r41686 | whiteknight++ | branches/pcc_reapply/src/call/args.c:
12:56 dalek parrot: [pcc] small aesthetic fixes
12:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41686/
12:56 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 #parrot
12:57 kid51 Uh oh.  I just got a build failure -- even with --buildframes=0
12:58 wknight8111 joined #parrot
12:59 kid51 Let me try that again.
13:00 wknight8111 stupid router is stupid
13:00 kid51 Now Whiteknight has multiple identities
13:01 wknight8111 tell me about it
13:01 purl rumour has it it is sad I recognize Jon's laptop/keyboard combo
13:04 dalek parrot: r41687 | bacek++ | branches/pcc_reapply/src/pmc/sub.pmc:
13:04 dalek parrot: [core] Fix strange shortcut in setting Sub.outer_ctx with normal loop.
13:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41687/
13:04 dalek parrot: r41688 | bacek++ | branches/pcc_reapply/src/pmc/sub.pmc:
13:04 dalek parrot: [cage] Remove unused variable in Sub.set_outer
13:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41688/
13:05 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
13:06 allison Whiteknight: but, yes, essentially
13:22 wknight8111 urg, the test results still aren't looking much better
13:22 kid51 With --buildframes=0, we have 131 tests still failing
13:23 kid51 http://smolder.plusthree.com/app/pu​blic_projects/report_details/28526
13:23 shorten kid51's url is at http://xrl.us/bfqdt7
13:24 wknight8111 is that in the pcc_reapply branch?
13:24 wknight8111 actually, the list is shorter then the last time i looked
13:25 PacoLinux joined #parrot
13:25 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
13:25 allison today it's down below 200
13:25 wknight8111 yay! hackathon++
13:26 kid51 Note that totals are much different without --buildframes=0
13:26 kid51 I'll have those totals in a few minutes
13:30 wknight8111 t/pmc/sub.t test 37 looks strange to me
13:30 wknight8111 it expects an :immediate :postcomp sub to be called twice
13:30 wknight8111 is that the case?
13:38 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
13:39 kid51 Yesterday, we were getting thru 'make test' with buildframes, albeit with > 400 errors.
13:40 kid51 but now, I'm hanging on test 118 in that file
13:41 wknight8111 bacek: yeah, :slurpy :named is a problm
13:44 wknight8111 I don't see any :named :slurpy parameters in t/oo/metamodel.t
13:55 dalek parrot: r41689 | rblasch++ | trunk/docs/book/pir (4 files):
13:55 dalek parrot: [book] Fixed typos.
13:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41689/
14:03 bacek joined #parrot
14:03 bacek hi again
14:03 purl oh, you're back!
14:03 bacek wknight8111: check Class.new.
14:04 bacek it uses "bare" :named :slurpy and receives empty hash instead of params
14:06 kid51 pcc_reapply branch without --buildframes=0:  t/op/gc.t hangs indefinitely before it gets to test at line 235
14:08 dalek parrot: r41690 | jkeenan++ | branches/pcc_reapply/t/op/gc.t:
14:08 dalek parrot: Add a test description to help debugging.
14:08 bacek kid51: all tests successful in t/op/gc.t on my box...
14:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41690/
14:08 wknight8111 t/pmc/coroutine.t:8 is failing because of lack of :optional and :opt_flag on returns
14:12 dalek parrot: r41691 | rblasch++ | trunk/docs/book/pir (4 files):
14:12 dalek parrot: [book] Reverted r41689, committed too much.
14:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41691/
14:13 bacek ok. we definitely need smarter fill_returns...
14:14 bacek mikehh++ # really good fix for codetest failures
14:15 dalek parrot: r41692 | mikehh++ | branches/pcc_reapply/src/call/args.c:
14:15 dalek parrot: attempt to fix codetest problems with src/call/args.c - codetest passes
14:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41692/
14:15 dalek parrot: r41693 | rblasch++ | trunk/docs/book/pir/ch09_exceptions.pod:
14:15 dalek parrot: [book] Fixed typos.
14:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41693/
14:21 dalek parrot: r41694 | jkeenan++ | branches/pcc_reapply/t/op/gc.t:
14:21 dalek parrot: Add more test descriptions.
14:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41694/
14:22 Psyche^ joined #parrot
14:33 cognominal joined #parrot
14:36 cognominal joined #parrot
14:38 AndyA joined #parrot
14:44 mikehh well codetest and manifest_tests PASS in pcc_reapply branch
14:59 kid51 Building without --buildframes=0, t/op/gc.t hangs during 'make coretest' for me.  It's been hung 20 minutes!
15:01 kid51 When I run it with prove, it stops after 117 tests -- but at least I can get the test summary report.
15:03 theory joined #parrot
15:06 Maddingue joined #parrot
15:07 kid51 With --buildframes=0, t/op/gc.t just sails right through -- no failures at all.
15:11 bacek kid51: it's "expected"...
15:14 mikehh it completes for me - waiting to send to smolder
15:16 dalek parrot: r41695 | bacek++ | branches/pcc_reapply/tools/build/nativecall.pl:
15:16 dalek parrot: Fix handling /B/ in nci nativecall builder. Claim one more passing test.
15:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41695/
15:16 dalek parrot: r41696 | bacek++ | branches/pcc_reapply/src/nci_test.c:
15:16 dalek parrot: Trade last test from t/pmc/nci.t into compiler warning.
15:16 dalek parrot: PMC_is_null function declared in parrot/pmc.h. Including this file into nci_test causing tonnes of failures...
15:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41696/
15:17 bacek holy sh...
15:17 bacek clock?
15:17 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 /
15:17 * bacek must sleep
15:17 purl $bacek->sleep(8 * 3600);
15:19 mikehh still waiting - doesn't seem to want to connect
15:30 jan joined #parrot
15:45 iblechbot joined #parrot
15:46 mikehh managed to get it smolder on the second attempt - http://smolder.plusthree.com/app/pu​blic_projects/report_details/28535
15:46 shorten mikehh's url is at http://xrl.us/bfqd7t
16:05 particle joined #parrot
16:13 allison bacek: ping
16:14 allison ah, bacek sleep, unping
16:20 nopaste joined #parrot
16:27 dalek parrot: r41697 | pmichaud++ | branches/pct-rx/t/compiler​s/pct/regex/06-p6regex.t:
16:27 dalek parrot: [pct-rx]:  Move p6regex test a bit later in sequence.
16:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41697/
16:28 allison Whiteknight: ping
16:29 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
16:30 allison mikehh: I'm not sure if it's just the last commit or the last two commits
16:30 allison mikehh: svn update -r41694 works
16:31 allison mikehh: haven't tried -r41695
16:31 allison mikehh: -r41696 is definitely broken
16:32 mikehh alison: yes at r41694 amd64 I get 6,434 ok, 125 failed, 100 todo, 162 skipped and 1 unexpectedly succeeded
16:34 mikehh I updated to r41696 and got a failure with src/nci_test.c
16:34 allison mikehh: that looks right, how about -r414695?
16:34 allison mikehh: that looks right, how about -r41695?
16:34 mikehh let's see
16:35 mikehh r41695 builds
16:36 mikehh I did svn update -r41695, make corevm (didn't clean or anything)
16:38 allison does it fail a lot of tests?
16:39 allison mikehh: (I ask because bacek's comment on r41696 implies that it was fixing test failures)
16:42 mikehh I am running smolder_codetest at the moment - will see
16:43 mikehh it will probably indicate r41696 because that is where I configured
16:44 mikehh but I reverted to r41695
16:44 mikehh it just reverted the test
16:44 mikehh src/nci_test.c
16:45 mikehh http://smolder.plusthree.com/app/pu​blic_projects/report_details/28540
16:45 shorten mikehh's url is at http://xrl.us/bfqedg
16:45 allison mikehh: great, thanks!
16:48 mikehh looks the same as #28535
16:48 wknight8111 allison: pong
16:49 mikehh bear in mind that it is actually at r41695 nor r41696 as indicated
16:49 mikehh not
16:56 allison whiteknight: I've got a diff for code review
16:56 allison Whiteknight: or I can check it in
16:56 whiteknight check it in
16:57 whiteknight we can roll it back if it stinks (unlikely) or build on it to make it better in place
16:58 allison whiteknight: committed
16:59 whiteknight w00t
16:59 whiteknight build is broken
16:59 * whiteknight backlogs
16:59 allison whiteknight: at the moment I'm tracking down a failure in t/oo/composition.t
16:59 whiteknight okay, I'll track down the build failure
17:00 allison whiteknight: mikehh said he reverted the build failure
17:00 dalek parrot: r41698 | allison++ | branches/pcc_reapply/src (2 files):
17:00 dalek parrot: [pcc] Reworking fill_params as an iterator over arguments rather than
17:00 dalek parrot: parameters.
17:00 purl parameters are definitely in the scope of the callee
17:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41698/
17:00 whiteknight oh. realclean, rebuilding
17:01 allison whiteknight: nope, looks like mikehh didn't commit
17:03 whiteknight gotcha
17:03 szabgab joined #parrot
17:05 allison whiteknight: commited revert
17:05 whiteknight awesome
17:06 allison whiteknight: was at 165 test failures after adding my patch
17:06 dalek parrot: r41699 | allison++ | branches/pcc_reapply/src/nci_test.c:
17:06 dalek parrot: [pcc] Reverting r41696 as it caused a build failure.
17:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41699/
17:07 whiteknight great! The number is getting very low
17:08 whiteknight 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 whiteknight both of which can be tracked down and fixed
17:09 allison whiteknight: aye
17:10 allison I'm gettin "too few named arguments: no argument for required parameter 'exclude_method'"
17:10 allison but the parameter is marked :optional
17:10 whiteknight urg. I was seeing problems with :named :optional the other day
17:10 allison (stranger still, the version of the method on that class doesn't even have that parameter at all)
17:10 whiteknight what test is this?
17:10 purl tested ok
17:11 allison t/oo/composition.t
17:11 masak joined #parrot
17:11 moritz re
17:12 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
17:12 allison mikehh: (that you had just reverted it locally for the smoke test run, or something like that)
17:13 dalek rakudo: a796cf1 | moritz++ | src/setting/Operators.pm:
17:13 dalek rakudo: add another &infix:<...> multi to handle the case 3 ... $+2, $max
17:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​796cf1685594947e4682fb0fa72d93928e39850
17:13 shorten dalek's url is at http://xrl.us/bfqei2
17:13 dalek rakudo: db7c668 | moritz++ | src/setting/Complex.pm:
17:13 dalek rakudo: Complex.ACCEPTS
17:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​b7c66847ab27a35484ae5e085e813e016f5e763
17:13 shorten dalek's url is at http://xrl.us/bfqei4
17:14 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
17:15 allison 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
17:16 whiteknight allison: I dont see anywhere that you set un-passed opt_flags to false
17:16 whiteknight oh wait, I found it
17:17 allison yeah, it's the next 'else'
17:18 mikehh All tests PASS (pre/post-config, smoke (#28541), fulltest) at r41696 - Ubuntu 9.04 amd64
17:23 dalek parrot: r41700 | allison++ | branches/pcc_reapply/src/call/args.c:
17:23 dalek parrot: [pcc] Don't declare variable until limited scope where it's used.
17:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41700/
17:33 ilbot2 joined #parrot
17:33 Topic for #parrotis now http://www.parrot.org | Parrot 1.6.0 "half-pie" released: PCC branch hackathon all $localtime Saturday | Testing priorities: pcc_reapply branch
17:34 mikehh What's with CONST_STRING - it breaks the compiler if THE STATEMENT with it in is split across lines
17:37 whiteknight if I add printf statements into the named arguments loop for debugging, Parrot fails an assertion inside do_thaw
17:42 whiteknight mikehh: yeah, it's stupid
17:42 kid51 joined #parrot
17:42 dalek parrot: r41701 | whiteknight++ | branches/pcc_reapply/src/call/args.c:
17:42 dalek parrot: [pcc] fix CONST_STRING spread across multiple lines
17:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41701/
17:43 dalek tracwiki: v104 | jkeenan++ | WikiStart
17:43 dalek tracwiki: https://trac.parrot.org/parrot/wiki/W​ikiStart?version=104&amp;action=diff
17:43 shorten dalek's url is at http://xrl.us/bfqeoe
17:45 tetragon joined #parrot
17:45 dalek parrot: r41702 | allison++ | branches/pcc_reapply/src/call/args.c:
17:45 dalek parrot: [pcc] Better checking on named argument passing counts.
17:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41702/
17:52 kid51 pcc_reapply branch: r 41701:  with --buildframes=0:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28543
17:52 shorten kid51's url is at http://xrl.us/bfqepj
17:55 kid51 Hmm:  that's 33 more test failures than at r41694, under the same conditions
17:56 kurahaupo joined #parrot
17:56 fperrad ping bacek
17:56 purl I can't find bacek in the DNS.
17:56 kurahaupo Bacek's in UTC+10 so he'll be asleep
17:57 kid51 Hmm, I notice that at r41694, all tests in t/pmc/class.t were SKIPped; at r41701 they are unSKIPped and failing
17:58 kid51 kid51:  wrong; it's the other way around
17:59 kid51 In more recent report, am getting failures in t/pmc/exporter.t that were not there in earlier.
18:01 kid51 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 http://smolder.plusthree.com/app/p​ublic_projects/tap_stream/28543/97
18:01 shorten kid51's url is at http://xrl.us/bfqeq3
18:05 allison kid51: the logic for argument handling has been expanded, working on fixing up the incidental damage
18:06 kid51 k
18:07 kid51 t/oo/composition.t also blew up in the later revision:  for same "too few named arguments" reason:  http://smolder.plusthree.com/app/pu​blic_projects/tap_stream/28543/180
18:07 shorten kid51's url is at http://xrl.us/bfqerw
18:08 dalek parrot: r41703 | allison++ | branches/pcc_reapply/src/call/args.c:
18:08 dalek parrot: [pcc] Add checking for a named parameter that doesn't have a string name.
18:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41703/
18:09 allison kid51: thanks for the reports, very helpful
18:13 moritz wow, the pcc_reapply branch looks much better than it did last week
18:16 whiteknight named parameter that doesn't have a string name?
18:17 whiteknight ah okay, we don't support it
18:17 whiteknight that's good
18:17 whoppix joined #parrot
18:23 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:24 allison 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 http://nopaste.snit.ch/18213
18:24 allison whiteknight: (it's also easier to refactor it down to smaller routines)
18:24 dalek parrot: r41704 | allison++ | branches/pcc_reapply/src/call/args.c:
18:24 dalek parrot: [pcc] Actually collect named args into the slurpy hash.
18:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41704/
18:25 whiteknight haha, that's funny
18:25 whiteknight I didn't notice it either
18:29 allison whiteknight: is parameter count checking supposed to be on by default? I remember it being of by default
18:29 allison off
18:29 whiteknight i thought it was on by default?
18:29 allison whiteknight: it is on by default now
18:30 allison whiteknight: just surprised me when I was working on a test case just now
18:30 whiteknight oh, okay
18:31 allison whiteknight: ah yeah, running the same code against trunk produces the same error
18:31 allison (or a similar error, slight text differences)
18:32 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
18:34 kurahaupo Never mind, someone beat me to it.
18:34 dalek parrot: r41705 | allison++ | branches/pcc_reapply/src/call/args.c:
18:34 dalek parrot: [pcc] Also mark the named argument as used when its pulled into the slurpy,
18:34 dalek parrot: for later error checking.
18:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41705/
18:36 whiteknight very few test files are aborting early now, that's a great sign
18:37 dalek parrot: r41706 | allison++ | branches/pcc_reapply/t/op/calling.t:
18:37 dalek parrot: [pcc] PIR test for slurpy named arguments.
18:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41706/
18:40 payload joined #parrot
18:40 whiteknight okay, the test I was just debugging works now after r41704
18:40 whiteknight so it was the slurpy hash that was the problem
18:41 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
18:41 allison whiteknight: I've been assuming it shows up on the string name
18:41 whiteknight I've sort of assumed it was the other way around
18:42 whiteknight we could switch it around and see if more or fewer tests pass
18:42 allison whiteknight: I'll try it
18:43 allison checking specifically t/pmc/class.t, where an optional parameter is being mishandled as required
18:47 allison whiteknight: alrighty then, that made the test pass
18:47 allison whiteknight: I guess the optional gets marked on the actual param, not on the param name
18:47 whiteknight sounds like we need some documentation about that
18:47 whiteknight All the tests I was debugging are passing now. I need to look for new tests
18:49 whiteknight can I get your opinion on t/pmc/sub_37.pir?
18:49 whiteknight we can "fix" it if that is the desired behavior
18:50 whiteknight 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 #parrot
18:51 allison whiteknight: (re :postcomp and :immediate) we should preserve the existing behavior now, even if we decide to change it later
18:52 whiteknight where do we see the number of tests failed? I never see that number
18:53 kid51 r41706 cleared about 42 tests:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28551
18:53 shorten kid51's url is at http://xrl.us/bfqewa
18:54 allison whiteknight: when you run 'make coretest' it should give you a summary at the end
18:54 kid51 whiteknight:  http://smolder.plusthree.com/app/​public_projects/smoke_reports/8:  I've been reporting results of make corevm makecoretest in pcc_reapply branch with --buildframes=0 in configuration
18:54 shorten kid51's url is at http://xrl.us/bfqewi
18:54 dalek parrot: r41707 | mikehh++ | branches/pcc_reapply/src/call/args.c:
18:54 dalek parrot: codetest fixes - assert args, function docs, linelength
18:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41707/
18:54 dalek parrot: r41708 | allison++ | branches/pcc_reapply/src/call/args.c:
18:54 dalek parrot: [pcc] The :optional flag is marked on the named parameter itself, not on the
18:54 dalek parrot: name string.
18:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41708/
18:54 allison kid51: try 41708 :)
18:54 Tene allison: src/call/args.c +811, ISO C90 forbids mixed declarations and code
18:55 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 http://nopaste.snit.ch/18214
18:55 allison Tene: thanks, fixing
18:58 whiteknight allison++ is kicking ass
19:01 dalek parrot: r41709 | allison++ | branches/pcc_reapply/src/call/args.c:
19:01 dalek parrot: [pcc] Fix C90 compiler warning about mixed declarations and code.
19:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41709/
19:01 moritz it seems some of the failures stem from too strict checks for error messages
19:02 moritz 'too few positional arguments: 1 passed, 2 (or more) expected
19:02 moritz ...
19:02 moritz doesn't match '/too (many|few) arguments passed .*
19:02 Tene moritz: yes, the tests need to be fixed.
19:03 allison moritz: yes, those are the old error messages
19:05 kid51 41708 gets us down to 58
19:05 allison kid51: excellent, the finish line is in sight
19:06 allison 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.
19:06 nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply branch: --buildframes=0: current failures verbose output" (1731 lines) at http://nopaste.snit.ch/18215
19:06 allison Tene: I'm going off to make some dinner, but I'll check in in case you have any questions
19:07 kid51 Of course, the results aren't going to be so pretty when we omit '--buildframes=0' from Configure.pl
19:07 kid51 but at least we have partialized the problems
19:07 Tene allison: just confirmation that you want me to use the old algorithm from fill_params for fill_returns
19:07 Tene allison: which you already gave last night.
19:07 mikehh I get 6,502 ok, 58 failed, 101 todo, 162 skipped and 1 unexpectedly succeeded with normal parameters on amd64 - smolder #28553
19:07 allison Tene: I'd start there, it's closest to what you'll want
19:08 allison Tene: but you can take a look at the new fill_params too
19:08 allison Tene: see if there's anything helpful there
19:09 allison 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 - http://smolder.plusthree.com/app/pu​blic_projects/report_details/28553
19:09 shorten mikehh's url is at http://xrl.us/bfqeyi
19:10 mikehh that's at r41708 - codetest also passes
19:11 kid51 allison:  See scrollback a couple of hours re my build problems on Linux 86 without --buildframes=0; compare mikehh's results
19:11 kid51 I fear we're going to encounter some platform-specific differences;
19:12 kid51 mikehh showed 58 failures  at r41708; I showed 63.  Why did I get more *with* --buildframes=0 and on 32 bit?
19:12 kid51 I don't know -- but I gotta book.
19:15 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:16 mikehh but it has been fun anyway
19:16 whiteknight urg, imcc is such a damn mess
19:17 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
19:17 whiteknight I'm trying to chase down that t/pmc/sub.t failure, and it's leading me into the abyss
19:18 dalek parrot: r41710 | moritz++ | branches/pcc_reapply/t/op/cc_params.t:
19:18 dalek parrot: adapt testing regex to new error messages in t/op/cc_params.t
19:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41710/
19:22 dalek close: r171 | Austin++ | trunk/ (50 files):
19:22 dalek close: NOT WORKING: Commit before directory moves.
19:22 dalek close: review: http://code.google.com/p/close/source/detail?r=171
19:27 dalek close: r172 | Austin++ | trunk/src/close/ (2 files):
19:27 dalek close: Renamed Compiler->Slam
19:27 dalek close: review: http://code.google.com/p/close/source/detail?r=172
19:27 dalek close: r173 | Austin++ | trunk/src/ (2 files):
19:27 dalek close: Moved src/close/Slam -> src/Slam
19:27 dalek close: review: http://code.google.com/p/close/source/detail?r=173
19:46 dalek close: r174 | Austin++ | trunk/build/Makefile.in:
19:46 dalek close: Updated Makefile.in
19:46 dalek close: review: http://code.google.com/p/close/source/detail?r=174
19:47 s1n joined #parrot
19:55 joeri left #parrot
20:07 s1n joined #parrot
20:11 cconstantine joined #parrot
20:19 mikehh pcc_reaply branch - smolder_coretest - http://smolder.plusthree.com/app/pu​blic_projects/report_details/28557 at r41710
20:19 shorten mikehh's url is at http://xrl.us/bfqe9u
20:20 mikehh 6,521 ok, 39 failed, 101 todo, 162 skipped and 1 unexpectedly succeeded - Ubuntu 9.04 amd64
20:21 mikehh that's down to 39 failures from 58 at r41708
20:22 mikehh of course kid51 was getting more on i386 but hey :-}
20:22 bacek joined #parrot
20:23 fperrad_ joined #parrot
20:26 mikehh oh and codetest and manifest_tests also PASS
20:26 mikehh and pre/post-config tests
20:28 * mikehh need a break, a nap, mabe some sleep
20:28 mikehh bbl
20:37 s1n joined #parrot
20:40 * allison full of enough pancakes to explode an elephant, and looking at the frame_builder
20:41 mokurai joined #parrot
20:43 whiteknight allison: did you see the libJIT-based framebuilder that plobsinger made?
20:43 whiteknight he has it up on git
20:43 allison whiteknight: I didn't
20:43 whiteknight http://github.com/plobsing/parrot-libjit
20:43 allison whiteknight: or, I saw his IRC message go by, but had my nose buried in pcc at the time
20:43 whiteknight no hurry, but it's a very cool project
20:44 allison whiteknight: cool, I'll take a look
20:44 whiteknight awesome
20:44 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?
20:45 allison Tene: 'returns' is only positional returns
20:45 Tene Where are named returns stored?
20:45 allison Tene: and, because Parrot's return handling is currently backward...
20:46 allison Tene: named returns aren't currently stored at all
20:46 allison Tene: ...backward, each return set by 'get_results' is actually a storage location where 'set_returns' will store the return value
20:47 allison 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?
20:47 allison Tene: but at the moment it has to work that way
20:47 Tene nodnod
20:47 allison Tene: yes
20:47 allison fill_returns is called from 'set_returns'
20:48 allison the raw signature of the results is passed to 'build_sig_object'
20:48 allison (in vararg and op variants)
20:52 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?
20:53 allison Tene: yes
20:53 Ryan52 allison: so...what's happening with getting a newer parrot in Debian? :)
20:53 allison Tene: first we fill 'returns' with CPointers to the destinations, then we set the values of those CPointers to the actual return values
20:54 allison Ryan52: I've been a bit busy
20:54 allison Ryan52: I did get your message though
20:54 Ryan52 allison: willing to let me do it? (just the upload to experimental)
20:54 allison Ryan52: go for it
20:55 allison Ryan52: but check with me if you have to make any packaging changes beyond version number
20:55 allison Ryan52: the packaging files are all in ports/debian in the repository
20:55 Tene allison: so how do we deal with, say, :slurpy results?
20:55 allison Ryan52: and please build from the tarball of the most recent release, rather than from svn
20:55 Tene allison: I don't see where I can find out that a given result is supposed to be :slurpy
20:56 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?
20:56 allison Tene: you have to check the return string signature
20:56 Ryan52 allison: okay, thanks!
20:56 allison where it will have the original marking for 'slurpy'
20:57 Tene Where can I find that?
20:57 purl that is how it does it.
20:57 allison Ryan52: thank you!
20:57 allison Tene: it's stored in the call_object
20:57 Tene Is it the short_sig?
20:58 allison Tene: or, if the signature was set up from an op, the FIA signature is stored in return_flags
20:58 allison Tene: yes, the short_sig is the string signature
20:58 Tene Okay.
20:58 allison Tene: short_sig is both args and returns, so jump ahead to everything after '->'
20:59 allison 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.
20:59 allison Tene: so the op and varargs version are consistent
20:59 Tene Okay.
20:59 Ryan52 allison: hm, what do you mean when you szy the files are in ports/debian?
20:59 Ryan52 *say
20:59 Tene I think I understand what's going on now.
21:00 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
21:00 allison Ryan52: okay
21:00 Tene I'll go back for another try at this.
21:01 allison Ryan52: the step-by-step guide on how we build the parrot packages is in docs/project/debian_packaging_guide.pod
21:01 allison Ryan52: (I know you already know all about debian packages, but that'll give you the Parrot specifics)
21:02 allison Tene: cool
21:02 dalek TT #1091 created by whiteknight++: ExceptionHandlers should be Subs
21:03 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
21:03 Tene Let me just say, those names are very confusing. :P
21:03 allison Tene: I've been mixing up returns and results in my usage as badly as whiteknight mixes up args and params :)
21:04 allison Tene: agreed, if you have any better ideas I'm open to them :)
21:04 allison Tene: maybe 'return args' and 'return params', just so we only have to deal with one set of confusion
21:04 whiteknight I think allison is full of crap if she thinks args and params are different things
21:04 whiteknight :)
21:04 allison whiteknight: :)
21:04 Tene whiteknight: I disagree.  args and params are very different.
21:04 allison whiteknight: I can say the same about returns and results
21:05 whiteknight Tene: That can't be! if they were different, I wouldn't be confusing the two words
21:05 dalek parrot: r41711 | whiteknight++ | trunk/DEPRECATED.pod:
21:05 dalek parrot: [DEPRECATED] Continuation-based ExceptionHandlers are on the chopping block after 2.0 TT #1091
21:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41711/
21:05 allison whiteknight: it's like a bus that changes route numbers depending on whether it's leaving or arriving
21:06 allison "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.
21:06 allison Tene: agreed, that would help
21:06 diakopter left #parrot
21:06 allison Tene: please to fix it where you find inconsistencies
21:06 allison do
21:06 Tene Well, i"ll look into it after I get this working.
21:07 Tene Maybe add it to the tasklist?
21:07 allison Tene: sure
21:07 Tene afk working
21:11 Tene allison: just to confirm, fill_results should be iterating over returns, or over results?
21:11 allison Tene: it should be iterating over returns
21:11 whiteknight ...which one is which?
21:11 Tene Okay.
21:11 allison Tene: parallel to fill_params which iterates over args
21:11 Tene whiteknight: returns are the ones you specify with .return ()
21:11 dalek tracwiki: v20 | allison++ | CallingConventionsOverview
21:11 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=20&amp;action=diff
21:11 shorten dalek's url is at http://xrl.us/bfqff6
21:12 allison whiteknight: returns==args, results==params
21:12 Tene allison: new fill_params or old fill_params? ;)
21:12 allison whiteknight: returns/args=="what you dump in" and results/params=="what you get out"
21:12 whiteknight gotcha
21:13 allison Tene: the new fill_params is the one that iterates over args
21:13 allison Tene: it's saner that way
21:13 Tene s/what you get out/where they end up/
21:13 whiteknight I'm thinking that maybe we should find a way to store strings like error messages externally to the code
21:13 allison Tene: easier to check
21:13 Tene allison: Okay.  I somehow got a bit confused last night.
21:13 allison whiteknight: yes, we have to for internationalization
21:13 whiteknight exactly.
21:14 whiteknight 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
21:14 * Tene strongly recommends something like Locale::MakeText over gettext
21:14 allison Tene: what's the linux kernel use?
21:14 Tene allison: enoclue
21:15 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 #parrot
21:16 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
21:17 allison Rosetta?
21:17 purl rumour has it Rosetta is at http://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
21:20 allison Tene: but it's pretty much unexplored territory for me too
21:22 whiteknight allison: I do some MediaWiki hacking too, and everything they do is i18n compatible
21:23 whiteknight what is 'f' in a signature, :flat?
21:24 Ryan52 allison: here's my "svn diff" http://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 Ryan52 allison: okay for me to upload it?
21:25 whiteknight yeah, 'f' is :flat (answered my own question)
21:27 bacek Good morning
21:27 GeJ G'Day bacek
21:28 bacek G'Day GeJ
21:28 whiteknight good morning GeJ
21:28 whiteknight and hello again, bacek
21:28 GeJ Heya whiteknight
21:28 purl whiteknight is mailto:wknight8111@gmail.com or the grand master funk or http://wknight8111.blogspot.com/
21:29 whiteknight allison: issue in multidispatch. an incoming :flat array has a signature "Pf" instead of signatures of each of it's component objects
21:31 dalek parrot: r41712 | bacek++ | branches/pcc_reapply/src/nci_test.c:
21:31 dalek parrot: [cage] Properly fix nci_test.
21:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41712/
21:34 * whiteknight has to look into trunk to see how it's handled there
21:35 kid51 joined #parrot
21:37 allison whiteknight: yes, I saw that failing test
21:38 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
21:39 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
21:40 allison 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
21:40 allison whiteknight: so we lose track of the fact that it was originally a :flatten argument
21:41 allison 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?
21:41 allison whiteknight: it's hard to do it in multidispatch, because we've lost the information about what it flattened into
21:41 whiteknight so "Pf" -> "IfSnfPf"
21:42 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..."
21:42 whiteknight allison: working backwards, what's the benefit to having that information in the first place?
21:43 allison whiteknight: PfPf might  flatten to any number of args
21:43 whiteknight what do you mean?
21:43 allison whiteknight: very little benefit
21:43 allison whiteknight: you can pass in more than one flattening argument
21:43 allison so, two arrays, or 4 arrays and 5 hashes
21:44 allison 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
21:44 allison they're all steamrolled
21:44 whiteknight is this information that is worth keeping?
21:44 allison whiteknight: not really, no
21:44 allison whiteknight: it's just a packrat principle
21:44 allison whiteknight: go ahead and rewrite
21:45 allison whiteknight: we can always find some way to retain the information of we need it someday
21:45 allison whiteknight: but no reason to keep it at the moment
21:45 whiteknight something like "Pf{...}" would do the trick
21:45 whiteknight but yes, something for the future
21:45 allison whiteknight: yeah, there are ways to do it, if we find we do need the information
21:48 whiteknight what does the arglist flatten to, all Ps?
21:48 whiteknight (for arrays)
21:50 Ryan52 allison: ??
21:51 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:53 allison Tene: just grab the returns array out of the call object
21:54 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
21:54 allison the return signature
21:54 allison i.e. the fixed integer array
21:54 allison Ryan52: yes?
21:54 Ryan52 14:24 < Ryan52> allison: here's my "svn diff" http://slexy.org/raw/s2juysTJm9 . the standards version, homepage, and passive ftp changes should probably be caried over into future debian packages of parrot.
21:55 Ryan52 14:24 < Ryan52> allison: okay for me to upload it?
21:55 Ryan52 allison: u never answered or acknowledged that I asked.
21:56 allison Ryan52: looks good, go ahead
21:56 allison Ryan52: (I didn't see the earlier message)
21:56 Ryan52 kk, thanks.
21:59 whiteknight make headerizer spits out a lot of warnings in the branch
22:00 allison whiteknight: it's all the function pointer definitions
22:01 allison whiteknight: they don't have the standard declarations
22:01 dalek parrot: r41713 | whiteknight++ | branches/pcc_reapply (3 files):
22:01 dalek parrot: [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
22:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41713/
22:01 allison whiteknight: that is src/call/args.c
22:03 whiteknight what is?
22:03 allison whiteknight: the headerizer complaints are about src/call/args.c
22:03 whiteknight oh, okay
22:06 * allison sleeps
22:18 dalek close: r175 | Austin++ | trunk/ (3 files):
22:18 dalek close: Moved src/parser -> src/Slam/parser
22:18 dalek close: review: http://code.google.com/p/close/source/detail?r=175
22:20 dalek rakudo: 42ed85a | (Lanny Ripple)++ | src/setting/Num.pm:
22:20 dalek rakudo: add a cast for Num to Rat with optional error
22:20 dalek rakudo: Adds Num.Rat which creates a Rat approximation of a Num with an error tolerance (defaults to 1e-6).
22:20 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​2ed85adefc2867d0d23399ac029c2a508fcd68b
22:20 dalek rakudo: 1ca164a | (Solomon Foster)++ | src/setting/Num.pm:
22:20 shorten dalek's url is at http://xrl.us/bfqfoj
22:20 dalek rakudo: Change Num._modf to "my" to make it private.
22:20 purl dalek: that doesn't look right
22:20 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​ca164a87db6324abd21c54070732260995a7a1d
22:20 shorten dalek's url is at http://xrl.us/bfqfom
22:24 dalek parrot: r41714 | bacek++ | branches/pcc_reapply/src/call/pcc.c:
22:24 dalek parrot: Runops for Eval PMC in invoke_from_sig_object. Fixes t/src/embed.t
22:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41714/
22:32 dalek close: r176 | Austin++ | trunk/ (23 files):
22:32 dalek close: Moved *Visitors into subdir, fixed Makefile.in
22:32 dalek close: review: http://code.google.com/p/close/source/detail?r=176
22:33 whiteknight this weekend has been very productive
22:36 bacek Anyone working on fill_returns?
22:36 whiteknight Tene was, I think
22:37 bacek Tene: any luck?
22:39 nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply branch: --buildframes=0: current failures verbose output" (1474 lines) at http://nopaste.snit.ch/18217
22:40 dalek parrot: r41715 | whiteknight++ | branches/pcc_reapply/src/call/args.c:
22:40 dalek parrot: [pcc] add PARROT_CAN[NOT]_RETURN_NULL to some functions in src/call/args.c. This shuts up some warnings in headerizer
22:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41715/
22:41 whiteknight why does stringhandle.t take so damn long to run?
22:43 Tene bacek: yes, making progress
22:43 Tene bacek: I have nomral positional returns and slurpy returns working.
22:43 bacek Tene: good.
22:44 Tene bacek: I probably have to stop working soon... will you be around to finish it?
22:45 bacek Tene: I can try. It's public holiday in Australia.
22:47 whiteknight Tene: commit what you have when you leave, we will carry on
22:47 dalek parrot: r41716 | jkeenan++ | branches/library_files/config (2 files):
22:47 dalek parrot: 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.:  https://trac.parrot.org/parrot/ticket/1061.
22:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41716/
22:47 nopaste "tene" at 24.10.252.130 pasted "The work so far on fill_params, fwiw" (662 lines) at http://nopaste.snit.ch/18218
22:48 whiteknight wow, that's a lot
22:48 whiteknight once we get slurpy and named returns working, I have very high hopes that PCT will build
22:49 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.
22:50 kid51 Running it with 'prove -v', I end up with:
22:50 kid51 ok 115 - end vanishing_return_continuation
22:50 kid51 ok 116
22:50 kid51 ok 117
22:50 kid51 Failed 23/140 subtests
22:50 kid51 Test Summary Report
22:50 kid51 -------------------
22:50 kid51 t/op/gc.t (Wstat: 11 Tests: 117 Failed: 0)
22:50 kid51 Non-zero wait status: 11
22:50 kid51 Parse errors: Bad plan.  You planned 140 tests but ran 117.
22:51 kid51 Files=1, Tests=117,  4 wallclock secs ( 0.06 usr  0.00 sys +  1.09 cusr  0.06 csys =  1.21 CPU)
22:51 kid51 Result: FAIL
22:51 kid51 perl t/harness t/op/gc.t fails at test 118, but the harness completes as intended.
22:54 kid51 So why should 'make smolder_coretest' -- which just wraps around t/harness -- cause t/op/gc.t to hang?
22:57 whiteknight that's weird
22:58 GeJ bacek: r41712 says "Properly fix nci_test." Should I remove it from CallingConventionsOverview's "Known Issues" list?
22:58 patspam joined #parrot
22:58 bacek GeJ: look like yes
23:01 dalek tracwiki: v21 | geraud++ | CallingConventionsOverview
23:01 dalek tracwiki: With bacek's confirmation on IRC, remove nci known issue.
23:01 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsOverview?version=21&amp;action=diff
23:01 shorten dalek's url is at http://xrl.us/bfqfsw
23:01 GeJ bacek++
23:06 cotto I see there's been a bunch of pcc hacking.  How much closer is the pcc_reapply branch to being mergeable?
23:07 dalek parrot: r41717 | bacek++ | branches/pcc_reapply/src/call/args.c:
23:07 dalek parrot: Clone Key args in fill_params. Stolen from old PCC.
23:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41717/
23:07 kid51 $ ps aux | grep 't/op/gc.t'
23:07 kid51 jimk      6453  8.2 71.5 457704 254884 pts/0   D+   19:03   0:14 parrot t/op/gc.t
23:07 kid51 It's eating up memory, I guess.
23:08 bacek cotto: before Christmas :)
23:08 whiteknight cotto: we've fixed A LOT of failing tests
23:08 whiteknight still a handfull, but a lot less then there was
23:09 whiteknight and Tene is doing some work on returns that should get us most of the way down to 0
23:10 bacek bloody headerizer...
23:10 cotto I'm disappointed not to have had the free time, but you all committed some serious pwnage.
23:10 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.
23:11 Tene (a :named('a'), b :named('b')) = foo()
23:12 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
23:12 cotto afk
23:13 dalek parrot: r41718 | bacek++ | branches/pcc_reapply/src/call/args.c:
23:13 dalek parrot: Make headerizer happy.
23:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41718/
23:13 dalek parrot: r41719 | jkeenan++ | branches/library_files/con​fig/gen/makefiles/root.in:
23:13 dalek parrot: Correct trailing whitespace codingstd error.
23:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41719/
23:13 dalek parrot: r41720 | bacek++ | branches/pcc_reapply (2 files):
23:13 dalek parrot: Fix ARGMOD guard in fill_returns_from_op
23:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41720/
23:14 whiteknight Tene: commit it and let us do some debuggering
23:15 kid51 pwnage?
23:16 whiteknight kid51: pwnage is when we kick ass and take names.
23:19 kid51 Having looked up pwnage on urbandictionary.com ..
23:19 * kid51 vows never to use it.
23:20 theory joined #parrot
23:21 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 #parrot
23:22 whiteknight Tene: awesome
23:22 whiteknight kid51: probably some weird heisenbug thing
23:22 whiteknight or something that is dependent on memory layout
23:22 kid51 No, I take that back.
23:23 kid51 I configured with --buildframes=0.
23:23 Tene Yay, headerizer conflicts when trying to update so I can commit.
23:23 kid51 In fact, the situation has gotten worse. r41714:  37 tests failed; r41720:  78 failures!
23:25 kid51 many failures in       t/pmc/exporter.t (again)
23:25 kid51 And new failures in t/pmc/key.t
23:26 whiteknight urg
23:26 kid51 and new failures in t/pmc/packfile.t
23:27 kid51 http://smolder.plusthree.com/app/pu​blic_projects/report_details/28565
23:27 shorten kid51's url is at http://xrl.us/bfqfvc
23:27 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.
23:28 whiteknight yeah, it's a work in progress
23:29 nopaste "kid51" at 70.85.31.226 pasted "diff of last 3 commits -- which caused more tests to fail" (536 lines) at http://nopaste.snit.ch/18219
23:29 dalek parrot: r41721 | tene++ | branches/pcc_reapply/src/call/args.c:
23:29 dalek parrot: [pcc] The start of the fill_results refactor.  Doesn't work well yet.
23:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41721/
23:30 * 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.
23:31 Tene 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
23:34 whiteknight holy crap Tene! You said it would break a lot of tests, not ALL of them
23:35 davidfetter joined #parrot
23:35 Tene whiteknight: what do you expect for a half-implemented fill_returns?
23:35 whiteknight haha, nice!
23:36 Tene afk
23:40 Tene I would have put it in a branch, but...
23:44 * bacek finally lost in over-complicated logic of fill_foo...
23:52 TonyC joined #parrot
23:59 rhr joined #parrot

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

Parrot | source cross referenced