Parrot 1.3.0 "Andean Swift" released | parrot.org
Set by moderator on 23 June 2009.
00:11 kid51 joined 00:33 cognominal joined 01:42 bacek joined 02:35 janus joined
dalek rrot: r39886 | cotto++ | branches/ops_pct:
[ops_pct] create a branch for the new PCT-based ops compiler
 03:02
03:04 bacek joined 03:50 zak_ joined
dalek ose: r42 | Austin++ | trunk/ (9 files):
Updated cl to inject -L args in front
 03:53
04:25 bacek joined
nopaste "bacek" at 114.73.27.188 pasted "Some L1 thoughts" (75 lines) at nopaste.snit.ch/17118 04:27
bacek cotto, chromatic, nopaste.snit.ch/17118 has some of ideas for required L1ops to rewrite PMC in L1. 04:28
mikehh seen kjs
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]
bacek msg cotto, nopaste.snit.ch/17118 has some of ideas for required L1ops to rewrite PMC in L1.
purl Sorry, I've never seen cotto, before.
bacek msg cotto nopaste.snit.ch/17118 has some of ideas for required L1ops to rewrite PMC in L1.
purl Message for cotto stored.
bacek msg chromatic nopaste.snit.ch/17118 has some of ideas for required L1ops to rewrite PMC in L1.
purl Message for chromatic stored.
bacek seen kj
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]
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 /
Austin Happy Wake-up-in-jail-and-call-your-mom-to-bail-you-out Day, America! 04:35
dalek ose: r43 | Austin++ | trunk/ (6 files):
Got PCT::Node almost working. Needs 'isa' fixes, 'typeof' builtin, and polish on
 05:02
05:03 Zak joined
dalek rrot: r39887 | petdance++ | trunk/src/pmc/sub.pmc:
localizing and consting
 05:05
rrot: r39888 | petdance++ | trunk (3 files):
localizing and consting
 05:18
05:27 bacek joined 06:07 flh joined 06:16 cotto joined
cotto hi 06:17
bacek_at_work, ping 06:23
also, bacek++ for writing some more L1 code, speculative though it may be 06:41
nopaste "cotto" at 72.84.3.165 pasted "possible file layout for opsc, perhaps easier to grok" (23 lines) at nopaste.snit.ch/17119 06:52
cotto bacek_at_work, I'd like your thoughts on how easy that layout is to understand and how much it dtrt. 07:06
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:07
07:17 barney joined 07:24 bacek joined
bacek cotto: It's still Sunday here! I'm not "_at_work" yet :) 07:28
cotto Gotcha. I saw the "at work" guy and not the suffixless version. 07:29
bacek I still waiting to connect "proper" internet at home... 07:30
cotto although you obviously saw something, since you're responding
bacek moritz++ # irclog.perlgeek.de ftw :)
cotto agreed 07:31
moritz++
any thoughts on the layout, or is it a bikeshed?
bacek "layout"?
cotto "cotto" at 72.84.3.165 pasted "possible file layout for opsc, perhaps easier to grok" (23 lines) at nopaste.snit.ch/17119 07:32
bacek Why drop "src"? 07:33
cotto it seems redundant
bacek good point. 07:34
btw, I spent few hours trying to understand how to replace op/vtable with L1 based one.
guess what?
purl All of the above.
bacek EPIC FAIL 07:35
purl EPIC FAIL is chopping chili and go pee without washing hands or whatever led to you being born
cotto it's hard?
bacek << purl-- >>
cotto: may be not, but I can't figure out how to do it...
cotto Yeah. There are some steps in the L1 conversion where all I can see are big question marks. 07:37
I don't doubt that they're feasible, but I'd rather build up the momentum and figure out the details jit.
Where'd you get stuck? 07:40
bacek erm. Tough questions.
Consider Integer.add, op add, and L1.
cotto I'm considering them.
bacek currently "op add" is "shortcut" for VTABLE_add(...), 07:41
if Integer.add is some kind of bytecode segment
how "op add" should be implemented? 07:42
Additional "l1vtable" in PMC?
to choose between "old" vtable and "l1vtable"
or we have to generate C version of Integer.add which will call PCCINVOKE. 07:43
?
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.
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.
I don't think so, at least. 07:46
bacek consider PCCINVOKE call from VTABLE_add
cotto That's an implementation detail of the PMC. 07:47
bacek erm... We are working on implementation details!
:)
cotto yes. Go ahead. 07:48
bacek I can't... I'm stuck... 07:49
Calling PCCINVOKE from automatically generated C stub will work.
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.
no-no-no.
Current op dispatcher is pure C
cotto so far, so good 07:51
bacek if some of ops are in L1 we need smarter dispatcher.
or use PCCINVOKE form auto-generated C stubs for L1-based ops.
eternaleye bacek: Why not 'C dispatcher dispatches L1, which dispatches PIR/PBC/PASM'
bacek and using PCCINVOKE will be slow.
cotto ah 07:52
eternaleye Then "C dispatcher" can be cgoto, jit, etc
bacek eternaleye: We can't replace whole PIR ops with L1 based in single step
cotto basically, how do we get C and L1-based opcodes to play nice
From my understanding, we don't have to.
bacek cotto: indeed
eternaleye bacek: Have the C PIR/PASM ops dispatcher call into an L1 dispatcher? 07:53
bacek eternaleye: it's single dispatcher
eternaleye bacek: But does it have to be?
cotto Until everything is L1-capable, we just convert L1 to C.
bacek eternaleye: but some of ops isn't implemented in C
cotto (automatically)
eternaleye bacek: I'm saying you need to take the microcode analogy a bit further 07:54
x86 cpus contain a risc core that executes the microcode. That microcode runs x86 ASM.
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.
bacek eternaleye: it's ultimate goal. But for time being we'll have mixed environment. And this is hardest part... 07:55
eternaleye bacek: We already can call from PIR to C and back. What part of that equationchanges when s/PIR/L1/ ? 07:56
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
Since later on, we won't _need_ to switch control back and fort 07:58
bacek eternaleye: of course... But it's still slowdown.
eternaleye bacek: Premature optimization is etc. etc.
If it's possible to do it in ~1 month, then the slowdown won't even be in a release 07:59
07:59 iblechbot joined
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.
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
cotto during the that transition time, L1 will essentially be a different C-like language 08:01
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
Thus, little performance lost
cotto bacek, In general I mean "anything that compiles to L1" by "L1"
bacek cotto: ok :)
cotto I need a word for that. that's the second time that's caused confusion. 08:03
L1-capable?
eternaleye L1-directed?
cotto That works.
It's so many more letters than "L1", though. :(
bacek actually, for this "language" we need only byte munging and "if" 08:04
eternaleye So call it L1-t for L1-targeting
bacek Level One Language :)
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...
cotto It'd be very slow, but it'd let us see them in action. 08:06
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
bacek As far as I can see there is few options to go forward:
cotto (which is emitting C), we should also work on making those ops directly runnable?
bacek 1. Implement some very-very tiny language which an emit L1 bytecode and C 08:09
2. Implement opsc which can emit L1 bytecode and C stubs with PCCINVOKE
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
cotto long-term, that's pretty accurate 08:10
bacek 3. Patch imcc to emit L1 bytecode for L1 reimplemented ops
cotto but L1 -> C is a short-term way to keep Parrot working while only a subset of the ops have been rewritten 08:11
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
eternaleye As is, the ops need to be implemented for each runcore, right? 08:13
cotto eternaleye, not currently.
They're in src/ops/foo.ops, which ops2c mangles into the various runcores
eternaleye Ah 08:14
bacek eternaleye: no, Ops2c will generate everything required.
cotto eternaleye, are you in Seattle?
eternaleye Are the ops pretty much static these days?
cotto: Yes, Kirkland
cotto eternaleye, mostly yes.
Cool. I'm in Bellevue (except not right now)
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
If the ops were still frequently changing it'd be infeasible, but as they're mostly static...
bacek but... 08:18
Wow
It's very good point!
Lets steel C generation for current ops from Ops2c
L1 still able to call C function directly 08:19
eternaleye cotto: I go to school in Bellevue. BCC.
bacek s/steel/steal/
eternaleye (well, Bellevue College now)
cotto That's not far from where I live.
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:21
eternaleye Makes sense 08:22
cotto eternaleye, do you mind writing up your suggestion and sending it to the list? 08:26
I need to go to sleep now. Good night. 08:27
eternaleye Sure
cotto thanks
bacek cotto: good night 08:29
bacek always wonder about cotto's awake time
clock?
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 /
eternaleye Message posted 09:01
purl Sorry, I've never seen poste before.
eternaleye ^^^ purlbug? 09:02
10:49 bacek joined 11:04 masak joined 12:09 ruoso joined 12:22 iblechbot joined
mikehh All tests PASS (pre/post config, smolder, fulltest) at r39888 - Ubuntu 9.04 amd64 12:26
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:29
12:53 kid51 joined
dalek rrot: r39889 | jkeenan++ | trunk/t/codingstd/c_indent.t:
Document an internal subroutine which you may use to debug c_indentation problems.
 13:14
rrot: r39890 | fperrad++ | trunk/config/gen/config_h.pm:
[config] generate a more helpful header in has_header.h
TT #764 closed by jkeenan++: t/codingstd/c_indent.t needs to handle indents after #ifdef better 13:15
mikehh All tests PASS (pre/post config, smolder, fulltest) at r39890 - Ubuntu 9.04 amd64 13:40
dalek rrot: r39891 | fperrad++ | trunk/include/parrot/parrot.h:
only include <pthread.h> in "thr_pthread.h"
 13:44
13:51 Whiteknight joined 14:02 skids joined
Whiteknight memory corruption issues are the worst 14:15
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
I get too much email
eternaleye Use a Usenet client and Gmane, much easier
Posting even works
Makes it less inbox-clogging and more like a threaded forum 14:17
Whiteknight I use gmail, which keeps things well threaded 14:18
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:19
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
eternaleye Okay
Whiteknight The L1 discussion was quite interesting 14:24
i think you're overcomplicating things though 14:25
eternaleye How so?
Whiteknight The idea of compiling L1->C is a temporary measure that allows us to rewrite ops in L1 over time
and the idea of creating a separate L1 runcore is unnecessary because we already have several opcores capable of executing bytecode 14:26
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
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
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
Essentially by moving runcores down a level of abstraction
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
ops are human readable, PBC is machine readable
it's a one-to-one mapping
jonathan
.oO( PBC is human readable when debugging the linker... )
 14:30
Those were the days. :-)
Whiteknight jonathan: in that case we're disassembling the PBC back into PASM
eternaleye Exactly. And if Ops are implemented in L1, then PBC can also be considered an abstraction over l1
Whiteknight PBC is a binary form of the instruction set
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"
PIR instructions essentially become macros for collections of L1 ops, called "superinstructions" 14:32
14:32 jq joined
Whiteknight PBC stays around as the binary format of those superinstructions, for compactness 14:32
eternaleye I think we're agreeing across each other
Whiteknight ok
eternaleye PBC stays around, yes
_How_ it gets _run_ changes
Whiteknight that doesn't change until the conversion is complete, but then yes it does change a little 14:33
what really changes is how Parrot gets built, and how PIR code is compiled
the core of Parrot doesn't change, really only the output of IMCC changes
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
*PBC
IMCC can continue outputting PBC that way
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
we already have runcores, we have plenty of them and there's no need to create another throwaway one 14:36
mj41 purl: ttbot is TapTinder build bot owned by mj41 AND reporting tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk build errors. 14:37
purl ...but ttbot is TapTinder bot. Owned by rj41...
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
Whiteknight so a second core that's equivalent to the switch core? Why not just use the existing switch core?
eternaleye purl: ttbot is also reporting tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk build errors. 14:38
purl okay, eternaleye.
mj41 ttbot? 14:39
purl ttbot is TapTinder build bot owned by mj41 and reporting tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk build errors.
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:40
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:41
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
eternaleye Sort of like uops get run by a risc CPU inside the x86 cpu
Whiteknight the behavior and performance doesn't have to change while we make the transition
i guess I also don't see how your proposed L1 core would work, and what the benefits of it would be 14:44
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
14:45 jdv79 joined
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:45
a few releases could even go out with a commandline switch that changes between the two behaviors for direct compariso 14:46
comparison
purl somebody said comparison was at idea.imsa.edu/~keithw/comp.txt
jdv79 maybe there should be a contest of how little C is in parrot
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
jdv79: Ah, but does that include generated C? 14:47
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:48
A 'tight' L1 runcore, which dispatches L1 to elementary-ops, which sits under a system dispatching PBC to L1 14:49
Eventually, IMCC or PIRC obviates the need for the second part by compiling to L1
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
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
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
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
and if the core contains checks to determine whether an op is written in C or L1, it will be slower 14:52
eternaleye Whiteknight: The point is to delete those as soon as all ops are written in L1 14:53
THe checks are the transition management system
After the transition, they aren't needed anymore
Whiteknight so then the L1 core will just be a functional duplicate of one of our other cores?
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
Whiteknight but so after PBC is deprecated and removed, what will this new core do differently from our existing cores? 14:55
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
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
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"
they will be the same cores
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:58
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
and then when everything works, we move L1 into Parrot as normal ops and take the old ops out
eternaleye Why not have a core that _just_ runs L1, and implement a PBC-runner over L1? 15:00
The microcore dispatches the superinstructions onto its own uops
in _terms_ of uops, and using uops 15:01
15:01 MoC joined
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:07
Whiteknight okay, I see what you are saying. 15:08
I expect the PIR->L1 translation will happen at runtime inside IMCC or PIRC, or whatever frontend we are using at that point
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
Whiteknight right, so the runcores will never see PBC
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
Whiteknight but it doesn't "understand PBC", it understands any bytecode, and L1 will be a bytecode
I don't think there will be any difficulties in mixing the two while we transition 15:11
cotto eternaleye++ for that charming list post 15:12
Whiteknight eternaleye++ # yes
eternaleye thanks cotto, Whiteknight!
Whiteknight okay, I am disappearing now. Latwer 15:14
Later
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
compatibility even after the transition
Thus even old, "pre-L1" PBC bundles can still be run, with all the benefits of L1
Including much simpler JIT 15:16
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
15:17 kid51 joined
eternaleye brb, breakfast 15:18
masak are tail calls treated specially in Parrot in any way? 15:19
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:20
masak oh right, the .tailcall directive. 15:22
15:26 jan joined 15:29 skids joined 15:40 Limbic_Region joined
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:41
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
eternaleye Okay
15:43 Austin joined
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
so when we load in a PBC file, we find the mapping file for that version and perform the translation
eternaleye That would be decidedly nice
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:46
apparently there are more GC heisenbugs to track down, that makes me happy 15:54
and I'm particularly happy that there is no good way to accurately reproduce them yet 15:55
</sarcasm>
and I'm double-super happy about how long it takes to run the rakudo test suite
to the max 15:56
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
I notice that fewer of the GC bugs in rakudo seem to manifest on amd64 :) 15:59
eternaleye They're afraid of you
Whiteknight I think I need to quash a few more bugs before they will be afraid of me :) 16:00
bacek_at_work: ping
eternaleye
.oO( <voice type="tinny">Come see the violence inherent in the programmer!</voice> )
 16:01
Whiteknight haha, nice
16:09 register joined
Whiteknight 1285 wallclock seconds 16:15
16:17 cognominal joined
Austin Hey, WhiteKnight: Did Todd Olson ever get that dtrace stuff working? 16:18
Whiteknight Austin: I haven't heard a word about it
Austin Boo. It would be good to have a real understanding of where PVM was spending its time...
16:18 kid51 joined
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
kid51 Good morning, Austin, et. al.
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
Austin Great news, Kid! Think of all the Parrot work you can do... :-$
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.
But I've been mulling over the idea of an East Coast hackathon in the fall.
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
Austin Kid: That would be cool. What is your skill-set, that you feel stuff is out-of-scope?
kid51 Core methodology of such a hackathon would be: Lock Whiteknight and Infinoid in a room and see what happens ;-)
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.
Austin Really?
Whiteknight kid51: good, avoid C like the plague
Austin Sweet. I have a job for you.
kid51 I envision such a hackathon as having two or three main aspects
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.
Hence, the locking of you 2 guys in a room aspect!
Whiteknight kid51: are you thinking of a one-day hackathon, or longer then that?
kid51 2nd: Major users of Parrot: People like jhorwitz (modparrot), Coke (particle), Austin (what you were proposing at Parrot workshop in Pittsburgh) 16:25
Whiteknight is Coke an east-coast guy? 16:26
16:26 cognominal joined
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
eternaleye kid51: s/particle/partcl?
kid51 eternaleye: Yes, I was trying to remember how to spell that/
Infinoid particle: the truth has been revealed :)
kid51 Coke lives 15-20 miles south of Albany NY
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.
cotto: NY state but not NY city
kid51 lives in NYC
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.
cotto yup, NY != New York City
Austin Kid51: If you've got P5 skillz, I've got a general-purpose tool that needs writing.
kid51 Austin: which?
purl i think which is too much :) or a stupid answer. No offense. :) or "to write"
Infinoid no, which is <reply> 16:30
purl okay, Infinoid.
Austin kid51: A tree testing language - so that compiler writers can make assertions about what PAST they are generating.
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.
kid51 What would we be able to accomplish if we worked F2F for, say, most of a Saturday and part of a Sunday?
Austin Cotto: Why on earth would I want to do that?
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.
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.
Whiteknight i did a lot of hacking through monday, but I was watching a lot of talks too
kid51 Hackathons tend to be more successful if they are "seeded" with a couple of hackers who really want to focus on some project.
Then you surround those seeds with other people looking to get involved. 16:34
Whiteknight sounds like a good recipe to me 16:35
16:35 tmoertel joined
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:35
tmoertel ping 16:36
tmoertel kid51: pong
kid51 Tom, first of all I want to thank you and the other Pittsburgh folks for pulling off YAPC! 16:37
tmoertel Thanks :)
kid51 Second, are you guys planning to organize a Pittsburgh Perl Workshop this October?
tmoertel We're doing a PPW for next year, but not 2009.
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
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
kid51 ... and we wouldn't want to conflict with any Perl workshops
Infinoid Austin: But more is always better. Do you have any ideas? :) 16:39
tmoertel kid51: understood. thanks for checking.
dalek rrot: r39892 | cotto++ | branches/ops_pct (16 files):
[opsc] add a makefile template and a bunch of empty files
 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.
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?
Infinoid I've done some profiling of small rakudo scripts
Austin Infinoid: (3) is not unfortunate. Statistics live in large data sets.
Infinoid Austin: It's unfortunate when it would take more than a day to run the profile :)
Austin :)
What kind of profiling exists? 16:42
Infinoid alias cgp='time valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes ../test/parrot'
Austin I've been using parrot -t, but you mentioned kgrind.
pmichaud (dtrace) Yes, Todd Olsen made very good progress with Parrot and dtrace.
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
pmichaud I had asked him to send me his scripts but that hadn't happened yet.
*hasn't
I probably just need to ping him again on it.
Austin pmichaud: Do you have an email for him?
Actually, for all the pvmw attendees?
pmichaud not directly. Might check the yapc::na site, though.
and there was the pvmw mailing list, which I think is still available. 16:44
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]" ?
Austin And the attached nopaste? Yes, I did.
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:46
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" ?
Austin PIR
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
pmichaud In the meantime, you can use :pirop("isa IPP") or :pirop("isa IP~")
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'"
pmichaud oh, you want the keyed form.
hmmm, I don't think PAST supports keyed forms yet.
it would be
two nodes
hmmmm.
Austin Maybe I don't. 16:50
But what's the string form look like?
pmichaud yeah, PAST doesn't support keys yet. It probably needs to.
There's not a reliable string form for multi-level class names.
Austin Laugh!
pmichaud Using strings to identify classes in Parrot is Evil. 16:51
Austin "You are in a maze of competing standards, all different."
So in close I want to say: if (isa node, PCT::Node) { ...}
where isa isa builtin :)
So I'm producing Op(:pirop('isa'), <var:node>, <...>) 16:52
What's the <...>? Should it be a string, or an expression that eventually calls get-class?
pmichaud I wonder if an array of strings works yet with 'isa' 16:53
$P0 = split '::', 'PCT::Node'
$I0 = isa <node>, $P0
that's _supposed_ to work, according to the docs.
Austin Really? 16:54
(Don't trust the docs.)
pmichaud yes. We're supposed to be able to use ResizableStringArray in place of keys for class identification
I *don't* trust the docs -- see TT #8. :-)
Austin :) 16:56
This pir nopaste.com/p/apLY2ZRgE produces get_string() not implemented in class 'ResizableStringArray' 16:57
pmichaud right, that's a bug. 16:58
Austin In particular: isa $I96, $P95, $P0
pmichaud this one works:
nopaste "pmichaud" at 72.181.176.220 pasted "isa from string" (14 lines) at nopaste.snit.ch/17120 16:59
Austin Okay, so I need to pass everything via get-class first.
pmichaud you're not supposed to have to do that, iirc 17:00
Austin "supposed to have to" != "need"
pmichaud I'll have to find the relevant posts from allison and then we can file a new ticket
no, I mean that the "isa" form should've worked.
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:01
pmichaud ah, the isa bug is TT #159 17:02
Austin Whoa. 17:04
I skipped over that one.
Relative to the current HLL namespace? WTF?
Outside of "one level down", is that ever a good idea? 17:05
pmichaud I don't understand. 17:08
"current HLL namespace" ne "current namespace"
Austin Allison's comment on 159 says that RSA and string namespaces are relative to the current namespace.
pmichaud no, it says "current HLL namespace" 17:09
Austin Okay.
And you're saying that "current HLL namespace" means "HLL namespace root" ?
pmichaud yes.
Austin Okay.
pmichaud "HLL namespace root" is a better way of phrasing it, yes.
Austin That's not insane.
Whew. :) 17:10
pmichaud gotta run for a bit -- bbl 17:13
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.
dalek TT #809 created by Austin_Hastings++: Opcode 'isa' does not accept RSA PMC for class
pmichaud Austin: you have to do a get_root_namespace
Austin pmichaud: ?? That kind of eliminates the RSA from the equation, no? 17:27
$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
but it's pretty clear that isa should accept an RSA (and currently doesn't) 17:29
Austin Umm
Right.
And for another HLL?
pmichaud $P0 = split '::', 'parrot::PCT::Node'
$P1 = get_class $P0
$I0 = isa <node>, $P1
oops
wait
wrong
Austin Yeah...
pmichaud $P0 = split '::', 'parrot::PCT::Node'
$P1 = get_root_namespace $P0 17:30
17:30 amuck joined
pmichaud $I0 = isa <node>, $P1 17:30
Austin get_class(get_root_namespace) ?
pmichaud (isa is also supposed to take a namespace PMC as a class identifier)
Austin Whoa.
Oh.
That's even better. 17:34
L:q 17:39
Bah.
17:49 Coke joined
dalek ose: r44 | Austin++ | trunk/ (4 files):
Got PCT::Node::node() working. Woot\\!
 17:54
ose: r45 | Austin++ | tags/0.1.0:
Release 0.1: Reimplement PCT::Node
 18:09
kudo: dfa317f | moritz++ | t/spectest.data:
two more passing test files for spectest.data
 18:15
ose: r46 | Austin++ | wiki/Milestones.wiki:
Edited wiki page through web user interface.
 18:19
18:40 bacek joined
Austin WhiteKnight++ for getting me to publish Close "too soon" 18:45
Tene Austin: interested in chatting about HLL interop today? 18:46
Austin Sure, Tene. What's up? 18:47
Tene Actually, I'll be back in a couple of minutes.
Austin brb 18:52
Tene back now
... heh
dalek ose: r47 | Austin++ | trunk/library/pct/PAST (3 files):
Added PAST files from ~compilers/pct
 18:53
Austin irb 18:58
Tene Austin: So, we were talking about some HLL stuff on the ML, right? 19:00
I'll go re-read the thread.
I remember you as still having some pending questions.
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:03
pmichaud afaik, all of the pir stuff I've written always loads what it needs. 19:04
Austin Patrick's comment that Rakudo modules load what they need makes a lot of sense to me. 19:05
pmichaud: PCT::Node doesn't load PGE
(Of course, I was probably supposed to load PAST.pbc or some such, but ...)
pmichaud Austin: PCT::Node doesn't require PGE. 19:06
if it does, I'm shocked by that.
Austin Sure it does. The .node() method does an ISA on PGE::Match
pmichaud If there's no PGE::Match class loaded, then isa returns false.
which is at least semantically correct.
Austin What's the term for a namespace/class with at least one '::' in the name? 19:07
Nested?
purl Nested is probably different from everything in catalyst i think
Tene I've also heard "subnamespace" used. 19:08
pmichaud I tend to call them multi-level class names.
jonathan I've seen multi-jointed used too.
Austin Anyway, to identify the class I have to do a get_root_namespace on the split of the classname.
jonathan Though didn't really like that one.
Austin Multilevel works for me.
jonathan Austin: Just saw your mail about close. Nice stuff! 19:09
Austin jonathan: thanks.
I'm happier than I expected to be.
pmichaud anyway, PCT::Node doesn't require PGE to run, so it doesn't load it.
Austin Okay.
pmichaud in many senses I expect PCT to be more fundamental than PGE anyway. (more)
in other words, PGE may eventually be built on PCT. 19:10
Austin pmichaud: I've been thinking the same thing.
PGE is a compiler. Compilers produce PAST. etc.
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?
:)
pmichaud slightly higher than that
like pre-compiled longest-token-matching
(in C)
Austin Ahh. 19:12
pmichaud anyway, PGE predates PCT by about two years.
which is why it's not currently built (much) on PCT :-)
Austin Yeah.
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.
And you'd get a text editor built in.
pmichaud I don't get my choice there. :-)
Austin :) :) :)
purl :) :) :) :) :) :) :) :) :)
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" ?
Austin Is it? If I call load_bytecode does it automatically search a hll-specific dir ? 19:16
pmichaud if you want to search a hll-specific dir, then I'd say one should use "load_language" 19:17
and then tell the hll-specific compiler what to load
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.
Austin So if I say "load_bytecode 'Foo/Bar.pbc'" I could be talking about close::Foo::Bar or parrot::Foo::Bar or ...
pmichaud you'd be talking about whatever Foo/Bar.pbc is first in the parrot search path. 19:19
Austin Right
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
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?
pmichaud that's not entirely designed yet (more) 19:21
but my feeling is that each compiler will likely have its own idea of search paths.
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
it won't rely on Parrot to do that search (because Parrot's search criteria are too limited for Rakudo) 19:22
Austin Good!
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.
pmichaud huh?
who is "you" in that statement?
Austin s/you/one/
s/are/is/ 19:24
pmichaud do you mean a compiler or a program or ... ?
if a program does a load_bytecode, then I expect the .pbc to know its target HLL
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.
pmichaud I think I agree with everything there except perhaps "there are two choices" :-) 19:26
(There might be more... haven't thought about it completely :)
Austin Unless it was just "I got this HLL via email, it told me I won the UK lottery, please run it."
sorry
s/HLL/bytecode file/
pmichaud I'm having trouble following terms here. 19:27
Austin ok
pmichaud HLL's don't normally call load_bytecode themselves, programs written in an HLL might do it
Austin Emit?
purl Emit is to radiate.
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 {{ ... }})
Okay.
pmichaud HLL means "high level language". Can we say "compiler" or "hll program" or something more specific?
Austin So does the pbc request that its HLL get loaded?
Sure.
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?
pmichaud that's what Rakudo does
Austin What happens if that doesn't work?
pmichaud then it should probably throw an exception
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" :-)
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.
Austin Or should it *always* load the HLL compiler?
pmichaud what is "it" here?
Austin The .pbc file
purl the .pbc file is the compiled form of the .pir (and has all of the includes already handled)
pmichaud the .pbc? 19:32
purl the .pbc is assumed to be different for each release step currently
pmichaud I think the .pbc should load whatever it needs to get its work done
for most dynamic languages, that probably includes the compiler
but it wouldn't have to
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.
Austin So how do I import symbols from an "anonymous" .pbc file?
pmichaud That's the part that Parrot hasn't designed yet. 19:33
Parrot I'm on it.
pmichaud That's why I think load_bytecode should return a handle of some sort so that we can introspect whatever got loaded.
Austin I agree.
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
Or I could see loading the .pbc and then saying "import some symbols from this namespace that you contain"
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.
Austin Which requires the compiler
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?
pmichaud the HLLCompiler object gives us a convenient place to communicate with a language
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
Austin So what kind of handle should it return? 19:37
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?
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.
[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.
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.
in Perl 6 it's handled by BEGIN/CHECK/INIT/END
Austin How does Rakudo do it?
pmichaud right now we just make sure that we put the :load :init subs in the correct sequence (more) 19:43
PAST::Block has a "loadinit" attribute that says "perform these load/init steps at the point where the block is encountered in the source"
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
(and flag it as ":load :init")
Austin Hmm. How to you recognize the "run at end" items?
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.
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.
we add more things to that placeholder as we encounter them
then when we get to the declaration, we do final class composition 19:47
all of those get placed into the .loadinit for the PAST::Block representing the class' scope
Austin Yeah, I'm doing the same thing there.
I just generate one block for namespaces, though, so I don't emit them in order. 19:49
Sorry.
I don't emit Past blocks in the order the namespace blocks occur in the source. I save them until the end
pmichaud ah. We emit them in order as we encounter them.
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. :)
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
(and in PGE)
Austin Anyway, if class Foo uses an instance of class Bar, I need to pick that up...
Which means I probably need to differentiate between class definition and class initialization. :( 19:52
Okay. 19:53
For plain old code, I think there needs to be a queue of some kind. 19:54
pmichaud ...queue?
Austin Yeah, run this stuff in this order.
pmichaud that just sounds like using .loadinit on your TOP level block
Austin I'm thinking of :main
Compilers don't run it.
pmichaud the only time :main gets run is when the .pbc is loaded directly from the parrot command line 19:55
granted that compilers don't run it, but neither does anything else.
Austin Yeah. All my test scripts have this little hook at the bottom: void _runner() :init :load { test(); }
pmichaud that's effectively what Rakudo does as well (more) 19:56
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.
Austin Which brings us back on topic.
pmichaud but I've also not been able to put together a concrete proposal about it that's also coherent
Austin If the load_bytecode returned a handle, the follow-on should be simple.
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)
then there should be a way to ask that Eval PMC for subs having specific attributes
Austin handle = load_bytecode "foo/bar.pbc", PBC_RUN_LOAD
What's an Eval PMC? 19:58
pmichaud best way I can explain is by example (more)
$P0 = compreg "PIR"
$P1 = $P0('...pir source...')
the $P1 that comes back is an Eval PMC
it contains all of the subs that were part of '...pir source...'
Austin Here it is: Eval extends Sub to provide eval-like dynamic code evaluation and execution.
pmichaud it's actually an array of Subs, however 19:59
so I can iterate or index the Eval PMC to locate specific subs
Austin It is?
purl Oh no it isn't!
pmichaud sure. invoking the Eval PMC actually invokes its first sub
Austin So .invoke() just grabs [0] and invokes it?
pmichaud yes.
Austin ok
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?
pmichaud sure, a packfile PMC would be fine also
if it affords the same sorts of introspection and invocation that Eval PMC does
Austin Oh. I was thinking that the introspection should probably be in one place.
pmichaud that's fine too 20:01
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.
Austin Ahhh! My billy mays key is stuck! 20:02
:)
pmichaud billy mays key?
would that be "HERE'S HOW TO ORDER!" ?
Austin twitpic.com/8z4zf 20:03
pmichaud heh
okay... so .uc in Perl is really .billymays
Austin Nothing a little air-in-a-can couldn't cure.
Indeed. And the huffman is better.
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
Austin What is parrot good at?
pmichaud Parrot is good at frustration. It's almost as good at it as Perl 6. :-) 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"
pmichaud at least, that's the implementers' perspective.
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.
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:07
pmichaud afaik, there isn't one. 20:08
at least, there's not a canonical one.
Austin One more thing to do, then.
pmichaud there might be pieces of one scattered throughout the book(s)
and probably some ideas from various Parrot-centered presentations (including mine)
Austin Ironically, Tene wanted to talk about X-HLL stuff, but then he went quiet when you and I started up.
Well, it's a wiki. I'm counting on you to edit. 20:09
pmichaud I'll be happy to edit (more)
but at the moment my plate is looking pretty ugly, and I'm trying to clean it up a bit
unfortunately, I'm thinking that means a bit less parrot-focus for a while
I'll still be looking at PCT, NQP, and the like 20:10
jonathan holds up a "want STM and proto-regex" banner ;-)
pmichaud but I _really_ need to get to PGE refactors and rebuilding, soon.
jonathan \\o/
pmichaud and that's going to eat up a *ton* of time.
Austin Well, gimme a few weeks and you can do it in Close. :)
Tene Austin: I'm around again for a bit.
pmichaud (ever notice how Tene and pmichaud are never on the channel at the same time? ;-)
Austin LOL
Tene There's a reason for that. 20:11
Austin Maybe I should apply for one of those grants...
20:11 cognominal joined
Austin Alright. I think I've sucked up enough Pmichaud mips for one day. 20:12
pmichaud.unlock();
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:13
moo 20:14
20:25 chromatic joined
dalek kudo: 697decd | jnthn++ | src/parser/ (2 files):
STD tracking: split module_name into module_name and def_module_name.
 21:29
kudo: 9f4f04c | jnthn++ | (6 files):
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.
kudo: 8825ffd | jnthn++ | t/spectest.data:
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
kudo: fb0db6c | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
kudo: 7522d14 | jnthn++ | src/setting/traits.pm:
Remove some debug code accidentally left in.
kudo: 3e5adcb | jnthn++ | src/setting/traits.pm:
Fix/workaround in trait_mod:<of> so that variables typed with Code types work.
kudo: 252399e | jnthn++ | t/spectest.data:
S14-roles/crony.t temporarily regressed due to Very Odd Bug.
21:35 darbelo joined
dalek kudo: 0e8a86a | (Matthew Walton)++ | (3 files):
Move infix:<leg> to the setting.
 21:35
chromatic jonathan, does Rakudo's rebless_subclass op copy the PObj_is_special_PMC_FLAG in all cases where you have attached metadata? 21:37
jonathan chromatic: It doesn't explicitly copy the flags at all 21:39
chromatic: It copies the PMC struct wholesale.
Which IIRC includes the flags.
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.
(And I figure we'd notice if we were losing flags on, say, objects etc)
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:41
21:42 kid51 joined
jonathan I memcpy the PMC structs. 21:45
I guess there's always setting a breakpoint after all of that.
And checking.
purl checking is just different
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
s/of/if/
Are we losing meta-data? 21:47
chromatic I looked into the GC problems and that seemed the most likely culprit.
I'm running one of the affected spectests now with the GC Debug core.
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.
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.
chromatic What would it take to get rid of some/most/all of that code? 21:49
jonathan Somebody thinking up a different way to solve the same problem. 21:51
(Which is, an in-place change of a PMC to a object which sublcasses that PMC) 21:52
It may be possible to work something up with the copy opcode. 21:53
But really, this code isn't doing anything so crazily different to copy.
In terms of the way it treats a PMC as "something you can memcpy around" anyway.
afk for a bit 21:56
dalek rrot: r39893 | jkeenan++ | trunk/config/auto/gettext.pm:
Add capacity to use Macports version of gettext.
 22:14
22:28 bacek joined 22:36 rg1 joined, amuck joined 22:37 clunker9_ joined 22:40 Austin_at_lunch joined
chromatic jonathan, I do think adding asserts to check PObj_is_special_PMC_TEST will find some problems, both in Rakudo and Parrot. 22:47
Infinoid chromatic: do you think it's possible to put a transparent read barrier into the PMC_* macros? 22:51
In other words, do you know of any cases which access struct members without going through them?
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:52
Or else just put a magic cookie or serial number or somesuch into the high bits of the pointer value directly 22:53
(Only for debugging, not for release code) 22:54
Austin_at_lunch Hmm. 23:08
Austin So I'm readin' the code, findin' some bugs, writin' some tests. 23:09
Do I test for "currently-does" or "should do" behavior?
kid51 Both.
pmichaud Austin: depends on what code you're looking at :-)
kid51 "should do" => TODO-ed tests 23:10
bacek and little pony
Austin PAST::Node::lvalue()
bacek good morning #parrot
kid51 Ahoy bacek
Austin Good morning, Bacek.
pmichaud anyway, test for "should do" behaviors in places where it currently doesn't meet a spec 23:11
test for "currently-does" behaviors in places where the behavior needs to be preserved across supported releases 23:12
Austin You got it.
pmichaud (actually, test for "should do" behaviors if they're things that are part of the spec and ought to be present)
dalek TT #810 created by Austin_Hastings++: PCT - PAST::Val::lvalue() passes through to 'value'
pmichaud yes, I agree it should be lvalue 23:14
that's pretty interesting, though :-)
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.
pmichaud huh.
trac set me as owner? Wonder why/how that happens?
Austin Someone would have to call is-lvalue on a PAST::Val.
Probably because of the PCT subsystem 23:16
pmichaud they would have to call PAST::Value with :lvalue(0)
otherwise it dies.
but yes, having :lvalue(0) would cause the PAST::Val node to get the wrong value.
Austin Say, what does 'PAST::VarList' do? And what does bindvalue mean?
pmichaud PAST::VarList was an early attempt to handle list assignment (primarily for pynie) 23:17
it's not "official"
btw, for TT #803, the PAST dump doesn't seem to give me enough output to figure out where the problem might be
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.
pmichaud it's only an error if you try to set lvalue true. 23:18
see the next line.
"unless value ..."
Austin Right.
pmichaud so setting lvalue false would have the unintended side effect of changing the PAST::Val node's :value
yes, low-probability bug.
Austin Yes. And calling "is_lvalue" on any value that is not "false" (which is all of them by default) returns bogus data. 23:19
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...
pmichaud maybe a reference to the code that is producing the past tree itself
esp if it's written in NQP or something like that
it's okay for it to just be a link to the relevant line in googlecode
I want to verify that the problem is in PCT and not in the construction of the PAST tree 23:21
or, just write a small NQP script that produces the PAST tree, and show that the result is incorrect output.
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?
Austin This code in the compiler: nopaste.com/p/aCmlTKggH produces this output: nopaste.com/p/a0Szjf3kj 23:29
How's that? 23:30
pmichaud okay, perfect.
purl perfect is probably the enemy of good enough.
pmichaud that's clearly a PCT bug.
Austin kid51: TODO tests are just "# TODO" after the output, right? 23:31
pmichaud and an easy example for me to work from.
Austin I'm all about easy.
:)
pmichaud okay, dinnertime, then I'll see about fixing #803 and #810
thanks for tracking these down -- excellent work.
Austin ... readin' ur code, findin' ur bugz 23:32
pmichaud actually, I didn't write the code for 'attribute' :-) 23:35
So I get to plead "Innocent" to that one.
The lvalue one... yeah, that was me.
Austin Don't sweat it. One typo in 750 lines is within limits. 23:36
Way better than me.
What's the right way to implement goto in PAST? 23:37
(Feel free to have dinner before answering.)
dalek TT #811 created by bacek++: [RFC] Deprecate "new Iterator" form for creating Iterators. 23:39
TT #812 created by Austin_Hastings++: PCT - PAST::Op::lvalue() is redundant 23:42
bacek Austin: (goto) you probably need 2 nodes: PAST::Node<label> and PAST::Op<goto> 23:50
time for $dayjob 23:51
dalek TT #813 created by bacek++: [RFC] Deprecate (parts) of OrderedHash. 23:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!