% mdiep has left mdiep!~matt@bursley-219-72.reshall.umich.edu
% mdiep_ has joined #parrotsketch
% avar is now known as dongs
% dongs is now known as avar
% kjs has joined #parrotsketch
% pmichaud has joined #parrotsketch
% Coke has joined #parrotsketch
% dickdawg has joined #parrotsketch
% smash has joined #parrotsketch
% jisom has joined #parrotsketch
% bernhard has joined #parrotsketch
% jonathan_ has joined #parrotsketch
% allison has joined #parrotsketch
<Coke> Hey everybody.
<particle> howdy
<Steve_p> Hi
<allison> hi
<jonathan_> hi
<Coke> reports first, as usual. I'll go first today, then I have chromatics, then allison, particle, jonathan, pmichaud, and then we'll see who's left.
<Coke> Submitted a "roadmap to 1.0" presentation for yapc::na.
<Coke> started writing down my list of parrot thigns to do. getting longer.
<Coke> three biggest todos:
<Coke>  - get a weekly PS Summary somewhere to the list or a summary.
<Coke>  - get parrotcode.org to be using 'make html' as its generated docs.
<Coke>  - add more predefined queries for RT tickets to parrotcode to help
<Coke>    manage the ever growing # of tickets (which is, in general,
<Coke>    a good thing)
<Coke> ^Z
<Coke> chromatic's:
<Coke> I'm working on my talk for the Portland Perl Mongers tomorrow night.  It 
<Coke> covers the design goals of Parrot, the high-level design, the source layout, 
<Coke> and a PIR tutorial.
<Coke> I'm trying to extract main() from compilers/imcc/main.c into src/main.c.  
<Coke> Along the way I'm refactoring the code.  The result will probably be that 
<Coke> it's easier to use an alternate compiler, or none at all.
<Coke> We have a lot of under and undocumented structs in C-land, and I suspect 
<Coke> there's a lot of unused code.  I'd like to start getting those documented for 
<Coke> the next release, so everyone's welcome.
<Coke> I'll take a whack at the NCI struct issue soon; I have some other ideas to 
<Coke> make that work better.
<Coke> If no one gets to it first, I want to write some fuzz tests, writing near-PIR 
<Coke> from an analysis of all of the PIR in the repository, to make sure Parrot 
<Coke> doesn't crash on bad input and gives good error messages.
<Coke> I want more C refactorers.
<Coke> -- c
<Coke> next. =-)
<allison> - I launched the Objects PDD, and continued to refine it with questions from the implementation.
<allison> I'm very pleased with the progress implementing the new objects model.
<allison> - Submitted 3 talks to YAPC::NA ("Parrot Update", "Parrot Architecture", and "Learning PIR").
<allison> - Implemented arrays and hashes in Punie.
<allison> - Started work on the next PDD: PMCs
<allison> EOR
<particle> ~ finished Exporter PMC--yay! 
<particle>   to exercise PCC* further, it's time to subclass it 
<particle>   however, i need two languages with different namespace semantics 
<particle>   and are ready for hll interop--i may block on this for a while
<particle> ~ i have a goal of getting pdd15 largely implemented by next week 
<particle>   so, i'm turning my attention to pdd15 
<particle>   i'll be reviewing jonathan's code, and current tests 
<particle>   i could use your help, if you have time
<particle> ~ updated NEWS to a current revision, to make matt's job easier
<particle> .end
<jonathan_> More PDD15 stuff
<jonathan_> * Added the new vtable methods
<jonathan_> * Asked questions about what vtable methods should be deprecated - and got answers
<jonathan_> * Implemented inspect, inspect_str for both roles and classes
<jonathan_> * Moved code from PCCMETHODs to vtable methods, PCCMETHODs call the vtable methods
<jonathan_> * Did more on tying classes and roles to namespaces
<jonathan_> * Various other questions on the list to clarify stuff
<jonathan_> Other than that, made it so PCCINVOKE can be used to call non-PCCMETHODs.
<jonathan_> Think I did some other random thing, I forget what.
<jonathan_> .end
<pmichaud> PGE:
<pmichaud> * Worked on the new S05 changes for PGE, implemented as PGE::Perl6Regex
<pmichaud> * Updated the test suite in t/compilers/pge/perl6regex/, merging in improvements and changes from the Pugs version of the regex tests
<pmichaud> * perl6regex tests have a new '# todo :pge<reason>' syntax to mark the tests that are considered 'todo'
<pmichaud> * This appears to work extremely well
<pmichaud> * I also implemented a '# trace :pge<1>' pragma so that individual tests can be run with tracing enabled -- very handy when trying to figure out why a particular test is failing
<pmichaud> * I kept all of the :pugs<...> adverbs, so hopefully Pugs can do a simple 'cat rx_* >regex_tests' to use the updated tests (or modify the harness to use multiple rx_* files)
<pmichaud> Other:
<pmichaud> * Now is also a good time to look at other S05 changes, as well as Larry's Perl-6.0.0-STD.pm grammar
<pmichaud> * So, I spent the weekend looking at a number of features we need
<pmichaud> **   modifiers in the middle of regexes
<pmichaud> **   the new :sym<...> adverb
<pmichaud> **   proto regexes
<pmichaud> **   longest-matching semantics of C<|>
<pmichaud> * I also spent a fair bit of time examining fglock++'s "miniperl6" implementation in pugs, now that I understand what it's doing
<pmichaud> * I may see about taking a miniperl6-like approach with some of Parrot's translation tools
<pmichaud> * I also spent some time looking at generator/iterator ideas over the weekend so that I can get that part of perl6 implemented
<pmichaud> eor
<Steve_p> * Making progress on both Borland C++ and Intel C++. Assorted patches sent in.  One waiting to be applied (RT #42271).  One needs more work (RT#42359)
<Coke> wow. sounds like everyone aside from me is getting a lot done. =-)
<Steve_p> * Sun CC on Linux seems to be tripping over buggy Linux pthread headers containing gcc-specific code.  Waiting for word from Sun on a fix.  We may need to work around it on Linux.
<Steve_p> * TODO - finish C++ based cleanups 
<Steve_p> * TODO - Resolve vtable->class variable name and cleanup the other remaining ones.
<Steve_p> * TODO - Get the existing Makefile to work with dmake for Borland C++ or try to work with gmake on Windows instead
<Steve_p> END
<Coke> excellent. Anyone else around with a report?
<bernhard> Added a list of PHP parsers and implementations to http://rakudo.org/parrot/imdex.cgi?plumhead
<bernhard> That's it
<bernhard> .end
<Steve_p> I actually have to run to a another meeting so, if anyone as any objections to the pmc_class renaming suggestion I mailed to, please let me know.
<allison> steve: it's good enough
<Steve_p> When's the next planned release date?  I'll hold that change until after a release.
<allison> next tuesday
<particle> 17apr
<Steve_p> OK.  I've got enough other things to cleanup right now :-)
<pmichaud> Coke lost his internet connection
<pmichaud> so, the only other item for today was to get NEWS updated for release
<pmichaud> (per Matt)
% Coke has left Coke!~coke@cpe-72-228-52-192.nycap.res.rr.com
<pmichaud> and with that we can open to any other discussion/question
<pmichaud> questions first, I guess
<allison> I have one
<pmichaud> go ahead, allison
<pmichaud> after allison's question we have two questions from jonathan_ 
<allison> patrick: to finish implementing subroutines with parameters in punie, I need slurpy params and flattening args
% coke has joined #parrotsketch
% coke is now known as Coke
<pmichaud> wb, coke, we're doing questions now
<allison> I didn't see them yet in partridge, is that on the list for the semi-near future?
<pmichaud> I think PAST-pm already support slurpy params via pragmas
<pmichaud> it's an attribute on the parameter node
<allison> do any languages use the feature yet?
<pmichaud> I don't think I have flattening args yet, but I think it can be added
<allison> or, is it documented?
<allison> or, I'll send you an email and get the details
<pmichaud> I don't think it's documented yet.  perl6 uses it to handle :optional params, I think
<pmichaud> or maybe not.  I'd have to check the code again
<allison> I didn't see any handling for optional params at the PAST->POST level
<allison> (though, of course I can add whatever I want at the PAST level)
<allison> I'll email you what I've got so far, I'm back into PDDs again for a while
<allison> EOQ
<pmichaud> okay.  If it's not there it's easily added, certainly on the param side.  I think it could be done similarly for the argument side
* particle enqueues a question
<pmichaud> jonathan's two questions next, then particle
<jonathan_> OK
<jonathan_> Number 1
* Coke does as well.
<pmichaud> (then coke)
<jonathan_> I asked this before, but either I lost the answer or the question got lost. Roles can have attributes, and attributes like methods can be composed. Does it make sense to provide "exclude" and "alias" for them at all? If it does, how do you specify what to exclude and alias (as in, syntax wise/what is the parameter called wise)? Using the existing parameters won't work - what if an attribute and method had the same name, etc.
<allison> Yes, we need alias and exclude for attributes as well as methods (and I think I answered before)
<allison> do exclude/alias take a list now?
<jonathan_> exclude a list, alias a hash (mapping name to alias)
<allison> 2 options: each takes a hash, with two keys 'attributes' and 'methods'
<allison> ('exclude' a hash of lists, and 'alias' a hash of hashes)
<allison> or, we name-mangle with exclude_attribute and exclude_method, etc (which is what you suggested IIRC)
<jonathan_> Aha, I remember suggesting that now too.
<allison> both add some level of complexity, so it's just a matter of deciding which is worse
<jonathan_> The second solution is my preferred one.
<allison> (or, coming up with other options)
<jonathan_> Saner interface.
<particle> why don't we call it 'resolve'
<jonathan_> Otherwise you have to construct a new hash.
<allison> particle: resolve is the option on the class
<allison> particle: that is, it expresses an intention to resolve a role conflict
<allison> particle: 'exclude' is a low-level brute-force option when importing a role, that just says "I want you to skip this method/attribute"
<jonathan_> It's not a great hardship to add method_, doing $Px = new 'Hash', etc, is.
<particle> building up the data structures is burdensome
<jonathan_> *nod*
<jonathan_> Whereas a parameter name being a bit longer isn't.
<particle> exclude_attribute( slurpy named list ) is better
<allison> jonathan: both seem annoying to me, but I don't have a better option at the moment, so let's go with: alias_attribute, exclude_attribute, resolve_attribute, etc
<jonathan_> OK, 'twill be done.
<particle> we could have something that encompasses them all.
<leo_> alias_or_resove('alias', 'attr', *) ...
<allison> particle: these are names to use in slurpy named lists (or hashes of named arguments)
<particle> merge( alias_pmc :named('alias'), exclude_list :named('exclude') )
<allison> they're not actually opcodes/methods
<leo_> s/resove/exclude/
<particle> okay, i'll shut up. i need to review pdd15 again
<jonathan_> e.g. .addrole(PMC* role, PMC* exclude :named('exclude'), ... 
<jonathan_> OK, anyone else got any more on that question or can I ask my second?
* jonathan_ times out
<allison> go ahead j
<jonathan_> I fear we have specified the unimplementable in PDD15. :-( When you make a change to an already instantiated class, the PDD says it is supposed to clone itself, update the namespace to point to the new version and then make the change on that new version of the class.
<jonathan_> That's fine, but unfortunately, the caller of the add_attribute method or vtable method will still be referencing the original unmodified class, and I see no way to change that. That in turn is a problem because if they modify it again, the old change will be lost; if then call .new(...), the change is lost, etc.
<jonathan_> Have I explained that in a way that makes sense?
<allison> I see what you're getting at, yes
<jonathan_> It's more of an "OH NO!" than a question, I'm afraid.
<allison> essentially, its the illusion of "modification in place" that we're trying to maintain
<leo_> you'd have to return the new modfied class for these actions
<jonathan_> Aye. For the ops that's not a real hardship, for the methods maybe it's a bit annoying having to say $P0 = $P0.add_attribute(...) and so on every time.
<leo_> no chance else I prsume
<allison> and we can't have the class modify itself because then all existing instantiated objects pointing to it would be pointing to the wrong thing
<jonathan_> Yup.
<jonathan_> The cop out option is to say "you have to clone the class yourself before doing a modification".
<allison> this seems like a question that needs example code
<jonathan_> And allowing the "has this class been instantiated" flag to be available through inspect.
<allison> pretty much everything is available through inspect
<jonathan_> Yeah, that isn't at the moment, though I suspect it should be and it's an oversight on my part.
<allison> jonathan: the "clone the class yourself" is the conclusion I came to with names and namespaces last night
<allison> we're essentially looking for an advanced form of morph
<allison> I don't have an immediate answer, but I'll go look over the PDD
<jonathan_> OK, sounds good.
<pmichaud> particle next?
<jonathan_> Thanks. :-) That's all of my questions, for this time.
<pmichaud> particle: ping
<particle> earlier i mentioned my goal of implementing pdd15 pre-release. is there anything more strategic we should be doing instead, and if not, can we split up the work, and expect to focus on it?
<allison> pdd15 is strategically important at the moment 
<Coke> New enterprise scheduling software that allows coordinated, distributed batch jobs across all the platforms used by OIS.
<Coke> Several people in BSB have had training on the software and should be considered go to people in your group. (* These people still need to be identified).
<Coke> whoops. wrong window.
<pmichaud>  /ignore coke :-)
<pmichaud> I would be very very happy to see pdd15 implemented asap
<pmichaud> there are a few design and implementation issues I'm hoping it will resolve
<pmichaud> (for pge and perl6)
<particle> great
<Coke> New enterprise scheduling software that allows coordinated, distributed batch jobs across all the platforms used by OIS.
<Coke> Several people in BSB have had training on the software and should be considered go to people in your group. (* These people still need to be identified).
<Coke> ... I am very sorry.
<pmichaud>  /ignore coke :-)
<allison> :)
<particle> project team spim.
<pmichaud> did we answer your question, particle?
<allison> I think the rest of the question is "how many people have time to work on it this week?"
<particle> i guess you did. we need a list of todo. how about a wiki page?
<allison> I do
<jonathan_> I do, too.
<pmichaud> it sounds like a good goal for the week then
<allison> particle: sounds good, start it and send the link to the list
<jonathan_> I'm probably in the best position to start a todo list.
<particle> jonathan_++
<jonathan_> Point me at the wiki page and I'll happily populate it tonight.
<particle> i'm creating it now, i'll send to list
<Coke> http://www.parrotcode.org/ -> wiki
<pmichaud> I think coke has a question, hopefully not related to OIS
<particle> lol
<allison> Oiy!
<Coke> My question comes in two parts. part one: why does my mouse's second button sit just next to the desk where it inadvertently pastes things repeatedly?
<pmichaud> your mouse hates you.
<allison> Murphy's Law
<Coke> second part: think about what sort of queries you'd like to see out of RT for finding/managing tickets. I'll put some that I think are useful, but please ping me with any suggestions or requests.
<spinclad> do you keep crackers on the desk
<spinclad> ?
<pmichaud> I think we ought to keep the standard queries on a page on the wiki
<leo_>  /resources.html
<pmichaud> it would make it easy for me to cut-n-paste them into my bookmarks :-)
<Coke> as opposed to parrotcode? Well, if they're on the wiki, lower barrier to updating them, anyway, which is good enough for now. we can enshrine them later.
<Coke> k. in that case, "please keep an eye on the wiki".
<pmichaud> we can enshrine the very obvious ones, with a link to the wiki for "other useful RT queries" that can be updated
<leo_> good idea(tm)
<pmichaud> that makes it easy for people to see them on parrotcode, while also making it easy to propose new entries without having to get parrotcode updated
<pmichaud> (not that getting updates to parrotcode is hard -- there's just a delay)
<pmichaud> I'll look through my list of bookmarked queries and see if any ideas come up
<pmichaud> I tend to have a query that finds anything with 'PGE' in it :-)
<pmichaud> anything else for coke's q?
<particle> we need to classify the tickets already in rt
<particle> otherwise queries will be useless
<pmichaud> okay, we need a query that can help us find the unclassified tix :-)
<particle> i'd *love* to see tickets submitted via web
<particle> then you can classify them as you submit, rather than after (and using a different interface)
<particle> btw: http://rakudo.org/parrot/index.cgi?pdd15_todo
<pmichaud> any other questions?
<pmichaud> allison:  to answer your previous q -- POST has the ability to add :slurpy to params, but you're correct that it doesn't appear in the PAST->POST transformation yet.  I'll add it shortly.
<pmichaud> or you can add it if you wish -- it should just be a flag/annotation to the PAST::Var node
<allison> in my code I added an 'isslurpy' param to PAST::Var's init
<pmichaud> works for me
<pmichaud> feel free to commit
<allison> k
<pmichaud> then we just need a way to pass :flat to arguments -- I'll have to think about that a bit
<pmichaud> I have to think about it wrt list context in perl6 anyway
<pmichaud> if no further questions, any discussion?  or are we done?
<pmichaud> I take it we're done for this week
<pmichaud> excellent work, all.  See you all next week
<spinclad> muribus biscues placent (mice like crackers)
% pmichaud has left #parrotsketch
% jonathan_ has left #parrotsketch
% smash has left #parrotsketch
% bernhard has left bernhard!~bernhard@p549A2654.dip0.t-ipconnect.de
% jisom has left jisom!~jisom@74-134-230-123.dhcp.insightbb.com
% dickdawg has left #parrotsketch
% mdiep_ is now known as mdiep
% kjs has left kjs!~IceChat7@seinfeld.xs4all.nl