% integral has joined #parrotsketch
% mdiep has joined #parrotsketch
% pmichaud has joined #parrotsketch
% jhorwitz has joined #parrotsketch
% barney has joined #parrotsketch
% chromatic has joined #parrotsketch
% allison has joined #parrotsketch
<chromatic> Shall we begin?
% Tene has joined #parrotsketch
<chromatic> Allison?
<allison> - Updated subclassing for the new metamodel.
<allison> - Got the PIR versions of Test::More and Test::Builder passing all tests except the PGE-related ones ('like' tests).
<allison> - Updated 'isa' for the new metamodel.
<allison> - Added keyed attribute access for reaching attributes from a specific parent.
<allison> - Fixed some tests with old OO assumptions.
<allison> - Integrated change suggestions on the PMC PDD.
<allison> - I took a stab at PGE::Match and the new metamodel last night, and I suspect that we'll need a Proto PMC (that inherits or composes from both Class and Object) to make it work properly.
<allison> - Currently updating the pdd15oo branch with a merge from trunk.
<allison> EOR
<chromatic> barney?
<barney> Fiddled a little bit with 'scheme'
<barney> Removed opcode 'hash'
<barney> .eor
<chromatic> I helped Allison a bit with the Test::More and Test::Builder issues.
<chromatic> jhorwitz?
<jhorwitz> spent time researching why mod_perl6 was broken
<jhorwitz> problem was in the perl6 grammar. when i changed new .Perl6Str to new 'Perl6Str' in PAST/Grammar.tg, things magically worked again.
<jhorwitz> haven't had time to follow up with Pm or particle yet
<jhorwitz> EOR
<chromatic> mdiep?
<mdiep> this isn't pre-typed...
<mdiep> I'm starting to work on a local branch (using git) for refactoring packfiles into pmcs
<mdiep> much like jonathan's now-defunct pdd15 branch
<mdiep> it should eventually make a huge patch
<mdiep> but it'll probably take a while. I'll try to post updates of some kind from time to time
<mdiep> I'm hoping this will clean up much of parrot's source
<mdiep> ^D
% ptc_ has joined #parrotsketch
<chromatic> particle?
<particle> ~ got 'make headerizer' working again -- some ugly c 'struct' code to clean up after that
<particle> ~ getting generated file headers to all look alike so they're easier to detect
<particle> ~ working with a new cage cleaner (jurre++)
<particle> ~ trying to help jhorwitz++ with mod_perl6 woes, but haven't had the time. UPDATE: looks like he's found and fixed the bug, yay!
<particle> .end
<chromatic> pmichaud?
<pmichaud> spent most of last week doing on-site lectures for $job
<pmichaud> glad that's overwith, now I can get back to Parrot :-)
<pmichaud> first task will be to look at PGE::Match in the oo branch and resolve any conflicts there
<pmichaud> I'm also planning to finish the AST documentation (and hopefully implementation) this week, to meet a deadline
<pmichaud> EOR
<chromatic> ptc_?
<chromatic> spinclad?
<spinclad> ENOREPORT  # but pretyped!
<chromatic> Alright, did I miss anyone?
% smash has joined #parrotsketch
<ptc_> chromatic: urm, should i be giving a report?
<particle> coke can't make it today
<chromatic> ptc_, if you have one sure.
<ptc_> - hacked Andy Lester's attribute sniffing code so that we can now sniff warnings
<ptc_> am having some problems with that atm, so shouldn't be default part of config just yet
<ptc_> working my way through parenthesis cage cleanup
<ptc_> still thinking about how to detect function signatures so that can make function documentation boilerplate
<ptc_> .end
<chromatic> smash?
<smash> chromatic: not much free time == no report, soz
<chromatic> Okay.  Question time.
<particle> ptc_: re: function signatures : C::Scan is one way, but it's imo ugly. a pct-based solution wolud be much nicer.
<ptc_> pct?
<particle> ...perhaps a languages/c89?
<particle> parrot compiler toolkit
<ptc_> ok
<chromatic> Seconded.
<ptc_> ok, i'll add that to my todo list 
<particle> all we need is the parser at the moment, if i understand correctly
<pmichaud> any questions for me?  I have to run off for errands soon
<chromatic> A Parrot dependency for this is fine.  If Parrot can't even build, there's not a lot of use for user-level documentation.
<ptc_> yup, that's right.  i just want to pick out the function sigs
<pmichaud> (still catching up on having been out of town last week)
<particle> pmichaud: no questions, just hope catch up and start being productive again :)
<mdiep> pmichaud: is this *the* christmas? ;)
<jhorwitz> particle and/or pmichaud: should we convert all instances of .Perl6Str and friends in Grammar.tg to 'Perl6Str'?
<particle> *you catch up
<particle> jhorwitz: yes!
<allison> pmichaud: on PGE::Match, focus on the AST PDD first
<pmichaud> mdiep: gosh I hope so
<pmichaud> allison: okay.  But PGE::Match may be very quick for me to do
<jhorwitz> k, i'll throw a patch together
<spinclad> all instances of new .Anything in *.tg
<pmichaud> jhorwitz: yes, .Perl6Str and friends need to be 'Perl6Str'
<allison> pmichaud: I'll create the Proto PMC, which should reduce the PGE::Match change to a couple of lines
<particle> all instances of new .Anything *anywhere*
<pmichaud> allison: I don't think we neeed a Proto PMC yet, although it would help
<chromatic> I thought we had a change to IMCC that caught new .Foo.
<jhorwitz> pmichaud: the error only manifested itself in an embedded environment.
<smash> chromatic: if not we can do that
<smash> maybe throw an error
<pmichaud> i.e., I'm fairly sure I can get PGE::Match to work without needing a Proto PMC just yet
<chromatic> We should.
<allison> pmichaud: I expect you can too, but it looks like it'll require adding a pile of PIR level vtable overrides
<pmichaud> I don't think it'll require more than what we have now.  Let me take a crack at it, anyway, because if it does require a ton of vtable overrides then I'm totally misunderstanding how things are working :-)
<spinclad> i wonder if Proto will want to be a full child of Class, or only certain Roles of it mixed in...
<allison> pmichaud: okay
<spinclad> (Prototype object, right?)
<pmichaud> I promise not to bog down on it -- if I get bogged, I'll say so and flip to AST docs
<allison> spinclad: aye, for prototype languages
<allison> pmichaud: perfect
<particle> reviewing allison++'s commits, they look great. but there are so many pdd15oo branch tests failing, i don't know where to begin to help
<allison> focus on the ones in t/pdd15oo/
<pmichaud> okay, any other questions to me should go to m/l or #parrot -- be back later!
<chromatic> Any other questions or concerns?
<barney> Can we get rid of PASM ?
<particle> i'm not quite ready to get rid of pasm. isn't basic implemented in it?
<chromatic> I'm not sure that's possible; it's isomorphic with PBC.
<mdiep> chromatic: in *theory* it is.
<particle> hrmm, a pasm disassembler for pbcs would be nice
<barney> Not really. AFAIK, there is no :outer in PASM
<chromatic> Speaking of which, I'm really anxious to see mdiep's new work.
<barney> Nor .HLL
<spinclad> so conversely, does PASM need to be kept up to date?
<particle> i wasn't aware of that, barney. i think pasm should be kept up-to-date. that's certainly been my expectation
<allison> PASM is just a text form of PBC, so it should be kept
<mdiep> I think the plan was to re-evaluate pasm at a later time. since no one actually uses it, it was deemed unimportant.
<allison> are there specific PBC features that can't currently be represented in PASM?
<particle> besides hll and :outer?
<chromatic> :init
<mdiep> lexicals?
<chromatic> :vtable
<allison> 'k, I'll add these to the PASM PDD
<mdiep> I'm a bit rusty, but anything that starts with a '.' or ':' is suspect
<chromatic> Agreed.
<spinclad> with a disassembler, it's at least a convenient form for editting PBCs
<allison> things that start with '.' are just directives to IMCC, equally applicable to PASM and PIR
<mdiep> isn't PASM separate from IMCC?
<chromatic> Yes.
<particle> uggh.
<barney> Disassembling could also be done to a canonical PIR
<allison> mdiep: it used to be separate
<mdiep> so to say that PASM can have directives is a major architectural change
<allison> perhaps the biggest thing we need is a definition of what PASM actually is
<mdiep> that sounds like a good place to start
<allison> the line has grown quite fuzzy over the years
<chromatic> Some of the directives change PMCs serialized into PBC.
<barney> PASM could be defined as stringified PBC
<particle> compilable stringified pbc
<mdiep> it should be defined that way if we're going to call it assembly.
<allison> barney: that's the most likely direction, and if so, it has some implications for how PASM behaves
<particle> allison: which is what we want, anyway, right?
<allison> particle: yup
<barney> yes
<particle> good, looks like we're in agreement and headed in the proper direction on that topic.
<particle> make -jN is really bothering me. why does const_string fail? can we get somebody who has experience in these matters to fix it? any candidates? any volunteers?
<chromatic> Now what's the relative priority of this?
<particle> ooh, priority. good one. pasm and bytecode spec/implementation should probably be at a similar priority
<chromatic> I'm all for the cleanup happening first.
<mdiep> since no one uses pasm right now, I'd vote that it be a lower priority than anything Perl 6 needs.
<spinclad> make -jN has been a chronic thorn
<chromatic> Once we have a cleaner mapping of PBC <-> PMCs, defining PASM should be easier.
<allison> <mdiep> My major focus in the next few months is cleaning up and solidifying the internals of Parrot so we can pronounce it ready for any language implementor (including Perl 6)
<jhorwitz> particle: i might have cycles to look at make -jN.  is there a ticket open documenting the problem?
<spinclad> can we currently define arbitrary PMC structure in a .data section, as it were, of a PBC?  with what linkage to other PBCs?
<allison> mdiep: which will mean putting priority on some things that don't directly benefit the languages, just so they're tidied up and out of the way
<particle> jhorwitz: i'm not aware of a ticket. coke looked into it and maybe even developed a utility to help with the debugging
<particle> he may have opened a ticket
<jhorwitz> can you summarize in 30 words or less?  :)
<mdiep> allison: sounds great. I've enjoyed seeing chromatic's cleanup commits the past few months, but there's still much to be done.
<particle> miniparrot segfaults with make -j. diffs reveal .str files are the only differences. this points to tools/build/c2str.pl
<mdiep> did the make -j pmc build issue get fixed?
<chromatic> I can poke at the .str files.
<particle> i'd love to be able to build parrot 8 times faster.
<particle> wouldn't you?
<chromatic> Oh yes.
<particle> oh, i should mention perldreamer++ has created a branch for Test::Harness 3.0 conversion
<jhorwitz> okay, i'll poke at it too
<particle> it also includes parallelization of testing, potentially making that much faster, too
<particle> ewilhelm++ for his key work towards this goal as well
<particle> oh, this comment is for patrick, i'll also tell him privately...
<particle> there have yet again been questions about past as input to pct
<particle> the kp6 folks are working on multiple emitters at the moment, and somebody wants to target past
<particle> their common lisp back end is coming along quite quickly
<particle> that's it for me.
<ptc_> we've got two complete languages targeting parrot atm right?
<chromatic> Lua and what else?
<ptc_> keacl?
<particle> that's not complete
<spinclad> Tcl
<particle> tcl is ~25% complete, testwise
<ptc_> well, my question was: how to advertise this a bit wider to generate more interest in parrot?
<barney> hq9+ is complete
<ptc_> also in terms of drawing in more developers from not-necessarily perl-related backgrounds
<particle> bf is probably complete, too :)
<ptc_> heh :-)
<chromatic> Lua needs some optimizations, but I can't figure out how to run the code.  I can't even figure out which directory to be in to run the code.
<barney> Lua benchmarks didn't look very convincing
<particle> ptc_: lua is a great start, but it'd have to be much faster for them to have interest, i think
<ptc_> k
<particle> however, we'd love to help profile and optimize parrot if we could get a hand from some lua folks
<ptc_> ok, maybe needs more work first
<chromatic> Anything else?
<chromatic> Shall we adjourn to #parrot?
<particle> let's do.
<ptc_> yup
<spinclad> ok
% chromatic has left #parrotsketch
% smash has left #parrotsketch
% jhorwitz has left #parrotsketch
% ptc_ has left ptc_!~cochrane@p5B0FE9A2.dip.t-dialin.net
% barney has left barney!~bernhard@p549A1223.dip0.t-ipconnect.de
% pmichaud has left #parrotsketch
% mdiep has left mdiep!~mdiep@v-adsl-fh-178-170.umnet.umich.edu
% leo has left leo!lt@feather.perl6.nl
% leo has joined #parrotsketch
% mdiep has joined #parrotsketch