% mdiep has joined #parrotsketch
<particle> tewk: i suspect File::Spec->canonpath will work in addition to your way for the FindBin patch
<particle> ww
% chromatic has joined #parrotsketch
% allison has joined #parrotsketch
<obra> Hi, gang
<allison> yo
<mdiep> hi all
<particle> oi
<leo_> hi @all
* tewk present
<chromatic> hello
<obra> wow. so well trained you all are ;)
% pmichaud has joined #parrotsketch
<obra> Hey patrick.
<obra> (I've also pinged chip)
<pmichaud> here today, on phone with calls -- available in 10 min (I hope)
<obra> ok. we'll go in order of "hi" then: allison, mdiep, particle, leo_, tewk,chromatic, pmichaud , stragglers
<allison> ah, damned by my own quick typing :)
<mdiep> heh
<allison> I've been working on the Threads PDD.
<allison> Most of it is checked in now.
<allison> Just a bit more discussion I want to summarize and include.
<allison> I'll finish that off this week. (I was going to finish it last week, life has been... lifelike.)
<allison> EOR
<obra>   mdiep 
<mdiep>  - Fought with svk for a couple hours... and gave up
<mdiep>  - Patched ResizableStringArray to allow $S0 = array[-1]
<mdiep>  - Made a lot of progress on forth; the only challenge left is variable access
<mdiep>    * Forth variables are essentially C pointers <http://www.amresearch.com/starting_forth/sf8/sf8.html>
<mdiep>    * Any "pointers" on how to handle them would be appreciated
<mdiep>    * Thinking about writing a PMC that allocates a stack of memory to use for variables
<mdiep> ^D
<obra> particle: your turn.  
<particle> ~ first commit of smartlinks.pl, linking tests to specs. so far, i'm still constructing objects. soon, i hope to implement the clever bits.
<particle> ...as an aside, Moose is a fun object framework, which i've just started to explore...
<particle> ~ emptied the code cleanup patch queue, which has allowed ptc++ to fill it up again :)
<particle> ~ committed some pge glob tests, including some failing which pmichaud++ fixed
<particle> ~ some more tests and info for the (still incomplete) calling convention state table -- i'm hoping for feedback from chip
<particle> ~ the usual patches, fixes and #parrot presence
<particle> .end
<obra> leo_: 
<leo_> * was discussing a lot of sprintf format chars
<leo_> * fixed totally b0rked %c conversion
<leo_> * and a lot more
<leo_> * discovered actually a (likely) perl5 bug converting "%03.2d" and such
<leo_> - we've either to follow susv3/posix/gcc or perl5 here for now
<leo_> ^D
<obra> tewk: 
<tewk> I've been digging into parrot intenals searching for my HLL method dispatch bug.
<tewk> I'm getting more comfortable with the internals.
<tewk> I've been learning a lot about packfiles and have some C coding sytle suggestions that will hit the list today.
<tewk> I'm going to send some C cage cleaning diffs to Chip and the list.
<tewk> EOR
<obra> chromatic: 
<chromatic> Fixed up Parrot::Embed -- now have Parrot::Interpreter and Parrot::PMC objects that should behave nicely with regards to garbage collection on both sides.  This needs documentation, but otherwise it's fairly complete for what it does.
<chromatic> That's it.
<obra> Damn. six minutes. we need 4 more minutes.
<obra> Ok. so. noow, same order. name me the thing that's frustrating you most about development right now.
<obra> allison: you're first
<pmichaud> <-- off phone
<allison> first at?
<obra> 14:12 <obra> Ok. so. noow, same order. name me the thing that's frustrating you most about development right now.
<obra> 14:12 <obra> allison: you're first
<allison> I'm designing things that aren't getting implemented.
<pmichaud> <-- ready to report
<allison> It's like a dead feedback loop.
<obra> pmichaud: as soon as we've done this round of this thing ;)
<pmichaud> fair enough
<mdiep> svk isn't working
<obra> particle: 
<particle> large lag time synchronizing ideas with design team
<obra> leo_: 
<leo_> no feedback re various design questions on p6i
<obra> tewk: 
<tewk> Hll method dispatch bug is blocking cardinal devel
<obra> chromatic: 
<chromatic> Too many open projects and avenues of exploration blocking on various things.
<obra> pmichaud: (frustration, then report)
<pmichaud> frustration:  real life keeps hitting me in unfortunate ways
<obra> Thanks for that everbody. 
<obra> pmichaud: what's new dev-wise for you?
<pmichaud> (brief rl summary: Paula ended up in ER weekend before last; we're still dealing with tests to try to figure out what's wrong)
<pmichaud> dev report:
<pmichaud> * cleaned up the sprintf test suite a bit, to eliminate the failing tests or mark them as todo as appropriate
<obra> (rl: is she basically ok?)
<pmichaud> * worked on fixing PGE namespaces -- expect to have that this afternoon. 
<pmichaud> * PGE namespaces will require some changes to various languages, but I think I can minimize the impact
<pmichaud> next plan is updated PAST implementation, will start that immediately after ns stuff
* particle is on hand to provide pge migration assistance for languages
<pmichaud> in answer to allison's frustration, the PGE ns stuff will quickly let us know if the NS pdd is going to be workable
<pmichaud> end of dev report
<allison> cool
<obra> ok. question time?
<pmichaud> (rl: yes, paula seems to be basically okay now, but we're getting conflicting diagnoses.  None of them are life threatening.)
* tewk will be meeting with Matz (creater of Ruby wednesday and thursday) and attending RubyConf Fri-Sun, does the parrot group have any questions for Ruby people?
<obra> pmichaud: please send her our best.
<pmichaud> obra: thanks, will do.  
* pmichaud has one question.
<obra> pmichaud: go for it
<chromatic> tewk, it might be nice to see a sample of bytecode from Ruby 2.0 and perhaps diagrams of their AST.
<pmichaud> question: has anything like the :init pragma for subs been implemented yet?
<pmichaud> earlier in the summer we discussed the possibility of :init -- I don't know where that ended up
<tewk> chromatic: noted
<mdiep> is there any reason to have :load? everywhere I've used :load or seen it used, it's been used like :init
<mdiep> or can :load be made into :init?
<pmichaud> I can conceive that there might be situations where loading a .pbc (:load) would be different from running it (:main/:init)
<leo_> what's the planned difference again?
<pmichaud> the planned difference:  subs marked :init are executed before :main
<mdiep> :init runs before :main in addition to running on load_bytecode
<pmichaud> we might want :init to be orthogonal to :load
<pmichaud> thus  :load --- run on load_bytecode      :init -- run before :main
<mdiep> and :init :load does both
<pmichaud> exactly
<particle> hrmm... now :load runs *unless* :main is defined
<allison> hmmm... that doesn't sound quite right, but now I can't find the relevant messages
<pmichaud> particle:  I don't think that's exactly right
<pmichaud> :load runs only in response to load_bytecode
<pmichaud> I don't think :load is affected by :main
<pmichaud> what I'm wanting to avoid is having to write the separate code in :main that causes all of the :load subroutines to be called
<particle> Run this subroutine during the load_library opcode. :load is ignored, if another subroutine in that file is marked with :main. If multiple subs have the :load pragma, the subs are run in source code order.
% smash has joined #parrotsketch
<particle> ...from http://www.parrotcode.org/docs/imcc/calling_conventions.html
<leo_> I think you can always rearrange your code such that you can get desired order with current :flags
<pmichaud> (especially when the .pbc is being formed by merging multiple .pbc's or via combining separate generated files via .include)
<pmichaud> is it true that :load is ignored if there's another sub marked :main?
<pmichaud> hmmmmm
<particle> yes
<particle> i've tested it
<pmichaud> is there a _reason_ for that behavior?
<particle> ask dan?
<leo_> specced by dan
<allison> it's so you can have some behaviour when running as a script and some when running as a module
<leo_> yep
<pmichaud> but we can already do that if we simply say that :load means "execute only when loaded as module"
<allison> that's what it should be
<leo_> well, else :main or the first sub is run
<allison> aye, it's not what it is, but it's what it was intended to be
<pmichaud> also, the calling_conventions.html says C<load_library> opcode -- shouldn't that be C<load_bytecode>
<pmichaud> what's the significance of C<load_library> here?
<allison> I think that was the old name
<leo_>  C<load_library> is loading .dll / .so / .dylib
<allison> ah, right
<pmichaud> right, I suspect the spec wasn't clearly thought out when written
<chromatic> Same as C<load_bytecode> loads .pbc / .pir / .pasm.
<pmichaud> yes, but there is no :main/:load with C<load_library>, is there?
<allison> I can't find :init in google/my parrot email archive
<allison> or searching through the repository
<particle> pmichaud: no
<leo_> sorry C<loadlib> that is
<particle> allison: i know it was discussed previously on #parrotsketch
<allison> but, IIRC, :init is supposed to act more or less like Perl 6 INIT
<leo_> there isn't any load_library op
<pmichaud> okay, so calling_conventions.html is at least wrong with respect to the name of the op :-)
<pmichaud> anyway
<obra> ok. waht's next?
<pmichaud> I want to have some sort of pragma that says "automatically run this sub when the module is invoked via parrot"
<obra> er. sorry. didn't mean to cut you off
<pmichaud> obra: np
<allison> (it was dicussed on p2 also, I just can't find it)
* mdiep is with pmichaud. this is a very common usage
<leo_> what does "invoked via parrot" mean?
<pmichaud> and I'd like for the :load pragma to mean "automatically run this sub when the module is loaded via load_bytecode"
<particle> email from august 3
<particle> [perl #39926] :init attribute (was Re: Implement .loadlib pragma in IMCC)
<pmichaud> leo:  "invoked via parrot" means    parrot perl6.pbc
<leo_> this one is called :main ;)
<mdiep> but you can only have one :main
<allison> blast, thunderbird has the worst search capabilities of any email client :(
<pmichaud> leo:  no!  I don't want just one sub, I want multiple
<leo_> it's the entry point
<allison> :main is the entry point
<leo_> call them from a dummy :main
<chromatic> Yes, but then he has to call all of the init() subs from that :main again, which is exactly what he doesn't want to do.
<pmichaud> leo: that's the thing I'm trying to avoid -- I don't want to have to write a :main that knows all of the init subs
<allison> no, main is for execution, not for loading
<leo_> I see
<pmichaud> especially when the perl6.pbc file has been automatically generated from a lot of other specifications, which may or may not need some form of initialization to take place prior to main
<chromatic> I'd love to be able to declare all of my classes and attributes in :init subs,
<allison> yes we should have :init
<tewk> Yes chromatic ++
<allison> does someone want to volunteer to write up a paragraph or two about it?
<pmichaud> I'll write the paragraph immediately following #parrotsketch, as it's an annoyance
<allison> post it to the list, and then lets get it into the documentation so we can find it next time this comes up?
<pmichaud> if I had enough parrot-fu I'd implement it
<pmichaud> (it's that big of an itch to scratch)
<allison> excellent
<allison> thanks :)
<pmichaud> I'll be sure to reference #39926, or add the message to that ticket
<pmichaud> okay, obra, I'm off my box now :-)
<particle> question... are there milestones we should be working toward?
<tewk> ref the parrotsketches too.
<pmichaud> tewk++
<obra> particle: That's a good question.
<obra> The problem with the current milestones is "design up front"
<allison> the big unfinished subsystems
<allison> or, are you looking for something smaller
<pmichaud> pm's milestones:  pge ns, past, perl6 compiler fixups, tge
<allison> obra: not true, exceptions could be being developed now
<chromatic> One problem is, we don't really have anyone turning PDDs into (failing) tests.
<particle> exhaustive testing of newly implemented subsystems is way behind
<obra> allison: I'd like to take the current milestones doc and create a matrix of it on its side, broken up by subsystem.
<pmichaud> obra++
<obra> which subsystems need testing next?
<obra> I _will_ have that by next week
<pmichaud> and chromatic++   .  I might grab the features from the pdds that I think I'm likely to want soon and turn those into failing tests
<allison> obra: cool
<chromatic> CAGE could do a lot of work on writing tests.
<obra> chromatic: did you get any takers on your request for a surrogate cage-wrangler?
<particle> calling conventions still need testing (there are known bugs.) namespaces, exceptions....
<tewk> Hash anyone approached Bob Rogers about doing exceptions?  He has been doing a lot of continuation and corroutine work.
<pmichaud> chromatic:  would it work if I simply identified for CAGE the pdd features I'm wanting tested soon?
<pmichaud> chromatic: and then let them write the tests?
<obra> pmichaud: that would certainly _help_
<particle> tickets without direction probably isn't enough
<particle> so a wrangler is important
<pmichaud> okay, I'll spend an hour today with the latest pdds and identify the specific items I'd like to have tests for
<obra> let's start with a couple of messages to the list before tickets get created
<allison> particle: yeah, we've reached ticket overload :)
<obra> tickets are useless without a higher-level wrangler.
<chromatic> Hal Wigoda responded; I think he's interested in wrangling.
<obra> (and I have a bit of experience there ;)
<particle> we're getting plenty of code cleanup patches, which is *great*, but i'd really like to see tests for functionality
<obra> particle: could you (Easily) create TODO stub test files?
<particle> yes
<pmichaud> yes, I'll see if I can provide some feed for a wrangler to pass along to CAGE cleaners
<obra> particle: that'd be great
<particle> done for all pmc files already...
<particle> ok
<pmichaud> shouldn't take long, and it would help with the feedback loop that allison mentioned
<obra> yep
<obra> it'd make it easy for people to make a one-line addition to help
<pmichaud> well, probably more like ten-line additions.  :-)
<particle> having a cohesive strategy for community involvement would be a great goal for chicago hackathon (live bodies)
<chromatic> I'd rather hack software there, actually.  Ew.
<obra> pmichaud: :)
<particle> ...before hackathon, i mean
<obra> how possible would it be to get CLAs and commit bits sorted out on the spot for contributors?
<obra> at the hackathon
<particle> ooh, that would be fantastic, if possible.
<pmichaud> it's looking very unlikely that I'll make it to chicago.  However, I can dedicate myself fully to IRC for the hackathon days except saturday
<obra>  allison: would you be comfortable with that?
<particle> pmichaud++
<obra> assuming a gatekeeper delegate you approve of
<pmichaud> so, I won't be physically present, but I'll at least be around to answer questions and work on hacking
<particle> and we've got your number if fingertips are slow
<chromatic> I can manage CLAs at the event.
<pmichaud> yes.  Saturday is the one sticky day where I'm fully committed to be elsewhere (and thus can't make it to Chicago)
<obra> chromatic: thanks.
<pmichaud> but other than that I can make myself available.
<allison> CLAs and commit bits on site
<allison> depends on the person
<obra> right: that's why I was asking about an approved gatekeeper
<obra> . O { Chip will be there, right? }
<allison> yes, chip is planning to be there
<allison> if he approves someone I'm comfortable with that
<obra> ok
<obra> chromatic: come with a stack of CLAs?
<obra> (er, go)
<obra> what else do we have for today?
<allison> (still following the general policy of only accepting committers after they've put in a quantity of sane patches)
<mdiep> are current committers supposed to sign CLAs?
<allison> yes
<chromatic> Anyone with a commit bit should have signed a CLA.
<particle> i think paul cochrane should be on the short list for a bit... his patches are quite good now
* mdiep hasn't signed one yet, but will hopefully make the hackathon
<particle> allison: i'll probably recommend him after applying his currently submitted patches
<allison> particle: great
<obra> other topics?
<obra> failing that, I'll catch y'all next week
<allison> thanks jesse!
<leo_> cya - thanks jesse
% chromatic has left #parrotsketch
<pmichaud> until next week!
% pmichaud has left #parrotsketch
% smash has left #parrotsketch
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
% mdiep has left mdiep!~matt@c-71-205-39-103.hsd1.mi.comcast.net