% pmichaud has joined #parrotsketch
% particl1 has joined #parrotsketch
% particle has left particle!~particle@c-24-22-165-145.hsd1.wa.comcast.net
% particl1 is now known as particle
% PerlJam has joined #parrotsketch
% Coke has joined #parrotsketch
% allison has joined #parrotsketch
% chromatic has joined #parrotsketch
% jhorwitz has joined #parrotsketch
% barney has joined #parrotsketch
<Coke> hello, everyone.
<allison> hello
<Coke> I need a volunteer from the audience to run the meeting. =-)
* jhorwitz waves
<chromatic> I'll do it, unless that was jhorwitz volunteering.
<particle> hi-o
<Coke> chromatic: Tag, you're it.
* jhorwitz was waving hi
* particle thinks jhorwitz wouldn't fare well at an auction
<chromatic> Alright, it's alphabetical order time again.  allison?
* jhorwitz knows when not to bid.  ;-)
<allison> - Prepared a timeline to meet requirements of NLNet grant.
<allison> - Made a branch for PDD 15 development (the pdd15oo branch, there's an older branch named pdd15 that was actually for pdd13 dev)
<allison> - Started ripping out guts of old OO implementation (a pile of commits to follow today)
<allison> EOR
<barney> Scanned RT for resolvable tickets.
<barney> Move substr_r to experimental ops
<barney> Remove 'object' from PIR.
<barney> Trying to grok Lsip lexicals.
<barney> s/Lsip/Lisp/
<barney> .eor
<chromatic> I checked in one of my long-promised GC cleanup patches.  Nothing especially broke.
<chromatic> I patched up the IMCC parser with compiler attributes, which fixed 64-bit builds.
<chromatic> I did more poking at src/hll.c, but things are a mess in there.  I think OrderedHash also has some memory problems related to freezing and thawing.
<chromatic> My plan for the week is to fix as much of Darwin/x86 as possible to unblock Tcl.
<chromatic> Next up, Coke if he's here.
<Coke> ENOREPORT
<chromatic> jhorwitz?
<jhorwitz> as reported to the list, perl6 handlers run under mod_parrot
<jhorwitz> added a directive to set parrot's library search path from apache config, which fixes a few long standing problems with mod_parrot
<jhorwitz> will probably release 0.4 soon
<jhorwitz> EOR
* particle needs to get mod_parrot building on win32
<particle> ...don't hold the release for me.
<chromatic> particle, keep going.
<particle> ~ talked to the folks in irc.perl.org#tbb about using intel's threading building blocks for parallelizing parrot
<particle> ~ kevin farnam aka kevinf blogged about the possibility here: http://xrl.us/5xun
<particle> ~ chatted with folks on irc.freenode.org#perl6 about kp6 futures. they're forking to address two different goals at the same time: STD parsing, and 6-in-6. they're hoping to keep the implementations only slightly divergent with frequent merges
<particle> ~ jonathan has talked about kp6-on-parrot, and fglock mentioned kp6-on-nqp as a possibility today
<particle> ~ hiking in the beautiful pacific northwest has absorbed all time that may have otherwise been devoted to parrot
<particle> .end
* particle registers two comments
<chromatic> pmichaud?
<pmichaud> * Worked more on PAST/POST changes needed for namespace support of symbols
<pmichaud> * I pretty much have the design like I want -- just need to commit it to an implementation
<pmichaud> * I got blocked a bit this past week tracking down why Parrot wasn't building on my 64-bit platform, that's now fixed (chromatic++)
<pmichaud> * Closed a couple of RT tickets
<pmichaud> * Added some new TODO documentation to NQP
<pmichaud> * Converted grammars to use the new form of S05 non-capturing syntax, which looks as though it's set to change yet again
<pmichaud> * Fixed POST to correctly handle the n_mod opcode
<pmichaud> * Fixed a bug in fixedfloatarray.pmc
<pmichaud> * Sent responses to various comments and questions on mailing lists
<pmichaud> * perlDreamer++ now has a commit bit -- I'm the designated mentor
<pmichaud> EOR
<chromatic> spinclad?
<chromatic> tewk?
<particle> oops, forgot to mention that ron++ also has a commit bit, but you knew that from the list post
<chromatic> Okay, let's go to comment time.  particle?
<particle> andy's headerizer needs to be able to deal with .y and .l files, as 'make headerizer' fails currently, which is blocking some cleanups
<particle> i'll likely enter a ticket about that soon, hopefully someone cagey will take a look
<particle> also, tcl doesn't compile on win32, haven't yet investigated why. this is worse than coke's report of tcl segfaults, as it's a parrot segfault
<particle> again, ticket likely today
<chromatic> Maybe you can collar Andy in for the .y and .l files.
<Coke> tickets++
<chromatic> Any other comments?  I have one.
<particle> oh, and one more thing. we now have a language in the repo using svn:externals
<allison> I saw that when I made the branch
<particle> this sets a precedent, as it's the first. i'm not sure whether its workable
% smash has joined #parrotsketch
<allison> is it the whole language, or just pieces of the language?
<particle> whole language
<pmichaud> languages/kea-cl
<barney> The certificate check for key is annoying
<allison> hmm... seems like it could just be completely external, no need for an svn link
<particle> allison: right, that's how it's been handled before
<particle> svk doesn't play nice with svn:externals
<allison> but, we do need to work on the tools for installing language addons
<particle> so, wanna give it a try with this language, and see what falls out?
<allison> try out creating tools for language installs? yes, sounds good
<allison> another ticket?
<barney> svn:externals might be nice for Perl6 test suite
<pmichaud> particle:  does "give it a try" refer to "using svn:externals" ?
<allison> pmichaud: I thought the opposite
<pmichaud> allison: that's why I'm asking :-)
<particle> i'm neutral. i don't like that it happened the way it happened, without discussion, but i'm open to trying life with svn:externals for a while
<pmichaud> svn:externals might work for the Perl6 test suite, when we get to the point that we're willing to grab the entire suite.  But it could leave svk users out in the cold
<particle> i'd rather not do that to our poor unfortunate svk users (although they might use SVN::Mirror::Notify and be done with svk already)
<allison> it seems like a short-term hack to me, trying to solve the lack of good language install tools
<particle> allison: yes, i agree
<allison> we don't want all languages in the parrot repository
<allison> ultimately, we probably don't want any languages in the parrot repository
<particle> also note it wasn't the language author who linked kea-cl in, it was j. random committer
<particle> we'll probably want 'core' languages like abc
<allison> we'll certainly want nqp
<allison> and we'll certainly make distros that include various combinations of languages
<particle> i have set up an empty googlecode repo for parrot languages, called squak
<particle> we could use that repo as a test bed for any work we want to do in dealing with external langs
<allison> I like that
<particle> i'll happily give out commit bits to the interested
<allison> let's remove the link for now
<barney> Why not simply set up another repos on svn.parrotcode.org ?
<particle> *squawk
<allison> if the author wants to request inclusion (by svn link or otherwise), we'll figure it out
<pmichaud> get commit bits on non-perl repos may be easier... also we don't have to deal with CLAs that way
<allison> barney: I think the general idea was to be more welcoming to all languages by making it a repository TPF doesn't manage
<particle> pmichaud: yep, that's why i chose googlecode
<allison> each language can choose its own licensing terms
<smash> i'd just like to point everyone out with the security issue on external links.. like my earlier example to coke: anyone without any metacommitter's control (a third party) can check in a perl test script that for example can do a "rm -rf /" when people do a 'svn up' on parrot's main repo will checkout or update that file, and we all run make test
<allison> well, generally we'd only do external links to trusted sources
<allison> but, we certainly can't stop people from loading untrusted language extensions
<smash> but do you actullay have any control on who can ci on those repos ?
<allison> any more than Perl can stop people from installing untrusted Perl modules (from CPAN or elsewhere)
<allison> smash: that's something we'd have to review for each case
<smash> true true
<allison> e.g. we don't have control over who ci's to the Pugs repository, but we do trust them to quickly remove malicious code
<smash> i see your point.. i'm neither against of for it.. i was just pointing an important issue 
<allison> I have a question, if we've wrapped that one up?
* PerlJam notes that you do have some control via hooks (i.e., you can disallow commits that include updates to svn:externals for instance)
<pmichaud> to summarize:  we're eliminating the svn:external link for now
<pmichaud> ?
<particle> yes, remove svn:externals link to languages/kea-cl
<allison> yes
<pmichaud> PerlJam: yes, but part of the reason we have limited commit access to the parrot repo is so that we don't have to have those sorts of commit hooks
<particle> message the list, refer to this discussion, perhaps open a ticket.
<allison> but will leave open the question of whether svn:external is a good tool to use later
<PerlJam> pm: Then a clearly published policy is needed :)
<allison> (it may be worth it, but isn't worth it for this language)
<allison> PerlJam: yes, that's a doc that hasn't been finished yet (I don't even remember who was working on it)
<particle> we should also invite fperrad to #parrotsketch meetings. next topic?
<chromatic> Questions?
<chromatic> I have one.
<allison> particle: good idea, fperrard welcome
<chromatic> How do we test that freeze/thaw work for PMCs?  I suspect it doesn't for OrderedHash.  Can we prove that somehow?
<particle> chromatic: freeze and thaw are available via the api, so we could write tests in c
<chromatic> I was hoping that Jonathan would be here; he knows more about PBC.
<allison> we have PASM/PIR ops freeze and thaw
<allison> getting the frozen string representation and thawing it back to a PMC should be enough
<allison> (at least for a core line of tests)
<particle> or does it need to be testing with load_bytecode?
<Coke> You might not want it to be done in the same interp.
<barney> Also testing across platforms would be nice, like t/native_pbc
<Coke> (or the same HLL. or namespace. or...)
<allison> aye, good additions
<chromatic> I think within the same interp but after a GC run would be enough to demonstrate basic correctness for now.
<Coke> k.
<chromatic> Other questions?  I have one more.
<particle> allison said she had one
<barney> RT#42769
<allison> on keywords in PIR?
<chromatic> I agree with the conclusions in #42769.
<chromatic> Valid register types should be only int, float/num, string, and pmc.
<particle> yep, agreement here, too.
<chromatic> (I wouldn't mind getting rid of "float" as a synonym for "num" either.)
<pmichaud> agreed here also
<allison> agreed
<pmichaud> does it need a deprecation cycle?
<barney> I'll put it in DEPRECATED.pod
<particle> could it hurt?
<allison> I don't know anyone who uses more complex type names in .locals
<Coke> that was mostly ripped out ages ago.
<allison> yes, give it a standard deprecation cycle
<chromatic> The next release is almost here, so we can whack it in a couple of weeks.
<particle> barney++
<barney> I've only seen one or two tests
<barney> using complex declarations
<allison> I'll add a note to the ticket
<chromatic> Anything else?
<allison> my question is on the NLNet timeline draft (for those who are reviewing it)
<allison> mainly for the people whose names I put next to dates
<pmichaud> I still need to read the draft -- will do that shortly
<allison> ok, I'll send them a copy of the draft today, so they have an early opportunity to comment
<pmichaud> allison: my timelines in that document look okay to me
<pmichaud> allison: I presume it's okay if we complete them earlier than the given date?  ;-)
<allison> absolutely :)
<allison> early completion is a plus
<pmichaud> are we done with #ps ?
<chromatic> Looks like it.
<pmichaud> okay, I'm done.  See you all next week
% chromatic has left #parrotsketch
% jhorwitz has left #parrotsketch
% barney has left barney!~bernhard@p549A3A2C.dip0.t-ipconnect.de
% Coke has left #parrotsketch
% pmichaud has left #parrotsketch
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
% allison has joined #parrotsketch
% allison has left allison!~chatzilla@c-24-21-59-142.hsd1.mn.comcast.net