www.parrot.org | Parrot 1.6.0 "half-pie" released: PCC branch hackathon all $localtime Saturday | Testing priorities: pcc_reapply branch
Set by moderator on 30 September 2009.
darbelo Heisenbugs! Whee! 00:01
00:02 allison joined
Whiteknight good evening allison 00:03
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.
nopaste "darbelo" at 200.49.154.173 pasted "Seemingly inocent bt" (47 lines) at nopaste.snit.ch/18171 00:05
Austin 77 mb?
darbelo what? 00:06
Austin The allocation that failed.
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:07
darbelo Austin: Yes. 77mb is too big. 00:09
Austin Is that the "seemingly innocent" part.
00:10 whoppix joined
darbelo No, the seemingly inocent part is the actual call chain up to the point where it runs out of memory. 00:10
Whiteknight extract_named_arg_from_op is using raw_index incorrectly 00:11
Austin Oh.
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.
s/open a packfile/load_bytecode a file/ 00:13
Whiteknight "PiSnPoIpSnPoIpSnPoIp" 00:14
that's a function signature
try saying that 5 times fast
darbelo Is that 10 arguments? 00:15
If that function is in parrot code I'm *so* going to cut it into pieces. 00:17
Whiteknight Pi is the invocant, Sn is an argument name, not an argument 00:20
so 6 args, three of which are named
no
three named optional arguments
00:20 cognominal joined
Whiteknight src/pmc/exporter.pmc:import 00:20
Austin What's PoIp ? 00:21
Whiteknight o is optional, p is opt_flag 00:22
so pmc :optional\\n int :opt_flag
Austin ah
Whiteknight big letters are P S N I, little letters are the flags 00:23
and believe it or not, these are much saner then how sigs used to be
Austin So SnPoIp is string-named optional pmc with accompanying flag?
GeJ Good morning everyone
clock?
darbelo I keep getting this stuff mixed up with NCI signatures in my head.
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 /
Austin morning gej
darbelo An timezones be added to purl's clock? 00:24
Whiteknight Austin: exactly 00:25
hello GeJ!
GeJ: What day is it where you are?
darbelo He said morning.
I'm guessing saturday.
Whiteknight allison: ping 00:26
GeJ technically it's PCC hackathon day
Whiteknight GeJ: So get a'hackin'!!
Austin ChST -- Chamorro Standard Time.
00:26 hercynium joined
GeJ darbelo: I usually fool everybody with that. I'll assume it's always morning for someone on IRC. 00:26
Whiteknight ah nevermind, allison unping 00:27
Austin Guam! "Where America's Day Begins." 00:28
00:28 rhr joined
GeJ checking branches/pcc_reapply out 00:28
that's the one right? 00:29
Whiteknight yessir
ah, I think I found it!
darbelo GeJ: Was it you that had a failing FreeBSD box after the kill-next_for_GC merge?
darbelo afk
GeJ yup. but not anymore. Whatever you did, thanks. 00:30
Whiteknight nopaste?
purl hmmm... nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
00:30 cognominal joined
nopaste "whiteknight" at 69.249.176.251 pasted "Anybody else see what I see?" (2 lines) at nopaste.snit.ch/18172 00:30
GeJ Well, for one, I have no idea of what I'm looking at. 00:34
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
shift_string() not implemented in class 'String'
*br0tch*.
Whiteknight but the important part is that all other arguments in that function call are passed as pointers, while the string names are not
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.
Whiteknight GeJ: yeah, lots of failures 00:37
darbelo GeJ: you should stick to "make corevm" and "make coretest" for now. 00:38
A full parrot is unlikely to build before the core's fixed. 00:39
Whiteknight I've got two fixes coming in that should have a beneficial effect 00:40
darbelo Whiteknight++
dalek rrot: r41625 | whiteknight++ | branches/pcc_reapply/lib/Parrot/Pmc2c/PCCMETHOD.pm:
[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
rrot: r41626 | whiteknight++ | branches/pcc_reapply/src/call/pcc.c:
[pcc] raw_index is the index into the register arrays, NOT the index into the arg flags FIA. fix the issue
nopaste "dukeleto" at 69.64.235.54 pasted "Primes.pasm runtime (in seconds) across released versions of Parrot and trunk (r41609)" (13 lines) at nopaste.snit.ch/18173 00:47
dukeleto nice work peeps, trunk is fastest
there was a huge jump in performance between 1.2 and 1.3 00:49
roughly 20x speed improvement for primes.pasm 00:50
00:50 quek left
darbelo Aha! I think I found the source of the invalid STRINGs in the io subsystem. 00:51
Austin Isn't undef supposed to stringify to "" (empty string) ? 00:52
darbelo undef's supposed to stringify? 00:53
treed I wouldn't expect it to stringify at all?
treed is decidedly not a perl person, though.
darbelo leaves for a while. 00:55
Laters!
00:55 darbelo left 00:58 quek joined, kid51 joined 01:00 quek left 01:01 patspam joined 01:02 whoppix joined
kid51 During the outage, I pasted this 'make coretest' output from the pcc_reapply branch: nopaste.snit.ch/18174 01:03
01:04 quek joined
Whiteknight Parrot_pcc_fill_params_from_c_args is definitely filling arguments incorrectly 01:04
dukeleto Coke: ping! 01:05
01:05 quek left 01:06 quek joined
Whiteknight or, it's getting bad signature information 01:07
01:07 quek left 01:08 quek joined 01:10 quek left
Whiteknight In the pattern SnPoIp, the opt_flags are being marked as positional arguments and iterated that way 01:10
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 01:11 quek left
Whiteknight well, actually I don't know in that case what the Ip should be listed as 01:14
PiSnPoIpSnPoIpSnPoIp is being processed as if it has 3 positional arguments 01:23
so I'm not sure where those are coming from
01:24 whoppix_ joined
dalek TT #1088 created by Austin_Hastings++: Multidispatch 'concatenate_str' does not handle LHS undef 01:26
01:29 quek joined
bacek o hai 01:29
Whiteknight I think I've got it 01:32
hello bacek
happy hackathon day!
bacek Whiteknight: not for me. It's "Happy Kids day"
Whiteknight bacek: that's a good day too! 01:33
technically I'm coding yesterday, but I'm starting hackathon day early
01:35 quek left 01:36 quek joined
dukeleto hola 01:37
01:38 quek left, quek joined 01:41 joeri left 01:43 quek left, quek joined
Coke dukeleto: pong 01:47
Whiteknight ...lots of little fixes... 01:50
dalek rrot: r41627 | whiteknight++ | branches/pcc_reapply/src/call/pcc.c:
[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
Coke anyone who has committed to partcl, do you have a github id? 01:56
01:58 TiMBuS joined 02:01 rhr joined, whoppix_ joined
Coke crud, I think I missed dukeleto. 02:06
dukeleto++
dalek kudo: f529b41 | (Solomon Foster)++ | src/setting/ (3 files):
Full support for Complex cosec and acosec.
 02:18
shorten dalek's url is at xrl.us/bfpwhz
dalek kudo: 54c4564 | (Solomon Foster)++ | src/setting/ (3 files):
Full support for Complex cotan and acotan.
shorten dalek's url is at xrl.us/bfpwh3
dalek kudo: 16a2810 | (Solomon Foster)++ | src/setting/ (3 files):
Full support for Complex sinh and asinh.
shorten dalek's url is at xrl.us/bfpwh7
dalek kudo: fc29434 | (Solomon Foster)++ | src/setting/ (3 files):
Full support for Complex cosh and acosh.
shorten dalek's url is at xrl.us/bfpwh9
dalek kudo: d5b578b | (Solomon Foster)++ | src/setting/ (3 files):
Full support for Complex tanh and atanh.
shorten dalek's url is at xrl.us/bfpwib
dalek kudo: 396f318 | (Solomon Foster)++ | src/setting/ (3 files):
Full support for Complex sech and asech.
shorten dalek's url is at xrl.us/bfpwid
dalek kudo: 7bfbe77 | (Solomon Foster)++ | src/setting/ (3 files):
Full support for Complex cosech and acosech.
shorten dalek's url is at xrl.us/bfpwif
dalek kudo: 197b1e1 | (Solomon Foster)++ | src/setting/ (3 files):
Full support for Complex cotanh and acotanh.
shorten dalek's url is at xrl.us/bfpwih
dalek kudo: e976f23 | (Solomon Foster)++ | t/spectest.data:
Update the spectest to run the new trig tests.
shorten dalek's url is at xrl.us/bfpwij
Coke darbelo: ping.
darbelo?
purl darbelo is Daniel Arbelo Arrocha <mailto:arbelo@gmail.com>
02:24 kid51 joined
dalek rrot: r41628 | whiteknight++ | branches/pcc_reapply/src/pmc/capture.pmc:
[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
02:26 quek left
Coke dukeleto? 02:27
purl somebody said dukeleto was still employeed. i "made the cut" in our CEO's words
02:29 quek joined 02:30 kid51 joined 02:36 janus joined 02:40 whoppix_ joined 02:41 quek left, quek joined 02:44 quek left, quek joined 02:47 kid51 joined 02:48 cconstantine joined
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.
Coke hio 02:59
03:00 whoppix joined
Whiteknight urg, this PCC argument processing state machine is a big pain 03:00
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.
Coke relax your mind: www.cesmes.fi/ 03:08
nopaste "Whiteknight" at 69.249.176.251 pasted "example patch for allison++" (126 lines) at nopaste.snit.ch/18175 03:09
03:10 darbelo_ joined
Whiteknight purl msg allison check out 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.
darbelo_ Coke: pong
Whiteknight and with that, I need me some sleep 03:11
goodnight
03:13 rhr joined
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.
Coke msg dukeleto darbelo is darbelo on github.
purl Message for dukeleto stored.
darbelo_ Coke: ping 03:27
03:30 whoppix joined
darbelo_ Oh. Nevermind 03:31
Coke: un-ping
dalek rrot: r41629 | mikehh++ | branches/pcc_reapply/lib/Parrot/Pmc2c/Method.pm:
fix some codetest errors - trailing whitespace and cuddled else
 03:55
04:03 quek left 04:04 whoppix joined, TonyC joined 04:05 Zak joined 04:07 quek joined 04:14 theory joined 04:19 quek left 04:20 whoppix joined 04:34 zak_ joined 04:47 Zak joined 04:48 kyle_l5l joined 05:02 whoppix joined 05:09 Zak joined 05:48 tokuhirom________ joined
dalek rrot: r41630 | pmichaud++ | branches/pct-rx/compilers/pct/src/Regex (2 files):
[pct-rx]: Refactor Cursor.!matchify, add Cursor.!subrule, other cleanups.
 05:51
06:22 ZeroForce joined
dalek rrot: r41631 | pmichaud++ | branches/pct-rx/compilers/pct/src/Regex (2 files):
[pct-rx]: Add Cursor.!literal, P6Regex.quantmod.
 06:23
07:17 iblechbot joined 07:50 quek joined 07:58 quek left 07:59 quek joined 08:04 quek left, quek joined 08:10 quek left, quek joined 08:34 bacek joined 08:35 Khisanth joined 08:44 quek left 08:46 quek joined 08:58 quek left 09:00 quek joined 09:04 quek left 09:05 quek joined 09:10 quek left, quek joined 09:16 quek left 09:17 quek joined 09:38 quek left 09:43 Austin joined 09:57 darbelo joined 10:06 whoppix joined 10:24 Whiteknight joined
darbelo Ugh. freeze and io are so entangled it hurts. 10:28
Whiteknight happy hackathon day! 10:33
...now if only we can get this argment procesing stuff to work 10:37
Austin Create a new branch, called UN. Just pretend the arguments don't happen. 10:53
11:00 joeri joined
mikehh hi Whiteknight 11:01
Whiteknight hello mikehh
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
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
Whiteknight there is some functionality missing still that PGE requires
ok
11:21 einstein joined
Whiteknight okay, there is something wrong with the set_args op 11:27
er, maybe not. nevermind 11:29
dalek rrot: r41632 | whiteknight++ | branches/pcc_reapply/src/call/pcc.c:
[pcc] two changes to the arg-handling code:

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. Net result is a handful of new passing subtests, especially in t/pmc/class.t where I am focusing my current debugging		 11:42
Whiteknight there is definitely a problem with the counting of positional elements 11:54
I just don't know what that problem is yet
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
Whiteknight: coordinating between the two is the task of this chunk of code
Whiteknight right, there was a little bit of a mixup in there though
r41632 fixes the mixup and adds a few passing tests (though I don't like the solution) 11:57
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
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
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
mikehh I am also getting assert args failures with: 12:02
purl okay, mikehh.
mikehh # unused assert macros found:
# /home/mhh/pcc_reapply/include/parrot/call.h: Parrot_pcc_get_call_sig_raw_args
# /home/mhh/pcc_reapply/include/parrot/call.h: Parrot_pcc_get_call_sig_raw_returns
# /home/mhh/pcc_reapply/include/parrot/call.h: Parrot_pcc_set_call_sig_raw_args
# /home/mhh/pcc_reapply/include/parrot/call.h: Parrot_pcc_set_call_sig_raw_returns
# 4 unused assert macros found in total.
I was looking at them but can't quite figure out where they come from 12:03
Whiteknight mikehh: probably need to make headerizer to get them to disappear 12:04
mikehh tried that - no svn diff
Whiteknight well that's weird
12:05 cconstantine joined
mikehh let me try again 12:05
allison mikehh: they were defined before, but no longer used. The headerizer should remove them.
mikehh ok - I have something odd - will check again 12:06
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:07
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
the file was src/call/callsignature.c
mikehh: if you just delete that whole section of include/parrot/call.h, it should take care of it 12:09
Whiteknight: yes, but we don't need to store that on the call signature anymore 12:10
mikehh just did a clean checkout - something was wrong - we'll see now 12:14
Whiteknight urg, some of these results make no sense 12:17
allison mikehh: well, those headers are in mine too, and not removed by running headerizer 12:19
12:29 kid51 joined
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: 'make' failure between 41626 and 41632" (664 lines) at nopaste.snit.ch/18179 12:39
dalek rrot: r41633 | allison++ | branches/pcc_reapply/t/pmc/parrotobject.t:
[pcc] Updating error message on incorrect number of arguments.
 12:40
kid51 Hmm, that paste did not capture all the output.
12:41 jsut_ joined
kid51 'make corevm' actually completed; but 'make smolder_coretest' failed quickly 12:45
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: early termination for 'make smolder_coretest' at 41632" (82 lines) at nopaste.snit.ch/18180 12:47
12:47 sjn left
mikehh kid51 - I get that failure when I try make world - PGE fails with shift_string() not implemented in class 'String' 12:53
dalek rrot: r41634 | allison++ | branches/pcc_reapply/t/pmc/sub.t:
[pcc] Updating error message for parameter count mismatch.
mikehh make corevm coretest works though 12:54
kid51 Yes, but that doesn't generate a Smolder report. 12:58
So the question arises: Should 'smolder_coretest' be changed from: 12:59
smolder_coretest : test_prep
purl somebody said test_prep was the 'make' target on which 'make test' immediately depends and is currently equivalent to 'make'
kid51 $(PERL) t/harness $(EXTRA_TEST_ARGS) --core-tests --archive --send-to-smolder
to:
smolder_coretest : corevm
$(PERL) t/harness $(EXTRA_TEST_ARGS) --core-tests --archive --send-to-smolder
darbelo kid51: +1 13:00
purl 1
darbelo purl: die in a fire.
purl HALP
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:01
dalek rrot: r41635 | jkeenan++ | branches/pcc_reapply/config/gen/makefiles/root.in:
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
purl dalek: that doesn't look right
13:06 jsut joined 13:08 cconstantine joined
kid51 I just posted to list about this. 13:10
13:10 cconstantine joined
kid51 Here's the Smolder report at 41632: smolder.plusthree.com/app/public_pr...ails/28482 13:14
shorten kid51's url is at xrl.us/bfp6v4
13:19 jsut_ joined
Whiteknight urg, the list of test failures is so daunting 13:30
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:34
i had to delete include/parrot/call.h and compilers/imcc/imcparser.c and svn update again 13:35
allison Whiteknight: but the list of test failures is also half as long as it was 2 days ago :) 13:46
Whiteknight: small fixes have a big impact
Whiteknight I am convinced that the majority of remaining failures have to do with this argument processing algorithm 13:51
allison Whiteknight: very likely 13:52
Whiteknight: though some of them also have to do with return processing
Whiteknight: at the moment, it's a monolithic mess 13:53
Whiteknight: I'd like to break it down into a more maintainable state
Whiteknight: and suspect that as we do that, we'll likely uncover the bugs
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?
Whiteknight: step one is to move all the argument handling functions to a separate file, src/call/args.c or somthing like that 13:59
Whiteknight allison: yes, a walkthrugh to figure out a refactor would be very good 14:01
I would have started it myself already, but I didn't want to introduce too many changes
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
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
14:03 cconstantine joined
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
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?
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
only the way of accessing values is different for each
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
allison it might be possible to reverse the logic
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
allison k
allison has to go pick up a dead laptop, will be back soon too
dalek rrot: r41636 | mikehh++ | branches/pcc_reapply/src/call/pcc.c:
fix codetest - line length > 100
14:10 einstein joined
einstein I see that socket.pmc clone function does return SELF; is that correct? 14:11
14:15 jsut joined
einstein I see that socket.pmc clone function does return SELF; is that correct? shall I open ticket for that one? 14:23
14:23 Psyche^ joined
mikehh messed something up there 14:26
kid51 mikehh: I think I got it 14:46
dalek rrot: r41637 | jkeenan++ | branches/pcc_reapply/src/call/pcc.c:
Fix correction of line lengths.
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
Although I don't know why breaking in the middle of the arglist caused those problems.
14:51 theory joined
mikehh kid51: yes - you just beat me to it - but I agree - it seems not to like CONST_STRING 14:52
kid51 Were those 3 lines where CONST_STRING is used actually giving linelength errors? 14:54
(I reverted to r41632 and made my corrections therefrom.) 14:55
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
Whiteknight back 14:59
kid51 Latest smolder on pcc_reapply branch: smolder.plusthree.com/app/public_pr...ails/28485 15:00
shorten kid51's url is at xrl.us/bfp96s
15:01 slavorg joined
kid51 pcc_reapply: t/codingstd/c_arg_assert.t has failures; otherwise make codetest passes 15:01
kid51 goes to gym 15:02
15:03 jsut_ joined 15:14 kjeldahl joined 15:23 iblechbot joined
Coke mikehh: in case it was not clear, CONST_STRING needs to be on one line. 15:53
Whiteknight I don't really understand that restriction 15:54
I mean, I follow it, but it seems stupid
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
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:08
Whiteknight I don't even know what I am working on right ow 16:09
but I will avoid that
allison okay, I think I'll start by moving return handling out to a separate file
Whiteknight ok
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?
allison can you think of a better name?
Whiteknight args.c is good for now
allison Whiteknight: yes, positional, then named
16:11 kjeldahl joined
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?
will that work with the :lookahead option?
allison looking for description and failing 16:12
Whiteknight depends where :lookahead args will be ordered
will they be after the positionals, or mixed in with them?
allison but, IIRC, what patrick needed was a way for a positional parameter to check and see if there was a corresponding named argument
Whiteknight right, so fill with a named first, positional otherwise 16:13
allison actually, it should be okay
Whiteknight we can still do that in the positional loop
okay
allison because your two loops are going over the parameters
the arguments are all there ready in the call signature
(so positional processing can pull from either positional or named arguments with no troubles) 16:14
positional *parameter* processing, that is
Whiteknight yeah
allison do you have a src/call/args.c already, or should I go ahead and create one? 16:15
Whiteknight create one 16:26
This argument processing algorithm is too damn complicated. There's no good way to do this
Austin Where is it, whiteknight? 16:28
Whiteknight I don't know if there is a concise description of the algorithm anywhere
Austin No, what file is it in?
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
Whiteknight and Parrot_pcc_fill_params_from_varargs
allison Whiteknight: no, there isn't, I started this variation as "it has to handle everything the current system handles"
16:29 masak joined
allison Whiteknight: looking at the old code may be helpful 16:29
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
Whiteknight trust me, I have no illusions that I'll be able to salvage much from there
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:31
dalek rrot: r41638 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Add a new file for argument processing and move the return handling
 16:33
Austin Actually, a good question would be "what's the problem?"
Whiteknight Austin: It's just a very complicated algorithm 16:34
Austin It is?
purl Oh no it isn't!
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
Whiteknight yeah, thats what I mean
allison and, at the moment they're all lumped in one bunch
which makes it really difficult to wrap a head around it 16:36
Austin So what are the rules?
Is there a pdd that details them? 16:37
allison Austin: pdd03_calling_conventions.pod specifies what flags it has to support 16:39
Whiteknight I'm running into difficulties with handling optional and opt_flag parameters 16:43
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
...and failing miserably
allison Whiteknight: okay, cool, I'll do it now
Whiteknight w00t
allison Whiteknight: think of it as a finite state machine 16:45
you loop over each param, and take various actions depending on the type of param it is
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
dalek rrot: r41639 | allison++ | branches/pcc_reapply (4 files):
[pcc] Set up compiling for new arg processing file, and run the headerizer.
allison which would have the advantage that the args are always the same whether we're dealing with a PIR or C call
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:48
Whiteknight okay, I'll wait for that and update before making any more changes 16:49
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
this is the code where the signature is disected
Austin Boggle<!>
Whiteknight What would make this all marginally easier is if CallSignature was an iterator 16:53
Austin So a CallSignature is a run-time thing? 16:54
allison Whiteknight: CallSignature could become an iterator
Whiteknight Austin: yeah, it's a PMC type that's like a combination of Array and Hash (with some additional info)
Austin Mkay
Whiteknight allison: I'm idly speculating. We would need to be able to iterate separately over named and positionals
allison Whiteknight: though, would you really want to different iterations, one over positonal and one over named?
yes, same thought at same time :) 16:55
Austin Is that the raw_sig input argument to _from_op?
allison Austin: the raw_sig is a fixed integer array of flags
it's created by IMCC
Austin So where's this CallSignature? 16:56
allison and gives the attributes of each argument/parameter/return
Whiteknight src/pmc/callsignature.pmc
allison Austin: it's purely internal, and acts as the mediator between the various different ways of passing args/returns
Whiteknight and it's the PMC * call_object there
Austin okay. 16:57
Whiteknight My wife went to the mall alone, came home with a box of marshmallow-covered caramel apples 16:58
note to self: pregnant wife doesn't shop alone 16:59
dalek rrot: r41640 | allison++ | branches/pcc_reapply (3 files):
[pcc] Move remaining argument/return handling functions into separate file.
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) ?
*positional
allison yes 17:00
The CallSignature contains the actual list of arguments passed
Austin Should fill_params_from_op be a CallSignature method?
Whiteknight no 17:01
this is the method-calling code. We would get into an infinite loop
allison Austin: no, CallSignature is just one piece of information
Austin What's the obverse of a CallSignature? 17:02
A CalleeSignature?
ParamList?
allison Whiteknight: I moved the functions over, so update before further work
Austin: CallSignature is both arguments and return values
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?
Whiteknight right, call signature contains information from the caller (args and expected returns). The Sig FIA contains information about the callee
well, contains some information about the callee
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
both use CallSignature
Austin Ah.
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:05
Austin Are the params always registers? 17:06
allison Austin: no, they can also be NCI 17:08
Austin The args, or the params?
allison that's why we have two variants on fill_params, one "from_op" and one "from_c_args"
Austin: both
Austin Hmm 17:09
allison any subroutine can be called from PIR or C, and any subroutine can be written in PIR or C
Austin Sure.
dalek rrot: r41641 | allison++ | branches/pcc_reapply/src/call/pcc.c:
[pcc] Delete static function no longer used in this file (usage has moved to
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
and the argument side doesn't have to know anything about the subroutine being called
didn't we remove the JIT? Why does src/frame_builder.c still exist? 17:14
17:14 kj joined
nopaste "whiteknight" at 69.249.176.251 pasted "argument processing algorithm outline" (42 lines) at nopaste.snit.ch/18181 17:15
Whiteknight allison: frame_builder is the only part of JIT that we kept
dalek rrot: r41642 | kjs++ | trunk/compilers/pirc/src/pircompunit.h:
[pirc] add some more comments to pircompunit.h; I start forgetting what some struct fields are for.
 17:16
allison Whiteknight: what was the reasoning?
Whiteknight ask chromatic
there's a branch on github that reimplements the frame_builder using libJIT
Austin Why do _count variables use INTVAL?
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
allison Austin: INTVAL is just an int
Whiteknight oh yes, it is a big performance win, not having to register all the NCI thunks at startup
Austin allison: And optimizing named_count > 0 would be a lot easier if the compiler saw "unsigned"
kj Good $(daytime) 17:18
Whiteknight allison: does that algorithm I posted look sane?
kj Whiteknight: would it be an idea to create a finite state automaton picture based on that algorithm?
or is would that be overkill... 17:19
eh, remove some words in that sentence there
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
more documentation is always a good thing
allison Whiteknight: looking now...
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"
Whiteknight: it's really a two-variable foreach loop 17:22
(a Perl 6 zip operation)
Whiteknight yeah, I was figuring that would be the case
allison I'd tweak the pseudocode to match 17:23
because, you actually need the "next" argument to check the first condition "no more arguments", but "get current argument" is listed after that check
Whiteknight: (this is a very helpful abstraction, to see it all boiled down to pseudocode) 17:24
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
only of positionals 17:26
Whiteknight we have a count of all passed arguments
(all passed) - (processed positionals) = (all named)
allison where is the all passed value coming from? 17:27
Whiteknight VTABLE_elements(interp, raw_sig)
allison that's a count of parameters, not arguments 17:28
and VTABLE_elements(interp, call_object) is a count of positionals
17:28 einstein joined
Whiteknight I keep getting those words mixed up 17:28
okay, let me redo the pseudocode and post it again 17:29
17:34 buildbot joined
Whiteknight are we going to support anything like :lookahead :slurpy? 17:35
or does that not even make any sense?
allison Whiteknight: I'd say no, :slurpy always has to come after all other parameters
Whiteknight and what does a named slurpy have for it's signature? 17:36
allison :named :slurpy
Whiteknight is that "Pns"?
allison or, what do you mean?
Whiteknight the signature string. how is a named slurpy listed in the sig string?
allison yes, Pns 17:37
PARROT_ARG_NAME & PARROT_ARG_SLURPY_ARRAY
(even though it's a hash)
Whiteknight right
allison Would love to rename that to PARROT_ARG_AGGREGATE 17:38
or PARROT_ARG_COLLECT
Whiteknight and how will a lookahead be listed? It has a name, so will it be SnPl?
allison next refactor
Whiteknight or will it be SnlP?
(I'm just trying to prepare)
allison lookahead is positional 17:39
Austin What's lookahead
purl well, lookahead is easy.. it's lookBACK that weirds me out
allison Austin: an option that pmichaud requested
Whiteknight: why is the action for a named arg always 'break'? 17:40
Austin whiteknight: the pseudocode around "if current arg is lookahead" is broken. Nesting, maybe? 17:41
allison: named args mark the end of positionals in the upper loop.
allison you mean named parameters?
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"
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
I'm about to paste a new version with only one loop. One second...
allison but, you're not going to see a named arg, because named args are in a different data structure
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 nopaste.snit.ch/18182
Whiteknight this is why I want to write some pseudocode right now, to make sure I get all the details correct 17:46
don't want to waste time slinging code if it's going to be wron
allison Whiteknight: check slurpy before named, since slurpy trumps everything else
Whiteknight that's fine too 17:47
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?
allison :slurpy is optional by definition (it takes 0 or more arguments)
Whiteknight that's what I figured
Austin: that's what I believe to be true, yes 17:50
A quick union here {INTVAL, FLOATVAL, STRING *, PMC *} will make a lot of this code much more streamlined
nopaste "whiteknight" at 69.249.176.251 pasted "more pseudocode for allison++" (40 lines) at nopaste.snit.ch/18183 17:54
Whiteknight eventually I'm going to get this right out of sheer luck 17:56
nopaste "allison" at 77.98.130.30 pasted "Simplified algorithm for parameter/argument iteration" (46 lines) at nopaste.snit.ch/18184 17:58
Austin how expensive is hash delete? 17:59
allison The CallSignature shouldn't be modified (if you're asking about deleting each named argument as it's used) 18:01
Austin nopaste.snit.ch/18185
I was thinking shallow-copy + delete
Whiteknight that's sort of what I was thinking about with my iterator idea
allison Austin: it already is a shallow copy, but there's no advantage to deleting it from the CallSignature 18:02
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
Austin Speaking of shallow-copy, allison, what's the right way to propose a new/changed set of clone behaviors?
allison Austin: optional or non is mainly a question of what error condition to set 18:04
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
Austin I'll send the message, then. Thanks.
allison Whiteknight: your pseudocode is still mixing up arguments and parameters 18:06
"if current arg is slurpy" 18:07
args are never slurpy, params are
Whiteknight yeah
allison "if current arg is named" should actually be checking if current param is named
same with optional and opt_flag 18:08
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
actually.... 18:09
Austin Does the code support opt_flag for named params?
Whiteknight yessir
allison Austin: yes
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.
purl i guess lookahead is easy.. it's lookBACK that weirds me out
allison so, make "check next argument" a function instead of part of the loop
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?
allison Austin: yes
Austin Can lookaheads be optional?
(Of course) 18:12
allison Austin: yes, it can be "take the named if you've got it, else the positional, else nothing"
Whiteknight: it takes the call sig, and the current index, and returns a PMC
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)
Whiteknight: the thing is, all args are currently stored as pmcs
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
okay, return a PMC it is
Austin nopaste.snit.ch/18186 18:15
allison Austin: there are no default values 18:16
Austin For lookaheads?
allison Austin: that's what the opt_flag is for, to prevent you from looking at garbage
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.
Whiteknight that's only if we don't pass enough arguments and if error checking is turned off 18:18
Austin Okay.
allison Whiteknight: of course, if we put "fetch the next argument" into a function, we lose the advantage of automatic boxing and unboxing
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
Austin: and not necessary
Austin How not necessary? 18:21
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?
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:24
Austin: you have to check it anyway to know if you were passed a 0 or just got a 0 by default 18:25
so, there's really no point in setting the default 0
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
Whiteknight: second check in the infinite loop is "if there are not more arguments"
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"
allison Whiteknight: you can only check it for positionals
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
allison Austin: all they need to know is "check opt_flag to see if you got an argument"
Austin: there is no "when they don't check it"
Whiteknight: which information? 18:30
for each parameter we need: its flags, the value from CallSignature 18:31
(and error checking if there is no available value)
Whiteknight how are named arguments stored in the CallSignature? 18:32
allison Whiteknight: in a hash
string keyed access on the CallSignature fetches a named argument
integer keyed access fetches a positional argument
Whiteknight okay, I think I'm starting to pick up what I was missing 18:34
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?
wait, before that. What is raw_params? 18:36
that's the piece of this little puzzle that I don't understand
allison it's a pointer to the place in the opcode where the parameter list is given 18:37
it's necessary for actually storing the arguments into the appropriate registers
Whiteknight so a pointer to the get_args opcode in the callee?
allison no, a pointer to the get_params opcode
Whiteknight urg, that 18:38
allison (this is parameter side, not argument side)
Whiteknight has a very tenuous grasp on the english language
allison the arguments were already extracted from get_args into the CallSingature
Signature
purl Signature is parsed before hand
allison arguments and parameters are often muddled up in the literature, so it's quite understandable 18:39
if there were other words to describe them, I'd use them
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
"value of the current argument"
then we get the storage location of the first suitable parameter, and stuff it in there 18:42
allison yes
Austin Is there any valid semantics for opt_flag on a slurpy parameter?
Whiteknight Austin: no
slurpy is optional by default
allison no, slurpy parameter is always an array or hash, though it may be empty
Whiteknight (see, I've managed to retain some information today!)
Austin Thanks.
And is lookahead + slurpy invalid, I hope? 18:43
allison Austin: yes, they're semantically incompatible
Austin You left args.c out of the makefile, I think 18:44
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
bunch
allison Austin: it's in the makefile
Austin: re-run Configure.pl
Austin Update got it 18:46
Is there a target test case for this? 18:48
allison Austin: for lookahead?
Austin No, for functionality and performance of arg filling
allison Austin: there are lots of test cases, but none specifically designed to exercise all the option flags 18:49
Austin What about performance?
Is there a make-a-million-calls test, or something?
allison Austin: not yet
Austin ten thousand? 18:50
one hundred?
libparrot.so: undefined reference to `SETATTR_Key_next_key'
What's that? 18:51
purl that is probably how it does it.
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 nopaste.snit.ch/18187
Austin make coretest is the only target that works right now, yes? 18:55
mikehh make codetest also
Austin mikehh++
Thanks
mikehh make corevm
Austin Got a bunch of failures. 18:56
allison Austin: 414 last I checked
Austin Don't know yet.
My machine is old.
mikehh not even make corevm at the moment - fails on src/call/args.c 18:58
Austin update, mikehh
And check that #include
allison mikehh: update and rerun Configure.pl 18:59
dalek rrot: r41643 | allison++ | branches/pcc_reapply/src/call/args.c:
[pcc] Move header file with the function that used it.
Whiteknight allison: how do we determine if we've passed more named arguments then we have parameters for? 19:01
or do we ignore named overflow like that?
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
allison Whiteknight: at the moment, we can't 19:04
Whiteknight: they're silently ignored
Whiteknight ok
allison The complete alternative way of approaching this problem would be to start by iterating over the arguments passed 19:05
Whiteknight I like that idea if there is a sane way to iterate over named parameters too 19:06
without the param_flags, there's no way to know if the named parameters exist 19:07
...unless we can disect the CallSignature and get direct access to the underlying array and hash storage 19:08
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)
allison Whiteknight: yes, that would be cleaner
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
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
allison Whiteknight: it would also be good to avoid the cost of creating additional Iterator PMCs for the array and hash
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
allison I suppose the named arguments could be an ordered hash
19:12 darbelo left
dalek rrot: r41644 | mikehh++ | branches/pcc_reapply/MANIFEST:
run perl tools/dev/mk_manifest_and_skip.pl
 19:13
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
mikehh codetest fails - there are now 7 unused assert macros in include/parrot/call.h - passes the rest of codetest 19:15
19:17 kurahaupo joined
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
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
allison mikehh: that should be gone now, I deleted those call signatures
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
It's already much easier to understand
allison mikehh: so, once the source file is gone, it no longer knows to remove the corresponding header entries
kurahaupo Good morning everyone. 19:21
ļ»æ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:22
What's the procedure? Do I just submit a bugfix as part of my patch to replace the tests? 19:23
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']
$P0 = 10
$P0[7] = 23
$P0 = 5
$P0[9] = 0
Is it supposed to be that way? 19:25
allison kurahaupo: the size allocations are only a suggestion to resizable arrays
kurahaupo: it will always allocate space for an element 19:26
kurahaupo: yes, it's supposed to be that way
kurahaupo: the fixed size arrays are the ones that force you to stick within the declared size
nopaste "whiteknight" at 69.249.176.251 pasted "argument-based iteration processing for allison++" (50 lines) at nopaste.snit.ch/18188
kurahaupo This is for a resizeable array 19:27
Whiteknight allison: this pseudocode has a few more lines, but is much simpler conceptually
allison yes, it does simplify things
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)
^are^should be
19:28 cconstantine joined
allison kurahaupo: for an integer array, yes, if you try to access an element that hasn't been set, it should return 0 19:29
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 ...
allison Whiteknight: it's actually "get next parameter flag"
kurahaupo: resizable integer arrays don't pay attention to setting the size 19:31
kurahaupo: they just silently ignore it
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.
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
allison Whiteknight: jumping ahead to the optional flag while processing the optional argument is a headache 19:36
Whiteknight: it's easier to just iterate over the opt_flag as an ordinary parameter
Whiteknight: but, that's an implementation detail. 19:37
Whiteknight: if setting parameters is made sufficiently modular, it won't be a headache anymore, it'll be a simple function call
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
we can do parameters in any order we want
at that point it's just updating a counter 19:39
allison Whitekight: the headache is in storing, not in accessing
Whiteknight I'm not sure what you mean
allison Whiteknight: the question stands, if we're iterating over the arguments, we'll never know when we skipped an optional argument 19:40
Whiteknight: so there's no way to mark the opt_flag as false
Whiteknight but we have param_flags. We're sort of iterating over both, just letting the argument iteration take precidence
for any given parameter we have a flag that says "this is optional" 19:41
and we can associate that with a register number
allison Whiteknight: there's no handling here for "we have more positional parameters, but no more arguments" 19:42
Whiteknight: well, there is, but it doesn't look for optional parameters 19:43
Whiteknight: it can be handled by duplicating the "mark all remaining opt_flag parameters" code after both the positional and named loops 19:45
Whiteknight okay, we can do that 19:47
brb, I need to run a quick errand
nevermind, nowhere to go 19:48
allison Whiteknight: or, pull that loop up inside the other... 19:49
Whiteknight if we have a "get next parameter slot" and a "put back parameter slot" we can lookahead more easily 19:50
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
right, I'm conflating the two
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 nopaste.snit.ch/18189 19:52
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
Whiteknight but besides that, this looks good
right
allison Whiteknight: aye
Whiteknight where "if no parameter flag" is "if no suitable parameter flag"
I like this much better 19:54
allison Whiteknight: which is easy to check in named, but there's no flag for positional
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
allison it's easier to follow, and has a better parallel between the PIR and C cases
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
(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
allison yup
now to see if I can apply all this to return arguments 20:09
Whiteknight yeah 20:28
20:44 plobsing joined
bacek Good morning 20:44
kurahaupo Morning bacek 20:45
bacek kurahaupo: G'Day
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:46
plobsing hello 20:49
Whiteknight allison: already looking at it
plobsing i am interested in adding the libjit nci changes I have at github.com/plobsing/parrot-libjit 20:51
bacek is pcc_reapply open for commits? 20:59
allison bacek: yes 21:00
bacek allison: ok
dalek rrot: r41645 | bacek++ | branches/pcc_reapply/src/call/pcc.c:
[care] Remove unused set_context_sig_params and _results functions
 21:03
allison bacek: ah, if you're interested in removing unused code, I can point you at a lot more 21:04
dalek rrot: r41646 | bacek++ | branches/pcc_reapply/src/call/pcc.c:
[cage] Remove unused count_signature_elements function
 21:06
bacek allison: It's too early for me to start thinking. So I just warming up :) 21:07
dukeleto 'ello 21:08
allison bacek: pretty much all the static functions in src/call/pcc.c are candidates for removal
bacek allison: indeed. 21:09
allison bacek: correction, that's really all
bacek: and anything that calls them
21:09 ruoso joined
dalek rrot: r41647 | bacek++ | branches/pcc_reapply (2 files):
[cage] Remove unused Parrot_init_ret_nci and Parrot_init_args_nci functions
 21:10
bacek allison: give me half-an-hour. I'll kill them all.
allison bacek: I want to say "anything that isn't Parrot_pcc_invoke... or Parrot_PCCINVOKE" in that file (scanning to double-check)
bacek Parrot_PCCINVOKE is deprecated, isn't it? 21:11
allison bacek: confirmed on removing all but the Parrot_pcc_invoke functions 21:16
bacek allison: ok
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
bacek: nope, those functions from src/frame_builder.c can be removed too
bacek allison: emitm_call_cfunc(pc, Parrot_init_arg_nci); 21:19
frame builder should be updated to new implementation anyway
allison bacek: it's the set_nci_* and get_nci_*
(that can be removed entirely) 21:20
bacek allison: I removed them already. And commented out emitm_call_cfunc(pc, Parrot_init_arg_nci);
allison bacek: yes, that part will need to be updated 21:21
bacek: (calling Parrot_init_arg_nci there wouldn't work anymore anyway)
21:22 jan joined
bacek allison: indeed. "frame builder should be updated to new implementation anyway" :) 21:22
allison bacek: aye 21:23
dalek tracwiki: v100 | dukeleto++ | Languages
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
shorten dalek's url is at xrl.us/bfqbki
allison bacek: looks like that whole function Parrot_jit_build_call_func will need a serious workover 21:24
21:30 preflex joined 21:44 kthakore joined 22:09 kid51 joined 22:15 Tene joined
Tene O HAI GUYZ 22:15
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: build failure at 41647" (344 lines) at nopaste.snit.ch/18190 22:22
"bacek" at 110.175.160.228 pasted "Patch for review for allison++" (148 lines) at nopaste.snit.ch/18191 22:23
kid51 Death rattle begins at line 186 of src/frame_builder.c
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
nevermind, kid51 beat me to it.
allison bacek: sensible, it will save on repeating the code between each of the Parrot_call_sub* variants
kid51 GeJ++ You tied the failure to a commit! 22:25
bacek allison: ok. I'll commit it.
allison: How Parrot_call_method_* should be updated?
dalek rrot: r41648 | bacek++ | branches/pcc_reapply/src/frame_builder.c:
Make frame_builder.c buildable but broken
 22:26
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?
allison Parrot_pcc_invoke_from_sig_object works for subs and methods 22:28
bacek: no, all of these functions are deprecated and will be replaced with a single function
bacek allison: ok. 22:29
allison bacek: it's only temporary to have all this silly code duplication
bacek allison: yeah. But I trying to wrap my head around new functions.
allison bacek: yeah, it is a wholesale replacement, lots of changes to the internal interface 22:30
Tene Looks like I'm getting linking errors when compiling miniparrot. undefined reference to set_nci_* 22:34
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply: build failure at 41648" (505 lines) at nopaste.snit.ch/18192 22:35
Tene Yeah, that.
purl Sure, that.
bacek Try r41649 22:36
dalek rrot: r41649 | bacek++ | branches/pcc_reapply/src/frame_builder.c:
Comment out more stuff in frame_builder.c
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?
kid51 make completes at r41649 22:39
allison Parrot_call_method used its own bizarre signature strings
bacek allison: ouch... 22:40
allison bacek: (that's why they're deprecated)
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?
allison bacek: that should do it
bacek allison: ok.
allison bacek: you may have to remove an O argument, if it was passing one
bacek allison: can you give example of signature? 22:42
22:43 jimk joined
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
allison implement it as if there's no signature element for the object
(just like Parrot_call_sub 22:44
)
we'll run testing with external users
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
japhb Austin, ping 22:47
Austin pong
'sup?
japhb I've pushed a version of Plumage that can be told to ignore failures in a build stage.
In particular, you can ./plumage --ignore-fail=test install Close
Austin sweet/
.
japhb ... except it only *appears* to work for me, because I appear to get a non-functional parrot-close binary. 22:48
Can you take a look?
Austin If only I could do the same thing in development. :|
japhb heh
Austin Probably. The trunk doesn't work at the moment.
I'd say you're getting it right.
japhb ah. Well, that would explain things
nopaste "bacek" at 110.175.160.228 pasted "Parrot_call_method patch for allison" (58 lines) at nopaste.snit.ch/18193
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
japhb Austin, at the moment, within the current directory. That's on the short list to fix. 22:49
Austin That's fine. I'll test plumage to make sure that the breaks work the same way. 22:50
And no, there's no branch that builds with a current parrot.
Sorry.
I'll see what I can produce, though. 22:51
japhb Austin, is there one that builds with Rakudo's current required version (r41447)?
Austin Nope.
jimk Smolder on branch: smolder.plusthree.com/app/public_pr...ails/28492
shorten jimk's url is at xrl.us/bfqbs2
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
Austin You have to get in the way-back machine to find a good parrot.
japhb d'oh!
Austin japhb++
Good job getting so far so fast with plumage. 22:52
japhb Thank you. :-)
allison bacek: but if you remove arg_sig[0] = 0; and allocate arg_sig as strlen(signature)+1 it should be good
bacek allison: can you give me example of Parrot_call_method signature? 22:53
allison vP
a void return and a PMC argument
bacek ok
allison or PP, a PMC return and a PMC argument
that is, assume it's the same as Parrot_call_sub
22:53 kid51 joined
bacek char *arg_sig = (char*)malloc(strlen(signature)+2); 22:53
arg_sig[0] = 'P';
arg_sig[1] = 'i';
arg_sig[2] = 0;
strcat(arg_sig, signature + 1);
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?
japhb: no
bacek allison: is this correct?
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
Any opinions?
allison since we're removing signature[0] it should only need to allocate one extra character
Tene: yes, which test?
Tene: or, are you looking for a test to tackle?
Tene allison: the latter
purl the latter is, like, better
Tene japhb: I think I prefer the last, but just barely
bacek allison: plus '\\0' at the end
Tene japhb: I kind of dislike the second. 22:56
allison bacek: won't the original char * already have '\\0' at the end?
japhb Tene, OK, fair enough.
bacek but strlen doesn't count it
allison Tene: t/pmc/namespace.t is a matter of fixing the test not to use 'like'
bacek: ah, yes
japhb Any other opinions from the peanut gallery? (It's not like I can't change it later, of course)
allison Tene: (this is a general fix, no core tests should use like because no core tests should depend on PGE) 22:57
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:58
Tene: t/pmc/integer.t is another one that needs to not use 'like' 22:59
22:59 Khisanth joined
japhb Tene: did you ever get around to coding that tree-like data structure merge function? 23:00
Tene japhb: No.
japhb Tene, OK, np.
Just wanted to make sure I wasn't going to duplicate something you'd written but just not pushed. ;-)
dalek rrot: r41650 | bacek++ | branches/pcc_reapply/src/extend.c:
Update Parrot_call_sub_ret_* function to use new PCC
 23:02
rrot: r41651 | bacek++ | branches/pcc_reapply/src/extend.c:
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.
rrot: r41652 | bacek++ | branches/pcc_reapply (4 files):
[cage] Remove bunch of unused functions
allison Tene: t/oo/metamodel.t is looking for a 'fail' subroutine that doesn't seem to exist
Tene Does anyone object to the name 'throws_substring' for a text-comparison workalike to 'throws_like'? 23:04
allison Tene: sounds like a good idea 23:05
Tene: with arguments for start position and length?
Tene: (maybe optional named arguments?) 23:06
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:07
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
"is the passed text a substring of the text of the exception, if any?
allison Tene: just checking "does this substring appear somewhere inside the larger string"? makes sense 23:09
Tene Yes.
allison Tene: yeah, that's all that's really needed 23:10
23:13 Zak joined 23:14 ZeroForce joined
nopaste "kid51" at 70.85.31.226 pasted "t/pmc/*.t using 'throws_like()'" (3 lines) at nopaste.snit.ch/18194 23:16
23:18 quek joined
dalek rrot: r41653 | allison++ | branches/pcc_reapply/t/op/annotate.t:
[pcc] Undo double pop on the exception handler (likely a merge problem).
 23:22
bacek allison: can you check r41654? Looks like it's better to move this constants assignment inside invoke_from_sig_object. 23:31
dalek rrot: r41654 | bacek++ | branches/pcc_reapply/src/extend.c:
Propogate constants to context. Claim few more passing tests.
rrot: r41655 | tene++ | branches/pcc_reapply (5 files):
Add 'substring' and 'throws_substring' functions to Test::More
 23:35
Tene allison: those three tests now all pass.
allison Tene: excellent! 23:40
purl plays air guitar
dalek rrot: r41656 | bacek++ | branches/pcc_reapply/t/op/cc_state.t:
[t] Update test to reflect current error message from PCC.
 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.
I can add one in very easily, though. 23:42
allison Tene: it's possible that the failure code has just never been called 23:44
Tene Hmm. True.
allison Tene: or that Test::More had a fail function a long time ago
Tene committed 23:45
I'll look at t/pmc/multidispatch now 23:47
dalek rrot: r41657 | tene++ | branches/pcc_reapply/t/oo/metamodel.t:
Add a fail sub to oo/metamodel.t so that it can fail properly
 23:48
nopaste "bacek" at 110.175.160.228 pasted "Fix handling of null CallSignature in fill_returns for allison" (14 lines) at nopaste.snit.ch/18195 23:51
dalek tracwiki: v7 | allison++ | CallingConventionsOverview 23:56
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqbxt
allison bacek: yes, that's the right fix
bacek allison: committed. 23:57
dalek rrot: r41658 | bacek++ | branches/pcc_reapply/src/call/args.c:
Fix handling null CallSignature in Parrot_pcc_fill_returns_* functions.
23:58 davidfetter joined
bacek Found good Configure.pl option: --buildframes=0 23:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!