% kjs has joined #parrotsketch
% tewk has joined #parrotsketch
% barney has joined #parrotsketch
% allison has joined #parrotsketch
% chromatic has joined #parrotsketch
% jhorwitz has joined #parrotsketch
<chromatic> Someone's going to have to run this; I have nothing to report and am on the phone for work.
<allison> ok
<allison> who's here?
<kjs> I'm not invited, but I'm here :-)
<allison> particle and coke are on vacation
<allison> kjs: do you have anything to report?
<kjs> well, I more or less finished the Pir compiler chain, which works pretty well :-)
<allison> excellent!
<allison> my report, for the log:
<allison> - Implemented the final interface pieces for the Exceptions PDD.
<allison> - Added tests to extend coverage for the features added in the PDD.
<allison> - Made a few changes to the Exceptions PDD. Testing the new interfaces revealed they weren't as usable as they could be. Implemented the changed features.
<allison> - Deprecated indexed access to exception attributes.
<allison> - Worked on catching up with mailing list questions.
<allison> - Now working on Concurrency PDD.
<allison> EOR
<pmichaud> my report:  I worked on PAST implementation over the weekend, but whatever cold/allergy crud has been affecting me in October is extending its run into November.  
<pmichaud> however, yesterday and today have been much better and I'm working on it again now
<pmichaud> eor
<barney> refaktored languages/scheme
<barney> .eor
<allison> others online now:
<allison> jhorwitz?
<allison> tewk?
<jhorwitz> lurking today
<jhorwitz> been out of touch for a while
<jhorwitz> EOR
<allison> any questions?
<kjs> what needs to be done for the release?
<kjs> it's still 2 weeks I think
<pmichaud> yes, release is in 2 weeks
<pmichaud> I should have past re-implementation and nqp done in the next couple of days
<allison> yes, Nov 20
<pmichaud> then I'll be focused on perl6 and helping migrating languages to new tools
<allison> kjs: the usual patch application and bug fixing runs are in order
<allison> close out as many tickets as we can
<pmichaud> I'm hoping to have much of that done before the release
<kjs> I'll have a look at the tickets I opened
<allison> special attention this month to object-related issues
<allison> many old object tickets may be closed now that the old object implementation is gone
<kjs> I have a question on the object implementation w.r.t. Type Ids
<kjs> I thought type ids were gone
<allison> (verifying first that the same issues aren't repeated in new implementation)
<allison> kjs: type IDs can't be entirely removed until the implementation of the PMC PDD in January
<allison> they can be considered deprecated, though
<kjs> oki
<allison> or, use discouraged
<jhorwitz> pmichaud: i promised you a patch for past-pm a few weeks ago to support quoted type names, but never delivered.  is that still relevant?
<pmichaud> jhorwitz: nope -- the new implementation can handle it
<pmichaud> i.e., the new past-pm doesn't use type ids at all
<kjs> my pirc/new compiler chain is an attempt to provide a replacement for IMCC. However, IMCC's code generating details are rather difficult, and I'm not sure if I can handle that. Any suggestions?
<pmichaud> sorry, the new past doesn't use type ids.  past-pm uses type ids, but it'll be deprecated soon
<jhorwitz> excellent
<allison> kjs: do you mean generating PASM or generating bytecode?
<kjs> preferably both, but I meant bytecode
<kjs> I saw some code that checked for a prefix "_" for labels
<kjs> something that is really old I think
<allison> take a look at the bytecode PDD, jonathan has a revamp of the generation code in order
<allison> (bytecode production and reading)
<kjs> I think it'd be useful to know a bit more about the PIR->PASM mapping, and how IMCC currently works
<barney> Does anybody work on compilers/bcg ? 
<kjs> if the mapping is a straight 1 to n mapping (1 pir instr -> n pasm instr), that's easy
<kjs> barney: don't think so
<kjs> hasn't been any activity for long there
<allison> kjs: there are a few places where it isn't a straight 1-to-n mapping, but they should be changed so it is
<allison> consider that part of the spec
<kjs> so it should be added to the spec?
<chromatic> Jonathan's the best one to ask about that.
<chromatic> He and... jhorwitz?  I forget exactly who, sorry, were working on PMCs that represent bytecode.
<jhorwitz> not i
<kjs> didn't mdiep do something with PMCs? (just a vague recollection)
<allison> kjs: PIR can also perform optimizations before the PASM/bytecode phase, but those should have identical behavior with unoptimized straight translation
<chromatic> That may be.
<allison> kjs: yes, the 1-to-n mapping can be added to the spec
<kjs> allison: right. It's kind of a big project to re-implement IMCC stuff; but I have the feeling it's necessary, because there are so many XXX and FIXME's and "this is ugly"s
<allison> kjs: would you have time to work on an initial draft of the IMCC PDD?
<kjs> allison: I meant a concrete mapping of: "x.y()" => "set_args\ninvokecc\netc."
<chromatic> Melvin always wanted to rewrite/refactor IMCC before it became the default compiler.
<kjs> every now and then I have some spare time (but I do need to finish my master's thesis :-/)
<allison> understandable. I was just thinking that summarizing how it works now would be a good way for you to get familiar with it, and for others to pitch in their own understanding
<pmichaud> afk, reboot
<kjs> what should exactly be in the IMCC PDD? (and I take it you mean the PDD19?)
<allison> pdd 19 is a specification of the PIR syntax
<kjs> ok. so you want a different pdd for the pir compiler?
<allison> I'm more looking for the specification of our bytecode interpreter
<allison> (including a couple of paragraphs on parsing PIR and PASM)
<allison> it may simply go into the bytecode PDD
<kjs> ehm, that's Parrot :-) Which specifics of the bytecode interpreting do you have in mind?
<allison> jonathan just mentioned he'll have more time soon, so I may sic him on it
<allison> it's not all of Parrot, just one subsystem
<allison> and, a fairly small subsystem at that
<allison> chromatic: did you have a report?
<chromatic> No progress.
<kjs> I'm not really clear on which part that is :-(
<allison> is anyone blocking on anything?
<pmichaud> time and energy, here
<chromatic> Ditto.
<allison> kjs: what we need most for the moment is a cleaner way of generating bytecode, so let's focus on that with jonathan
<kjs> ok. I'm happy to help with that
<allison> kjs: great
<chromatic> How much of PIR can pirc handle right now?
<chromatic> Is it just generating bytecode that it doesn't do yet?
<kjs> it's just a parser 
<kjs> but it handles heredocs (also for macro expansion arguments) and multiple heredocs in macro/function calls
<kjs> so that's an improvement on imcc
<chromatic> What does it produce from the parse?
<kjs> nothing
<kjs> I just finished the heredoc/macro parsing (still some loose ends but nothing difficult)
<kjs> so, now is more or less the time to add the semantic actions
<kjs> to output PASM for instance
<chromatic> ... but it *could* produce PBC much more cleanly than IMCC does.
<kjs> sure! :)
<kjs> my first plan was to generate PASM, and have that parsed by a PASM grammar, just as an exercise, so that there is a clean PIR->PASM translation
<chromatic> None of those options hurt my feelings.
<barney> PIR->PASM has problems: lexicals and maybe .HLL
<kjs> barney: right, I think PASM needs a representation for that
<chromatic> Agreed.
<chromatic> If PASM and PBC are truly isomorphic, anyway.
<barney> lexicals were the reason for generating PIR instead of PASM in languages/scheme
<kjs> I think once there's a clean pir->pasm translation, things can be optimized later
<kjs> but surely there must be a way to express it in pbc?
<barney> Maybe we should rename PASM to cPIR, canonical PIR
<kjs> I mean, if Parrot can deal with lexicals and .HLL stuff, it must be present in the PBC, no?
<barney> yes
<kjs> so, if there's no PASM representation of it yet, we'll have to think of it I guess
<chromatic> One of the difficulties in that isomorphism is that PBC contains serialized PMCs.
<kjs> what do they do?
<barney> I'd rather see a YAML dump of PBC, with PMC serialisation
<kjs> barney: how is YAML more itneresting than PASM?
<allison> chromatic: the PBC contains serialized PMCs, but the PASM should contain the translated instructions for creating the PMCs
<allison> (translated down from PIR, that is)
<allison> translating from bytecode to PASM is another question
<kjs> isnt' that a 1 to 1 mapping?
<barney> YAML is a tree structure PASM is linear
<kjs> barney: ok. is PBC tree-like?
<kjs> I mean, what would be the advantage?
<allison> PBC is linear
<barney> I think PBC is a tree, but I haven't really read the PDD
<kjs> if PBC is linear, and PASM too, that sounds like a match :)
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
<allison> barney: nope, it's a linear format
<allison> with sectors for storing data in addition to sections for storing code instructions
<allison> it's really, really low-level, closer to machine code than anything else
<allison> which makes sense, since it's native code for a virtual machine
<kjs> allison: everything that can be expressed in PIR, is somehow stored in PBC?
<allison> kjs: yes, with the exception of code sections that are run during compilation
<kjs> right, these are not stored in the PBC at all?
<allison> that is, you have the option of specifying that some specific code sections should be run before the bytecode is produced
<allison> and not stored in the bytecode
<kjs> right, :immediate, or :postcomp
<allison> yes, iirc
<allison> (the flag names haven't been clearly specd anywhere yet)
% chromatic has joined #parrotsketch
<kjs> they are specd somewhere, but probably not in a pdd?
<allison> kjs: not even that far
<kjs> http://www.parrotcode.org/docs/imcc/calling_conventions.html
<kjs> I guess it should be included in pdd19
<allison> pdd03 is most important
<allison> imcc/calling_conventions.pod should disappear, replaced by pdd03 and pdd19
<kjs> ok, the flags into pdd03
<allison> parts also go in the PASM PDD
<allison> I'll do that now
<allison> parts are out-of-date, so keeping them around is just going to bite someone
<allison> anything else before we wrap u?
<allison> up
<kjs> nothing here, thanks
<allison> talk to you all next week
<kjs> bye
% chromatic has left #parrotsketch
% barney has left barney!~bernhard@p549A24A3.dip0.t-ipconnect.de
% kjs has left kjs!~kjs@ip565fd420.direct-adsl.nl
% jhorwitz has left jhorwitz!~chatzilla@pool-68-163-17-123.phlapa.east.verizon.net
% contingencyplan has joined #parrotsketch