Parrot 1.7.0 "African Grey" is out! Feel free to nuke trunk | Improve PCC testing this week or the release gets it!
Set by moderator on 21 October 2009.
japhb Austin, well, in the older Playstations, at least. 00:00
But yes, I think we've got good enough evidence to presume at least .c.o style rules work, until proven otherwise. 00:01
00:06 darbelo joined
mikehh trunk - pre/post-config, smoke (#29318) PASS, fulltest FAIL at r42027 - Ubuntu 9.10 (beta updated) amd64 00:11
t/op/annotate-old.t - Failed test: 1 - in testf and testg (TT #1135)
t/pmc/threads.t - Failed tests: 8-9 - in testr
the rest of fulltest passes
Whiteknight Tene: I welcome all comments on my blog. I doubt you'll convince me to give vim yet another try 00:14
00:16 hercynium joined
mikehh chromatic: still failing to build with g++ - I am pretty sure the problem is with strchr as Notfound mentioned - I found a couple of Bug reports relating to it on Launchpad (not exactly the same but...) 00:18
chromatic Hm, that doesn't make sense to me. It takes a const char * and returns a char *. Can you nopaste the error? 00:19
00:20 dukeleto left 00:21 dukeleto joined
mikehh chromatic: the various bug reports indicate it might be a problem with the libraries - it is definately a g++ 4.4.1 (or the libraries) problem as it does not effect g++ 4.3 00:21
moderator Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply merge 00:21
dalek rrot-plumage: 61aa506 | japhb++ | :
[CORE] Move metadata functions out to lib/Metadata.nqp; update .gitignor...
 00:22
rrot-plumage: 381889e | japhb++ | :
[CORE] Metadata.nqp: Add POD and SYNOPSIS for functions
00:24 zerhash joined
Coke I remember using vi on an actual mainframe. 00:26
<-- old fart.
dukeleto Austin: i will try to get on the merge request you sent me
Coke: !
Austin dukeleto: I think japhb already got it. 00:27
japhb yup
dukeleto japhb++ Austin++ 00:28
nopaste "mikehh" at 81.149.189.7 pasted "possible cause of g++ 4.4.1 build problems" (31 lines) at nopaste.snit.ch/18423
japhb Earliest processor I coded for was the Zilog Z80, on a 64K CP/M system. 00:29
I think that nowadays qualifies me as "oldish"
darbelo Or a retrocomputer. 00:30
kid51 plobsing ping
cotto_work some TI calculators use a Z80 00:31
Coke japhb: I had a commodore 128 that could be booted into CP/M - I almost never used that mode, though.
dukeleto japhb: i prefer the term 'old skool'
Whiteknight ...and Parrot has :call_sig
(well, a partial implementation of it
darbelo Whiteknight++
japhb Well, it was current at the time. We even had the very latest high-capacity drive controllers -- that allowed us to get a whopping 1 MB onto 8" floppies.
darbelo Holy shit! A whole MEGA-byte? But what could you want all that storage space for? 00:32
cotto_work Whiteknight, but no tests?
plobsing kid51: pong
dalek rrot: r42028 | whiteknight++ | trunk (10 files):
[pcc] Add EXPERIMENTAL support for :call_sig on the callee param side only. This is not the final form of the implementation, but enough proof-of-concept to get some HLL developers using it. Tests forthcoming
 00:33
cotto_work still, Whiteknight++
kid51 plobsing: I tried out your codingstd_outdent.patch
cotto_work and dalek agrees
kid51 It doesn't clear up the c_indent.t failures in the branch.
It reports a couple of failures in trunk -- but far fewer than it does in branch. 00:34
japhb darbelo, corporate accounting and tax records. Documents couldn't even get close to using up a whole floppy. :-)
plobsing oops, retesting now
mikehh anyway that's enough for me at the moment - must sleep - bbl
kid51 Since it's not directly tied to libjit, I'd like to recommend that you submit it in a separate TT
I don't know the ins and outs of the c_indent coding standard myself 00:35
So I don't know whether your version represents the standard better than the current one or not.
In any case, I think it's best handled in a separate ticket.
plobsing i thought so. 00:36
wasn't sure though
wrt the c_indent failures, I cleaned the ones not covered by the patch with the config_fixup.patch 00:37
kid51 I'll have to take a closer look at that one
but I'm going to be afk for several days
plobsing ok, thanks. 00:38
what are the steps that still need to be taken on this branch? As I see it it's codingstd, merge with pcc changes, make everything pass, apply to trunk 00:40
anythinig else?
kid51 With the config_fixup.patch, how is it that you are able to remove those OS-specific files such as config/auto/frames/test_exec_linux_c.in ?
ttbot Parrot trunk/ r42028 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/119234.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
plobsing because they check for W^X
which is handled by libjit
chromatic I used CP/M briefly.
kid51 and the additions to lib/Parrot/Distribution.pm were for ... ? 00:41
plobsing skip generated files.
because otherwise macros in the templates conflict with macros in the generated files
the assumption being that if the template files conform, the generated files conform. 00:42
chromatic mikehh, what if you prepend 'const ' to line 2790? 00:43
You may have to remove line 2803, but that's doable too.
kid51 testing config_fixup.patch in branch 00:44
pre-config tests, Configure and post-config tests good 00:45
cotto_work coverage? 00:48
purl coverage is, like, cv.perl6.cz
dalek rrot: r42029 | whiteknight++ | trunk/src/call/args.c:
[pcc] remove debugging message from previous commit
 00:49
cotto_work of interest to anyone wanting to increase CallSignature coverage: tapir2.ro.vutbr.cz/cover/cover-resu...e-pmc.html 00:50
00:51 kurahaupo joined
dalek TT #1137 created by plobsing++: [PATCH] fix codingstd/c_indent.t wrt switch/case labels 00:51
chromatic That's fairly well tested already. 00:52
cotto_work yes. There are only a couple holes. 00:53
ttbot Parrot trunk/ r42029 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/119268.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 00:56
00:56 abqar joined
japhb Austin, can you try the newest Plumage Makefile.in on your systems? (So of course need to 'parrot_nqp Configure.nqp' again) 01:02
dalek rrot: r42030 | jkeenan++ | branches/auto_libjit (10 files):
Applying config_fixup patch submitted by plobsing++ in trac.parrot.org/parrot/ticket/1105.
Austin I'll give it a shot.
japhb dalek_lag ... 01:03
dalek rrot: r42031 | whiteknight++ | trunk (5 files):
[pcc] Add some tests for :call_sig that show how the proof-of-concept works. Also, wrote these tests in PIR so moved the old tests in Perl5 to cc_params_old.t
 01:06
Austin japhb: It works for me.
darbelo japhb: workforme
japhb excellent
dalek rrot-plumage: 4e30f63 | japhb++ | :
[BUILD] Makefile.in: Use (very) slightly more advanced make features; ad...
cotto_work Yay! My test pestering is having an effect. Whiteknight++
Austin You know that .PHONY is a gnuism, yes? 01:07
japhb I have a feeling I'm working my way through the history of make from pretty much the Paleozoic era
Austin, yes, but IIRC '.RANDOMWORDHERE' is ignored if not understood, right? 01:08
Because it appears to be just a rule that never gets used
Austin Yes. But systems that don't do .PHONY won't get what you're doing. You're better off doing "help : FORCE" and then doing ".PHONY : FORCE" 01:09
japhb Oh, OK, I can do that, no problem
Austin (On the vanishingly small chance that someone creates a file called "help" in the plumage directory.) 01:10
darbelo Or, even better. not having anything named 'help' 'test' or 'clean' on the top-level.
japhb darbelo, sure, but in addition Gnu will avoid doing its usual searches on any PHONY targets 01:11
Very minor performance improvement that comes with a minor correctness improvement as well.
ttbot Parrot trunk/ r42031 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/119311.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
darbelo Yeah. I'm just making sure we don't *rely* on that working.
01:13 eternaleye joined
japhb darbelo, oh sure, gotcha 01:14
kid51 plobsing: Referring to your question from a half-hour ago: "what are the steps that still need to be taken on this branch? As I see it it's codingstd, merge with pcc changes, make everything pass, apply to trunk" ...
japhb Austin, darbelo: incoming fixed version, I hope 01:15
kid51 I see what's happening in this branch, in the detect_llvm branch and in perhaps others yet to be created a clearing-away of the underbrush in preparation for the restoration of JIT to parrot.
I believe it was whiteknight and bacek who did the work of ripping our old, malfunctioning JIT out. 01:16
I see what we're doing as laying the ground work for restoration of JIT.
Whiteknight darbelo ripped it out
cotto_work darbelo++
darbelo?
purl hmmm... darbelo is Daniel Arbelo Arrocha <mailto:arbelo@gmail.com>
kid51 So it may not be a simple case of merging this branch into trunk. It may be more like, "Merge the best features of several branches back into trunk."
When darbelo, whiteknight et al get the tuits for that 01:17
cotto_work darbelo is also Daniel "The Wrecking Ball" Arbelo Arrocha
purl okay, cotto_work.
darbelo likes to remove code.
dalek rrot-plumage: e088429 | japhb++ | :
[BUILD] Makefile.in: Go further back in prehistory of make syntax
plobsing fair enough. still, I would like to get this working with pcc and merged ASAP. the longer it sits outside trunk, the more painfull will be the merge 01:18
cotto_work good attitude
kid51 True enough.
If you can participate in #parrotsketch on Tuesday, you may want to raise the questions "When is JIT restoration going to happen? When can auto_libjit branch be merged?" 01:19
I myself am not knowledgeable enough about JIT to answer those questions. 01:20
plobsing I wish I could. Unfortunately, I have a weekly dev team meeting at roughly the same time on tuesdays.
kid51 As do I.
but please post on #parrotsketch earlier in that same UCT day.
the participants read the comments on backscroll before the meeting 01:21
cotto_work plobsing, feel free to prepost your question in #parrotsketch on Tuesday before the meeting.
plobsing ok. thanks.
cotto_work (though Whiteknight may be able to answer it now)
Whiteknight ?
kid51 And, in any event, whiteknight, bacek, darbelo -- all of you JIT-knowledgeable people, please review TT 1105 and TT 1075
Whiteknight isn't paying attention, tries backlogging
cotto_work or not
darbelo plobsing: JIT restoration will happen as soon as we can manage it. 01:22
cotto_work iiuc jit will be part of Lorito, which puts it out a ways
darbelo plobsing: The libjit branch will merge as soon as it's updated to work with current trunk. 01:23
Which will hopefully be sooner.
cotto_work but I don't think that excludes plobsing's branch from being merged
darbelo cotto_work: Exactly, if his branch can be made to work with post-pcc-merge trunk it get's merged as soon as I get the chance to. 01:24
plobsing sweet
cotto_work we don't want to cause any less pain than necessary
s/less/more/ ;)
Whiteknight Lorito will be the JIT implementatin
the two are one and the same
darbelo But the pcc changes are pretty much guaranteed to screw up any frame builder built before it landed. 01:25
plobsing looking at it, less so than you'd think.
darbelo I saw what it did to the current frame builder, and it wasn't pretty. 01:26
But then the frame builder wasn't pretty either ;)
Austin japhb: There's no Makefile: rule in the Makefile.
plobsing I'm just looking at what it did to nci.c. The change looks pretty trivial.
note that the frame builder doesn't actually touch pcc strings.
Whiteknight the old frame builder wasn't pretty
plobsing thats the task of nci.pmc
darbelo slaps his forehead. 01:27
chromatic The old frame builder is salvageable for anyone who wants to compile one of the working NCI thunks, examine the assembly output, then write C functions to construct that assembly output.
darbelo The ugly shit our frame builder was pulling is now getting done inside libjit.
cotto_work chromatic, you make it sound so easy 01:28
darbelo chromatic: I don't think anyone wants to.
Anyway, I have to go now. 01:29
See y'all later.
chromatic It's not that complex.
nopaste "kid51" at 71.247.47.180 pasted "auto_libjit branch diff from trunk at its branch point" (4442 lines) at nopaste.snit.ch/18424
01:30 darbelo left
chromatic There are details and it's a pain to debug, but mostly you only have to be able to read assembly code and juggle which registers you use and where. 01:30
If the libjit branch is close, it's not worth salvaging the trunk code though.
kid51 must sleep 01:31
purl $kid51->sleep(8 * 3600);
plobsing I'd say its pretty close, but I doubt I'm being objective
Whiteknight has to sleep now. Look at it tomorrow 01:32
japhb Austin, what should be in the Makefile: rule? 01:41
Austin Whatever generates the Makefile. I think 7 parrot_nqp Configure.nqp 01:42
japhb And I take it (at least some) makes will notice the magic rule and rebuild themselveS?
er, reread the rebuilt makefile before continuing?
Austin Yes. 01:44
japhb Oooh, that's useful.
Austin You edit makefile.in, and it rebuilds makefile.
It's pretty sweet.
japhb OK, have to do $family stuff for a bit, but then I will absolutely put that in, thanks for the idea.
Oh, do I need to make anything depend on Makefile ? or is that implicit? 01:45
Austin No, it needs to specify src/Makefile.in as its dependency. 01:46
But nothing has to require Makefile. I recommend that you make things which are frequently having code added/removed depend on it, just to force the rebuild. (That is, if you add "foo.nqp" to the Makefile, you probably want to force a rebuild of plumage.) 01:47
japhb OK, and I noticed a "How Makefiles Are Remade" section of the Gnu Make manual, so I'll read that too
k
AFK for now, but will backlog if you have more advice in the mean time .... 01:48
dalek p-rx: f8fb418 | pmichaud++ | src/NQP/ (2 files):
Handle immediate blocks (in 'if' statements, at least).
 01:51
p-rx: 16b3e50 | pmichaud++ | src/ (3 files):
Fix error in protoregex token string test.
p-rx: a3d0b4e | pmichaud++ | (4 files):
[nqp]: Recognize statement end after close curly brace. Add "make nqp-test" target, and first set of tests.
p-rx: b870296 | pmichaud++ | t/nqp/02-if-else.t:
[nqp]: Add (passing) if-elsif-else tests.
p-rx: 182e820 | pmichaud++ | t/nqp/0 (2 files):
[nqp]: Somehow missed adding these tests in earlier commits.
p-rx: 4174ed2 | pmichaud++ | (3 files):
[nqp]: Add 'unless' statement.
 01:57
01:59 davidfetter joined
nopaste "Austin" at 98.235.55.43 pasted "Suggested changes to plumage's src/Makefile.in (japhb, darbelo)" (26 lines) at nopaste.snit.ch/18425 02:06
02:35 janus joined 02:45 particle1 joined
japhb Austin, thank you. Just pushed a slightly modified version of your patch. 02:53
Austin cool
dalek rrot-plumage: cfa89e9 | japhb++ | :
[BUILD] Automatic Makefile rebuilding, Austin++
 02:55
Austin Looks good, G
japhb "That's the way the ball bounces, G." 02:58
Austin Man, I'm getting this "0" printed out all the time and I can't figure out where the hell it comes from. Boy is it irritating. 03:14
Ahh, that's got it. Thanks, parrot -t4 03:16
dalek kudo: 49e62fa | (Kyle Hasselbacher)++ | t/spectest.data:
[spectest.data] Add integration/return-from-method-in-hash.t (RT 69610)
 03:43
03:49 mokurai left 03:54 mokurai joined
Austin Bass for your face! 04:25
www.youtube.com/watch?v=PBlMrGgpwXE @ 1:55 04:26
04:30 mberends joined
dalek p-rx: 6ebc781 | pmichaud++ | t/nqp/0 (4 files):
[nqp]: More test fixes, add 04-comments.t .
 04:39
p-rx: c48a575 | pmichaud++ | t/nqp/0 (10 files):
Rename test files to avoid 00-* test (and since we won't use 05-pod.t
p-rx: c5c2958 | pmichaud++ | t/nqp/06-args-pos.t:
Add 06-args-pos.t test.
p-rx: 6be2c89 | pmichaud++ | (4 files):
[nqp]: Add prefix:<!> and prefix:<?>. Add 'plan' and 'ok' builtins.
p-rx: 86ff73b | pmichaud++ | (2 files):
[nqp]: Make immediate blocks work in statementlists. Add 08-blocks.t.
 04:51
05:01 Austin_Hastings joined
dalek p-rx: d6f5066 | pmichaud++ | src/PAST/Regex.pir:
Zero-width anchors allow prefix tokens.
 05:14
05:17 eternaleye joined 05:53 nbrown joined 06:03 bacek joined
Austin Good day, Bacek. 06:03
Speaking of which, how did your big production release go? 06:04
japhb Well played, Austin 06:11
Austin Apparently I've rendered him speechless with my witty repartee... 06:12
cotto clock?
purl cotto: LAX: Thu 11:12pm PDT / CHI: Fri 1:12am CDT / NYC: Fri 2:12am EDT / LON: Fri 7:12am BST / BER: Fri 8:12am CEST / IND: Fri 11:42am IST / TOK: Fri 3:12pm JST / SYD: Fri 5:12pm EST /
Austin :|
japhb The "Well played, Austin" was in reference to you catching the Public Enemy reference and returning it in spades. ;-) 06:13
Austin Ah.
06:13 uniejo joined
Austin They're on my iPod. 06:13
japhb Ditto
g'night! 06:15
Austin Somewhere between Pink Floyd and Rammstein :)
06:15 desertm4x joined
japhb Damn you for making me laugh until I cough 06:15
japhb really afk now
dalek p-rx: fbaf420 | pmichaud++ | src/ (4 files):
Add special handling of <sym>.
 06:29
p-rx: a02da52 | pmichaud++ | src/NQP/Grammar.pm:
[nqp]: Switch grammar to use <sym> subrule.
p-rx: 5ad06df | pmichaud++ | src/ (3 files):
[p6regex]: Switch to use <sym> subrule in protoregexes.
06:31 bacek joined
bacek o hai 06:44
Austin: pretty well. We are totally messed up :)
Austin Yes! 06:45
Job security.
purl somebody said job security was very useful!
06:45 eternaleye joined
dalek rrot: r42032 | chromatic++ | trunk/config/gen/makefiles/root.in:
[config] Fixed Makefile dependencies for src/call/args.c. This should help
 06:47
bacek chromatic: any objections for my morning patch? I'm going to commit it. 06:50
ttbot Parrot trunk/ r42032 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/119441.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 06:55
chromatic I don't think it's the right approach.
I have a weird feeling we're adding a vtable entry we'll yank out again soon. 06:56
I'd rather we get a few people together, figure out exactly what we need to do, and work up a design that'll work pretty well now and very well after we fix the params/returns opcodes in January.
dalek rrot: r42033 | chromatic++ | trunk/src/string/api.c:
[string] Fixed some compiler warnings in Parrot_str_unescape().
 07:00
rrot: r42034 | chromatic++ | trunk/t/op/cc_params.t:
[t] Added necessary test boilerplate (such as a copyright statement and footer)

this as a PIR program, not a Perl 5 program.
07:00 JimmyZ joined
chromatic It's two things, really. The biggest red flag for me is that we're still copying pointers around. I think whatever system we eventually end up with will have to avoid that. Adding a new vtable entry to keep that around bothers me. 07:00
bacek chromatic: heh. I can rework it using set_pointer_keyed_int. push_pointer is just shortcut. 07:01
chromatic That would help, yes.
bacek and copying pointers in build_returns is much smaller then copying everything in build_sigobject 07:02
chromatic I agree, but all that looping and memory copying is expensive.
Austin Anyone want some improved performance?
chromatic In general, yes. 07:03
Austin I've got an opcode for you: "replace_null(INOUT $1, PMC $2)" replaces a null in $1 with $2.
Every third line in the output of NQP is "unless_null .... goto ..." to get this behavior. 07:04
chromatic The equivalent of Perl 5.10's //= then? 07:05
Austin No. Not a PMC as $2, but a typename.
Yes.
Have a look at some nqp-generated .pir code.
chromatic Seems cheaper to add :default on parameters. 07:06
Austin Back in 1.6, it was just on variables (which sucked enough) but now he's apparently got it on storage temporaries, too.
chromatic ... except semantics are tricky.
Austin It's not a parameters thing. It's after every variable reference.
chromatic Can you nopaste an example? 07:07
nopaste "Austin" at 98.235.55.43 pasted "Why a //= opcode?" (14 lines) at nopaste.snit.ch/18426
ttbot Parrot trunk/ r42034 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/119495.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 07:08
chromatic Seems reasonable. 07:10
I'd like to hear pmichaud's thoughts, but I can see the use.
Austin No vtable required, but adding that op, and putting into PCT, would knock probably 12-18% off the generated file sizes.
07:11 fperrad joined
Austin I'm wrong. It's 6.3 percent. 07:12
In a .pir file with 21872 lines, 1381 were "unless_null"
purl, 1381 / 21872
purl 0.0631400877834674
chromatic Right, but we can also get rid of the label and the assignment lines too.
Austin I think not. 07:13
I'm talking about replacing 2 opcodes (unless-goto, init) with one opcode (init-unless)
I'm guessing that the short branch is a single opcode, and that there's nothing in the pbc for the label, right? 07:14
chromatic I don't know much about bytecode storage, but I think you're right.
The labels come out of the PIR code though.
Austin So the pir goes down by 12%, but the pbc by 6%. Still nothing to sneeze at, I think.
Plenty of states pay their budget with a 6% tax... 07:15
chromatic PBC goes down from five opcode_ts to three.
Austin Does it? 07:16
What's the pbc look like for that sequence?
chromatic set_unless_null P SC is one opcode_t for the op type and one each for two arguments.
07:17 desertm4x_ joined
Austin set if null, you mean? 07:17
chromatic Right.
Austin Okay.
unless-null-branch P, small-offset is probably 2 opcode_t's, and new R, SC is 2. 07:18
chromatic unless_null P IC is three opcode_t s. 07:19
Austin Really?
That's bad design.
chromatic That's no reason not to believe it.
Austin :)
So 5->3 07:20
About a 2% size reduction, then.
chromatic Speed-wise, maybe a 2-3% gain. 07:21
Austin I'm thinking it's "new_if_null" or "vivify".
Is it?
purl it's it!
chromatic I like vivify.
Austin I think the gain might be more.
chromatic It might.
Austin But what's the branch penalty, or is there one, really? 07:22
For the most part, it always jumps, because most of these vivs are redundant.
chromatic A local jump like this merely changes the address of the next opcode to execute. 07:23
If there's any notable penalty, it's a data cache read miss.
In straight-line code like you pasted, we'd have to pay that cache miss anyway. 07:24
The PBC size reduction actually *helps* there more than avoiding the jump.
Austin Why would we pay the cache miss anyway? 07:25
chromatic Because that's straight line code through the PBC. If one instruction is on one page and the next instruction is on another, we'll probably end up there anyway. 07:26
Austin Oh, sure.
TT# 1138 07:34
dalek TT #1138 created by Austin_Hastings++: Create a 'vivify' opcode
Austin Hmm. Now I can generate nulls, but it's hard to catch them. 07:35
mikehh just updated my Ubuntu 9.10 beta - I think I need to reboot - bbiab 07:36
07:39 kurahaupo joined
Austin Anyone have a bunch of test cases for bsearch laying around? 07:41
07:42 mikehh joined 07:49 xenoterracide joined 08:01 einstein joined
dalek rrot: r42035 | fperrad++ | trunk/t/op/cc_params_old.t:
[codingstd] fix SVN properties
 08:06
ttbot Parrot trunk/ r42035 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/119584.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 08:13
08:15 mikehh joined 08:21 eternaleye joined 08:30 TiMBuS joined 08:47 colomon joined 09:00 barney joined 09:17 chromatic joined 09:21 masak joined
dalek p-rx: 7fa2ece | masak++ | src/cheats/hll-grammar.pir:
Fixed typo in documentation.
 09:23
desertm4x_ I've a question concerning PMCs. I'd like to call a method on another PMC (not SELF, but of the same pmclass). How would I do this? I could not find examples / documentation. 09:58
10:01 donaldh joined
Austin desert4mx_ : In what language? 10:09
And are you being precise, when you say "method" ?
10:12 pjcj joined 10:37 kid51 joined
desertm4x_ Austin: Sorry, I was away... Well, language ... I'm trying to write a PMC in C (i.e. src/dynpmc/...pmc) and the question was about methods I declared with the METHOD keyword. But I found a better solution for this case. Still, I would be interested in that question. 10:47
Austin desertm4x_ : Take at look around for "Parrot_pcc_invoke_method_from_c_args". 11:00
desertm4x_ Thanks.
Austin np 11:02
11:12 bacek joined 11:39 rdice joined
dalek TT #1093 closed by fperrad++: t/pmc/env.t segfaults on Windows 12:06
12:13 mj41 joined 12:26 bluescreen joined 12:34 whiteknight joined 12:36 whiteknight_ joined
bacek fperrad: ping. 12:42
fperrad pong bacek
bacek fperrad: pcc.patch doesn't applied clearly on 9b5ce128 12:43
a, my bud
bad
nope, still not. Looks like luatable.pmc and luauserdata.pmc somehow different on my checkout... 12:46
Coke fperrad: hope your email wasn't sitting around long, it was moderated.
12:48 colomon joined 12:49 preflex joined
nopaste "fperrad" at 77.194.156.254 pasted "[PATCH] Lua PMC" (625 lines) at nopaste.snit.ch/18428 12:53
12:59 gaz joined
Coke fperrad: when I rewrote partcl's one use of this, I used github.com/partcl/partcl/blob/maste...ng.pmc#L47 13:02
(not sure if that helps you or not) 13:03
fperrad Coke, in Parrot tree, I found few files where Parrot_runops_fromc_args() become Parrot_pcc_invoke_sub_from_c_args() 13:08
Coke if it works, it works. =-) 13:09
(my initial replacement for invoking something segfaulted, so I was happy for the new func in src/extend.c)
13:10 payload joined 13:13 donaldh joined, donaldh left 13:15 fperrad_ joined
Coke huge # of failing smokes. 13:23
13:45 ruoso joined 13:47 bacek joined
PerlJam Is the parrot svn server down? 13:50
I get svn: OPTIONS of 'svn.parrot.org/parrot/trunk': could not connect to server (svn.parrot.org) when trying to "svn up"
13:51 gaz joined
Coke PerlJam: looks ok to me. 13:58
14:00 colomon joined
Coke todo: add a link to widget.mibbit.com/?server=irc.perl....=%23parrot to the website. 14:01
particle ping svn.parrot.org 14:02
purl 10 packets transmitted, 10 received, 0% packet loss, time 9015ms, rtt min/avg/max/mdev = 82.531/82.837/83.567/0.474 ms 14:03
14:06 colomon_ joined, cghene joined 14:11 payload joined
nopaste "bacek" at 114.73.47.212 pasted "Patch for Lua to use public parrot API for fperrad++" (647 lines) at nopaste.snit.ch/18431 14:15
bacek fperrad: ping
fperrad bacek, pong
dalek rrot: r42036 | bacek++ | trunk/src/call/pcc.c:
Run ops for Sub subclasses. fperrad++
bacek try nopasted patch on r42036
14:16 whiteknight joined
bacek It works on my box. 14:16
fperrad bacek, great 14:17
bacek fperrad: does it work?
fperrad bacek, I need time (rebuild, ...) 14:18
bacek fperrad: ok. 14:19
14:24 davidfetter joined
dalek TT #1139 created by bacek++: Need tests for invoke_sigobject for Sub subclasses. 14:25
bacek fperrad: looks like it hangs on make spectest in 000-sanity.t... Sigh.
14:27 elmex_ joined 14:30 colomon joined
whiteknight trac is rediculously slow today 14:33
Where is plumage hosted? 14:40
is it in the parrot repo?
moritz plumage? 14:42
purl plumage is the future Parrot module ecosystem. It will include tools to search metadata, handle dependencies, install modules, and so forth. The repository is at gitorious.org/parrot-plumage/parrot-plumage and the design docs are at trac.parrot.org/parrot/wiki/ModuleEcosystem
NotFound whiteknight: trac.parrot.org/parrot/wiki/ModuleEcosystem
whiteknight ah, gitorious
cotto_work good day, #parrot 14:45
dalek rrot: r42037 | bacek++ | trunk/t (5 files):
Rebuild native PBC and update packfile tests.
 14:49
whiteknight has finally printed out a new Parrot CLA to mail in
it's taken me this long to find the damn link
particle parrot cla?
feh, what happened to purl's factoid 14:50
cla?
purl rumour has it cla is Contributor License Agreement or www.perlfoundation.org/contributor_..._agreement or www.parrot.org/foundation/legal or www.parrot.org/files/parrot_cla.pdf or www.lowcarbfriends.com/bbs/main-low...-acne.html
14:52 Psyche^ joined
cotto_work Are we supposed to be sending CLAs to PaFo, even if we've sent them to TPF? 14:54
moritz yes
allison answered a mail about that recently on parrot-dev
cotto_work good to knoq. I'll have to get on that.
s/q/k/ 14:55
moritz good to knok :-)
cotto_work nm
I apparently don't knok how to type this week. ;) 14:56
NotFound++ for the random Spanish blog post 14:57
particle you typed 'this week' just fine. 14:59
cotto_work my bad 15:00
nobody's perfectly imperfect 15:01
NotFound Oh, someone reads my blog?
cotto_work It won't read itself. 15:02
(not until Skynet, at least)
particle write a blogging engine with nqp-rx and see what happens
15:08 theory joined
whiteknight what I would really like to do is write a "make" utility for Parrot 15:09
ESPECIALLY one with reasonable syntax 15:10
pmichaud_ I just added a proposal for "fetch" and "vivify" opcodes to TT #1138, comments welcomed. I'd *really* like to see these added to Parrot, they'll simplify a huge amount of PCT code and be far more efficient.
cotto_work Interesting idea. It'd be as portable as Parrot by definition.
particle there's already on ein the works, whiteknight
whiteknight particle: really? link?
in theory, make's algorithm isn't too hard to duplicate 15:11
pmichaud_ arrrg, trac lost my post!
dalek rrot: r42038 | bacek++ | trunk (7 files):
[core] Replace RPA of CPointers for handling returns with single

This decrease number of allocated GC objects by ~1M in fib.pir and improve performance by ~11%. This is temporary solution to bring some speed loss after PCC refactors. Will probably removed after 2.0 release with unification of args/returns handling.
pmichaud_ (my earlier post to #787, not the one I just made to #1138)
particle code.google.com/p/smart-make/
15:12 colomon joined
whiteknight take rules, build an acyclic graph of dependencies, then traverse the graph building each peice 15:12
particle *directed acyclic graph 15:13
NotFound pmichaud_: hey, you stolen that idea from me ;)
whiteknight ah, true. Directed acyclic graph
the hardest parts would be to build the graph(s) while avoiding cycles, and building a library of build rules for each type of object 15:14
particle did you see my link? 15:15
bacek whiteknight: you shouldn't "avoid" cycles. You should detect them.
whiteknight yes, but I'm still preaching
bacek: detect them and panic is the same as avoid
particle sits in the choir
whiteknight Assuming we aren't trying to be graceful about it
particle javac is quite graceful about it 15:16
it builds binaries from sources with cyclic dependencies
moritz "graceful" = "nice error message"?
particle incremental compilation
moritz time travel! 15:17
purl i guess time travel is easy. It's just changing the speed and direction that's hard or www.explosm.net/comics/1129/
15:17 rdice joined
dalek TT #1140 created by doughera++: config/gen/platform/generic/env.c unsetenv() out of sync 15:21
whiteknight I also want to add an "Enhanced PIR" preprocessor tool that gives PIR code some common code structures (if/then/else, for, foreach, while, etc) 15:27
proper try/catch, in a way that will will abstract away changes we need to make there later 15:28
NotFound whiteknight: I think last time we talked about that some pople said that pir already has too much sugar
whiteknight NotFound: I'm talking about a separate compiler project that would take "Enhanced PIR" files and translate them to normal PIR
NotFound whiteknight: that is Winxed ;) 15:29
whiteknight NotFound: that uses different syntax. I'm still thinking about a PIR-like syntax
just with loops and stuff
NotFound Not a bad idea.
15:29 fperrad joined
fperrad ping bacek 15:30
purl I can't find bacek in the DNS.
whiteknight Matrixy, for instance, uses matrices and a lot of loops. multiple loops and nested loops are horrendous in normal PIR
bacek fperrad: pong
15:30 payload joined
fperrad bacek, not ok 15:31
nopaste "bacek" at 114.73.47.212 pasted "More lua patches for fperrad" (13 lines) at nopaste.snit.ch/18433
fperrad have you try :
$ prove t/pmc/*.t
whiteknight so I want a small pre-processor to throw in the build that will allow us to write prettier libraries in PIR
nopaste "bacek" at 114.73.47.212 pasted "Lua test summary report" (47 lines) at nopaste.snit.ch/18434
bacek fperrad: nopaste.snit.ch/18434 with additional patch from nopaste.snit.ch/18433 15:32
nopaste "bacek" at 114.73.47.212 pasted "Result of "prove t/*pmc" in Lua" (25 lines) at nopaste.snit.ch/18435 15:33
whiteknight oi! lua is failing a lot of tests
Tene Yeah. See mail on the list about updating lua to pcc.
whiteknight does lua use lots of C code? 15:35
bacek whiteknight: yes. A lot of PMCs at least
whiteknight ok 15:36
are the failures from old Lua code needing to be updated, or PCC not supporting all features?
bacek # got: 'lua.pbc: _._:0: We don't handle :flat returns into a :slurpy result yet 15:37
whiteknight that doesn't make any sense?
15:37 payload joined
bacek I helped fperrad++ for updating to current PCC. Time to update PCC by it self 15:38
whiteknight: src/call/args.c:1666
whiteknight wtf? 15:40
the return should be flattened when the signature is created, before the call to fill_results
the return should be flattened in the set_returns opcode 15:41
oh shit, get_params is called before set_returns is
bacek it doesn't matter. 15:42
Coke is there a way with mailman to say "I don't care about implicit destinations" for a given list?
bacek We don't update original signature during flattening
Coke (I have a user who is whitelisted, but I keep having to approve his messages because of the implicit destintation.)
bacek whiteknight: and build_sigobject_returns doesn't flatten result... 15:43
whiteknight the whole returns process is backwards and I still don't understand all the intricacies of it
probably need to read more code 15:44
Coke whiteknight: (enhanced pir) see hllmacros.pir.
whiteknight Coke: seen them. step in the right direction but not nearly enough
Coke feel free to add more. =-) 15:45
I have some TryCatch that I added to partcl that could be stolen back.
(I know it's not another language, but I don't have a need for something between nqp and pir+hllmacros. YMMV, orf course.)
github.com/partcl/partcl/blob/maste...os.pir#L36 15:46
15:46 iblechbot joined
pmichaud_ tries nqp-rx against parrot trunk 15:47
Coke I didn't bother moving the trycatch ones in because someone was pushing for killing that kind of handler.
(but feel free if you want to. =-)
dalek a: f44ff0a | unknown++ | t/pmc/thread_hll.t:
fix plan
 15:49
cotto_work interesting idea about svn (and implicitly a good case for git): designbygravity.wordpress.com/2009/...d-merging/
pmichaud_ heh 15:52
Coke cotto_work: that's pretty much allisons' approach to branching/merging.
pmichaud_ that's essentially the way I've been recommending to do branches in svn
Coke and pmichaud's. =-)
pmichaud_ always start a new branch from trunk and merge your old branch into it 15:53
don't ever merge trunk into a branch
cotto_work and hope you don't have to bisect something
Coke (comments in that article poitning out that pre-1.5, 1.5, and 1.6 handle this problem differently, and that the author is probably addressing pre-1.5) 15:55
moritz which means you lose log and blame log for the branch 15:56
dalek rrot: r42039 | bacek++ | trunk/src/call/args.c:
[core][pcc] FLAT returns into SLURPY results.
 15:57
cotto_work It works, but it's inelegant. 15:59
16:02 darbelo joined
bacek whiteknight: Parrot_pcc_merge_signature_for_tailcall asserting on "parent" in Lua. 16:02
whiteknight damnit 16:03
bacek # Back in sub 'parrot;Parrot::Coroutine;resume', env 80bb474 16:05
*** switching to
src/call/args.c:2353: failed assertion 'parent'
looks like some problems with Coroutines
16:07 Andy joined
Tene whiteknight: :flat returns into :slurpy results is certainly possible... I just stubbed out that exception clause in my first draft of that code, and it looks like nobody ever got around to finishing it. 16:07
whiteknight: yes, it's all very backwards.
whiteknight yeah, I really want to make it un-backwards at some point 16:08
bacek Tene: r42039 16:09
whiteknight but I want a lot of things 16:10
bacek and little pony? 16:13
pmichaud_ ... the new pcc doesn't handle :flat into :slurpy returns?
that's a problem.
bacek pmichaud_: it does already.
pmichaud_ oh 16:14
I just tried 42038
I'll try 42039
bacek For last 15 minutes. It's like for ages in modern world :)
pmichaud_ really wants the fetch and vivify opcodes he just proposed in TT #1138
I'll even write fetch+vivify. PCT could use them today. Code would be much cleaner. 16:15
whiteknight much cleaner
nopaste "bacek" at 114.73.47.212 pasted "Lua "prove -r t" results..." (76 lines) at nopaste.snit.ch/18436
Coke pmichaud_: you could pretty easily add them as experimental ops for comparison. 16:16
pmichaud_ Coke: yes, but as soon as I add them PCT will convert to depend on them.
I will probably take that approach, though.
Coke so I would get concensus from a few more people before doing a full on convert. 16:17
pmichaud_ well, I like the part of my proposal that doesn't create new objects for read-only values
Coke but if they're in as experimental, demonstrating improvments in code size/speed/etc. becomes concrete.
16:18 kthakore joined
kthakore hi again! 16:18
purl oh, you're back!
pmichaud_ although I suspect the consistent and safe behavior would be to always clone, even in the read-only case 16:19
kthakore dalek: how did this go btw? irclog.perlgeek.de/parrot/2009-10-17#i_1612550
oops
dukeleto: how did this go btw? irclog.perlgeek.de/parrot/2009-10-17#i_1612550
pmichaud_ any thoughts about which approach I should take to handling lexicals (from trac.parrot.org/parrot/ticket/1138#comment:3) ? 16:20
Coke thinks he's figured out his mailman question
pmichaud_ nqp-rx works with r42039 bacek++ 16:21
Coke msg allison added the hosting alias OSU uses for directors list, should cut down on admin requests.
purl Message for allison stored.
dalek rrot: r42040 | darbelo++ | trunk/config/gen/makefiles/root.in:
Add some more dependecies to the main makfile template. This fixes parallel building for BSD make.
 16:26
darbelo Do any of the parallel buildes in the room care to test r42040 with GNU make? 16:27
cotto_work darbelo, yes they do 16:29
darbelo Cool. I just ran a make -j3 on OpenBSD with those changes. 16:30
having confirmation for GNU make would be cool.
cotto_work first try worked. I'll try a couple more times just to be sure. 16:31
bacek darbelo: looks good on my box. 16:32
darbelo Ok, just spotted another missing dep, but it seems to build fine anyways. 16:33
dalek a: fef745c | unknown++ | (6 files):
PMC conversion after pcc merge (trac.parrot.org/parrot/changeset/41972)
darbelo Ha! failed with -j6 16:35
particle cotto_work: you did realclean first, yes? 16:36
cotto_work yes
it worked for me 16:37
particle, reconfig (but that does realclean)
particle just checking :) 16:38
dalek rrot: r42041 | darbelo++ | trunk/config/gen/makefiles/root.in:
Add another missing makefile dep.
 16:42
16:44 payload joined 16:50 mikehh joined
dalek TT #472 closed by fperrad++: segfault when catching an exception from C 16:52
cotto_work darbelo, ~30 minutes of running parallel make seems to say that you fixed it 17:07
darbelo++
darbelo Yay!
17:08 mikehh joined
darbelo japhb: ping 17:12
japhb pong 17:13
darbelo I've just replied to your 'install-dev' mail with a patch. Does it work as intended for you? 17:14
japhb will look. Still catching up with morning
17:18 colomon joined, gaz joined
dalek a: 066428c | unknown++ | src/lib/bc.pir:
fix library bc
 17:23
japhb darbelo, patch looks good. I haven't tested it locally, but you didn't use anything that's not ultra-portable, so I'd say just go ahead and commit, unless someone objects. 17:24
darbelo japhb: They can't object if I commit before they notice :) 17:26
japhb :-)
darbelo But I'd rather wait for a bit. Maybe I'll open a Trac Ticket. 17:27
cotto_work +1 to do it now
japhb pmichaud_, which level in the lexpad stack would vivify_lex create the new entry? Nearest? 17:31
darbelo jfdi 17:35
japhb Go darbelo, go darbelo
cotto_work It'd be a good idea to leave the ticket open for a couple days for feedback. 17:37
dalek rrot: r42042 | darbelo++ | trunk/config/gen/makefiles/root.in:
Add files installed by 'install-dev' to the 'install' make target.
17:43 desertm4x joined
dalek rrot: r42043 | mikehh++ | trunk/MANIFEST:
fix manifest_tests error - Failed test 'No need to regenerate MANIFEST'
 17:47
darbelo mikehh: doesn't that regress TT#1126 ? 17:49
cotto_work ow my script 17:52
dalek rrot: r42044 | mikehh++ | trunk/src/call/args.c:
fix codetest failure - space between C keyword and subsequent open parenthesis
 17:53
rrot: r42045 | mikehh++ | trunk/src/pmc/callsignaturereturns.pmc:
set svn properties
 17:57
18:05 joeri joined
dalek rrot: r42046 | mikehh++ | trunk/src/pmc/callsignaturereturns.pmc:
fix codetest failure - there should be at least one space between a C keyword and any subsequent open parenthesis
 18:06
cotto_work darbelo, feel free to fix that
pmichaud_, is it possible to generate PAST from C? 18:12
mikehh call
dalek rrot: r42047 | mikehh++ | trunk/src/pmc/callsignaturereturns.pmc:
fix codetest failure - missed a trailing space
 18:13
mikehh bah - src/pmc/callsignaturereturns.pmc is missing a associated test file
rrot: r42048 | darbelo++ | trunk/MANIFEST:
Re-add the [devel] tag to the tools/dev/pprof2cg.pl MANIFEST entry.
mikehh an
cotto_work thanks darbelo
mikehh darbello - you beat me to it 18:15
18:16 kurahaupo joined
mikehh still got an unused assert macro to come 18:16
dalek rrot: r42049 | mikehh++ | trunk/src/call/pcc.c:
fix codetest failure - unused assert macro
 18:23
mikehh ok that fixes all but one codetest failure - files in src/pmc but not in test dir: callsignaturereturns 18:25
I don't know if I am going to attempt that one :-}
cotto_work mikehh, you can create a stub test and file a ticket requesting more tests, 18:27
you could even write some tests yourself. Ask bacek what needs to be tested if you're interested. 18:28
18:34 chromatic joined 18:38 Coke joined
darbelo is amused that Coke is the only guy who doesn't like Google Wave in the GSoC poll 18:41
dalek tracwiki: v16 | kurahaupo++ | ArrayTasklist 18:42
tracwiki: Arrays as mix-ins
tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
mikehh cotto_work: I have a stub - just not sure what to put in it - trying to figure out what it does 18:47
pmichaud_ japhb: (vivify_lex) it wouldn't create new entries, it would only fill in existing ones
in parrot, lexpad entries are determined at compile time (except for dynlexpads, which are different here) 18:48
darbelo mikehh: You don't have to figure it out, just ask bacek :)
mikehh ha
bacek: ping
japhb pmichaud_, OK, sure. 18:49
darbelo It's all his fault for not committing tests along with the feature to begin with ;) 18:50
japhb Thus vivify_lex would be able to fill the one it found in lex search order
Great, you get a +1 from me ... which isn't a surprise, given I filed the old ticket asking for the protean form.
Coke darbelo: so far, it sucks. 18:51
I was a maybe until I actually tried to use it. =-)
pmichaud_ yes, "fetch/vivify" have much more of the semantics I think we're looking for. They certainly resolve the issue without having to introduce new vtables, and they map more cleanly to the problem space. 18:52
I'll probably implement them as experimental ops over the weekend.
japhb yep, please!
pmichaud_ tomorrow I'm at a conference much of the day, so don't know how much hacking I'll be able to do
darbelo Coke: Not blaming you for not liking it. 18:53
chromatic I could implement them if you gave me some tests.
pmichaud_ on the plus side, nqp-rx is coming along very well. :)
japhb Which conference?
yay!
pmichaud_ chromatic: thanks for the offer, but since they'll ultimately be tied to PAST I think I'm happy to do them. Plus I'm already familiar with the lexicals side of things.
chromatic: I would like a review of the patch when I get it done, though.
chromatic: (and does this count as a +1 from you as well? ;-) 18:54
chromatic I'm less sure about the fetch_lex op; I slightly prefer a new PMC for that.
pmichaud_ yes. I'm thinking Rakudo would like a new PMC.
it would be nice to have an object that allows one to look in all outer scopes at once
i.e., a keyed interface that does the equivalent of find_lex 18:55
if you wanted to create that PMC, that'd be awesome.
i'm thinking a PMC that has an associated context, key lookups on the PMC cause it to search the context and its outer scope
*scopes 18:56
I'm also not sure if $P0 = fetch $P1[key], $P2 should return $P2 directly or a clone of $P2
at the moment I'm leaning towards clone
whiteknight got a blackberry!
pmichaud_ gives whiteknight a raspberry.
chromatic Austin's suggestion was the name of a PMC to create, but a clone is more flexible.
whiteknight estimates about 2 weeks before Parrot runs on blackberry
pmichaud_ yes, I think clone is more flexible too. 18:57
chromatic That's a six line op.
pmichaud_ well, if you want to go ahead and create the ops, I'll certainly test/evaluate them for you. I can patch them if I need some slightly different semantics. 18:58
it will require changing PAST a bit, but I think I'll just augment the existing interface
chromatic The syntax will have to be $P0 = fetch $P1, [key], $P2 however.
s/will/may/
pmichaud_ I have no problem with that
in some ways I like that much better 18:59
it's much easier for PAST to deal with $P1, key, $P2 than $P1[key], $P2
chromatic That's good, otherwise one of us might have to coerce IMCC to allowing a keyed lookup there, and I suspect I know who it isn't going to be.
pmichaud_ I suspect you're correct about that.
$P0 = fetch $P1, key, $P2 works very well for me 19:00
key should be any of pmc/int/string
(and dispatch to the appropriate vtable interface on the aggregate)
chromatic They almost write themselves.
pmichaud_ there may come a time when we also want $P2 to be any of pmc/int/str/num but that's a future issue (say, when we want lexicals to be able to hold things other than PMCs) 19:01
out of curiosity, how hard would it be to enable temporary registers of the form $Pfoo, $Ibar, etc.? I.e., to allow identifiers after the $P, $I, etc. ?
chromatic What's your estimate on how much code this saves, NQP-wise?
Enabling temporary registers is pretty easy. 19:02
pmichaud_ it will tend to convert as many as 7 opcodes down to 1
the long sequence is currently
$P0 = fetch_lex '$foo'
unless null $P0 goto label
$P0 = new ['Something']
purl $P0 = new ['Something'] is the correct syntax now btw
pmichaud_ store_lex '$foo', $P0 19:03
label
...
okay, maybe 4 down to one
japhb purl, forget $P0 = new ['Something']
purl japhb: I forgot $p0 = new ['something']
mikehh I am getting a post_config test failure - t/tools/pmc2cutils/00-qualify.t - Failed test: 5
pmichaud_ I suspect I'm missing something somewhere
japhb pmichaud_, didn't you paste the full sequences into one of the two tickets?
pmichaud_ I pasted one of the full sequences
chromatic Alright, give me a bit here.
pmichaud_ where it gets really tricky is when autovivifying containers
chromatic Are you in a position to take advantage of these in trunk? 19:04
pmichaud_ yes
it's really more of a PAST benefit than an NQP one
chromatic It may eventually be an NQP-ng benefit, but yes. 19:05
pmichaud_ I'd be able to update existing PAST and NQP to take advantage of it in trunk
chromatic Okay, give me an hour or so.
pmichaud_ it'd definitely be an NQP-rx benefit, yes.
(not only would I be able to do it, but I will do it)
I have to go searching for a lost dog -- bbiab
chromatic I have to go searching for a lost meal.
(this one's vegetarian, if anyone's confused) 19:06
Coke I'm always confused; your vegetarian dog food aside.
pmichaud_ found her... fortunately she didn't run far this time :) 19:07
19:16 payload joined
Coke pmichaud_: did you happen to see my motivation out there? 19:17
pmichaud_ Did not. 19:24
purl did not is did too
pmichaud_ actually, most of what is outside at the moment would be motivation to stay outside. :)
cotto_work pmichaud_, is it possible to generate PAST from C? 19:25
purl i already had it that way, cotto_work.
cotto_work purl, forget pmichaud_
purl cotto_work, I didn't have anything matching pmichaud_
cotto_work purl, forget pmichaud_,
purl cotto_work: I forgot pmichaud_,
pmichaud_ cotto_work: not that I know of.
cotto_work: generating past is all just method calls
mikehh bah - the test failed because I had not removed the *.*~ files in src/pmc - fixed now
cotto_work That's what I thought. 19:26
Isn't an eventual goal to allow non PCT-based tools to generate PAST, or is the intended target PIR like winxed does 19:27
?
pmichaud_ I don't understand the question. 19:28
cotto_work grammar fail there.
Do we eventually want to allow parsers to be written in e.g. C/C++ that emit PAST? 19:29
pmichaud_ nothing prevents that from happening, other than we'd want a good C-to-Parrot interface 19:30
i.e., if we can create Parrot objects from C and invoke Parrot methods, then we can generate PAST from C
cotto_work is such an interface on the roadmap? 19:31
pmichaud_ I think that one of the motivations for the pcc refactor was to (eventually) make it easier to interface with Parrot from C (and vice-versa)
but the generic form for creating past structures is just 19:32
$P0 = get_hll_global ['PAST'], 'Op'
$P1 = $P0.'new'( ...arguments... )
cotto_work certainly nothing magical there
pmichaud_ where 'new' expects to be able to get both positional and named arguments
the best place to see creation of PAST from PIR is compilers/nqp/src/Grammar/Actions.pir 19:33
it gives the NQP version in the comments, then the equivalent PIR code in the source
s/from PIR/using PIR/ 19:35
cotto_work and the C would look something like that, except more verbose because it couldn't use pcc directly like PIR can
pmichaud_ right
although it could certainly be made less verbose 19:36
past = PAST_VAR_new( ...args... )
where PAST_VAR_new encapsulates the PCC calls needed to look up the PAST::Var protoobject and then invoke the 'new' method on it
19:39 Austin joined
pmichaud_ afk 19:39
cotto_work nothing like that is currently planned, though?
Coke pmichaud_: I will have some hacking time available this weekend, if there's anything I can do to prep. 19:41
19:49 ruoso joined
whiteknight purl forget did no 19:50
purl whiteknight, I didn't have anything matching did no
whiteknight purl forget did not
purl whiteknight: I forgot did not
whiteknight purl did not is <reply>did too
purl OK, whiteknight.
whiteknight did not
did not?
purl did too
whiteknight slightly better
pmichaud_ Coke: I'm not planning anything from C at the moment, no. 19:55
s/Coke/cotto_work/ # tab fail 19:56
cotto_work I'll try to remember to ask about that at the next #ps
afk 19:59
Coke darbelo: +1 on your install patch.
cotto_work Coke, it's already in trunk
Coke perhaps someone could close out that thread, then. =-) 20:00
mikehh trunk - pre/post-config, smoke (#29347) PASS, fulltest FAIL at r42049 - Ubuntu 9.10 (beta updated) amd64 20:03
t/op/annotate-old.t - Failed test: 1 - in testf and testg (TT #1135)
t/pmc/eval.t - Failed test: 12 - in testr
t/pmc/threads.t - Failed tests: 8-9 - in testr
the testr failures come from Segmentation faults
t/codingstd/test_file_coverage.t - files in src/pmc but not in test dir: src/pmc/callsignaturereturns.pmc
the remainder of fulltest passes
20:04 colomon joined
Austin pmichaud, re your comments on TT# 1138, I agree that we could come up with more potent opcodes. I was reluctant to propose the obvious N ops, since N is pretty large (= every 'get*' op). 20:07
whiteknight I think common usage patterns should inform our inclusion or exclusion of various ops 20:08
I like the idea of having fewer ops, so that we can get rid of the ones we don't use
Austin me too, which is why I think vivify should already be there. :)
Frankly, I'm bewildered by the existence of PMCNULL. 20:09
whiteknight In parsing PIR, looking up an op is O(n) worst case, so having fewer increases parsing speed
Austin It is?
purl Oh no it isn't!
Austin I thought it was O(1).
Coke darbelo: any pointers/docs on using your bignum stuff?
whiteknight yeah, if it's not a common case, or if there is an arg mismatch, it iterates the whole array of ops 20:10
at least, I'm reasonably certain it does
darbelo Coke: decnum-dynpmcs?
purl decnum-dynpmcs is code.google.com/p/decnum-dynpmcs/ or a 2009 GSoC porject or a set of 'big' decimal arithmetic types for parrot.
mikehh messages
Coke whiteknight: that's an argument for improving pir. =-)
whiteknight an argument for many things
tightening up our instruction set is always always always a good thing
Coke darbelo: ah, it's just Num, not Int? 20:11
Austin When is it O(n) ?
20:11 mokurai joined
whiteknight Austin: I'll have to look through the code again, But the parser has to identify each op in the PIR code 20:11
Coke whiteknight: "fewer is better" is not a long standing criteria for ops in parrot.
whiteknight Coke: that may be, but it should have been 20:12
Austin Whiteknight: Are we talking about compile time or run time?
darbelo Coke: There's a DecInt PMC, that was my attempt at convincing the decNumber library to work with integers, it's something of a hack.
Putting the right values into the Context might, or might not, yield sane Integer arithmetic. 20:13
whiteknight There are a lot of benefits to having a smaller instuction set
Austin: when we have runtime eval(), it's both
pmichaud_ Austin: (N ops) I agree, which is why I simplified it down to just two ops. :-) 20:14
I've been trying to come up with those two ops since last year, your message and the one in TT #787 finally crystallized my thinking on the subject :)
Austin pmichaud: yeah, but it's wrong. :( 20:15
pmichaud_ wrong?
purl but it feels so right
Austin I was just putting this in trac.
pmichaud_ why wrong?
darbelo Coke: code.google.com/p/decnum-dynpmcs/so..._group.pir
but s/DecNum/DecInt/g in the file. 20:16
Austin pmichaud: A lot of this is doing the job that the backing pmc's ought to be doing for us.
Why the hell is there such a thing as PMCNULL, other than a crutch for the C coders? 20:17
pmichaud_ Austin: that still doesn't avoid the fact that we need a way at the PIR level to indicate "lvalue fetch" versus "rvalue fetch"
PMCNULL basically provides a way to say "object doesn't exist" without requiring a separate "exists" check or throwing an exception
nopaste "chromatic" at 72.87.39.97 pasted "pmichaud -- tests for the fetch opcode" (138 lines) at nopaste.snit.ch/18438
Austin pmichaud: I abstain from agreeing, because I haven't slept on that issue - I genuinely didn't think of it.
Coke Austin: PMCNULL is exposed at the PIR level. 20:18
pmichaud_ PMCNULL isn't a C NULL pointer
they're completely different things
Austin But what I'm thinking is that Undef should be (and I think, is) a hll-map-able type.
chromatic PMCNULL is the Null Object Pattern.
pmichaud_ fetching a non-existant object from an aggregate is not the same as having an undef stored at that position 20:19
Austin And most things that return values to PIR ought to return undef, not null.
pmichaud_ I agree that we can have PMCs that default to returning Undef somehow. But there also needs to be a way to fetch values from an aggregate that doesn't vivify an aggregate at that location
Austin pmichaud: I grant that fetching something that doesn't exist is not the same thing, but it's the same result, since you just hacked PCT to replace nulls with undef. 20:20
pmichaud_ false
that's not what PCT
does
PCT doesn't automatically replace nulls with Undef -- NQP does that.
It's entirely possible for an HLL to not specify a viviself value, in which case the returned value remains PMCNULL
Austin Okay.
pmichaud_ NQP imposes the "aggregate defaults to undef" semantics, not PCT
20:21 bluescreen joined
pmichaud_ The point being, that's a HLL decision, not really a core PMC one. 20:21
I'd like an aggregate to be able to return me a value that says "no such element"
Austin Granted. But I think the underlying aggregates should get a 'default return' semantic.
pmichaud_ without me having to always check "do you really have an element there, or did you just default one?"
because "no such element" != "undefined" 20:22
japhb Austin: There needs to be a sentinel value for 'key in aggregate doesn't exist'. If the overlying languages did not have a 'null' or 'undef' value already, that's what we'd use. Except they do, so we need a different value, which is what PMCNULL is.
pmichaud_ that's why the fetch and vivify opcodes are so elegant 20:23
Austin Alternatively, throw InvalidElementException.new().
pmichaud_ I'd prefer not to have to catch an exception on every aggregate access either.
it's not necessarily an error to request @foo[10000000]
japhb There are four truthiness values for a value in an aggregate: 1. It's not there at all. 2. It's there, but it's undefined, 3. It's defined, but has a value that coerces to false, and 4. It's defined and has a value that coerces to true.
pmichaud_ but that shouldn't automatically build 10000001 elements for me
and if I have to build an exception handler for every aggregate fetch, that's going to get awfully expensive. 20:24
japhb definitely.
pmichaud_ fetch and vivify give me a way to say "I want this element, but if you don't have it, give me one of these instead" 20:25
that becomes particularly helpful for lexpads
because I can do
$P0 = vivify lexpad, '$foo', undef
and
$P1 = vivify lexpad, '@array', array
and
$P2 = vivify lexpad, '%hash', hash
japhb Austin, so we need both operations. The old ones that may return PMCNULL, and the new ones that pmichaud_++ have suggested. We shouldn't deprecate one for the other; they cover different use cases.
pmichaud_ there's no way that the lexpad can know what it should default the non-existent aggregate to be
Austin So again, the current pmc's have a "no-such-element" return that is 'pmcnull'. Which may have value to some hll somewhere, in theory. But NQP doesn't use it. And so, it remaps nulls to undef. So why not make the defaulting semantics explicit in the pmc?
pmichaud_ because the defaulting semantics really depend on context more than the underlying PMC, as my above example just showed. 20:26
in the above example, the underlying PMC is always lexpad
but what gets vivified depends on the HLL logic
Tene hll_map PMCNULL to Undef, obviously. ;)
pmichaud_ that would be wrong
in my example above for vivifying scalar/array/hash
same for fetch 20:27
Austin pmichaud: Okay. As I said, I'm abstaining on vivify - focusing on fetch.
pmichaud_ if I do a fetch of @array, I expect to get back an empty array, not an undef.
Coke tene: can you take a look at RT#49061 and RT#53978 and see if they are still valid? (if so, can you move them to trac and reject the old ones?)
pmichaud_ if I do a fetch of %hash, I expect to get back an empty hash, not an undef
those semantics are HLL semantics, not underlying PMC ones 20:28
Austin You've said that you are going to eliminate the need for fetch w.r.t., lexicals, soon, right?
pmichaud_ that works for Perl 6. Might not work for other languages.
wouldn't work for Perl 5.
I said I was going to do it in NQP and Rakudo.
Austin But not soon?
pmichaud_ soon, yes.
Tene Coke: 49061 is PGE's repeated zero-width match error. Consult pmichaud. 20:29
Coke cotto_work: can you look at RT#56718 and see if that can be folded into the array cleanup tasklist on the wiki?
Austin So then fetch becomes mostly an expression-temporary thing, right?
pmichaud_ but even with that, both NQP and Rakudo (and PAST in general) will benefit hugely from this
20:29 kurahaupo joined
pmichaud_ fetch becomes the correct thing to use for any fetch from an aggregate 20:29
because it provides sane defaulting semantics 20:30
Tene Coke: the status on the latter seems to be "not really a problem".
pmichaud_ and those defaulting semantics are under the control of the caller, not the aggregate
of coure, an aggregate could choose to override that default
Austin That's my point. 20:31
pmichaud_ but that's still more generic/useful than always assigning the task to the aggregate
Coke pmichaud_: ah. is 53978 obsoleted by your recent RFC?
pmichaud_ because there are many times that the aggregate can't know what the default should be, and always returning "Undef" loses information.
Coke ah, not really. but I agree with tene's NR assessment. 20:32
pmichaud_ coke: it's not obseleted at a PAST level, but PAST already makes the distinction
I have to go pick up kids, back in 15
Austin fetch winds up looking like e.g., fetch_pmc_indexed_pmc_default_pmc, aka OP, P, P, P, which is at least 4 opcode_t's. Making fetch the standard way of loading imposes this 25-40% tax on pbc sizes. 20:33
If you tell the array, "hey, return undef instead of null" you get that back, and NQP doesn't lose anything.
japhb Austin, how do you tell the array that? 20:34
And how do you tell it which case to use for something like pmichaud_'s lexpad example, where the default differs on every lookup?
Austin japhb: ResizablePMCArray.new(:default($undef)) 20:35
Coke austin: then you can't tell between undef and null, neh?
Austin Coke: exactly, which is the current semantics.
Coke and what if you create that array and then pass it to me?
austin;and I don't expect that I'm not going to get null... boom.
Austin japhb: You're conflating vivify with fetch.
japhb Austin: PCT is not PIR. I'm OK with PCT limiting my expressive power slightly. But I want the full expressiveness in PIR, because that's the relief valve from PCT. 20:36
Austin Coke: why boom? But more to the point, why not reset it?
japhb Austin, If you have the semantics pmichaud_ and I want for vivify, why not have the same ones for fetch? Why make them different? 20:37
Austin japhb: Because they are different use cases? Because there's this enormous tax associated with doing it that way?
japhb Essentially, you'd be having to both support defaulting in the PMC *and* outside it. Why do that, when always outside is fine? 20:38
But it's an ugly DRY violation to have a very similar thing implemented differently in two different places.
Actually, in N+1 different places,
because *every* aggregate PMC would need to include the ability to remember current default and use it.
Instead of just 1.
Austin japhb: pmichaud has said he's going to get rid of the vivify-variables problem. Which means that fetch is a problem only for aggregates. 20:39
Since it's an aggregate problem, why not let the aggregates solve it?
chromatic Because they can't know how. 20:40
japhb My argument above stands.
Austin chromatic: why can't they? They currently DO know how: return PMCNULL. I just want them to be a little smarter: return self->notfound_return. 20:41
japhb What does notfound_return default to?
Austin PMCNULL, of course. It's compatible with current code. 20:42
japhb OK, let's say you're working in a cross-HLL use case ...
The aggregate is created in language A, which tells it that it's default notfound_return is foo.
Language B always wants bar for it's notfound_return. 20:43
You pass the aggregate from A to B and do a fetch operation. What should be returned?
chromatic Setting a single default works great until you want to store all types of things in a NameSpace, for example, like Perl 5 and 6 do.
japhb How did the aggregate know?
dukeleto kthakore: i got to talk to Olly from SWIG briefly, but I will talk to him more about getting SWIG to talk PIR
Austin japhb: Assuming we're talking about an RPA here, (not some language-specific PMC) I'll say B should tell it: hey, $P0.notfound_return(bar) 20:44
Coke chromatic: this reminds me of $[
japhb Austin, OK, now we're multithreaded. B just changed the aggregate. Now A tries to do a fetch. What does it get? 20:45
Austin It gets a bar, and probably dies. And the developers learns a valuable lesson about multithreading. :)
japhb LOL
This is just one use case to try to explain: the default is *not* an intrinsic property of an aggregate. It is a property of the context (in the general sense) in which you are doing the fetch operation. 20:46
s/not/not necessarily/, because I can imagine the S&M type people wanting to make it intrinsic, and we should let them. But not all use cases are S&M compliant. 20:47
If they want that stricture, they can make a special PMC for it. But we should not impose that on the general case.
Note that pmichaud_ 20:48
's ops do not prevent the PMC from doing it's own defaulting, they just don't force it. They essentially let the PMC say "caller gets to decide defaults"
PMC always knowing its default forces "callee decide" semantics always, with no way to work around that. 20:49
japhb done, I think
pmichaud_ back 20:50
japhb bit of a backscroll for you. :-)
pmichaud_ Austin: I think you're working from an assumption that since NQP tends to default variables to Undef, that should be the default everywhere (more)
chromatic pmichaud_, see nopaste.snit.ch/18438 for tests for the fetch op. If those look useful to you, I'll commit. 20:51
pmichaud_ however, it's important to note that NQP does not always default to Undef. It sometimes defaults to ResizablePMCArray and Hash
More to the point, NQP is not representative of the code, nor even of the code that I write in PIR
an absolutely HUGE amount of code in PGE, PCT, and Rakudo depends on the semantic of a non-existent element returning NULL
all of that could would need to be updated to have separate existence checks
and that would be a pain 20:52
in fact, if you grep for "if null" and "unless null" in the PGE, PCT, and Rakudo code bases, I think you'll find that nearly all of them are doing something *other* than replacing the fetched value with Undef. 20:53
cotto_work msg cotto <Coke> cotto_work: can you look at RT#56718 and see if that can be folded into the array cleanup tasklist on the wiki?
purl Message for cotto stored.
Austin Pmichaud_: Actually, I was working from two related issues: NQP does a lot of redundant vivs for variables, and NQP (I think recently started) does default-undef for aggregate accesses. My statistics show something like 19% of kakapo's LOC were involved in this pattern. 20:54
So I suggested vivify. But you point out, correctly, there are different cases, and it should be fetch and vivify. Okay. And further, per you, vivify is important (above) and the redundant vivs for variables are going away soon. 20:55
IMO, that's going to reduce the "problem" considerably. 20:56
pmichaud_ I agree.
I've been struggling with this problem for some time, but I could never (until today) come up with the opcodes that properly expressed the semantic I was looking for.
Austin So now it's aggregate accesses that require this fetch mojo.
pmichaud_ more to the point, I'm wanting all fetches to be aggregate fetches, instead of the separate get_hll_global/get_global/get_root_global/fetch_lex/get_pmc_keyed mess that we have now. 20:57
Austin Do you think that other aggregates will also need it? (getprop, getfoo?)
pmichaud_ no
for getprop, I can use getprophash and use that with 'fetch'
Austin That sounds like "yes" to me. 20:58
pmichaud_ I don't understand the question then.
I'm probably misunderstanding "it".
Austin If you're thinking of changing how to access properties to get the fetch mojo, then it seems like you think get-prop needs the fetch mojo. 20:59
chromatic You can use fetch on any aggregate.
pmichaud_ fetching currently takes place via the vtable interface
any PMC that supports get_*_keyed_* would be able to be used with the fetch opcode 21:00
I'm not saying we have to eliminate any existing opcode
*opcodes
(chromatic, I'm reviewing tests now)
Austin Right. But what about attributes and property accesses?
pmichaud_ those will likely have to remain separate. 21:01
Austin you can do $foo, $foo[0], $foo<bar>, $foo.member, and some other syntaxes I don't know.
pmichaud_ property accesses won't
but attribute accesses really need separate support, a hash interface isn't completely sufficient
Austin And I'm asking, do you think the property / trait / attribute / whatever accesses will need the defaulting semantics?
pmichaud_ (we could make it sufficient, but I'm not sure that's in the cards)
I don't understand "need defaulting semantics". 21:02
If we want default semantics, use "fetch".
If we don't want defaulting semantics, then use a normal "set" opcode
Austin Right.
pmichaud_ er
getprop or getattribute
Austin So does there need to be a fetch_property $P0, 'name', $Pdefault
pmichaud_ er
no
there absolutely does *not* need to be a fetch_property 21:03
I'm explicitly *not* proposing separate fetch_global, fetch_lex, fetch_* opcodes
I'm proposing two opcodes: "fetch" and "vivify".
I'm not saying fetch and vivify for every type of thing we have.
if I want to use fetch with a property, then the sequence is 21:04
$P1 = getprophash $P0
$P2 = fetch $P1, 'key', default
Austin What about attributes? 21:05
pmichaud_ attributes don't fall into this scheme well, so they remain separate opcodes. That's okay with me.
Austin (Correct me if I have the terminology wrong, but classes specify attributes that their instances have, while any object can have a property, no?) 21:06
pmichaud_ I'd rather have one special case to deal with in PAST than N special cases.
(you're correct)
Austin Should/will object attributes always be initialized to undef? 21:07
pmichaud_ No.
sometimes they're initialized to arrays or hashes
and in rakudo's case, they actually get initialized to protoobjects 21:08
same for lexicals
Austin But they're always initialized?
pmichaud_ in Perl 6, yes.
in NQP, still to be determined.
In other languages, who knows?
Austin :)
But you're leaning toward 'yes'?
pmichaud_ at the moment, yes.
even so, I like the clarity and parallelism that fetch provides 21:09
for example, to fetch from @foo[3]<bar> becomes 21:10
$P0 = fetch lexpad, 3, array
oops
$P0 = fetch lexpad, '@foo', array
Austin s/3/'foo'/?
pmichaud_ $P1 = fetch $P0, 3, hash
$P2 = fetch $P1, 'bar', undef
and if that is an lvalue, it becomes 21:11
$P0 = vivify lexpad, '@foo', array
$P1 = vivify $P0, 3, hash
$P2 = vivify $P1, 'bar', undef
japhb That has the sweet taste of real cream butter.
pmichaud_ note that if the array that is built by fetch lexpad, 3, array defaults to creating non existent elements as undef, then the later operations don't work. 21:12
in other words, if I do
$P0 = find_lex '@foo'
$P1 = $P0[3]
and $P0 gives me back an Undef 21:13
then the next operation
$P2 = $P1['bar']
fails
dalek a: eccb512 | unknown++ | src/lib/complex.pir:
minor improvement (library complex)
pmichaud_ because $P0 didn't know what sort of element to default to
pmichaud_ and if I tell $P0 "you should always give me back a Hash for non-existent elements", that would not be valid Perl semantics 21:14
because both @foo[2][4] and @foo[3]<bar> are valid (i.e., @foo[2] is an Array while @foo[3] is a Hash)
anyway 21:15
if we provide a mechanism for aggregates to automatically create elements for non-existent fetches, I'd probably make use of it. But that would be in addition to the fetch/vivify opcodes, not as a viable replacement for them. 21:16
and in terms of overall efficiency, the two approaches are a wash.
(i.e., they both create the same number of objects)
(and require roughly equivalent numbers of opcodes) 21:17
21:19 hercynium joined
pmichaud_ once again I fear I have written too much and scared everyone away. :-( 21:21
21:21 bacek joined
moritz warnock says hi ;-) 21:22
Austin hi, brian!
pmichaud_ or otherwise made them want to leave.
hercynium wonders if African Grey is a very smart, talkative version of Parrot :) 21:23
pmichaud_ chromatic: the fetch tests look fine to me 21:24
japhb pmichaud_, I've been reading and in total agreement. I just didn't want to sound too much like a cheerleader by chiming in while you were on such a roll. ;-)
chromatic INCOMING.
purl incoming is pause.perl.org/incoming/
japhb hercynium, as a matter of fact, it is.
pmichaud_ also, note that
$P0 = new ['Integer'] 21:25
$P0 = 123
is often easier to read as
$P0 = box 123
A really nice programmer added that for me about a year ago. :-)
Austin The fetch tests as written assume a default object. Shouldn't they take a default type?
pmichaud_ I think default object is more useful.
and we clone that object
japhb certainly more general
Austin Ah, clone. Right. 21:26
pmichaud_ that way we can have something already set up with properties, attributes, etc.
for example: 21:27
$P0 = box 'xyz'
dalek rrot: r42050 | chromatic++ | trunk (2 files):
[ops] Added experimental fetch ops and tests.
pmichaud_ $P1 = fetch $P2, key, $P0 # returns 'xyz' if $P2[key] non-existent
chromatic IRC message overlap makes me appreciate atomicity in a way that CS theoretical discussions of ACID never do.
pmichaud_ in fact, I wish I had set PAST up to assume default object to be cloned instead of type 21:28
Austin It's not too late to change it. :)
pmichaud_ from a deprecation perspective it is. :0| 21:29
I'm likely to just add a new attribute instead of :viviself, it would mean "clone this value"
Austin Ahh.
pmichaud_ for backwards compatibility we'll still support viviself, but NQP would switch to the new value
Austin So how do you handle default objects? Declare them .localpmc at the top of the sub
? 21:30
pmichaud_ sure
or .const
simple is to do something like 21:31
.local pmc undef
undef = get_hll_global ['Private'], 'undef'
I thought about saying that one could specify a type key as the final argument to mean "create a new object of this type", but that overloads the semantic a bit too much 21:33
for example: $P0 = fetch $P1, key, ['Undef']
but since there's discussion that ['Undef'] may end up being a constant ResizableStringArray, I'm not sure I want to make that special-case 21:34
japhb That looks like a premature optimization that turned out to be a pessimization. 21:36
(Meaning I agree that looks like a bad idea) 21:37
chromatic Hmm: dragonegg.llvm.org/
pmichaud_ well, it would be nice to have a way to say "default to an object of this type" without having to initialize a register for it at the top of a sub 21:38
and in nqp's case (no runtime), I'm not sure where I'd stick the default object type 21:39
chromatic From LLVM 2.6 release notes: When "libffi" is available, the LLVM interpreter now uses it, which supports calling almost arbitrary external (natively compiled) functions.
Austin What are the limitations of .const in this regard? 21:41
Can I create a .const RPA pmc?
pmichaud_ yes, but it's not pretty
essentially
.const pmc rpa = 'foo'
.sub 'foo' :immediate 21:42
$P0 = new ['ResizablePMArray']
.return ($P0)
.end
Austin So is that how to handle hash and array defaults?
pmichaud_ NQP could certainly put that prelude at the beginning of code it generates
Austin And then the .const symbol is visible in what scope? globally, or per-sub? 21:43
pmichaud_ file scope
it's visible to the compilation unit
Coke chromatic: EBREAKMANIFEST
Austin Okay. So it applies throughout. 21:44
Coke pmichaud_: there is a ticket that suggests we can collapse all docs regarding compilation unit back to "sub", but they ain't the same thing.
(as you point out.)
pmichaud_ Coke: the original meaning of "compilation unit" in the docs was "sub" 21:45
i.e., the PIR compiler(s) (PASM/IMCC) considered a sub to be a compilation unit, and a file containing multiple subs had multiple compilation units. 21:46
or something like that.
anyway, it didn't fit the with the traditional notion of "compilation unit" as I'm used to the term :)
dalek kudo: 501b4fb | (Kyle Hasselbacher)++ | t/spectest.data:
[spectest.data] moved my misplaced test
rrot: r42051 | chromatic++ | trunk/MANIFEST:
Updated MANIFEST, which I forgot to do in r42050.
pmichaud_ (not disagreeing with anyone or anything here -- just pointing out that the term has been muddled over time and we ought to clean it up at some point :)
ttbot Parrot trunk/ r42037 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/119812.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 21:50
Parrot trunk/ r42050 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/119817.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
Parrot trunk/ r42051 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/119878.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 21:57
Austin nopaste 21:59
nopaste?
purl it has been said that nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
Austin Should poundperl be poundparrot? 22:00
poundparrot.pastebin.com/m70fa4b3 22:01
Pmichaud, the 'contains' method here is a naive rewrite of code shown, but it doesn't include vivify. 22:02
Would vivify still require .lex?
22:02 colomon joined
pmichaud_ yes, .lex is still needed -- that's what creates the lexicals in the first place 22:03
kthakore dukeleto: great!
dalek a: 4f26945 | unknown++ | t/lua-TestMore:
update submodule lua-TestMore
 22:04
pmichaud_ Austin: I don't quite understand the point of the code.
you're saying this is what it would end up being? 22:05
bacek o hai
Austin pmichaud: The code is (a) scaffolding that would be generated to support viv/fetch, and (b) a trivial nqp function shown at line 34: method contains($what) { return Array::contains($what); }
mikehh howdy bacek 22:06
bacek mikehh: good-good.
dalek rrot: r42052 | bacek++ | trunk/t/pmc/callsignaturereturns.t:
[t] Add stub test for CallSignatureReturns.
 22:07
Austin (Except I elided the exception handling)
mikehh dat's what I was going to ask you about - ;} 22:08
pmichaud_ I'm thinking that the .consts would actually end up being lookups
bacek mikehh: :)
Austin Is NQP (gonna be soon) smart enough to know that $what is vivified?
pmichaud_ nqp-rx will know, yes.
mikehh maybe that should be ;_]
Austin Or is $what untrusted because it's a param?
Lookups of what? 22:10
pmichaud_ .local pmc defsub
Austin Hmm. Why? 22:11
pmichaud_ defsub = get_hll_global ['_nqp'], 'defsub'
so that they're all clones of the same object instead of cloning different things from different compilation units
I agree that part isn't so well thought-out yet
Austin Hmm. I think the .const way can do the same thing, if you're willing to put _nqp::defsub in a library. 22:12
pmichaud_ except that .const has to link to a symbol in the current compilation unit, I think. 22:13
i.e., it doesn't handle external linking.
Austin That really should get an opcode, BTW. The current behavior (PMCNULL.invoke()) isn't friendly towards recovery/debugging/overriding. 22:14
pmichaud_ agreed. 22:15
Austin I was thinking the .const would link to a trampoline that made the external call.
pmichaud_ I don't think .const does that sort of thing.
here's my version
Austin Why not? .const wants a local sub, this is a local sub. 22:16
It's just a sub that dispatches somewhere else.
chromatic bacek, if we fixed CallSig's get_pmc() to figure out the type tuple *without* going through the short_sig, we could get rid of STRING manipulations when building the CallSig. ~4-6% improvement there.
Austin But do the .const subs have to live in the same nsp as the code?
pmichaud_ they have to live in the same compilation unit. 22:17
bacek chromatic: but we still need short_sig for MMD, isn't it?
pmichaud_ the :immediate flag causes them to be executed at compilation time, and replaced in the bytecode by whatever the sub returns as a result
bacek chromatic: and we have to rebuild it for :flat args... 22:18
pmichaud_ i.e., .const pmc array = 'default_array' doesn't mean that array points to a sub, it actually points to a ResizablePMCArray stored in the bytecode
it's not a trampoline effect
put another way, if I did
$S0 = typeof array
say $S0
then I'd get back "ResizablePMCArray", not "Sub"
(I didn't design this system, fwiw) 22:19
chromatic bacek, that's the only spot we use it in MMD.
pmichaud_ hmmm, no pastebot 22:20
nopaste.snit.ch/18439
chromatic I don't think named arguents participate in MMD either.
bacek chromatic: if they are not than we can build short_sig lazily 22:22
pmichaud_ I'm missing a .returns ($P25) at the end of nopaste #18439
ttbot Parrot trunk/ r42052 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/120042.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 22:23
Austin Actually, I put it on pastebin so you could edit it. :)
pmichaud_ an optimizer would be able to figure out that we don't need the separate fetches for $what and self, but I'm showing what would be generated for unoptimized code
chromatic I think we can too. I don't see where we use it in the code now, bacek.
pmichaud_ this version looks pretty darn efficient, though. 22:24
Austin Should subs have a predefined 'lexpad' symbol, a la 'self', to support viv?
pmichaud_ wouldn't hurt, but it can't be the actual LexPad PMC 22:25
it has to be something else that knows how to search outer scopes
and tbh, I'd like a PMC that can also search the dynamic scopes as well
that's why I used "LexSearchPad" here
Austin Yeah.
pmichaud_ optimally, somethin glike:
Austin Should that be a lexpad replacement?
pmichaud_ probably not 22:26
LexPads are more than just hashes.
(and yet not as much as a hash)
LexPads actually map symbols to registers, instead of mapping symbols to PMCs
Austin Right. 22:27
pmichaud_ I'm thinking:
$P0 = new ['LexSearch']
assign $P0, .LEX_SEARCH_DYNAMIC
or
$P0 = new ['LexSearch']
22:27 Whiteknight joined
pmichaud_ assign $P0, .LEX_SEARCH_OUTER # this is the default 22:27
and even the possibility of
bacek chromatic: Parrot_mmd_build_type_tuple_from_sig_obj 22:28
pmichaud_ $P0 = new ['LexSearch']
assign $P0, .LEX_SEARCH_BOTH
chromatic Called only from CallSig's get_pmc.
Austin Is there enough information available in that call? (Can LexSearch find the right lexpad, etc.?)
pmichaud_ sure
it just needs to capture the current context 22:29
the context knows all of the references to its current lexpad, its caller context, and outer context
Austin Okay.
pmichaud_ but it might also be nice if LexSearch (possibly renamed) could search package and global scopes as well :-) 22:30
Austin So is the LexSearch pmc the base pmc for (chains of) vivify ops?
pmichaud_ yes
Austin vivify $P0, '$what', defscalar
pmichaud_ $P0 = vivify lexpad, '$what', defscalar
bacek chromatic: hmm. Let me try couple of ideas.
pmichaud_ the lexpad PMC looks through the appropriate scopes for a symbol called '$what', then does the correct thing with that. 22:31
Austin So it's get.*global, or new LexSearch, or get_namespace, then viv or fetch
pmichaud_ yes, but only one LexSearch for the entire sub
Austin Sure.
pmichaud_ and it's just LexSearch or get_namespace
I don't think we need a get.*global 22:32
Austin Right, because you're going to viv those, too.
pmichaud_ well, they get viv'd by get_namespace, iirc
either that or we use make_namespace 22:33
(which is the viv form of get_namespace
Austin I was thinking of the symbols themselves, not hte namespaces.
*the
pmichaud_ right
for that it's just
$P0 = get_namespace ['NS']
bacek chromatic: looks like we should do other way around: build "native signature" from string. To support unified calls from ops and C.
pmichaud_ $P1 = vivify $P0, 'key', default 22:34
Austin okay.
chromatic I'm trying to get away from building a STRING we rarely use and can rebuild when we need it anyway.
pmichaud_ and "current namespace" can be fetched at the top of the sub, same as lexpad.
Austin Another opcode, or two, there: get_[namespace, lexpad] 22:35
pmichaud_ we already have the get_namespace opcode
I don't think we need a get_lexpad opcode, when we can just use new ['LexSomething']
Austin Right, because of the search. 22:36
So we need a set of lexsearch pmcs (lexical scope, caller-dynamic, caller-lexical-dynamic scope)
pmichaud_ it does somewhat make me wish we could use sentinels
one lexsearch PMC could do it
oh, I see what you're saying. 22:37
yes, a set per scope.
actually, I'm wondering if sentinels might be the way to go here
Austin Sentinels?
purl Sentinels are 65
pmichaud_ something like this:
$P0 = fetch .FETCH_LEXICAL, 'key', default
$P0 = fetch .FETCH_LEXICAL_DYNAMIC, 'key', default
$P0 = fetch .FETCH_NAMESPACE, 'key', default 22:38
$P0 = fetch $P0, 'key', default
am I missing any others?
the first three take integers as the first argument 22:39
those integers indicate the fetch
maybe .FETCH_HLL_NAMESPACE and .FETCH_ROOT_NAMESPACE too
probably less likely
*although*
what would be really nice is
Austin Nah, those work.
pmichaud_ .FETCH_HLL_PRIVATE
to provide easy access into the private HLL namespace 22:40
I'm coming up with a few places where that would be very helpful to have
Austin Yeah, that _hll namespace has always been kind of a red-headed stepchild. 22:41
dukeleto i just learned from some postgres folks that they are interested in embedding parrot. has anybody heard about this? 22:42
chromatic Yes.
dukeleto chromatic: other than josh berkus's questions at OSBridge? do you know who is actively working on it?
Austin Hey, will nqp-rx have //=? 22:43
or something like it?
pmichaud_ it'll have // 22:44
chromatic I don't know anyone actively working on it, no.
pmichaud_ we don't have assignops, because at the moment we only support binding
(because parrot's assign opcodes are all screwed up too.) 22:45
Austin s'ok, // is enough
Yeah, I noticed that.
dukeleto chromatic: ok. i will talk to some postgres peeps at the gsoc conference. I think they just hit some roadblocks that they couldn't figure out
darbelo dukeleto: Sounds like a real stress test of the embedding interface. Getting them to drop by here will probably help us as much as it helps them. 22:46
chromatic Seconded.
pmichaud_ (private hll namespace) well, I suspect most compiler writers will want their compiler to live in the private hll namespace, instead of the normal runtime namespace
darbelo I don't think any recent (-ish) parrot has been successfully embedded into a real application. 22:47
pmichaud_ oooh, if we have the constant forms of fetch, then our defaults can be
.local pmc defscalar, defarray, defhash, defcode 22:48
defscalar = fetch .FETCH_HLL_NAMESPACE, 'scalar', defnull
defscalar = fetch .FETCH_HLL_NAMESPACE, 'array', defnull
er,
defarray = fetch .FETCH_HLL_NAMESPACE, 'array', defnull
argggh 22:49
can't type
purl that would be tkil.
pmichaud_ null defnull
defscalar = fetch .FETCH_HLL_PRIVATE, 'scalar', defnull
dalek rrot: r42053 | bacek++ | trunk/src/call/args.c:
[core] Poke into CallSignature directly in Parrot_pcc_merge_signature_for_tailcall
pmichaud_ defarray = fetch .FETCH_HLL_PRIVATE, 'array', defnull
pmichaud_ defhash = fetch .FETCH_HLL_PRIVATE, 'hash', defnull
i.e., it's up to the outer HLL to set up the scalar/array/hash defaults it would like the code to use. 22:50
dukeleto darbelo: do you know why the embeddings haven't worked?
darbelo dukeleto: Lack of embedders. 22:51
We don't have people in here bitching at us that our interfaces suck or got broken by release 'X' 22:52
Which means we don't know whe we screw up, which means we can fix the screw-ups.
dalek rrot: r42054 | bacek++ | trunk (2 files):
[core] Update guards in Parrot_pcc_merge_signature_for_tailcall. We test argument for nullness inside
pmichaud_ bah 22:53
what I really want to have are predefined values for fetch
.FETCH_LEXICAL
.FETCH_LEXICAL_DYNAMIC
.FETCH_NAMESPACE
and
darbelo dukeleto: The poster child there was mod_parrot. Latest release: January 2009.
pmichaud_ .FETCH_ARRAY # create an instance of the HLL-mapped array type
.FETCH_SCALAR # create an instance of the HLL-mapped scalar type 22:54
nopaste "fperrad" at 77.194.156.254 pasted "[BUG] FLAT returns into SLURPY results" (27 lines) at nopaste.snit.ch/18440
pmichaud_ .FETCH_HASH # create an instance of the HLL-mapped hash type
so that one can do:
$P0 = vivify .FETCH_LEXICAL, '%hash', .FETCH_HASH
chromatic Padre embeds Parrot too. 22:55
dukeleto chromatic: successfully?
pmichaud_ all of which starts to sound a lot like vivify_lex, vivify_namespace, vivify_*, etc.
fperrad msg bacek, I isolate a problem with r42039, see nopaste.snit.ch/18440
purl Sorry, I've never seen bacek, before.
darbelo Oh. I didn't know that.
bacek fperrad: looking 22:56
Austin pmichaud: don't forget LEXICAL_DYNAMIC_CALLER 22:57
pmichaud_ DYNAMIC is "CALLER"
Austin sure, it's vivify_lex. It's a macro.
pmichaud_ the point being more that there's not a lot of difference between having multiple vivify_* opcodes and a vivify opcode that changes behavior based on the value of its first param 22:58
Austin I noticed that there is no store_lex for one of the dynamic modes.
pmichaud_ find_caller_lex ought to be deprecatd
which is why there's no store_caller_lex 22:59
Austin I was wondering if someone could point to two languages that used the two modes.
pmichaud_ find_caller_lex was based on an imprecise Perl 6 definition
Austin ah
pmichaud_ find_dynamic_lex and store_dynamic_lex are based on the correct definition. I couldn't re-use "find_caller_lex" because of the deprecation policy.
ttbot Parrot trunk/ r42054 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/120179.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
pmichaud_ compiler writers (writing in NQP) will definitely want both the static and dynamic modes available. 23:00
dukeleto fperrad: your msg to bacek didn't work because you had a trailing comma
pmichaud_ so, Perl 6 and NQP.
darbelo dukeleto: search.cpan.org/~szabgab/Padre-Plug...rrot-0.26/
pmichaud_ (not a fair "two languages", I admit)
Austin NQP doesn't use any of the dynamic modes, does it? 23:01
It's purely lexical.
pmichaud_ the old one doesn't, because they weren't available.
the new one definitely does, and it depends on them.
contextual variables are incredibly useful for writing compilers.
fperrad dukeleto, thanks
Austin Okay. 23:02
Here's one: what's the right code for a variable definition?
pmichaud_ in any discussion of lexicals in parrot, keep in mind that lexicals were basically broken in Parrot until a year ago.
(literally "less than twelve months ago")
Austin :) 23:03
pmichaud_ so NQP is older than working lexicals by about a year. :)
Austin Do you just do $P1 = viv_lex '$foo', undef and forget $P1?
pmichaud_ probably
.lex '$foo', $P1 23:04
$P2 = vivify .LEXICAL, '$foo', undef
(could be viv_lex... still need to think about that a bit.)
Austin nah, call it vivify_lex
I'm just lazy
pmichaud_ I was trying to avoid the opcode explosion 23:05
Austin :)
What's an opcode?
purl hmmm... an opcode is not dual lived
japhb FWIW, I'd prefer different opcodes rather than single opcode with implicit switch-on-first-arg.
pmichaud_ japhb: with both fetch_* and vivify_* variants?
japhb pmichaud_, yes.
Austin I think he means instead of fetch .LEX
having fetch_lex
pmichaud_ right
japhb yup
pmichaud_ so, we'd need
$P1 = fetch $P0, 'key', default 23:06
Austin But "opcode" means two things. It means "identifier that humans type", and "concept" and "contents of an opcode_t"
pmichaud_ $P1 = fetch_lex 'key', default
$P1 = fetch_lex_dynamic, 'key', default
I'd be willing to live with those.
Austin Can we make "_lex_dynamic" be "_dynamic"
?
pmichaud_ I'm fine with that also, but I expect most of this to be generated code anyway. 23:07
Austin Sure.
pmichaud_ I chose lex_dynamic to make it clear that we're dealing with lexicals.
Austin And then 9 flavors of fetch.
pmichaud_ _dynamic by itself is a little less certain.
9 flavors?
japhb So six new ops. <lvalue rvalue> X <generic_aggregate lex dynamic>
Austin keyed_int, keyed_str, keyed_num, keyed_pmc, keyed_phase_of_the_moon, keyed_were_there_wmds_in_iraq, etc, etc, 23:08
pmichaud_ <fetch vivify> X <generic lex dynamic> X <keyed_pmc keyed_int keyed_str>
Austin I'm still liking the namespace stuff as well.
pmichaud_ namespace is much less common in code 23:09
japhb 18
Austin What, no num?
pmichaud_ we don't key on num
Austin Aren't NQP expressions num ?
pmichaud_ only int, str, and pmc
Parrot doesn't key on num, only int, str, and pmc
Austin Oksu.
yikes
Okay..
japhb 18 is within my personal limits for reasonable. 23:10
Austin fetch_private, fetch_root, fetch_hll, fetch_namespace?
pmichaud_ anyway, namespace lookups are much less common in code, so I don't mind requiring the explicit namespace lookup and then the generic aggregate fetch/vivify
instead of adding another n X 3 x 3 opcode variants 23:11
Austin I thought you had a bunch of use cases for fetching private?
pmichaud_ I have places where it's starting to look useful 23:12
but I tend to think in terms of "what does PAST need" as opposed to "what opcodes do I need"
not every operation needs its own opcode
we should have opcodes for the common ones, and uncommon ones can be put together from other opcodes
fetching private can be useful but isn't nearly enough to warrant its own opcode at present 23:13
it's just as easy for me to fetch the private namespace at the beginning of the sub and use that
Austin So fetch_symbol seems like a good one, then.
pmichaud_ ?
Austin OR fetch_global
I guess.
pmichaud_ for _global, that's the same as namespaces
Austin Symbol from current nsp
pmichaud_ symbol from current nsp still not very common, and easy to optimize 23:14
Austin Not very common?
pmichaud_ in fact, in general
fetch from current namespace only common with "our" variables
those are relatively rare
Austin And subs.
23:15 plobsing joined
pmichaud_ actually, sub lookups don't use fetch at all 23:15
unless you're wanting to get a handle to the sub directly
Austin But then we cross the line into "find_sub_not_null" or whatever it's called.
pmichaud_ but even then, Perl 6 has changed the spec so that subs default to lexical scope instead of package scope
I haven't decided if I'll mimic that in NQP yet
my current inclination is that NQP should default subs to lexical scope also. 23:16
either way, sub invocation doesn't use the fetch/vivify interface.
bacek fperrad: fixed in r42055
Austin What's with subs being lexical? 23:17
pmichaud_ most things in P6 now default to being lexical scope
Austin Okay.
pmichaud_ much better control of namespaces, and more ability to optimize properly at compile-time
Austin Why not make sub lookups, at least non-local ones, use fetch? It's probably a lot easier to set a breakpoint in "_hll::defaultsub." 23:18
fperrad bacek, thanks, time to sleep for me
pmichaud_ well, Foo::sub would still likely use fetch, yes.
because we have to get the symbol from the namespace
Austin So I can't say "Othernamespace::foo" anymore?
bacek fperrad: good night! And thanks for kicking some lazy developers :)
pmichaud_ sure, that works, as long as foo was declared "our"
Austin our sub foo() {} ?
dalek rrot: r42055 | bacek++ | trunk (2 files):
[core] Skip empty aggregates during flattening results
 23:19
pmichaud_ yes
Austin public sub foo() {}
pmichaud_ P6 has always had the ability to do "my sub foo() ... " and "our sub foo() ..." -- the only difference is that the scope now defaults to "my" when there's no scope declarator present
davidfetter dukeleto, i'm here a lot ;) 23:20
pmichaud_ where previously it defaulted to "our" 23:21
the switch from "our" to "my" also means that we can heavily optimize the capture_lex rules
Austin I gather chromatic is working on fetch?
Well, that's a relief.
pmichaud_ it also avoids a lot of the "I'm calling sub xyz when I haven't even entered its scope yet!" sorts of problems 23:22
dukeleto davidfetter: oh, there you are :)
pmichaud_ for example:
chromatic I committed fetch earlier.
pmichaud_ foo(); { my $x = 'xyz'; our sub foo() { say $x; } } 23:23
Austin chromatic++
Got vivify, too?
chromatic I'm not sure how vivify should work yet.
Austin (backscroll)
pmichaud_ chromatic: based on discussion here, do you still feel we'd be better with a custom lexical lookup pmc instead of fetch_lex ? 23:24
discussion here seems to lean towards fetch_lex and vivify_lex
chromatic I didn't follow the discussion closely enough to feel strongly about it.
pmichaud_ okay.
and I'd _really_ like a way to specify something in that last parameter that says "use the HLL mapped type" 23:25
e.g. $P0 = vivify_lex '@foo', .ARRAY
Austin I think the preference for fetch_lex was over fetch .LEXICAL. But fetch $P0, etc, where $P0 is a lexsearch object probably works best of all.
pmichaud_ the downside of $P0 as a lexsearch object is that we're creating lexsearch objects
a new one for every context. 23:26
Austin Wouldn't those be .const?
pmichaud_ no
because each object has to be tied to its context
Austin Oh, right, closures.
Yeah.
But wait.
If the lexsearch did the lookup at runtime, that would be okay. 23:27
(calltime, rather)
pmichaud_ we could certainly have a singleton that says ... right
but that gets to the same issue of "how do I specify singletons"?
ttbot Parrot trunk/ r42055 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/120279.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
pmichaud_ then lexsearch is just another case of also wanting to have a way to say defscalar, defhash, defarray, etc.
I'd prefer not to create opcodes for each case 23:28
although, we could query the interpreter for mapping information
$P0 = getinterp
Austin Still a .const 23:29
pmichaud_ right, but it's runtime lookups
Austin For defscalar?
pmichaud_ yes.
I don't see how to avoid that.
Austin Why? Hll emits the code, hll knows the type.
japhb Work that can be shared across multiple ops should not be folded into the op itself. It should be done in separate ops.
Austin .const pmc defscalar = ... 23:30
pmichaud_ Austin: I don't see how to get the .const initialized with the type
japhb Meaning, a sequence of ops.
pmichaud_ _unless_ you want the header code to appear in every .PIR output
but then we have a problem that each compiled PIR code is actually initializing from a different object
Austin Cloning a different object, you mean?
pmichaud_ we also don't provide the HLL with a way to say "hey, you really should use something different" short of re-generating the PIR
short answer: I don't see how to make it work with .const 23:31
Austin When would the hll want to say that?
pmichaud_ short answer: I don't see how to make defscalar work with .const
dukeleto davidfetter: in here?
purl in here are you *joking*?
pmichaud_ I don't think that NQP or any code generator should be putting :immediate subs at the beginning of the code it generates, because then each module (even those from the same HLL) all end up with different default objects they're cloning from 23:32
Austin So every sub starts up with fetching the defscalar from the private namespace?
Or fetch needs to do it. 23:33
And viv.
pmichaud_ or we need a way to be able to get at the type mapper easily.
Austin Or we pass it a string! :-$ 23:34
pmichaud_ strings bad.
if for no other reason than a string can't be our default object :)
japhb You know, having the ability to specify the type mapper as your default isn't a bad idea. Basically a level of indirection that allows you to delay fetching the clonable defaults if you don't use them. 23:35
pmichaud_ japhb: "Work that can be shared across..." That's effectively what we have now.
the situation we're in now is that we handle fetch and vivification as a sequence of opcodes 23:36
Austin so $P0 = new [ 'NameLookup'; 'Lexical' ] ; $P1 = defscalar() ; $P2 = fetch $P0, '$foo', $P1
pmichaud_ I definitely don't want a subroutine call at the beginning of every sub invocation 23:37
that's taking one pcc call and turning it into two. :-|
japhb pmichaud_, but my point was that the sequence being replaced with your original fetch and vivify proposal did not contain subparts that could be shared amongst multiple fetch or vivify operations. Some of the more recent variations have broken that, and have some fetch and vivify becoming big enough that they would contain redundant subparts. 23:38
Austin What about a PMC type that handles the clone call by looking up its sentinel?
pmichaud_ Austin: we'd still need a way to get to that PMC
dalek rrot: r42056 | bacek++ | trunk/src/call/args.c:
[cage][core] Remove unused string_sig in Parrot_pcc_build_sig_object_returns_from_op
Austin Sort of the reverse of the smart undef.
Sure: $P0 = new 'CloningTypeMapper'; $P0 = .ARRAY ; ... 23:39
pmichaud_ if we're doing a new, we can shortcut that altogether with
$P0 = new ['Array']
and get_*_global is cheaper than new anyway
Austin For some type-mapped value of array, no?
pmichaud_ we don't need type mapping in the 'new' case -- as you said, the HLL knows its own types 23:40
(yes, I'm moving in circles a bit here. I don't see the right answer yet.)
Austin Until it wants to change them.
pmichaud_ oh, the other problem with the .const form is that it only works for Parrot built-in PMCs 23:41
one can't .const a dynpmc
Austin Even when the dynpmc is loaded?
pmichaud_ (at least, not yet.)
even when it's loaded.
Austin Whoops.
So those hlls would have to do it differently. 23:42
pmichaud_ technically, Parrot expects all hlls to create its own PMC types
s/its/their/
Austin right
Speaking of which, what is an 'Array' ?
pmichaud_ you mean Parrot's Array PMC? 23:43
Austin I thought it was an abstract base for [RF]*A, but apparently not.
Yea.
pmichaud_ It's not very useful. I think it's primarily an early attempt at arrays. Or perhaps it's only used in very special situations.
Whiteknight I wanted to delete Array, but found no support 23:44
Austin Me, too. But I think F*A might derive from it.
Whiteknight I don't think it does
darbelo: ping
23:45 Zak joined
pmichaud_ japhb: the sequence being generated by my original fetch/vivify proposal could certainly be done as a shared sequence of smaller ops 23:46
essentially the sequence would just be the sequence for any keyed aggregate, same as it is now
nopaste "bacek" at 114.73.162.96 pasted "chromatic, we really can avoid building string_sig" (36 lines) at nopaste.snit.ch/18441
bacek chromatic: With nopasted patch make coretest passed. 23:47
pmichaud_ fetch and vivify are really just a way to reduce the number of opcodes generated in the output, they don't add any capability we're currently missing.
the fact that PAST sometimes generates different sequences is because PAST knows more optimal forms of fetch and vivify
Whiteknight dukeleto: ping 23:48
pmichaud_ in fact, if we simply replaced the current
$P0 = new ['Undef']
with
$P0 = clone undef
japhb pmichaud_, perhaps we are talking across each other. I meant, if you have two lines of source, one using '@foo[3]<bar>' and the other '@foo[2]<baz>', is there a more efficient sequence than just two sets of 'fetch' ops?
pmichaud_ japhb: depends on how one defines efficiency
if using the fetch ops means that I first have to set up a number of other pmcs in order to use them, it may be a false efficiency 23:49
dalek rrot-linear-algebra: 7b0fb53 | Whiteknight++ | CREDITS:
Add a CREDITS file
rrot-linear-algebra: 765995b | Whiteknight++ | README:
add a note referencing CREDITS to README
japhb Is there work that is semantically duplicated between the two sets of fetch sequences?
pmichaud_ I don't understand the question.
japhb pmichaud_, sorry, let me try again. My flu-addled brain seems to be failing me. 23:50
pmichaud_ np
japhb I'm imagining seeing through the sequence of ops to the underlying implementation. Unwrapping the PIR all the way down to machine operations, if you will. 23:51
If we take an op like 'fetch .SENTINEL, key, .OTHER_SENTINEL', the underlying op is having to look up those two sentinels in some way to figure out what it is really supposed to do. 23:52
dukeleto Whiteknight: i didn't do it
Whiteknight: wazzup?
japhb but if you have a sequence of several of those ops, the underlying op implementation has to do that sentinel lookup over and over. 23:53
ttbot Parrot trunk/ r42056 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/120367.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
Whiteknight dukeleto: I'm breaking ground on a 2D matrix PMC, and I'm trying to figure out the best way to do indexing
japhb Those lookups can be moved out of the fetch opcode into their own pir-visible ops,
Whiteknight VTABLEs obviously only support a single index, except the ones that take a Key pmc
japhb with the fetch opcode taking the *result* of those lookups, not the sentinel values.
Whiteknight and obviously I want an interface that isn't too expensive
japhb So when I write my matrix algebra code in PIR, 23:54
pmichaud_ the "lookup the sentinels" is actually fairly cheap
that said, I see your point.
japhb I don't end up forcing the VM to do dozens of implicit lookups.
Ah, good, I managed to form a coherent thought!
(and there was much rejoicing)
dukeleto Whiteknight: very, very interesting
pmichaud_ i.e., I think you're saying that fetch_lex is quicker than fetch .LEXICAL because we save the check for .LEXICAL
japhb pmichaud_, yes 23:55
pmichaud_ I have no problem with that. (more)
japhb which when you do it just once, doesn't matter. It's doing it multiple times per sub that there is a difference.
Whiteknight dukeleto: I was thinking about using a flat array PMC with a thin PIR wrapper class to precalculate offsets
dukeleto Whiteknight: if you want to optimize for performance, we can get by with only 1 index.
Whiteknight but that would still require method calls
So I'm thinking about using a flat array internally, keyed PMC lookup for most access, but an optimized lookup internally 23:56
pmichaud_ however, in the case of fetch_hll_global, it's likely cheaper to look up the namespace once at the beginning of the sub and re-use it for normal "fetch" opcodes thereafter, than to have a specialized fetch_hll_global opcode look it up on each execution.
japhb pmichaud_, yes, and that's the other half of what I was trying to say. 23:57
just like 'fetch .SENTINEL', fetch_hll_global is again doing extra work on every op that you want to share across the sub. 23:58
I was trying to say that a rule of thumb is that ops should not contain redundant implicit work.
(As a way to help decide which ops we want and don't.) 23:59
pmichaud_ okay, I can agree to that, I think.

Powered by Cro and the Raku® Programming Language.

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

Thank you!