% avar has left avar!~avar@dsl-228-236.hive.is
% avar has joined #parrotsketch
% avar has left avar!~avar@dsl-228-236.hive.is
% avar has joined #parrotsketch
% mdiep has left mdiep!~matt@bursley-219-72.reshall.umich.edu
% mdiep has joined #parrotsketch
<mdiep> My pre-pasted report:
<mdiep>  - Working on a couple C-level patches in my spare time
<mdiep>     - 41511  Parrot_call_sub* Incompatible with Multisubs
<mdiep>     - 40490  Flat/Slurpy Named Parameter Passing Errors
<mdiep>     - 39844  [BUG] Parrot doesn't do args checking for a sub without params
<mdiep>  - The code there is too convoluted to understand. Trying to rewrite/refactor (making the patches harder and more substantial).
<mdiep>  - In particular, parameter passing uses a state machine. This makes things more complicated than I think they need to be.
<mdiep>  - 0.4.11 is 2 weeks away:
<mdiep>     - People haven't been tackling tickets like I'd hoped they would: http://xrl.us/veso
<mdiep>     - I suspect everyone is busy with other things
<mdiep> Question:
<mdiep>   1. I briefly looked through PDD15 and noticed there are a lot of methods on the Class and Object PMCs. How do you envision this working with languages that don't have those methods? For example, a Python class should use the invoke vtable for object creation - not a "new" method. I think this means that if Python wants interop it would have to create *two* PMCs for a class: one that maps to Parrot and one that wraps to Python. This is 
<avar> mdiep: question cut off at "this is"
<mdiep> I briefly looked through PDD15 and noticed there are a lot of methods on the Class and Object PMCs.
<mdiep> How do you envision this working with languages that don't have those methods?
<mdiep> For example, a Python class should use the invoke vtable for object creation - not a "new" method.
<mdiep> I think this means that if Python wants interop it would have to create *two* PMCs for a class: one that maps to Parrot and one that wraps to Python.
<mdiep> This is the reason for vtable functions.
% kjs has joined #parrotsketch
% pmichaud has joined #parrotsketch
% smash has joined #parrotsketch
% jonathan has joined #parrotsketch
% bernhard has joined #parrotsketch
% allison has joined #parrotsketch
% chromatic has joined #parrotsketch
% Coke has joined #parrotsketch
<Coke> hello, everyone.
<Coke> No agenda today, just the usual reports + questions.
<allison> hi coke
<jonathan> hi everyone
<pmichaud> coke:  I thought I had a discussion item, but I'm now recanting that
<Coke> allison, why don't you go first. (then bernhard, chromatic, jonathan, mdiep, particle, pmichaud, smash, tewk). 
<Coke> (if anyone can spot my devious ordering scheme, I'll give them a cookie)
<allison> - I spent the week working on the objects PDD, and am just about to move it out of draft.
<pmichaud> I know!  it's alphabetical!
<Coke> (curses. there goes my cookie. and I see mdiep has already reported)
<allison> - Then I'll spend a couple of days on Punie, as a reward/break.
<allison> EOR
<bernhard> Removed config/auto/bc.pm
<bernhard> Refactored TGE grammor of 'Plumhead partridge'
<bernhard> END_REPORT
<chromatic> I like cookies, except with raisins.
<bernhard> s/or/ar/
<chromatic> I continued to try to release all memory at shutdown.
<chromatic> I applied most of speters' patches.  Yay.
<chromatic> I tracked down a couple of bugs and reported a few more.
<chromatic> I'll take a look at any open ticket on the list that anyone asks me to look at, starting with the nested structs issue.
<chromatic> EOR
<jonathan> Not had so much time in the last week, but mostly been doing PDD15 stuff in what I've had...
<jonathan> * C3 MRO now works, so inheritance in the new class model works as it does in the current one; we'll go pluggable sometime, when it's specced
<jonathan> * Roles made up of other roles are now implemented, added some tests too
<jonathan> * Made role conflict resolution match the changes to PDD15: implemented resolve, changed semantics of alias and s/without/exclude/
<jonathan> * Class.new() now accepts a slurpy hash and sets the attributes
<jonathan> * Implemented can and get_class v-table methods for the Object PMC
<jonathan> Got some questions for question time.
<jonathan> .end
<jonathan> * Very happy to see allison++ clarifying lots in PDD15, and done various postings on list to further clarify stuff/suggest stuff
<jonathan> * Other than that, did a couple of PCC* fixes, including to the new Parrot_PCCINVOKE by tewk++
<Coke> danke. particle?
<particle> ~ the majority of my code this week was the Exporter PMC
<particle> ~ it's close to complete, but MMD and PCCMETHODs don't play nice yet
<particle> ~ reviewing dickdawg++'s new implementation of ecmascript v3 -- looks almost ready for initial commit
<particle> ~ i modified the style of pmc documentation a bit in Exporter. it's much clearer, and more complete. i suggest everyone should start documenting pmc source this way
<particle> ~ likely i'll write something up to the list, but i wanted to announce it here so folks in attendance can review and offer comments
<particle> .end
<pmichaud> Commentary:
<pmichaud> * allison++ # long-needed improvements to objects PDD
<pmichaud> * jonathan++ # long-needed improvements to object implementation
<pmichaud> Current status:
<pmichaud> * Finally back at work on Parrot this week after lots of real-life distractions throughout March.
<pmichaud> * Today I'm working on implementing some of the S05 changes into PGE, especially the new quoting rules.
<pmichaud> * Should have those checked in today
<pmichaud> * This will involve adding a new --syntax option to 'pgc', so that systems using pgc can specify the grammar syntax to be used for the input
<pmichaud> * Default will initially be --syntax=PGE::P6Regex
<pmichaud> * Today/tomorrow I'll be updating the perl6 and pynie grammars to the new syntax
<pmichaud> * I also want to convert to the new Exporter interfaces
<pmichaud> * Then I'll be chipping away at 01-sanity/ again, probably initially starting with 'for' loops
<pmichaud> * However, if there's likely to be any change to Iterator (cf: recent messages to parrot-porters) then perhaps I should target something else first
<pmichaud> .end
<smash> "no report"
<Coke> ok. tewk's last... unless I missed someone?
<Coke> ok. questions. pmichaud?
<particle> pmichaud: i wouldn't wait for iterator, if i were you. those discussions have gone on for decades (so it seems) with no real action yet
<pmichaud> particle: noted
<pmichaud> 18:39 <particle> ~ likely i'll write something up to the list, but i wanted to announce it here so folks in attendance can review and offer comments
<pmichaud> is it worth writing up that something as a pdd?
<pmichaud> (EOQ)
<particle> pmichaud: yes, once we've come to agreement, it should be documented
<pmichaud> also, where *is* Exporter?  Is it a built-in PMC?
<Coke> in the meantime, the wiki is a good place for us to come to agreement?
<particle> yep, src/pmc/exporter.pmc
<pmichaud> oh
<particle> coke: sure, i'll start a wiki page, and publish the link to p2
<pmichaud> so, is the documentation format really more appropriate for C-based code, or does it work well for PIR-based stuff also?
<particle> pmichaud: i haven't thought beyond c-based pmcs
<particle> perhaps it could be extended
<pmichaud> okay, for some reason I was expecting Exporter to be pir-based instead of C-based
<pmichaud> I've found the C-based descriptions don't work quite so well for pir-based subs and methods
<particle> now that we have pcc in c, we get the best of both worlds
<jonathan> PCC is only one part of the work needed to make C and PIR play nice together.
<pmichaud> I'll save my remaining comments for the mailing list or the wiki
<pmichaud> (or #parrot)
<Coke> ok. Jonathan, your questions are up next.
* jonathan tries to remember them all
<jonathan> First, a kinda practical one. A recent on-list discussion suggests that Class is the base of all classes
<jonathan> *but* it just implements the v-table methods, so it's good for HLL implementers to extend
<jonathan> (if it gives the semantics they want)
<jonathan> And the one with all the nice sugar (methods et al) is called ParrotClass.
<jonathan> In fitting with [OtherHLLNameHere]Class
<jonathan> Trouble is, we already have a ParrotClass PMC, and I suspect I'm going to break lots of stuff that currently works if I just change it to use the new PDD15 stuff.
<allison> actually, I'm leaning more toward the role implementation anyway
<jonathan> Particularly as the new implementation doesn't know how to inherit from PMCs yet, which is unspecced and problematic.
<allison> (problem being that we don't have roles in low-level PMCs yet
<pmichaud> (role implementation)++
<jonathan> Yes, exactly.
<jonathan> And PMCs are potentially changing quite a bit generally, with all the various proposals on the table.
<chromatic> Roles could make the C-based PMCs much simpler too.
<particle> i'd like to keep the vtables flat, though
<allison> so, create a subclass called ClassMethods, for now, and when we implement roles for PMCs we can change it to a role
<jonathan> I'm not sure I really want to see people being able to use the new PDD15 stuff blocking on changes to PMCs.
<jonathan> OK, sounds good.
<allison> Or, for that matter, keep the methods in Class for now
<allison> and split them out when we have roles
<jonathan> OK, that's fine too.
<jonathan> Let's do that.
<Coke> jonathan: did you have another q?
<jonathan> allison: Are the PMC changes next in your design TODO list?
<allison> that's actually my q for the day, when you're done with your qs
<Coke> Which I think he is. tag you're it.
<jonathan> I think that's enough for now.
<jonathan> :-)
<allison> Okay, the question is, which PDD is currently the greatest blocker for forward progress?
<allison> I'll work on that one next.
<allison> My list of candidates are threads and events, low-level PMCs
<Coke> I have no preference atm. =-)
<jonathan> IO PDD depends on PDD15 and figuring out interation between that and PMCs.
<pmichaud> Objects (and an implementation for it) has been my biggest blocker.  I'm not sure of any other blockers at the moment.
<allison> threads and events are both needed for the implementation of I/O
<jonathan> So my vote is getting low-level PMC stuff sorted.
<chromatic> Seems like figuring out how to inherit from low-level PMCs would fix a lot of bugs.
<jonathan> They're needed for parts of I/O.
<particle> my vote is also pmc
<pmichaud> inherit from low-level PMC is something I definitely need at this point
<allison> low-level PMCs are needed for getting the inheritance to high-level objects (what c said)
<allison> okay, PDDs 4 and 2 it is, then
<jonathan> Yay.
<particle> datatypes and vtables?
<particle> what about pddxx_pmc.pod?
<particle> or cstruct, for that matter?
<particle> i suppose they're all related
<allison> pddXX_pmc leo is proposal on cstruct
<allison> s/leo is/is leo's/
<allison> and will be rolled into the other pdds
<allison> though, I can definitely see possibilities for moving much of the details on pmcs out of pdd4 on datatypes
<allison> there's also pdd17
<allison> basic_types
<jonathan> And PDD8 ;-)
<particle> yes, which needs an overhaul, but later
<particle> (17, that is)
<allison> ok, so a definition of low-level pmcs is my  next goal
<particle> i expect our basic types will be our roles, plus more
<allison> and I'll be pulling input from PDDs 2, 4, 8, 14, 17, and 2 XX proposals
<allison> (and possibly rearranging them into more sensible groupings of related concepts)
<allison> thanks and EOQ
<Coke>  any one else with qs?
<chromatic> I'm giving a talk at PDX.pm next Wednesday about the design of Parrot and PIR.
* particle idly wonders if he can attend
<pmichaud> who's presenting at yapc?
<pmichaud> (yapc proposals due this week)
<allison> I'm submitting a proposal (haven't yet)
<allison> patrick, are you talking there, or too busy organizing?
<chromatic> I'll probably submit mine.
<pmichaud> I'm definitely planning to talk, yes
<allison> ok, good
<pmichaud> (I'm not at all involved in organizing yapc, afaik)
<jonathan> allison: You know what you're proposing for YAPC::Europe yet? Don't want to submit anything conflicting...
<jonathan> Or could just submit whatever and let the organizers figure it out. :-)
<allison> jonathan: I submit a Parrot overview talk and a parrot internals talk
<allison> leo won't be presenting at YAPC::EU, because he's too busy organizing
<jonathan> Good job I asked, I was going to submit the second of those myself. :-)
<jonathan> (internals)
<pmichaud> is it worth submitting anything about pynie?
<Coke> I'm probably submitting a yapc paper. we should coordinate on the list.
<allison> jonathan: well, let's email about it, we might share it, or divide up the topics
<Coke> (or perhaps the wiki)
<pmichaud> or is that too off-topic for perl?
<Coke> i think anything parrot related is fair game.
<allison> pmichaud: it's not too offtopic, it's a good example of parrot's capabilities
<chromatic> Perl 6 might be more on-topic.
<jonathan> allison: Sure.
<particle> pmichaud: i don't think it's off topic at all, for a dynamic language virtual machine
<pmichaud> well, especially since I put pynie together in <1 day :-)
<Coke> So, is anyone not having fun?
<pmichaud> at least the initial working compiler :-)
<particle> write python in less than 24 hours
<pmichaud> actually, that might be a good talk title "How to write a python compiler in less than 1 day using Parrot"
<allison> coke: definitely having fun :)
<smash> anything left for me to present at yapc::europe ?
<allison> smash: of course
<Coke>  
<allison> coke has turned invisible
<Coke> <ninja/>
<particle> shadow puppets with parrot
<smash> after everyone submits their presentations i'll see if i can talk about anything else
<Coke> don't have to worry about yapc:na overlapping with yapc:eu talks, I don't think.
<smash> nope, but i'm guessing some ppl here will attend yapc::eu
<allison> smash: I'll start an email thread with you, me, jonathan, and anyone else who's interested in speaking about parrot at yapc::eu
% mdiep_ has joined #parrotsketch
<smash> plz don't start the thread with me, i'll reply when appropriated
<particle> should i expect mmd to work with pccmethods?
<Coke> alrightee. anyone have anything else? As always, feel free to ping the list in between meetings.
<chromatic> particle, yes.
<chromatic> But not now.
* particle wants a ponie
<chromatic> I'm not a huge fan of the way Multi works...
<Coke> fresh out, sorry.
<particle> okay, this will mean that Exporter.'import'(src, dest, 'list of globals') won't work for a bit, yet
<chromatic> But it seems that the PCCMETHOD could check if it has a multi, then push the sub onto the array.
<jonathan> Making that work would involve implementing something like a MultiNCI PMC, analgous to MultiSub.
<particle> you'll have to array = split ' ', 'list of globals' first
<jonathan> At least, I guess that'd be the way to go about it.
<chromatic> The only problem is identifying conflicting signatures.
<jonathan> I think we only do that today at call-time with PIR multis?
<chromatic> Okay, so for now that's not a problem.
<chromatic> Eventually we might need to do it at declaration time.
<jonathan> Sure.
<pmichaud> particle:  cannot 'import' get a PMC as the third argument, and then do a split if it's a String?
<pmichaud> instead of trying to use MMD to handle it?
<particle> oh, i think i'm mixing things up
<particle> yes, it can, and will :)
<jonathan> I see in the PDD list there's no MMD PDD. Guess one day there should be.
<Coke> jonathan: please open a ticket. =-)
<mdiep_> (no MMD PDD) that's been brought up before
<allison> shouldn't mmd be part of the parrot calling conventions PDD?
<Coke> mdiep_: would you care to re-iterate your question?
<jonathan> allison: Up to you, I don't mind where it is, provided it's spec'd.
<mdiep_> you're the architect. you tell us. :-)
<allison> lol :)
<mdiep_> Coke: sure.
* jonathan will file a generic "please spec MMD" ticket. :-)
<allison> I'll add "look at PCC PDD and see if it needs MMD split out" to my list
<allison> jonathan: yes, thanks
<particle> i expect pccmethod et al will end up in the calling conventions pdd, as well
<jonathan> *nod*
<particle> ...i'm editing that dev doc now.
<allison> particle: yes, makes sense
<jonathan> The documentation for PCCMETHOD needs updating to mention Parrot_PCCMETHOD - will try and get to taht this weeek if nobody beats me.
<mdiep_> I was looking over pdd15. There are a lot of methods on the Class and Object PMCs. How do you see those working with HLLs that might not have those methods?
<mdiep_> For example, Python doesn't have a "new" method on its classes. Do you anticipate Python creating 2 Class PMCs? One for internal and one for external/interop use?
<allison> mdiep: ah-ha, you've hit upon the mailing list thread from last night
<jonathan> mdiep_: They're all going to become v-table methods, and then a role will be mixed in provided the methods.
<jonathan> s/provided/providing/
<allison> mdiep: great minds think alike
<mdiep_> allison: ah, okay. I've fallen a bit behind on list traffic. :-)
<allison> mdiep: I love the independent verification "this is a good idea"
<allison> (I'll check in the changes soon after parrotsketch is over)
<jonathan> allison: We also have a void become_parent(PMC* class)
<jonathan> Should that go?
<particle> allison: from what i read, you're thinking about a single new vtable item, right
<allison> jonathan: that tells a class to add itself as a parent of another class?
<jonathan> I'm...really not sure. :-)
<jonathan> I guess so!
<allison> ok, I'll look at it
<jonathan> It feels...wrong.
<Coke> welcome to parrot development!
<allison> if so, I'd favor add_parent over become_parent
<jonathan> allison: There is both.
<jonathan> add_parent - adds a parent to a class # you'd expect this...
<jonathan> become_parent - er, add yourself as a parent to a class # weird...
<allison> unless there's a substantially good reason to have both, I'm inclined to delete become_parent
<jonathan> Me too.
<allison> but, I'll look at it
<jonathan> Sure.
<Coke> anything else?
<jonathan> particle: You asked allison, but - I think a couple of new vtable methods. add_role, and inspect
<jonathan> Maybe remove_role too
<jonathan> Nothing else from me.
<allison> particle: or did you mean, a single vtable item for 'new'?
<particle> i meant a single for meta stuff, like jonathan said
<particle> inspect, that's the one
<particle> the smaller we can keep the vtable, the better for it to fit in caches etc
<allison> yeah, rather than relying on keyed access or attribute-level access, which may vary for different HLLs
<particle> another way to organize would be to hang a pointer to another vtable off it
<mdiep_> the invoke vtable could actually work well as "new". it buys us some things that could be nice. (pir subclasses of PMCs don't enter a secondary runloop with invoke())
<particle> so class/object based methods are one more indirection
<allison> $P0.inspect.thingy()
<allison> (the notional equivalent)
<particle> yep
<allison> yeah, it's possible
<jonathan> We don't really have anything to support nested v-tables at the moment though.
<allison> I've been thinking of introspection more like keyed access by name
* jonathan would be happy to avoid the complication and go with an inspect v-table method taking a string name of what to get.
<allison> there may be cases where you need more than that... I'm not sure they're common enough that they make overriding 'inspect' problematic
<allison> I'll leave it bubbling in the back of my brain for a while
<allison> thanks!
<particle> you may want to check src/ops/experimental.ops, which has: classname, getclass, new, instantiate, etc
<particle> oh, and pmcinfo
<allison> yeah, I was looking at pmcinfo last night
<allison> (as well as new and instantiate)
<particle> fab
<allison> it's not too far off
<allison> (pmcinfo, that is)
<particle> yes, it could work
<allison> and I liked the name 'instantiate' better than 'new'
<allison> (we don't need both)
* particle mutters something about huffman
<allison> huffman is why introspection doesn't get a hundred different method names
<allison> vtable method names, that is
<particle> i'm beginning to see a world where most pir is human-generated, and compilers go from past -> pbc
<particle> but, i digress
<allison> that's a good point
<jonathan> IMO, the main thing we need for that to work is a stable spec of POST, then someone can implement BCG.
<jonathan> (Bytecode generation, from POST)
<allison> I mainly diverged from 'new' because of the confusion when instantiating classes, versus instantiating roles
<jonathan> Instantiating roles?
<allison> er, meant to type objects
<particle> heh. i can see the confusion
<allison> (in fact I specifically thought "type objects, you don't mean roles" and then typed roles)
<particle> EPEBCAK
<particle> darn, and i missed my chance to add that error code to parrot for april fool's
<allison> :)
<allison> sounds like we're about wrapped up, I'm going to find some food
<allison> thanks all!
<Coke> see everyone next week. thanks!
% chromatic has left #parrotsketch
% smash has left #parrotsketch
% bernhard has left bernhard!~bernhard@p549a1cb9.dip0.t-ipconnect.de
% kjs has left #parrotsketch
% jonathan has left #parrotsketch
% pmichaud has left #parrotsketch
% Steve_p has joined #parrotsketch
% dickdawg has joined #parrotsketch
% avar has left avar!~avar@dsl-228-236.hive.is
% mdiep_ has left mdiep_!~matt@udhcp-macvpn-313.public.engin.umich.edu
% particle has left #parrotsketch
% particle has joined #parrotsketch
% particle has left particle!~particle@144.81.84.207
% avar has joined #parrotsketch
% particle has joined #parrotsketch
% particle has left particle!~particle@144.81.84.207
% particle has joined #parrotsketch
% particle_ has joined #parrotsketch
% particle has left particle!~particle@144.81.84.207
% particle_ is now known as particle
% avar has left avar!~avar@85.197.228.236
% avar has joined #parrotsketch
% particle has left particle!~particle@144.81.84.207
<tewk>  http://nopaste.snit.ch:8001/9859
<tewk>  http://nopaste.snit.ch:8001/9859
<tewk>  http://nopaste.snit.ch:8001/9859
<tewk>  http://nopaste.snit.ch:8001/9859
% dickdawg has left dickdawg!~richard@136.159.broadband2.iol.cz
% dickdawg has joined #parrotsketch
% avar has left avar!~avar@dsl-228-236.hive.is
% avar has joined #parrotsketch
% particle has joined #parrotsketch