Camelia, the Perl 6 bug

IRC log for #parrot, 2009-10-23

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 japhb Austin, well, in the older Playstations, at least.
00:01 japhb But yes, I think we've got good enough evidence to presume at least .c.o style rules work, until proven otherwise.
00:06 darbelo joined #parrot
00:11 mikehh trunk - pre/post-config, smoke (#29318) PASS, fulltest FAIL at r42027 - Ubuntu 9.10 (beta updated) amd64
00:11 mikehh t/op/annotate-old.t -  Failed test:  1 - in testf and testg (TT #1135)
00:11 mikehh t/pmc/threads.t - Failed tests:  8-9 - in testr
00:11 mikehh the rest of fulltest passes
00:14 Whiteknight Tene: I welcome all comments on my blog. I doubt you'll convince me to give vim yet another try
00:16 hercynium joined #parrot
00:18 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:19 chromatic Hm, that doesn't make sense to me.  It takes a const char * and returns a char *.  Can you nopaste the error?
00:20 dukeleto left #parrot
00:21 dukeleto joined #parrot
00:21 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 Topic for #parrotis now Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply merge
00:22 dalek parrot-plumage: 61aa506 | japhb++ | :
00:22 dalek parrot-plumage: [CORE] Move metadata functions out to lib/Metadata.nqp; update .gitignor...
00:22 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/61aa5067a8a0f4c08a3a14604257bbd35659a9a0
00:22 dalek parrot-plumage: 381889e | japhb++ | :
00:22 dalek parrot-plumage: [CORE] Metadata.nqp: Add POD and SYNOPSIS for functions
00:22 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/381889e4d40f5293a5dc893f0e40d9df19152fa8
00:24 zerhash joined #parrot
00:26 Coke I remember using vi on an actual mainframe.
00:26 Coke <-- old fart.
00:26 dukeleto Austin: i will try to get on the merge request you sent me
00:26 dukeleto Coke: !
00:27 Austin dukeleto: I think japhb already got it.
00:27 japhb yup
00:28 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 http://nopaste.snit.ch/18423
00:29 japhb Earliest processor I coded for was the Zilog Z80, on a 64K CP/M system.
00:29 japhb I think that nowadays qualifies me as "oldish"
00:30 darbelo Or a retrocomputer.
00:30 kid51 plobsing ping
00:31 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.
00:31 dukeleto japhb: i prefer the term 'old skool'
00:31 Whiteknight ...and Parrot has :call_sig
00:31 Whiteknight (well, a partial implementation of it
00:31 darbelo Whiteknight++
00:31 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.
00:32 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?
00:32 plobsing kid51: pong
00:33 dalek parrot: r42028 | whiteknight++ | trunk (10 files):
00:33 cotto_work still, Whiteknight++
00:33 dalek parrot: [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 kid51 plobsing:  I tried out your codingstd_outdent.patch
00:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42028/
00:33 cotto_work and dalek agrees
00:33 kid51 It doesn't clear up the c_indent.t failures in the branch.
00:34 kid51 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.  :-)
00:34 plobsing oops, retesting now
00:34 * mikehh anyway that's enough for me at the moment - must sleep - bbl
00:34 kid51 Since it's not directly tied to libjit, I'd like to recommend that you submit it in a separate TT
00:35 kid51 I don't know the ins and outs of the c_indent coding standard myself
00:35 kid51 So I don't know whether your version represents the standard better than the current one or not.
00:35 kid51 In any case, I think it's best handled in a separate ticket.
00:36 plobsing i thought so.
00:36 plobsing wasn't sure though
00:37 plobsing 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
00:37 kid51 but I'm going to be afk for several days
00:38 plobsing ok, thanks.
00:40 plobsing 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 plobsing anythinig else?
00:40 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 ?
00:40 ttbot Parrot trunk/ r42028 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/119234.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
00:40 plobsing because they check for W^X
00:40 plobsing which is handled by libjit
00:40 chromatic I used CP/M briefly.
00:41 kid51 and the additions to lib/Parrot/Distribution.pm were for ... ?
00:41 plobsing skip generated files.
00:41 plobsing because otherwise macros in the templates conflict with macros in the generated files
00:42 plobsing the assumption being that if the template files conform, the generated files conform.
00:43 chromatic mikehh, what if you prepend 'const ' to line 2790?
00:43 chromatic You may have to remove line 2803, but that's doable too.
00:44 kid51 testing config_fixup.patch in branch
00:45 kid51 pre-config tests, Configure and post-config tests good
00:48 cotto_work coverage?
00:48 purl coverage is, like, http://cv.perl6.cz
00:49 dalek parrot: r42029 | whiteknight++ | trunk/src/call/args.c:
00:49 dalek parrot: [pcc] remove debugging message from previous commit
00:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42029/
00:50 cotto_work of interest to anyone wanting to increase CallSignature coverage: http://tapir2.ro.vutbr.cz/cover/cover-results​/42023/c_cover/src-pmc-callsignature-pmc.html
00:51 kurahaupo joined #parrot
00:51 dalek TT #1137 created by plobsing++: [PATCH] fix codingstd/c_indent.t wrt switch/case labels
00:52 chromatic That's fairly well tested already.
00:53 cotto_work yes.  There are only a couple holes.
00:56 ttbot Parrot trunk/ r42029 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/119268.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
00:56 abqar joined #parrot
01:02 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 parrot: r42030 | jkeenan++ | branches/auto_libjit (10 files):
01:02 dalek parrot: Applying config_fixup patch submitted by plobsing++ in https://trac.parrot.org/parrot/ticket/1105.
01:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42030/
01:02 Austin I'll give it a shot.
01:03 japhb dalek_lag ...
01:06 dalek parrot: r42031 | whiteknight++ | trunk (5 files):
01:06 dalek parrot: [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 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42031/
01:06 Austin japhb: It works for me.
01:06 darbelo japhb: workforme
01:06 japhb excellent
01:06 dalek parrot-plumage: 4e30f63 | japhb++ | :
01:06 dalek parrot-plumage: [BUILD] Makefile.in: Use (very) slightly more advanced make features; ad...
01:06 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/4e30f633b3d90645679bac660d92b70e25abec99
01:06 cotto_work Yay!  My test pestering is having an effect.  Whiteknight++
01:07 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
01:08 japhb Austin, yes, but IIRC '.RANDOMWORDHERE' is ignored if not understood, right?
01:08 japhb Because it appears to be just a rule that never gets used
01:09 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
01:10 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.
01:11 japhb darbelo, sure, but in addition Gnu will avoid doing its usual searches on any PHONY targets
01:11 japhb Very minor performance improvement that comes with a minor correctness improvement as well.
01:11 ttbot Parrot trunk/ r42031 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/119311.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
01:11 darbelo Yeah. I'm just making sure we don't *rely* on that working.
01:13 eternaleye joined #parrot
01:14 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" ...
01:15 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.
01:16 kid51 I believe it was whiteknight and bacek who did the work of ripping our old, malfunctioning JIT out.
01:16 kid51 I see what we're doing as laying the ground work for restoration of JIT.
01:16 Whiteknight darbelo ripped it out
01:16 cotto_work darbelo++
01:16 cotto_work darbelo?
01:16 purl hmmm... darbelo is Daniel Arbelo Arrocha <mailto:arbelo@gmail.com>
01:16 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."
01:17 kid51 When darbelo, whiteknight et al get the tuits for that
01:17 cotto_work darbelo is also Daniel "The Wrecking Ball" Arbelo Arrocha
01:17 purl okay, cotto_work.
01:17 * darbelo likes to remove code.
01:17 dalek parrot-plumage: e088429 | japhb++ | :
01:17 dalek parrot-plumage: [BUILD] Makefile.in: Go further back in prehistory of make syntax
01:17 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/e0884297b3445f4e26ca6da9cef9743006e6e966
01:18 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
01:18 kid51 True enough.
01:19 kid51 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:20 kid51 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.
01:20 kid51 As do I.
01:20 kid51 but please post on #parrotsketch earlier in that same UCT day.
01:21 kid51 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.
01:21 plobsing ok. thanks.
01:21 cotto_work (though Whiteknight may be able to answer it now)
01:21 Whiteknight ?
01:21 kid51 And, in any event, whiteknight, bacek, darbelo -- all of you JIT-knowledgeable people, please review TT 1105 and TT 1075
01:21 * Whiteknight isn't paying attention, tries backlogging
01:21 cotto_work or not
01:22 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
01:23 darbelo plobsing: The libjit branch will merge as soon as it's updated to work with current trunk.
01:23 darbelo Which will hopefully be sooner.
01:23 cotto_work but I don't think that excludes plobsing's branch from being merged
01:24 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
01:24 cotto_work we don't want to cause any less pain than necessary
01:24 cotto_work s/less/more/ ;)
01:24 Whiteknight Lorito will be the JIT implementatin
01:24 Whiteknight the two are one and the same
01:25 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.
01:26 darbelo I saw what it did to the current frame builder, and it wasn't pretty.
01:26 darbelo But then the frame builder wasn't pretty either ;)
01:26 Austin japhb: There's no Makefile: rule in the Makefile.
01:26 plobsing I'm just looking at what it did to nci.c. The change looks pretty trivial.
01:26 plobsing note that the frame builder doesn't actually touch pcc strings.
01:26 Whiteknight the old frame builder wasn't pretty
01:26 plobsing thats the task of nci.pmc
01:27 * 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.
01:27 darbelo The ugly shit our frame builder was pulling is now getting done inside libjit.
01:28 cotto_work chromatic, you make it sound so easy
01:28 darbelo chromatic: I don't think anyone wants to.
01:29 darbelo Anyway, I have to go now.
01:29 darbelo See y'all later.
01:29 chromatic It's not that complex.
01:29 nopaste "kid51" at 71.247.47.180 pasted "auto_libjit branch diff from trunk at its branch point" (4442 lines) at http://nopaste.snit.ch/18424
01:30 darbelo left #parrot
01:30 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 chromatic If the libjit branch is close, it's not worth salvaging the trunk code though.
01:31 * kid51 must sleep
01:31 purl $kid51->sleep(8 * 3600);
01:31 plobsing I'd say its pretty close, but I doubt I'm being objective
01:32 * Whiteknight has to sleep now. Look at it tomorrow
01:41 japhb Austin, what should be in the Makefile: rule?
01:42 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?
01:42 japhb er, reread the rebuilt makefile before continuing?
01:44 Austin Yes.
01:44 japhb Oooh, that's useful.
01:44 Austin You edit makefile.in, and it rebuilds makefile.
01:44 Austin It's pretty sweet.
01:44 japhb OK, have to do $family stuff for a bit, but then I will absolutely put that in, thanks for the idea.
01:45 japhb Oh, do I need to make anything depend on Makefile ? or is that implicit?
01:46 Austin No, it needs to specify src/Makefile.in as its dependency.
01:47 Austin 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
01:47 japhb k
01:48 japhb AFK for now, but will backlog if you have more advice in the mean time ....
01:51 dalek nqp-rx: f8fb418 | pmichaud++ | src/NQP/ (2 files):
01:51 dalek nqp-rx: Handle immediate blocks (in 'if' statements, at least).
01:51 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/f​8fb418149ef0b1ca133f62d32224762cc82ab8a
01:51 dalek nqp-rx: 16b3e50 | pmichaud++ | src/ (3 files):
01:51 dalek nqp-rx: Fix error in protoregex token string test.
01:51 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/1​6b3e500c81c36f0b3c61e6a165876b6789dcbb3
01:51 dalek nqp-rx: a3d0b4e | pmichaud++ |  (4 files):
01:52 dalek nqp-rx: [nqp]:  Recognize statement end after close curly brace.  Add "make nqp-test" target, and first set of tests.
01:52 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​3d0b4e817492e94c127708312368403d21e2009
01:52 dalek nqp-rx: b870296 | pmichaud++ | t/nqp/02-if-else.t:
01:52 dalek nqp-rx: [nqp]: Add (passing) if-elsif-else tests.
01:52 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/b​870296bcf76dc53d00434ab6e670224226da04c
01:52 dalek nqp-rx: 182e820 | pmichaud++ | t/nqp/0 (2 files):
01:52 dalek nqp-rx: [nqp]: Somehow missed adding these tests in earlier commits.
01:52 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/1​82e820765d09297345ddfc7a41a64cdd883989c
01:57 dalek nqp-rx: 4174ed2 | pmichaud++ |  (3 files):
01:57 dalek nqp-rx: [nqp]:  Add 'unless' statement.
01:57 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/4​174ed291a9f7a8bddaf6d548c0efe5741cdd65b
01:59 davidfetter joined #parrot
02:06 nopaste "Austin" at 98.235.55.43 pasted "Suggested changes to plumage's src/Makefile.in (japhb, darbelo)" (26 lines) at http://nopaste.snit.ch/18425
02:35 janus joined #parrot
02:45 particle1 joined #parrot
02:53 japhb Austin, thank you.  Just pushed a slightly modified version of your patch.
02:53 Austin cool
02:55 dalek parrot-plumage: cfa89e9 | japhb++ | :
02:55 dalek parrot-plumage: [BUILD] Automatic Makefile rebuilding, Austin++
02:55 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/cfa89e98371e8bc0dff2cca4e0091f8243433c2c
02:55 Austin Looks good, G
02:58 japhb "That's the way the ball bounces, G."
03:14 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:16 Austin Ahh, that's got it. Thanks, parrot -t4
03:43 dalek rakudo: 49e62fa | (Kyle Hasselbacher)++ | t/spectest.data:
03:43 dalek rakudo: [spectest.data] Add integration/return-from-method-in-hash.t (RT 69610)
03:43 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​9e62fa9af5143edd784122d81e17f83b9853b01
03:49 mokurai left #parrot
03:54 mokurai joined #parrot
04:25 Austin Bass for your face!
04:26 Austin http://www.youtube.com/watch?v=PBlMrGgpwXE @ 1:55
04:30 mberends joined #parrot
04:39 dalek nqp-rx: 6ebc781 | pmichaud++ | t/nqp/0 (4 files):
04:39 dalek nqp-rx: [nqp]: More test fixes, add 04-comments.t .
04:39 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/6​ebc781bc22d8845fde288142e4d76144a4389a2
04:39 dalek nqp-rx: c48a575 | pmichaud++ | t/nqp/0 (10 files):
04:39 dalek nqp-rx: Rename test files to avoid 00-* test (and since we won't use 05-pod.t
04:39 dalek nqp-rx: as-is anyway).
04:39 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​48a575f5ed3f5585304c3f9c97bdfbb172b553d
04:39 dalek nqp-rx: c5c2958 | pmichaud++ | t/nqp/06-args-pos.t:
04:39 dalek nqp-rx: Add 06-args-pos.t test.
04:39 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​5c2958381547966737c6a08cc273cbb91009ee3
04:39 dalek nqp-rx: 6be2c89 | pmichaud++ |  (4 files):
04:39 dalek nqp-rx: [nqp]: Add prefix:<!> and prefix:<?>.  Add 'plan' and 'ok' builtins.
04:39 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/6​be2c8907bfd54c190aab87a12b9b9074fae2ce0
04:51 dalek nqp-rx: 86ff73b | pmichaud++ |  (2 files):
04:51 dalek nqp-rx: [nqp]:  Make immediate blocks work in statementlists.  Add 08-blocks.t.
04:51 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/8​6ff73bf54ff407460a8ba0a9cae8ab2ae55247d
05:01 Austin_Hastings joined #parrot
05:14 dalek nqp-rx: d6f5066 | pmichaud++ | src/PAST/Regex.pir:
05:14 dalek nqp-rx: Zero-width anchors allow prefix tokens.
05:14 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/d​6f5066a951709e26d9141056e7680e80e3e97eb
05:17 eternaleye joined #parrot
05:53 nbrown joined #parrot
06:03 bacek joined #parrot
06:03 Austin Good day, Bacek.
06:04 Austin Speaking of which, how did your big production release go?
06:11 japhb Well played, Austin
06:12 Austin Apparently I've rendered him speechless with my witty repartee...
06:12 cotto clock?
06:12 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 /
06:12 Austin :|
06:13 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 #parrot
06:13 Austin They're on my iPod.
06:13 japhb Ditto
06:15 japhb g'night!
06:15 Austin Somewhere between Pink Floyd and Rammstein :)
06:15 desertm4x joined #parrot
06:15 japhb Damn you for making me laugh until I cough
06:15 * japhb really afk now
06:29 dalek nqp-rx: fbaf420 | pmichaud++ | src/ (4 files):
06:29 dalek nqp-rx: Add special handling of <sym>.
06:29 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/f​baf420d94b8ad4a2a68075bbd02a8540f7dacf8
06:29 dalek nqp-rx: a02da52 | pmichaud++ | src/NQP/Grammar.pm:
06:29 dalek nqp-rx: [nqp]:  Switch grammar to use <sym> subrule.
06:29 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​02da5221f6dc4af5c044d74d98cbfa99684439a
06:29 dalek nqp-rx: 5ad06df | pmichaud++ | src/ (3 files):
06:29 dalek nqp-rx: [p6regex]:  Switch to use <sym> subrule in protoregexes.
06:29 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/5​ad06dfbbd4b7ac50ca55ee8f13e58f0c8d8fff2
06:31 bacek joined #parrot
06:44 bacek o hai
06:44 bacek Austin: pretty well. We are totally messed up :)
06:45 Austin Yes!
06:45 Austin Job security.
06:45 purl somebody said job security was very useful!
06:45 eternaleye joined #parrot
06:47 dalek parrot: r42032 | chromatic++ | trunk/config/gen/makefiles/root.in:
06:47 dalek parrot: [config] Fixed Makefile dependencies for src/call/args.c.  This should help
06:47 dalek parrot: parallel building.
06:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42032/
06:50 bacek chromatic: any objections for my morning patch? I'm going to commit it.
06:55 ttbot Parrot trunk/ r42032 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/119441.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
06:55 chromatic I don't think it's the right approach.
06:56 chromatic I have a weird feeling we're adding a vtable entry we'll yank out again soon.
06:56 chromatic 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.
07:00 dalek parrot: r42033 | chromatic++ | trunk/src/string/api.c:
07:00 dalek parrot: [string] Fixed some compiler warnings in Parrot_str_unescape().
07:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42033/
07:00 dalek parrot: r42034 | chromatic++ | trunk/t/op/cc_params.t:
07:00 dalek parrot: [t] Added necessary test boilerplate (such as a copyright statement and footer)
07:00 dalek parrot: as well as the shebang line, which tells prove and Test::Harness to know to run
07:00 dalek parrot: this as a PIR program, not a Perl 5 program.
07:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42034/
07:00 JimmyZ joined #parrot
07:00 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:01 bacek chromatic: heh. I can rework it using set_pointer_keyed_int. push_pointer is just shortcut.
07:01 chromatic That would help, yes.
07:02 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.
07:02 Austin Anyone want some improved performance?
07:03 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.
07:04 Austin Every third line in the output of NQP is "unless_null .... goto ..." to get this behavior.
07:05 chromatic The equivalent of Perl 5.10's //= then?
07:05 Austin No. Not a PMC as $2, but a typename.
07:05 Austin Yes.
07:05 Austin Have a look at some nqp-generated .pir code.
07:06 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.
07:06 chromatic ... except semantics are tricky.
07:06 Austin It's not a parameters thing. It's after every variable reference.
07:07 chromatic Can you nopaste an example?
07:07 nopaste "Austin" at 98.235.55.43 pasted "Why a //= opcode?" (14 lines) at http://nopaste.snit.ch/18426
07:08 ttbot Parrot trunk/ r42034 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/119495.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
07:10 chromatic Seems reasonable.
07:10 chromatic I'd like to hear pmichaud's thoughts, but I can see the use.
07:10 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 #parrot
07:12 Austin I'm wrong. It's 6.3 percent.
07:12 Austin In a .pir file with 21872 lines, 1381 were "unless_null"
07:12 Austin purl, 1381 / 21872
07:12 purl 0.0631400877834674
07:12 chromatic Right, but we can also get rid of the label and the assignment lines too.
07:13 Austin I think not.
07:13 Austin I'm talking about replacing 2 opcodes (unless-goto, init) with one opcode (init-unless)
07:14 Austin 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.
07:14 chromatic The labels come out of the PIR code though.
07:14 Austin So the pir goes down by 12%, but the pbc by 6%. Still nothing to sneeze at, I think.
07:15 Austin Plenty of states pay their budget with a 6% tax...
07:15 chromatic PBC goes down from five opcode_ts to three.
07:16 Austin Does it?
07:16 Austin What's the pbc look like for that sequence?
07:16 chromatic set_unless_null P SC is one opcode_t for the op type and one each for two arguments.
07:17 desertm4x_ joined #parrot
07:17 Austin set if null, you mean?
07:17 chromatic Right.
07:17 Austin Okay.
07:18 Austin unless-null-branch P, small-offset is probably 2 opcode_t's, and new R, SC is 2.
07:19 chromatic unless_null P IC is three opcode_t s.
07:19 Austin Really?
07:19 Austin That's bad design.
07:19 chromatic That's no reason not to believe it.
07:19 Austin :)
07:20 Austin So 5->3
07:20 Austin About a 2% size reduction, then.
07:21 chromatic Speed-wise, maybe a 2-3% gain.
07:21 Austin I'm thinking it's "new_if_null" or "vivify".
07:21 Austin Is it?
07:21 purl it's it!
07:21 chromatic I like vivify.
07:21 Austin I think the gain might be more.
07:21 chromatic It might.
07:22 Austin But what's the branch penalty, or is there one, really?
07:22 Austin For the most part, it always jumps, because most of these vivs are redundant.
07:23 chromatic A local jump like this merely changes the address of the next opcode to execute.
07:23 chromatic If there's any notable penalty, it's a data cache read miss.
07:24 chromatic In straight-line code like you pasted, we'd have to pay that cache miss anyway.
07:24 chromatic The PBC size reduction actually *helps* there more than avoiding the jump.
07:25 Austin Why would we pay the cache miss anyway?
07:26 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.
07:34 Austin TT# 1138
07:34 dalek TT #1138 created by Austin_Hastings++: Create a 'vivify' opcode
07:35 Austin Hmm. Now I can generate nulls, but it's hard to catch them.
07:36 mikehh just updated my Ubuntu 9.10 beta - I think I need to reboot - bbiab
07:39 kurahaupo joined #parrot
07:41 Austin Anyone have a bunch of test cases for bsearch laying around?
07:42 mikehh joined #parrot
07:49 xenoterracide joined #parrot
08:01 einstein joined #parrot
08:06 dalek parrot: r42035 | fperrad++ | trunk/t/op/cc_params_old.t:
08:06 dalek parrot: [codingstd] fix SVN properties
08:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42035/
08:13 ttbot Parrot trunk/ r42035 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/119584.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
08:15 mikehh joined #parrot
08:21 eternaleye joined #parrot
08:30 TiMBuS joined #parrot
08:47 colomon joined #parrot
09:00 barney joined #parrot
09:17 chromatic joined #parrot
09:21 masak joined #parrot
09:23 dalek nqp-rx: 7fa2ece | masak++ | src/cheats/hll-grammar.pir:
09:23 dalek nqp-rx: Fixed typo in documentation.
09:23 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/7​fa2ece7c85190b3d23dfc818ddd36c3aaa54c59
09:58 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.
10:01 donaldh joined #parrot
10:09 Austin desert4mx_ : In what language?
10:09 Austin And are you being precise, when you say "method" ?
10:12 pjcj joined #parrot
10:37 kid51 joined #parrot
10:47 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.
11:00 Austin desertm4x_ : Take at look around for "Parrot_pcc_invoke_method_from_c_args".
11:00 desertm4x_ Thanks.
11:02 Austin np
11:12 bacek joined #parrot
11:39 rdice joined #parrot
12:06 dalek TT #1093 closed by fperrad++: t/pmc/env.t segfaults on Windows
12:13 mj41 joined #parrot
12:26 bluescreen joined #parrot
12:34 whiteknight joined #parrot
12:36 whiteknight_ joined #parrot
12:42 bacek fperrad: ping.
12:42 fperrad pong bacek
12:43 bacek fperrad: pcc.patch doesn't applied clearly on 9b5ce128
12:43 bacek a, my bud
12:43 bacek bad
12:46 bacek 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 #parrot
12:49 preflex joined #parrot
12:53 nopaste "fperrad" at 77.194.156.254 pasted "[PATCH] Lua PMC" (625 lines) at http://nopaste.snit.ch/18428
12:59 gaz joined #parrot
13:02 Coke fperrad: when I rewrote partcl's one use of this, I used http://github.com/partcl/partcl/blo​b/master/src/pmc/tclstring.pmc#L47
13:03 Coke (not sure if that helps you or not)
13:08 fperrad Coke, in Parrot tree, I found few files where Parrot_runops_fromc_args() become Parrot_pcc_invoke_sub_from_c_args()
13:09 Coke if it works, it works. =-)
13:09 Coke (my initial replacement for invoking something segfaulted, so I was happy for the new func in src/extend.c)
13:10 payload joined #parrot
13:13 donaldh joined #parrot
13:13 donaldh left #parrot
13:15 fperrad_ joined #parrot
13:23 Coke huge # of failing smokes.
13:45 ruoso joined #parrot
13:47 bacek joined #parrot
13:50 PerlJam Is the parrot svn server down?
13:50 PerlJam I get svn: OPTIONS of 'https://svn.parrot.org/parrot/trunk': could not connect to server (https://svn.parrot.org) when trying to "svn up"
13:51 gaz joined #parrot
13:58 Coke PerlJam: looks ok to me.
14:00 colomon joined #parrot
14:01 Coke todo: add a link to http://widget.mibbit.com/?server=i​rc.perl.org&amp;channel=%23parrot to the website.
14:02 particle ping svn.parrot.org
14:03 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:06 colomon_ joined #parrot
14:06 cghene joined #parrot
14:11 payload joined #parrot
14:15 nopaste "bacek" at 114.73.47.212 pasted "Patch for Lua to use public parrot API for fperrad++" (647 lines) at http://nopaste.snit.ch/18431
14:15 bacek fperrad: ping
14:15 fperrad bacek, pong
14:15 dalek parrot: r42036 | bacek++ | trunk/src/call/pcc.c:
14:15 dalek parrot: Run ops for Sub subclasses. fperrad++
14:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42036/
14:15 bacek try nopasted patch on r42036
14:16 whiteknight joined #parrot
14:16 bacek It works on my box.
14:17 fperrad bacek, great
14:17 bacek fperrad: does it work?
14:18 fperrad bacek, I need time (rebuild, ...)
14:19 bacek fperrad: ok.
14:24 davidfetter joined #parrot
14:25 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 #parrot
14:30 colomon joined #parrot
14:33 whiteknight trac is rediculously slow today
14:40 whiteknight Where is plumage hosted?
14:40 whiteknight is it in the parrot repo?
14:42 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 http://gitorious.org/parrot-plumage/parrot-plumage and the design docs are at https://trac.parrot.org/pa​rrot/wiki/ModuleEcosystem
14:42 NotFound whiteknight: https://trac.parrot.org/pa​rrot/wiki/ModuleEcosystem
14:42 whiteknight ah, gitorious
14:45 cotto_work good day, #parrot
14:49 dalek parrot: r42037 | bacek++ | trunk/t (5 files):
14:49 dalek parrot: Rebuild native PBC and update packfile tests.
14:49 dalek parrot: There is no PIC segment in PBC anymore.
14:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42037/
14:49 * whiteknight has finally printed out a new Parrot CLA to mail in
14:49 whiteknight it's taken me this long to find the damn link
14:49 particle parrot cla?
14:50 particle feh, what happened to purl's factoid
14:50 particle cla?
14:50 purl rumour has it cla is Contributor License Agreement or http://www.perlfoundation.org/​contributor_license_agreement or http://www.parrot.org/foundation/legal or http://www.parrot.org/files/parrot_cla.pdf or http://www.lowcarbfriends.com/bbs/mai​n-lowcarb-lobby/223884-cla-acne.html
14:52 Psyche^ joined #parrot
14:54 cotto_work Are we supposed to be sending CLAs to PaFo, even if we've sent them to TPF?
14:54 moritz yes
14:54 moritz allison answered a mail about that recently on parrot-dev
14:54 cotto_work good to knoq.  I'll have to get on that.
14:55 cotto_work s/q/k/
14:55 moritz good to knok :-)
14:55 cotto_work nm
14:56 cotto_work I apparently don't knok how to type this week. ;)
14:57 cotto_work NotFound++ for the random Spanish blog post
14:59 particle you typed 'this week' just fine.
15:00 cotto_work my bad
15:01 cotto_work nobody's perfectly imperfect
15:01 NotFound Oh, someone reads my blog?
15:02 cotto_work It won't read itself.
15:02 cotto_work (not until Skynet, at least)
15:02 particle write a blogging engine with nqp-rx and see what happens
15:08 theory joined #parrot
15:09 whiteknight what I would really like to do is write a "make" utility for Parrot
15:10 whiteknight 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.
15:10 cotto_work Interesting idea.  It'd be as portable as Parrot by definition.
15:10 particle there's already on ein the works, whiteknight
15:10 whiteknight particle: really? link?
15:11 whiteknight in theory, make's algorithm isn't too hard to duplicate
15:11 pmichaud_ arrrg, trac lost my post!
15:11 dalek parrot: r42038 | bacek++ | trunk (7 files):
15:11 dalek parrot: [core] Replace RPA of CPointers for handling returns with single
15:11 dalek parrot: CallSingatureReturns PMC.
15:11 pmichaud_ (my earlier post to #787, not the one I just made to #1138)
15:12 dalek parrot: This decrease number of allocated GC objects by ~1M in fib.pir and
15:12 particle http://code.google.com/p/smart-make/
15:12 dalek parrot: improve performance by ~11%.
15:12 dalek parrot: This is temporary solution to bring some speed loss after PCC refactors.
15:12 dalek parrot: Will probably removed after 2.0 release with unification of args/returns
15:12 dalek parrot: handling.
15:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42038/
15:12 colomon joined #parrot
15:12 whiteknight take rules, build an acyclic graph of dependencies, then traverse the graph building each peice
15:13 particle *directed acyclic graph
15:13 NotFound pmichaud_: hey, you stolen that idea from me ;)
15:13 whiteknight ah, true. Directed acyclic graph
15:14 whiteknight 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:15 particle did you see my link?
15:15 bacek whiteknight: you shouldn't "avoid" cycles. You should detect them.
15:15 whiteknight yes, but I'm still preaching
15:15 whiteknight bacek: detect them and panic is the same as avoid
15:15 * particle sits in the choir
15:15 whiteknight Assuming we aren't trying to be graceful about it
15:16 particle javac is quite graceful about it
15:16 particle it builds binaries from sources with cyclic dependencies
15:16 moritz "graceful" = "nice error message"?
15:16 particle incremental compilation
15:17 moritz time travel!
15:17 purl i guess time travel is easy. It's just changing the speed and direction that's hard or http://www.explosm.net/comics/1129/
15:17 rdice joined #parrot
15:21 dalek TT #1140 created by doughera++: config/gen/platform/generic/env.c unsetenv() out of sync
15:27 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:28 whiteknight 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
15:28 whiteknight NotFound: I'm talking about a separate compiler project that would take "Enhanced PIR" files and translate them to normal PIR
15:29 NotFound whiteknight: that is Winxed ;)
15:29 whiteknight NotFound: that uses different syntax. I'm still thinking about a PIR-like syntax
15:29 whiteknight just with loops and stuff
15:29 NotFound Not a bad idea.
15:29 fperrad joined #parrot
15:30 fperrad ping bacek
15:30 purl I can't find bacek in the DNS.
15:30 whiteknight Matrixy, for instance, uses matrices and a lot of loops. multiple loops and nested loops are horrendous in normal PIR
15:30 bacek fperrad: pong
15:30 payload joined #parrot
15:31 fperrad bacek, not ok
15:31 nopaste "bacek" at 114.73.47.212 pasted "More lua patches for fperrad" (13 lines) at http://nopaste.snit.ch/18433
15:31 fperrad have you try :
15:31 fperrad $ prove t/pmc/*.t
15:31 whiteknight so I want a small pre-processor to throw in the build that will allow us to write prettier libraries in PIR
15:31 nopaste "bacek" at 114.73.47.212 pasted "Lua test summary report" (47 lines) at http://nopaste.snit.ch/18434
15:32 bacek fperrad: http://nopaste.snit.ch/18434 with additional patch from http://nopaste.snit.ch/18433
15:33 nopaste "bacek" at 114.73.47.212 pasted "Result of "prove t/*pmc" in Lua" (25 lines) at http://nopaste.snit.ch/18435
15:33 whiteknight oi! lua is failing a lot of tests
15:33 Tene Yeah.  See mail on the list about updating lua to pcc.
15:35 whiteknight does lua use lots of C code?
15:35 bacek whiteknight: yes. A lot of PMCs at least
15:36 whiteknight ok
15:36 whiteknight are the failures from old Lua code needing to be updated, or PCC not supporting all features?
15:37 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 #parrot
15:38 bacek I helped fperrad++ for updating to current PCC. Time to update PCC by it self
15:38 bacek whiteknight: src/call/args.c:1666
15:40 whiteknight wtf?
15:40 whiteknight the return should be flattened when the signature is created, before the call to fill_results
15:41 whiteknight the return should be flattened in the set_returns opcode
15:41 whiteknight oh shit, get_params is called before set_returns is
15:42 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?
15:42 bacek We don't update original signature during flattening
15:42 Coke (I have a user who is whitelisted, but I keep having to approve his messages because of the implicit destintation.)
15:43 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
15:44 whiteknight probably need to read more code
15:44 Coke whiteknight: (enhanced pir) see hllmacros.pir.
15:44 whiteknight Coke: seen them. step in the right direction but not nearly enough
15:45 Coke feel free to add more. =-)
15:45 Coke I have some TryCatch that I added to partcl that could be stolen back.
15:45 Coke (I know it's not another language, but I don't have a need for something between nqp and pir+hllmacros. YMMV, orf course.)
15:46 Coke http://github.com/partcl/partcl​/blob/master/src/macros.pir#L36
15:46 iblechbot joined #parrot
15:47 * 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.
15:47 Coke (but feel free if you want to. =-)
15:49 dalek lua: f44ff0a | unknown++ | t/pmc/thread_hll.t:
15:49 dalek lua: fix plan
15:49 dalek lua: Now with pcc, test_6 works
15:49 dalek lua: review: http://github.com/fperrad/lua/commit/f4​4ff0acdefc7268436ab3eb00432526ebcb0e34
15:49 cotto_work interesting idea about svn (and implicitly a good case for git): http://designbygravity.wordpress.com​/2009/10/19/what-mother-never-told-y​ou-about-svn-branching-and-merging/
15:52 pmichaud_ heh
15:52 Coke cotto_work: that's pretty much allisons' approach to branching/merging.
15:52 pmichaud_ that's essentially the way I've been recommending to do branches in svn
15:52 Coke and pmichaud's. =-)
15:53 pmichaud_ always start a new branch from trunk and merge your old branch into it
15:53 pmichaud_ don't ever merge trunk into a branch
15:53 cotto_work and hope you don't have to bisect something
15:55 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:56 moritz which means you lose log and blame log for the branch
15:57 dalek parrot: r42039 | bacek++ | trunk/src/call/args.c:
15:57 dalek parrot: [core][pcc] FLAT returns into SLURPY results.
15:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42039/
15:59 cotto_work It works, but it's inelegant.
16:02 darbelo joined #parrot
16:02 bacek whiteknight: Parrot_pcc_merge_signature_for_tailcall asserting on "parent" in Lua.
16:03 whiteknight damnit
16:05 bacek # Back in sub 'parrot;Parrot::Coroutine;resume', env 80bb474
16:05 bacek *** switching to
16:05 bacek src/call/args.c:2353: failed assertion 'parent'
16:05 bacek looks like some problems with Coroutines
16:07 Andy joined #parrot
16:07 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 Tene whiteknight: yes, it's all very backwards.
16:08 whiteknight yeah, I really want to make it un-backwards at some point
16:09 bacek Tene: r42039
16:10 whiteknight but I want a lot of things
16:13 bacek and little pony?
16:13 pmichaud_ ... the new pcc doesn't handle :flat into :slurpy returns?
16:13 pmichaud_ that's a problem.
16:13 bacek pmichaud_: it does already.
16:14 pmichaud_ oh
16:14 pmichaud_ I just tried 42038
16:14 pmichaud_ I'll try 42039
16:14 bacek For last 15 minutes. It's like for ages in modern world :)
16:14 * pmichaud_ really wants the fetch and vivify opcodes he just proposed in TT #1138
16:15 pmichaud_ I'll even write fetch+vivify.  PCT could use them today.  Code would be much cleaner.
16:15 whiteknight much cleaner
16:15 nopaste "bacek" at 114.73.47.212 pasted "Lua "prove -r t" results..." (76 lines) at http://nopaste.snit.ch/18436
16:16 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.
16:16 pmichaud_ I will probably take that approach, though.
16:17 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
16:17 Coke but if they're in as experimental, demonstrating improvments in code size/speed/etc. becomes concrete.
16:18 kthakore joined #parrot
16:18 kthakore hi again!
16:18 purl oh, you're back!
16:19 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? http://irclog.perlgeek.de/p​arrot/2009-10-17#i_1612550
16:19 kthakore oops
16:19 kthakore dukeleto: how did this go btw? http://irclog.perlgeek.de/p​arrot/2009-10-17#i_1612550
16:20 pmichaud_ any thoughts about which approach I should take to handling lexicals (from https://trac.parrot.org/pa​rrot/ticket/1138#comment:3) ?
16:20 * Coke thinks he's figured out his mailman question
16:21 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.
16:21 purl Message for allison stored.
16:26 dalek parrot: r42040 | darbelo++ | trunk/config/gen/makefiles/root.in:
16:26 dalek parrot: Add some more dependecies to the main makfile template. This fixes parallel building for BSD make.
16:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42040/
16:27 darbelo Do any of the parallel buildes in the room care to test r42040 with GNU make?
16:29 cotto_work darbelo, yes they do
16:30 darbelo Cool. I just ran a make -j3 on OpenBSD with those changes.
16:30 darbelo having confirmation for GNU make would be cool.
16:31 cotto_work first try worked.  I'll try a couple more times just to be sure.
16:32 bacek darbelo: looks good on my box.
16:33 darbelo Ok, just spotted another missing dep, but it seems to build fine anyways.
16:33 dalek lua: fef745c | unknown++ |  (6 files):
16:33 dalek lua: PMC conversion after pcc merge (http://trac.parrot.org/parrot/changeset/41972)
16:33 dalek lua: Courtesy of bacek++
16:33 dalek lua: review: http://github.com/fperrad/lua/commit/fe​f745c3a1f83639951c34d5b4cc73adc9019ef4
16:35 darbelo Ha! failed with -j6
16:36 particle cotto_work: you did realclean first, yes?
16:36 cotto_work yes
16:37 cotto_work it worked for me
16:37 cotto_work particle, reconfig (but that does realclean)
16:38 particle just checking :)
16:42 dalek parrot: r42041 | darbelo++ | trunk/config/gen/makefiles/root.in:
16:42 dalek parrot: Add another missing makefile dep.
16:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42041/
16:44 payload joined #parrot
16:50 mikehh joined #parrot
16:52 dalek TT #472 closed by fperrad++: segfault when catching an exception from C
17:07 cotto_work darbelo, ~30 minutes of running parallel make seems to say that you fixed it
17:07 cotto_work darbelo++
17:07 darbelo Yay!
17:08 mikehh joined #parrot
17:12 darbelo japhb: ping
17:13 japhb pong
17:14 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 #parrot
17:18 gaz joined #parrot
17:23 dalek lua: 066428c | unknown++ | src/lib/bc.pir:
17:23 dalek lua: fix library bc
17:23 dalek lua: review: http://github.com/fperrad/lua/commit/06​6428cc66e4fefed7f28aac6b72dd5b7ae7abea
17:24 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:26 darbelo japhb: They can't object if I commit before they notice :)
17:26 japhb :-)
17:27 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
17:31 japhb pmichaud_, which level in the lexpad stack would vivify_lex create the new entry?  Nearest?
17:35 * darbelo jfdi
17:35 japhb Go darbelo, go darbelo
17:37 cotto_work It'd be a good idea to leave the ticket open for a couple days for feedback.
17:37 dalek parrot: r42042 | darbelo++ | trunk/config/gen/makefiles/root.in:
17:37 dalek parrot: Add files installed by 'install-dev' to the 'install' make target.
17:37 dalek parrot: The functionality provided by the old 'install' target now lives in install-bin.
17:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42042/
17:43 desertm4x joined #parrot
17:47 dalek parrot: r42043 | mikehh++ | trunk/MANIFEST:
17:47 dalek parrot: fix manifest_tests error - Failed test 'No need to regenerate MANIFEST'
17:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42043/
17:49 darbelo mikehh: doesn't that regress TT#1126 ?
17:52 cotto_work ow my script
17:53 dalek parrot: r42044 | mikehh++ | trunk/src/call/args.c:
17:53 dalek parrot: fix codetest failure - space between C keyword and subsequent open parenthesis
17:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42044/
17:57 dalek parrot: r42045 | mikehh++ | trunk/src/pmc/callsignaturereturns.pmc:
17:57 dalek parrot: set svn properties
17:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42045/
18:05 joeri joined #parrot
18:06 dalek parrot: r42046 | mikehh++ | trunk/src/pmc/callsignaturereturns.pmc:
18:07 dalek parrot: fix codetest failure - there should be at least one space between a C keyword and any subsequent open parenthesis
18:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42046/
18:07 cotto_work darbelo, feel free to fix that
18:12 cotto_work pmichaud_, is it possible to generate PAST from C?
18:12 mikehh call
18:13 dalek parrot: r42047 | mikehh++ | trunk/src/pmc/callsignaturereturns.pmc:
18:13 mikehh bah - src/pmc/callsignaturereturns.pmc is missing a associated test file
18:13 dalek parrot: fix codetest failure - missed a trailing space
18:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42047/
18:13 dalek parrot: r42048 | darbelo++ | trunk/MANIFEST:
18:13 dalek parrot: Re-add the [devel] tag to the tools/dev/pprof2cg.pl MANIFEST entry.
18:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42048/
18:13 mikehh an
18:13 cotto_work thanks darbelo
18:15 mikehh darbello - you beat me to it
18:16 kurahaupo joined #parrot
18:16 mikehh still got an unused assert macro to come
18:23 dalek parrot: r42049 | mikehh++ | trunk/src/call/pcc.c:
18:23 dalek parrot: fix codetest failure - unused assert macro
18:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42049/
18:25 mikehh ok that fixes all but one codetest failure - files in src/pmc but not in test dir: callsignaturereturns
18:25 mikehh I don't know if I am going to attempt that one :-}
18:27 cotto_work mikehh, you can create a stub test and file a ticket requesting more tests,
18:28 cotto_work you could even write some tests yourself.  Ask bacek what needs to be tested if you're interested.
18:34 chromatic joined #parrot
18:38 Coke joined #parrot
18:41 * darbelo is amused that Coke is the only guy who doesn't like Google Wave in the GSoC poll
18:42 dalek tracwiki: v16 | kurahaupo++ | ArrayTasklist
18:42 dalek tracwiki: Arrays as mix-ins
18:42 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Ar​rayTasklist?version=16&amp;action=diff
18:47 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
18:48 pmichaud_ 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 :)
18:48 mikehh ha
18:48 mikehh bacek: ping
18:49 japhb pmichaud_, OK, sure.
18:50 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
18:50 japhb Great, you get a +1 from me ... which isn't a surprise, given I filed the old ticket asking for the protean form.
18:51 Coke darbelo: so far, it sucks.
18:51 Coke I was a maybe until I actually tried to use it. =-)
18:52 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 pmichaud_ I'll probably implement them as experimental ops over the weekend.
18:52 japhb yep, please!
18:52 pmichaud_ tomorrow I'm at a conference much of the day, so don't know how much hacking I'll be able to do
18:53 darbelo Coke: Not blaming you for not liking it.
18:53 chromatic I could implement them if you gave me some tests.
18:53 pmichaud_ on the plus side, nqp-rx is coming along very well.  :)
18:53 japhb Which conference?
18:53 japhb yay!
18:53 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.
18:53 pmichaud_ chromatic: I would like a review of the patch when I get it done, though.
18:54 pmichaud_ 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.
18:54 pmichaud_ yes.  I'm thinking Rakudo would like a new PMC.
18:54 pmichaud_ it would be nice to have an object that allows one to look in all outer scopes at once
18:55 pmichaud_ i.e., a keyed interface that does the equivalent of find_lex
18:55 pmichaud_ if you wanted to create that PMC, that'd be awesome.
18:55 pmichaud_ 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
18:56 pmichaud_ *scopes
18:56 pmichaud_ I'm also not sure if    $P0 = fetch $P1[key], $P2    should return $P2 directly or a clone of $P2
18:56 pmichaud_ at the moment I'm leaning towards clone
18:56 * whiteknight got a blackberry!
18:56 * pmichaud_ gives whiteknight a raspberry.
18:56 chromatic Austin's suggestion was the name of a PMC to create, but a clone is more flexible.
18:56 * whiteknight estimates about 2 weeks before Parrot runs on blackberry
18:57 pmichaud_ yes, I think clone is more flexible too.
18:57 chromatic That's a six line op.
18:58 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 pmichaud_ it will require changing PAST a bit, but I think I'll just augment the existing interface
18:58 chromatic The syntax will have to be $P0 = fetch $P1, [key], $P2 however.
18:58 chromatic s/will/may/
18:58 pmichaud_ I have no problem with that
18:59 pmichaud_ in some ways I like that much better
18:59 pmichaud_ it's much easier for PAST to deal with   $P1, key, $P2   than   $P1[key], $P2
18:59 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.
18:59 pmichaud_ I suspect you're correct about that.
19:00 pmichaud_ $P0 = fetch $P1, key, $P2  works very well for me
19:00 pmichaud_ key should be any of pmc/int/string
19:00 pmichaud_ (and dispatch to the appropriate vtable interface on the aggregate)
19:00 chromatic They almost write themselves.
19:01 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 pmichaud_ 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. ?
19:01 chromatic What's your estimate on how much code this saves, NQP-wise?
19:02 chromatic Enabling temporary registers is pretty easy.
19:02 pmichaud_ it will tend to convert as many as 7 opcodes down to 1
19:02 pmichaud_ the long sequence is currently
19:02 pmichaud_ $P0 = fetch_lex '$foo'
19:02 pmichaud_ unless null $P0 goto label
19:02 pmichaud_ $P0 = new ['Something']
19:02 purl $P0 = new ['Something'] is the correct syntax now btw
19:03 pmichaud_ store_lex '$foo', $P0
19:03 pmichaud_ label
19:03 pmichaud_ ...
19:03 pmichaud_ okay, maybe 4 down to one
19:03 japhb purl, forget $P0 = new ['Something']
19:03 purl japhb: I forgot $p0 = new ['something']
19:03 mikehh I am getting a post_config  test failure - t/tools/pmc2cutils/00-qualify.t - Failed test:  5
19:03 pmichaud_ I suspect I'm missing something somewhere
19:03 japhb pmichaud_, didn't you paste the full sequences into one of the two tickets?
19:03 pmichaud_ I pasted one of the full sequences
19:03 chromatic Alright, give me a bit here.
19:03 pmichaud_ where it gets really tricky is when autovivifying containers
19:04 chromatic Are you in a position to take advantage of these in trunk?
19:04 pmichaud_ yes
19:04 pmichaud_ it's really more of a PAST benefit than an NQP one
19:05 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
19:05 chromatic Okay, give me an hour or so.
19:05 pmichaud_ it'd definitely be an NQP-rx benefit, yes.
19:05 pmichaud_ (not only would I be able to do it, but I will do it)
19:05 pmichaud_ I have to go searching for a lost dog -- bbiab
19:05 chromatic I have to go searching for a lost meal.
19:06 chromatic (this one's vegetarian, if anyone's confused)
19:06 Coke I'm always confused; your vegetarian dog food aside.
19:07 pmichaud_ found her... fortunately she didn't run far this time :)
19:16 payload joined #parrot
19:17 Coke pmichaud_: did you happen to see my motivation out there?
19:24 pmichaud_ Did not.
19:24 purl did not is did too
19:24 pmichaud_ actually, most of what is outside at the moment would be motivation to stay outside.  :)
19:25 cotto_work pmichaud_, is it possible to generate PAST from C?
19:25 purl i already had it that way, cotto_work.
19:25 cotto_work purl, forget pmichaud_
19:25 purl cotto_work, I didn't have anything matching pmichaud_
19:25 cotto_work purl, forget pmichaud_,
19:25 purl cotto_work: I forgot pmichaud_,
19:25 pmichaud_ cotto_work: not that I know of.
19:25 pmichaud_ cotto_work: generating past is all just method calls
19:25 mikehh bah - the test failed because I had not removed the *.*~ files in src/pmc - fixed now
19:26 cotto_work That's what I thought.
19:27 cotto_work 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 cotto_work ?
19:28 pmichaud_ I don't understand the question.
19:28 cotto_work grammar fail there.
19:29 cotto_work Do we eventually want to allow parsers to be written in e.g. C/C++ that emit PAST?
19:30 pmichaud_ nothing prevents that from happening, other than we'd want a good C-to-Parrot interface
19:30 pmichaud_ i.e., if we can create Parrot objects from C and invoke Parrot methods, then we can generate PAST from C
19:31 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)
19:32 pmichaud_ but the generic form for creating past structures is just
19:32 pmichaud_ $P0 = get_hll_global ['PAST'], 'Op'
19:32 pmichaud_ $P1 = $P0.'new'( ...arguments... )
19:32 cotto_work certainly nothing magical there
19:32 pmichaud_ where 'new' expects to be able to get both positional and named arguments
19:33 pmichaud_ the best place to see creation of PAST from PIR is compilers/nqp/src/Grammar/Actions.pir
19:33 pmichaud_ it gives the NQP version in the comments, then the equivalent PIR code in the source
19:35 pmichaud_ 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
19:35 pmichaud_ right
19:36 pmichaud_ although it could certainly be made less verbose
19:36 pmichaud_ past = PAST_VAR_new( ...args... )
19:36 pmichaud_ 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 #parrot
19:39 pmichaud_ afk
19:39 cotto_work nothing like that is currently planned, though?
19:41 Coke pmichaud_: I will have some hacking time available this weekend, if there's anything I can do to prep.
19:49 ruoso joined #parrot
19:50 whiteknight purl forget did no
19:50 purl whiteknight, I didn't have anything matching did no
19:50 whiteknight purl forget did not
19:50 purl whiteknight: I forgot did not
19:50 whiteknight purl did not is <reply>did too
19:50 purl OK, whiteknight.
19:50 whiteknight did not
19:50 whiteknight did not?
19:50 purl did too
19:50 whiteknight slightly better
19:55 pmichaud_ Coke: I'm not planning anything from C at the moment, no.
19:56 pmichaud_ s/Coke/cotto_work/   # tab fail
19:56 cotto_work I'll try to remember to ask about that at the next #ps
19:59 cotto_work afk
19:59 Coke darbelo: +1 on your install patch.
19:59 cotto_work Coke, it's already in trunk
20:00 Coke perhaps someone could close out that thread, then. =-)
20:03 mikehh trunk - pre/post-config, smoke (#29347) PASS, fulltest FAIL at r42049 - Ubuntu 9.10 (beta updated) amd64
20:03 mikehh t/op/annotate-old.t -  Failed test:  1 - in testf and testg (TT #1135)
20:03 mikehh t/pmc/eval.t - Failed test:  12 - in testr
20:03 mikehh t/pmc/threads.t - Failed tests:  8-9 - in testr
20:03 mikehh the testr failures come from Segmentation faults
20:03 mikehh t/codingstd/test_file_coverage.t - files in src/pmc but not in test dir: src/pmc/callsignaturereturns.pmc
20:03 mikehh the remainder of fulltest passes
20:04 colomon joined #parrot
20:07 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:08 whiteknight I think common usage patterns should inform our inclusion or exclusion of various ops
20:08 whiteknight I like the idea of having fewer ops, so that we can get rid of the ones we don't use
20:08 Austin me too, which is why I think vivify should already be there. :)
20:09 Austin 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
20:09 Austin It is?
20:09 purl Oh no it isn't!
20:09 Austin I thought it was O(1).
20:09 Coke darbelo: any pointers/docs on using your bignum stuff?
20:10 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 whiteknight at least, I'm reasonably certain it does
20:10 darbelo Coke: decnum-dynpmcs?
20:10 purl decnum-dynpmcs is http://code.google.com/p/decnum-dynpmcs/ or a 2009 GSoC porject or a set of 'big' decimal arithmetic types for parrot.
20:10 mikehh messages
20:10 Coke whiteknight: that's an argument for improving pir. =-)
20:10 whiteknight an argument for many things
20:10 whiteknight tightening up our instruction set is always always always a good thing
20:11 Coke darbelo: ah, it's just Num, not Int?
20:11 Austin When is it O(n) ?
20:11 mokurai joined #parrot
20:11 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.
20:12 whiteknight Coke: that may be, but it should have been
20:12 Austin Whiteknight: Are we talking about compile time or run time?
20:12 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.
20:13 darbelo 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
20:13 whiteknight Austin: when we have runtime eval(), it's both
20:14 pmichaud_ Austin: (N ops) I agree, which is why I simplified it down to just two ops.  :-)
20:14 pmichaud_ 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 :)
20:15 Austin pmichaud: yeah, but it's wrong. :(
20:15 pmichaud_ wrong?
20:15 purl but it feels so right
20:15 Austin I was just putting this in trac.
20:15 pmichaud_ why wrong?
20:15 darbelo Coke: http://code.google.com/p/decnum-dynpmcs/sou​rce/browse/trunk/examples/decnum_group.pir
20:16 darbelo 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.
20:17 Austin 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"
20:17 pmichaud_ PMCNULL basically provides a way to say "object doesn't exist"  without requiring a separate "exists" check or throwing an exception
20:17 nopaste "chromatic" at 72.87.39.97 pasted "pmichaud -- tests for the fetch opcode" (138 lines) at http://nopaste.snit.ch/18438
20:17 Austin pmichaud: I abstain from agreeing, because I haven't slept on that issue - I genuinely didn't think of it.
20:18 Coke Austin: PMCNULL is exposed at the PIR level.
20:18 pmichaud_ PMCNULL isn't a C NULL pointer
20:18 pmichaud_ they're completely different things
20:18 Austin But what I'm thinking is that Undef should be (and I think, is) a hll-map-able type.
20:18 chromatic PMCNULL is the Null Object Pattern.
20:19 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.
20:19 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
20:20 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
20:20 pmichaud_ that's not what PCT
20:20 pmichaud_ does
20:20 pmichaud_ PCT doesn't automatically replace nulls with Undef -- NQP does that.
20:20 pmichaud_ It's entirely possible for an HLL to not specify a viviself value, in which case the returned value remains PMCNULL
20:20 Austin Okay.
20:20 pmichaud_ NQP imposes the "aggregate defaults to undef" semantics, not PCT
20:21 bluescreen joined #parrot
20:21 pmichaud_ The point being, that's a HLL decision, not really a core PMC one.
20:21 pmichaud_ I'd like an aggregate to be able to return me a value that says "no such element"
20:21 Austin Granted. But I think the underlying aggregates should get a 'default return' semantic.
20:21 pmichaud_ without me having to always check "do you really have an element there, or did you just default one?"
20:22 pmichaud_ 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.
20:23 pmichaud_ that's why the fetch and vivify opcodes are so elegant
20:23 Austin Alternatively, throw InvalidElementException.new().
20:23 pmichaud_ I'd prefer not to have to catch an exception on every aggregate access either.
20:23 pmichaud_ it's not necessarily an error to request  @foo[10000000]
20:23 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.
20:23 pmichaud_ but that shouldn't automatically build 10000001 elements for me
20:24 pmichaud_ and if I have to build an exception handler for every aggregate fetch, that's going to get awfully expensive.
20:24 japhb definitely.
20:25 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 pmichaud_ that becomes particularly helpful for lexpads
20:25 pmichaud_ because I can do
20:25 pmichaud_ $P0 = vivify lexpad, '$foo', undef
20:25 pmichaud_ and
20:25 pmichaud_ $P1 = vivify lexpad, '@array', array
20:25 pmichaud_ and
20:25 pmichaud_ $P2 = vivify lexpad, '%hash', hash
20:25 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.
20:25 pmichaud_ there's no way that the lexpad can know what it should default the non-existent aggregate to be
20:25 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?
20:26 pmichaud_ because the defaulting semantics really depend on context more than the underlying PMC, as my above example just showed.
20:26 pmichaud_ in the above example, the underlying PMC is always lexpad
20:26 pmichaud_ but what gets vivified depends on the HLL logic
20:26 Tene hll_map PMCNULL to Undef, obviously. ;)
20:26 pmichaud_ that would be wrong
20:26 pmichaud_ in my example above for vivifying scalar/array/hash
20:27 pmichaud_ same for fetch
20:27 Austin pmichaud: Okay. As I said, I'm abstaining on vivify - focusing on fetch.
20:27 pmichaud_ if I do a fetch of @array, I expect to get back an empty array, not an undef.
20:27 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?)
20:27 pmichaud_ if I do a fetch of %hash, I expect to get back an empty hash, not an undef
20:28 pmichaud_ 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?
20:28 pmichaud_ that works for Perl 6.  Might not work for other languages.
20:28 pmichaud_ wouldn't work for Perl 5.
20:28 pmichaud_ I said I was going to do it in NQP and Rakudo.
20:28 Austin But not soon?
20:28 pmichaud_ soon, yes.
20:29 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?
20:29 Austin So then fetch becomes mostly an expression-temporary thing, right?
20:29 pmichaud_ but even with that, both NQP and Rakudo (and PAST in general) will benefit hugely from this
20:29 kurahaupo joined #parrot
20:29 pmichaud_ fetch becomes the correct thing to use for any fetch from an aggregate
20:30 pmichaud_ because it provides sane defaulting semantics
20:30 Tene Coke: the status on the latter seems to be "not really a problem".
20:30 pmichaud_ and those defaulting semantics are under the control of the caller, not the aggregate
20:30 pmichaud_ of coure, an aggregate could choose to override that default
20:31 Austin That's my point.
20:31 pmichaud_ but that's still more generic/useful than always assigning the task to the aggregate
20:31 Coke pmichaud_: ah. is 53978 obsoleted by your recent RFC?
20:31 pmichaud_ because there are many times that the aggregate can't know what the default should be, and always returning "Undef" loses information.
20:32 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
20:32 pmichaud_ I have to go pick up kids, back in 15
20:33 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 Austin If you tell the array, "hey, return undef instead of null" you get that back, and NQP doesn't lose anything.
20:34 japhb Austin, how do you tell the array that?
20:34 japhb And how do you tell it which case to use for something like pmichaud_'s lexpad example, where the default differs on every lookup?
20:35 Austin japhb: ResizablePMCArray.new(:default($undef))
20:35 Coke austin: then you can't tell between undef and null, neh?
20:35 Austin Coke: exactly, which is the current semantics.
20:35 Coke and what if you create that array and then pass it to me?
20:35 Coke austin;and I don't expect that I'm not going to get null... boom.
20:35 Austin japhb: You're conflating vivify with fetch.
20:36 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?
20:37 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?
20:38 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 japhb But it's an ugly DRY violation to have a very similar thing implemented differently in two different places.
20:38 japhb Actually, in N+1 different places,
20:38 japhb because *every* aggregate PMC would need to include the ability to remember current default and use it.
20:38 japhb Instead of just 1.
20:39 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 Austin Since it's an aggregate problem, why not let the aggregates solve it?
20:40 chromatic Because they can't know how.
20:40 japhb My argument above stands.
20:41 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?
20:42 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 ...
20:42 japhb The aggregate is created in language A, which tells it that it's default notfound_return is foo.
20:43 japhb Language B always wants bar for it's notfound_return.
20:43 japhb You pass the aggregate from A to B and do a fetch operation.  What should be returned?
20:43 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.
20:43 japhb How did the aggregate know?
20:43 dukeleto kthakore: i got to talk to Olly from SWIG briefly, but I will talk to him more about getting SWIG to talk PIR
20:44 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 $[
20:45 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. :)
20:45 japhb LOL
20:46 japhb 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:47 japhb 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 japhb If they want that stricture, they can make a special PMC for it.  But we should not impose that on the general case.
20:48 japhb Note that pmichaud_
20:48 japhb '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"
20:49 japhb PMC always knowing its default forces "callee decide" semantics always, with no way to work around that.
20:49 * japhb done, I think
20:50 pmichaud_ back
20:50 japhb bit of a backscroll for you.  :-)
20:50 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)
20:51 chromatic pmichaud_, see http://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
20:51 pmichaud_ More to the point, NQP is not representative of the code, nor even of the code that I write in PIR
20:51 pmichaud_ an absolutely HUGE amount of code in PGE, PCT, and Rakudo depends on the semantic of a non-existent element returning NULL
20:51 pmichaud_ all of that could would need to be updated to have separate existence checks
20:52 pmichaud_ and that would be a pain
20:53 pmichaud_ 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?
20:53 purl Message for cotto stored.
20:54 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:55 Austin 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:56 Austin IMO, that's going to reduce the "problem" considerably.
20:56 pmichaud_ I agree.
20:56 pmichaud_ 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.
20:56 Austin So now it's aggregate accesses that require this fetch mojo.
20:57 pmichaud_ more to the point, I'm wanting all fetches to be aggregate fetches, instead of the separate   get_hll_global/get_global/get_roo​t_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?)
20:57 pmichaud_ no
20:57 pmichaud_ for getprop, I can use getprophash and use that with 'fetch'
20:58 Austin That sounds like "yes" to me.
20:58 pmichaud_ I don't understand the question then.
20:58 pmichaud_ I'm probably misunderstanding "it".
20:59 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.
20:59 pmichaud_ fetching currently takes place via the vtable interface
21:00 pmichaud_ any PMC that supports get_*_keyed_* would be able to be used with the fetch opcode
21:00 pmichaud_ I'm not saying we have to eliminate any existing opcode
21:00 pmichaud_ *opcodes
21:00 pmichaud_ (chromatic, I'm reviewing tests now)
21:00 Austin Right. But what about attributes and property accesses?
21:01 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.
21:01 pmichaud_ property accesses won't
21:01 pmichaud_ but attribute accesses really need separate support, a hash interface isn't completely sufficient
21:01 Austin And I'm asking, do you think the property / trait / attribute / whatever accesses will need the defaulting semantics?
21:01 pmichaud_ (we could make it sufficient, but I'm not sure that's in the cards)
21:02 pmichaud_ I don't understand "need defaulting semantics".
21:02 pmichaud_ If we want default semantics, use "fetch".
21:02 pmichaud_ If we don't want defaulting semantics, then use a normal "set" opcode
21:02 Austin Right.
21:02 pmichaud_ er
21:02 pmichaud_ getprop or getattribute
21:02 Austin So does there need to be a fetch_property $P0, 'name', $Pdefault
21:02 pmichaud_ er
21:02 pmichaud_ no
21:03 pmichaud_ there absolutely does *not* need to be a fetch_property
21:03 pmichaud_ I'm explicitly *not* proposing separate fetch_global, fetch_lex, fetch_* opcodes
21:03 pmichaud_ I'm proposing two opcodes:  "fetch" and "vivify".
21:03 pmichaud_ I'm not saying fetch and vivify for every type of thing we have.
21:04 pmichaud_ if I want to use fetch with a property, then the sequence is
21:04 pmichaud_ $P1 = getprophash $P0
21:04 pmichaud_ $P2 = fetch $P1, 'key', default
21:05 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.
21:06 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.
21:06 pmichaud_ (you're correct)
21:07 Austin Should/will object attributes always be initialized to undef?
21:07 pmichaud_ No.
21:07 pmichaud_ sometimes they're initialized to arrays or hashes
21:08 pmichaud_ and in rakudo's case, they actually get initialized to protoobjects
21:08 pmichaud_ same for lexicals
21:08 Austin But they're always initialized?
21:08 pmichaud_ in Perl 6, yes.
21:08 pmichaud_ in NQP, still to be determined.
21:08 pmichaud_ In other languages, who knows?
21:08 Austin :)
21:08 Austin But you're leaning toward 'yes'?
21:08 pmichaud_ at the moment, yes.
21:09 pmichaud_ even so, I like the clarity and parallelism that fetch provides
21:10 pmichaud_ for example, to fetch from  @foo[3]<bar>  becomes
21:10 pmichaud_ $P0 = fetch lexpad, 3, array
21:10 pmichaud_ oops
21:10 pmichaud_ $P0 = fetch lexpad, '@foo', array
21:10 Austin s/3/'foo'/?
21:10 pmichaud_ $P1 = fetch $P0, 3, hash
21:10 pmichaud_ $P2 = fetch $P1, 'bar', undef
21:11 pmichaud_ and if that is an lvalue, it becomes
21:11 pmichaud_ $P0 = vivify lexpad, '@foo', array
21:11 pmichaud_ $P1 = vivify $P0, 3, hash
21:11 pmichaud_ $P2 = vivify $P1, 'bar', undef
21:11 japhb That has the sweet taste of real cream butter.
21:12 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 pmichaud_ in other words, if I do
21:12 pmichaud_ $P0 = find_lex '@foo'
21:12 pmichaud_ $P1 = $P0[3]
21:13 pmichaud_ and   $P0 gives me back an Undef
21:13 pmichaud_ then the next operation
21:13 pmichaud_ $P2 = $P1['bar']
21:13 pmichaud_ fails
21:13 dalek lua: eccb512 | unknown++ | src/lib/complex.pir:
21:13 dalek lua: minor improvement (library complex)
21:13 pmichaud_ because $P0 didn't know what sort of element to default to
21:13 dalek lua: review: http://github.com/fperrad/lua/commit/ec​cb512e5ee9a0de94d1f1b69caa7282ad49a38b
21:14 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 pmichaud_ because both   @foo[2][4]   and @foo[3]<bar>  are valid  (i.e., @foo[2] is an Array while @foo[3] is a Hash)
21:15 pmichaud_ anyway
21:16 pmichaud_ 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 pmichaud_ and in terms of overall efficiency, the two approaches are a wash.
21:16 pmichaud_ (i.e., they both create the same number of objects)
21:17 pmichaud_ (and require roughly equivalent numbers of opcodes)
21:19 hercynium joined #parrot
21:21 pmichaud_ once again I fear I have written too much and scared everyone away.  :-(
21:21 bacek joined #parrot
21:22 moritz warnock says hi ;-)
21:22 Austin hi, brian!
21:22 pmichaud_ or otherwise made them want to leave.
21:23 * hercynium wonders if African Grey is a very smart, talkative version of Parrot :)
21:24 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.  ;-)
21:24 chromatic INCOMING.
21:24 purl incoming is https://pause.perl.org/incoming/
21:24 japhb hercynium, as a matter of fact, it is.
21:24 pmichaud_ also, note that
21:25 pmichaud_ $P0 = new ['Integer']
21:25 pmichaud_ $P0 = 123
21:25 pmichaud_ is often easier to read as
21:25 pmichaud_ $P0 = box 123
21:25 pmichaud_ A really nice programmer added that for me about a year ago.  :-)
21:25 Austin The fetch tests as written assume a default object. Shouldn't they take a default type?
21:25 pmichaud_ I think default object is more useful.
21:25 pmichaud_ and we clone that object
21:25 japhb certainly more general
21:26 Austin Ah, clone. Right.
21:26 pmichaud_ that way we can have something already set up with properties, attributes, etc.
21:27 pmichaud_ for example:
21:27 pmichaud_ $P0 = box 'xyz'
21:27 dalek parrot: r42050 | chromatic++ | trunk (2 files):
21:27 dalek parrot: [ops] Added experimental fetch ops and tests.
21:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42050/
21:27 pmichaud_ $P1 = fetch $P2, key, $P0    #  returns 'xyz' if $P2[key] non-existent
21:27 chromatic IRC message overlap makes me appreciate atomicity in a way that CS theoretical discussions of ACID never do.
21:28 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. :)
21:29 pmichaud_ from a deprecation perspective it is.  :0|
21:29 pmichaud_ I'm likely to just add a new attribute instead of :viviself, it would mean "clone this value"
21:29 Austin Ahh.
21:29 pmichaud_ for backwards compatibility we'll still support viviself, but NQP would switch to the new value
21:29 Austin So how do you handle default objects? Declare them .localpmc at the top of the sub
21:30 Austin ?
21:30 pmichaud_ sure
21:30 pmichaud_ or .const
21:31 pmichaud_ simple is to do something like
21:31 pmichaud_ .local pmc undef
21:31 pmichaud_ undef = get_hll_global ['Private'], 'undef'
21:33 pmichaud_ 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 pmichaud_ for example:   $P0 = fetch $P1, key, ['Undef']
21:34 pmichaud_ 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:36 japhb That looks like a premature optimization that turned out to be a pessimization.
21:37 japhb (Meaning I agree that looks like a bad idea)
21:37 chromatic Hmm: http://dragonegg.llvm.org/
21:38 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:39 pmichaud_ 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.
21:41 Austin What are the limitations of .const in this regard?
21:41 Austin Can I create a .const RPA pmc?
21:41 pmichaud_ yes, but it's not pretty
21:41 pmichaud_ essentially
21:41 pmichaud_ .const pmc rpa = 'foo'
21:42 pmichaud_ .sub 'foo' :immediate
21:42 pmichaud_ $P0 = new ['ResizablePMArray']
21:42 pmichaud_ .return ($P0)
21:42 pmichaud_ .end
21:42 Austin So is that how to handle hash and array defaults?
21:42 pmichaud_ NQP could certainly put that prelude at the beginning of code it generates
21:43 Austin And then the .const symbol is visible in what scope? globally, or per-sub?
21:43 pmichaud_ file scope
21:43 pmichaud_ it's visible to the compilation unit
21:43 Coke chromatic: EBREAKMANIFEST
21:44 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.
21:44 Coke (as you point out.)
21:45 pmichaud_ Coke: the original meaning of "compilation unit" in the docs was "sub"
21:46 pmichaud_ 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 pmichaud_ or something like that.
21:46 pmichaud_ anyway, it didn't fit the with the traditional notion of "compilation unit" as I'm used to the term :)
21:46 dalek rakudo: 501b4fb | (Kyle Hasselbacher)++ | t/spectest.data:
21:46 dalek rakudo: [spectest.data] moved my misplaced test
21:46 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​01b4fb08ece44433e2bbedba0ef13e3e523f883
21:46 dalek parrot: r42051 | chromatic++ | trunk/MANIFEST:
21:47 dalek parrot: Updated MANIFEST, which I forgot to do in r42050.
21:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42051/
21:47 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 :)
21:50 ttbot Parrot trunk/ r42037 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/119812.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
21:50 ttbot Parrot trunk/ r42050 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/119817.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
21:57 ttbot Parrot trunk/ r42051 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/119878.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
21:59 Austin nopaste
21:59 Austin nopaste?
21:59 purl it has been said that nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or https://trac.parrot.org/parrot/br​owser/trunk/tools/dev/nopaste.pl
22:00 Austin Should poundperl be poundparrot?
22:01 Austin http://poundparrot.pastebin.com/m70fa4b3
22:02 Austin Pmichaud, the 'contains' method here is a naive rewrite of code shown, but it doesn't include vivify.
22:02 Austin Would vivify still require .lex?
22:02 colomon joined #parrot
22:03 pmichaud_ yes, .lex is still needed -- that's what creates the lexicals in the first place
22:03 kthakore dukeleto: great!
22:04 dalek lua: 4f26945 | unknown++ | t/lua-TestMore:
22:04 dalek lua: update submodule lua-TestMore
22:04 dalek lua: review: http://github.com/fperrad/lua/commit/4f​26945a4ff6f7836b65b8c2e30f1ef6d6ff81a6
22:04 pmichaud_ Austin: I don't quite understand the point of the code.
22:05 pmichaud_ you're saying this is what it would end up being?
22:05 bacek o hai
22:05 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); }
22:06 mikehh howdy bacek
22:06 bacek mikehh: good-good.
22:07 dalek parrot: r42052 | bacek++ | trunk/t/pmc/callsignaturereturns.t:
22:07 dalek parrot: [t] Add stub test for CallSignatureReturns.
22:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42052/
22:07 Austin (Except I elided the exception handling)
22:08 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
22:08 bacek mikehh: :)
22:08 Austin Is NQP (gonna be soon) smart enough to know that $what is vivified?
22:08 pmichaud_ nqp-rx will know, yes.
22:08 mikehh maybe that should be ;_]
22:08 Austin Or is $what untrusted because it's a param?
22:10 Austin Lookups of what?
22:10 pmichaud_ .local pmc defsub
22:11 Austin Hmm. Why?
22:11 pmichaud_ defsub = get_hll_global ['_nqp'], 'defsub'
22:11 pmichaud_ so that they're all clones of the same object instead of cloning different things from different compilation units
22:11 pmichaud_ I agree that part isn't so well thought-out yet
22:12 Austin Hmm. I think the .const way can do the same thing, if you're willing to put _nqp::defsub in a library.
22:13 pmichaud_ except that .const has to link to a symbol in the current compilation unit, I think.
22:13 pmichaud_ i.e., it doesn't handle external linking.
22:14 Austin That really should get an opcode, BTW. The current behavior (PMCNULL.invoke()) isn't friendly towards recovery/debugging/overriding.
22:15 pmichaud_ agreed.
22:15 Austin I was thinking the .const would link to a trampoline that made the external call.
22:15 pmichaud_ I don't think .const does that sort of thing.
22:15 pmichaud_ here's my version
22:16 Austin Why not? .const wants a local sub, this is a local sub.
22:16 Austin It's just a sub that dispatches somewhere else.
22:16 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.
22:16 Austin But do the .const subs have to live in the same nsp as the code?
22:17 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?
22:17 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
22:18 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
22:18 pmichaud_ it's not a trampoline effect
22:18 pmichaud_ put another way, if I did
22:18 pmichaud_ $S0 = typeof array
22:18 pmichaud_ say $S0
22:18 pmichaud_ then I'd get back "ResizablePMCArray", not "Sub"
22:19 pmichaud_ (I didn't design this system, fwiw)
22:19 chromatic bacek, that's the only spot we use it in MMD.
22:20 pmichaud_ hmmm, no pastebot
22:20 pmichaud_ http://nopaste.snit.ch/18439
22:20 chromatic I don't think named arguents participate in MMD either.
22:22 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
22:23 ttbot Parrot trunk/ r42052 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/120042.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
22:23 Austin Actually, I put it on pastebin so you could edit it. :)
22:23 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
22:23 chromatic I think we can too.  I don't see where we use it in the code now, bacek.
22:24 pmichaud_ this version looks pretty darn efficient, though.
22:24 Austin Should subs have a predefined 'lexpad' symbol, a la 'self', to support viv?
22:25 pmichaud_ wouldn't hurt, but it can't be the actual LexPad PMC
22:25 pmichaud_ it has to be something else that knows how to search outer scopes
22:25 pmichaud_ and tbh, I'd like a PMC that can also search the dynamic scopes as well
22:25 pmichaud_ that's why I used "LexSearchPad" here
22:25 Austin Yeah.
22:25 pmichaud_ optimally, somethin glike:
22:25 Austin Should that be a lexpad replacement?
22:26 pmichaud_ probably not
22:26 pmichaud_ LexPads are more than just hashes.
22:26 pmichaud_ (and yet not as much as a hash)
22:26 pmichaud_ LexPads actually map symbols to registers, instead of mapping symbols to PMCs
22:27 Austin Right.
22:27 pmichaud_ I'm thinking:
22:27 pmichaud_ $P0 = new ['LexSearch']
22:27 pmichaud_ assign $P0, .LEX_SEARCH_DYNAMIC
22:27 pmichaud_ or
22:27 pmichaud_ $P0 = new ['LexSearch']
22:27 Whiteknight joined #parrot
22:27 pmichaud_ assign $P0, .LEX_SEARCH_OUTER   # this is the default
22:27 pmichaud_ and even the possibility of
22:28 bacek chromatic: Parrot_mmd_build_type_tuple_from_sig_obj
22:28 pmichaud_ $P0 = new ['LexSearch']
22:28 pmichaud_ assign $P0, .LEX_SEARCH_BOTH
22:28 chromatic Called only from CallSig's get_pmc.
22:28 Austin Is there enough information available in that call? (Can LexSearch find the right lexpad, etc.?)
22:28 pmichaud_ sure
22:29 pmichaud_ it just needs to capture the current context
22:29 pmichaud_ the context knows all of the references to its current lexpad, its caller context, and outer context
22:29 Austin Okay.
22:30 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?
22:30 pmichaud_ yes
22:30 Austin vivify $P0, '$what', defscalar
22:30 pmichaud_ $P0 = vivify lexpad, '$what', defscalar
22:30 bacek chromatic: hmm. Let me try couple of ideas.
22:31 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
22:31 pmichaud_ yes, but only one LexSearch for the entire sub
22:31 Austin Sure.
22:31 pmichaud_ and it's just LexSearch or get_namespace
22:32 pmichaud_ I don't think we need a get.*global
22:32 Austin Right, because you're going to viv those, too.
22:32 pmichaud_ well, they get viv'd by get_namespace, iirc
22:33 pmichaud_ either that or we use make_namespace
22:33 pmichaud_ (which is the viv form of get_namespace
22:33 Austin I was thinking of the symbols themselves, not hte namespaces.
22:33 Austin *the
22:33 pmichaud_ right
22:33 pmichaud_ for that it's just
22:33 pmichaud_ $P0 = get_namespace ['NS']
22:33 bacek chromatic: looks like we should do other way around: build "native signature" from string. To support unified calls from ops and C.
22:34 pmichaud_ $P1 = vivify $P0, 'key', default
22:34 Austin okay.
22:34 chromatic I'm trying to get away from building a STRING we rarely use and can rebuild when we need it anyway.
22:34 pmichaud_ and "current namespace" can be fetched at the top of the sub, same as lexpad.
22:35 Austin Another opcode, or two, there: get_[namespace, lexpad]
22:35 pmichaud_ we already have the get_namespace opcode
22:35 pmichaud_ I don't think we need a get_lexpad opcode, when we can just use  new ['LexSomething']
22:36 Austin Right, because of the search.
22:36 Austin So we need a set of lexsearch pmcs (lexical scope, caller-dynamic, caller-lexical-dynamic scope)
22:36 pmichaud_ it does somewhat make me wish we could use sentinels
22:36 pmichaud_ one lexsearch PMC could do it
22:37 pmichaud_ oh, I see what you're saying.
22:37 pmichaud_ yes, a set per scope.
22:37 pmichaud_ actually, I'm wondering if sentinels might be the way to go here
22:37 Austin Sentinels?
22:37 purl Sentinels are 65
22:37 pmichaud_ something like this:
22:37 pmichaud_ $P0 = fetch .FETCH_LEXICAL, 'key', default
22:37 pmichaud_ $P0 = fetch .FETCH_LEXICAL_DYNAMIC, 'key', default
22:38 pmichaud_ $P0 = fetch .FETCH_NAMESPACE, 'key', default
22:38 pmichaud_ $P0 = fetch $P0, 'key', default
22:38 pmichaud_ am I missing any others?
22:39 pmichaud_ the first three take integers as the first argument
22:39 pmichaud_ those integers indicate the fetch
22:39 pmichaud_ maybe .FETCH_HLL_NAMESPACE  and .FETCH_ROOT_NAMESPACE too
22:39 pmichaud_ probably less likely
22:39 pmichaud_ *although*
22:39 pmichaud_ what would be really nice is
22:39 Austin Nah, those work.
22:39 pmichaud_ .FETCH_HLL_PRIVATE
22:40 pmichaud_ to provide easy access into the private HLL namespace
22:40 pmichaud_ I'm coming up with a few places where that would be very helpful to have
22:41 Austin Yeah, that _hll namespace has always been kind of a red-headed stepchild.
22:42 dukeleto i just learned from some postgres folks that they are interested in embedding parrot. has anybody heard about this?
22:42 chromatic Yes.
22:42 dukeleto chromatic: other than josh berkus's questions at OSBridge? do you know who is actively working on it?
22:43 Austin Hey, will nqp-rx have //=?
22:43 Austin or something like it?
22:44 pmichaud_ it'll have //
22:44 chromatic I don't know anyone actively working on it,  no.
22:44 pmichaud_ we don't have assignops, because at the moment we only support binding
22:45 pmichaud_ (because parrot's assign opcodes are all screwed up too.)
22:45 Austin s'ok, // is enough
22:45 Austin Yeah, I noticed that.
22:45 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
22:46 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.
22:46 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
22:47 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
22:48 pmichaud_ .local pmc defscalar, defarray, defhash, defcode
22:48 pmichaud_ defscalar = fetch .FETCH_HLL_NAMESPACE, 'scalar', defnull
22:48 pmichaud_ defscalar = fetch .FETCH_HLL_NAMESPACE, 'array', defnull
22:48 pmichaud_ er,
22:48 pmichaud_ defarray = fetch .FETCH_HLL_NAMESPACE, 'array', defnull
22:49 pmichaud_ argggh
22:49 pmichaud_ can't type
22:49 purl that would be tkil.
22:49 pmichaud_ null defnull
22:49 pmichaud_ defscalar = fetch .FETCH_HLL_PRIVATE, 'scalar', defnull
22:49 dalek parrot: r42053 | bacek++ | trunk/src/call/args.c:
22:49 dalek parrot: [core] Poke into CallSignature directly in Parrot_pcc_merge_signature_for_tailcall
22:49 pmichaud_ defarray  = fetch .FETCH_HLL_PRIVATE, 'array', defnull
22:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42053/
22:49 pmichaud_ defhash   = fetch .FETCH_HLL_PRIVATE, 'hash', defnull
22:50 pmichaud_ 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?
22:51 darbelo dukeleto: Lack of embedders.
22:52 darbelo We don't have people in here bitching at us that our interfaces suck or got broken by release 'X'
22:52 darbelo Which means we don't know whe we screw up, which means we can fix the screw-ups.
22:52 dalek parrot: r42054 | bacek++ | trunk (2 files):
22:52 dalek parrot: [core] Update guards in Parrot_pcc_merge_signature_for_tailcall. We test argument for nullness inside
22:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42054/
22:53 pmichaud_ bah
22:53 pmichaud_ what I really want to have are predefined values for fetch
22:53 pmichaud_ .FETCH_LEXICAL
22:53 pmichaud_ .FETCH_LEXICAL_DYNAMIC
22:53 pmichaud_ .FETCH_NAMESPACE
22:53 pmichaud_ and
22:53 darbelo dukeleto: The poster child there was mod_parrot. Latest release: January 2009.
22:53 pmichaud_ .FETCH_ARRAY   # create an instance of the HLL-mapped array type
22:54 pmichaud_ .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 http://nopaste.snit.ch/18440
22:54 pmichaud_ .FETCH_HASH   # create an instance of the HLL-mapped hash type
22:54 pmichaud_ so that one can do:
22:54 pmichaud_ $P0 = vivify .FETCH_LEXICAL, '%hash', .FETCH_HASH
22:55 chromatic Padre embeds Parrot too.
22:55 dukeleto chromatic: successfully?
22:55 pmichaud_ all of which starts to sound a lot like   vivify_lex, vivify_namespace, vivify_*, etc.
22:55 fperrad msg bacek, I isolate a problem with r42039, see http://nopaste.snit.ch/18440
22:55 purl Sorry, I've never seen bacek, before.
22:55 darbelo Oh. I didn't know that.
22:56 bacek fperrad: looking
22:57 Austin pmichaud: don't forget LEXICAL_DYNAMIC_CALLER
22:57 pmichaud_ DYNAMIC is "CALLER"
22:57 Austin sure, it's vivify_lex. It's a macro.
22:58 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.
22:58 pmichaud_ find_caller_lex ought to be deprecatd
22:59 pmichaud_ 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.
22:59 pmichaud_ find_caller_lex was based on an imprecise Perl 6 definition
22:59 Austin ah
22:59 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.
22:59 ttbot Parrot trunk/ r42054 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/120179.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
23:00 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
23:00 pmichaud_ so, Perl 6 and NQP.
23:00 darbelo dukeleto: http://search.cpan.org/~szabg​ab/Padre-Plugin-Parrot-0.26/
23:00 pmichaud_ (not a fair "two languages", I admit)
23:01 Austin NQP doesn't use any of the dynamic modes, does it?
23:01 Austin It's purely lexical.
23:01 pmichaud_ the old one doesn't, because they weren't available.
23:01 pmichaud_ the new one definitely does, and it depends on them.
23:01 pmichaud_ contextual variables are incredibly useful for writing compilers.
23:01 fperrad dukeleto, thanks
23:02 Austin Okay.
23:02 Austin Here's one: what's the right code for a variable definition?
23:02 pmichaud_ in any discussion of lexicals in parrot, keep in mind that lexicals were basically broken in Parrot until a year ago.
23:02 pmichaud_ (literally "less than twelve months ago")
23:03 Austin :)
23:03 pmichaud_ so NQP is older than working lexicals by about a year.  :)
23:03 Austin Do you just do $P1 = viv_lex '$foo', undef and forget $P1?
23:03 pmichaud_ probably
23:04 pmichaud_ .lex '$foo', $P1
23:04 pmichaud_ $P2 = vivify .LEXICAL, '$foo', undef
23:04 pmichaud_ (could be viv_lex... still need to think about that a bit.)
23:04 Austin nah, call it vivify_lex
23:04 Austin I'm just lazy
23:05 pmichaud_ I was trying to avoid the opcode explosion
23:05 Austin :)
23:05 Austin What's an opcode?
23:05 purl hmmm... an opcode is not dual lived
23:05 japhb FWIW, I'd prefer different opcodes rather than single opcode with implicit switch-on-first-arg.
23:05 pmichaud_ japhb: with both fetch_* and vivify_* variants?
23:05 japhb pmichaud_, yes.
23:05 Austin I think he means instead of fetch .LEX
23:05 Austin having fetch_lex
23:05 pmichaud_ right
23:05 japhb yup
23:05 pmichaud_ so, we'd need
23:06 pmichaud_ $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"
23:06 pmichaud_ $P1 = fetch_lex 'key', default
23:06 pmichaud_ $P1 = fetch_lex_dynamic, 'key', default
23:06 pmichaud_ I'd be willing to live with those.
23:06 Austin Can we make "_lex_dynamic" be "_dynamic"
23:06 Austin ?
23:07 pmichaud_ I'm fine with that also, but I expect most of this to be generated code anyway.
23:07 Austin Sure.
23:07 pmichaud_ I chose lex_dynamic to make it clear that we're dealing with lexicals.
23:07 Austin And then 9 flavors of fetch.
23:07 pmichaud_ _dynamic by itself is a little less certain.
23:07 pmichaud_ 9 flavors?
23:07 japhb So six new ops.  <lvalue rvalue> X <generic_aggregate lex dynamic>
23:08 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>
23:08 Austin I'm still liking the namespace stuff as well.
23:09 pmichaud_ namespace is much less common in code
23:09 japhb 18
23:09 Austin What, no num?
23:09 pmichaud_ we don't key on num
23:09 Austin Aren't NQP expressions num ?
23:09 pmichaud_ only int, str, and pmc
23:09 pmichaud_ Parrot doesn't key on num, only int, str, and pmc
23:09 Austin Oksu.
23:09 Austin yikes
23:09 Austin Okay..
23:10 japhb 18 is within my personal limits for reasonable.
23:10 Austin fetch_private, fetch_root, fetch_hll, fetch_namespace?
23:10 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
23:11 pmichaud_ 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?
23:12 pmichaud_ I have places where it's starting to look useful
23:12 pmichaud_ but I tend to think in terms of "what does PAST need" as opposed to "what opcodes do I need"
23:12 pmichaud_ not every operation needs its own opcode
23:12 pmichaud_ we should have opcodes for the common ones, and uncommon ones can be put together from other opcodes
23:13 pmichaud_ fetching private can be useful but isn't nearly enough to warrant its own opcode at present
23:13 pmichaud_ it's just as easy for me to fetch the private namespace at the beginning of the sub and use that
23:13 Austin So fetch_symbol seems like a good one, then.
23:13 pmichaud_ ?
23:13 Austin OR fetch_global
23:13 Austin I guess.
23:13 pmichaud_ for _global, that's the same as namespaces
23:13 Austin Symbol from current nsp
23:14 pmichaud_ symbol from current nsp still not very common, and easy to optimize
23:14 Austin Not very common?
23:14 pmichaud_ in fact, in general
23:14 pmichaud_ fetch from current namespace only common with "our" variables
23:14 pmichaud_ those are relatively rare
23:14 Austin And subs.
23:15 plobsing joined #parrot
23:15 pmichaud_ actually, sub lookups don't use fetch at all
23:15 pmichaud_ unless you're wanting to get a handle to the sub directly
23:15 Austin But then we cross the line into "find_sub_not_null" or whatever it's called.
23:15 pmichaud_ but even then, Perl 6 has changed the spec so that subs default to lexical scope instead of package scope
23:15 pmichaud_ I haven't decided if I'll mimic that in NQP yet
23:16 pmichaud_ my current inclination is that NQP should default subs to lexical scope also.
23:16 pmichaud_ either way, sub invocation doesn't use the fetch/vivify interface.
23:16 bacek fperrad: fixed in r42055
23:17 Austin What's with subs being lexical?
23:17 pmichaud_ most things in P6 now default to being lexical scope
23:17 Austin Okay.
23:17 pmichaud_ much better control of namespaces, and more ability to optimize properly at compile-time
23:18 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
23:18 pmichaud_ well,   Foo::sub  would still likely use fetch, yes.
23:18 pmichaud_ because we have to get the symbol from the namespace
23:18 Austin So I can't say "Othernamespace::foo" anymore?
23:18 bacek fperrad: good night! And thanks for kicking some lazy developers :)
23:18 pmichaud_ sure, that works, as long as foo was declared "our"
23:18 Austin our sub foo() {} ?
23:19 dalek parrot: r42055 | bacek++ | trunk (2 files):
23:19 dalek parrot: [core] Skip empty aggregates during flattening results
23:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42055/
23:19 pmichaud_ yes
23:19 Austin public sub foo() {}
23:19 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
23:20 davidfetter dukeleto, i'm here a lot ;)
23:21 pmichaud_ where previously it defaulted to "our"
23:21 pmichaud_ the switch from "our" to "my" also means that we can heavily optimize the capture_lex rules
23:21 Austin I gather chromatic is working on fetch?
23:21 Austin Well, that's a relief.
23:22 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 :)
23:22 pmichaud_ for example:
23:22 chromatic I committed fetch earlier.
23:23 pmichaud_ foo();   {  my $x = 'xyz';  our sub foo() { say $x; } }
23:23 Austin chromatic++
23:23 Austin Got vivify, too?
23:23 chromatic I'm not sure how vivify should work yet.
23:23 Austin (backscroll)
23:24 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 pmichaud_ discussion here seems to lean towards fetch_lex and vivify_lex
23:24 chromatic I didn't follow the discussion closely enough to feel strongly about it.
23:24 pmichaud_ okay.
23:25 pmichaud_ and I'd _really_ like a way to specify something in that last parameter that says "use the HLL mapped type"
23:25 pmichaud_ e.g.    $P0 = vivify_lex '@foo', .ARRAY
23:25 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.
23:25 pmichaud_ the downside of $P0 as a lexsearch object is that we're creating lexsearch objects
23:26 pmichaud_ a new one for every context.
23:26 Austin Wouldn't those be .const?
23:26 pmichaud_ no
23:26 pmichaud_ because each object has to be tied to its context
23:26 Austin Oh, right, closures.
23:26 Austin Yeah.
23:26 Austin But wait.
23:27 Austin If the lexsearch did the lookup at runtime, that would be okay.
23:27 Austin (calltime, rather)
23:27 pmichaud_ we could certainly have a singleton that says ... right
23:27 pmichaud_ but that gets to the same issue of "how do I specify singletons"?
23:27 ttbot Parrot trunk/ r42055 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/120279.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
23:27 pmichaud_ then lexsearch is just another case of also wanting to have a way to say  defscalar, defhash, defarray, etc.
23:28 pmichaud_ I'd prefer not to create opcodes for each case
23:28 pmichaud_ although, we could query the interpreter for mapping information
23:28 pmichaud_ $P0 = getinterp
23:29 Austin Still a .const
23:29 pmichaud_ right, but it's runtime lookups
23:29 Austin For defscalar?
23:29 pmichaud_ yes.
23:29 pmichaud_ I don't see how to avoid that.
23:29 Austin Why? Hll emits the code, hll knows the type.
23:29 japhb Work that can be shared across multiple ops should not be folded into the op itself.  It should be done in separate ops.
23:30 Austin .const pmc defscalar = ...
23:30 pmichaud_ Austin:  I don't see how to get the .const initialized with the type
23:30 japhb Meaning, a sequence of ops.
23:30 pmichaud_ _unless_ you want the header code to appear in every .PIR output
23:30 pmichaud_ but then we have a problem that each compiled PIR code is actually initializing from a different object
23:30 Austin Cloning a different object, you mean?
23:30 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
23:31 pmichaud_ short answer:  I don't see how to make it work with .const
23:31 Austin When would the hll want to say that?
23:31 pmichaud_ short answer:  I don't see how to make defscalar work with .const
23:31 dukeleto davidfetter: in here?
23:31 purl in here are you *joking*?
23:32 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?
23:33 Austin Or fetch needs to do it.
23:33 Austin And viv.
23:33 pmichaud_ or we need a way to be able to get at the type mapper easily.
23:34 Austin Or we pass it a string! :-$
23:34 pmichaud_ strings bad.
23:34 pmichaud_ if for no other reason than a string can't be our default object :)
23:35 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.
23:36 pmichaud_ 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
23:37 pmichaud_ I definitely don't want a subroutine call at the beginning of every sub invocation
23:37 pmichaud_ that's taking one pcc call and turning it into two.  :-|
23:38 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?
23:38 pmichaud_ Austin: we'd still need a way to get to that PMC
23:38 dalek parrot: r42056 | bacek++ | trunk/src/call/args.c:
23:38 dalek parrot: [cage][core] Remove unused string_sig in Parrot_pcc_build_sig_object_returns_from_op
23:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42056/
23:38 Austin Sort of the reverse of the smart undef.
23:39 Austin Sure:  $P0 = new 'CloningTypeMapper'; $P0 = .ARRAY ; ...
23:39 pmichaud_ if we're doing a new, we can shortcut that altogether with
23:39 pmichaud_ $P0 = new ['Array']
23:39 pmichaud_ and get_*_global is cheaper than new anyway
23:39 Austin For some type-mapped value of array, no?
23:40 pmichaud_ we don't need type mapping in the 'new' case -- as you said, the HLL knows its own types
23:40 pmichaud_ (yes, I'm moving in circles a bit here.  I don't see the right answer yet.)
23:40 Austin Until it wants to change them.
23:41 pmichaud_ oh, the other problem with the .const form is that it only works for Parrot built-in PMCs
23:41 pmichaud_ one can't .const a dynpmc
23:41 Austin Even when the dynpmc is loaded?
23:41 pmichaud_ (at least, not yet.)
23:41 pmichaud_ even when it's loaded.
23:41 Austin Whoops.
23:42 Austin So those hlls would have to do it differently.
23:42 pmichaud_ technically, Parrot expects all hlls to create its own PMC types
23:42 pmichaud_ s/its/their/
23:42 Austin right
23:42 Austin Speaking of which, what is an 'Array' ?
23:43 pmichaud_ you mean Parrot's Array PMC?
23:43 Austin I thought it was an abstract base for [RF]*A, but apparently not.
23:43 Austin Yea.
23:43 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.
23:44 Whiteknight I wanted to delete Array, but found no support
23:44 Austin Me, too. But I think F*A might derive from it.
23:44 Whiteknight I don't think it does
23:44 Whiteknight darbelo: ping
23:45 Zak joined #parrot
23:46 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 pmichaud_ essentially the sequence would just be the sequence for any keyed aggregate, same as it is now
23:46 nopaste "bacek" at 114.73.162.96 pasted "chromatic, we really can avoid building string_sig" (36 lines) at http://nopaste.snit.ch/18441
23:47 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.
23:47 pmichaud_ the fact that PAST sometimes generates different sequences is because PAST knows more optimal forms of fetch and vivify
23:48 Whiteknight dukeleto: ping
23:48 pmichaud_ in fact, if we simply replaced the current
23:48 pmichaud_ $P0 = new ['Undef']
23:48 pmichaud_ with
23:48 pmichaud_ $P0 = clone undef
23:48 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?
23:48 pmichaud_ japhb: depends on how one defines efficiency
23:49 pmichaud_ 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 parrot-linear-algebra: 7b0fb53 | Whiteknight++ | CREDITS:
23:49 dalek parrot-linear-algebra: Add a CREDITS file
23:49 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/7b0fb53f54a7b40c7c1370b8660b98e5e79c67e1
23:49 dalek parrot-linear-algebra: 765995b | Whiteknight++ | README:
23:49 dalek parrot-linear-algebra: add a note referencing CREDITS to README
23:49 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/765995bab698c59ff576b651294868db816045d2
23:49 japhb Is there work that is semantically duplicated between the two sets of fetch sequences?
23:49 pmichaud_ I don't understand the question.
23:50 japhb pmichaud_, sorry, let me try again.  My flu-addled brain seems to be failing me.
23:50 pmichaud_ np
23:51 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:52 japhb 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
23:52 dukeleto Whiteknight: wazzup?
23:53 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 http://tt.ro.vutbr.cz/file/cmdout/120367.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
23:53 Whiteknight dukeleto: I'm breaking ground on a 2D matrix PMC, and I'm trying to figure out the best way to do indexing
23:53 japhb Those lookups can be moved out of the fetch opcode into their own pir-visible ops,
23:53 Whiteknight VTABLEs obviously only support a single index, except the ones that take a Key pmc
23:53 japhb with the fetch opcode taking the *result* of those lookups, not the sentinel values.
23:53 Whiteknight and obviously I want an interface that isn't too expensive
23:54 japhb So when I write my matrix algebra code in PIR,
23:54 pmichaud_ the "lookup the sentinels"  is actually fairly cheap
23:54 pmichaud_ that said, I see your point.
23:54 japhb I don't end up forcing the VM to do dozens of implicit lookups.
23:54 japhb Ah, good, I managed to form a coherent thought!
23:54 japhb (and there was much rejoicing)
23:54 dukeleto Whiteknight: very, very interesting
23:54 pmichaud_ i.e., I think you're saying that   fetch_lex  is quicker than fetch .LEXICAL   because we save the check for .LEXICAL
23:55 japhb pmichaud_, yes
23:55 pmichaud_ I have no problem with that.  (more)
23:55 japhb which when you do it just once, doesn't matter.  It's doing it multiple times per sub that there is a difference.
23:55 Whiteknight dukeleto: I was thinking about using a flat array PMC with a thin PIR wrapper class to precalculate offsets
23:55 dukeleto Whiteknight: if you want to optimize for performance, we can get by with only 1 index.
23:55 Whiteknight but that would still require method calls
23:56 Whiteknight 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.
23:57 japhb pmichaud_, yes, and that's the other half of what I was trying to say.
23:58 japhb 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 japhb I was trying to say that a rule of thumb is that ops should not contain redundant implicit work.
23:59 japhb (As a way to help decide which ops we want and don't.)
23:59 pmichaud_ okay, I can agree to that, I think.

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

Parrot | source cross referenced