#parrot Parrot 2.1.1 Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Tasks: PCC deprecations hackathon on Saturday, TT #389 branch
Set by moderator on 5 March 2010.
shockwave Have a good weekend guys (and gals). 00:00
Peace!
00:00 shockwave left
dalek rrot: r44666 | bacek++ | branches/ops_pct/compilers/opsc/t/04-op.t:
Remove outdated test
 00:06
rrot: r44667 | bacek++ | branches/ops_pct/compilers/opsc (6 files):
Add skeleton for emitter.
rrot: r44668 | bacek++ | branches/ops_pct/compilers/opsc/t/06-emitter.t:
Add test for Emitter.
rrot: r44669 | bacek++ | branches/ops_pct/compilers/opsc (3 files):
Start c header emitting
rrot: r44670 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
Emit preamble
00:07 tetragon joined 00:11 snarkyboojum joined 00:14 snarkyboojum joined 00:38 payload joined 00:58 parthm joined 01:22 Whiteknight joined
Whiteknight barely able to get online tonigh 01:26
(wireless routers)--
isn't there just a "-Wall" option we can use instead of specifying every single individual warning by name? 01:30
01:32 bacek joined 01:35 rblackwe left
Whiteknight holy crap the build is moving quick tonight 01:35
kid51 Whiteknight: Whenever I see that option, I think: "Compile this with everything Larry recommends" :-) 01:38
GeJ Good morning everyone.
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
GeJ kid51: seconded.
Whiteknight hello GeJ
01:39 rblackwe joined
GeJ Hello Andrew, James. 01:39
01:39 bubaflub joined
kid51 Coke probably knows a *lot* about those warnings, having waded thru that branch. 01:40
And, of course, AndyD will have an expert opinion.
bacek aloha
seen cotto
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]
bacek seen cotto_work
purl cotto_work was last seen on #parrot 4 hours, 1 minutes and 49 seconds ago, saying: moving tiem
GeJ G'Day bacek. 01:41
plobsing bacek: any words of advice on TT #1499? 01:42
bacek plobsing, shenanigans...
G'Day GeJ
plobsing, I wasn't able to trace it down...
Whiteknight every time I see fill_params, I cry a little on the inside 01:44
I know it's all necessary, and I know it's not bad code, but still. It's huge
Coke Whiteknight: -Wall isn't really all 01:45
it's just "a lot".
also, as chromatic has pointed out, -Wall doesn't mean the same warnings every release.
Whiteknight Coke: do we enable more warnings than that?'
Coke Whiteknight: yes.
Whiteknight ah, okay then
I rescind my critique 01:46
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:47
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 kudo: 974d9a8 | (Solomon Foster)++ | t/spectest.data:
Turn on S14-roles/basic.t.
rrot: r44671 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
Properly store Ops::Op.arg_types.
 01:52
rrot: r44672 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
Add test for Ops::Op.full_name
rrot: r44673 | bacek++ | branches/ops_pct/compilers/opsc/src/builtins.pir:
Add sprintf into builtins
rrot: r44674 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Actions.pm:
Once again emit Ops::Op in Compiler::Action
rrot: r44675 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
Add more stubs for Ops body rewriting
rrot: r44676 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
Drop parser_ops from Ops::File. Store just ops
rrot: r44677 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (2 files):
Add preparing ops to Tanscode
rrot: r44678 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Emitter.pm:
Prepare ops in trans. Emit trans-specific header part
rrot: r44679 | whiteknight++ | branches/pcc_hackathon_6Mar10/src/call/args.c:
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
rrot: r44680 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
Add loading version in Ops::File
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) 01:58
Whiteknight yeah 02:03
that was supposed to have been removed months ago, but the patch didnt catch all uses
so Rakudo was never "motivated" to use the alternative 02:04
02:04 atrodo joined
dalek rrot: r44681 | coke++ | trunk/lib/Parrot/Configure/Compiler.pm:
Remove apparently unused function.
 02:08
Whiteknight hasd to go. battery running out. Need to prepare for hackathon tomorrow. Later 02:10
Coke we should totally be using the gcc deprecated attribute. 02:11
02:31 Andy joined
Andy log 02:32
dukeleto 'ello 02:39
bubaflub hola dukeleto 02:40
dukeleto bubaflub: howdy!
bubaflub: have you been thinking of gsoc ideas?
bubaflub whatcha hackin' on?
dukeleto: i have, i shot ya an email with some ideas
do we need Math::Primality-esque stuff for Parrot or Rakudo?
dukeleto bubaflub: yes, i saw the email but didn't have time to respond 02:41
bubaflub yeah, i reckon'd as much
dukeleto bubaflub: yes, but lower-level stuff needs doin' first
bubaflub yeah, do we have usable bindings to GMP?
dukeleto bubaflub: have you looked at whiteknights blog posts about gsoc ideas?
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
dukeleto is hacking a scotch + club soda together
bubaflub dukeleto: GSOC or not i can hack a bit on some GMP stuff 02:43
chromatic Strings would be very, very useful. 02:44
bubaflub if i were to do the strings overhaul, is there something i should be hacking on now? 02:49
02:49 szabgabx_ joined
dukeleto bubaflub: start with whiteknights writeup and go from there. I am not the best person to ask about that stuff 02:51
bubaflub: is there a wiki page/TT for that stuff? 02:53
chromatic: do you have any direction for bubaflub ?
bubaflub dukeleto, all i'm seeing on wknight8111.blogspot.com/2010/01/gs...d-nfg.html is the PDD 02:54
dukeleto chromatic: i read PDD18 (security) last night. it seems all very high level. has nothing in there been implemented yet? 02:55
chromatic No to both questions. 02:56
With that said, pluggable runloops (as tewk has experimented) give us more options for security and such.
dukeleto chromatic: it seems that PL/Parrot will drive a lot of security features in Parrot 02:57
chromatic: the most important thing I need is to disable all file I/O
chromatic: do you have any suggestions for accomplishing that? 02:58
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
For every op dispatched in the runloop, check against a mask of allowed caps.
dukeleto chromatic: ok, that sounds like a direction i can go in 03:01
chromatic: where can i learn more about the op_info table? 03:02
i see that ops can be defined with group membership like: inline op print(in INT) :base_io,io { 03:04
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:05
dukeleto plobsing: i would rather disable opcodes than have PMCs require logic to disallow things 03:06
plobsing: but both are possible
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?
chromatic That's a good question and I don't have an answer for it now. 03:09
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
chromatic I'm not aware of any docs. 03:12
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?
chromatic: duly noted
chromatic dukeleto, I think it's ad hoc so far. 03:14
dukeleto i see :base_core, :deprecated, :object_classes, :base_math, :base_io, :filesys_open, :flow, :check_event and that is it 03:15
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
chromatic: is there a way to lookup what group an opcode is in?
chromatic I don't know a good way, off hand. 03:16
We may not do anything with that information.
Here's your chance to help define a good API.
dukeleto chromatic: ok, i am all about that. should I create a TT with an RFC for the API to do that?
jimk nods at #parrot and gives him a small kipper 03:17
chromatic Please do. 03:20
dukeleto chromatic: ok, i am on it.
this is needs to be done before any progress on implementing PDD18 can move forward 03:21
03:21 mj41_ joined
dukeleto is excited to see that PL/Parrot is drving new features in Parrot 03:22
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
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:36
chromatic: i see them in lib/Parrot/OpLib/core.pm, though 03:40
:q
03:41 janus joined
dukeleto seems that there is no other instances of opcode groups except when an op is defined and in lib/Parrot/OpLib/core.pm 03:42
woot. i got TT 1500 04:01
chromatic: TT made and parrot-dev poked 04:07
dalek TT #1500 created by dukeleto++: API to tell which opcode group an opcode is in 04:12
04:24 mj41_ joined 04:26 ttbot joined 07:53 davidfetter joined 07:55 fperrad joined 08:08 Austin_Hastings joined 08:43 iblechbot joined 08:52 lucian joined 09:25 bacek joined
cotto hi bacek 09:34
bacek cotto, aloha! 09:35
cotto I see you've been busy
bacek I wanna made opsc functional over weekend. 09:36
headers part are mostly done
cotto That's ambitious.
bacek++ 09:37
bacek cotto, will you have couple of spare hours to hack on? 09:43
09:44 cottoo joined
cottoo yup 09:44
bacek Ops::Op._substitute require some love :) 09:45
cottoo I'll give it a hug.
I was just looking at it.
bacek excellent 09:46
Just add bunch of "pure-virtual functions" to Ops::Trans, implement them in Ops::Trans::C and we are golden 09:47
I'm switching to c emitting.
Headers are done :) 09:48
cotto Nice.
I'll need to sleep eventually, but that'll give me something to hack on whenever I wake up.
bacek Ok 09:49
cotto Does anything test Ops::Trans::C yet? 09:50
nm 09:51
bacek 06-emitter
mikehh bacek: you want me to add svn properties and fix MANIFEST? 09:52
bacek but we do need separate test for Trans::C
mikehh, too early. But feel free to get cheap karma :)
mikehh :-}
bacek (Ignore svn properties. I'll merge with git and lost them anyway)
dalek rrot: r44682 | cotto++ | branches/ops_pct/compilers/opsc (3 files):
[opsc] add some more substitutions to munch_body, make Op.pm responsible for op-specific knowledge
 09:56
rrot: r44683 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
Store syn_export and init_func fields. Finish generating headers.
rrot: r44684 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
Comment out debug output.
rrot: r44685 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Trans/C.pm:
Use accessor instead of direct hash access to Emitter.syn_export
cotto time for sleep. Happy hacking bacek! 09:59
10:04 payload joined
mikehh in trunk I get a warning in the build I haven't seen before - anyone any idea what it means: 10:06
/usr/local/bin/perl tools/build/pmc2c.pl --c src/pmc/parrotthread.pmc
PMC has attributes but no auto_attrs or manual_attrs at /home/mhb/parrot/tools/build/../../lib/Parrot/Pmc2c/PMCEmitter.pm line 744.
/usr/local/bin/perl tools/build/c2str.pl src/pmc/parrotthread.c > src/pmc/parrotthread.str
even with that - 10:15
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 10:42 eternaleye joined
bacek mikehh, ask NotFound. He start moving to auto_attrs as default 10:44
mikehh bacek: yes - creating a ticket 11:04
dalek TT #1501 created by mikehh++: parrotthread.pmc - PMC has attributes but no auto_attrs or manual_attrs 11:25
11:43 snarkyboojum joined 11:51 clinton joined
dalek rrot: r44686 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
Add stub for emitting C source
 11:53
rrot: r44687 | bacek++ | branches/ops_pct/compilers/opsc (3 files):
Preserve ops preamble in Ops::File
rrot: r44688 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (3 files):
Add more stuff for emitting C source
rrot: r44689 | bacek++ | branches/ops_pct/compilers/opsc/t/06-emitter.t:
Add tests for emitting C source.
rrot: r44690 | bacek++ | branches/ops_pct/compilers/opsc (4 files):
Add Trans.source_preamble
rrot: r44691 | bacek++ | branches/ops_pct/compilers/opsc (4 files):
Add emiting init_func and dynload
rrot: r44692 | bacek++ | branches/ops_pct/compilers/opsc (4 files):
Add emiting op_lookup
rrot: r44693 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Trans.pm:
Add Trans.core_type
rrot: r44694 | bacek++ | branches/ops_pct/compilers/opsc (5 files):
Add emiting op lib description
11:56 snarkyboojum_ joined 12:06 cognominal joined 12:07 payload joined 12:09 payload joined 12:23 TzAnAnY joined
TzAnAnY hello all i have a question 12:23
there is TimeOut (Alarm) Command For win32?
12:30 Whiteknight joined
Whiteknight good morning everybody! 12:35
Everybody ready for T3H M4J0R H4XX0RING? 12:41
dalek rrot: r44695 | mikehh++ | branches/ops_pct/MANIFEST:
regenerate MANIFEST
 12:43
mikehh hi whiteknight and yes just waitin to test 12:45
Whiteknight awesome
mikehh fiddlin' with ops_pct branch at the moment
12:46 iblechbot joined
Whiteknight yeah, I've seen a lot of activity over there recently 12:49
12:50 joeri joined
Whiteknight allison: ping 12:50
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
purl Message for allison stored.
dalek rrot: r44696 | mikehh++ | branches/ops_pct/compilers/nqp/src/quote_expression.pir:
fix copyright statement
 12:59
rrot: r44697 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (3 files):
Pass emitter into emit_source_part
rrot: r44698 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
Workadound scalar/list in Op.size
rrot: r44699 | bacek++ | branches/ops_pct/ext/nqp-rx/src/gen/settings.pm:
Update NQP settings.
rrot: r44700 | bacek++ | branches/ops_pct/compilers/opsc (2 files):
Implement emitting op_info_table and op_func_table
rrot: r44701 | bacek++ | branches/ops_pct/compilers/opsc/TODO:
Add TODO for cotto++
13:04 kid51 joined 13:06 mikehh_ joined
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.
allison Whiteknight: it doesn't return the context, the context is accessed the same as it is in opcode calls 13:13
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:14
dalek rrot: r44702 | bacek++ | branches/ops_pct/compilers/opsc/TODO:
Update todo.
 13:16
13:16 mikehh joined
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:16
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:32
and if we are explicitly recycling the parameters CallContext, that does make a lot of things easier 13:33
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:34
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:36
Whiteknight exactly 13:37
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
or, just have a second function that parses the signature from the beginning and returns storage
it bugs the hell out of me that some of these functions that an FIA to parse the flags 13:40
dalek tracwiki: v22 | allison++ | CallingConventionsTasklist 13:41
tracwiki: trac.parrot.org/parrot/wiki/Calling...ction=diff
tracwiki: v23 | allison++ | CallingConventionsTasklist
tracwiki: trac.parrot.org/parrot/wiki/Calling...ction=diff
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:43
that is, store the return signature FIA in the CallContext 13:44
Whiteknight we dont always have an FIA
allison the first thing Parrot_pcc_build_sig_object_from_varargs does is build one 13:45
It used to build two: one for args and one for returns
Whiteknight: op calls will never have a return sig from the start, though 13:47
Whiteknight: so it's better to store that information locally, than to cache it in the CallContext
Whiteknight right 13:48
this refactor is going to be larger than I anticipated 13:55
allison it's mainly a matter of deleting code
Whiteknight all the _from_c_args and *_varags func need to be rewritten 13:56
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
better to have an explicit separate step setting "wants" 13:58
Whiteknight that's fine too
allison well, half the *_from_c_args *_varargs functions just go away 13:59
Whiteknight: what platforms barf on using one va_list within another 14:05
14:05 atrodo joined
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
Whiteknight if we copy the returns hal of va_list into an array, we can process it separately 14:07
dalek rrot: r44703 | allison++ | branches/pcc_hackathon_6Mar10/src/call/args.c:
[pcc] Fix compilation and runtime errors.
rrot: r44704 | allison++ | branches/pcc_hackathon_6Mar10 (2 files):
[pcc] Remove deprecated and unused function for old-style return
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
at least it's only a local array of pointers
doesn't even have to be a PMC 14:09
Whiteknight exactly
14:11 Psyche^ joined
dalek rrot: r44705 | jonathan++ | trunk/src/runcore/main.c:
[loadlib] Though shalt always use the return value of realloc calls, otherwise segfaults happen.
 14:24
Whiteknight amen! 14:25
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:32
allison it should keep parsing the full string 14:40
but, I'm speculating on whether the various functions that currenly accept only a signature string should accept a FIA instead 14:41
that is, parse the signature string once when we first hit it
rather than reparsing it over and over again
either that, or we need a "split_signature_string" 14:42
dalek kudo: 8505d39 | Worthington@.(none)++ | src/builtins/Mu.pir:
Fix has %.noms.
 14:43
allison and then parse_signature_string switches over to expecting only args/returns, not both combined
in fact, that's probably the better solution
all calls to parse_signature_string now ignore the second half 14:44
14:45 TzAnAnY left 15:00 PacoLinux joined
dalek kudo: 43f5a52 | (Solomon Foster)++ | build/PARROT_REVISION:
Bump parrot.
 15:00
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:07
allison Whiteknight: well, see it needs a different half at different times 15:08
but, it only ever needs one half
Whiteknight and the two halves can basically be parsed to FIA without knowing which it is 15:09
allison for example: Parrot_pcc_fill_params_from_c_args will be called both for filling parameters, and for filling results 15:10
it calls parse_signature_string
so, half the time it'll be parsing an arg signature, and half the time a return signature
Whiteknight exactly
allison it doesn't have to know which is which
so, if we split the signature string when it first enters the system 15:11
in Parrot_pcc_invoke_method_from_c_args, for example
then we never have to handle the bundled singnature again 15:12
Whiteknight: hmmm... what bacek actually said is that va_list can't be "restarted" 15:27
Whiteknight: but we aren't restarting it, just handling it in two separate function calls
dalek kudo: ab3f44b | (Solomon Foster)++ | src/ (2 files):
Quick implementation of !===. (Should be a meta op, but this will work for now.)
 15:34
kudo: 7882db4 | (Solomon Foster)++ | t/spectest.data:
Turn on S03-operators/value_equivalence.t.
15:35 Psyche^ joined 15:39 tetragon joined
allison Whiteknight: ah, interesting, I've always used va_list as if it were a consuming iterator 15:40
nopaste "allison" at 77.98.130.30 pasted "method 1 of passing va_list" (28 lines) at nopaste.snit.ch/19862 15:42
"allison" at 77.98.130.30 pasted "method 2 of passing va_list, as a pointer" (23 lines) at nopaste.snit.ch/19863 15:45
15:46 payload left
dalek kudo: 28f5203 | (Solomon Foster)++ | t/spectest.data:
Turn on S06-traits/is-rw.t. arnsholt++.
 15:52
16:01 kurahaupo joined 16:14 payload joined 16:17 payload1 joined 16:24 snarkyboojum_ joined
dalek kudo: ba6cd4e | (Solomon Foster)++ | src/builtins/ (2 files):
Change === on Num to return Bool, and clean up === on Int. baest++
 16:26
purl dalek: that doesn't look right
16:44 AndyA joined
dukeleto 'ello 16:50
16:50 theory joined
allison hi 17:03
purl hi, allison.
cotto bacek++ for being awesome 17:05
davidfetter oh hai 17:12
cotto Happy Cat- and/or Saturday! 17:17
davidfetter
.oO([CS]aturday)
 17:22
dalek kudo: c054780 | (Solomon Foster)++ | t/spectest.data:
Turn on S02-literals/string-interpolation.t and S02-literals/quoting-unicode.t. arnsholt++
 17:23
17:30 jan joined 17:47 Austin_Hastings joined 18:03 Whiteknight joined
dalek kudo: 14a83eb | moritz++ | t/spectest.data:
more passing test files
 18:03
18:06 lucian joined
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
why does "make corevm" try to build PGE/builtins_gen.pir? 18:12
I thought that was exactly the kind of thing the corevm target was not supposed to make
allison Whiteknight: corevm didn't used to, I was quite careful about stripping out any PGE features 18:20
but, we've had some makefile cleanups recently, so it might have snuck back in
18:22 iblechbot joined
allison Whiteknight: yeah, looks like GEN_LIBRARY has been added to the corevm target, which is everything including the kitchen sink 18:28
dukeleto we *reaaaaaaally* need a test that verifies that "make corevm" does what it is supposed to do 18:29
dalek rrot: r44706 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Actions.pm:
[opsc] fix op macro substitutions, break op_body action into two parts to allow munch_body access to the past
 18:30
allison dukeleto: difficult to test
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:32
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
allison: that is a nice idea
allison: just created trac.parrot.org/parrot/ticket/1502 for testing "make corevm" 18:37
18:44 szabgabx joined
dalek rrot: r44707 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Actions.pm:
[opsc] set jump flag for ops with goto/restart OFFSET
 18:46
allison dukeleto: nice! 18:48
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:49
dalek TT #1502 created by dukeleto++: Test that "make corevm" works as expected 18:50
18:51 chromatic joined
cotto hi chromatic 18:58
chromatic morning 18:59
mikehh hi chromatic
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:02
dalek rrot: r44708 | cotto++ | trunk/lib/Parrot/Op.pm:
[ops2c] remove a substitution that seems to have outlived its usefulness
 19:03
mikehh I queried this a couple of weeks ago mut nothing futher was said or done
s/mut/but/
cotto Wouldn't it be easier to parse the generated makefile? 19:04
bacek_at_work, ping 19:12
I thought nqp-rx had mmd now. 19:23
allison I need a nice general word that encompasses args/params/returns/results 19:33
we're conflating them now, and calling a function named "fill_params" to fetch return values is confusinc 19:34
and, I sure don't want to make separate functions that do the same thing just for the name
Whiteknight calling them all "args" and "params" is fitting when you think both directions are invokes 19:35
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)
allison plobsing: depends on the context, either "registers" for values/variables or "continuation chain" for call frames 19:38
plobsing: stack-based implementations use the stack for multiple different things
plobsing next_cont then? 19:39
allison Whiteknight: yeah, arg/param is what I've done so far 19:41
Whiteknight: the userfacing ops have distinctive names, and the extend/embed API completely hides the details
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:42
plobsing: it really is, in many ways 19:43
19:43 lucian joined
allison plobsing: there are places in the code now that say "signature" when they just mean "the next continuation down the chain" 19:43
plobsing: ah well, some later refactor 19:44
19:48 Austin joined
nopaste "allison" at 77.98.130.30 pasted "series of steps for calling from C, for consideration" (5 lines) at nopaste.snit.ch/19865 19:48
allison the downside is it makes the FIAs part of the public interface, which makes it harder to eliminate them later 19:49
Whiteknight add another layer, and hide the FIAs from the public interface 19:50
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
eliminate
particle a ManagedStruct?
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?
allison particle: could be, yeah.
particle: they're currently only used inside one function, so no persistence necessary
chromatic: aye, that's what the nopaste above does 19:53
chromatic: parses the string into FIAs once on the first entry point
chromatic That's not what I'm saying.
allison chromatic: then passes the FIAs into the signature building and return handling
chromatic: expand?
purl well, expand is at language.perl.com/ppt/src/expand/
chromatic Stop parsing the strings from every invocation from PIR -> PIR. 19:54
allison oh hush, purl. :)
purl meep!
allison chromatic: PIR->PIR calls directly use the FIAs passed in the call
chromatic What creates those FIAs? 19:55
allison chromatic: or at least they used to, may have been changed by someone
Whiteknight I like that last nopaste. Very simple
allison IMCC creates the FIAs
long before it gets anywhere near the PCC code
chromatic Okay. That's what I wanted to hear.
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
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
chromatic: aye, they don't (and it's a good thing)
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
chromatic: AFAIK, it's been that way for years (creating FIAs in IMCC during compilation) 19:59
I suppose the last big PCC refactor in 2006 might have done it
chromatic Hm, I guess it is. 20:00
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:01
splitting the sig string involves iterating over it once, before iterating over it again later to parse it 20:02
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?
allison yes
and, involves less reversal if we do rip out FIAs later
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.
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 nopaste.snit.ch/19866 20:06
allison heh, it doesn't actually change the interface much
which is good
it just replaces a "parse signature string" call with a "split signature string call"
and arg_sig and ret_sig are char* instead of PMC* 20:07
20:07 payload joined
allison diving in 20:08
20:18 bubaflub joined
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:23
In particular, we could completely factor out resizable/limited/fixed from the element type of an array. 20:26
chromatic That sounds like a good way to expose raw pointers to PIR. 20:29
Whether exposing raw pointers to PIR is good, well....
kurahaupo_mobi The idea is they'd be used only internally by native methods and vtable functions. 20:38
So for example FixedIntegerArray becomes a composition of FixedByteBuffer and IntegerArrayAccessor 20:41
Look on trac wiki for Array for vmore 20:44
details. This keyboard is too small to type whole explanation. 20:45
20:48 lucian_ joined 20:50 theory joined 20:52 lucian joined
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
"/nick Blacknight" ?
Whiteknight Austin: don't know if you're familiar with the area across the river, but the house is an old levittowner
Austin Yeah
Whiteknight "/nick whiteknight-in-blackface" 21:26
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:29
Austin I was wondering what prompted you to undertake two projects on the same weekend.. 21:30
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:34
of course, now 1) There is very little time to hack, and 2) I'm getting nagged about destroying the kitchen 21:35
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...
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..
Whiteknight yeah, "they
"
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
allison Whiteknight: the iteration is quick
Whiteknight: aye, I suspect they will grow around the new cleaner code 21:39
Whiteknight yeah
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
how many buffer overflow attacks were crafted around sscanf and sprintf?
chromatic Two, but they repeat ad infinitum. 21:44
21:45 patspam joined
chromatic plobsing, 'sudo echo 0 > /proc/sys/kernel/randomize_va_space' on Linux, at least. 21:50
Modern kernels randomize address space.
cotto Whiteknight, can you get pictures at least? 21:59
plobsing chromatic: nope, still fails intermittently 22:00
22:01 bacek joined
cotto hi bacek 22:02
chromatic Way too much indeterminancy there. 22:03
plobsing is wondering about hash seeding and why gdb mentions threaded debugging 22:04
22:06 lucian joined
dalek rrot: r44709 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops/File.pm:
[opsc] break up new, allow initialization from a string via new_str
 22:18
rrot: r44710 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops (2 files):
[opsc] implement in some macro translators
Austin What exactly do I need to do to isolate a closure? 22:26
chromatic What do you mean by "isolate"? 22:28
Austin Enclose? Cut off from the outside world?
In particular, to snapshot a set of lexical vars that are iterating.
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.
chromatic That depends on how you re-enter the enclosing block. 22:32
nopaste "Austin" at 68.39.12.202 pasted "This closure-taking business is harder than I thought..." (38 lines) at nopaste.snit.ch/19867 22:34
dalek rrot: r44711 | chromatic++ | trunk/src/io/unix.c:
[IO] Worked around attempts to close unopened file descriptors in
 22:35
Austin See in particular the "else { \\n my &method := " near the bottom
chromatic That should clear up the last three Coverity errors. 22:41
I don't see the problem, Austin. 22:42
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:43
bacek cotto, ping 22:46
chromatic Are you sure that &method is a lexical in the generated PIR? 22:47
22:50 snarkyboojum joined
dalek rrot: r44712 | chromatic++ | trunk/src/io/buffer.c:
[IO] Worked around a flaw in the way we use C's type system to tell static

fashion, don't worry!" This should finally fix Coverity CID #169.		 22:51
rrot: r44713 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Trans/C.pm:
Emit functions definitions in Trans::C
rrot: r44714 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/File.pm:
Fix Ops::File.compile_ops invokation
rrot: r44715 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
Fix fetching Op.body
nopaste "Austin" at 68.39.12.202 pasted "pir generated for else {...} block" (20 lines) at nopaste.snit.ch/19868
cotto bacek++ 22:52
bacek cotto, looks like I forgot to push last yesterday commit about emitting C code... 22:53
But it's pushed now :)
cotto I was just going to ask for what you did in '13
bacek Just check 06-emitter.t. It will dump generated code.
cotto that was a strange omission 22:54
bacek it was almost 1am when I finished.
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...
cotto I'm on it. 22:56
bacek ok.
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
chromatic I see nothing obvious, Austin.
Austin Thanks. 22:57
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... :(
dalek kudo: 9a94503 | moritz++ | t/spectest.data:
turn on new test in S03-operators/names.t
 23:01
Whiteknight allison: in the nopastes you pasted, did Parrot_pcc_split_signature_string operate on a char* or a STRING*?
allison char * 23:02
that's what comes in, so avoiding the overhead of creating GC-able strings
Whiteknight are you working on that code, or should I start hacking some of it together? 23:03
allison nearly done
Whiteknight ah, okay. I'll wait for you to commit before I start hacking
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
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???
Austin Whiteknight: Sounds like you need to go out for ribs 23:07
Whiteknight bacek: is there any other kind?
Austin That way you can just ask for some extra wet-naps...
dalek izkost: 25e081c | unknown++ | src/pmc/p5invocation.pmc:
Updates to bring us in line with latest Parrot calling conventions API.
allison Whiteknight: okay, committed the added functions, with one function translated to use the new code
Whiteknight Austin: sure, that's *definitely* one of my current needs
w00t
dalek rrot: r44716 | allison++ | branches/pcc_hackathon_6Mar10 (3 files):
[pcc] Adding functions for handling calls from C, with the new order the
allison we've deprecated Parrot_PCCINVOKE, right? 23:09
chromatic Yes. 23:12
Not that I can find it in DEPRECATED.pod.
allison it's just seeming silly to update two identical functions with different names 23:13
Whiteknight I remember it being deprecated, yes 23:16
I seem to remember it being "removed" at one point
bacek cotto, I have to go. Will try to finish opsc tonight for Trans::C. 23:17
see you
dalek izkost: 9e954eb | unknown++ | src/pmc/p5 (4 files):
Final catch-ups to get Blizkost linking again.
 23:19
plobsing am I using this right: './parrot -H F001 t/pir/macro.t' ? 23:24
cotto looks right to me 23:27
plobsing when I run that I get "Class 'Undef' not found" 23:29
I can't seem to set the hash seed at all
cotto in a branch? 23:33
23:34 theory joined
cotto nm. it's in trunk 23:34
plobsing, fixed 23:51
plobsing++ for noticing that 23:52
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 /
dalek rrot: r44717 | allison++ | branches/pcc_hackathon_6Mar10/src/call/args.c:
[pcc] Pick a more robust condition for the test of an empty return signature.
 23:58
rrot: r44718 | cotto++ | trunk/src/main.c:
[string] move --hash-seed to parseflags_minimal, before any strings are created

Powered by Cro and the Raku® Programming Language.

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

Thank you!