Camelia, the Perl 6 bug

IRC log for #parrot, 2009-07-05

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:11 kid51 joined #parrot
00:33 cognominal joined #parrot
01:42 bacek joined #parrot
02:35 janus joined #parrot
03:02 dalek parrot: r39886 | cotto++ | branches/ops_pct:
03:02 dalek parrot: [ops_pct] create a branch for the new PCT-based ops compiler
03:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39886/
03:04 bacek joined #parrot
03:50 zak_ joined #parrot
03:53 dalek close: r42 | Austin++ | trunk/ (9 files):
03:53 dalek close: Updated cl to inject -L args in front
03:53 dalek close: review: http://code.google.com/p/close/source/detail?r=42
04:25 bacek joined #parrot
04:27 nopaste "bacek" at 114.73.27.188 pasted "Some L1 thoughts" (75 lines) at http://nopaste.snit.ch/17118
04:28 bacek cotto, chromatic, http://nopaste.snit.ch/17118 has some of ideas for required L1ops to rewrite PMC in L1.
04:28 mikehh seen kjs
04:28 purl kjs was last seen on #perl 1 years, 11 days, 12 hours, 50 minutes and 4 seconds ago, saying: yo  [Jun 23 15:33:30 2008]
04:28 bacek msg cotto, http://nopaste.snit.ch/17118 has some of ideas for required L1ops to rewrite PMC in L1.
04:28 purl Sorry, I've never seen cotto, before.
04:28 bacek msg cotto http://nopaste.snit.ch/17118 has some of ideas for required L1ops to rewrite PMC in L1.
04:28 purl Message for cotto stored.
04:28 bacek msg chromatic http://nopaste.snit.ch/17118 has some of ideas for required L1ops to rewrite PMC in L1.
04:28 purl Message for chromatic stored.
04:28 bacek seen kj
04:28 purl kj was last seen on #parrot 23 days, 10 hours, 23 minutes and 45 seconds ago, saying: (forgiving, or maybe just keeping silent)  [Jun 11 18:00:25 2009]
04:29 bacek clock?
04:29 purl bacek: LAX: Sat 9:29pm PDT / CHI: Sat 11:29pm CDT / NYC: Sun 12:29am EDT / LON: Sun 5:29am BST / BER: Sun 6:29am CEST / IND: Sun 9:59am IST / TOK: Sun 1:29pm JST / SYD: Sun 2:29pm EST /
04:35 Austin Happy Wake-up-in-jail-and-call-your-mom-to-bail-you-out Day, America!
05:02 dalek close: r43 | Austin++ | trunk/ (6 files):
05:02 dalek close: Got PCT::Node almost working. Needs 'isa' fixes, 'typeof' builtin, and polish on
05:02 dalek close: some assembly stuff.
05:02 dalek close: review: http://code.google.com/p/close/source/detail?r=43
05:03 Zak joined #parrot
05:05 dalek parrot: r39887 | petdance++ | trunk/src/pmc/sub.pmc:
05:05 dalek parrot: localizing and consting
05:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39887/
05:18 dalek parrot: r39888 | petdance++ | trunk (3 files):
05:18 dalek parrot: localizing and consting
05:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39888/
05:27 bacek joined #parrot
06:07 flh joined #parrot
06:16 cotto joined #parrot
06:17 cotto hi
06:23 cotto bacek_at_work, ping
06:41 cotto also, bacek++ for writing some more L1 code, speculative though it may be
06:52 nopaste "cotto" at 72.84.3.165 pasted "possible file layout for opsc, perhaps easier to grok" (23 lines) at http://nopaste.snit.ch/17119
07:06 cotto bacek_at_work, I'd like your thoughts on how easy that layout is to understand and how much it dtrt.
07:07 cotto When I was working on pmcc, I spent a lot of time hunting around for functions because it wasn't obvious where they should be.  I'm trying to avoid that here.
07:17 barney joined #parrot
07:24 bacek joined #parrot
07:28 bacek cotto: It's still Sunday here! I'm not "_at_work" yet :)
07:29 cotto Gotcha.  I saw the "at work" guy and not the suffixless version.
07:30 bacek I still waiting to connect "proper" internet at home...
07:30 cotto although you obviously saw something, since you're responding
07:30 bacek moritz++ # irclog.perlgeek.de ftw :)
07:31 cotto agreed
07:31 cotto moritz++
07:31 cotto any thoughts on the layout, or is it a bikeshed?
07:31 bacek "layout"?
07:32 cotto "cotto" at 72.84.3.165 pasted "possible file layout for opsc, perhaps easier to grok" (23 lines) at http://nopaste.snit.ch/17119
07:33 bacek Why drop "src"?
07:33 cotto it seems redundant
07:34 bacek good point.
07:34 bacek btw, I spent few hours trying to understand how to replace op/vtable with L1 based one.
07:34 bacek guess what?
07:34 purl All of the above.
07:35 bacek EPIC FAIL
07:35 purl EPIC FAIL is chopping chili and go pee without washing hands or whatever led to you being born
07:35 cotto it's hard?
07:35 bacek << purl-- >>
07:35 bacek cotto: may be not, but I can't figure out how to do it...
07:37 cotto Yeah.  There are some steps in the L1 conversion where all I can see are big question marks.
07:37 cotto I don't doubt that they're feasible, but I'd rather build up the momentum and figure out the details jit.
07:40 cotto Where'd you get stuck?
07:40 bacek erm. Tough questions.
07:40 bacek Consider Integer.add, op add, and L1.
07:40 cotto I'm considering them.
07:41 bacek currently "op add" is "shortcut" for VTABLE_add(...),
07:41 bacek if Integer.add is some kind of bytecode segment
07:42 bacek how "op add" should be implemented?
07:42 bacek Additional "l1vtable" in PMC?
07:42 bacek to choose between "old" vtable and "l1vtable"
07:43 bacek or we have to generate C version of  Integer.add which will call PCCINVOKE.
07:43 bacek ?
07:44 bacek Same for ops. If we have op foo implemented in L1 bytecode how we adjust dispatch to handle it?
07:44 cotto I don't see the problem.  If we're calling VTABLE_add on two PMCs (we get that info for free), we just build a vtable call to the first's add, then that add vtable function dtrt.
07:45 bacek VTABLE_add is "C". And we try to avoid it
07:45 cotto No, VTABLE functions in C don't cost us anything because we don't have to mess around with pcc to use them.
07:46 cotto I don't think so, at least.
07:46 bacek consider PCCINVOKE call from VTABLE_add
07:47 cotto That's an implementation detail of the PMC.
07:47 bacek erm... We are working on implementation details!
07:47 bacek :)
07:48 cotto yes.  Go ahead.
07:49 bacek I can't... I'm stuck...
07:49 bacek Calling PCCINVOKE from automatically generated C stub will work.
07:50 cotto So you don't see how we'd do the equivalent of a PCCINVOKE call from L1?
07:50 bacek But it will cause big slowdown.
07:50 bacek no-no-no.
07:50 bacek Current op dispatcher is pure C
07:51 cotto so far, so good
07:51 bacek if some of ops are in L1 we need smarter dispatcher.
07:51 bacek or use PCCINVOKE form auto-generated C stubs for L1-based ops.
07:51 eternaleye bacek: Why not 'C dispatcher dispatches L1, which dispatches PIR/PBC/PASM'
07:51 bacek and using PCCINVOKE will be slow.
07:52 cotto ah
07:52 eternaleye Then "C dispatcher" can be cgoto, jit, etc
07:52 bacek eternaleye: We can't replace whole PIR ops with L1 based in single step
07:52 cotto basically, how do we get C and L1-based opcodes to play nice
07:52 cotto From my understanding, we don't have to.
07:52 bacek cotto: indeed
07:53 eternaleye bacek: Have the C PIR/PASM ops dispatcher call into an L1 dispatcher?
07:53 bacek eternaleye: it's single dispatcher
07:53 eternaleye bacek: But does it have to be?
07:53 cotto Until everything is L1-capable, we just convert L1 to C.
07:53 bacek eternaleye: but some of ops isn't implemented in C
07:53 cotto (automatically)
07:54 eternaleye bacek: I'm saying you need to take the microcode analogy a bit further
07:54 eternaleye x86 cpus contain a risc core that executes the microcode. That microcode runs x86 ASM.
07:54 cotto Part of what L1 will need to do is be capable of emitting C that's functionally equivalent to the C we've got now.
07:55 bacek eternaleye: it's ultimate goal. But for time being we'll have mixed environment. And this is hardest part...
07:56 eternaleye bacek: We already can call from PIR to C and back. What part of that equationchanges when s/PIR/L1/ ?
07:57 bacek eternaleye: speed... We usually doesn't call from C to PIR in ops
07:57 eternaleye bacek: But if the stage where we have both types of ops is temporary, the speed loss is also temporary
07:58 eternaleye Since later on, we won't _need_ to switch control back and fort
07:58 bacek eternaleye: of course... But it's still slowdown.
07:58 eternaleye bacek: Premature optimization is etc. etc.
07:59 eternaleye If it's possible to do it in ~1 month, then the slowdown won't even be in a release
07:59 iblechbot joined #parrot
08:00 bacek eternaleye: oh... 1 month... You are way too optimistic...
08:00 cotto eternaleye, the expected plan is to do s/C/L1/ for a bunch of code, only going to the next step once all {ops|pmcs} are converted.
08:00 eternaleye What if we implement it as a runcore? That allows doing everything except actually translating PMCs/ops without anything changing unless you use -R l1core
08:01 cotto during the that transition time, L1 will essentially be a different C-like language
08:02 bacek cotto: no-no-no. Some HighLevelLanguageWhichEasyToCompileToL1AndC
08:02 eternaleye Then, right after a release, we can switch to l1core and immediately translate ops/etc. If the majority (or most-used) get translated, the frequency of calling between C and L1 is minimized
08:02 eternaleye Thus, little performance lost
08:02 cotto bacek, In general I mean "anything that compiles to L1" by "L1"
08:02 bacek cotto: ok :)
08:03 cotto I need a word for that.  that's the second time that's caused confusion.
08:03 cotto L1-capable?
08:03 eternaleye L1-directed?
08:03 cotto That works.
08:03 cotto It's so many more letters than "L1", though. :(
08:04 bacek actually, for this "language" we need only byte munging and "if"
08:04 eternaleye So call it L1-t for L1-targeting
08:04 bacek Level One Language :)
08:05 cotto eternaleye, there's actually a plan to implement L1 opcodes as dynops.
08:05 eternaleye But honestly, if the option is to temporarily give up some speed, in order to permanently improve the architecture...
08:06 cotto It'd be very slow, but it'd let us see them in action.
08:08 cotto eternaleye, you're saying that while we're switching ops to L1
08:08 eternaleye Alternately, you could take the existing switch-based runcore and set it up so that if an op is in a table of "these ops are in L1", it hands off the L1code bytestream to a L1 switching loop
08:08 bacek As far as I can see there is few options to go forward:
08:08 cotto (which is emitting C), we should also work on making those ops directly runnable?
08:09 bacek 1. Implement some very-very tiny language which an emit L1 bytecode and C
08:09 bacek 2. Implement opsc which can emit L1 bytecode and C stubs with PCCINVOKE
08:09 eternaleye cotto: IIUC, the plan is not to compile L1 to C, but to compile everything to L1 and make L1 the bytecode language of the virtual machine
08:10 cotto long-term, that's pretty accurate
08:10 bacek 3. Patch imcc to emit L1 bytecode for L1 reimplemented ops
08:11 cotto but L1 -> C is a short-term way to keep Parrot working while only a subset of the ops have been rewritten
08:12 eternaleye cotto: Then why go about it backwards? If the plan is to VM L1, then why compile L1 to c and run that? Why not VM the L1, and call into what residual C is needed? It puts us on a direct path (rewrite each C op and you gain more speed since it's all L1 now) to the end goal (which would be achieved immediately when the last op is translated)
08:12 bacek eternaleye: 4 cores stay on this path
08:13 eternaleye As is, the ops need to be implemented for each runcore, right?
08:13 cotto eternaleye, not currently.
08:13 cotto They're in src/ops/foo.ops, which ops2c mangles into the various runcores
08:14 eternaleye Ah
08:14 bacek eternaleye: no, Ops2c will generate everything required.
08:14 cotto eternaleye, are you in Seattle?
08:14 eternaleye Are the ops pretty much static these days?
08:14 eternaleye cotto: Yes, Kirkland
08:14 cotto eternaleye, mostly yes.
08:14 cotto Cool.  I'm in Bellevue (except not right now)
08:16 eternaleye Then why not make an L1core, that prefers L1ops and can call into Cops, and rewrite the ops into L1 _for_that_core_? Then, when they're all written (or enough that speed is no longer a problem), make L1core the default
08:16 eternaleye If the ops were still frequently changing it'd be infeasible, but as they're mostly static...
08:18 bacek but...
08:18 bacek but...
08:18 bacek Wow
08:18 bacek It's very good point!
08:18 bacek Lets steel C generation for current ops from Ops2c
08:19 bacek L1 still able to call C function directly
08:19 eternaleye cotto: I go to school in Bellevue. BCC.
08:19 bacek s/steel/steal/
08:19 eternaleye (well, Bellevue College now)
08:19 cotto That's not far from where I live.
08:21 cotto eternaleye, I think you may have a good idea.  (I need to process it more fully and I'm sleepy.)  We should probably put an L1 roadmap on the wiki so these kinds of suggestions can be added.
08:22 eternaleye Makes sense
08:26 cotto eternaleye, do you mind writing up your suggestion and sending it to the list?
08:27 cotto I need to go to sleep now.  Good night.
08:27 eternaleye Sure
08:27 cotto thanks
08:29 bacek cotto: good night
08:29 * bacek always wonder about cotto's awake time
08:29 bacek clock?
08:29 purl bacek: LAX: Sun 1:29am PDT / CHI: Sun 3:29am CDT / NYC: Sun 4:29am EDT / LON: Sun 9:29am BST / BER: Sun 10:29am CEST / IND: Sun 1:59pm IST / TOK: Sun 5:29pm JST / SYD: Sun 6:29pm EST /
09:01 eternaleye Message posted
09:01 purl Sorry, I've never seen poste before.
09:02 eternaleye ^^^ purlbug?
10:49 bacek joined #parrot
11:04 masak joined #parrot
12:09 ruoso joined #parrot
12:22 iblechbot joined #parrot
12:26 mikehh All tests PASS (pre/post config, smolder, fulltest) at r39888 - Ubuntu 9.04 amd64
12:29 mikehh rakudo gets 1 FAIL in make test/spectest -  t/spec/S10-packages/basic.rakudo but this passes the tests then exits with a segmentation fault
12:53 kid51 joined #parrot
13:14 dalek parrot: r39889 | jkeenan++ | trunk/t/codingstd/c_indent.t:
13:14 dalek parrot: Document an internal subroutine which you may use to debug c_indentation problems.
13:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39889/
13:14 dalek parrot: r39890 | fperrad++ | trunk/config/gen/config_h.pm:
13:14 dalek parrot: [config] generate a more helpful header in has_header.h
13:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39890/
13:15 dalek TT #764 closed by jkeenan++: t/codingstd/c_indent.t needs to handle indents after #ifdef better
13:40 mikehh All tests PASS (pre/post config, smolder, fulltest) at r39890 - Ubuntu 9.04 amd64
13:44 dalek parrot: r39891 | fperrad++ | trunk/include/parrot/parrot.h:
13:44 dalek parrot: only include <pthread.h> in "thr_pthread.h"
13:44 dalek parrot: avoid conflict with MinGW gcc 4.4.0, which supplies a pthread.h
13:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39891/
13:51 Whiteknight joined #parrot
14:02 skids joined #parrot
14:15 Whiteknight memory corruption issues are the worst
14:16 eternaleye Whiteknight: bacek, cotto and I had a neat conversation about implementing l1 about 6 hours ago. I posted a summary to parrot-dev, did you see it?
14:16 Whiteknight eternaleye: I haven't gotten to most of my email yest
14:16 Whiteknight I get too much email
14:16 eternaleye Use a Usenet client and Gmane, much easier
14:16 eternaleye Posting even works
14:17 eternaleye Makes it less inbox-clogging and more like a threaded forum
14:18 Whiteknight I use gmail, which keeps things well threaded
14:19 eternaleye Whiteknight: So do I, but mailing lists get even easier with usenet - instead of say, opening a thread and being presented with all the messages in a column, some collapsed, you have something more like slashdot, where you see the title and the author and choose to expand it per message, rather than per thread.
14:20 eternaleye But the messages are still arranged hierarchically
14:20 Whiteknight meh, I've seen usenet and gmane before and it doesn't fit my style of work
14:20 eternaleye Okay
14:24 Whiteknight The L1 discussion was quite interesting
14:25 Whiteknight i think you're overcomplicating things though
14:25 eternaleye How so?
14:25 Whiteknight The idea of compiling L1->C is a temporary measure that allows us to rewrite ops in L1 over time
14:26 Whiteknight and the idea of creating a separate L1 runcore is unnecessary because we already have several opcores capable of executing bytecode
14:27 Whiteknight so right now we compile Ops->C directly during the build. We change that to be Ops->L1->C so we have the L1 code but nothing changes at Parrot's level
14:27 Whiteknight then when everything is Ops->L1->C, we cut out the last step and just have Ops->L1, and execute those on our existing runcores
14:28 eternaleye I thought that PBC was implemented in terms of ops, and therefore parrot would run the L1, which would run the PBC
14:28 eternaleye Essentially by moving runcores down a level of abstraction
14:29 eternaleye That being the most direct analogue to microcode
14:29 Whiteknight PBC and ops are interchangable, they're just two different ways to write the same instructions
14:29 Whiteknight ops are human readable, PBC is machine readable
14:29 Whiteknight it's a one-to-one mapping
14:30 jonathan .oO( PBC is human readable when debugging the linker... )
14:30 jonathan Those were the days. :-)
14:30 Whiteknight jonathan: in that case we're disassembling the PBC back into PASM
14:30 eternaleye Exactly. And if Ops are implemented in L1, then PBC can also be considered an abstraction over l1
14:30 Whiteknight PBC is a binary form of the instruction set
14:31 eternaleye And microcode's purpose is to allow a Reduced Instruction Set Computer to handle the instructions of a Complex Instruction Set Computer
14:31 Whiteknight eternaleye: In an L1 world, PBC becomes the binary format of the PIR "superinstructions"
14:32 Whiteknight PIR instructions essentially become macros for collections of L1 ops, called "superinstructions"
14:32 jq joined #parrot
14:32 Whiteknight PBC stays around as the binary format of those superinstructions, for compactness
14:32 eternaleye I think we're agreeing across each other
14:32 Whiteknight ok
14:32 eternaleye PBC stays around, yes
14:32 eternaleye _How_ it gets _run_ changes
14:33 Whiteknight that doesn't change until the conversion is complete, but then yes it does change a little
14:33 Whiteknight what really changes is how Parrot gets built, and how PIR code is compiled
14:33 Whiteknight the core of Parrot doesn't change, really only the output of IMCC changes
14:34 eternaleye Why does that have to be the last thing to change though? If we make it a runcore, that is a sort of 'microcore' that runs L1 ops, and takes PBS and dispatches to L1 if available and C if not, we get the architectural advantages immediately and the efficiency advantages gradually
14:34 eternaleye *PBC
14:34 eternaleye IMCC can continue outputting PBC that way
14:35 eternaleye Then, when the transition to L1-written ops has finished, IMCC (or PIRC) can generate L1
14:35 Whiteknight That's an extra step that I don't think is necessary. Certainly plausible, but not necessary
14:36 Whiteknight we already have runcores, we have plenty of them and there's no need to create another throwaway one
14:37 mj41 purl: ttbot is TapTinder build bot owned by mj41 AND reporting http://tt.ro.vutbr.cz/buil​dstatus/pr-Parrot/rp-trunk build errors.
14:37 purl ...but ttbot is TapTinder bot. Owned by rj41...
14:37 eternaleye Whiteknight: Why would it have to be throwaway? When all ops are rewritten in L1, we can excise the C-ops-calling code, and have what is functionally equivalent to the switch core
14:37 Whiteknight so a second core that's equivalent to the switch core? Why not just use the existing switch core?
14:38 eternaleye purl: ttbot is also reporting http://tt.ro.vutbr.cz/buil​dstatus/pr-Parrot/rp-trunk build errors.
14:38 purl okay, eternaleye.
14:39 mj41 ttbot?
14:39 purl ttbot is TapTinder build bot owned by mj41 and reporting http://tt.ro.vutbr.cz/buil​dstatus/pr-Parrot/rp-trunk build errors.
14:40 eternaleye Because it needs to be non-default. It can start as a clone of the switch core, with some ops going to 'L1dispatch-land', but it needs to be separate so it can be clearly marked as experimental
14:41 eternaleye It only gets marked default once it's known to be functional. We can't do that if we alter the switch core in-place
14:42 eternaleye Also, it is conceptually a runcore, just at a lower level than the current runcores
14:42 Whiteknight eternaleye: but we don't need to alter any cores at all. We keep PBC as-is, we continue to expect that Ops are written in C, we just use L1 to write the ops and a compiler to generate the C
14:42 eternaleye Sort of like uops get run by a risc CPU inside the x86 cpu
14:42 Whiteknight the behavior and performance doesn't have to change while we make the transition
14:44 Whiteknight i guess I also don't see how your proposed L1 core would work, and what the benefits of it would be
14:45 eternaleye Whiteknight: But then we have to make an all-at-once change anyway: we switch from dispatching to L1-generated C to dispatching L1 to the elementary L1 operations
14:45 jdv79 joined #parrot
14:45 Whiteknight yes, but we could make the switch once we have all the ops written in L1, and after we've had the opportunity to test everything in place
14:46 Whiteknight a few releases could even go out with a commandline switch that changes between the two behaviors for direct compariso
14:46 Whiteknight comparison
14:46 purl somebody said comparison was at http://idea.imsa.edu/~keithw/comp.txt
14:46 jdv79 maybe there should be a contest of how little C is in parrot
14:46 eternaleye The idea of doing it as a runcore is that it allows parallel development - we can iteratively improve both the L1 dispatcher and the ops, rather than only the ops
14:47 eternaleye jdv79: Ah, but does that include generated C?
14:48 eternaleye My idea is to have it running what L1 is available right away, and excising C-calling systems as we eliminate the need for them, piecewise
14:49 eternaleye A 'tight' L1 runcore, which dispatches L1 to elementary-ops, which sits under a system dispatching PBC to L1
14:49 eternaleye Eventually, IMCC or PIRC obviates the need for the second part by compiling to L1
14:49 Whiteknight eternaleye: Like I said, it's a plausible idea, just unnecessary. If somebody produces such a core for testing and development it could be used for the transition
14:50 Whiteknight but after the transition is complete, that core will no longer be necessary
14:50 eternaleye Whiteknight: How come? Once the C-ops-calling code is excised, it is to L1 what the switch core is to PBC
14:51 Whiteknight eternaleye: we're not going to have a PBC executing core in Parrot anymore. All our existing cores will be executing L1 directly
14:51 eternaleye Exactly
14:51 Whiteknight So we're already going to have cores to execute L1, so a new core that does it more slowly is not necessary to keep
14:52 Whiteknight and if the core contains checks to determine whether an op is written in C or L1, it will be slower
14:53 eternaleye Whiteknight: The point is to delete those as soon as all ops are written in L1
14:53 eternaleye THe checks are the transition management system
14:53 eternaleye After the transition, they aren't needed anymore
14:53 Whiteknight so then the L1 core will just be a functional duplicate of one of our other cores?
14:54 Whiteknight unless the new core does something functionally different after the transition is over, it is not necessary to keep it
14:54 eternaleye It'll be built for L1, rather than built for PBC and repurposed for L1. Also, it will run, _and_ the switch, cgoto, etc cores are still there. It doesn't have the risk of changing a working system in-pace. It allows a deprecation cycle for PBC
14:55 Whiteknight but so after PBC is deprecated and removed, what will this new core do differently from our existing cores?
14:56 eternaleye See the first sentence of my last message
14:56 Whiteknight I don't think that makes any sense, L1 and PBC will be executed in the same ways
14:56 eternaleye It takes on some complexity in supporting both C and L1 based ops, but reduces complexity by not having to simultaneously support PBC and L1
14:57 eternaleye Like say, the switch core would if you grafted on the ability to run L1
14:57 Whiteknight a core "built for L1" will be no different from a core "built for PBC"
14:57 Whiteknight they will be the same cores
14:58 eternaleye Whiteknight: But will they be able to run both in the same core? I think answering "yes" to that makes a whole series of things more complicated
14:59 eternaleye I'm saying leave the switch core alone, and let it dispatch PBC
14:59 Whiteknight we might run them both in the same core initially, yes. if L1 are dynops, they will be executed in the same core as "normal" ops
14:59 Whiteknight and then when everything works, we move L1 into Parrot as normal ops and take the old ops out
15:00 eternaleye Why not have a core that _just_ runs L1, and implement a PBC-runner over L1?
15:00 eternaleye The microcore dispatches the superinstructions onto its own uops
15:01 eternaleye in _terms_ of uops, and using uops
15:01 MoC joined #parrot
15:07 eternaleye If we take the switch core and make it work in such a way that if fed L1, it runs the L1 instruction set, and if fed PBC, it dispatches the PBC instruction set, we have one runcore trying to run two types of bytecode. That sounds unnecessarily complicated, especially when it involves heavy, in-place modifications to a working, relied-upon runcore
15:08 Whiteknight okay, I see what you are saying.
15:08 Whiteknight I expect the PIR->L1 translation will happen at runtime inside IMCC or PIRC, or whatever frontend we are using at that point
15:09 Whiteknight after the transition, Parrot will only execute L1, and that's all it will receive from the compiler
15:09 eternaleye yes, and it's the compiler that will use the L1-definitions of ops, rather than the runcore
15:09 Whiteknight right, so the runcores will never see PBC
15:10 Whiteknight they only get L1 and execute that like normal
15:10 eternaleye Exactly, which is why grafting L1 onto something that understands PBC doesn't make sense to me
15:10 Whiteknight but it doesn't "understand PBC", it understands any bytecode, and L1 will be a bytecode
15:11 Whiteknight I don't think there will be any difficulties in mixing the two while we transition
15:12 cotto eternaleye++ for that charming list post
15:12 Whiteknight eternaleye++ # yes
15:12 eternaleye thanks cotto, Whiteknight!
15:14 Whiteknight okay, I am disappearing now. Latwer
15:14 Whiteknight Later
15:15 eternaleye The way I see it is that, if we're implementing ops in L1, and PBC is dispatched to ops, we can not only take PIR and generate L1 instead of PBC, we can take PBC and generate L1. That's why I'm saying that generalizing runcores to "they run bytecode" is overgeneralization - if we speciate them into L1 and PBC runcores, we can later on make it so that the PBC runcores are frontends to a runtime PBC->L1 translater, which provides
15:15 eternaleye compatibility even after the transition
15:15 eternaleye Thus even old, "pre-L1" PBC bundles can still be run, with all the benefits of L1
15:16 eternaleye Including much simpler JIT
15:17 eternaleye I'm finding that I seem to have more ideas when I forget to sleep than any other time. However, correlation is not causation - it may be I forget to sleep when I have ideas ;D
15:17 kid51 joined #parrot
15:18 eternaleye brb, breakfast
15:19 masak are tail calls treated specially in Parrot in any way?
15:20 eternaleye Well, IIRC, PIR has a .tailcall directive, so I'd think so - though it might just be a hint to the compiler that isn't made use of yet
15:22 masak oh right, the .tailcall directive.
15:26 jan joined #parrot
15:29 skids joined #parrot
15:40 Limbic_Region joined #parrot
15:41 Whiteknight eternaleye: if we only execute L1 internally, then we don't have a PBC runcore. We might have a PBC->L1 translation step before the runcore, but not a runcore that executes PBC directly
15:43 eternaleye Whiteknight: yeah
15:43 Whiteknight and maintaining compatibility for old PBC files is a non-issue, we already arent' compatible with old PBC formats
15:43 eternaleye Okay
15:43 Austin joined #parrot
15:44 Whiteknight hopefully L1 will allow us to fix that issue, because we will be able to maintain PBC->L1 mapping files for each PBC format in the Parrot core
15:44 Whiteknight so when we load in a PBC file, we find the mapping file for that version and perform the translation
15:44 eternaleye That would be decidedly nice
15:46 Whiteknight A PBC file could also contain definitions for any dynops that they use, so we wouldn't need to bundle dynops libraries together with the PBC files that use them
15:54 Whiteknight apparently there are more GC heisenbugs to track down, that makes me happy
15:55 Whiteknight and I'm particularly happy that there is no good way to accurately reproduce them yet
15:55 Whiteknight </sarcasm>
15:55 Whiteknight and I'm double-super happy about how long it takes to run the rakudo test suite
15:56 Whiteknight to the max
15:58 eternaleye Whiteknight: Well, if you need a tester on amd64, I'll be here - I have Rakudo, and can check out other langs as-needed
15:58 Whiteknight yeah, I'm on amd64 as well
15:59 Whiteknight I notice that fewer of the GC bugs in rakudo seem to manifest on amd64 :)
15:59 eternaleye They're afraid of you
16:00 Whiteknight I think I need to quash a few more bugs before they will be afraid of me :)
16:00 Whiteknight bacek_at_work: ping
16:01 eternaleye .oO( <voice type="tinny">Come see the violence inherent in the programmer!</voice> )
16:01 Whiteknight haha, nice
16:09 register joined #parrot
16:15 Whiteknight 1285 wallclock seconds
16:17 cognominal joined #parrot
16:18 Austin Hey, WhiteKnight: Did Todd Olson ever get that dtrace stuff working?
16:18 Whiteknight Austin: I haven't heard a word about it
16:18 Austin Boo. It would be good to have a real understanding of where PVM was spending its time...
16:18 kid51 joined #parrot
16:19 Whiteknight I don't know if I ever sent you my kudos for close, it's excellent work you've got there
16:19 Austin Hello, kid51
16:19 kid51 Good morning, Austin, et. al.
16:20 * kid51 is somewhat housebound, having suffered tendonitis (or something) in R ankle on last day of YAPC
16:20 Infinoid Austin: If you're looking for decent profiling of parrot, callgrind/kcachegrind has been working quite well for me
16:20 Austin Great news, Kid! Think of all the Parrot work you can do... :-$
16:21 Austin Infinoid: Is there an archive of results?
16:21 kid51 Actually, the bulk of what needs to be done in Parrot these days is out of my scope.
16:21 kid51 But I've been mulling over the idea of an East Coast hackathon in the fall.
16:22 Infinoid Austin: Not that I know of.  The results vary quite a lot depending on what we're running.
16:22 Whiteknight kid51: that would be awesome
16:22 Austin Kid: That would be cool. What is your skill-set, that you feel stuff is out-of-scope?
16:22 kid51 Core methodology of such a hackathon would be:  Lock Whiteknight and Infinoid in a room and see what happens ;-)
16:23 Infinoid kid51: I keep telling myself that I'll meet up with you guys some time.  Please keep bugging me about that hackathon :)
16:23 kid51 My skill set is Perl 5.
16:23 Austin Really?
16:23 Whiteknight kid51: good, avoid C like the plague
16:23 Austin Sweet. I have a job for you.
16:23 kid51 I envision such a hackathon as having two or three main aspects
16:24 Whiteknight because as soon as you tell people you know C, you get stuck looking at horrible GC bug backtraces for hours
16:24 kid51 1st:  The Parrot internals, particularly refactoring and optimizing of subsystems.
16:24 kid51 Hence, the locking of you 2 guys in a room aspect!
16:24 Whiteknight kid51: are you thinking of a one-day hackathon, or longer then that?
16:25 kid51 2nd:  Major users of Parrot:  People like jhorwitz (modparrot), Coke (particle), Austin (what you were proposing at Parrot workshop in Pittsburgh)
16:26 Whiteknight is Coke an east-coast guy?
16:26 cognominal joined #parrot
16:26 Austin kid51: You mean close? I'm >< this far away from 0.1 release.
16:26 kid51 3rd:  If people on East Coast active in ongoing Perl 5 projects want to have a track in the same time/place, so much the better
16:26 eternaleye kid51: s/particle/partcl?
16:26 kid51 eternaleye:  Yes, I  was trying to remember how to spell that/
16:26 Infinoid particle: the truth has been revealed :)
16:26 kid51 Coke lives 15-20 miles south of Albany NY
16:28 cotto Whiteknight, Coke lives in NY iirc
16:28 kid51 Example of 3rd:  If Ricardo wanted to organize some Perl QA hacking during hackathon, we'd have the space available.  But we'd only commit to organizing 1st and 2nd aspects.
16:28 kid51 cotto:  NY state but not NY city
16:28 * kid51 lives in NYC
16:29 Whiteknight oh, okay
16:29 kid51 jdv79 also lives in NYC (or area) and attended Parrot Workshop in Pittsburgh, but I don't know what his ambitions re Parrot are.
16:29 cotto yup, NY != New York City
16:29 Austin Kid51: If you've got P5 skillz, I've got a general-purpose tool that needs writing.
16:29 kid51 Austin:  which?
16:29 purl i think which is too much :) or a stupid answer. No offense. :) or "to write"
16:30 Infinoid no, which is <reply>
16:30 purl okay, Infinoid.
16:30 Austin kid51: A tree testing language - so that compiler writers can make assertions about what PAST they are generating.
16:31 kid51 So, as for 1st aspect:   The way that discussion would start would be for Infinoid and Whiteknight to ask:
16:31 cotto Austin, you can play with PAST from PIR quite nicely.
16:31 kid51 What would we be able to accomplish if we worked F2F for, say, most of a Saturday and part of a Sunday?
16:31 Austin Cotto: Why on earth would I want to do that?
16:32 Whiteknight that is a good question, what could a handful of parroteers accomplish in a dedicated day of hacking?
16:32 kid51 Whiteknight:  Yes.  For example, what would we have been able to do if we had had a 3rd day of workshop in Pittsburgh.  Chances are, such a third day would have been more dedicated to coding.
16:33 Whiteknight yeah, definitely
16:33 Austin Infinoid: (On tracing) I think, considering all the noise people are making about performance, that it would make sense for there to be a standard set of performance metrics.
16:33 Whiteknight i did a lot of hacking through monday, but I was watching a lot of talks too
16:33 kid51 Hackathons tend to be more successful if they are "seeded" with a couple of hackers who really want to focus on some project.
16:34 kid51 Then you surround those seeds with other people looking to get involved.
16:35 Whiteknight sounds like a good recipe to me
16:35 tmoertel joined #parrot
16:35 kid51 So, for each major track within a hackathon, you begin by shaping the event around the people who are hot to hack on that track.
16:36 kid51 tmoertel ping
16:36 tmoertel kid51: pong
16:37 kid51 Tom, first of all I want to thank you and the other Pittsburgh folks for pulling off YAPC!
16:37 tmoertel Thanks  :)
16:37 kid51 Second, are you guys planning to organize a Pittsburgh Perl Workshop this October?
16:37 tmoertel We're doing a PPW for next year, but not 2009.
16:38 tmoertel We need a bit more breathing room for planning than 2009 would allow for.
16:38 kid51 Thanks.  I ask cause, just before you came on channel, we were floating idea of East Coast hackathon this fall
16:38 Infinoid Austin: Yes, we have a set of benchmarks under the examples/ directory.  And we've done a fair bit of work optimizing them as much as we can
16:38 kid51 ... and we wouldn't want to conflict with any Perl workshops
16:39 Infinoid Austin: But more is always better.  Do you have any ideas? :)
16:39 tmoertel kid51: understood.  thanks for checking.
16:40 dalek parrot: r39892 | cotto++ | branches/ops_pct (16 files):
16:40 dalek parrot: [opsc] add a makefile template and a bunch of empty files
16:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39892/
16:40 Austin It depends on what kind of tracing we can do. But I don't really care for benchmarks, per se. I prefer taking something real and (ab)using it. The Tcl test suite, for example, seems to be both (1) stable; and (2) representative of a language.
16:41 Infinoid Austin: and (3) unfortunately huge, though individual tests are definitely worthy of profiling
16:41 Austin Unfortunately, it's not based on PCT, which I would like to include. Maybe one of the other PCT languages has a good code set?
16:41 Infinoid I've done some profiling of small rakudo scripts
16:41 Austin Infinoid: (3) is not unfortunate. Statistics live in large data sets.
16:41 Infinoid Austin: It's unfortunate when it would take more than a day to run the profile :)
16:41 Austin :)
16:42 Austin What kind of profiling exists?
16:42 Infinoid alias cgp='time valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes ../test/parrot'
16:42 Austin I've been using parrot -t, but you mentioned kgrind.
16:42 pmichaud (dtrace)  Yes, Todd Olsen made very good progress with Parrot and dtrace.
16:43 Infinoid that will save a "callgrind.*" file, or more than one if you had more than one thread.  kcachegrind is a GUI tool to interactively interpret the results
16:43 Austin Hello, pm
16:43 pmichaud I had asked him to send me his scripts but that hadn't happened yet.
16:43 pmichaud *hasn't
16:43 pmichaud I probably just need to ping him again on it.
16:43 Austin pmichaud: Do you have an email for him?
16:43 Austin Actually, for all the pvmw attendees?
16:43 pmichaud not directly.  Might check the yapc::na site, though.
16:44 pmichaud and there was the pvmw mailing list, which I think is still available.
16:45 Austin Yeah. I was hoping to ping Krishna on some of his stuff.
16:45 pmichaud Austin: did you see my note about "Capture[0xb74b34a8]" ?
16:45 Austin And the attached nopaste? Yes, I did.
16:46 Austin I think that's a bug, but I'm not sure where. IMO, if a default to-string is going to print a class name, it should print the right one.
16:47 Austin pmichaud: Unrelated question: How should I code a PAST node for "isa"? In particular, what does the RHS look like?
16:47 pmichaud a PIR "isa"  or a P6object "isa" ?
16:47 Austin PIR
16:48 pmichaud It probably doesn't exist directly in the PAST compiler yet.  WE can add it.
16:48 Austin P6object is just a method call. But PCT supports pirop=isa
16:48 pmichaud In the meantime, you can use   :pirop("isa IPP")   or   :pirop("isa IP~")
16:49 pmichaud the first is probably preferred -- the second would use a string as a class identifier (bad)
16:49 Austin and I'm trying to make it a builtin, but the PIR isa takes things like "$I0 = isa foo, [ 'Animal' ; 'Dog' ], 'Fido'"
16:49 pmichaud oh, you want the keyed form.
16:49 pmichaud hmmm, I don't think PAST supports keyed forms yet.
16:49 pmichaud it would be
16:49 pmichaud two nodes
16:49 pmichaud hmmmm.
16:50 Austin Maybe I don't.
16:50 Austin But what's the string form look like?
16:50 pmichaud yeah, PAST doesn't support keys yet.  It probably needs to.
16:50 pmichaud There's not a reliable string form for multi-level class names.
16:50 Austin Laugh!
16:51 pmichaud Using strings to identify classes in Parrot is Evil.
16:51 Austin "You are in a maze of competing standards, all different."
16:51 Austin So in close I want to say:     if (isa node, PCT::Node) { ...}
16:51 Austin where isa isa builtin :)
16:52 Austin So I'm producing Op(:pirop('isa'), <var:node>, <...>)
16:52 Austin What's the <...>? Should it be a string, or an expression that eventually calls get-class?
16:53 pmichaud I wonder if an array of strings works yet with 'isa'
16:53 pmichaud $P0 = split '::', 'PCT::Node'
16:53 pmichaud $I0 = isa <node>, $P0
16:53 pmichaud that's _supposed_ to work, according to the docs.
16:54 Austin Really?
16:54 Austin (Don't trust the docs.)
16:54 pmichaud yes.  We're supposed to be able to use ResizableStringArray in place of keys for class identification
16:54 pmichaud I *don't* trust the docs -- see TT #8.  :-)
16:56 Austin :)
16:57 Austin This pir http://nopaste.com/p/apLY2ZRgE produces get_string() not implemented in class 'ResizableStringArray'
16:58 pmichaud right, that's a bug.
16:58 Austin In particular:     isa $I96, $P95, $P0
16:58 pmichaud this one works:
16:59 nopaste "pmichaud" at 72.181.176.220 pasted "isa from string" (14 lines) at http://nopaste.snit.ch/17120
16:59 Austin Okay, so I need to pass everything via get-class first.
17:00 pmichaud you're not supposed to have to do that, iirc
17:00 Austin "supposed to have to" != "need"
17:00 pmichaud I'll have to find the relevant posts from allison and then we can file a new ticket
17:00 pmichaud no, I mean that the "isa" form should've worked.
17:01 Austin FYI: My definition of 0.1 for Close is "able to reimplement PCT/Node.pir". This is the last problem for 0.1. I have "worked around" some issues, rather than address them in the language, but I'm still feeling pretty good about it.
17:02 pmichaud ah, the isa bug is TT #159
17:04 Austin Whoa.
17:04 Austin I skipped over that one.
17:04 Austin Relative to the current HLL namespace? WTF?
17:05 Austin Outside of "one level down", is that ever a good idea?
17:08 pmichaud I don't understand.
17:08 pmichaud "current HLL namespace" ne "current namespace"
17:08 Austin Allison's comment on 159 says that RSA and string namespaces are relative to the current namespace.
17:09 pmichaud no, it says "current HLL namespace"
17:09 Austin Okay.
17:09 Austin And you're saying that "current HLL namespace" means "HLL namespace root" ?
17:09 pmichaud yes.
17:09 Austin Okay.
17:09 pmichaud "HLL namespace root" is a better way of phrasing it, yes.
17:09 Austin That's not insane.
17:10 Austin Whew. :)
17:13 pmichaud gotta run for a bit -- bbl
17:26 Austin msg pmichaud (re: opcode 'isa' and RSA pmcs) Patrick, how can I -- or can I not -- specify a class in another HLL?
17:26 purl Message for pmichaud stored.
17:26 dalek TT #809 created by Austin_Hastings++: Opcode 'isa' does not accept RSA PMC for class
17:26 pmichaud Austin: you have to do a get_root_namespace
17:27 Austin pmichaud: ?? That kind of eliminates the RSA from the equation, no?
17:28 Austin $P0 = split '::', 'parrot::PCT::Node'
17:28 pmichaud there's still an RSA there -- it just becomes an argument to get_class instead of isa
17:29 pmichaud but it's pretty clear that isa should accept an RSA (and currently doesn't)
17:29 Austin Umm
17:29 Austin Right.
17:29 Austin And for another HLL?
17:29 pmichaud $P0 = split '::', 'parrot::PCT::Node'
17:29 pmichaud $P1 = get_class $P0
17:29 pmichaud $I0 = isa <node>, $P1
17:29 pmichaud oops
17:29 pmichaud wait
17:29 pmichaud wrong
17:29 Austin Yeah...
17:29 pmichaud $P0 = split '::', 'parrot::PCT::Node'
17:30 pmichaud $P1 = get_root_namespace $P0
17:30 amuck joined #parrot
17:30 pmichaud $I0 = isa <node>, $P1
17:30 Austin get_class(get_root_namespace) ?
17:30 pmichaud (isa is also supposed to take a namespace PMC as a class identifier)
17:30 Austin Whoa.
17:30 Austin Oh.
17:34 Austin That's even better.
17:39 Austin L:q
17:39 Austin Bah.
17:49 Coke joined #parrot
17:54 dalek close: r44 | Austin++ | trunk/ (4 files):
17:54 dalek close: Got PCT::Node::node() working. Woot\!
17:54 dalek close: review: http://code.google.com/p/close/source/detail?r=44
18:09 dalek close: r45 | Austin++ | tags/0.1.0:
18:09 dalek close: Release 0.1: Reimplement PCT::Node
18:09 dalek close: review: http://code.google.com/p/close/source/detail?r=45
18:15 dalek rakudo: dfa317f | moritz++ | t/spectest.data:
18:15 dalek rakudo: two more passing test files for spectest.data
18:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​fa317f1e9caf41cffa09d19c1daabb709cb0cdf
18:19 dalek close: r46 | Austin++ | wiki/Milestones.wiki:
18:19 dalek close: Edited wiki page through web user interface.
18:19 dalek close: review: http://code.google.com/p/close/source/detail?r=46
18:40 bacek joined #parrot
18:45 Austin WhiteKnight++ for getting me to publish Close "too soon"
18:46 Tene Austin: interested in chatting about HLL interop today?
18:47 Austin Sure, Tene. What's up?
18:47 Tene Actually, I'll be back in a couple of minutes.
18:52 Austin brb
18:52 Tene back now
18:52 Tene ... heh
18:53 dalek close: r47 | Austin++ | trunk/library/pct/PAST (3 files):
18:53 dalek close: Added PAST files from ~compilers/pct
18:53 dalek close: review: http://code.google.com/p/close/source/detail?r=47
18:58 Austin irb
19:00 Tene Austin: So, we were talking about some HLL stuff on the ML, right?
19:00 Tene I'll go re-read the thread.
19:00 Tene I remember you as still having some pending questions.
19:03 Austin I won't say I have no questions, but I'm not sure how relevant they are at this point. So far I've got a small data set. Loading someone else's PIR that doesn't load what it needs is irksome. Sort of the difference between static and dynamic linking, I guess.
19:04 pmichaud afaik, all of the pir stuff I've written always loads what it needs.
19:05 Austin Patrick's comment that Rakudo modules load what they need makes a lot of sense to me.
19:05 Austin pmichaud: PCT::Node doesn't load PGE
19:05 Austin (Of course, I was probably supposed to load PAST.pbc or some such, but ...)
19:06 pmichaud Austin: PCT::Node doesn't require PGE.
19:06 pmichaud if it does, I'm shocked by that.
19:06 Austin Sure it does. The .node() method does an ISA on PGE::Match
19:06 pmichaud If there's no PGE::Match class loaded, then isa returns false.
19:06 pmichaud which is at least semantically correct.
19:07 Austin What's the term for a namespace/class with at least one '::' in the name?
19:07 Austin Nested?
19:07 purl Nested is probably different from everything in catalyst i think
19:08 Tene I've also heard "subnamespace" used.
19:08 pmichaud I tend to call them multi-level class names.
19:08 jonathan I've seen multi-jointed used too.
19:08 Austin Anyway, to identify the class I have to do a get_root_namespace on the split of the classname.
19:08 jonathan Though didn't really like that one.
19:08 Austin Multilevel works for me.
19:09 jonathan Austin: Just saw your mail about close. Nice stuff!
19:09 Austin jonathan: thanks.
19:09 Austin I'm happier than I expected to be.
19:09 pmichaud anyway, PCT::Node doesn't require PGE to run, so it doesn't load it.
19:09 Austin Okay.
19:09 pmichaud in many senses I expect PCT to be more fundamental than PGE anyway. (more)
19:10 pmichaud in other words, PGE may eventually be built on PCT.
19:10 Austin pmichaud: I've been thinking the same thing.
19:10 Austin PGE is a compiler. Compilers produce PAST. etc.
19:11 pmichaud but I think it's also likely that PGE will end up with some custom opcodes for things that have to be fast.
19:11 Austin Like the cclass stuff?
19:11 Austin :)
19:11 pmichaud slightly higher than that
19:11 pmichaud like pre-compiled longest-token-matching
19:11 pmichaud (in C)
19:12 Austin Ahh.
19:12 pmichaud anyway, PGE predates PCT by about two years.
19:12 pmichaud which is why it's not currently built (much) on PCT :-)
19:12 Austin Yeah.
19:13 pmichaud put another way, we needed to be able to build parsers before we could build compilers :-)
19:13 Austin You know, if you'd just stick with S-exps the parser is trivial.
19:13 Austin And you'd get a text editor built in.
19:13 pmichaud I don't get my choice there.  :-)
19:13 Austin :) :) :)
19:13 purl :) :) :) :) :) :) :) :) :)
19:15 Austin So on the question of loading what you need: is there/should there be a hll-aware load_FOO?
19:15 pmichaud isn't that just "load_bytecode" ?
19:16 Austin Is it? If I call load_bytecode does it automatically search a hll-specific dir ?
19:17 pmichaud if you want to search a hll-specific dir, then I'd say one should use "load_language"
19:17 pmichaud and then tell the hll-specific compiler what to load
19:18 Austin My point is that nothing is overall-unique without the HLL name, right?
19:18 pmichaud I don't quite understand.  I probably need an example.
19:18 Austin So if I say "load_bytecode 'Foo/Bar.pbc'" I could be talking about close::Foo::Bar or parrot::Foo::Bar or ...
19:19 pmichaud you'd be talking about whatever Foo/Bar.pbc is first in the parrot search path.
19:19 Austin Right
19:19 pmichaud but in that case, Foo/Bar.pbc should know what hll it's using and dtrt as far as loading any hll-specific stuff
19:20 pmichaud if you want a *specific* Foo/Bar.pbc from a specific hll, you probably need to ask that hll for it.
19:20 Austin So should my HLL do a load of "$HLL/Foo/Bar.pbc" or should it tweak the search path or should it call load_hll_bytecode or what?
19:21 pmichaud that's not entirely designed yet (more)
19:21 pmichaud but my feeling is that each compiler will likely have its own idea of search paths.
19:21 pmichaud for example, Rakudo will search its own set of search paths and then do load_bytecode of the specific file it believes should be loaded
19:22 pmichaud it won't rely on Parrot to do that search (because Parrot's search criteria are too limited for Rakudo)
19:22 Austin Good!
19:23 pmichaud s/Rakudo will search/Rakudo searches/   # present tense, not future tense
19:23 Austin But that kind of means that if you are calling load_bytecode, you know the target HLL if it can be known.
19:23 pmichaud huh?
19:23 pmichaud who is "you" in that statement?
19:23 Austin s/you/one/
19:24 Austin s/are/is/
19:24 pmichaud do you mean a compiler or a program or ... ?
19:24 pmichaud if a program does a load_bytecode, then I expect the .pbc to know its target HLL
19:25 pmichaud but I would also expect load_bytecode to return me a handle to what is loaded, so the caller can figure out what happened.  But that doesn't exist yet in Parrot.
19:25 Austin I mean that there are two choices: either you know something about the original HLL, or you don't. And if we presume that each HLL is on its own regarding locating files, etc., then presumably the HLL wouldn't call load_bytecode without first knowing what the bytecode's HLL was.
19:26 pmichaud I think I agree with everything there except perhaps "there are two choices" :-)
19:26 pmichaud (There might be more... haven't thought about it completely :)
19:26 Austin Unless it was just "I got this HLL via email, it told me I won the UK lottery, please run it."
19:26 Austin sorry
19:26 Austin s/HLL/bytecode file/
19:27 pmichaud I'm having trouble following terms here.
19:27 Austin ok
19:27 pmichaud HLL's don't normally call load_bytecode themselves, programs written in an HLL might do it
19:27 Austin Emit?
19:27 purl Emit is to radiate.
19:28 pmichaud if someone gets a .pbc file via email, then presumably that .pbc knows what HLL it was written in.
19:28 Austin According to me, if there's an opcode being used it's the HLL's fault. (Except when you go all asm {{ ... }})
19:28 Austin Okay.
19:28 pmichaud HLL means "high level language".  Can we say "compiler" or "hll program" or something more specific?
19:28 Austin So does the pbc request that its HLL get loaded?
19:28 Austin Sure.
19:29 pmichaud sure, I think the pbc requests that its HLL gets loaded
19:29 Austin So does the .pbc file request that its required HLL support libraries/runtime get loaded?
19:29 pmichaud that's what Rakudo does
19:29 Austin What happens if that doesn't work?
19:29 pmichaud then it should probably throw an exception
19:30 Austin Ok. We like exceptions.
19:30 pmichaud but that should be true for any operation where we request something to be done and it "doesn't work"  :-)
19:31 Austin So each .pir/.pbc file is responsible for loading its "HLL runtime" if needed?
19:31 pmichaud that's the model I've been working from internally, yes.
19:31 Austin Or should it *always* load the HLL compiler?
19:31 pmichaud what is "it" here?
19:31 Austin The .pbc file
19:31 purl the .pbc file is the compiled form of the .pir (and has all of the includes already handled)
19:32 pmichaud the .pbc?
19:32 purl the .pbc is assumed to be different for each release step currently
19:32 pmichaud I think the .pbc should load whatever it needs to get its work done
19:32 pmichaud for most dynamic languages, that probably includes the compiler
19:32 pmichaud but it wouldn't have to
19:32 pmichaud one could, for example, have the compiler and runtime split, and only load the compiler in response to a HLL's "eval" call or something like that.
19:32 Austin So how do I import symbols from an "anonymous" .pbc file?
19:33 pmichaud That's the part that Parrot hasn't designed yet.
19:33 Parrot I'm on it.
19:33 pmichaud That's why I think load_bytecode should return a handle of some sort so that we can introspect whatever got loaded.
19:33 Austin I agree.
19:34 Austin Because I can easily see loading the .pbc because I'm writing a linker, say. And I don't care a fig about the compiler, etc.
19:34 Austin Or I could see loading the .pbc and then saying "import some symbols from this namespace that you contain"
19:34 pmichaud So far my ideas about that haven't gotten much traction though, so I've been working on out-of-band ways to communicate between the .pbc and the caller.
19:34 Austin Which requires the compiler
19:35 pmichaud well, it's likely that loading the runtime should go ahead and load the HLLCompiler object.... but the HLLCompiler object could be lazy about loading the other compiler components (e.g., in response to a .compile request)
19:35 Austin Tene: are you still with us?
19:35 pmichaud the HLLCompiler object gives us a convenient place to communicate with a language
19:36 Austin Ayup. Unless there's 2 of them.
19:36 pmichaud but yes, ultimately I think the fact that load_bytecode doesn't give the loaded .pbc any straightforward way to communicate back to the caller is a design problem
19:37 Austin So what kind of handle should it return?
19:38 pmichaud not sure.  The more direct question is "What do we need to do after load_bytecode?"
19:38 Austin Can I change topics slightly?
19:39 pmichaud Sure.
19:39 Austin Suppose that I'm inspecting. After loading bytecode, I want to get a list of symbols, etc. and display it in my gee-whiz gui tool.
19:41 Austin [off topic] One thing that I keep banging my head against is :init, :load, and :main. Compilers produce code but don't call :main (because they themselves are :main, I guess). And :init and :load just go "in order", so there's no good way of saying "I need to do this after all class inits are done"
19:41 pmichaud Rakudo has to manage the order of the :init :load subs it generates to make sure they're in the correct order.
19:42 Austin [off topic] I kind of suspect that I need to build some sort of queue into the Close RTL, but doesn't every language have this sort of problem?
19:42 pmichaud many languages have this issue, yes.
19:42 pmichaud in Perl 6 it's handled by   BEGIN/CHECK/INIT/END
19:42 Austin How does Rakudo do it?
19:43 pmichaud right now we just make sure that we put the :load :init subs in the correct sequence (more)
19:43 pmichaud PAST::Block has a "loadinit" attribute that says "perform these load/init steps at the point where the block is encountered in the source"
19:44 pmichaud for things that have to happen after all other initialization, we create a special PAST::Block and then make sure it's generated at the end of the output
19:44 pmichaud (and flag it as ":load :init")
19:44 Austin Hmm. How to you recognize the "run at end" items?
19:45 pmichaud in PAST?  or in Perl 6 source, or ??
19:45 Austin I'm thinking of the case where I've got a :init sub that instantiates a class. And if the class hasn't been initialized yet, blammo.
19:46 Austin In the P6 parsing.
19:46 pmichaud in the P6 parsing, we create a "class object placeholder" as soon as we encounter its declaration in the source.
19:46 pmichaud we add more things to that placeholder as we encounter them
19:47 pmichaud then when we get to the declaration, we do final class composition
19:47 pmichaud all of those get placed into the .loadinit for the PAST::Block representing the class' scope
19:47 Austin Yeah, I'm doing the same thing there.
19:49 Austin I just generate one block for namespaces, though, so I don't emit them in order.
19:49 Austin Sorry.
19:49 Austin I don't emit Past blocks in the order the namespace blocks occur in the source. I save them until the end
19:49 pmichaud ah.  We emit them in order as we encounter them.
19:50 pmichaud but Perl 6 is somewhat designed to have to be that way.
19:50 Austin I might have been able to do that if I knew what I was doing when I started. :)
19:51 pmichaud lots of things that we struggle with in Rakudo become much easier when we have contextual variables implemented (in NQP and in Rakudo)
19:51 pmichaud (and in PGE)
19:51 Austin Anyway, if class Foo uses an instance of class Bar, I need to pick that up...
19:52 Austin Which means I probably need to differentiate between class definition and class initialization. :(
19:53 Austin Okay.
19:54 Austin For plain old code, I think there needs to be a queue of some kind.
19:54 pmichaud ...queue?
19:54 Austin Yeah, run this stuff in this order.
19:54 pmichaud that just sounds like using .loadinit on your TOP level block
19:54 Austin I'm thinking of :main
19:54 Austin Compilers don't run it.
19:55 pmichaud the only time :main gets run is when the .pbc is loaded directly from the parrot command line
19:55 pmichaud granted that compilers don't run it, but neither does anything else.
19:55 Austin Yeah. All my test scripts have this little hook at the bottom: void _runner() :init :load { test(); }
19:56 pmichaud that's effectively what Rakudo does as well (more)
19:56 pmichaud I've had the discussion with Allison that we need something that acts like :main for load_bytecode, but it hasn't gone anywhere specific.
19:56 Austin Which brings us back on topic.
19:56 pmichaud but I've also not been able to put together a concrete proposal about it that's also coherent
19:56 Austin If the load_bytecode returned a handle, the follow-on should be simple.
19:57 Austin handle = load_bytecode "foo/bar.pbc"
19:57 pmichaud in some sense, the load_bytecode should return the Eval PMC that was loaded (assuming it's a Eval PMC)
19:57 pmichaud then there should be a way to ask that Eval PMC for subs having specific attributes
19:57 Austin handle = load_bytecode "foo/bar.pbc", PBC_RUN_LOAD
19:58 Austin What's an Eval PMC?
19:58 pmichaud best way I can explain is by example (more)
19:58 pmichaud $P0 = compreg "PIR"
19:58 pmichaud $P1 = $P0('...pir source...')
19:58 pmichaud the $P1 that comes back is an Eval PMC
19:58 pmichaud it contains all of the subs that were part of '...pir source...'
19:58 Austin Here it is: Eval extends Sub to provide eval-like dynamic code evaluation and execution.
19:59 pmichaud it's actually an array of Subs, however
19:59 pmichaud so I can iterate or index the Eval PMC to locate specific subs
19:59 Austin It is?
19:59 purl Oh no it isn't!
19:59 pmichaud sure.  invoking the Eval PMC actually invokes its first sub
19:59 Austin So .invoke() just grabs [0] and invokes it?
19:59 pmichaud yes.
19:59 Austin ok
20:00 pmichaud but we should also be able to search through the Eval PMC for a correctly-marked sub to invoke instead
20:00 Austin Shouldn't load_bytecode return a packfile pmc?
20:00 pmichaud sure, a packfile PMC would be fine also
20:00 pmichaud if it affords the same sorts of introspection and invocation that Eval PMC does
20:00 Austin Oh. I was thinking that the introspection should probably be in one place.
20:01 pmichaud that's fine too
20:01 pmichaud as things stand now, I know that printing an Eval PMC to a file produces a valid .pbc, so there's *some* relationship between them.  I'm just not familiar with those details yet.
20:02 Austin Ahhh! My billy mays key is stuck!
20:02 Austin :)
20:02 pmichaud billy mays key?
20:02 pmichaud would that be  "HERE'S HOW TO ORDER!"  ?
20:03 Austin http://twitpic.com/8z4zf
20:03 pmichaud heh
20:03 pmichaud okay...   so  .uc in Perl is really .billymays
20:03 Austin Nothing a little air-in-a-can couldn't cure.
20:03 Austin Indeed. And the huffman is better.
20:04 Austin Hey, here's something leftover in my list from PVMW:
20:04 pmichaud anyway, I'd be happy if load_bytecode returned the packfile pmc, and if there's a way to search through the packfile pmc for a specific sub to be invoked
20:04 Austin What is parrot good at?
20:05 pmichaud Parrot is good at frustration.  It's almost as good at it as Perl 6.  :-)
20:05 Austin :-)
20:05 Austin One of the things that Allison mentioned in her article was "there's a bunch of problems that other people have solved"
20:05 pmichaud at least, that's the implementers' perspective.
20:06 Austin And I think that while Perl6 is good for a slashdot stampede whenever it releases, Parrot needs a glossy brochure so that people can think about it separately.
20:06 pmichaud Sure.  Should be on parrot.org somewhere.
20:07 Austin I agree, but I haven't found it yet. Do you know where there is one? If there's not one, I'll start a wiki page for it.
20:08 pmichaud afaik, there isn't one.
20:08 pmichaud at least, there's not a canonical one.
20:08 Austin One more thing to do, then.
20:08 pmichaud there might be pieces of one scattered throughout the book(s)
20:08 pmichaud and probably some ideas from various Parrot-centered presentations (including mine)
20:08 Austin Ironically, Tene wanted to talk about X-HLL stuff, but then he went quiet when you and I started up.
20:09 Austin Well, it's a wiki. I'm counting on you to edit.
20:09 pmichaud I'll be happy to edit (more)
20:09 pmichaud but at the moment my plate is looking pretty ugly, and I'm trying to clean it up a bit
20:09 pmichaud unfortunately, I'm thinking that means a bit less parrot-focus for a while
20:10 pmichaud I'll still be looking at PCT, NQP, and the like
20:10 * jonathan holds up a "want STM and proto-regex" banner ;-)
20:10 pmichaud but I _really_ need to get to PGE refactors and rebuilding, soon.
20:10 jonathan \o/
20:10 pmichaud and that's going to eat up a *ton* of time.
20:10 Austin Well, gimme a few weeks and you can do it in Close. :)
20:10 Tene Austin: I'm around again for a bit.
20:10 pmichaud (ever notice how Tene and pmichaud are never on the channel at the same time?  ;-)
20:10 Austin LOL
20:11 Tene There's a reason for that.
20:11 Austin Maybe I should apply for one of those grants...
20:11 cognominal joined #parrot
20:12 Austin Alright. I think I've sucked up enough Pmichaud mips for one day.
20:12 Austin pmichaud.unlock();
20:13 * Austin sings "I can take a noun and bend it! Gimme a noun. (Bat, ball, rake and plow.) Make it a verb and really send it! (Show me how!)"
20:14 Austin moo
20:25 chromatic joined #parrot
21:29 dalek rakudo: 697decd | jnthn++ | src/parser/ (2 files):
21:29 dalek rakudo: STD tracking: split module_name into module_name and def_module_name.
21:29 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​97decd6cafd6408ecf0a0d3468c28f67f4cf1c6
21:29 dalek rakudo: 9f4f04c | jnthn++ |  (6 files):
21:29 dalek rakudo: Extensive traits refactoring. Removes a lot of custom traits dispatch code in favor of multi dispatch, changes the way we handle traits, and wipes out all remenants of trait_verb and trait_auxiliary; it's trait_mod all the way now. All traits implemented as Perl 6 multi subs in the setting, with (probably reducable) inline PIR.
21:29 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​f4f04ce54f56c94d3955f1879b2e64922f49786
21:30 dalek rakudo: 8825ffd | jnthn++ | t/spectest.data:
21:30 dalek rakudo: Regress S12-attributes/mutators.t; it got away with using an unimplemnted trait and unimplemented Proxy, so the passes were a tad bogus anyway.
21:30 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​825ffdc56ee53ab19ac4f2bbd90e6e7f96ffe7c
21:30 dalek rakudo: fb0db6c | jnthn++ | :
21:30 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
21:30 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​b0db6c03812ce603ce27c0b1302158316b3ace6
21:30 dalek rakudo: 7522d14 | jnthn++ | src/setting/traits.pm:
21:30 dalek rakudo: Remove some debug code accidentally left in.
21:30 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​522d1437dcc926244a15ed35fcb0f4cb2391571
21:30 dalek rakudo: 3e5adcb | jnthn++ | src/setting/traits.pm:
21:30 dalek rakudo: Fix/workaround in trait_mod:<of> so that variables typed with Code types work.
21:30 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​e5adcb6cc26e1969f473c0f4dcf2ce55e918ecf
21:30 dalek rakudo: 252399e | jnthn++ | t/spectest.data:
21:30 dalek rakudo: S14-roles/crony.t temporarily regressed due to Very Odd Bug.
21:30 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​52399e6984b267f4a5b89feeb75ec17c9ef85c2
21:35 darbelo joined #parrot
21:35 dalek rakudo: 0e8a86a | (Matthew Walton)++ |  (3 files):
21:35 dalek rakudo: Move infix:<leg> to the setting.
21:35 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​e8a86a7244bd22a72810a4ae75f753efb8c8017
21:37 chromatic jonathan, does Rakudo's rebless_subclass op copy the PObj_is_special_PMC_FLAG in all cases where you have attached metadata?
21:39 jonathan chromatic: It doesn't explicitly copy the flags at all
21:39 jonathan chromatic: It copies the PMC struct wholesale.
21:39 jonathan Which IIRC includes the flags.
21:40 chromatic That's how I read it to.
21:40 jonathan So unless that flag is stored separately to any other flags, I can't see how we'd lose it.
21:40 jonathan (And I figure we'd notice if we were losing flags on, say, objects etc)
21:41 chromatic You're *sure* then that if the new object has any properties stored in metadata, they get detached from the new object, the new object loses its "I have metadata!" flag, and the reblessed object gets that flag and the metadata?
21:42 kid51 joined #parrot
21:45 jonathan I memcpy the PMC structs.
21:45 jonathan I guess there's always setting a breakpoint after all of that.
21:45 jonathan And checking.
21:45 purl checking is just different
21:46 jonathan But given the metadata pointer would be copied too (OK, the pmc_ext pointer of the metadata is in there), I really find it hard to see how that could happen.
21:46 jonathan s/of/if/
21:47 jonathan Are we losing meta-data?
21:47 chromatic I looked into the GC problems and that seemed the most likely culprit.
21:47 chromatic I'm running one of the affected spectests now with the GC Debug core.
21:47 jonathan Maybe some asserts afterwards that if the metadata pointer is set and the metadata flag isn't, we explode would help us be more sure of it.
21:48 chromatic I can't reproduce these problems; that's the worst part.
21:48 jonathan But I've been over that code quite a few times, and yes it's trixy, but I haven't been able to find it wrong.
21:49 chromatic What would it take to get rid of some/most/all of that code?
21:51 jonathan Somebody thinking up a different way to solve the same problem.
21:52 jonathan (Which is, an in-place change of a PMC to a object which sublcasses that PMC)
21:53 jonathan It may be possible to work something up with the copy opcode.
21:53 jonathan But really, this code isn't doing anything so crazily different to copy.
21:53 jonathan In terms of the way it treats a PMC as "something you can memcpy around" anyway.
21:56 jonathan afk for a bit
22:14 dalek parrot: r39893 | jkeenan++ | trunk/config/auto/gettext.pm:
22:14 dalek parrot: Add capacity to use Macports version of gettext.
22:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39893/
22:28 bacek joined #parrot
22:36 rg1 joined #parrot
22:36 amuck joined #parrot
22:37 clunker9_ joined #parrot
22:40 Austin_at_lunch joined #parrot
22:47 chromatic jonathan, I do think adding asserts to check PObj_is_special_PMC_TEST will find some problems, both in Rakudo and Parrot.
22:51 Infinoid chromatic: do you think it's possible to put a transparent read barrier into the PMC_* macros?
22:51 Infinoid In other words, do you know of any cases which access struct members without going through them?
22:52 Infinoid I'm wanting to reserve a little extra space for each PMC within the arenas and offset them one dword (or whatever) every time they're reallocated, to catch dangling pointers
22:53 Infinoid Or else just put a magic cookie or serial number or somesuch into the high bits of the pointer value directly
22:54 Infinoid (Only for debugging, not for release code)
23:08 Austin_at_lunch Hmm.
23:09 Austin So I'm readin' the code, findin' some bugs, writin' some tests.
23:09 Austin Do I test for "currently-does" or "should do" behavior?
23:09 kid51 Both.
23:09 pmichaud Austin: depends on what code you're looking at :-)
23:10 kid51 "should do" => TODO-ed tests
23:10 bacek and little pony
23:10 Austin PAST::Node::lvalue()
23:10 bacek good morning #parrot
23:10 kid51 Ahoy bacek
23:10 Austin Good morning, Bacek.
23:11 pmichaud anyway, test for "should do" behaviors in places where it currently doesn't meet a spec
23:12 pmichaud test for "currently-does" behaviors in places where the behavior needs to be preserved across supported releases
23:12 Austin You got it.
23:12 pmichaud (actually, test for "should do" behaviors if they're things that are part of the spec and ought to be present)
23:12 dalek TT #810 created by Austin_Hastings++: PCT - PAST::Val::lvalue() passes through to 'value'
23:14 pmichaud yes, I agree it should be lvalue
23:14 pmichaud that's pretty interesting, though :-)
23:15 pmichaud good, you set me as owner -- I'll fix it after dinner tonight.
23:15 Austin Low-probability bug. Actually, I just submitted it. Trac set you as the owner.
23:15 pmichaud huh.
23:15 pmichaud trac set me as owner?  Wonder why/how that happens?
23:15 Austin Someone would have to call is-lvalue on a PAST::Val.
23:16 Austin Probably because of the PCT subsystem
23:16 pmichaud they would have to call PAST::Value with  :lvalue(0)
23:16 pmichaud otherwise it dies.
23:16 pmichaud but yes, having :lvalue(0) would cause the PAST::Val node to get the wrong value.
23:16 Austin Say, what does 'PAST::VarList' do? And what does bindvalue mean?
23:17 pmichaud PAST::VarList was an early attempt to handle list assignment (primarily for pynie)
23:17 pmichaud it's not "official"
23:17 pmichaud btw, for TT #803, the PAST dump doesn't seem to give me enough output to figure out where the problem might be
23:17 Austin pmichaud: No. The PIR says "unless has_value" -- you correctly coded that querying for lvalue-ness was not an error, but trying to set lvalue-ness was an error.
23:18 pmichaud it's only an error if you try to set lvalue true.
23:18 pmichaud see the next line.
23:18 pmichaud "unless value ..."
23:18 Austin Right.
23:18 pmichaud so setting lvalue false would have the unintended side effect of changing the PAST::Val node's :value
23:18 pmichaud yes, low-probability bug.
23:19 Austin Yes. And calling "is_lvalue" on any value that is not "false" (which is all of them by default) returns bogus data.
23:20 pmichaud I'm not sure about that part, but okay.
23:20 Austin About #803, what more do you need? The only thing I can think of is to do some kind of "code-my-own-dumper" to avoid the "smart" references...
23:20 pmichaud maybe a reference to the code that is producing the past tree itself
23:20 pmichaud esp if it's written in NQP or something like that
23:20 pmichaud it's okay for it to just be a link to the relevant line in googlecode
23:21 pmichaud I want to verify that the problem is in PCT and not in the construction of the PAST tree
23:21 pmichaud or, just write a small NQP script that produces the PAST tree, and show that the result is incorrect output.
23:22 Austin Hey, it's a compiler. I don't know what line does what!
23:22 pmichaud we know what the PAST tree should look like for the test2() function, yes?
23:29 Austin This code in the compiler: http://nopaste.com/p/aCmlTKggH produces this output: http://nopaste.com/p/a0Szjf3kj
23:30 Austin How's that?
23:30 pmichaud okay, perfect.
23:30 purl perfect is probably the enemy of good enough.
23:30 pmichaud that's clearly a PCT bug.
23:31 Austin kid51: TODO tests are just "# TODO" after the output, right?
23:31 pmichaud and an easy example for me to work from.
23:31 Austin I'm all about easy.
23:31 Austin :)
23:31 pmichaud okay, dinnertime, then I'll see about fixing #803 and #810
23:31 pmichaud thanks for tracking these down -- excellent work.
23:32 Austin ... readin' ur code, findin' ur bugz
23:35 pmichaud actually, I didn't write the code for 'attribute'  :-)
23:35 pmichaud So I get to plead "Innocent" to that one.
23:35 pmichaud The lvalue one... yeah, that was me.
23:36 Austin Don't sweat it. One typo in 750 lines is within limits.
23:36 Austin Way better than me.
23:37 Austin What's the right way to implement goto in PAST?
23:37 Austin (Feel free to have dinner before answering.)
23:39 dalek TT #811 created by bacek++: [RFC] Deprecate "new Iterator" form for creating Iterators.
23:42 dalek TT #812 created by Austin_Hastings++: PCT - PAST::Op::lvalue() is redundant
23:50 bacek Austin: (goto) you probably need 2 nodes: PAST::Node<label> and PAST::Op<goto>
23:51 bacek time for $dayjob
23:52 dalek TT #813 created by bacek++: [RFC] Deprecate (parts) of OrderedHash.

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

Parrot | source cross referenced