Camelia, the Perl 6 bug

IRC log for #parrot, 2010-03-06

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 shockwave Have a good weekend guys (and gals).
00:00 shockwave Peace!
00:00 shockwave left #parrot
00:06 dalek parrot: r44666 | bacek++ | branches/ops_pct/compilers/opsc/t/04-op.t:
00:06 dalek parrot: Remove outdated test
00:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44666/
00:06 dalek parrot: r44667 | bacek++ | branches/ops_pct/compilers/opsc (6 files):
00:06 dalek parrot: Add skeleton for emitter.
00:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44667/
00:06 dalek parrot: r44668 | bacek++ | branches/ops_pct/compilers/opsc/t/06-emitter.t:
00:06 dalek parrot: Add test for Emitter.
00:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44668/
00:06 dalek parrot: r44669 | bacek++ | branches/ops_pct/compilers/opsc (3 files):
00:06 dalek parrot: Start c header emitting
00:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44669/
00:06 dalek parrot: r44670 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
00:06 dalek parrot: Emit preamble
00:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44670/
00:07 tetragon joined #parrot
00:11 snarkyboojum joined #parrot
00:14 snarkyboojum joined #parrot
00:38 payload joined #parrot
00:58 parthm joined #parrot
01:22 Whiteknight joined #parrot
01:26 Whiteknight barely able to get online tonigh
01:26 Whiteknight (wireless routers)--
01:30 Whiteknight isn't there just a "-Wall" option we can use instead of specifying every single individual warning by name?
01:32 bacek joined #parrot
01:35 rblackwe left #parrot
01:35 Whiteknight holy crap the build is moving quick tonight
01:38 kid51 Whiteknight:  Whenever I see that option, I think:  "Compile this with everything Larry recommends"  :-)
01:38 GeJ Good morning everyone.
01:38 Whiteknight kid51: We obviously want a very strict, tight build. It seems like we should just enable all warnings instead of just enabling most of them
01:38 GeJ kid51: seconded.
01:38 Whiteknight hello GeJ
01:39 rblackwe joined #parrot
01:39 GeJ Hello Andrew, James.
01:39 bubaflub joined #parrot
01:40 kid51 Coke probably knows a *lot* about those warnings, having waded thru that branch.
01:40 kid51 And, of course, AndyD will have an expert opinion.
01:40 bacek aloha
01:40 bacek seen cotto
01:40 purl cotto was last seen on #parrot 1 days, 17 hours, 17 minutes and 28 seconds ago, saying: chromatic, would it be worthwhile to rip them out?  [Mar  4 08:23:18 2010]
01:40 bacek seen cotto_work
01:40 purl cotto_work was last seen on #parrot 4 hours, 1 minutes and 49 seconds ago, saying: moving tiem
01:41 GeJ G'Day bacek.
01:42 plobsing bacek: any words of advice on TT #1499?
01:42 bacek plobsing, shenanigans...
01:42 bacek G'Day GeJ
01:42 bacek plobsing, I wasn't able to trace it down...
01:44 Whiteknight every time I see fill_params, I cry a little on the inside
01:44 Whiteknight I know it's all necessary, and I know it's not bad code, but still. It's huge
01:45 Coke Whiteknight: -Wall isn't really all
01:45 Coke it's just "a lot".
01:45 Coke also, as chromatic has pointed out, -Wall doesn't mean the same warnings every release.
01:45 Whiteknight Coke: do we enable more warnings than that?'
01:45 Coke Whiteknight: yes.
01:45 Whiteknight ah, okay then
01:46 Whiteknight I rescind my critique
01:47 Whiteknight Parrot_pcc_fill_returns_from_* is going to be a lot of work to redo, and fill_returns() is going to require big effort
01:49 Whiteknight actually, I take it back. The only places that really appear to be using those functions still in the branch are the nci thunks
01:49 dalek rakudo: 974d9a8 | (Solomon Foster)++ | t/spectest.data:
01:49 dalek rakudo: Turn on S14-roles/basic.t.
01:49 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​74d9a82a2652165d6819028df1a96e0e4138836
01:52 dalek parrot: r44671 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
01:53 dalek parrot: Properly store Ops::Op.arg_types.
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44671/
01:53 dalek parrot: r44672 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
01:53 dalek parrot: Add test for Ops::Op.full_name
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44672/
01:53 dalek parrot: r44673 | bacek++ | branches/ops_pct/compilers/opsc/src/builtins.pir:
01:53 dalek parrot: Add sprintf into builtins
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44673/
01:53 dalek parrot: r44674 | bacek++ | branches/ops_pct/compilers/ops​c/src/Ops/Compiler/Actions.pm:
01:53 dalek parrot: Once again emit Ops::Op in Compiler::Action
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44674/
01:53 dalek parrot: r44675 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
01:53 dalek parrot: Add more stubs for Ops body rewriting
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44675/
01:53 dalek parrot: r44676 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
01:53 dalek parrot: Drop parser_ops from Ops::File. Store just ops
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44676/
01:53 dalek parrot: r44677 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (2 files):
01:53 dalek parrot: Add preparing ops to Tanscode
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44677/
01:53 dalek parrot: r44678 | bacek++ | branches/ops_pct/compilers​/opsc/src/Ops/Emitter.pm:
01:53 dalek parrot: Prepare ops in trans. Emit trans-specific header part
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44678/
01:53 dalek parrot: r44679 | whiteknight++ | branches/pcc_hackathon_6Mar10/src/call/args.c:
01:53 dalek parrot: in Parrot_pcc_build_sig_object_from_varargs, we can skip information here about returns handling. We're probably going to need to create a new function somewhere to unpack the returns back from the return CallContext in places like Parrot_pcc_invoke_sig_object and family
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44679/
01:53 dalek parrot: r44680 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
01:53 dalek parrot: Add loading version in Ops::File
01:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44680/
01:58 plobsing hmmm, I can't build with the versions given in TT #1499, rakudo is trying to use PObj_active_destroy_SET (which I'm pretty sure has been axed for a while)
02:03 Whiteknight yeah
02:03 Whiteknight that was supposed to have been removed months ago, but the patch didnt catch all uses
02:04 Whiteknight so Rakudo was never "motivated" to use the alternative
02:04 atrodo joined #parrot
02:08 dalek parrot: r44681 | coke++ | trunk/lib/Parrot/Configure/Compiler.pm:
02:08 dalek parrot: Remove apparently unused function.
02:08 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44681/
02:10 * Whiteknight hasd to go. battery running out. Need to prepare for hackathon tomorrow. Later
02:11 Coke we should totally be using the gcc deprecated attribute.
02:31 Andy joined #parrot
02:32 Andy log
02:39 dukeleto 'ello
02:40 bubaflub hola dukeleto
02:40 dukeleto bubaflub: howdy!
02:40 dukeleto bubaflub: have you been thinking of gsoc ideas?
02:40 bubaflub whatcha hackin' on?
02:40 bubaflub dukeleto: i have, i shot ya an email with some ideas
02:40 bubaflub do we need Math::Primality-esque stuff for Parrot or Rakudo?
02:41 dukeleto bubaflub: yes, i saw the email but didn't have time to respond
02:41 bubaflub yeah, i reckon'd as much
02:41 dukeleto bubaflub: yes, but lower-level stuff needs doin' first
02:41 bubaflub yeah, do we have usable bindings to GMP?
02:41 dukeleto bubaflub: have you looked at whiteknights blog posts about gsoc ideas?
02:42 bubaflub yeah, i also thought about doing the unicode string overhaul one
02:42 dukeleto bubaflub: parrot has a PMC interface to GMP, but the access to the whole library is not there
02:42 * dukeleto is hacking a scotch + club soda together
02:43 bubaflub dukeleto: GSOC or not i can hack a bit on some GMP stuff
02:44 chromatic Strings would be very, very useful.
02:49 bubaflub if i were to do the strings overhaul, is there something i should be hacking on now?
02:49 szabgabx_ joined #parrot
02:51 dukeleto bubaflub: start with whiteknights writeup and go from there. I am not the best person to ask about that stuff
02:53 dukeleto bubaflub: is there a wiki page/TT for that stuff?
02:53 dukeleto chromatic: do you have any direction for bubaflub ?
02:54 bubaflub dukeleto, all i'm seeing on http://wknight8111.blogspot.com/201​0/01/gsoc-idea-strings-and-nfg.html is the PDD
02:55 dukeleto chromatic: i read PDD18 (security) last night. it seems all very high level. has nothing in there been implemented yet?
02:56 chromatic No to both questions.
02:56 chromatic With that said, pluggable runloops (as tewk has experimented) give us more options for security and such.
02:57 dukeleto chromatic: it seems that PL/Parrot will drive a lot of security features in Parrot
02:57 dukeleto chromatic: the most important thing I need is to disable all file I/O
02:58 dukeleto chromatic: do you have any suggestions for accomplishing that?
03:00 chromatic The best idea I've seen so far is to provide some sort of op_info table (and we have one) which groups ops into capabilities, or holds flags representing capabilities.
03:00 chromatic For every op dispatched in the runloop, check against a mask of allowed caps.
03:01 dukeleto chromatic: ok, that sounds like a direction i can go in
03:02 dukeleto chromatic: where can i learn more about the op_info table?
03:04 dukeleto i see that ops can be defined with group membership like: inline op print(in INT) :base_io,io {
03:05 plobsing chromatic: that sounds nifty, but aren't we moving more towards PMCs to do more (potentially protected) stuff? maybe we need to put some checks into new?
03:06 dukeleto plobsing: i would rather disable opcodes than have PMCs require logic to disallow things
03:06 dukeleto plobsing: but both are possible
03:07 plobsing (new Filehandle).open.do_bad_things
03:07 dukeleto plobsing: from the standpoint of PL/Parrot, DBA's want to disallow stored procedures to access the filesystem. how would you accomplish that with PMCs?
03:09 chromatic That's a good question and I don't have an answer for it now.
03:10 dukeleto chromatic: is there any docs for the op_info table? PDD18 doesn't mention it
03:10 plobsing even worse: (new OS).muk_around_with_filesystem
03:11 jimk joined #parrot
03:12 chromatic I'm not aware of any docs.
03:13 chromatic Remember about PMCs: PL/Parrot or something else may create its own PMCs and try to perform known-safe operations on them, so appropriate scoping of security is important.
03:13 dukeleto chromatic: do you know where i can find a list of valid op groups?
03:13 dukeleto chromatic: duly noted
03:14 chromatic dukeleto, I think it's ad hoc so far.
03:15 dukeleto i see :base_core, :deprecated, :object_classes, :base_math, :base_io, :filesys_open, :flow, :check_event and that is it
03:15 dukeleto chromatic: if I wanted to document those, should I put that in PDD18 ? it doesn't seem like anyone is actually doing anything with these groups
03:15 dukeleto chromatic: is there a way to lookup what group an opcode is in?
03:16 chromatic I don't know a good way, off hand.
03:16 chromatic We may not do anything with that information.
03:16 chromatic Here's your chance to help define a good API.
03:16 dukeleto chromatic: ok, i am all about that. should I create a TT with an RFC for the API to do that?
03:17 * jimk nods at #parrot and gives him a small kipper
03:20 chromatic Please do.
03:20 dukeleto chromatic: ok, i am on it.
03:21 dukeleto this is needs to be done before any progress on implementing PDD18 can move forward
03:21 mj41_ joined #parrot
03:22 * dukeleto is excited to see that PL/Parrot is drving new features in Parrot
03:22 dukeleto chromatic: i actually got postgres to run PIR code recently, but I am still figuring out how to marshall function arguments and return values
03:27 parthm left #parrot
03:36 dukeleto chromatic: i am reading op_info_t in core_ops.c, and I don't see the opcode groups being stored in there
03:40 dukeleto chromatic: i see them in lib/Parrot/OpLib/core.pm, though
03:40 dukeleto :q
03:41 janus joined #parrot
03:42 dukeleto seems that there is no other instances of opcode groups except when an op is defined and in lib/Parrot/OpLib/core.pm
04:01 dukeleto woot. i got TT 1500
04:07 dukeleto chromatic: TT made and parrot-dev poked
04:12 dalek TT #1500 created by dukeleto++: API to tell which opcode group an opcode is in
04:24 mj41_ joined #parrot
04:26 ttbot joined #parrot
07:53 davidfetter joined #parrot
07:55 fperrad joined #parrot
08:08 Austin_Hastings joined #parrot
08:43 iblechbot joined #parrot
08:52 lucian joined #parrot
09:25 bacek joined #parrot
09:34 cotto hi bacek
09:35 bacek cotto, aloha!
09:35 cotto I see you've been busy
09:36 bacek I wanna made opsc functional over weekend.
09:36 bacek headers part are mostly done
09:36 cotto That's ambitious.
09:37 cotto bacek++
09:43 bacek cotto, will you have couple of spare hours to hack on?
09:44 cottoo joined #parrot
09:44 cottoo yup
09:45 bacek Ops::Op._substitute require some love :)
09:45 cottoo I'll give it a hug.
09:45 cottoo I was just looking at it.
09:46 bacek excellent
09:47 bacek Just add bunch of "pure-virtual functions" to Ops::Trans, implement them in Ops::Trans::C and we are golden
09:47 bacek I'm switching to c emitting.
09:48 bacek Headers are done :)
09:48 cotto Nice.
09:48 cotto I'll need to sleep eventually, but that'll give me something to hack on whenever I wake up.
09:49 bacek Ok
09:50 cotto Does anything test Ops::Trans::C yet?
09:51 cotto nm
09:51 bacek 06-emitter
09:52 mikehh bacek: you want me to add svn properties and fix MANIFEST?
09:52 bacek but we do need separate test for Trans::C
09:52 bacek mikehh, too early. But feel free to get cheap karma :)
09:52 mikehh :-}
09:52 bacek (Ignore svn properties. I'll merge with git and lost them anyway)
09:56 dalek parrot: r44682 | cotto++ | branches/ops_pct/compilers/opsc (3 files):
09:56 dalek parrot: [opsc] add some more substitutions to munch_body, make Op.pm responsible for op-specific knowledge
09:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44682/
09:57 dalek parrot: r44683 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
09:57 dalek parrot: Store syn_export and init_func fields. Finish generating headers.
09:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44683/
09:57 dalek parrot: r44684 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
09:57 dalek parrot: Comment out debug output.
09:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44684/
09:57 dalek parrot: r44685 | bacek++ | branches/ops_pct/compilers​/opsc/src/Ops/Trans/C.pm:
09:57 dalek parrot: Use accessor instead of direct hash access to Emitter.syn_export
09:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44685/
09:59 cotto time for sleep.  Happy hacking bacek!
10:04 payload joined #parrot
10:06 mikehh in trunk I get a warning in the build I haven't seen before - anyone any idea what it means:
10:06 mikehh /usr/local/bin/perl tools/build/pmc2c.pl --c  src/pmc/parrotthread.pmc
10:06 mikehh PMC has attributes but no auto_attrs or manual_attrs at /home/mhb/parrot/tools/build/../.​./lib/Parrot/Pmc2c/PMCEmitter.pm line 744.
10:06 mikehh /usr/local/bin/perl tools/build/c2str.pl src/pmc/parrotthread.c > src/pmc/parrotthread.str
10:15 mikehh even with that -
10:15 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32524), fulltest) at r44685 - Ubuntu 9.10 amd64 (g++ with --optimize)
10:22 AndyA joined #parrot
10:42 eternaleye joined #parrot
10:44 bacek mikehh, ask NotFound. He start moving to auto_attrs as default
11:04 mikehh bacek: yes - creating a ticket
11:25 dalek TT #1501 created by mikehh++: parrotthread.pmc - PMC has attributes but no auto_attrs or manual_attrs
11:43 snarkyboojum joined #parrot
11:51 clinton joined #parrot
11:53 dalek parrot: r44686 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
11:54 dalek parrot: Add stub for emitting C source
11:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44686/
11:54 dalek parrot: r44687 | bacek++ | branches/ops_pct/compilers/opsc (3 files):
11:54 dalek parrot: Preserve ops preamble in Ops::File
11:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44687/
11:54 dalek parrot: r44688 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (3 files):
11:54 dalek parrot: Add more stuff for emitting C source
11:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44688/
11:54 dalek parrot: r44689 | bacek++ | branches/ops_pct/compilers/opsc/t/06-emitter.t:
11:54 dalek parrot: Add tests for emitting C source.
11:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44689/
11:54 dalek parrot: r44690 | bacek++ | branches/ops_pct/compilers/opsc (4 files):
11:54 dalek parrot: Add Trans.source_preamble
11:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44690/
11:54 dalek parrot: r44691 | bacek++ | branches/ops_pct/compilers/opsc (4 files):
11:54 dalek parrot: Add emiting init_func and dynload
11:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44691/
11:54 dalek parrot: r44692 | bacek++ | branches/ops_pct/compilers/opsc (4 files):
11:54 dalek parrot: Add emiting op_lookup
11:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44692/
11:54 dalek parrot: r44693 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Trans.pm:
11:54 dalek parrot: Add Trans.core_type
11:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44693/
11:54 dalek parrot: r44694 | bacek++ | branches/ops_pct/compilers/opsc (5 files):
11:54 dalek parrot: Add emiting op lib description
11:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44694/
11:56 snarkyboojum_ joined #parrot
12:06 cognominal joined #parrot
12:07 payload joined #parrot
12:09 payload joined #parrot
12:23 TzAnAnY joined #parrot
12:23 TzAnAnY hello all i have a question
12:23 TzAnAnY there is TimeOut (Alarm) Command For win32?
12:30 Whiteknight joined #parrot
12:35 Whiteknight good morning everybody!
12:41 Whiteknight Everybody ready for T3H M4J0R H4XX0RING?
12:43 dalek parrot: r44695 | mikehh++ | branches/ops_pct/MANIFEST:
12:43 dalek parrot: regenerate MANIFEST
12:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44695/
12:45 mikehh hi whiteknight and yes just waitin to test
12:45 Whiteknight awesome
12:45 mikehh fiddlin' with ops_pct branch at the moment
12:46 iblechbot joined #parrot
12:49 Whiteknight yeah, I've seen a lot of activity over there recently
12:50 joeri joined #parrot
12:50 Whiteknight allison: ping
12:54 mikehh anyway got to go do some shopping - bbl
12:54 Whiteknight purl msg allison I'm thinking Parrot_pcc_invoke_sig_object should return the results CallContext, so it can be unpacked by a function that knows how to do the unpacking like Parrot_pcc_invoke_method_from_c_args, or Parrot_pcc_invoke_method_from_op
12:54 purl Message for allison stored.
12:59 dalek parrot: r44696 | mikehh++ | branches/ops_pct/compilers/n​qp/src/quote_expression.pir:
12:59 dalek parrot: fix copyright statement
12:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44696/
12:59 dalek parrot: r44697 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (3 files):
12:59 dalek parrot: Pass emitter into emit_source_part
12:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44697/
12:59 dalek parrot: r44698 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
13:00 dalek parrot: Workadound scalar/list in Op.size
13:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44698/
13:00 dalek parrot: r44699 | bacek++ | branches/ops_pct/ext/nqp-rx/src/gen/settings.pm:
13:00 dalek parrot: Update NQP settings.
13:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44699/
13:00 dalek parrot: r44700 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
13:00 dalek parrot: Implement emitting op_info_table and op_func_table
13:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44700/
13:00 dalek parrot: r44701 | bacek++ | branches/ops_pct/compilers/opsc/TODO:
13:00 dalek parrot: Add TODO for cotto++
13:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44701/
13:04 kid51 joined #parrot
13:06 mikehh_ joined #parrot
13:11 bacek msg cotto Good morning! Looks like I finished end-2-end emitting for Trans::C. I added simple TODO file. As soon as we can have first 4 items done we can try to use opsc in "real world" :)
13:11 purl Message for cotto stored.
13:13 allison Whiteknight: it doesn't return the context, the context is accessed the same as it is in opcode calls
13:14 allison Whiteknight: specifically, the CallContext object that contains the return values is the same PMC as the one that passed in the arguments to the function
13:16 dalek parrot: r44702 | bacek++ | branches/ops_pct/compilers/opsc/TODO:
13:16 dalek parrot: Update todo.
13:16 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44702/
13:16 mikehh joined #parrot
13:16 allison Whiteknight: the main thing to wrap your head around is the fact that fetching return values is now exactly the same process as filling parameters
13:32 Whiteknight allison: I've got the process in my head no problem. I'm just trying to figure out where the unpacking of the returns CallContext happens
13:33 Whiteknight and if we are explicitly recycling the parameters CallContext, that does make a lot of things easier
13:34 Whiteknight still going to require some munging in Parrot_pcc_invoke_method_from_c_args, because we can't have two open va_lists in a portable way, so we're going to need to cache the return value pointers, call va_end, invoke the Sub, and then unpack the returns
13:36 allison as in, we may still have to store pointers to the result destinations locally within the function, so we don't have to keep the va_list around
13:37 Whiteknight exactly
13:38 Whiteknight Two options I can think of: Modify Parrot_pcc_build_sig_object_from_* to return in an ARGOUT(int) the index where the return params start, and pass that to another function to count them and allocate array space to hold pointers
13:38 Whiteknight or, just have a second function that parses the signature from the beginning and returns storage
13:40 Whiteknight it bugs the hell out of me that some of these functions that an FIA to parse the flags
13:41 dalek tracwiki: v22 | allison++ | CallingConventionsTasklist
13:41 dalek tracwiki: http://trac.parrot.org/parrot/wiki/CallingCo​nventionsTasklist?version=22&action=diff
13:41 dalek tracwiki: v23 | allison++ | CallingConventionsTasklist
13:41 dalek tracwiki: http://trac.parrot.org/parrot/wiki/CallingCo​nventionsTasklist?version=23&action=diff
13:43 allison Whiteknight: well, there's no reason we can't continue parsing the full signature at the start and store it in the CallContext
13:44 allison that is, store the return signature FIA in the CallContext
13:44 Whiteknight we dont always have an FIA
13:45 allison the first thing Parrot_pcc_build_sig_object_from_varargs does is build one
13:45 allison It used to build two: one for args and one for returns
13:47 allison Whiteknight: op calls will never have a return sig from the start, though
13:47 allison Whiteknight: so it's better to store that information locally, than to cache it in the CallContext
13:48 Whiteknight right
13:55 Whiteknight this refactor is going to be larger than I anticipated
13:55 allison it's mainly a matter of deleting code
13:56 Whiteknight all the _from_c_args and *_varags func need to be rewritten
13:57 Whiteknight in the future, caching information about returns in the callsig will allow us to check expectations
13:57 allison but you can't rely on it to check expectations, since it's not always set
13:58 allison better to have an explicit separate step setting "wants"
13:58 Whiteknight that's fine too
13:59 allison well, half the *_from_c_args *_varargs functions just go away
14:05 allison Whiteknight: what platforms barf on using one va_list within another
14:05 atrodo joined #parrot
14:06 Whiteknight Not sure. bacek was talking about it yeterday, and I just trust what he says
14:06 allison Whiteknight: the ideal solution is to process the args half of the va_list, make the call, then process the returns half of the va_list
14:07 Whiteknight if we copy the returns hal of va_list into an array, we can process it separately
14:07 dalek parrot: r44703 | allison++ | branches/pcc_hackathon_6Mar10/src/call/args.c:
14:07 dalek parrot: [pcc] Fix compilation and runtime errors.
14:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44703/
14:07 dalek parrot: r44704 | allison++ | branches/pcc_hackathon_6Mar10 (2 files):
14:07 dalek parrot: [pcc] Remove deprecated and unused function for old-style return
14:07 dalek parrot: handling from an op.
14:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44704/
14:08 allison Whiteknight: yeah, but it's an array of pointers, and that funky pointer storage is one of the things we were trying to avoid
14:08 allison at least it's only a local array of pointers
14:09 allison doesn't even have to be a PMC
14:09 Whiteknight exactly
14:11 Psyche^ joined #parrot
14:24 dalek parrot: r44705 | jonathan++ | trunk/src/runcore/main.c:
14:24 dalek parrot: [loadlib] Though shalt always use the return value of realloc calls, otherwise segfaults happen.
14:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44705/
14:25 Whiteknight amen!
14:32 Whiteknight should parse_signature_string continue to return a PMC** to the returns FIA, or should it just return an index in the string where the returns start?
14:40 allison it should keep parsing the full string
14:41 allison but, I'm speculating on whether the various functions that currenly accept only a signature string should accept a FIA instead
14:41 allison that is, parse the signature string once when we first hit it
14:41 allison rather than reparsing it over and over again
14:42 allison either that, or we need a "split_signature_string"
14:43 dalek rakudo: 8505d39 | Worthington@.(none)++ | src/builtins/Mu.pir:
14:43 dalek rakudo: Fix has %.noms.
14:43 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​505d39fc6aa7fe963b519a1ca9a2b4134823ffb
14:43 allison and then parse_signature_string switches over to expecting only args/returns, not both combined
14:43 allison in fact, that's probably the better solution
14:44 allison all calls to parse_signature_string now ignore the second half
14:45 TzAnAnY left #parrot
15:00 PacoLinux joined #parrot
15:00 dalek rakudo: 43f5a52 | (Solomon Foster)++ | build/PARROT_REVISION:
15:00 dalek rakudo: Bump parrot.
15:00 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​3f5a52c83ba384d690f14e6b579295329edefd3
15:07 Whiteknight allison: if all uses of parse_signature_string ignore the second half, that may just be our answer. Let's cut it so it only parses half a signature
15:08 allison Whiteknight: well, see it needs a different half at different times
15:08 allison but, it only ever needs one half
15:09 Whiteknight and the two halves can basically be parsed to FIA without knowing which it is
15:10 allison for example: Parrot_pcc_fill_params_from_c_args will be called both for filling parameters, and for filling results
15:10 allison it calls parse_signature_string
15:10 allison so, half the time it'll be parsing an arg signature, and half the time a return signature
15:10 Whiteknight exactly
15:10 allison it doesn't have to know which is which
15:11 allison so, if we split the signature string when it first enters the system
15:11 allison in Parrot_pcc_invoke_method_from_c_args, for example
15:12 allison then we never have to handle the bundled singnature again
15:27 allison Whiteknight: hmmm... what bacek actually said is that va_list can't be "restarted"
15:27 allison Whiteknight: but we aren't restarting it, just handling it in two separate function calls
15:34 dalek rakudo: ab3f44b | (Solomon Foster)++ | src/ (2 files):
15:34 dalek rakudo: Quick implementation of !===.  (Should be a meta op, but this will work for now.)
15:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​b3f44bb1435b28fb08ef3ab03433d8500718bb6
15:34 dalek rakudo: 7882db4 | (Solomon Foster)++ | t/spectest.data:
15:34 dalek rakudo: Turn on S03-operators/value_equivalence.t.
15:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​882db4f0b6eda5174f615569253cae690d44b74
15:35 Psyche^ joined #parrot
15:39 tetragon joined #parrot
15:40 allison Whiteknight: ah, interesting, I've always used va_list as if it were a consuming iterator
15:42 nopaste "allison" at 77.98.130.30 pasted "method 1 of passing va_list" (28 lines) at http://nopaste.snit.ch/19862
15:45 nopaste "allison" at 77.98.130.30 pasted "method 2 of passing va_list, as a pointer" (23 lines) at http://nopaste.snit.ch/19863
15:46 payload left #parrot
15:52 dalek rakudo: 28f5203 | (Solomon Foster)++ | t/spectest.data:
15:52 dalek rakudo: Turn on S06-traits/is-rw.t.  arnsholt++.
15:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​8f5203fdabe1ce247be0b1cc4964e3ba1c54d90
16:01 kurahaupo joined #parrot
16:14 payload joined #parrot
16:17 payload1 joined #parrot
16:24 snarkyboojum_ joined #parrot
16:26 dalek rakudo: ba6cd4e | (Solomon Foster)++ | src/builtins/ (2 files):
16:26 dalek rakudo: Change === on Num to return Bool, and clean up === on Int.  baest++
16:26 purl dalek: that doesn't look right
16:26 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​a6cd4e9ea7cc14dafc2759e34808f48b2f2a929
16:44 AndyA joined #parrot
16:50 dukeleto 'ello
16:50 theory joined #parrot
17:03 allison hi
17:03 purl hi, allison.
17:05 cotto bacek++ for being awesome
17:12 davidfetter oh hai
17:17 cotto Happy Cat- and/or Saturday!
17:22 davidfetter .oO([CS]aturday)
17:23 dalek rakudo: c054780 | (Solomon Foster)++ | t/spectest.data:
17:23 dalek rakudo: Turn on S02-literals/string-interpolation.t and S02-literals/quoting-unicode.t.  arnsholt++
17:23 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​0547805d440bdd4ec32e33e5c19297eea404c66
17:30 jan joined #parrot
17:47 Austin_Hastings joined #parrot
18:03 Whiteknight joined #parrot
18:03 dalek rakudo: 14a83eb | moritz++ | t/spectest.data:
18:03 dalek rakudo: more passing test files
18:03 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​4a83ebc61a29f2397794325e4786e7d8035b5ea
18:06 lucian joined #parrot
18:11 cotto davidfetter, cats aren't good at regexes
18:11 Whiteknight in the branch, parrot actually builds and is able to do quite a few steps after that before a segfault
18:12 Whiteknight why does "make corevm" try to build PGE/builtins_gen.pir?
18:12 Whiteknight I thought that was exactly the kind of thing the corevm target was not supposed to make
18:20 allison Whiteknight: corevm didn't used to, I was quite careful about stripping out any PGE features
18:20 allison but, we've had some makefile cleanups recently, so it might have snuck back in
18:22 iblechbot joined #parrot
18:28 allison Whiteknight: yeah, looks like GEN_LIBRARY has been added to the corevm target, which is everything including the kitchen sink
18:29 dukeleto we *reaaaaaaally* need a test that verifies that "make corevm" does what it is supposed to do
18:30 dalek parrot: r44706 | cotto++ | branches/ops_pct/compilers/ops​c/src/Ops/Compiler/Actions.pm:
18:30 dalek parrot: [opsc] fix op macro substitutions, break op_body action into two parts to allow munch_body access to the past
18:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44706/
18:30 allison dukeleto: difficult to test
18:32 dukeleto allison: sure, but a worthy goal. the test would have to create a copy of the source tree and then verify that it is doing the right thing. not something that should be part of "make test", but I would say it would be good to have that in "make fulltest"
18:33 allison duke: it could check a list of files that shouldn't exist after a "make realclean" and "make corevm"
18:33 dukeleto every time "make corevm" breaks, you can hear a screeching halt of productivity from some devs that rely on it, like plobsing
18:33 dukeleto allison: that is a nice idea
18:37 dukeleto allison: just created http://trac.parrot.org/parrot/ticket/1502 for testing "make corevm"
18:44 szabgabx joined #parrot
18:46 dalek parrot: r44707 | cotto++ | branches/ops_pct/compilers/ops​c/src/Ops/Compiler/Actions.pm:
18:46 dalek parrot: [opsc] set jump flag for ops with goto/restart OFFSET
18:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44707/
18:48 allison dukeleto: nice!
18:49 allison Whiteknight: we're already splitting out va_list over multiple function calls for param handling, so we won't be taking any portability hit if we use the same technique for building signature objects
18:50 dalek TT #1502 created by dukeleto++: Test that "make corevm" works as expected
18:51 chromatic joined #parrot
18:58 cotto hi chromatic
18:59 chromatic morning
18:59 mikehh hi chromatic
19:02 mikehh dukeleto: I think the same applies to make coretest - this has additional tests as per the ones used in the various cores in fulltest
19:03 dalek parrot: r44708 | cotto++ | trunk/lib/Parrot/Op.pm:
19:03 dalek parrot: [ops2c] remove a substitution that seems to have outlived its usefulness
19:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44708/
19:03 mikehh I queried this a couple of weeks ago mut nothing futher was said or done
19:03 mikehh s/mut/but/
19:04 cotto Wouldn't it be easier to parse the generated makefile?
19:12 cotto bacek_at_work, ping
19:23 cotto I thought nqp-rx had mmd now.
19:33 allison I need a nice general word that encompasses args/params/returns/results
19:34 allison we're conflating them now, and calling a function named "fill_params" to fetch return values is confusinc
19:34 allison and, I sure don't want to make separate functions that do the same thing just for the name
19:35 Whiteknight calling them all "args" and "params" is fitting when you think both directions are invokes
19:36 plobsing I want to say stack, but I know parrot doesn't work that way. What's the equivalent word for "the stack" in parrot?
19:36 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32530), fulltest) at r44708 - Ubuntu 9.10 amd64 (gcc with --optimize)
19:38 allison plobsing: depends on the context, either "registers" for values/variables or "continuation chain" for call frames
19:38 allison plobsing: stack-based implementations use the stack for multiple different things
19:39 plobsing next_cont then?
19:41 allison Whiteknight: yeah, arg/param is what I've done so far
19:41 allison Whiteknight: the userfacing ops have distinctive names, and the extend/embed API completely hides the details
19:42 allison Whiteknight: so, the idea that returns are just calls doesn't have to dawn on the average user, just on those who make their way into the core
19:43 allison plobsing: it really is, in many ways
19:43 lucian joined #parrot
19:43 allison plobsing: there are places in the code now that say "signature" when they just mean "the next continuation down the chain"
19:44 allison plobsing: ah well, some later refactor
19:48 Austin joined #parrot
19:48 nopaste "allison" at 77.98.130.30 pasted "series of steps for calling from C, for consideration" (5 lines) at http://nopaste.snit.ch/19865
19:49 allison the downside is it makes the FIAs part of the public interface, which makes it harder to eliminate them later
19:50 Whiteknight add another layer, and hide the FIAs from the public interface
19:51 allison I have this idea that using a pointer to a c integer array will be faster, when we can elimination the FIAs
19:51 allison eliminate
19:51 particle a ManagedStruct?
19:52 particle i assume introspection is important, and this int array should be visible from pir
19:52 chromatic Is this refactor going to get rid of the "let's freeze a string into bytecode describing args/params, then parse that into a new FIA for every invocation!" misfeature of the bytecode?
19:52 allison particle: could be, yeah.
19:52 allison particle: they're currently only used inside one function, so no persistence necessary
19:53 allison chromatic: aye, that's what the nopaste above does
19:53 allison chromatic: parses the string into FIAs once on the first entry point
19:53 chromatic That's not what I'm saying.
19:53 allison chromatic: then passes the FIAs into the signature building and return handling
19:53 allison chromatic: expand?
19:53 purl well, expand is at language.perl.com/ppt/src/expand/
19:54 chromatic Stop parsing the strings from every invocation from PIR -> PIR.
19:54 allison oh hush, purl. :)
19:54 purl meep!
19:54 allison chromatic: PIR->PIR calls directly use the FIAs passed in the call
19:55 chromatic What creates those FIAs?
19:55 allison chromatic: or at least they used to, may have been changed by someone
19:55 Whiteknight I like that last nopaste. Very simple
19:55 allison IMCC creates the FIAs
19:55 allison long before it gets anywhere near the PCC code
19:55 chromatic Okay.  That's what I wanted to hear.
19:56 Whiteknight what I particularly hate are the strings of hex flag codes
19:56 allison there are future optimizations there, in having IMCC create CallContext, instead of a FIA that we later store in a CallContext
19:57 chromatic As long as the get/set/_params/_returns ops don't store frozen strings, I'm happy for now.
19:57 allison Whiteknight: aye, there's a chunk of code in FIA dedicated to those icky strings
19:57 allison chromatic: aye, they don't (and it's a good thing)
19:58 chromatic When did that change?
19:58 allison the PIR->PIR code path is working in the branch, working on C->PIR and PIR->C
19:59 allison chromatic: AFAIK, it's been that way for years (creating FIAs in IMCC during compilation)
19:59 allison I suppose the last big PCC refactor in 2006 might have done it
20:00 chromatic Hm, I guess it is.
20:01 allison any calls before I jump into coding? Q: is it worse to make the FIAs part of the public interface, or to split the sig string, and then do the string parsing into FIAs buried deep in the PCC code?
20:02 allison splitting the sig string involves iterating over it once, before iterating over it again later to parse it
20:03 allison but, it's generally a short string
20:03 chromatic It's a smaller refactor to keep the string parsing part of the interface for now, isn't it?
20:03 allison yes
20:03 allison and, involves less reversal if we do rip out FIAs later
20:04 allison chromatic: (that is, if you're asking "It's a smaller refactor to keep passing around signature strings instead of passing around FIAs)
20:04 chromatic Right.
20:06 nopaste "allison" at 77.98.130.30 pasted "second alternate - series of steps for calling from C, for consideration, split sig string" (5 lines) at http://nopaste.snit.ch/19866
20:06 allison heh, it doesn't actually change the interface much
20:06 allison which is good
20:06 allison it just replaces a "parse signature string" call with a "split signature string call"
20:07 allison and arg_sig and ret_sig are char* instead of PMC*
20:07 payload joined #parrot
20:08 * allison diving in
20:18 bubaflub joined #parrot
20:23 kurahaupo_mobi Sorry for jumping in a bit late, have juat woken. It seems that if there were a vtable op for "gimme the raw memory address for byte offset x ensuring the next w bytes are contiguous" then it would be useful for both arrays and managed structs, and for ad hoc pack/unpack.
20:26 kurahaupo_mobi In particular, we could completely factor out resizable/limited/fixed from the element type of an array.
20:29 chromatic That sounds like a good way to expose raw pointers to PIR.
20:29 chromatic Whether exposing raw pointers to PIR is good, well....
20:38 kurahaupo_mobi The idea is they'd be used only internally by native methods and vtable functions.
20:41 kurahaupo_mobi So for example FixedIntegerArray becomes a composition of FixedByteBuffer and IntegerArrayAccessor
20:44 kurahaupo_mobi Look on trac wiki for Array for vmore
20:45 kurahaupo_mobi details. This keyboard is too small to type whole explanation.
20:48 lucian_ joined #parrot
20:50 theory joined #parrot
20:52 lucian joined #parrot
21:25 * Whiteknight helped his father-in-law remove some cabinets from the kitchen, which apparently were holding up the old chimney. Long story short, the chimney is now in the kitchen and I am covered with soot
21:25 Austin heh
21:25 Austin "/nick Blacknight" ?
21:25 Whiteknight Austin: don't know if you're familiar with the area across the river, but the house is an old levittowner
21:25 Austin Yeah
21:26 Whiteknight "/nick whiteknight-in-blackface"
21:29 Whiteknight All I wanted to do today was hackathon, but I removed some cabinets, now need to remove a chimney, and later need to repair some drywall
21:30 Austin I was wondering what prompted you to undertake two projects on the same weekend..
21:34 Whiteknight I agreed to come to the inlaws house for two reasons: 1) I was promised that there would be ample time to hack, and 2) I didn't want to get nagged about it if I said no
21:35 Whiteknight of course, now 1) There is very little time to hack, and 2) I'm getting nagged about destroying the kitchen
21:36 Whiteknight allison: if the sig string wasn't const, Parrot_pcc_split_signature_string could be a simple call to strtok
21:36 Austin Well, look on the bright side...
21:37 Whiteknight can't see the bright side, windows are covered in a thin film of soot
21:37 Austin There you go! You'll be able to stay in the rest of the weekend while they clean the windows..
21:37 Whiteknight yeah, "they
21:37 Whiteknight "
21:38 allison Whiteknight: I tried strtok first, but it's a bit hacky, modifying the original string and all
21:38 Whiteknight allison: Now that we are having proper bi-directional CPS, we might want more API interfaces that make better use of that
21:38 allison Whiteknight: the iteration is quick
21:39 allison Whiteknight: aye, I suspect they will grow around the new cleaner code
21:39 Whiteknight yeah
21:40 Whiteknight The whole string.h library is so buggy and hacky. strtok is a great example of that, but is hardly the worst offender
21:40 Whiteknight how many buffer overflow attacks were crafted around sscanf and sprintf?
21:44 chromatic Two, but they repeat ad infinitum.
21:45 patspam joined #parrot
21:50 chromatic plobsing, 'sudo echo 0 > /proc/sys/kernel/randomize_va_space' on Linux, at least.
21:50 chromatic Modern kernels randomize address space.
21:59 cotto Whiteknight, can you get pictures at least?
22:00 plobsing chromatic: nope, still fails intermittently
22:01 bacek joined #parrot
22:02 cotto hi bacek
22:03 chromatic Way too much indeterminancy there.
22:04 * plobsing is wondering about hash seeding and why gdb mentions threaded debugging
22:06 lucian joined #parrot
22:18 dalek parrot: r44709 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops/File.pm:
22:18 dalek parrot: [opsc] break up new, allow initialization from a string via new_str
22:18 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44709/
22:18 dalek parrot: r44710 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops (2 files):
22:18 dalek parrot: [opsc] implement in some macro translators
22:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44710/
22:26 Austin What exactly do I need to do to isolate a closure?
22:28 chromatic What do you mean by "isolate"?
22:28 Austin Enclose? Cut off from the outside world?
22:28 Austin In particular, to snapshot a set of lexical vars that are iterating.
22:30 bacek ~~
22:30 Austin I had thought, based on a conversation with pmichaud++, that if a sub block is lexically inferior to another block, and that outer block is re-entered, the closure was then isolated from any further changes. Clearly I'm wrong.
22:32 chromatic That depends on how you re-enter the enclosing block.
22:34 nopaste "Austin" at 68.39.12.202 pasted "This closure-taking business is harder than I thought..." (38 lines) at http://nopaste.snit.ch/19867
22:35 dalek parrot: r44711 | chromatic++ | trunk/src/io/unix.c:
22:35 dalek parrot: [IO] Worked around attempts to close unopened file descriptors in
22:35 dalek parrot: Parrot_io_open_unix() (Coverity CID #168).
22:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44711/
22:35 Austin See in particular the "else {  \n my &method := " near the bottom
22:41 chromatic That should clear up the last three Coverity errors.
22:42 chromatic I don't see the problem, Austin.
22:43 Austin Nor do I. But that last else block, where I thought I was enclosing &method, doesn't work - my %passthrough<_init_obj> winds up calling 'isa'
22:46 bacek cotto, ping
22:47 chromatic Are you sure that &method is a lexical in the generated PIR?
22:50 snarkyboojum joined #parrot
22:51 dalek parrot: r44712 | chromatic++ | trunk/src/io/buffer.c:
22:51 dalek parrot: [IO] Worked around a flaw in the way we use C's type system to tell static
22:51 dalek parrot: analysis tools that "Yes, this parameter cannot be negative here at all in any
22:51 dalek parrot: fashion, don't worry!"  This should finally fix Coverity CID #169.
22:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44712/
22:51 dalek parrot: r44713 | bacek++ | branches/ops_pct/compilers​/opsc/src/Ops/Trans/C.pm:
22:51 dalek parrot: Emit functions definitions in Trans::C
22:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44713/
22:51 dalek parrot: r44714 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/File.pm:
22:51 dalek parrot: Fix Ops::File.compile_ops invokation
22:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44714/
22:51 dalek parrot: r44715 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
22:51 dalek parrot: Fix fetching Op.body
22:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44715/
22:51 nopaste "Austin" at 68.39.12.202 pasted "pir generated for else {...} block" (20 lines) at http://nopaste.snit.ch/19868
22:52 cotto bacek++
22:53 bacek cotto, looks like I forgot to push last yesterday commit about emitting C code...
22:53 bacek But it's pushed now :)
22:53 cotto I was just going to ask for what you did in '13
22:53 bacek Just check 06-emitter.t. It will dump generated code.
22:54 cotto that was a strange omission
22:54 bacek it was almost 1am when I finished.
22:55 bacek Anyway, Op.body is properly fetched and ready for some munching :)
22:55 Austin AFAICT, chromatic, it's good code. The sub blocks have their :outer tags, the storing routine does a capture-lex of the sub immediately before sticking it in the antiphon, then it leaves, taking its lexpad with it...
22:56 cotto I'm on it.
22:56 bacek ok.
22:56 bacek I will not have much time today. But as soon as you finish we cat try to compile "ops2c.nqp" script and try to generate real code
22:56 chromatic I see nothing obvious, Austin.
22:57 Austin Thanks.
22:57 Austin I'm working around it by moving the stuff I wanted in that closure to other places. But I thought for sure I was getting the hang of this stuff... :(
23:01 dalek rakudo: 9a94503 | moritz++ | t/spectest.data:
23:01 dalek rakudo: turn on new test in S03-operators/names.t
23:01 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​a945039e6b6619e4e621d5ae48a2a1997b67654
23:01 Whiteknight allison: in the nopastes you pasted, did Parrot_pcc_split_signature_string operate on a char* or a STRING*?
23:02 allison char *
23:02 allison that's what comes in, so avoiding the overhead of creating GC-able strings
23:03 Whiteknight are you working on that code, or should I start hacking some of it together?
23:03 allison nearly done
23:03 Whiteknight ah, okay. I'll wait for you to commit before I start hacking
23:05 chromatic That sounds like dialog from "So I Married an Axe Murderer".
23:05 Whiteknight now that I FINALLY have some free time to do it
23:06 Whiteknight I would be taking a shower, but the drain pipe is open and I don't need my now-considerable filth spewing out onto the floor like so much IMCC code
23:06 bacek Axe murdering???
23:07 Austin Whiteknight: Sounds like you need to go out for ribs
23:07 Whiteknight bacek: is there any other kind?
23:07 Austin That way you can just ask for some extra wet-naps...
23:07 dalek blizkost: 25e081c | unknown++ | src/pmc/p5invocation.pmc:
23:07 dalek blizkost: Updates to bring us in line with latest Parrot calling conventions API.
23:08 dalek blizkost: review: http://github.com/jnthn/blizkost/commit/​25e081c7ba536ffa2dfed39ccc5eb7dc8bbee8af
23:08 allison Whiteknight: okay, committed the added functions, with one function translated to use the new code
23:08 Whiteknight Austin: sure, that's *definitely* one of my current needs
23:08 Whiteknight w00t
23:08 dalek parrot: r44716 | allison++ | branches/pcc_hackathon_6Mar10 (3 files):
23:08 dalek parrot: [pcc] Adding functions for handling calls from C, with the new order the
23:08 dalek parrot: results have to be fetched after invocation.
23:08 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44716/
23:09 allison we've deprecated Parrot_PCCINVOKE, right?
23:12 chromatic Yes.
23:12 chromatic Not that I can find it in DEPRECATED.pod.
23:13 allison it's just seeming silly to update two identical functions with different names
23:16 Whiteknight I remember it being deprecated, yes
23:16 Whiteknight I seem to remember it being "removed" at one point
23:17 bacek cotto, I have to go. Will try to finish opsc tonight for Trans::C.
23:17 bacek see you
23:19 dalek blizkost: 9e954eb | unknown++ | src/pmc/p5 (4 files):
23:19 dalek blizkost: Final catch-ups to get Blizkost linking again.
23:19 dalek blizkost: review: http://github.com/jnthn/blizkost/commit/​9e954eb1da01eb8ecbafcd8ba99ea4f3a51edcf3
23:24 plobsing am I using this right: './parrot -H F001 t/pir/macro.t' ?
23:27 cotto looks right to me
23:29 plobsing when I run that I get "Class 'Undef' not found"
23:29 plobsing I can't seem to set the hash seed at all
23:33 cotto in a branch?
23:34 theory joined #parrot
23:34 cotto nm.  it's in trunk
23:51 cotto plobsing, fixed
23:52 cotto plobsing++ for noticing that
23:54 cotto clock?
23:54 purl cotto: LAX: Sat 3:54pm PST / CHI: Sat 5:54pm CST / NYC: Sat 6:54pm EST / LON: Sat 11:54pm GMT / BER: Sun 12:54am CET / IND: Sun 5:24am IST / TOK: Sun 8:54am JST / SYD: Sun 10:54am EST /
23:58 dalek parrot: r44717 | allison++ | branches/pcc_hackathon_6Mar10/src/call/args.c:
23:58 dalek parrot: [pcc] Pick a more robust condition for the test of an empty return signature.
23:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44717/
23:58 dalek parrot: r44718 | cotto++ | trunk/src/main.c:
23:58 dalek parrot: [string] move --hash-seed to parseflags_minimal, before any strings are created
23:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44718/

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

Parrot | source cross referenced