% davidfetter has left davidfetter!~davidfett@start.fetter.org
% PerlJam has left PerlJam!duff@feather.perl6.nl
% leo has left leo!lt@feather.perl6.nl
% pmichaud has left pmichaud!pmichaud@feather.perl6.nl
% PerlJam has joined #parrotsketch
% pmichaud has joined #parrotsketch
% leo has joined #parrotsketch
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% contingencyplan has joined #parrotsketch
% rdice has joined #parrotsketch
% particl1 has joined #parrotsketch
% particle has left particle!~particle@c-24-19-3-148.hsd1.mn.comcast.net
% particl1 is now known as particle
% davidfetter has joined #parrotsketch
% Infinoid has joined #parrotsketch
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
% Coke has joined #parrotsketch
% cotto_work has joined #parrotsketch
% wknight8111 has joined #parrotsketch
% barney has joined #parrotsketch
% chromatic has joined #parrotsketch
<Coke> Hello, everybody.
<barney> Hi
<cotto_work> hi
<Infinoid> oi oi
<chromatic> good $localtime
<Coke> barney: very dangerous. You go first.
<barney> Reimplemented HQ9+ with PCT. Sorry for the mess on case insensitive filesystems.
<barney> .eor
% allison has joined #parrotsketch
<Coke> bumpy, but all over now. chromatic?
<chromatic> Helped Coke remove type IDs from IMCC and PIR
<chromatic> Cleaned up some other code
<chromatic> Fixed a couple of bugs (especially PPC seggies)
<chromatic> Added a couple of features related to objects and PDD 17
<chromatic> Ported Test::More and friends to use keyed class names from strings
<chromatic> that's it
<Coke> allison: You ready? 
<allison> ready enough
<Coke> floor is yours. =-)
<allison> - Committed the architectural revisions to the Strings PDD. I'm filling in the API spec now.
<allison> - Created the concurrency branch, now making a list of concurrency implementation tasks so I can share them with others.
<allison> - Started a list of components for Milestone 4 (the final push to 1.0). I'll put those up on a wiki page.
<allison> EOR
<Coke> Infinoid: ?
<Infinoid> * A few minor fixes, a couple RT patches applied, a few tweaks to pass codingstd tests.
<Infinoid> * Worked (with Coke++) on fixing some "make -jN" issues, for various quantities of N.  Seems to be working a lot better now.
<Infinoid> * Diakopter++ and I replaced svnbotl with something less broken.  Hopefully.
<Infinoid> * Coke volunteered me to act as "point of contact" for an Apache SoC applicant, who wants to plug Harmony GC into Parrot.
<Infinoid> 1;
<Coke> pmichaud?
<Coke> particle: ?
<pmichaud> here
<Coke> particle: wait for pm. =-)
<pmichaud> (was on phone a second)
<pmichaud> * Fixed up a number of RT tickets
<pmichaud> * Big ticket was RT#48028, deprecation of PGE::P6Regex
<pmichaud> also RT#48026, pgc (which used PGE::P6Regex)
<pmichaud> * converted most languages and tools off of P6Regex and onto new tools (Perl6Grammar/Perl6Regex)
<pmichaud> * also advised/applied patches to NQP for postfix:++/--, relational ops, and plans for ??!!
<pmichaud> * added push/pop/shift/unshift methods to ResizablePMCArray
<pmichaud> * reviewed first 5 episodes of kjs++'s PCT tutorial, provided feedback/comments
<pmichaud> EOR
<particle> ~ back from nyc, it was a fun but all too short trip
<particle> ~ SoC student application period has been extended a week
<particle> ~ read allison++'s changes to strings pdd. looks good, waiting more
<particle> ~ yapc submissions in
<particle> ~ helped some folks debug some windows-related functionality
<particle> maybe someday i'll do some coding again. :(
<particle> .end
<Coke> tene?
<Tene> Lolcode fixes.
<Tene> KTHXBAI
<Coke> anyone else? ... pending them, my report:
<Coke> - Ticket Status: 44 new, 752 open, 95 stalled
<Coke> - worked with chromatic to start getting rid of integer type ids in the 'type_ids' branch, also removed some of the usage in trunk
<Coke> - working through RT queue, one ticket at a time
<Coke> - improved build dependencies
<Coke> - tried to fix imcc constant folding issue, needs more work
<Coke> - improved some codingstd items
<Coke> - remove some deprecated items
<Coke> - made a google doc to show some RT stats. (see list)
<Coke> .
<Coke> Pretty quiet otherwise. Anything annoying, blocking, or otherwise crummy going on?
<cotto_work> my report:
<cotto_work> * boss is on vacation, legal status is still pending
<cotto_work> * have been working on phparrays out of tree
<cotto_work> * all vtable relevant (afaict) methods have been implemented and tested
<cotto_work> s/vtable relevant/relevant vtable/
<cotto_work> * I'll be writing more tests and working on builtin functions
<cotto_work> * working to help find bugs without actually submitting code
<cotto_work> eor
<particle> c: i'm concerned about the lack of integer typeids and dynpmc detection
<Coke> there are many issues regarding losing integer typeids.
<particle> yep.
<chromatic> There are many issues regarding dynpmcs.
<particle> ok. let's leave it at that and get 1.0 out the door :P
* pmichaud enqueues one discussion item
<Coke> I will probably start a thread on the list regarding the ticket for type ids.
<allison> particle: we still have integer type ids internally
* chromatic also enqueues
<particle> if i create a dynpmc called 'Integer', how is it distinguished from the core Integer pmc?
<allison> allison: but they're not considered a reliable way to identify pmcs
<particle> previous to typeid deprecation, this was possible
<Coke> (leave it in for 1.0) If we're talking about removing something, it's going to involve a LOT more work to do it post 1.0
<allison> core PMCs don't currently support namespaces, and need to
<Coke> allison: note that by removing VTABLE_type and friends, we are going to have to poke into PMC guts to get the int type id.
<pmichaud> fwiw, PCT, NQP, and Rakudo are going to generally avoid using string classnames, and access everything via a namespace and/or protoobject
<allison> coke: that we can't do, because Classes and Objects report a different type id than the PMC structure stores
<Coke> ... which we can't do?
<pmichaud> does VTABLE_type need to go away?  or just various opcodes that made use of type ids?
<Coke> VTABLE_type and friends were marked deprecated.
<allison> coke: we can't poke directly into the PMC guts for type id
<Coke> allison: ok. I'm going to need to know how to get the type id for internal use, then.
<allison> coke: yes, but the modification is to remove the parts of the system that expect to create a new object from an existing object's type id
<Coke> allison: I need this to remove VTABLE_type.
<allison> yes, you can't remove VTABLE_type yes
<allison> yet
<Coke> in the branch.
<Coke> so if VTABLE_type is supposed to (eventually) go away, I want to rip it out in the branch and fix what is using it now. (like, say, MMD)
<Coke> (I was going to save this for a discussion on list, but since particle broached the subject. =-)
<allison> you remove it in the branch, after first going through all calls to VTABLE_type and seeing which can be reworked
<chromatic> It seems like a good listy discussion, actually.
<pmichaud> can I get a clarification, for my own knowledge?  when we say "get rid of type ids", is that from all vtables or is it just from opcodes in PIR?
<allison> currently from the user-facing opcodes
<pmichaud> so we could presumably keep a VTABLE_type entry even though the opcode disappears?
<allison> yes, we can
<pmichaud> okay
<Coke> If we're going to keep VTABLE_type, we need to reject that ticket. =)
<Coke> I'll summarize my issues on list and we can go from there.
<allison> coke: sounds good
<Coke> ok. pmichaud had a question.
<pmichaud> I think too much may have been read into the notion of "get rid of type ids"
<pmichaud> okay, my item for queuing
<pmichaud> it may go on the list, but just to see if there are quick answers
<pmichaud> there's an issue when combining modules compiled from HLL down to PIR
<allison> (type ids) there's some architectural history there, I'll post to list
<pmichaud> for example, if we want to bundled several Perl 6 modules into a single PIR file, then there's a conflict in anonymous blocks
<pmichaud> as far as what they're named
<pmichaud> after looking at it a bit further, I think I'm going to go with nclark's suggestion to use md5 hashes (for now) of the source as part of the sub name
<pmichaud> unless anyone violently objects
<pmichaud> or has a better alternative
<particle> works for me. we have a pir md5 lib at the ready.
<chromatic> Pure-PIR?
<pmichaud> at the moment it's pure pir, yes
<particle> examples/library/md5sum.pir
<pmichaud> actually, runtime/parrot/library/Digest/MD5.pir
<particle> tests Digest/MD5.pir
<pmichaud> the interface could probably use some work to make it more o-o
<pmichaud> that's all I had, we can go on if there aren't any other immediate reactions
<Coke> ok. chromatic?
<allison> pmichaud: it works for now
<chromatic> I'd like to start listing potential cleanups and their dependencies.
<chromatic> For example, pirc relies on bytecode PMCs.
<chromatic> I think we can remove (or at least improve) a lot of code if we can identify it and figure out how to clean it up nicely.
<particle> sounds like a good idea. we can probably remove the Array pmc, for one
<Coke> storing that in the wiki in the short term would be good.
<Coke> we can open tickets once we decide what really needs to go.
<chromatic> Mostly I just want a list of ugliness and some sense of dependencies.
<allison> sounds good, c, and a wiki page is a good place to draft it
* barney wants to kill PASM
<Coke> barney: that just a rant, or something you want to elaborate on? =-)
<particle> pasm is (supposed to be) a human-readable bytecode format. i'd like to make it so.
<allison> particle: yes
<barney> Mostly ranting. But a simplified PIR could serve as a PBC dump format
<pmichaud> maybe we could call it PASM.  1/2 :-)
<allison> barney: really, PASM is simplified PIR
<allison> or PIR is PASM with syntactic sugar on top
<allison> barney: what is it that you dislike about PASM?
<allison> (we may be able to fix it)
<allison> or is it just that ordinary humans rarely write code in it?
% kj has joined #parrotsketch
<barney> that you can say things in PIR, that can't be said in PASM
<barney> e.g. .HLL
<allison> that has come up before... but .HLL is a directive, and directives apply to both PIR and PASM
<barney> I'll check about .HLL in PASM
<allison> okay, so I think this means we need the PASM PDD, to think through all the issues
<allison> there are a handful that keep popping up, so need to resolve them
<allison> the strings PDD is the last one on the official milestones list
<allison> so I'll keep doing one PDD a month
<particle> wow!
<allison> the next one to launch is the PIR PDD
<kj> I wrote an initial pure-pasm grammar, it's located in compilers/pirc/new/pasm.y, if that can be of any help. It probably lacks some syntax. 
<kj> sorry to barge in like that.
<allison> I can tag the PASM PDD for June, unless another is more urgent
<allison> I mean, May
<particle> may seems fine to me
<kj> (launching PIR PDD)++
* particle needs to run
<Coke> Be nice if our overview was out of draft.
<allison> coke: okay, I'll tag that one early
<Coke> I think that's a good place to wrap up for this week. KJ - meet me and allison in #parrot. =-)
<Coke> anyone have anything else before we break? (If not, have a good week.)
<Infinoid> thanks, Coke!
<pmichaud> see you next week!
<pmichaud> (or in a few mins in #parrot :-)
% Infinoid has left #parrotsketch
<cotto_work> bye
<kj> good night
% cotto_work has left #parrotsketch
% chromatic has left #parrotsketch
% kj has left #parrotsketch
% barney has left barney!~bernhard@dslb-084-058-181-232.pools.arcor-ip.net
% wknight8111 has left #parrotsketch
% Coke has left #parrotsketch
% allison has left allison!~chatzilla@63.105.17.30