% Coke has joined #parrotsketch
% tewk has joined #parrotsketch
% pmichaud has joined #parrotsketch
% jonathan has joined #parrotsketch
% barney has joined #parrotsketch
% chromatic has joined #parrotsketch
% davidfetter has joined #parrotsketch
% allison has joined #parrotsketch
<chromatic> Okay, who's here today?
<chromatic> I even saw Coke.
* barney is here
* pmichaud is present.
* davidfetter yo
* particle *coughs*
<allison> hi
<chromatic> Alright, let's go in order of reporting then.
<chromatic> barney?
<barney> I have been lept busy with other things.
<barney> Tried to refactor Parrot::Test.
<barney> Will continue with tests for Lisp.
<barney> Plumhead is on hold.
<barney> .eor
<barney> s/le/ke/
<chromatic> pmichaud?
<pmichaud> * Worked some more on NQP, but now I'm running into segfaults with it
<pmichaud> * I need to track those down a bit... otherwise I'll just start using -G everywhere
<pmichaud> * Saturday I did a presentation for the local Python users group -- I have 2-3 people that are very interested in hacking Pynie (they've already downloaded Parrot and started looking at the grammars)
<pmichaud> (and reporting bugs)
<davidfetter> ENOREPORT :/
<pmichaud> * Other family issues continue to steal random portions of time, but that seems to be clearing up for a week
<pmichaud> * I'm still expecting to have NQP and PCT completed by OSCON (which would be this time next week)
<pmichaud> * Per discussion with particle, I'm holding off on the NQP checkin until after today's release (or will check it into a branch)
<pmichaud> (I have one question)
<pmichaud> EOR
<chromatic> davidfetter?
<davidfetter> sorry. see above.
<chromatic> particle?
<particle> applied some patches ; doing release prep ; segfaults suck ; PLATFORMS updates welcome ; .end
<chromatic> allison?
<allison> I've been working on the object implementation. I knocked out the big problem of initialization, so you can now use the 'new' opcode with pdd 15 classes.
<allison> I added a new feature allowing you to pass a class object to the new opcode, instead of just a string or key name.
<allison> Also a number of cleanups along the way. I'm holding of on further internal refactoring until after the release.
<allison> There's only one more big feature gap before switching over to the new object model, and that's adding methods and vtable overrides from an associated namespace.
<allison> Then more cleanups and we should be ready to shift.
<allison> EOR
<chromatic> I finished porting Pheme to PAST-pm and deleted over 1400 lines of code.
<chromatic> There's one nasty hack in there, but it may be a limitation of TGE currently.
<chromatic> I also fixed two segfaults in the shootout tests in the default runcore and am looking at another problem with CGP right now.
<chromatic> EOR
<chromatic> Did I miss anyone else who has a report?
* Coke 
<chromatic> Cok?
<chromatic> e
<Coke> Project -
<Coke> Did very basic triage on RT queue - everything is now open or stalled (RTCLI++)
<Coke> Developers, please check the tickets you have assigned to you, give them up if you're not working on them, close them if possible.
<Coke> Helpers, go through old tickets, check to see if the ticket is still relevant.
<Coke> I'd like to clean up a few crufty tickets each week.
<Coke> #Feel free to steal these.
<Coke> Tcl - Pondering converting to using HLLCompiler.
<Coke> XML - Pondering adding something ala JSON's current implementation.
<Coke> Lots of pondering, not much coding.
<Coke> Xcode - Pondering getting parrot running in OSX's IDE.
% ptc_away has joined #parrotsketch
<Coke> .eor
<chromatic> Okay, question time.  I have two and pmichaud had one.  pmichaud?
<pmichaud> this one is for allison --
<pmichaud> earlier in the week you posted a change to pdd15 that said that retrieving from an unset attribute would return undef
<pmichaud> I responded that it should return NULL (to be consistent with other similar operations), but no response -- any comment?
<pmichaud> (and are my messages not showing up in your inbox? ;-)
<allison> sorry, my inbox is flooded
<allison> agreed on Null
<pmichaud> I can totally empathize with that :-)
<allison> it currently returns Undef, which seemed odd to me
<jonathan> * Back from vacation
<jonathan> * This week: sorting out my OSCON talk and trying to get something together for YAPC::EU proceedings
<jonathan> oops
<jonathan> sorry
<jonathan> Well, that was my report.
* jonathan didn't mean to right-click then. :-)
<allison> finish the report?
<jonathan> Er, that's it.
<allison> ok, cool, carrying on
<pmichaud> okay, I just wanted to make sure that we get some consistency.  My message also recommended that we standardize on get_attribute and set_attribute
<pmichaud> but I can argue those either way
<allison> but balancing between the two, it seemed sensible to leave the implementation in place until I had some feedback from users
<pmichaud> okay.  I come down strongly on the side of return NULL for unset attributes.  Otherwise it's very difficult to determine that an attribute is unset
<jonathan> I assume access to a non-existent attribute is an exception?
<allison> (the reason it currently returns undef is that it's just relying on the internal storage of a ResizablePMCArray
<pmichaud> jonathan: yes, that's what the spec says (and I agree)
<pmichaud> but ResizablePMCArray currently returns NULL...?
<jonathan> IIRC, it's what's implemented to.
<pmichaud> oh wait
<pmichaud> you're right, ResizablePMCArray returns undef
<pmichaud> interesting.  Hash returns null, fwiw
<allison> really, it can go either way, it's just a question of which is most useful
<allison> and, yeah, we should probably be more consistent across all the PMCs
<allison> that's a good point for the PMC PDD
<pmichaud> Hash returns null, along with the various get_global opcodes
* allison adds a note to PDD 17
<pmichaud> at one point I think we had a Null PMC type that was returned for unset elements in containers
<pmichaud> that could work also
<pmichaud> but returning NULL seems easier
<allison> ah, interesting
<pmichaud> (if only because we have an if_null opcode that makes it easy to handle such cases)
<allison> Null is certainly cheaper, if we don't need an actual PMC there
<jonathan> I think that returning NULL always puts the Null PMC into the PMC register anyway.
<jonathan> As in, really you should return PMCNULL
<chromatic> Do we have a singleton NULL?
<jonathan> Yeah.
<jonathan> It's a singleton.
<chromatic> Clever.
<jonathan> Or such is my understanding.
<jonathan> I guess if_null op must test it.
<jonathan> Is it the singleton, etc.
<jonathan> That's my understanding of it, anyways.
<particle> ack "define PMC_IS_NULL"
<allison> ok, we'll double-check the implementation of PMCNULL and if it is really a singleton Null PMC, we standardize on that
<pmichaud> I don't think it is
<jonathan> OK
<pmichaud> because other vtable ops don't seem to do reasonable things on NULL values
<pmichaud> so it doesn't act like a PMC
<chromatic> I wonder if we can decorate the functions that return PMC * such that they never return NULL.
<particle> well, heck. once we're role based, we'll compose the singleton role into Null PMC
* jonathan reserves a question spot
<pmichaud> in particular, trying to do     unless $P0 goto xyz    will fail if $P0 is null
<allison> and, if we don't have a singleton Null PMC, we create one. I like it the best of all the other solutions
<pmichaud> I wouldn't expect it to fail if it was a "Null PMC"
<allison> I'll copy this into PDD 17
<jonathan> pmichaud: I think it fails because unless calls get_bool on $P0, and the Null PMC throws a Null PMC access exception.
<jonathan> For *any* vtable call
<jonathan> Including get_bool
<pmichaud> jonathan: that's possible
<chromatic> It sounds like we have an answer.  Shall we move on?
<allison> yup
<pmichaud> yes, I'm very satisfied.  Thanks to all.
<chromatic> Okay, my turn.
<chromatic> barney, what's your take on reclaiming old languages?  Most of them don't use PGE/TGE.  Should they?  Is that valuable?  Is it time-consuming?
<Coke> I have input on that.
<particle> chromatic: we can add PARROT_CANNOT_RETURN_NULL
<chromatic> Coke, go ahead.
<Coke> if they fail, we should try to get someone to update them. failing that, they should be removed. they'll always be in svn. they don't have to use pge/tge; esp for some of the small languages, it's overkill and not worth converting.
<Coke> Perhaps 0.5.0 would be a good target for cleaning out some cruft there.
<pmichaud> on a related question, are any languages using compilers/past ?
<chromatic> I just moved Pheme to PAST-pm; that's the only one I knew about besides Punie.
<pmichaud> or compilers/post ?
<pmichaud> I think Punie has switched to PAST-pm
<Coke> I honestly don't know what tcl ended up with. =-)
<allison> Punie has switched
<pmichaud> was Tcl using any of the asts?  I thought it was primarily using PGE for parsing and that's about it...?
<particle> pmichaud: delete them an run make languages-test
<chromatic> I seem to remember creating at least one of those directories for Punie/Pheme.
<pmichaud> chromatic: your memory is correct
<pmichaud> particle: I'm thinking we can deprecate compilers/p[ao]st in this release and remove them in the August release
<Coke> deprecation good. this parrot is fat.
<particle> sounds good. get the rt# into deprecated.pod.
<pmichaud> (I haven't tried running make languages-test with them missing.  However, make languages-test doesn't always test all languages -- e.g., perl6 isn't part of make languages-test)
<chromatic> It could be, now.
<particle> it *should be*, now
<barney> Sorry, I have been away
<allison> can you mark them as deprecated in today's release?
<allison> then remove them tomorrow, and give a month for everyone to try it out and see if it catches them?
<barney> I aggree with coke.
<barney> perl6 is not in languages-test, as it doesn't have Perl5 test scripts.
<chromatic> My only concern with not generally porting these languages to the compiler tools is that the languages may need external tools (such as Perl 5).
<Coke> chromatic: if these were "officially supported parrot languages", that might be a concern.
<pmichaud> I'll make sure that the deprecation note for compilers/p[ao]st/ goes in immediately following parrotsketch
<chromatic> They're in tree, but not supported?  That seems odd.
<Coke> it is.
<Coke> There's an argument to be made that they shouldn't be in the parrot distro.
<chromatic> Maybe we should re-evaluate the reason they're in the distro.
<pmichaud> I think that as we get closer to 1.0 we'll start winnowing out languages that "aren't supported" 
<barney> I think it's OK for languages to use other tools.
<pmichaud> either through deprecation or by farming them out to other repositories/locations
<particle> i've created a googlecode repo called 'squawk' that i've earmarked for parrot hlls
<Coke> parrot doesn't really have any languages that are part of our deliverable at the moment.
<allison> anyone want to volunteer to do a survey of languages, what features of parrot they depend on and what external dependencies they have?
<particle> coke: abc is.
<Coke> particle: fair enough.
<chromatic> Fair enough.  This is a longer term question that doesn't need an immediate answer.
<allison> the conversation is pretty vague without concrete details
<barney> Languages.status is mostly up to date. Where data can be rather old :=)
<Coke> for now, I think the goal of getting them running (and in the master test suite) is a good one, and we should be eventually strict about killing them.
<chromatic> barney, in theory Perl 6's tests can run through the same system; I made a Perl shim that can run through Test::Harness appropriately.  Pheme uses the same system.
<Coke> once that's done, we can see about ratcheting down requirements.
<allison> good concrete plan, let's run with it
<Coke> there's already a ticket for the perl6 in the master test suite.
<barney> Switch to Test::Run is also on option.
<allison> we're working toward eliminating Perl 5 from the parrot support framework
<allison> so, the effort of switching to a different perl 5 framework isn't worth it
<Coke> "working toward" is a very strong phrasing.
<Coke> more of a "we'll get to it eventually" at the moment.
<allison> ok, "our goal is"
<Coke> any major changes are probably not worth it, though, yes.
<barney> Well the framework is TAP, where the actual implemention happens to be Perl5
<particle> if we move to anything, i'd like it to be TAP::Parser (destined to be Test::Harness 3.0)
<allison> aye, and I expect to be TAP based permanently
<barney> me too
<chromatic> Okay, shall we move on?
<allison> yup
<chromatic> pmichaud, can you open tickets for your segfaults, once you get them reproducable?  I'd like to help fix them if possible.
<barney> Are there hackathon plans for YAPC::EU
<barney> ?
<pmichaud> chromatic: yes.  So far they are very un-reproducable
<Coke> (fix them) hey, you still haven't fixed mine!
<allison> barney: I don't know. jonathan: did parrot get a registered hackathon in the session days?
<chromatic> I fixed a GC segfault the other day!
<jonathan> allison: No
<particle> wrong one, c. that doesn't count :P
<jonathan> But I expect we'll have a Parrot BOF?
<jonathan> And hopefully this year, I will read the BOFs noticeboard and actually know about it!
<allison> jonathan: yes, an evening BOF
<jonathan> OK
<chromatic> Any segfault someone can reproduce in PIR, I'll try to fix.
<allison> my schedule is tight enough that I won't arrive until the evening before YAPC, and leave the morning after
<jonathan> Whoa!
<particle> hallway-track hackathon, then :)
<jonathan> Aye.
<allison> that's my plan :)
<jonathan> I gotta be somewhere else in a couple of minutes...
<jonathan> allison: Did you get chance to look at the PMC inheritance stuff I implemented? Is it right? Good? Horrible?
<particle> okay, so i'm waiting on the deprecated.pod updates for release. any other reason i should wait?
<chromatic> testC fails horribly
<particle> there is a known cgp segfault (seen in shootout)... is that why?
<chromatic> I saw several failures actually.
<chromatic> I don't see the shootout failure.  I think that's Darwin only.
<particle> i'll check ubuntu as soon as parrot's built here.
<particle> i can wait a few hours if you think we can track down the testC failures
<chromatic> I'm working on it.
<particle> oh, i have a question about default.pmc
<particle> we still have those warnings about the vtable functions missing during pmc2c
<chromatic> Let's whack them.
<particle> get_integer_keyed_int or whatever
<pmichaud> (deprecated.pod updated, r19935)
<allison> kill, kill
<particle> why is is_equal_str gone?
<particle> 'get_bool_keyed_int' 'elements_keyed_int' 'set_bool_keyed_int' 'is_equal_str'.
<allison> jonathan: I didn't get a chance to look at PMC inheritance yet
<particle> he's probably left.
<allison> ah, right, I'll email
<chromatic> Any other questions?
<particle> i'm gonna pre-commit the release stuff now
<particle> feel free to review
<pmichaud> I'm done
<particle> note, when i do this commit, it will force realclean for everybody
<particle> i'm getting testC failures on ubuntu, too.
<chromatic> Some 38 test files, right?
<particle> yes. i stopped the test suite so i could debug
<particle> lot's of files fail.
<chromatic> Shall we move back to #parrot?
<particle> yes.
% chromatic has left #parrotsketch
% pmichaud has left #parrotsketch
% allison has left #parrotsketch
% davidfetter has left #parrotsketch
% Coke has left #parrotsketch
% barney has left barney!~bernhard@p549A3133.dip0.t-ipconnect.de
% ptc_away is now known as ptc_asleep
% jonathan has left jonathan!jonathan@feather.perl6.nl
% PerlJam has left PerlJam!duff@feather.perl6.nl
% leo has left leo!lt@feather.perl6.nl
% leo has joined #parrotsketch
% PerlJam has joined #parrotsketch
% jonathan has joined #parrotsketch
% leo has left leo!lt@feather.perl6.nl
% PerlJam has left PerlJam!duff@feather.perl6.nl
% jonathan has left jonathan!jonathan@feather.perl6.nl
% jonathan has joined #parrotsketch
% PerlJam has joined #parrotsketch
% leo has joined #parrotsketch
% ptc_asle1p has joined #parrotsketch
% ptc_asleep has left ptc_asleep!~cochrane@p5B0FC752.dip.t-dialin.net