Camelia, the Perl 6 bug

IRC log for #parrot, 2009-10-03

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 darbelo Heisenbugs! Whee!
00:02 allison joined #parrot
00:03 Whiteknight good evening allison
00:04 darbelo Out of memory panic. Nice.
00:04 Austin Whiteknight, I know there is (or used to be) code in the parrot tests that "knew" when it was being run in different test modes.
00:05 nopaste "darbelo" at 200.49.154.173 pasted "Seemingly inocent bt" (47 lines) at http://nopaste.snit.ch/18171
00:05 Austin 77 mb?
00:06 darbelo what?
00:06 Austin The allocation that failed.
00:07 Whiteknight okay, next failure now: Parrot_pcc_build_sig_object_from_op is trying to access an index in an FPA that's out of bounds
00:09 darbelo Austin: Yes. 77mb is too big.
00:09 Austin Is that the "seemingly innocent" part.
00:10 whoppix joined #parrot
00:10 darbelo No, the seemingly inocent part is the actual call chain up to the point where it runs out of memory.
00:11 Whiteknight extract_named_arg_from_op is using raw_index incorrectly
00:11 Austin Oh.
00:12 Whiteknight Everywhere else is using raw_index as a register index number, but extract_named_arg_from_op is using it as an index into the sig
00:12 darbelo It's trying to open a packfile (the includes in line 1 and 2 of that file's :main) and dies with out of mem while trying to allocate the string that holds the error message.
00:13 darbelo s/open a packfile/load_bytecode a file/
00:14 Whiteknight "PiSnPoIpSnPoIpSnPoIp"
00:14 Whiteknight that's a function signature
00:14 Whiteknight try saying that 5 times fast
00:15 darbelo Is that 10 arguments?
00:17 darbelo If that function is in parrot code I'm *so* going to cut it into pieces.
00:20 Whiteknight Pi is the invocant, Sn is an argument name, not an argument
00:20 Whiteknight so 6 args, three of which are named
00:20 Whiteknight no
00:20 Whiteknight three named optional arguments
00:20 cognominal joined #parrot
00:20 Whiteknight src/pmc/exporter.pmc:import
00:21 Austin What's PoIp ?
00:22 Whiteknight o is optional, p is opt_flag
00:22 Whiteknight so pmc :optional\n int :opt_flag
00:22 Austin ah
00:23 Whiteknight big letters are P S N I, little letters are the flags
00:23 Whiteknight and believe it or not, these are much saner then how sigs used to be
00:23 Austin So SnPoIp is string-named optional pmc with accompanying flag?
00:23 GeJ Good morning everyone
00:23 GeJ clock?
00:23 darbelo I keep getting this stuff mixed up with NCI signatures in my head.
00:23 purl GeJ: LAX: Fri 5:23pm PDT / CHI: Fri 7:23pm CDT / NYC: Fri 8:23pm EDT / LON: Sat 1:23am BST / BER: Sat 2:23am CEST / IND: Sat 5:53am IST / TOK: Sat 9:23am JST / SYD: Sat 10:23am EST /
00:23 Austin morning gej
00:24 darbelo An timezones be added to purl's clock?
00:25 Whiteknight Austin: exactly
00:25 Whiteknight hello GeJ!
00:25 Whiteknight GeJ: What day is it where you are?
00:25 darbelo He said morning.
00:25 darbelo I'm guessing saturday.
00:26 Whiteknight allison: ping
00:26 GeJ technically it's PCC hackathon day
00:26 Whiteknight GeJ: So get a'hackin'!!
00:26 Austin ChST -- Chamorro Standard Time.
00:26 hercynium joined #parrot
00:26 GeJ darbelo: I usually fool everybody with that. I'll assume it's always morning for someone on IRC.
00:27 Whiteknight ah nevermind, allison unping
00:28 Austin Guam! "Where America's Day Begins."
00:28 rhr joined #parrot
00:28 GeJ checking branches/pcc_reapply out
00:29 GeJ that's the one right?
00:29 Whiteknight yessir
00:29 Whiteknight ah, I think I found it!
00:29 darbelo GeJ: Was it you that had a failing FreeBSD box after the kill-next_for_GC merge?
00:29 * darbelo afk
00:30 GeJ yup. but not anymore. Whatever you did, thanks.
00:30 Whiteknight nopaste?
00:30 purl hmmm... nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or https://trac.parrot.org/parrot/br​owser/trunk/tools/dev/nopaste.pl
00:30 cognominal joined #parrot
00:30 nopaste "whiteknight" at 69.249.176.251 pasted "Anybody else see what I see?" (2 lines) at http://nopaste.snit.ch/18172
00:34 GeJ Well, for one, I have no idea of what I'm looking at.
00:35 Whiteknight haha, it's part of the new PCC awesomeness
00:35 GeJ ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir  --output=PGE/builtins_gen.pir PGE/builtins.pg
00:35 GeJ shift_string() not implemented in class 'String'
00:35 GeJ *br0tch*.
00:35 Whiteknight but the important part is that all other arguments in that function call are passed as pointers, while the string names are not
00:36 Whiteknight which causes segfault fun anytime a C-based PMC method is called with named arguments
00:36 GeJ that's what I get on my bug-magnet FreeBSD box while trying to build pcc_reapply.
00:37 Whiteknight GeJ: yeah, lots of failures
00:38 darbelo GeJ: you should stick to "make corevm" and "make coretest" for now.
00:39 darbelo A full parrot is unlikely to build before the core's fixed.
00:40 Whiteknight I've got two fixes coming in that should have a beneficial effect
00:40 darbelo Whiteknight++
00:41 dalek parrot: r41625 | whiteknight++ | branches/pcc_reapply/lib/P​arrot/Pmc2c/PCCMETHOD.pm:
00:41 dalek parrot: [pcc] named argument name strings in C-based PMCs were not being filled correctly because we were missing an ampersand on them. Fix that.
00:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41625/
00:41 dalek parrot: r41626 | whiteknight++ | branches/pcc_reapply/src/call/pcc.c:
00:41 dalek parrot: [pcc] raw_index is the index into the register arrays, NOT the index into the arg flags FIA. fix the issue
00:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41626/
00:47 nopaste "dukeleto" at 69.64.235.54 pasted "Primes.pasm runtime (in seconds) across released versions of Parrot and trunk (r41609)" (13 lines) at http://nopaste.snit.ch/18173
00:47 dukeleto nice work peeps, trunk is fastest
00:49 dukeleto there was a huge jump in performance between 1.2 and 1.3
00:50 dukeleto roughly 20x speed improvement for primes.pasm
00:50 quek left #parrot
00:51 darbelo Aha! I think I found the source of the invalid STRINGs in the io subsystem.
00:52 Austin Isn't undef supposed to stringify to "" (empty string) ?
00:53 darbelo undef's supposed to stringify?
00:53 treed I wouldn't expect it to stringify at all?
00:53 * treed is decidedly not a perl person, though.
00:55 * darbelo leaves for a while.
00:55 darbelo Laters!
00:55 darbelo left #parrot
00:58 quek joined #parrot
00:58 kid51 joined #parrot
01:00 quek left #parrot
01:01 patspam joined #parrot
01:02 whoppix joined #parrot
01:03 kid51 During the outage, I pasted this 'make coretest' output from the pcc_reapply branch:  http://nopaste.snit.ch/18174
01:04 quek joined #parrot
01:04 Whiteknight Parrot_pcc_fill_params_from_c_args is definitely filling arguments incorrectly
01:05 dukeleto Coke: ping!
01:05 quek left #parrot
01:06 quek joined #parrot
01:07 Whiteknight or, it's getting bad signature information
01:07 quek left #parrot
01:08 quek joined #parrot
01:10 quek left #parrot
01:10 Whiteknight In the pattern SnPoIp, the opt_flags are being marked as positional arguments and iterated that way
01:10 Whiteknight when that's clearly not what it's supposed to be (it's a flag on a named arg in this case)
01:10 quek joined #parrot
01:11 quek left #parrot
01:14 Whiteknight well, actually I don't know in that case what the Ip should be listed as
01:23 Whiteknight PiSnPoIpSnPoIpSnPoIp is being processed as if it has 3 positional arguments
01:23 Whiteknight so I'm not sure where those are coming from
01:24 whoppix_ joined #parrot
01:26 dalek TT #1088 created by Austin_Hastings++: Multidispatch 'concatenate_str' does not handle LHS undef
01:29 quek joined #parrot
01:29 bacek o hai
01:32 Whiteknight I think I've got it
01:32 Whiteknight hello bacek
01:32 Whiteknight happy hackathon day!
01:32 bacek Whiteknight: not for me. It's "Happy Kids day"
01:33 Whiteknight bacek: that's a good day too!
01:33 Whiteknight technically I'm coding yesterday, but I'm starting hackathon day early
01:35 quek left #parrot
01:36 quek joined #parrot
01:37 dukeleto hola
01:38 quek left #parrot
01:38 quek joined #parrot
01:41 joeri left #parrot
01:43 quek left #parrot
01:43 quek joined #parrot
01:47 Coke dukeleto: pong
01:50 Whiteknight ...lots of little fixes...
01:52 dalek parrot: r41627 | whiteknight++ | branches/pcc_reapply/src/call/pcc.c:
01:52 dalek parrot: [pcc] move around the logic for handling optionals. Named params can be optional too, but the fill_params_* functions were short circuiting when a named argument was found and were not setting the correspondig opt_flag. This fixes that issue
01:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41627/
01:56 Coke anyone who has committed to partcl, do you have a github id?
01:58 TiMBuS joined #parrot
02:01 rhr joined #parrot
02:01 whoppix_ joined #parrot
02:06 Coke crud, I think I missed dukeleto.
02:06 Coke dukeleto++
02:18 dalek rakudo: f529b41 | (Solomon Foster)++ | src/setting/ (3 files):
02:18 dalek rakudo: Full support for Complex cosec and acosec.
02:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​529b41dce20e36e0eb6eb25dff952489e4c0121
02:18 shorten dalek's url is at http://xrl.us/bfpwhz
02:18 dalek rakudo: 54c4564 | (Solomon Foster)++ | src/setting/ (3 files):
02:18 dalek rakudo: Full support for Complex cotan and acotan.
02:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​4c4564fba55f03c40dfb831666d1d514da4684c
02:18 shorten dalek's url is at http://xrl.us/bfpwh3
02:18 dalek rakudo: 16a2810 | (Solomon Foster)++ | src/setting/ (3 files):
02:18 dalek rakudo: Full support for Complex sinh and asinh.
02:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​6a2810fd5bf7773ff04997c9cecf59c91cd359c
02:18 shorten dalek's url is at http://xrl.us/bfpwh7
02:18 dalek rakudo: fc29434 | (Solomon Foster)++ | src/setting/ (3 files):
02:18 dalek rakudo: Full support for Complex cosh and acosh.
02:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​c29434a8a80de648ea125bb6112af9067cab5a0
02:18 shorten dalek's url is at http://xrl.us/bfpwh9
02:18 dalek rakudo: d5b578b | (Solomon Foster)++ | src/setting/ (3 files):
02:18 dalek rakudo: Full support for Complex tanh and atanh.
02:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​5b578b550e43d7aaca95cae4bf5181edd9e2402
02:18 shorten dalek's url is at http://xrl.us/bfpwib
02:18 dalek rakudo: 396f318 | (Solomon Foster)++ | src/setting/ (3 files):
02:18 dalek rakudo: Full support for Complex sech and asech.
02:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​96f318937b4a49859cd74ef94cd0cfca0a25b16
02:18 shorten dalek's url is at http://xrl.us/bfpwid
02:18 dalek rakudo: 7bfbe77 | (Solomon Foster)++ | src/setting/ (3 files):
02:18 dalek rakudo: Full support for Complex cosech and acosech.
02:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​bfbe7725e340eb46cd1fa916bc84045a6fb24aa
02:18 shorten dalek's url is at http://xrl.us/bfpwif
02:18 dalek rakudo: 197b1e1 | (Solomon Foster)++ | src/setting/ (3 files):
02:18 dalek rakudo: Full support for Complex cotanh and acotanh.
02:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​97b1e1190220196d75ea7048da020e70d2ca8b2
02:18 shorten dalek's url is at http://xrl.us/bfpwih
02:18 dalek rakudo: e976f23 | (Solomon Foster)++ | t/spectest.data:
02:19 dalek rakudo: Update the spectest to run the new trig tests.
02:19 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​976f23c73dd9fa68da194ab92a7c44a25fb04d6
02:19 shorten dalek's url is at http://xrl.us/bfpwij
02:19 Coke darbelo: ping.
02:19 Coke darbelo?
02:19 purl darbelo is Daniel Arbelo Arrocha <mailto:arbelo@gmail.com>
02:24 kid51 joined #parrot
02:25 dalek parrot: r41628 | whiteknight++ | branches/pcc_reapply/src/pmc/capture.pmc:
02:25 dalek parrot: [pcc] fix some of the mark logic in Capture PMC to just make sure that everything that I think should be getting marked is actually getting marked
02:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41628/
02:26 quek left #parrot
02:27 Coke dukeleto?
02:27 purl somebody said dukeleto was still employeed. i "made the cut" in our CEO's words
02:29 quek joined #parrot
02:30 kid51 joined #parrot
02:36 janus joined #parrot
02:40 whoppix_ joined #parrot
02:41 quek left #parrot
02:41 quek joined #parrot
02:44 quek left #parrot
02:44 quek joined #parrot
02:47 kid51 joined #parrot
02:48 cconstantine joined #parrot
02:54 diakopter Coke?
02:54 purl Coke is probably Will Coleda <mailto:will@coleda.com> or perpetually annoyed. or magical ticket robot or (if Diet), something that turns into formaldehyde in my blood.
02:59 Coke hio
03:00 whoppix joined #parrot
03:00 Whiteknight urg, this PCC argument processing state machine is a big pain
03:07 Whiteknight purl msg allison Parrot_pcc_fill_params* has a lot of problems, especially with optional parameters. I committed a fix earlier but it isn't enough. When filling args there's a difference between "the last storage space was an optional arg" and "we actually had a value to put there". Two meanings, but we only have one flag
03:07 purl Message for allison stored.
03:08 Coke relax your mind: http://www.cesmes.fi/
03:09 nopaste "Whiteknight" at 69.249.176.251 pasted "example patch for allison++" (126 lines) at http://nopaste.snit.ch/18175
03:10 darbelo_ joined #parrot
03:10 Whiteknight purl msg allison check out http://nopaste.snit.ch/18175 for an example of what I am talking about. Incomplete, but shows one way we could account for the different issues here.
03:10 purl Message for allison stored.
03:10 darbelo_ Coke: pong
03:11 Whiteknight and with that, I need me some sleep
03:11 Whiteknight goodnight
03:13 rhr joined #parrot
03:14 darbelo_ purl: msg Coke I'm "darbelo" on github if that is what you were going to ask me.
03:14 purl Message for coke stored.
03:14 Coke msg dukeleto darbelo is darbelo on github.
03:14 purl Message for dukeleto stored.
03:27 darbelo_ Coke: ping
03:30 whoppix joined #parrot
03:31 darbelo_ Oh. Nevermind
03:31 darbelo_ Coke: un-ping
03:55 dalek parrot: r41629 | mikehh++ | branches/pcc_reapply/lib/Parrot/Pmc2c/Method.pm:
03:55 dalek parrot: fix some codetest errors - trailing whitespace and cuddled else
03:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41629/
04:03 quek left #parrot
04:04 whoppix joined #parrot
04:04 TonyC joined #parrot
04:05 Zak joined #parrot
04:07 quek joined #parrot
04:14 theory joined #parrot
04:19 quek left #parrot
04:20 whoppix joined #parrot
04:34 zak_ joined #parrot
04:47 Zak joined #parrot
04:48 kyle_l5l joined #parrot
05:02 whoppix joined #parrot
05:09 Zak joined #parrot
05:48 tokuhirom________ joined #parrot
05:51 dalek parrot: r41630 | pmichaud++ | branches/pct-rx/compilers/pct/src/Regex (2 files):
05:51 dalek parrot: [pct-rx]:  Refactor Cursor.!matchify, add Cursor.!subrule, other cleanups.
05:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41630/
06:22 ZeroForce joined #parrot
06:23 dalek parrot: r41631 | pmichaud++ | branches/pct-rx/compilers/pct/src/Regex (2 files):
06:23 dalek parrot: [pct-rx]:  Add Cursor.!literal, P6Regex.quantmod.
06:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41631/
07:17 iblechbot joined #parrot
07:50 quek joined #parrot
07:58 quek left #parrot
07:59 quek joined #parrot
08:04 quek left #parrot
08:04 quek joined #parrot
08:10 quek left #parrot
08:10 quek joined #parrot
08:34 bacek joined #parrot
08:35 Khisanth joined #parrot
08:44 quek left #parrot
08:46 quek joined #parrot
08:58 quek left #parrot
09:00 quek joined #parrot
09:04 quek left #parrot
09:05 quek joined #parrot
09:10 quek left #parrot
09:10 quek joined #parrot
09:16 quek left #parrot
09:17 quek joined #parrot
09:38 quek left #parrot
09:43 Austin joined #parrot
09:57 darbelo joined #parrot
10:06 whoppix joined #parrot
10:24 Whiteknight joined #parrot
10:28 darbelo Ugh. freeze and io are so entangled it hurts.
10:33 Whiteknight happy hackathon day!
10:37 Whiteknight ...now if only we can get this argment procesing stuff to work
10:53 Austin Create a new branch, called UN. Just pretend the arguments don't happen.
11:00 joeri joined #parrot
11:01 mikehh hi Whiteknight
11:01 Whiteknight hello mikehh
11:03 mikehh I still fail to build in the pcc_reapply branch - PGE fails with shift_string() not implemented in class 'String'
11:03 Whiteknight yeah, that's expected
11:04 Whiteknight you need to "make corevm" to just build parrot and not the rest of the library, and then "make coretest" to test it
11:04 mikehh I have been using make corevm coretest etc and make codetest works
11:04 Whiteknight there is some functionality missing still that PGE requires
11:04 Whiteknight ok
11:21 einstein joined #parrot
11:27 Whiteknight okay, there is something wrong with the set_args op
11:29 Whiteknight er, maybe not. nevermind
11:42 dalek parrot: r41632 | whiteknight++ | branches/pcc_reapply/src/call/pcc.c:
11:42 dalek parrot: [pcc] two changes to the arg-handling code:
11:42 dalek parrot: 1) sig building code was broken on named arguments, attempted to extract a named arg without first updating the index pointer to point to the next one. This means the name of the arg was itself being taken as the name and then the arg too (leading to :named args always being a String PMC).
11:42 dalek parrot: 2) Some changes to the arg filling code to handle named optional params. There is a semantic mixup between 'have storage available for an optional' and 'have an actual value to use in it'. This fix is not perfect and probably needs to be rethought.
11:42 dalek parrot: Net result is a handful of new passing subtests, especially in t/pmc/class.t where I am focusing my current debugging
11:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41632/
11:54 Whiteknight there is definitely a problem with the counting of positional elements
11:54 Whiteknight I just don't know what that problem is yet
11:56 allison Whiteknight: it's not really a semantic mixup, it's just the fact that we have two lists: the available arguments and the requested parameters
11:56 allison Whiteknight: coordinating between the two is the task of this chunk of code
11:56 Whiteknight right, there was a little bit of a mixup in there though
11:57 Whiteknight r41632 fixes the mixup and adds a few passing tests (though I don't like the solution)
11:57 Whiteknight the one flag got_optional was pulling double-duty: trying to tell when we had an optional container to fill, and when we had a value to put in it
12:00 Whiteknight What I'm tracking down now is a problem with overflow in positional arguments.
12:00 mikehh you get a codetest failure on the last commit - line length # /home/mhh/pcc_reapply/src/call/pcc.c:1237: 102 cols
12:01 Whiteknight src/call/pcc.c:1014 "if (positional_index >= positional_elements) {..." positional_elements is the number passed, not expected. So this exception never triggers
12:01 allison Whiteknight: (re: got optional) makes sense
12:02 mikehh I am also getting assert args failures with:
12:02 purl okay, mikehh.
12:02 mikehh # unused assert macros found:
12:02 mikehh # /home/mhh/pcc_reapply/include/parrot/call.h: Parrot_pcc_get_call_sig_raw_args
12:02 mikehh # /home/mhh/pcc_reapply/include/parrot/call.h: Parrot_pcc_get_call_sig_raw_returns
12:02 mikehh # /home/mhh/pcc_reapply/include/parrot/call.h: Parrot_pcc_set_call_sig_raw_args
12:02 mikehh # /home/mhh/pcc_reapply/include/parrot/call.h: Parrot_pcc_set_call_sig_raw_returns
12:02 mikehh # 4 unused assert macros found in total.
12:03 mikehh I was looking at them but can't quite figure out where they come from
12:04 Whiteknight mikehh: probably need to make headerizer to get them to disappear
12:04 mikehh tried that - no svn diff
12:04 Whiteknight well that's weird
12:05 cconstantine joined #parrot
12:05 mikehh let me try again
12:05 allison mikehh: they were defined before, but no longer used. The headerizer should remove them.
12:06 mikehh ok - I have something odd - will check again
12:07 Whiteknight in Parrot_pcc_fill_params_from_op, call_object is the CallSignature with passed-in parameters, and raw_sig is the list of expected containers?
12:08 Whiteknight well, raw_sig is the list of flags of expected containers?
12:08 allison mikehh: looks like it's a bug in the headerizer, it doesn't remove sections if the file doesn't exist
12:08 allison the file was src/call/callsignature.c
12:09 allison mikehh: if you just delete that whole section of include/parrot/call.h, it should take care of it
12:10 allison Whiteknight: yes, but we don't need to store that on the call signature anymore
12:14 mikehh just did a clean checkout - something was wrong - we'll see now
12:17 Whiteknight urg, some of these results make no sense
12:19 allison mikehh: well, those headers are in mine too, and not removed by running headerizer
12:29 kid51 joined #parrot
12:39 nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: 'make' failure between 41626 and 41632" (664 lines) at http://nopaste.snit.ch/18179
12:40 dalek parrot: r41633 | allison++ | branches/pcc_reapply/t/pmc/parrotobject.t:
12:40 dalek parrot: [pcc] Updating error message on incorrect number of arguments.
12:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41633/
12:41 kid51 Hmm, that paste did not capture all the output.
12:41 jsut_ joined #parrot
12:45 kid51 'make corevm' actually completed; but 'make smolder_coretest' failed quickly
12:47 nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: early termination for 'make smolder_coretest' at 41632" (82 lines) at http://nopaste.snit.ch/18180
12:47 sjn left #parrot
12:53 mikehh kid51 - I get that failure when I try make world - PGE fails with shift_string() not implemented in class 'String'
12:53 dalek parrot: r41634 | allison++ | branches/pcc_reapply/t/pmc/sub.t:
12:53 dalek parrot: [pcc] Updating error message for parameter count mismatch.
12:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41634/
12:54 mikehh make corevm coretest works though
12:58 kid51 Yes, but that doesn't generate a Smolder report.
12:59 kid51 So the question arises:  Should 'smolder_coretest' be changed from:
12:59 kid51 smolder_coretest : test_prep
12:59 purl somebody said test_prep was the 'make' target on which 'make test' immediately depends and is currently equivalent to 'make'
12:59 kid51 $(PERL) t/harness $(EXTRA_TEST_ARGS) --core-tests --archive --send-to-smolder
12:59 kid51 to:
12:59 kid51 smolder_coretest : corevm
12:59 kid51 $(PERL) t/harness $(EXTRA_TEST_ARGS) --core-tests --archive --send-to-smolder
13:00 darbelo kid51: +1
13:00 purl 1
13:00 darbelo purl: die in a fire.
13:00 purl HALP
13:01 kid51 I think I'll make that change in the pcc_reapply branch, at least for this period of intense concentration on core tests in that branch.
13:04 dalek parrot: r41635 | jkeenan++ | branches/pcc_reapply/config/gen/makefiles/root.in:
13:04 dalek parrot: Change 'make' target 'smolder_coretest' to depend on 'corevm' rather than 'test_prep' (which in turn depends on 'all').  This will enable Smolder reporting equivalent to 'make corevm coretest'.
13:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41635/
13:04 purl dalek: that doesn't look right
13:06 jsut joined #parrot
13:08 cconstantine joined #parrot
13:10 kid51 I just posted to list about this.
13:10 cconstantine joined #parrot
13:14 kid51 Here's the Smolder report at 41632:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28482
13:14 shorten kid51's url is at http://xrl.us/bfp6v4
13:19 jsut_ joined #parrot
13:30 Whiteknight urg, the list of test failures is so daunting
13:34 mikehh I tried deleting the relevant headerizer section in pcc_reapply/include/parrot/call.h and various options including re-doing make headerizer - but it blows up with compilers/imcc/imcparser.c
13:35 mikehh i had to delete include/parrot/call.h and compilers/imcc/imcparser.c and svn update again
13:46 allison Whiteknight: but the list of test failures is also half as long as it was 2 days ago :)
13:46 allison Whiteknight: small fixes have a big impact
13:51 Whiteknight I am convinced that the majority of remaining failures have to do with this argument processing algorithm
13:52 allison Whiteknight: very likely
13:52 allison Whiteknight: though some of them also have to do with return processing
13:53 allison Whiteknight: at the moment, it's a monolithic mess
13:53 allison Whiteknight: I'd like to break it down into a more maintainable state
13:53 allison Whiteknight: and suspect that as we do that, we'll likely uncover the bugs
13:55 mikehh Whiteknight - if I fix the codetest linelengh errors in src/call/pcc.c is that going to mess you up?
13:55 allison Whiteknight: would you like to walk through one together, and see if we can come up with a good refactoring strategy?
13:59 allison Whiteknight: step one is to move all the argument handling functions to a separate file, src/call/args.c or somthing like that
14:01 Whiteknight allison: yes, a walkthrugh to figure out a refactor would be very good
14:01 Whiteknight I would have started it myself already, but I didn't want to introduce too many changes
14:02 allison Whiteknight: changes are fine at this point, we'll have to live with this code for a long time
14:02 Whiteknight if the code gets cleaner, more people will be empowered to modify and improve it
14:03 allison the next step I'd take is to start breaking down each section into a separate subroutine (like "handle slurpy args", "handle named args", etc)
14:03 cconstantine joined #parrot
14:03 allison that'll make the main subroutine much easier to follow
14:03 mikehh src/call/pcc.c is 4159 line long - that is not good
14:04 Whiteknight mikehh: get your machete ready, we've got some rubbish to clear
14:04 cconstantine is there a way to :flat arguments in NQP?
14:05 kid51 mikehh:  If you fix the long lines, at least you'll be looking at the code ;-)
14:05 allison Whiteknight: it would be nice to be able to merge Parrot_pcc_fill_params_from_op and Parrot_pcc_fill_params_from_c_args, because the logic is exactly the same
14:05 allison only the way of accessing values is different for each
14:06 allison but, the only way I can think to merge them is using function pointers, which is a maintenance headache anyway
14:06 Whiteknight allison: I had those exact thoughts as well
14:06 allison it might be possible to reverse the logic
14:07 Whiteknight I have to disappear for a bit. Pregnant wife craves orange juice and getting it is my only superpower
14:07 * Whiteknight will be back soonish
14:07 allison k
14:07 * allison has to go pick up a dead laptop, will be back soon too
14:07 dalek parrot: r41636 | mikehh++ | branches/pcc_reapply/src/call/pcc.c:
14:07 dalek parrot: fix codetest - line length > 100
14:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41636/
14:10 einstein joined #parrot
14:11 einstein I see that socket.pmc clone function does return SELF; is that correct?
14:15 jsut joined #parrot
14:23 einstein I see that socket.pmc clone function does return SELF; is that correct? shall I open ticket for that one?
14:23 Psyche^ joined #parrot
14:26 mikehh messed something up there
14:46 kid51 mikehh:  I think I got it
14:46 dalek parrot: r41637 | jkeenan++ | branches/pcc_reapply/src/call/pcc.c:
14:46 dalek parrot: Fix correction of line lengths.
14:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41637/
14:50 kid51 I've found that, in fixing linelengths, if you have to break an arglist, it's best to do so right after the opening parenthesis.
14:50 kid51 Although I don't know why breaking in the middle of the arglist caused those problems.
14:51 theory joined #parrot
14:52 mikehh kid51: yes - you just beat me to it - but I agree - it seems not to like CONST_STRING
14:54 kid51 Were those 3 lines where CONST_STRING is used actually giving linelength errors?
14:55 kid51 (I reverted to r41632 and made my corrections therefrom.)
14:57 mikehh kid51: yes  make codetest passed linelength but I didn't do a regular make until I had commited and then it failed
14:57 * mikehh must follow proper procedures
14:58 cognominal joined #parrot
14:59 Whiteknight back
15:00 kid51 Latest smolder on pcc_reapply branch:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28485
15:00 shorten kid51's url is at http://xrl.us/bfp96s
15:01 slavorg joined #parrot
15:01 kid51 pcc_reapply:  t/codingstd/c_arg_assert.t has failures; otherwise make codetest passes
15:02 * kid51 goes to gym
15:03 jsut_ joined #parrot
15:14 kjeldahl joined #parrot
15:23 iblechbot joined #parrot
15:53 Coke mikehh: in case it was not clear, CONST_STRING needs to be on one line.
15:54 Whiteknight I don't really understand that restriction
15:54 Whiteknight I mean, I follow it, but it seems stupid
15:59 allison Whiteknight: it is stupid, it's a bug/feature of the way CONST_STRING is parsed and stored
15:59 Whiteknight okay, just so we're all clear
16:08 allison Whiteknight: I just got back and am thinking of working on return handling next, will that overlap with anything you're working on?
16:09 Whiteknight I don't even know what I am working on right ow
16:09 Whiteknight but I will avoid that
16:09 allison okay, I think I'll start by moving return handling out to a separate file
16:09 Whiteknight ok
16:10 allison eventually, I'd like return and parameter handling to be unified, so I'm thinking src/call/args.c
16:10 Whiteknight In passed arguments, positions must be passed first and named must be passed thereafter, right?
16:10 allison can you think of a better name?
16:10 Whiteknight args.c is good for now
16:10 allison Whiteknight: yes, positional, then named
16:11 kjeldahl joined #parrot
16:11 Whiteknight okay, so if I break up this huge statemachine into two separate loops, that would be good?
16:11 allison one for positionals and one for named?
16:11 allison will that work with the :lookahead option?
16:12 * allison looking for description and failing
16:12 Whiteknight depends where :lookahead args will be ordered
16:12 Whiteknight will they be after the positionals, or mixed in with them?
16:12 allison but, IIRC, what patrick needed was a way for a positional parameter to check and see if there was a corresponding named argument
16:13 Whiteknight right, so fill with a named first, positional otherwise
16:13 allison actually, it should be okay
16:13 Whiteknight we can still do that in the positional loop
16:13 Whiteknight okay
16:13 allison because your two loops are going over the parameters
16:13 allison the arguments are all there ready in the call signature
16:14 allison (so positional processing can pull from either positional or named arguments with no troubles)
16:14 allison positional *parameter* processing, that is
16:14 Whiteknight yeah
16:15 allison do you have a src/call/args.c already, or should I go ahead and create one?
16:26 Whiteknight create one
16:26 Whiteknight This argument processing algorithm is too damn complicated. There's no good way to do this
16:28 Austin Where is it, whiteknight?
16:28 Whiteknight I don't know if there is a concise description of the algorithm anywhere
16:28 Austin No, what file is it in?
16:29 Whiteknight but the current code is in src/call/pcc.c:Parrot_pcc_fill_params_from_op (in the pcc_reapply branch)
16:29 Austin 'kl
16:29 Whiteknight and Parrot_pcc_fill_params_from_varargs
16:29 allison Whiteknight: no, there isn't, I started this variation as "it has to handle everything the current system handles"
16:29 masak joined #parrot
16:29 allison Whiteknight: looking at the old code may be helpful
16:30 Whiteknight yeah, I'm going to have to do that, I think
16:30 allison but, the old code had two completely different strategies for calling from PIR and calling from C, so it's even worse
16:30 Whiteknight trust me, I have no illusions that I'll be able to salvage much from there
16:31 Whiteknight but getting an idea about how they handle all these options, and handle them in a way that isn't O(n^30) would be good
16:33 dalek parrot: r41638 | allison++ | branches/pcc_reapply/src/call/args.c:
16:33 dalek parrot: [pcc] Add a new file for argument processing and move the return handling
16:33 dalek parrot: functions into it.
16:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41638/
16:33 Austin Actually, a good question would be "what's the problem?"
16:34 Whiteknight Austin: It's just a very complicated algorithm
16:34 Austin It is?
16:34 purl Oh no it isn't!
16:35 Whiteknight when you consider :named, :optional, :opt_flag, and :slurpy parameters, yes
16:35 allison Whiteknight: the logic itself is fairly straightforward, but once you write out all the details it's a mess
16:35 Whiteknight yeah, thats what I mean
16:35 allison and, at the moment they're all lumped in one bunch
16:36 allison which makes it really difficult to wrap a head around it
16:36 Austin So what are the rules?
16:37 Austin Is there a pdd that details them?
16:39 allison Austin: pdd03_calling_conventions.pod specifies what flags it has to support
16:43 Whiteknight I'm running into difficulties with handling optional and opt_flag parameters
16:44 allison Whiteknight: will it mess you up if I go ahead and move the fill_params routines into the new file?
16:44 Whiteknight allison: no. I'm trying to outline an algorithm in pseudocode right now
16:44 Whiteknight ...and failing miserably
16:44 allison Whiteknight: okay, cool, I'll do it now
16:44 Whiteknight w00t
16:45 allison Whiteknight: think of it as a finite state machine
16:45 allison you loop over each param, and take various actions depending on the type of param it is
16:46 allison we could reverse it and loop over the args instead
16:46 Whiteknight yeah, I know how to do it. It's structuring and organizing all those actions that is getting complicated
16:46 dalek parrot: r41639 | allison++ | branches/pcc_reapply (4 files):
16:46 dalek parrot: [pcc] Set up compiling for new arg processing file, and run the headerizer.
16:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41639/
16:46 allison which would have the advantage that the args are always the same whether we're dealing with a PIR or C call
16:48 allison Whiteknight: okay, I'm moving everything to do with argument/return handling into src/call/args.c, including the various ways of building a call signature object
16:49 Whiteknight okay, I'll wait for that and update before making any more changes
16:52 Austin Is this mechanism aware of arg-flattening, and generators? Or is that expected to happen before this code is reached?
16:52 Whiteknight flattening happens when the signature is created
16:52 Whiteknight this is the code where the signature is disected
16:52 Austin Boggle<!>
16:53 Whiteknight What would make this all marginally easier is if CallSignature was an iterator
16:54 Austin So a CallSignature is a run-time thing?
16:54 allison Whiteknight: CallSignature could become an iterator
16:54 Whiteknight Austin: yeah, it's a PMC type that's like a combination of Array and Hash (with some additional info)
16:54 Austin Mkay
16:54 Whiteknight allison: I'm idly speculating. We would need to be able to iterate separately over named and positionals
16:54 allison Whiteknight: though, would you really want to different iterations, one over positonal and one over named?
16:55 allison yes, same thought at same time :)
16:55 Austin Is that the raw_sig input argument to _from_op?
16:55 allison Austin: the raw_sig is a fixed integer array of flags
16:55 allison it's created by IMCC
16:56 Austin So where's this CallSignature?
16:56 allison and gives the attributes of each argument/parameter/return
16:56 Whiteknight src/pmc/callsignature.pmc
16:56 allison Austin: it's purely internal, and acts as the mediator between the various different ways of passing args/returns
16:56 Whiteknight and it's the PMC * call_object there
16:57 Austin okay.
16:58 Whiteknight My wife went to the mall alone, came home with a box of marshmallow-covered caramel apples
16:59 Whiteknight note to self: pregnant wife doesn't shop alone
16:59 dalek parrot: r41640 | allison++ | branches/pcc_reapply (3 files):
16:59 dalek parrot: [pcc] Move remaining argument/return handling functions into separate file.
16:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41640/
16:59 Austin So if I say, in PIR, 7   'foo'( $P0 :flat )   then I get a raw_sig that says "you passed 1 positonal+flat" at compile time, and a CallSignature at run time that says ($P0) ?
16:59 Austin *positional
17:00 allison yes
17:00 allison The CallSignature contains the actual list of arguments passed
17:00 Austin Should fill_params_from_op be a CallSignature method?
17:01 Whiteknight no
17:01 Whiteknight this is the method-calling code. We would get into an infinite loop
17:01 allison Austin: no, CallSignature is just one piece of information
17:02 Austin What's the obverse of a CallSignature?
17:02 Austin A CalleeSignature?
17:02 Austin ParamList?
17:02 allison Whiteknight: I moved the functions over, so update before further work
17:02 allison Austin: CallSignature is both arguments and return values
17:03 allison Austin: there is no equivalent for parameters, they just pull from CallSignature
17:03 Austin Yes, but it is the "given" side -- the "args". Is there a "taking" or "params" side for the recipient?
17:03 Whiteknight right, call signature contains information from the caller (args and expected returns). The Sig FIA contains information about the callee
17:03 Whiteknight well, contains some information about the callee
17:04 allison Austin: there are two functions, one to store the arguments in the CallSignature, and one to extract the parameters from the CallSignature
17:04 allison both use CallSignature
17:04 Austin Ah.
17:05 allison and, Whiteknight is right, IMCC generates a fixed integer array separately for arguments and parameters, which determines how the args are stored and parameters extracted from CallSignature
17:06 Austin Are the params always registers?
17:08 allison Austin: no, they can also be NCI
17:08 Austin The args, or the params?
17:08 allison that's why we have two variants on fill_params, one "from_op" and one "from_c_args"
17:08 allison Austin: both
17:09 Austin Hmm
17:09 allison any subroutine can be called from PIR or C, and any subroutine can be written in PIR or C
17:09 Austin Sure.
17:09 dalek parrot: r41641 | allison++ | branches/pcc_reapply/src/call/pcc.c:
17:09 dalek parrot: [pcc] Delete static function no longer used in this file (usage has moved to
17:09 dalek parrot: src/call/args.c).
17:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41641/
17:10 allison standardizing on CallSignature in the middle means that the parameter side doesn't have to know anything about how it was called
17:10 allison and the argument side doesn't have to know anything about the subroutine being called
17:14 allison didn't we remove the JIT? Why does src/frame_builder.c still exist?
17:14 kj joined #parrot
17:15 nopaste "whiteknight" at 69.249.176.251 pasted "argument processing algorithm outline" (42 lines) at http://nopaste.snit.ch/18181
17:15 Whiteknight allison: frame_builder is the only part of JIT that we kept
17:16 dalek parrot: r41642 | kjs++ | trunk/compilers/pirc/src/pircompunit.h:
17:16 dalek parrot: [pirc] add some more comments to pircompunit.h; I start forgetting what some struct fields are for.
17:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41642/
17:16 allison Whiteknight: what was the reasoning?
17:16 Whiteknight ask chromatic
17:16 Whiteknight there's a branch on github that reimplements the frame_builder using libJIT
17:16 Austin Why do _count variables use INTVAL?
17:17 allison ah... it looks like it contains a number of functions that used to be needed for calling NCI, but not needed anymore
17:17 darbelo It gives a startup and nci performace boost IIRC
17:17 allison Austin: INTVAL is just an int
17:17 Whiteknight oh yes, it is a big performance win, not having to register all the NCI thunks at startup
17:17 Austin allison: And optimizing named_count > 0 would be a lot easier if the compiler saw "unsigned"
17:18 kj Good $(daytime)
17:18 Whiteknight allison: does that algorithm I posted look sane?
17:18 kj Whiteknight: would it be an idea to create a finite state automaton picture based on that algorithm?
17:19 kj or is would that be overkill...
17:19 kj eh, remove some words in that sentence there
17:19 Whiteknight kj: I wouldn't even know how to go about making a good picture of it, but you're welcome to if you have the means
17:19 Whiteknight more documentation is always a good thing
17:19 allison Whiteknight: looking now...
17:21 darbelo allison: You have to watch out for the CAN_BULD_FRAMES #define in the frame builder. A completely different set of functions is used if that isn't available.
17:21 allison Whiteknight: I think you have to say "loop over all parameters and arguments"
17:22 allison Whiteknight: it's really a two-variable foreach loop
17:22 allison (a Perl 6 zip operation)
17:22 Whiteknight yeah, I was figuring that would be the case
17:23 allison I'd tweak the pseudocode to match
17:23 allison because, you actually need the "next" argument to check the first condition "no more arguments", but "get current argument" is listed after that check
17:24 allison Whiteknight: (this is a very helpful abstraction, to see it all boiled down to pseudocode)
17:25 Whiteknight allison: we can know that there are no more arguments without checking the next one, because we have a count of how many we got and how many we've processed
17:25 allison Whiteknight: we don't have a count of named arguments
17:26 allison only of positionals
17:26 Whiteknight we have a count of all passed arguments
17:26 Whiteknight (all passed) - (processed positionals) = (all named)
17:27 allison where is the all passed value coming from?
17:27 Whiteknight VTABLE_elements(interp, raw_sig)
17:28 allison that's a count of parameters, not arguments
17:28 allison and VTABLE_elements(interp, call_object) is a count of positionals
17:28 einstein joined #parrot
17:28 Whiteknight I keep getting those words mixed up
17:29 Whiteknight okay, let me redo the pseudocode and post it again
17:34 buildbot joined #parrot
17:35 Whiteknight are we going to support anything like :lookahead :slurpy?
17:35 Whiteknight or does that not even make any sense?
17:35 allison Whiteknight: I'd say no, :slurpy always has to come after all other parameters
17:36 Whiteknight and what does a named slurpy have for it's signature?
17:36 allison :named :slurpy
17:36 Whiteknight is that "Pns"?
17:36 allison or, what do you mean?
17:36 Whiteknight the signature string. how is a named slurpy listed in the sig string?
17:37 allison yes, Pns
17:37 allison PARROT_ARG_NAME & PARROT_ARG_SLURPY_ARRAY
17:37 allison (even though it's a hash)
17:37 Whiteknight right
17:38 allison Would love to rename that to PARROT_ARG_AGGREGATE
17:38 allison or PARROT_ARG_COLLECT
17:38 Whiteknight and how will a lookahead be listed? It has a name, so will it be SnPl?
17:38 allison next refactor
17:38 Whiteknight or will it be SnlP?
17:38 Whiteknight (I'm just trying to prepare)
17:39 allison lookahead is positional
17:39 Austin What's lookahead
17:39 purl well, lookahead is easy.. it's lookBACK that weirds me out
17:39 allison Austin: an option that pmichaud requested
17:40 allison Whiteknight: why is the action for a named arg always 'break'?
17:41 Austin whiteknight: the pseudocode around "if current arg is lookahead" is broken. Nesting, maybe?
17:41 Austin allison: named args mark the end of positionals in the upper loop.
17:41 allison you mean named parameters?
17:42 Austin I'll bite: What does lookahead *mean* ?
17:42 allison it means "check to see if there is a named argument for this parameter, otherwise use a positional argument to fill it"
17:43 Austin No, named args, according to the code. He's filling parameters from args, and if he sees a named arg, it means he can't fill any more params.
17:43 Whiteknight allison: because there are two loops. The first loop is only for positionals, so if we see a named break and enter the next loop
17:43 Whiteknight I'm about to paste a new version with only one loop. One second...
17:43 allison but, you're not going to see a named arg, because named args are in a different data structure
17:44 Austin That'll likely change the code :)
17:44 nopaste "whiteknight" at 69.249.176.251 pasted "pseudocode for arg processing for allison++" (41 lines) at http://nopaste.snit.ch/18182
17:46 Whiteknight this is why I want to write some pseudocode right now, to make sure I get all the details correct
17:46 Whiteknight don't want to waste time slinging code if it's going to be wron
17:46 allison Whiteknight: check slurpy before named, since slurpy trumps everything else
17:47 Whiteknight that's fine too
17:49 Whiteknight can :slurpy also be :optional, or is that implied/nonsensical?
17:49 Austin Is the sequencing rule {positional, optional, @slurpy, named, optional, %slurpy} still in place?
17:49 allison :slurpy is optional by definition (it takes 0 or more arguments)
17:49 Whiteknight that's what I figured
17:50 Whiteknight Austin: that's what I believe to be true, yes
17:50 Whiteknight A quick union here {INTVAL, FLOATVAL, STRING *, PMC *} will make a lot of this code much more streamlined
17:54 nopaste "whiteknight" at 69.249.176.251 pasted "more pseudocode for allison++" (40 lines) at http://nopaste.snit.ch/18183
17:56 Whiteknight eventually I'm going to get this right out of sheer luck
17:58 nopaste "allison" at 77.98.130.30 pasted "Simplified algorithm for parameter/argument iteration" (46 lines) at http://nopaste.snit.ch/18184
17:59 Austin how expensive is hash delete?
18:01 allison The CallSignature shouldn't be modified (if you're asking about deleting each named argument as it's used)
18:01 Austin http://nopaste.snit.ch/18185
18:01 Austin I was thinking shallow-copy + delete
18:01 Whiteknight that's sort of what I was thinking about with my iterator idea
18:02 allison Austin: it already is a shallow copy, but there's no advantage to deleting it from the CallSignature
18:03 Whiteknight I think there's benefit to be had by checking opt_flags at the same time as when we check optionals
18:03 allison Austin: nopaste#18185 ends up duplicating a good bit of behavior
18:03 Austin Speaking of shallow-copy, allison, what's the right way to propose a new/changed set of clone behaviors?
18:04 allison Austin: optional or non is mainly a question of what error condition to set
18:05 Austin Yeah, but clarity is worth something for my very small brain. Like, I can see that I missed setting the opt flags.
18:05 allison Austin: a mailing list message is often a good way to start a discussion
18:05 Austin I'll send the message, then. Thanks.
18:06 allison Whiteknight: your pseudocode is still mixing up arguments and parameters
18:07 allison "if current arg is slurpy"
18:07 allison args are never slurpy, params are
18:07 Whiteknight yeah
18:07 allison "if current arg is named" should actually be checking if current param is named
18:08 allison same with optional and opt_flag
18:08 allison the check for "no more arguments" can just go at the start of the loop, instead of repeating it before the loop and at the end of the loop
18:09 allison actually....
18:09 Austin Does the code support opt_flag for named params?
18:09 Whiteknight yessir
18:09 allison Austin: yes
18:10 allison so, the question of whether to fetch from positional or named arguments is determined by the type of the parameter
18:10 Austin Okay. Lookahead.
18:10 purl i guess lookahead is easy.. it's lookBACK that weirds me out
18:10 allison so, make "check next argument" a function instead of part of the loop
18:11 Austin Lookahead means "this parameter has a name and a position, and if the named setting is available, use that, else use the corresponding positional", correct?
18:11 Whiteknight allison: okay, so what does that function take and what does it return?
18:11 allison Austin: yes
18:11 Austin Can lookaheads be optional?
18:12 Austin (Of course)
18:12 allison Austin: yes, it can be "take the named if you've got it, else the positional, else nothing"
18:12 allison Whiteknight: it takes the call sig, and the current index, and returns a PMC
18:13 Whiteknight returns a PMC? wouldn't it need to return a union of P, N, S, I?
18:13 allison (alternatively, it can have 4 variants that return an INT, NUM, STRING, or PMC)
18:13 allison Whiteknight: the thing is, all args are currently stored as pmcs
18:14 allison Whiteknight: though, an early optimization is likely to be to make it possible to store them directly as the lower types
18:14 Whiteknight Okay, I guess I didn't realize hat
18:14 Whiteknight okay, return a PMC it is
18:15 Austin http://nopaste.snit.ch/18186
18:16 allison Austin: there are no default values
18:16 Austin For lookaheads?
18:16 allison Austin: that's what the opt_flag is for, to prevent you from looking at garbage
18:17 allison Austin: no defaults for any kind of parameters
18:17 Austin The current code sets things to 0/0.0/NULL/PMCNULL if no value is provided.
18:18 Whiteknight that's only if we don't pass enough arguments and if error checking is turned off
18:18 Austin Okay.
18:18 allison Whiteknight: of course, if we put "fetch the next argument" into a function, we lose the advantage of automatic boxing and unboxing
18:19 Austin So call it a feature: optionals now have a sane default value.
18:19 allison Austin: it's extra work, which means extra execution cost
18:19 allison Austin: and not necessary
18:21 Austin How not necessary?
18:23 allison Austin: the opt_flag tells you if you got an argument in that parameter
18:23 Austin And when you don't check it?
18:24 allison Whiteknight: I like the idea of separating out the storage of the argument into the parameter context out from the parameter/argument processing (from most recent nopaste), it has the potential to simplify the process as it goes along
18:25 allison Austin: you have to check it anyway to know if you were passed a 0 or just got a 0 by default
18:25 allison so, there's really no point in setting the default 0
18:26 Whiteknight allison: in your pseudocode, how do we know when we have run out of arguments? Are we keeping a counter?
18:26 allison Austin: various HLLs will set their own defaults, and will use opt_flag to know when they need to set a default
18:26 allison Whiteknight: second check in the infinite loop is "if there are not more arguments"
18:27 Whiteknight right, how do we check that?
18:27 Austin allison: I'm not thinking about HLL's. I'm thinking about people who are stumbling their way into PIR from "I'm trying to do scheme" or "I need to parse SQL"
18:27 allison Whiteknight: you can only check it for positionals
18:29 allison Whiteknight: which is why I started think of pushing the argument checking down to the point were you actually want an argument
18:29 Whiteknight there's a disconnect inside my mind about how we get all the necessary pieces of information together at once
18:29 allison Austin: all they need to know is "check opt_flag to see if you got an argument"
18:29 allison Austin: there is no "when they don't check it"
18:30 allison Whiteknight: which information?
18:31 allison for each parameter we need: its flags, the value from CallSignature
18:31 allison (and error checking if there is no available value)
18:32 Whiteknight how are named arguments stored in the CallSignature?
18:32 allison Whiteknight: in a hash
18:32 allison string keyed access on the CallSignature fetches a named argument
18:32 allison integer keyed access fetches a positional argument
18:34 Whiteknight okay, I think I'm starting to pick up what I was missing
18:35 allison the logic is simpler if "store the current arg in the destination context" is a function instead of part of the loop
18:35 Whiteknight Why in Parrot_pcc_fill_params_from_op do we need the opcode_t* from the caller?
18:36 Whiteknight wait, before that. What is raw_params?
18:36 Whiteknight that's the piece of this little puzzle that I don't understand
18:37 allison it's a pointer to the place in the opcode where the parameter list is given
18:37 allison it's necessary for actually storing the arguments into the appropriate registers
18:37 Whiteknight so a pointer to the get_args opcode in the callee?
18:37 allison no, a pointer to the get_params opcode
18:38 Whiteknight urg, that
18:38 allison (this is parameter side, not argument side)
18:38 * Whiteknight has a very tenuous grasp on the english language
18:38 allison the arguments were already extracted from get_args into the CallSingature
18:38 allison Signature
18:38 purl Signature is parsed before hand
18:39 allison arguments and parameters are often muddled up in the literature, so it's quite understandable
18:39 allison if there were other words to describe them, I'd use them
18:41 Whiteknight so infinite loop. We get the flags for the current parameter, then we get the value of the current parameter as a PMC or a STRING/PMC pair if it's a named?
18:41 Whiteknight "value of the current argument"
18:42 Whiteknight then we get the storage location of the first suitable parameter, and stuff it in there
18:42 allison yes
18:42 Austin Is there any valid semantics for opt_flag on a slurpy parameter?
18:42 Whiteknight Austin: no
18:42 Whiteknight slurpy is optional by default
18:42 allison no, slurpy parameter is always an array or hash, though it may be empty
18:42 Whiteknight (see, I've managed to retain some information today!)
18:42 Austin Thanks.
18:43 Austin And is lookahead + slurpy invalid, I hope?
18:43 allison Austin: yes, they're semantically incompatible
18:44 Austin You left args.c out of the makefile, I think
18:45 mikehh You got this bunh of things you want to pass (the arguments) which you are going to put in their appropriate places (the parameters)
18:45 mikehh bunch
18:45 allison Austin: it's in the makefile
18:45 allison Austin: re-run Configure.pl
18:46 Austin Update got it
18:48 Austin Is there a target test case for this?
18:48 allison Austin: for lookahead?
18:48 Austin No, for functionality and performance of arg filling
18:49 allison Austin: there are lots of test cases, but none specifically designed to exercise all the option flags
18:49 Austin What about performance?
18:49 Austin Is there a make-a-million-calls test, or something?
18:49 allison Austin: not yet
18:50 Austin ten thousand?
18:50 Austin one hundred?
18:50 Austin libparrot.so: undefined reference to `SETATTR_Key_next_key'
18:51 Austin What's that?
18:51 purl that is probably how it does it.
18:53 Austin args.c needs #include ../pmc/pmc_key.h
18:53 nopaste "allison" at 77.98.130.30 pasted "A new variation, assuming that "get next arg" checks whether an arg is available" (38 lines) at http://nopaste.snit.ch/18187
18:55 Austin make coretest is the only target that works right now, yes?
18:55 mikehh make codetest also
18:55 Austin mikehh++
18:55 Austin Thanks
18:55 mikehh make corevm
18:56 Austin Got a bunch of failures.
18:56 allison Austin: 414 last I checked
18:56 Austin Don't know yet.
18:56 Austin My machine is old.
18:58 mikehh not even make corevm at the moment - fails on src/call/args.c
18:58 Austin update, mikehh
18:58 Austin And check that #include
18:59 allison mikehh: update and rerun Configure.pl
18:59 dalek parrot: r41643 | allison++ | branches/pcc_reapply/src/call/args.c:
18:59 dalek parrot: [pcc] Move header file with the function that used it.
18:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41643/
19:01 Whiteknight allison: how do we determine if we've passed more named arguments then we have parameters for?
19:01 Whiteknight or do we ignore named overflow like that?
19:02 Austin Call vtable_elements on the hash
19:02 Whiteknight can't get directly to the hash, at least not without breaking encapsulation I think
19:04 allison Whiteknight: at the moment, we can't
19:04 allison Whiteknight: they're silently ignored
19:04 Whiteknight ok
19:05 allison The complete alternative way of approaching this problem would be to start by iterating over the arguments passed
19:06 Whiteknight I like that idea if there is a sane way to iterate over named parameters too
19:07 Whiteknight without the param_flags, there's no way to know if the named parameters exist
19:08 Whiteknight ...unless we can disect the CallSignature and get direct access to the underlying array and hash storage
19:09 allison Whiteknight: it would have to be a hash iterator for the named arguments
19:09 Whiteknight or implement an iterator-like interface on CallSignature with shift_pmc (for positionals) and shift_string (for named)
19:09 allison Whiteknight: yes, that would be cleaner
19:10 Austin WhiteKnight is the pmc master!
19:10 allison Whiteknight: really don't want anyone poking into the internals of the CallSignature, as it prevents later optimizations
19:10 Whiteknight The problem there comes with :lookahead objects, we would need to be able to look into the hash and remove an item from the iteration so we don't double count it
19:10 allison Whiteknight: it would also be good to avoid the cost of creating additional Iterator PMCs for the array and hash
19:11 Whiteknight right, that's why I like the idea of shoehorning the shift_* interface into CallSignature
19:11 mikehh oh manifest_tests also runs (fails) fixed
19:11 allison I suppose the named arguments could be an ordered hash
19:12 darbelo left #parrot
19:13 dalek parrot: r41644 | mikehh++ | branches/pcc_reapply/MANIFEST:
19:13 dalek parrot: run perl tools/dev/mk_manifest_and_skip.pl
19:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41644/
19:14 allison oh, but not Parrot's current ordered hash, since it doesn't give you "keys in order" it only gives you "values in order" or "values by key"
19:14 Whiteknight urg
19:15 mikehh codetest fails - there are now 7 unused assert macros in include/parrot/call.h - passes the rest of codetest
19:17 kurahaupo joined #parrot
19:18 Austin which function creates the raw signature?
19:18 allison Whiteknight: okay, I think I've got how to do code reuse between the _from_op and _from_c_args variations
19:19 allison Whiteknight: each calls 2 functions "fetch next arg" and "store next arg"
19:19 mikehh I have no idea how to fix the 'no unused assert macros" problem with call.h - when I ran make headerizer before it didn't do anything
19:19 allison mikehh: that should be gone now, I deleted those call signatures
19:20 allison mikehh: the problem is that the headerizer searches source files first, then writes the header files
19:20 Whiteknight allison: I'm working on pseudocode right now for an arguments-based iteration
19:20 Whiteknight It's already much easier to understand
19:20 allison mikehh: so, once the source file is gone, it no longer knows to remove the corresponding header entries
19:21 kurahaupo Good morning everyone.
19:22 kurahaupo As Bacek suggested last week, I've been redoing some tests from PMC to PIR, starting with t/pmc/resizeableintegerarray.t. Anyway, I noticed some gaps in the test coverage, and now I think I've found a bug: resizing an array down and up again doesn't erase the preallocated memory.
19:23 kurahaupo What's the procedure? Do I just submit a bugfix as part of my patch to replace the tests?
19:24 allison kurahaupo: we don't provide guarantees to the user on whether shrinking the size of the array will change the memory allocated
19:24 kurahaupo $P0 = new ['ResizableIntegerArray']
19:24 kurahaupo $P0 = 10
19:24 kurahaupo $P0[7] = 23
19:24 kurahaupo $P0 = 5
19:24 kurahaupo $P0[9] = 0
19:25 kurahaupo Is it supposed to be that way?
19:25 allison kurahaupo: the size allocations are only a suggestion to resizable arrays
19:26 allison kurahaupo: it will always allocate space for an element
19:26 allison kurahaupo: yes, it's supposed to be that way
19:26 allison kurahaupo: the fixed size arrays are the ones that force you to stick within the declared size
19:26 nopaste "whiteknight" at 69.249.176.251 pasted "argument-based iteration processing for allison++" (50 lines) at http://nopaste.snit.ch/18188
19:27 kurahaupo This is for a resizeable array
19:27 Whiteknight allison: this pseudocode has a few more lines, but is much simpler conceptually
19:27 allison yes, it does simplify things
19:28 allison need a check inside "get next positional parameter slot" in case it's a named parameter slot
19:28 kurahaupo allison: what are the "visible semantics" for increasing the size of an array? I thought it was supposed to be zero-filled (in the case of an integerarray)
19:28 kurahaupo ^are^should be
19:28 cconstantine joined #parrot
19:29 allison kurahaupo: for an integer array, yes, if you try to access an element that hasn't been set, it should return 0
19:30 allison Whiteknight: ah, I see, your check is for NULL
19:30 kurahaupo allison: This doesn't work then: set array size to 10, set element 7 to some value, reduce array size to 5, increase array size to 10, check that element 7 is now zero ...
19:30 allison Whiteknight: it's actually "get next parameter flag"
19:31 allison kurahaupo: resizable integer arrays don't pay attention to setting the size
19:31 allison kurahaupo: they just silently ignore it
19:32 allison kurahaupo: that was considered less disruptive than throwing an exception
19:32 kurahaupo allison: That's not exactly obvious behaviour, given that it responds to resizing in all other respects.
19:33 kurahaupo Push/pop/shift/unshift/elements all work as expected
19:33 Whiteknight allison: whatever we call it. We need to get the register index and the metadata about the storage location. For ease I'm grouping it as one thing
19:36 allison Whiteknight: jumping ahead to the optional flag while processing the optional argument is a headache
19:36 allison Whiteknight: it's easier to just iterate over the opt_flag as an ordinary parameter
19:37 allison Whiteknight: but, that's an implementation detail.
19:37 allison Whiteknight: if setting parameters is made sufficiently modular, it won't be a headache anymore, it'll be a simple function call
19:38 allison Whiteknight: how would this code handle opt_flag parameters where no optional was passed?
19:38 Whiteknight allison: but that's the thing, we're not iterating over the parameters, we're iterating over the args
19:38 Whiteknight we can do parameters in any order we want
19:39 Whiteknight at that point it's just updating a counter
19:39 allison Whitekight: the headache is in storing, not in accessing
19:39 Whiteknight I'm not sure what you mean
19:40 allison Whiteknight: the question stands,  if we're iterating over the arguments, we'll never know when we skipped an optional argument
19:40 allison Whiteknight: so there's no way to mark the opt_flag as false
19:40 Whiteknight but we have param_flags. We're sort of iterating over both, just letting the argument iteration take precidence
19:41 Whiteknight for any given parameter we have a flag that says "this is optional"
19:41 Whiteknight and we can associate that with a register number
19:42 allison Whiteknight: there's no handling here for "we have more positional parameters, but no more arguments"
19:43 allison Whiteknight: well, there is, but it doesn't look for optional parameters
19:45 allison Whiteknight: it can be handled by duplicating the "mark all remaining opt_flag parameters" code after both the positional and named loops
19:47 Whiteknight okay, we can do that
19:47 Whiteknight brb, I need to run a quick errand
19:48 Whiteknight nevermind, nowhere to go
19:49 allison Whiteknight: or, pull that loop up inside the other...
19:50 Whiteknight if we have a "get next parameter slot" and a "put back parameter slot" we can lookahead more easily
19:51 allison Whiteknight: it's "get next parameter flag" rather than slot
19:51 Whiteknight and then we lookahead so long as we find slots that are what we're looking for
19:51 Whiteknight right, I'm conflating the two
19:52 nopaste "allison" at 77.98.130.30 pasted "cleanup, down to 2 loops, clarified slot, made the logic for parameter/arg checking the same between positional and named" (50 lines) at http://nopaste.snit.ch/18189
19:53 Whiteknight it's not just finding the next flag, it's finding the next *suitable* flag
19:53 allison Whiteknight: what I didn't add is checking whether the flag is the right kind of flag
19:53 Whiteknight but besides that, this looks good
19:53 Whiteknight right
19:53 allison Whiteknight: aye
19:53 Whiteknight where "if no parameter flag" is "if no suitable parameter flag"
19:54 Whiteknight I like this much better
19:54 allison Whiteknight: which is easy to check in named, but there's no flag for positional
19:55 allison I like it better too
19:55 Whiteknight we can create a mask of flags that we want and a mask of flags that we don't want
19:55 allison it's easier to follow, and has a better parallel between the PIR and C cases
19:56 Whiteknight :lookahead is a problem, but not one we need to address immediately
19:56 allison Whiteknight: parameter checking in general is harder here too
19:57 allison (argument checking is easy)
19:57 Whiteknight well that's the way it's going to be, whichever we don't iterate over directly will be harder to work with
19:57 allison yup
20:09 allison now to see if I can apply all this to return arguments
20:28 Whiteknight yeah
20:44 plobsing joined #parrot
20:44 bacek Good morning
20:45 kurahaupo Morning bacek
20:45 bacek kurahaupo: G'Day
20:46 allison Whiteknight: there is a way to iterate over a hash without creating an Iterator, though it's not pretty. See dissect_aggregate_arg in src/call/args.c
20:49 plobsing hello
20:49 Whiteknight allison: already looking at it
20:51 plobsing i am interested in adding the libjit nci changes I have at http://github.com/plobsing/parrot-libjit
20:59 bacek is pcc_reapply open for commits?
21:00 allison bacek: yes
21:00 bacek allison: ok
21:03 dalek parrot: r41645 | bacek++ | branches/pcc_reapply/src/call/pcc.c:
21:03 dalek parrot: [care] Remove unused set_context_sig_params and _results functions
21:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41645/
21:04 allison bacek: ah, if you're interested in removing unused code, I can point you at a lot more
21:06 dalek parrot: r41646 | bacek++ | branches/pcc_reapply/src/call/pcc.c:
21:06 dalek parrot: [cage] Remove unused count_signature_elements function
21:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41646/
21:07 bacek allison: It's too early for me to start thinking. So I just warming up :)
21:08 dukeleto 'ello
21:08 allison bacek: pretty much all the static functions in src/call/pcc.c are candidates for removal
21:09 bacek allison: indeed.
21:09 allison bacek: correction, that's really all
21:09 allison bacek: and anything that calls them
21:09 ruoso joined #parrot
21:10 dalek parrot: r41647 | bacek++ | branches/pcc_reapply (2 files):
21:10 dalek parrot: [cage] Remove unused Parrot_init_ret_nci and Parrot_init_args_nci functions
21:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41647/
21:10 bacek allison: give me half-an-hour. I'll kill them all.
21:10 allison bacek: I want to say "anything that isn't Parrot_pcc_invoke... or Parrot_PCCINVOKE" in that file (scanning to double-check)
21:11 bacek Parrot_PCCINVOKE is deprecated, isn't it?
21:16 allison bacek: confirmed on removing all but the Parrot_pcc_invoke functions
21:16 bacek allison: ok
21:18 bacek bah... Last bits from JIT blocking total removal of this functions...
21:18 allison bacek: and yes, Parrot_PCCINVOKE is replaced by Parrot_pcc_invoke_method_from_c_args, which is currently identical
21:18 allison bacek: nope, those functions from src/frame_builder.c can be removed too
21:19 bacek allison: emitm_call_cfunc(pc, Parrot_init_arg_nci);
21:19 bacek frame builder should be updated to new implementation anyway
21:19 allison bacek: it's the set_nci_* and get_nci_*
21:20 allison (that can be removed entirely)
21:20 bacek allison: I removed them already. And commented out  emitm_call_cfunc(pc, Parrot_init_arg_nci);
21:21 allison bacek: yes, that part will need to be updated
21:21 allison bacek: (calling Parrot_init_arg_nci there wouldn't work anymore anyway)
21:22 jan joined #parrot
21:22 bacek allison: indeed. "frame builder should be updated to new implementation anyway" :)
21:23 allison bacek: aye
21:23 dalek tracwiki: v100 | dukeleto++ | Languages
21:23 dalek tracwiki: https://trac.parrot.org/parrot/wiki/L​anguages?version=100&amp;action=diff
21:23 shorten dalek's url is at http://xrl.us/bfqbki
21:24 allison bacek: looks like that whole function Parrot_jit_build_call_func will need a serious workover
21:30 preflex joined #parrot
21:44 kthakore joined #parrot
22:09 kid51 joined #parrot
22:15 Tene joined #parrot
22:15 Tene O HAI GUYZ
22:22 nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: build failure at 41647" (344 lines) at http://nopaste.snit.ch/18190
22:23 nopaste "bacek" at 110.175.160.228 pasted "Patch for review for allison++" (148 lines) at http://nopaste.snit.ch/18191
22:23 kid51 Death rattle begins at line 186 of src/frame_builder.c
22:24 GeJ bacek: your last commit says Remove unused Parrot_init_ret_nci and Parrot_init_args_nci functions. Fresh build complains about those two missing in src/frame_builder.c
22:24 GeJ nevermind, kid51 beat me to it.
22:24 allison bacek: sensible, it will save on repeating the code between each of the Parrot_call_sub* variants
22:25 kid51 GeJ++ You tied the failure to a commit!
22:25 bacek allison: ok. I'll commit it.
22:25 bacek allison: How Parrot_call_method_* should be updated?
22:26 dalek parrot: r41648 | bacek++ | branches/pcc_reapply/src/frame_builder.c:
22:26 dalek parrot: Make frame_builder.c buildable but broken
22:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41648/
22:27 allison bacek: the same as the others, but with Pi added to the front of the signature
22:27 bacek allison: and do we need PARROT_CALLING_START/END macros back?
22:28 allison Parrot_pcc_invoke_from_sig_object  works for subs and methods
22:28 allison bacek: no, all of these functions are deprecated and will be replaced with a single function
22:29 bacek allison: ok.
22:29 allison bacek: it's only temporary to have all this silly code duplication
22:29 bacek allison: yeah. But I trying to wrap my head around new functions.
22:30 allison bacek: yeah, it is a wholesale replacement, lots of changes to the internal interface
22:34 Tene Looks like I'm getting linking errors when compiling miniparrot.  undefined reference to set_nci_*
22:35 nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: build failure at 41648" (505 lines) at http://nopaste.snit.ch/18192
22:35 Tene Yeah, that.
22:35 purl Sure, that.
22:36 bacek Try r41649
22:36 dalek parrot: r41649 | bacek++ | branches/pcc_reapply/src/frame_builder.c:
22:36 dalek parrot: Comment out more stuff in frame_builder.c
22:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41649/
22:37 Tene bacek: WFM
22:37 bacek allison: Parrot_call method usually invoked with "Pi..." signature, correct? So I have to skip 2 first chars in signature?
22:39 kid51 make completes at r41649
22:39 allison Parrot_call_method used its own bizarre signature strings
22:40 bacek allison: ouch...
22:40 allison bacek: (that's why they're deprecated)
22:41 allison bacek: that is, the return argument was first (which is why we increment it)
22:41 bacek so, skip first char, prepend "Pi" to signature, build sig_object, append "->[T]", invoke?
22:41 allison bacek: that should do it
22:41 bacek allison: ok.
22:41 allison bacek: you may have to remove an O argument, if it was passing one
22:42 bacek allison: can you give example of signature?
22:43 jimk joined #parrot
22:43 allison bacek: was just looking for one, and of course there are no calls to Parrot_call_method in the repository (not even tests)
22:43 bacek allison: yeah... That why I'm little bit stuck
22:43 allison implement it as if there's no signature element for the object
22:44 allison (just like Parrot_call_sub
22:44 allison )
22:44 allison we'll run testing with external users
22:44 allison it's very possible that no one has ever used Parrot_call_method*, in which case we'll just rip it out after 2.0 and not worry about it
22:47 japhb Austin, ping
22:47 Austin pong
22:47 Austin 'sup?
22:47 japhb I've pushed a version of Plumage that can be told to ignore failures in a build stage.
22:47 japhb In particular, you can ./plumage --ignore-fail=test install Close
22:47 Austin sweet/
22:47 Austin .
22:48 japhb ... except it only *appears* to work for me, because I appear to get a non-functional parrot-close binary.
22:48 japhb Can you take a look?
22:48 Austin If only I could do the same thing in development. :|
22:48 japhb heh
22:48 Austin Probably. The trunk doesn't work at the moment.
22:48 Austin I'd say you're getting it right.
22:48 japhb ah.  Well, that would explain things
22:48 nopaste "bacek" at 110.175.160.228 pasted "Parrot_call_method patch for allison" (58 lines) at http://nopaste.snit.ch/18193
22:49 Austin Where does plumage put its downloads?
22:49 japhb Austin, well, is there a branch that's working?  Maybe it's time to teach Plumage about pulling particular branches and/or revs ....
22:49 allison joined #parrot
22:49 japhb Austin, at the moment, within the current directory.  That's on the short list to fix.
22:50 Austin That's fine. I'll test plumage to make sure that the breaks work the same way.
22:50 Austin And no, there's no branch that builds with a current parrot.
22:50 Austin Sorry.
22:51 Austin I'll see what I can produce, though.
22:51 japhb Austin, is there one that builds with Rakudo's current required version (r41447)?
22:51 Austin Nope.
22:51 jimk Smolder on branch:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/28492
22:51 shorten jimk's url is at http://xrl.us/bfqbs2
22:51 allison bacek: Parrot_pcc_build_sig_object_from_varargs won't know what to do with the '0' at the front of the arg_sig
22:51 Austin You have to get in the way-back machine to find a good parrot.
22:51 japhb d'oh!
22:51 Austin japhb++
22:52 Austin Good job getting so far so fast with plumage.
22:52 japhb Thank you.  :-)
22:52 allison bacek: but if you remove arg_sig[0] = 0; and allocate arg_sig as strlen(signature)+1 it should be good
22:53 bacek allison: can you give me example of Parrot_call_method signature?
22:53 allison vP
22:53 allison a void return and a PMC argument
22:53 bacek ok
22:53 allison or PP, a PMC return and a PMC argument
22:53 allison that is, assume it's the same as Parrot_call_sub
22:53 kid51 joined #parrot
22:53 bacek char *arg_sig = (char*)malloc(strlen(signature)+2);
22:53 bacek arg_sig[0] = 'P';
22:53 bacek arg_sig[1] = 'i';
22:53 bacek arg_sig[2] = 0;
22:53 bacek strcat(arg_sig, signature + 1);
22:54 japhb Has parrot carved out a prefs dir yet?  ~/.parrot or the like?
22:54 Tene allison: you able to point me in the right direction on a failing test to diagnose in pcc_reapply?
22:54 Tene japhb: no
22:54 bacek allison: is this correct?
22:55 japhb OK, so:  Do I treat plumage as a separate entity, so ~/.plumage/ or ~/.parrot_plumage/ ... or as part of parrot, so ~/.parrot/plumage/ ?
22:55 japhb Any opinions?
22:55 allison since we're removing signature[0] it should only need to allocate one extra character
22:55 allison Tene: yes, which test?
22:55 allison Tene: or, are you looking for a test to tackle?
22:55 Tene allison: the latter
22:55 purl the latter is, like, better
22:55 Tene japhb: I think I prefer the last, but just barely
22:55 bacek allison: plus '\0' at the end
22:56 Tene japhb: I kind of dislike the second.
22:56 allison bacek: won't the original char * already have '\0' at the end?
22:56 japhb Tene, OK, fair enough.
22:56 bacek but strlen doesn't count it
22:56 allison Tene: t/pmc/namespace.t is a matter of fixing the test not to use 'like'
22:56 allison bacek: ah, yes
22:56 japhb Any other opinions from the peanut gallery?  (It's not like I can't change it later, of course)
22:57 allison Tene: (this is a general fix, no core tests should use like because no core tests should depend on PGE)
22:58 allison Tene: t/pmc/multidispatch.t is more hairy, it involves getting MMD signature parsing to figure out what to do with flattened argument lists
22:59 allison Tene: t/pmc/integer.t is another one that needs to not use 'like'
22:59 Khisanth joined #parrot
23:00 japhb Tene: did you ever get around to coding that tree-like data structure merge function?
23:00 Tene japhb: No.
23:00 japhb Tene, OK, np.
23:00 japhb Just wanted to make sure I wasn't going to duplicate something you'd written but just not pushed.  ;-)
23:02 dalek parrot: r41650 | bacek++ | branches/pcc_reapply/src/extend.c:
23:02 dalek parrot: Update Parrot_call_sub_ret_* function to use new PCC
23:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41650/
23:02 dalek parrot: r41651 | bacek++ | branches/pcc_reapply/src/extend.c:
23:02 dalek parrot: Rework Parrot_call_method to use new API. There is no tests for this functions and I couldn't find any HLL which uses them.
23:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41651/
23:02 dalek parrot: r41652 | bacek++ | branches/pcc_reapply (4 files):
23:03 dalek parrot: [cage] Remove bunch of unused functions
23:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41652/
23:03 allison Tene: t/oo/metamodel.t is looking for a 'fail' subroutine that doesn't seem to exist
23:04 Tene Does anyone object to the name 'throws_substring' for a text-comparison workalike to 'throws_like'?
23:05 allison Tene: sounds like a good idea
23:05 allison Tene: with arguments for start position and length?
23:06 allison Tene: (maybe optional named arguments?)
23:07 Tene allison: might be useful... doesn't look like anyone needs that functionality right now, so I'm not going to implement it, though.
23:08 allison Tene: is the substr from start to end of passed string then?
23:08 Tene allison: I was just going to pass it to index_i_s_s
23:08 Tene "is the passed text a substring of the text of the exception, if any?
23:09 allison Tene: just checking "does this substring appear somewhere inside the larger string"? makes sense
23:09 Tene Yes.
23:10 allison Tene: yeah, that's all that's really needed
23:13 Zak joined #parrot
23:14 ZeroForce joined #parrot
23:16 nopaste "kid51" at 70.85.31.226 pasted "t/pmc/*.t using 'throws_like()'" (3 lines) at http://nopaste.snit.ch/18194
23:18 quek joined #parrot
23:22 dalek parrot: r41653 | allison++ | branches/pcc_reapply/t/op/annotate.t:
23:22 dalek parrot: [pcc] Undo double pop on the exception handler (likely a merge problem).
23:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41653/
23:31 bacek allison: can you check r41654? Looks like it's better to move this constants assignment inside invoke_from_sig_object.
23:31 dalek parrot: r41654 | bacek++ | branches/pcc_reapply/src/extend.c:
23:31 dalek parrot: Propogate constants to context. Claim few more passing tests.
23:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41654/
23:35 dalek parrot: r41655 | tene++ | branches/pcc_reapply (5 files):
23:35 dalek parrot: Add 'substring' and 'throws_substring' functions to Test::More
23:35 dalek parrot: Use substring functions instead of PGE in three tests.
23:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41655/
23:35 Tene allison: those three tests now all pass.
23:40 allison Tene: excellent!
23:40 * purl plays air guitar
23:41 dalek parrot: r41656 | bacek++ | branches/pcc_reapply/t/op/cc_state.t:
23:41 dalek parrot: [t] Update test to reflect current error message from PCC.
23:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41656/
23:41 Tene I can't figure out where oo/metamodel.pt is expecting to find a 'fail' method... it doesn't include anything that would define it.
23:42 Tene I can add one  in very easily, though.
23:44 allison Tene: it's possible that the failure code has just never been called
23:44 Tene Hmm.  True.
23:44 allison Tene: or that Test::More had a fail function a long time ago
23:45 Tene committed
23:47 Tene I'll look at t/pmc/multidispatch now
23:48 dalek parrot: r41657 | tene++ | branches/pcc_reapply/t/oo/metamodel.t:
23:48 dalek parrot: Add a fail sub to oo/metamodel.t so that it can fail properly
23:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41657/
23:51 nopaste "bacek" at 110.175.160.228 pasted "Fix handling of null CallSignature in fill_returns for allison" (14 lines) at http://nopaste.snit.ch/18195
23:56 dalek tracwiki: v7 | allison++ | CallingConventionsOverview
23:56 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingC​onventionsOverview?version=7&amp;action=diff
23:56 shorten dalek's url is at http://xrl.us/bfqbxt
23:56 allison bacek: yes, that's the right fix
23:57 bacek allison: committed.
23:57 dalek parrot: r41658 | bacek++ | branches/pcc_reapply/src/call/args.c:
23:57 dalek parrot: Fix handling null CallSignature in Parrot_pcc_fill_returns_* functions.
23:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41658/
23:58 davidfetter joined #parrot
23:59 bacek Found good Configure.pl option: --buildframes=0

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

Parrot | source cross referenced