% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% masak has joined #parrot
% ruoso has left ruoso!~ruoso@81.84.157.134
% jan has joined #parrot
% clunker9__ is now known as clunker3
% cotto_home has left cotto_home!~cotto@75-92-237-130.sea.clearwire-dns.net
% cotto_home has joined #parrot
% iblechbot has joined #parrot
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% cosimo has left cosimo!~cosimo@pat-tdc.opera.com
% kj has joined #parrot
% cosimo has joined #parrot
% bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au
<TiMBuS> anyone here bored enough to help me out?
<moritz> depends on the kind of help you need ;)
<TiMBuS> trying to implement a compiler
<TiMBuS> im pretty terrible at it but hey its my first attempt
<moritz> I'm not too familiar with PCT, so I can't promise to help
<TiMBuS> well, i need to put function pointers in a pmcarray
% ruoso has joined #parrot
<TiMBuS> im not really sure how to go about how to make the PAST for doing so. would i use the 'sub' pmc?
<moritz> do you mean pointers to HLL functions?
<TiMBuS> yes
<TiMBuS> im implementing the language 'joy', which needs lists with functions in them
<TiMBuS> so i figures a pmcarray would work best.. although i might be wrong
<moritz> I think it should work
<moritz> I know that perl6 implements anonymous subs already
<moritz> maybe you can find out they do it by looking at the code
<TiMBuS> yeah i was looking at that
<moritz> just 2k lines in actions.pm ;-)
<jonathan> morning
<TiMBuS> heh
<moritz> good morning jonathan
<moritz> jonathan: be our (or better TiMBuS') saviour ;)
<moritz> how to store sub pointers in an array in PCT
<jonathan> To get the Sub, I guess just use a PAST::Var node, with :scope(package)
<jonathan> And :name(...) set to the name of the sub itself
<jonathan> If you're tyring to do it in PAST, anyway.
<TiMBuS> well the issue is, i want the sub inside a resizablepmcarray
<TiMBuS> it won't be ran until something 'runs' the array
<TiMBuS> yay homoiconic languages =/
<jonathan> Yes, using the PAST::Var node just gets you the Sub, it doesn't run it.
<jonathan> Then you can put it in an array, using the keyed_int scope.
<TiMBuS> ah
<jonathan> And a PAST::Op node of pasttype bind to put it in there.
<TiMBuS> ooh. so the PAST::Var node returns a 'Sub' pmc?
<jonathan> Yes.
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
<TiMBuS> that should do it then
<jonathan> Hopefully. :-)
<TiMBuS> i probably should have made an ordinary imperative language but i haad to be different
<kj> TiMBuS: you might have a look at the PCT tutorial in languages/squaak/doc, maybe there's some useful info there for you
<TiMBuS> hey they've all been added.
<jonathan> Heh, I'm planning to try getting ML running on Parrot.
<moritz> jonathan: exercise in type inference? ;-)
<jonathan> moritz: Yes, exactly.
<moritz> jonathan: don't know if you've seen it yesterday... t/spec/S02-polymorphic_types/subset-range.t has a failure that shouldn't be there
<jonathan> moritz: Thanks, will take a look.
<jonathan> Just got a broken Parrot build at the moment
<jonathan> Done realclean...fingers crossed....
<jonathan> Argh. Yes, my parrot is busted. :-(
<jonathan>         ..\..\parrot.exe ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir  --ou
<jonathan> tput=PGE\builtins_gen.pir PGE\builtins.pg
<jonathan> Null PMC access in invoke()
<kj> jonathan: mine was broken yesterday already, but i thought it was because I broke something in my sandbox; just did a clean check out, still broken; same error
<kj> parrot is fine, though; it's something with PGE i think
<moritz> smoke (after a realclean) is fine here
<jonathan> Yes, it's PGE issue.
<jonathan> kj: You found this on Win32?
<moritz> which means we really need PGE tests
<kj> jonathan: yes
<jonathan> Argh.
<jonathan> It's not even a GC problem; -G doesn't fix it.
<kj> i didn't report it yesterday ; didn't have time to check whether it was my local problem
<kj> it may have been a rename of some sub in the grammar compiler
<kj> I mean, there's some null access in invoke, so that would make sense
<jonathan> Yeah, but @other who ain't on Win32 can build fine.
<jonathan> oh
<kj> really??
* purl removes pants
<jonathan> I just got a clean checkout
<jonathan> And it worked.
<purl> Of course it worked
<kj> you on win32
<kj> ?
<jonathan> realclean didn't, but a clean checkout did...
<jonathan> Yeah
<kj> that's odd
<moritz> local changes?
<jonathan> svn diff was clean.
<kj> i'll do a realclean
<jonathan> OK, phew...I can hack on Rakudo today after all.
<kj> phew indeed :-)
* jonathan makes a cup of tea and digs in
<kj> jonathan: great slides by the way
<jonathan> kj: Thanks; they were fun to deliver.
% tetragon has left tetragon!~seneca@216.126.67.44
<kj> i can imagine :-)
<jonathan> moritz: t\spec\S02-polymorphic_types\subset-range....ok # I guess I need to un-fudge something in there?
<moritz> jonathan: yes, or just copy it to t/localtest.dat and add a # pure comment at the end
<moritz> or run the .t file directly
<moritz> it's not a parse failure
<jonathan> ok, will do once I've run the current bunch of tests
* jonathan wants to make sure he has a clean set of passes before he starts the day's hacking
<kj> jonathan: well i still have the same error
<kj> i'll report a bug
<jonathan> kj: Did you try getting a clean checkout?
<jonathan> moritz: Actually the fact that two of the tests pass is actually a bug too.
<jonathan> my Int $x = -1; # also gives type check error.
<moritz> testing++
<jonathan> Hmm. Actually there's three separate things that need fixing to make this test pass. :-)
<moritz> I thought it would be just a small range thing ;)
<kj> jonathan: clean checkout) well, my svn flag is green
<kj> well, just to make sure, will do a complete new checkout
<jonathan> If you do prefix:- on an Int, you'd expect to get an Int back, right?
<moritz> right
<jonathan> .sub 'prefix:-' :multi(_) .param num a $N0 = neg a .return ($N0)
<jonathan> .end
<jonathan> Is most probably wrong.
<moritz> yes
<moritz> because it makes a num out of everything
<moritz> and now you'd need generics ;)
<jonathan> Nah, MMD. ;-)
<moritz> so we need 1) an Int multi 2) a num multi 3) a 'any' multi that coerces to num?
<moritz> or are 2 and 3 the same?
<jonathan> I've left 2 and 3 the same for now.
<dalek> r28085 | jonathan++ | trunk:
<dalek> : [rakudo] prefix:+ and prefix:- should preserve integer type when done on an integer.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28085
<jonathan> OK, so that fixes the my Int $x = -42 bug
<jonathan> Now, lists need smart-match.
<jonathan> And then finally, I need to fix where :-)
<moritz> or to put it this way, I killed your productivity regarding new features
<jonathan> These things need fixing anyway.
<moritz> I know, I just forgot the smily
<moritz> t/spec/S29-num/int.rakudo                       58    5   8.62%  11-15
<moritz> not ok 13 - int(-0.5) is -0
<jonathan> Oh.
<jonathan> Hmm. list isn't in the smartmatch table.
<jonathan> Range is.
<moritz> > say int(-0.5)
<moritz> -0
<purl> 0
<moritz> wtf?
<jonathan> Ouch. :-S
<moritz> does is() try to do string comparison?
<jonathan> Not sure
<jonathan> yes
<jonathan> multi sub is($got, $expected, $desc) { my $test = $got eq $expected; proclaim($test, $desc);
<jonathan> }
<moritz> I'll now remove these ridcolous -0 from int.t
<moritz> and test is(-0, 0)
<jonathan> OK. Erm, my fix makes the range subset test fail even more.
<jonathan> Also, I've realized that since List isn't in the smartmatch table...we really need ranges proper to make that test pass.
<jonathan> Since we have '!flatten' and 'list' now, that might just be possible, though.
<moritz> > say int(-0.4).WHAT
<moritz> Num
<jonathan> Hmm. I've not got any int failure here.
<jonathan> Oh, hmm.
<jonathan> .sub 'int' .param num a .return 'truncate'(a)
<jonathan> .end
<jonathan> I'm not convinced that's right.
<jonathan> Especially given above it we have the comment
<jonathan>  our Int multi Num::truncate ( Num $x )
% mire has joined #parrot
<jonathan> moritz: Just smoking a fix for that, then will ci
% mire has left mire!~Frodo@80-168-222-85.adsl.verat.net
<moritz> jonathan: I just commited more int test, specifically int($something).WHAT eq 'Int'
<jonathan> great, I have that working here now
<kj> jonathan: FYI: (clean checkout) works now; no problems anymore
<dalek> r28086 | jonathan++ | trunk:
<dalek> : [rakudo] Make return value of truncate match that in the specification/comment above.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28086
<dalek> r28087 | jonathan++ | trunk:
<dalek> : [core] Implement get_iter vtable method on ResizableStringArray. Patch courtesy of chromatic++, test added by me.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28087
<moritz> ok, now tehre are two failures in subset-range.t because that int bug doesn't prevent assignment of negative numbers any more ;)
<jonathan> Yeah, I know!
<jonathan> Leave it for now, I'm working towards fixes for that test file.
<moritz> ok
<jonathan> Just need to try implementing a few things, to make it work.
% bacek has joined #parrot
<bacek> good localtime() everyone
<moritz> hey bacek ;)
<bacek> moritz, hi there
<bacek> moritz, howisgoing?
<moritz> bacek: fine, I'm producing more failing tests for jonathan to fix ;-)
<moritz> jonathan: abs() needs similar fixing, abs($_).WHAT should be identical to $_.WHAT
<moritz> those tests are fudged as parsefail, because rakudo doesn't know WHAT as a sub yet
<jonathan> parsefail?
<moritz> yes, but easy to work around by using the method form
<moritz> sent ticket anyway
<jonathan> OK, thanks.
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<moritz> pmichaud++ asked to turn all missing features into tickets
% Zaba has joined #parrot
<moritz> (at least those that are used in the test suite)
<moritz> > say abs(-2).WHAT
<moritz> 0
<moritz> > abs(-2).WHAT.say
<moritz> Int
<moritz> b0rked
<jonathan> What's...odd.
<jonathan> s/W/T
<dalek> allison@perl.org | A foundation for Parrot:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?a_foundation_for_parrot
<shorten> dalek's url is at http://xrl.us/bkxq5
<dalek> allison@perl.org | Annual Conflict of Interest Statement:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?annual_conflict_of_interest_statement
<shorten> dalek's url is at http://xrl.us/bmjh7
<dalek> allison@perl.org | Annual Conflict of Interest Statement:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?annual_conflict_of_interest_statement
<shorten> dalek's url is at http://xrl.us/bmjh7
<dalek> allison@perl.org | Bylaws:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?bylaws
<dalek> allison@perl.org | Bylaws:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?bylaws
% kj has left kj!~IceChat7@193.1.100.109
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<jonathan> moritz: The bad news: the test fails even harder at the moment. The good news: I've got .. constructing a range operator, which is lazy when used in iteration and eager elsewhere, with all other tests passing (sanity and spectest_regression).
<moritz> jonathan: "eager elsewhere", surely not in a smart match?
<jonathan> Correct, smart-match it won't be eager in, but that doesn't count because I've no implemented it yet. ;-)
<dalek> allison@perl.org | Bylaws:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?bylaws
<moritz> ;)
<dalek> r28088 | jonathan++ | trunk:
<dalek> : [rakudo] Make .. construct a Range object. Currently we don't have lazy lists implemented, so we eagerly flatten it into a list whenever it is used in list context (easily possible thanks to recent lists changes), however just using it as an iterator will give the lazy semantics. All tests that passed before this change in sanity and spectest_regression still pass.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28088
% Zaba has joined #parrot
<moritz> jonathan++ for also incorporating the root.in makefile changes (svn up||true)
% TiMBuS has left TiMBuS!~Hurf@123-243-167-27.static.tpgi.com.au
<dalek> r28089 | jonathan++ | trunk:
<dalek> : [rakudo] Implement smart-matching for Range objects.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28089
% jan has left jan!~chatzilla@nsabfw1.nsab.se
<ruoso> Hi... let me bring a question I just made in #perl6 that is probably better put here...
<ruoso> there's something I'm very curious about parrot/rakudo... how are you planning to interoperate different object representations? like ... my $o = Object.CREATE(:repr<Glib>);
<ruoso> for instance... in SMOP I defined a specific API for that...
<masak> jonathan: any further insights into the '$_' runtime error?
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
<jonathan> All operations on objects are performed using v-table method calls. I haven't got to working out exactly how to get this working yet, but I think it'll be along the lines of...
<jonathan> * Make a pmrole (at the Parrot/C level, I expect) that contains the object-y methods.
<jonathan> * Build an anonymous subclass of the representation type that does this role
<jonathan> I think :repr is in the bag of weirder things we'll worry about a little later. :-)
<ruoso> much like what XS does for p5
<jonathan> pmichaud may also have thought this through more than I have.
<jonathan> How are you approaching this in SMOP?
<jonathan> masak: Remind me which one, or is there a ticket?
<ruoso> SMOP defines much less things in low-level
<ruoso> and there's a REPR api
<ruoso> that even p6opaque will comply to
<masak> jonathan: there is. let me see if I find the tnr
<jonathan> OK.
<masak> #55184
<ruoso> the only static lookup made on SMOP is for the MESSAGE member of the SMOP__ResponderInterface
<ruoso> everything else is dynamic
<ruoso> (MESSAGE, REFERENCE and RELEASE actually... but that's details)
<ruoso> the v-table lookup happens *inside* the object
<ruoso> and might be implemented any way wanted
<ruoso> basically SMOP ends up being a series of SMOP_DISPATCH(interpreter, object, identifier, capture)
<ruoso> where every parameter in there is already an SMOP__Object
<jonathan> Sounds pretty neat.
<jonathan> I'll give it a closer look, especially the way you're handling different representations.
<ruoso> but anyway... If I could give you an advice, I would recommed taking a closer look at the repr issue earlier...
<ruoso> that was a turning point in SMOP
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
<ruoso> and I'm gald I got to it early
<ruoso> s/gald/glad/
<jonathan> Thanks, I'll have a look and think it through a bit more. I've been trying to get a bunch of potentially tricker stuff in earlier to make sure it can work, or at least making sure that we know how we will do various things in Rakudo even if we aren't doing them yet.
<ruoso> you probably would like to take a look at the slides for the SMOP talk I'll present saturday
<ruoso> http://people.debian.org/~ruoso/SMOP.pdf
<jonathan> And as I said, pmichaud may have already got it nicely worked out in his head, how we will do this. ;-)
<ruoso> :)
<jonathan> Thanks....happy they are in English! :-)
<ruoso> :)
<ruoso> I was expecting to present it in YAPC::EU also, but I'm not sure I'll be able to be there...
% iblechbot has left iblechbot!~iblechbot@105.16-dial.augustakom.net
<ruoso> jonathan, btw... http://www.perlfoundation.org/perl6/index.cgi?smop_oo_api contains the summary of the REPR support
<jonathan> Thanks, just reading through the slides now.
% bacek has joined #parrot
% TiMBuS has joined #parrot
<jonathan> moritz: t\spec\S02-polymorphic_types\subset-range....ok
<jonathan> Just running rest of tests, and if they're fine will check-in.
<jonathan> Then you can un-fudge. :-)
<moritz> jonathan: while you are at it, S29-list/grep.t seems to pass as well
<moritz> (at least the fudged form
<jonathan> I'm not seeing any unexpected pass warnings from that.
<dalek> r28090 | jonathan++ | trunk:
<dalek> : [rakudo] Make where without a block work. This gets us passing the subset-range test.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28090
<jonathan> OK, lunch time.
<purl> _FUD!
% Whiteknight has joined #parrot
% tetragon has joined #parrot
<pmichaud> good morning, all.
<masak> mornin'
<masak> (though Europe has mid-afternoon already)
<ruoso> pmichaud, hi pmichaud 
<ruoso> have you seen my comments on the join signature?
<ruoso> (#perl6 backlog)
<pmichaud> yes, but didn't quite understand them.
<ruoso> The method dispatching always falls back to sub-dispatching when it fails
<ruoso> and only really fails if the sub dispatching fails
<pmichaud> right, I understand that part.
<ruoso> so our multi sub join (Str $separator, Array @items) will be found on both
<ruoso> join ', ', @items
<pmichaud> sure, but that's not what S29 has
<moritz> S29 can be fixed ;)
<ruoso> and
<moritz> actually TimToady said earlier today (GMT day, that is) that we still have a rather liberal commit policy for S29
<pmichaud> moritz: yes, I'm the one that asked that.
<moritz> pmichaud: ok, I forgot ;)
<ruoso> our multi sub join (Str $oneitem, Str separator) would get the 'foo'.join(',')
<ruoso> actually 
<pmichaud> but I'm a bit concerned about that, because it means that we may be adding/changing behaviors without any real review
<ruoso> our multi sub join (Object $oneitem, Str separator) would get the whatever-not-array.join(',')
<pmichaud> ruoso: yes, that's what TimToady and I concluded
<dalek> r28091 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] updating to trunk r28090
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28091
<ruoso> pmichaud, ah... ok... I didn't see that part on the discussion... :)
<dalek> allison@perl.org | Bylaws:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?bylaws
<ruoso> pmichaud, about S29 review... I think S29 will have to evolve toguether with the implementations
<pmichaud> and the test suite
<purl> or awesome and very educational
<ruoso> and it will be easier if we see S29 as documentation rather than spec at this moment
<pmichaud> but that's kinda what concerns me -- someone could modify S29 just to make sure it matches what's in the test suite, without really asking if what is in the test suite is what ought to be correct in the first place
<ruoso> that's the point of "it's not a spec yet" :)
<dalek> allison@perl.org | Articles of Incorporation:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?articles_of_incorporation
<shorten> dalek's url is at http://xrl.us/bkyfj
<pmichaud> except the official test suite "is a spec"
<pmichaud> (agreed it's still evolving)
<pmichaud> anyway, we'll just keep evolving things as we go.
<ruoso> pmichaud, yes... and the S29 part will be very unstable in the next few ?months?
<ruoso> S29 part of the tests, I mean...
<ruoso> but still the tests doesn't have the signatures...
<ruoso> they only list some use cases
<ruoso> and the signatures must be able to match them
<jonathan> morning, pmichaud  # finished eating lunch
% tetragon has left tetragon!~seneca@216.126.67.44
<dalek> r28092 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Change some :multi(Int) to :multi(Integer), just in case any Parrot
<dalek> :   types leak into our code.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28092
<pmichaud> r28060 has:
<pmichaud> +    # Propagate exception to caller
<pmichaud> +    $P0 = getinterp
<pmichaud> +    $P0 = $P0['lexpad';1]
<pmichaud> +    $P0['$!'] = exception
<pmichaud> ... is that right?
<jonathan> I don't think so.
<pmichaud> well, that's what we're doing for Regex ACCEPTS, too, so I guess it is right.
<pmichaud> when looking at it I was thinking that would give OUTER, not CALLER
<jonathan> Ah, OK.
<jonathan> What I menat by "not right" is I think $! is supposed to collect exceptions on a fail.
<pmichaud> oh, that is in a fail.
<jonathan> I'm not sure if this example here is meant to fail or die.
<pmichaud> well, we really need a 'fail' function.  :-)
<jonathan> Because the contextual variable $! contains all exceptions collected in the current lexical scope, saying die $! will throw all exceptions, whether they were handled or not. 
<jonathan> So it seems to collect 'em up. :-)
<jonathan> Yes, we need a fail function. ;-)
<jonathan> purl, nopaste
<purl> nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://paste.husk.org/ or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or don't bother me while I'm eating or App::Nopaste or tools/dev/nopaste.pl
<nopaste> "jonathan" at 85.216.151.226 pasted "proposed patch" (46 lines) at http://nopaste.snit.ch/13176
<jonathan> pmichaud: That nopaste should switch us over to using mutables, and it passes all of spectest and spectest_regression.
<jonathan> Does it look sane?
<pmichaud> looks great.  commit.
% tetragon has joined #parrot
<jonathan> OK, done.
<dalek> r28093 | jonathan++ | trunk:
<dalek> : [rakudo] Switch us over to using Mutable for scalars. Passes all sanity and spec tests.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28093
<jonathan> pmichaud: I think that maybe the is ro/rw/copy patch I did for parameters maybe can go in now and not break as much. But I know you were pondering doing some refactoring relating to parameters too.
<pmichaud> does it still use !TYPECHECKPARAM ?
<jonathan> Yeah, I hadn't eliminated that.
<jonathan> I'm not sure if we can for now.
<pmichaud> I was thinking that !DOTYPECHECK ought to be sufficient.
<jonathan> Yes, I think so too.
<jonathan> Plus I added a sub that generates the type constraint object.
<jonathan> It'd be good to refactor params to call that instead.
<pmichaud> right.
<jonathan> That was my intention when I factored it out before.
<jonathan> Just never got to it yet.
<pmichaud> if the change to parameters doesn't break anything, feel free to (re-)commit it.  But I may end up rearranging a lot of it soon.  :-)
% iblechbot has joined #parrot
<pmichaud> or you can just send it as a patch and I'll add/revise it as part of my refactoring. 
<jonathan> OK, I can put it in...and tests.
<jonathan> Then it's there for you to refactor as you wish.
<dalek> r28094 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Fix hash() so that it again correctly reports "Odd number of
<dalek> :   elements found where hash expected."
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28094
% gryphon has joined #parrot
% tetragon has left tetragon!~seneca@69-196-141-26.dsl.teksavvy.com
<jonathan> pmichaud: Well, geck. I just put the parameter stuff back in. And get one failure. Which is due to the Parrot GC bug.
<jonathan> One in spectest_regression, that is. Not in sanity.
<pmichaud> I've been letting things commit if they work with -G
<jonathan> OK
<pmichaud> because usually it clears up on its own
<jonathan> I'll commit then.
<pmichaud> and if it doesn't, then we'll have stronger incentive to finally figure out what is breaking :-)
<jonathan> But I know full well this won't clear up "on its own".
<jonathan> Since I found a real GC bug (lack of marking something reachable).
<pmichaud> oh, you mean the sub bug?
<pmichaud> hrm.
<jonathan> Yes.
<jonathan> It only causes one failure in a (larger, thus why we see it) test.
<pmichaud> I leave it to your discretion, then.  :-)
<jonathan> OK, I'll put this in.
<pmichaud> I'm willing to live with the spectest_regression failure.
<jonathan> Then I'll go look at the segfault.
<jonathan> I can put in a workaround quite easily in find_name_op, but it's a *total* hack.
<pmichaud> I don't mind if spectest_regression has failures for short intervals ( O(days) )  if we know why they exist
<jonathan> I'll have another glance at the GC bug now.
<jonathan> And if no better fix comes to mind, I'll file a ticket with the details I have.
<jonathan> At least it's a "we have a GC bug exactly here" rather than "these thousands of lines exhibit a GC bug". :-)
<dalek> r28095 | jonathan++ | trunk:
<dalek> : [rakudo] Get is ro, is rw and is copy, with ro being the default, working on parameters to subs. This time, we get just one failure in spectest_regression (on Win32), which is a result of a Parrot GC bug.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28095
% jan has joined #parrot
<jonathan> pmichaud: Up for some testing?
<pmichaud> sure.
<jonathan> I now have a patch that fixes the GC bug, giving a clean pass of Rakudo sanity and spectest_regression
<jonathan> And also doesn't cause any new failures in Parrot tests.
<pmichaud> excellent.  send patch.
<pmichaud> I'll test it immediately.
<pmichaud> (unless Paula needs me for something quickly -- getting ready to head off to chemo)
<nopaste> "jonathan" at 85.216.151.226 pasted "GC fix" (13 lines) at http://nopaste.snit.ch/13177
<jonathan> there it is
<jonathan> I would like test from you too, since I know the issues my last attempt caused were quite different than I had been seeing.
<pmichaud> right.
<pmichaud> I'll do a full test.
<jonathan> Great, thanks.
<pmichaud> (parrot and rakudo)
<pmichaud> and rebuild, too.
<nopaste> "jonathan" at 85.216.151.226 pasted "What works now" (11 lines) at http://nopaste.snit.ch/13178
<pmichaud> oh, btw, it's  "is readonly", not "is ro"
<jonathan> Oh?
<jonathan> OK :-)
<pmichaud> I couldn't find any instances of \bro\b in S04
<pmichaud> sorry, in the Synopses
<jonathan> OK, not sure where I got that from.
<cognominal> I also find readonly too verbose.
<pmichaud> fortunately... it's the default.  :-)
<cognominal> that's good
<jonathan> I guess having is rw made is ro feel kinda natural. :-)
<dalek> allison@perl.org | Articles of Incorporation:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?articles_of_incorporation
<shorten> dalek's url is at http://xrl.us/bkyfj
% jhorwitz has joined #parrot
<dalek> allison@perl.org | Articles of Incorporation:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?articles_of_incorporation
<shorten> dalek's url is at http://xrl.us/bkyfj
<dalek> r28096 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Remove trailing spaces in Range.pir .
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28096
<dalek> allison@perl.org | Articles of Incorporation:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?articles_of_incorporation
<shorten> dalek's url is at http://xrl.us/bkyfj
<pmichaud> I got an odd failure in S29-str/capitalize.t --- but re-running it seems to cause it to pass.  Running once more for a check.
<dalek> r28097 | jonathan++ | trunk:
<dalek> : [rakudo] ro trait is actually called readonly.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28097
<pmichaud> jonathan: all tests pass here.  +1 on the patch.
<pmichaud> (the GC fix)
<jonathan> OK, great.
<dalek> r28098 | jonathan++ | trunk:
<dalek> : [core] Fix a GC bug where subs did not mark their context, which could cause LexPad PMCs referred to by the context to get collected. This fix does not have the issues that my previous attempt to fix the bug created.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28098
<jonathan> pmichaud: On VAR and .VAR, I think that since we keep properties in a hash right now, we're going to have to do quite some faking to make VAR($foo).readonly to work.
<pmichaud> really?
* purl removes pants
<jonathan> I think so, because find_method needs to return something invokabe
<pmichaud> seems to me that a MutableVAR would be able to define a .readonly method.
<jonathan> Oh, hmm.
<jonathan> OK, that special-cases 'em all.
<jonathan> OK, we can do that for now.
<pmichaud> or even a   .property('readonly')
<jonathan> The Spec suggests VAR($foo).readonly
<pmichaud> or we can define a .readonly method on Perl6Scalar that returns its 'readonly' property
<pmichaud> then VAR($foo).readonly dtrt
<jonathan> Yeah, that's a point.
<jonathan> OK, that'll be cleanest for the future.
% kj has joined #parrot
% Andy has joined #parrot
<pmichaud> moritz: for RT#55338, what file tests WHAT() ?
<moritz> pmichaud: S29-num/abs.t
<pmichaud> perhaps mention it in the ticket?  ;-)
<pmichaud> (thanks)
<moritz> ok, will do next time
<pmichaud> and why does abs.t use WHAT?!
<moritz> to ensure that the type doesn't change
<diakopter> pmichaud: don't shout
<moritz> and it's good that it does, because we had some cases where int() returned a Num ;)
<jonathan> We can't help it! S12 made us do it!
<diakopter> :)
<pmichaud> shouldn't we be using ~~ instead?
<moritz> how?
<pmichaud> $abs($_) ~~ $_.WHAT    perhaps?
<moritz> currently the test is WHAT(abs($_)) eq WHAT($_)
<pmichaud> sorry
<pmichaud> abs($_) ~~ $_.WHAT
<moritz> ok, that might be more permissive
<pmichaud> are we guaranteed that abs($_)  shouldn't change type?
<pmichaud> or just in select cases?
<moritz> pmichaud: they are tests with Num and Int
<moritz> pmichaud: and I think in those it shouldn't change
<pmichaud> okay.
<pmichaud> works for me then.
<moritz> actually some of these tests failed quite horribly
<moritz> abs(-2).WHAT.say said "Int"
<moritz> and way abs(-2).WHAT said "-2"
<moritz> > abs(-2).WHAT.say
<moritz> Int
<moritz> > say abs(-2).WHAT
<moritz> 0
<particle> jonathan: i have some code review items of your ro, rw, copy patch: http://www.parrotvm.org/svn/parrot/revision?rev=28095
<particle> your error messages should include the trait name: $/.panic("Cannot apply traits to parameters yet.");
<particle> it seems 'is rw is rw' won't error (should it, or just warn, which we haven't implemented yet)
<jonathan> 'is rw is rw' does error here for me
<particle> i think the last 'else {' in the bottom patch chunk is too permissive, should check "elsif $cont_trait eq 'copy'" specifically
<particle> ah, yes, it will error.
<particle> should it?
<jonathan> And yes, including trait name would be a good thing, though the original message isn't so far off - we're not really applying traits proper yet.
<jonathan> I'm not sure, but it'd seem odd specifying multiple.
<jonathan> I was really tyring to catch is readonly is copy and other such meaningless fun.
<particle> syntactically, it's allowed
<particle> semantically, it has no meaning
<jonathan> Oh, I know, but that doesn't mean the compiler should allow it.
<particle> but, since it looks funny, it sends up a red flag
<jonathan> my Int $x = "foo" is syntactically allowed. :-)
<particle> yes, but that's semantically wrong
<jonathan> On the last else, $cont_trait is something that we directly set ourselves, not the user.
<particle> yes, correct
<particle> but it doesn't match the cases above
<jonathan> So from the block above we know it can't have any other value.
<particle> if the block above is changed, then the block below needs changing
<particle> but what if a rakudo committer changes the above without the below?
<particle> those blocks are tightly coupled
<particle> so i'm arguing that the if/elsif cases should match, to make that more clear
<jonathan> Can be done.
* pmichaud notes as an aside that he's still planning to refactor a lot of this.
<particle> i can do the changes
<particle> but i don't want to without discussion
<jonathan> particle: I have no objections to the changes you're proposing.
<particle> okie
<jonathan> Generally, I don't mind clean-ups to anything I commit to make it more maintainable/readable/give better error messages.
<particle> i'm reviewing your range commit now
<diakopter> anyone who's going to yapc::na - msg me if you have an extra bed/couch/floor to offer - I'll pay for half..all of your housing costs...  I need a place to crash.
<particle> i hate that wicked gc bugs are usually solved by one line of code... after all that digging
<particle> diakopter: i think there's a wiki page for such requests
<diakopter> particle: it's pretty bare
<particle> ah
<moritz> from the discussions here I get the impression that the GC is a bit crappy
<moritz> but why? is it neglected? or not well tested?
<particle> moritz: it's not crappy
<jonathan> particle: That one took about an hour and a half, in the C debugger, at the airport on Sunday to find.
<particle> well, the performance is
<particle> but we're replacing the current gc with a better one
<particle> we = Whiteknight++
<particle> moritz: the hard part is programming for gc
<moritz> particle: ok, not crappy, but it still accounts for at least half the parrot bugs I'm confronted with
<particle> that's the trouble with C
<particle> if we could program in perl, we wouldn't have to worry about gc :)
<moritz> so are the "GC bugs" actually spread out over all the code base?
<particle> unlike perl 5 source (refcounting), parrot's gc bugs are usually in one of a few places in any .pmc file
<jonathan> The problems generally are things that are still somehow reachable, but we aren't telling the garbage collector that.
<particle> perhaps the 'mark' vtable function, or 'init'
<jonathan> That's the case in the one I just fixed.
<moritz> ok, thanks for the insight
<jonathan> And to go with what particle just mentioned, the thing I just fixed was inside mark method of the Sub PMC.
<particle> moritz: i thought of a new todo for rakudo tests...
* jonathan finally finds a box with bison and flex versions that allow him to add parsing of :instanceof(blah) to IMCC.
<particle> make sure that files marked # pure don't have any #?rakudo directives in them
<moritz> particle: sounds like a one-liner ;)
<particle> yay for jonathan!
<moritz> well, perhaps a bit more than one line
<particle> yep, pretty easy
<particle> would make a nice util to add to the test suite maintainer toolkit
<moritz> any suggestions for a name?
<moritz> fudge-purity-warnings?
<particle> purity_check?
<particle> sure, i like fudge_purity_inspector.pl
<moritz> how do I add an inital $Id: tag to a file?
<Infinoid> just put $Id$, it will fill out the rest
<moritz> Infinoid: thanks
<dalek> r28099 | jonathan++ | trunk:
<dalek> : [core] Add parsing (but not semantics) for :instanceof('Type') adverb on .subs.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28099
<jonathan> feather++ # had correct versions of flex and bison to let me do this patch, at last
<particle> moritz: need to set some svn properties, too, probably
<particle> do we have a make target for that in perl6 now?
<moritz> in parrot we have 'codetest'
<particle> run that after your svn add
<Infinoid> if it passes t/distro/file_metadata.t, $Id$ should work
<moritz> do we have a script for adding files and setting svn props?
<particle> no, unlike pugs
<moritz> like pugs' util/svn-add-textfiles
<particle> shouldn't be hard to steal that one, though
<particle> stick it in parrot's tools/dev/
<dalek> r28100 | infinoid++ | pdd13pbc:
<dalek> : [pdd13] Merge changes from trunk (-r27563:28099) into pdd13pbc branch.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28100
<pmichaud> (make codetest)  I'm thinking of moving the existing 'make test' target to 'make coretest', and then have 'make test' run both coretest and codetest
<pmichaud> then we can have 'make fulltest' that runs coretest, spectest_regression, and codetest
% ruoso has left ruoso!~ruoso@195.23.92.2
<particle> pmichaud++
<particle> i think the default test target should have no body, just dependencies
<particle> (unless that body is @echo whatever)
<pmichaud> that's what I'm thinking also.
% ruoso has joined #parrot
<moritz> is MANIFEST generated somehow?
<pmichaud> perl tools/dev/mk_manifest_and_skip.pl
<Infinoid> tools/dev/mk_manifest_and_skip.pl
<Infinoid> heh :)
<moritz> ok, let's ask the other way round: is there a "must-read for new commiters" somewhere?
<moritz> (not that I'm a commiter yet...)
% kj has left kj!~IceChat7@193.1.100.109
<dalek> r28101 | jonathan++ | trunk:
<dalek> : [rakudo] Stub in MutableVAR PMC.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28101
<NotFound> The first law of the commitotic: "A commiter may not injure a human being or, through inaction, allow a human being to come to harm."
<moritz> "die Würde des Menschen ist unantastbar" - we have that in our constitution already ;)
<Infinoid> there's docs/project/committer_guide.pod
<NotFound> "... to commit and serve"
<jonathan> Thou shalt never commit anything that breaks t/codingstd/trailing_whitespace.t. ;-)
<particle> sinner!
* jonathan looks forward to having codetest run as part of make test for Rakudo. 
<NotFound> Aye.
<jonathan> I'm still mystified, how I manage to end up with so many of these.
<pmichaud> jonathan: any ideas about making method calls fall back to sub calls?
% davidfetter has joined #parrot
<jonathan> pmichaud: Example of what you're trying to do?
<pmichaud> $foo.abs   should call abs($foo)   if   no abs method is defined.
<moritz> Patch sent
<pmichaud> S12:207
<jonathan> pmichaud: Is that general Perl 6 sem....right.
<jonathan> We need to override find_method.
<pmichaud> ouch
<pmichaud> more generally I think we need our own dispatcher
<jonathan> We need to anyway.
<jonathan> Because we need to get SubMethods in parent classes not to be dispatched to.
<jonathan> And other such fun.
<pmichaud> and junctions
<purl> junctions are what you call Quantum::Superpositions in Perl 6. or fun
<jonathan> That's the MMD dispatcher, but yes.
<pmichaud> ...MMD dispatcher can do the autothreading?
<jonathan> I will deal with that in July when I do the MMD work.
<jonathan> Yes, that's my plan.
<pmichaud> so, wouldn't "fallback to sub" just be part of that, also?
<jonathan> No, because find_method will never have returned you a multi to invoke.
<pmichaud> the mmd dispatcher for junctions won't work with methods?
<pmichaud> I'm confused.
<jonathan> Let me try and explain better.
<jonathan> For sub calls => either have a Sub in the namespace, which we just invoke directly, or it's a MultiSub, in which case on invoke it runs the MMD dispatcher.
% peepsalot has joined #parrot
<jonathan> For methods => call find_method. If find_method doesn't find anything, it instead does the "fallback to sub" logic. Otherwise, it returns what it found, which may or may not be a multisub.
<jonathan> Then we proceed the same as if we'd looked a sub up
<pmichaud> so, what handles autothreading on Sub?
<pmichaud> (as opposed to MultiSub)
<jonathan> Oh, urgh.
<moritz> isn't it handled *after* finding the correct sub?
<jonathan> Yes, it is. And type check failure.
<jonathan> The type check failure is caught (like no applicable methods is caught - but we probably won't bother throwing and catching anything here).
<pmichaud> moritz: isn't <what?> handled after the finding the correct sub?
<moritz> pmichaud: autothreading
<pmichaud> foo(1 | 'b')    might invoke two different subs.
<jonathan> And then we examine the signature, and if the failure was due to a parameter not taking a junction and we passed one, we change it to a multi, with the newly generated auto-threader inside it.
<jonathan> Aye.
<jonathan> The junction distributor just re-dispatches back to the multi, which will dispatch the correct way.
<pmichaud> I have a feeling that's not going to really work.
<jonathan> Which bit?
<purl> Which bit is probably the time part? Anyone?
<pmichaud> well, for one, I don't think that we should require every sub to check its arguments for Junctions
<pmichaud> that should really occur prior to dispatch.
<jonathan> Subs are responsible for checking the types of things passed as parameters, I would have thought?
<pmichaud> ultimately I think every sub needs to carry a signature property, and then the dispatcher selects a sub based on matching signature
<pmichaud> and that's the part that does the type checking of arguments
<jonathan> OK, but that's just moving the check done in each sub into one common place (e.g. done inside invoke)
<jonathan> Which is neater, I agree.
<jonathan> I'd been pondering that we probably need to have signature objects in place to do the MMD dispatcher properly.
<pmichaud> well, we know we have to have a Signature type
<moritz> re "every sub needs to carry a signature property", yes, you can even access it with <c>.sig</c>
<pmichaud> moritz: I think it's  '.signature', but yes.
<jonathan> Sure, it's just a little way down on the roadmap. But I suspect we should hoist it up and doing it before MMD.
<jonathan> The :instanceof stuff I'm working on here and there, is one part of that.
<pmichaud> ultimately my guess is that we'll end up with our own custom MultiSub type
<pmichaud> and override its 'invoke'
<jonathan> That was my plan.
<pmichaud> and then all of our Sub objects are that type
<jonathan> Something like that.
<pmichaud> i.e., we don't have any Parrot 'Sub' objects, they're all 'Perl6Code'  or whatever
<moritz> jonathan: actually both .sig and .signature is used in the synopsis :(
<jonathan> moritz: Aliasing! :-)
<pmichaud> heh, you're right. 
<jonathan> pmichaud: Right. That's what I'm working towards.
<pmichaud> I think S03 is incorrect.
<pmichaud> then I think that instead of trying to fix find_method, we do something to generate method calls instead of $x.'foo'
<pmichaud> because i don't hold out a lot of hope for getting find_method to do what we want.
<pmichaud> I suppose it could work if we assume that everything isa Perl6Object
<jonathan> pmichaud: I think we should use find_method, but we need to subclass the Object PMC.
<jonathan> And implement our own semantics in there.
<pmichaud> that would seem to eliminate P6object
<jonathan> I suspect just writing our own dispatcher and ignoring find_method is going to hurt language inter-op.
<jonathan> Does P6Object subclass Object?
<jonathan> Or is it just an instance of it?
<jonathan> I'm guessing the second.
<pmichaud> I'm not saying ignore find_method, I'm saying that we don't use it as our primary form of method dispatch
<pmichaud> nothing subclasses Object
<jonathan> I figured so.
<jonathan> I think the original intention was to make class and object subclassable.
<jonathan> So you can put your own dispatch etc semantics into them.
<pmichaud> well, if we want to do that, and to put PGE and PCT into that category, I guess that's okay.
<pmichaud> *however*
<pmichaud> this is a case where I think that it's the language that is dictating the semantics, not the object.
<pmichaud> i.e.,   if someone gets a hold of a Perl6Array in another HLL and invokes a method on it, perhaps we shouldn't have the "fall back to sub" semantic in that other HLL
<pmichaud> similarly, if I get a Python object into my Perl6 program, I should expect "fall back to sub" to work.
<jonathan> Hmm. Good point.
<purl> Thanks, jonathan, I'm glad you agree with me.
<pmichaud> so, perhaps a couple of dynops
<jonathan> Implenting our own custom dispatcher?
<pmichaud> yes.
<jonathan> OK, let's try this way then, and see how it goes.
<pmichaud> oh, hrm.
<pmichaud> here's another evil thought.  :-)
<jonathan> But there's still things like Signature to get in before we can do it really well. ;-)
<jonathan> :-)
<jonathan> Uh-oh. :-)
<pmichaud> we could implement a "pseudoclass" that always occurs at the end of the parent list
<pmichaud> and that pseudoclass reports all subs in the current lexical scope as being methods :-)
<pmichaud> and then find_method would work.  :-P
<pmichaud> sounds too evil, though.
<jonathan> Ewww!
<jonathan> You're sick. :-)
<jonathan> That would have...interesting...consequences for .*
<pmichaud> as an interim measure we could see about overriding the 'call' and 'callmethod' pasttypes  in PAST::Op
<pmichaud> to call a custom dispatcher instead of the default Parrot one.
<jonathan> I guess just callmethod for now, would get us the semantics you're after of sub fallback?
<pmichaud> yes, I think so.
<pmichaud> and would be a reasonable proof of concept.
<pmichaud> is there a way (in PIR) to determine if a multisub will dispatch?
<particle> so, $foo.?abs will call abs($foo) ?
<jonathan> particle: I'd not hope.
<pmichaud> i.e., if a given set of arguments will match a given MultiSub PMC
<jonathan> pmichaud: Only to invoke it.
<pmichaud> hrm.
<pmichaud> I might want to add a method to MultiSub then.
<jonathan> Yeah, we need to be able to do things like MySub<Int, Str> or similar to get at particular variants too.
<jonathan> I may be a little off on the syntax.
<jonathan> I asked for this in the MMD PDD, but I don't think anything made it in there.
<pmichaud> Ultimately I think we're going to be using :load :init to set properties on our subs
<pmichaud> I don't think we'll be able to get every property we might want/need into PIR syntax.
<pmichaud> but having :instanceof  is something we definitely need.
<pmichaud> why wouldn't  $foo.?abs  call abs($foo)  ?
<jonathan> :load :init - wouldn't :emit_pbc be better, so once we serialize the bytecode and sub PMCs we don't have to do it every load?
<jonathan> I thought .? just said "call a method if we have it"
<jonathan> I'm not sure, just feels kinda surprising it'd go for a sub instead.
<jonathan> I guess if . does though...
<pmichaud> oh, I'm not familiar with :emit_pbc
% TiMBuS has left TiMBuS!~Hurf@123-243-167-27.static.tpgi.com.au
<jonathan> I *think* it runs it right after it compiled it.
<jonathan> Or is it :immediate or something...I'm sure not long back I saw such a mechanism, for running during compile time.
<pmichaud> :immediate means that we do it during the compile, yes.
<jonathan> ok
<jonathan> I thought there was emit_pbc one as well, I may be wrong.
<pmichaud> (phone)
<pmichaud> but thinks that happen as part of :immediate don't show up in any .pbc output
<pmichaud> s/thinks/things
<pmichaud> that's why we have :load :init
<pmichaud> (:immediate was commonly used for compiler side-effects, such as loading a .so module prior to trying to obtain a type id)
<pmichaud> if/when we can do bytecode serialization then we'll probably be in better shape.
<pmichaud> that sounds like something PCT should offer.
<pmichaud> or the PIR compiler itself.
<pmichaud> I suppose if we can serialize the Eval PMC that comes back from compiling PIR then that might be good enough.
<jonathan> Yeah, I guess so.
<jonathan> This might be in the realm of, things that should work but maybe don't.
<pmichaud> and then we could do properties as :immediate
<jonathan> If :load :init works for now though, I guess easier to use that while we work out what we need.
<pmichaud> right, that's been the approach I've been taking.
<pmichaud> it's mostly generated code, so easy to change when Parrot gets improvements.
<jonathan> Sure.
<pmichaud> afk, lunch, kids
<diakopter> kids for lunch :(
% masak has left masak!~user@130.238.45.242
% barney has joined #parrot
<cotto_home> barney, ping
<barney> hi cotto
<cotto_home> are you familiar with clean-room implementation?
<dalek> r28102 | jonathan++ | trunk:
<dalek> : [rakudo] Add readonly method to Mutable PMC.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28102
<cotto_home> (with the concept)
<barney> what's that ? Implementation according to spec ?
<cotto_home> my understanding is that it's a way of copying the idea behind code without copy the code
<cotto_home> one guy looks at the code and writes a spec
<dalek> r28103 | jonathan++ | trunk:
<dalek> : [rakudo] Fill out MutableVAR a bit more, and add a few (passing) tests for it.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28103
<cotto_home> another looks at the spec and writes another implementation of the code
<particle> sounds like "chinese wall"
<cotto_home> I was thinking that this method might be the easiest way to use an existing PHP grammar in Plumhead without dealing with relicensing issues
<cotto_home> particle, yes
<barney> I remember that being mentioned WRT to Linux drivers
<cotto_home> If I used the Zend PHP5 implementation to write a spec for the grammar, would you be willing to implement the PGE grammar? (or the other way around)
<barney> Have you investigated the PHC and Phalanger grammars?
<cotto_home> AFAICT they're both based on Zend, which probably means that they couldn't be relicensed
<jonathan> afk, dinner and language study, back later
% Theory has joined #parrot
<barney> cotto: I'm willing to do the PGE and ANTLR implementation without looking at Zend code. In fact, that's what I did so far.
<cotto_home> yes, but working from a spec would help prevent surprises
<barney> Of course using a spec from you.
<cotto_home> yes
<dalek> r28104 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] updates to comments and datastructures
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28104
<cotto_home> OK.  I'll start a spec on the wiki and send you a link once it nears usability.
<barney> What is the license of the Zend parser? I think they distinguish between a basic PHP and some kind of accelerator.
<cotto_home> Zend 2.0
<cotto_home> You may be thinking of Zend's opcode cache or optimizer
<barney> cotto: I plan on a some free time in July and August. Being busy with a project in Darmstadt till end of June
<cotto_home> such is life
<cotto_home> tuits are usually in short supply
<barney> Isn't that GPL-compatible? http://shiflett.org/blog/2006/apr/zend-framework-license
<cotto_home> I'll have to check if that's the same as the Zend 2.0 license
<cotto_home> bbs (work)
* barney hitting the road to Munich
% barney has left barney!~bernhard@dslb-084-058-128-075.pools.arcor-ip.net
<japhb> Yikes.  I think this morning's scrollback may be too long to read without my brain melting ....
<moritz> japhb: just skip the whol karma battle ;)
<dalek> r28105 | particle++ | trunk:
<dalek> : #55346: [PATCH] tool for checking if '# pure' files still contain fudging
<dalek> : ~ applied with minor formatting corrections and enhancements
<dalek> : Courtesy of Moritz Lenz (moritz++)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28105
<particle> oh, our test tools are looking much nicer these days!
<moritz> though I'm wondering if we should actually remove some tests from spectest_regression
<moritz> some of them have 100% skip, which only increases test time
<moritz> but doesn't add any value
<particle> moritz: they shouldn't be in _regression, probably, but i'd like them in spectest
<moritz> particle: "spectest" runs *everything*
<particle> ssorry, here's what i'm getting at:
<particle> is it worthwhile to decorate all spec tests with #?rakudo markers?
<moritz> why should it?
<particle> ...or only the tests we expect to be working soon
<moritz> only those that are partly implemented
<moritz> there's no use to fudge concurrency test when no concurrency is implemented
<particle> does "use v6; plan 5;" count as partly implemented? :)
<moritz> ;) no
% NotFound has left NotFound!~julian@50.Red-213-96-228.staticIP.rima-tde.net
<particle> ok, then for those test files tha have all skipped, let's rip out #?rakudo and from _regression
<nopaste> "moritz" at 89.13.199.151 pasted "patch for particle: less tests" (31 lines) at http://nopaste.snit.ch/13181
% NotFound has joined #parrot
<particle> we don't do pi yet?
<particle> seems like it could be a quick add
<particle> sprintf, too, if we use parrot's directly
<moritz> didn't look at it, that's just the list of all skip-all tests
<moritz> does perl 6 have the same format as parrot?
<particle> i don't know, but i bet it's a close-enough approximation for now
<particle> parrot's is modelled after perl 5's
<moritz> oh it seems that S29-num/exp.t is overly fudged
<moritz> exp(5) fails from too low precision :(
<particle> ah. that's fixable someday
<pmichaud> I wonder what Parrot's exp(5) is generating.
<moritz> > say exp(5) - 148.4131591025766
<moritz> 0.000159103
<moritz> perl -wle 'print exp(5) - 148.4131591025766'
<moritz> 0
<moritz> ticket?
<purl> ticket is, like, saying to select a compiler based on the extension of the script file
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
<pmichaud> grrrr
<pmichaud> I think someone changed the float code.
% rdice has joined #parrot
<pmichaud> okay, better:
<pmichaud> > say exp(5) - 148.4131591025766
<pmichaud> 0
<pmichaud> let's see what else breaks :-)
<moritz> btw I get a failure in t/spec/S02-polymorphic_types/subset-range.t (last test)
<pmichaud> odd, I don't.
<moritz> and eval_dies_ok doesn't prevent it from dying :(
<moritz> uhm, who fixes svn for me?
<moritz> I added tools/fudge_purity_inspector.pl locally
<moritz> then particle++ commited it
<dalek> r28106 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Avoid losing precision in floating point constants.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28106
<moritz> at svn up: svn: Failed to add file 'languages/perl6/tools/fudge_purity_inspector.pl': object of the same name already exists
<moritz> so I deleted it
<moritz> now it says svn: Failed to add file 'languages/perl6/tools/fudge_purity_inspector.pl': object of the same name is already scheduled for addition
<moritz> is svn that broken? or am I?
% ruoso has left ruoso!~ruoso@195.23.92.2
<particle> moritz: did you svn del?
<particle> i bet you did svn add before i committed
<moritz> particle: I did
<moritz> but since you commited an identical file, what's the problem?
<particle> it's not identical
<particle> i modified the file
<moritz> well, then it could still report a merge conflict
<moritz> anyway, svn del --force fixed it, thanks particle++
<pmichaud> how does exp.t perform after r28106 ?
<nopaste> "moritz" at 89.13.199.151 pasted "failure in t/spec/S02-polymorphic_types/subset-range.t" (15 lines) at http://nopaste.snit.ch/13182
<pmichaud> the problem wasn't exp(), it was that rakudo/parrot was encoding 148.413591025766 as 148.143
<moritz> pmichaud: I'll check when my parrot build is finished
% cotto_work has left cotto_work!~cotto@tide535.microsoft.com
<moritz> re paste, a clean rebuild of parrot and perl6 fixed that
<pmichaud> the subset-range stuff?
<moritz> yes
<moritz> and the exp() stuff is also fixed
<pmichaud> okay.  I suspect jonathan had to update parrot in order to get it to work properly.
<pmichaud> yay for fixes
<moritz> ok, that resolves [perl #55350]
% Zaba_ has joined #parrot
<pmichaud> (closed ticket, thanks)
<jonathan> pmichaud: Updated Parrot needed due to GC fix.
<pmichaud> oh, right.
<jonathan> That's only core change I did today.
% tewk has joined #parrot
<particle> hey, tewk! how's your tan?
<jonathan> Not sure why you'd need to rebuild to get the subset range test to pass.
<jonathan> pmichaud: $x.VAR and VAR($x), according to S12, are macros, not just methods/sub calls.
<particle> had to regen makefile after that range commit
<tewk> Not bad.
<jonathan> Meaning we should do 'em in the grammar.
<jonathan> Any preferences where we stick them for now, until we have macros?
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<jonathan> I think .VAR can just be a special case of dotty for now.
<pmichaud> jonathan: yes, that's fine with me.  I wasn't thinking of them as method calls.
<pmichaud> (it's okay with me if they are done with method calls, but whatever implementation gets us the right semantics.)
<particle> pmichaud: how are you counting passing spectests?
<particle> i get:
<jonathan> They're not meant to be method calls, and if they were we'd get the wrong semantics. :-)
<particle> Files=58, Tests=1110, 285 wallclock secs
<pmichaud> particle:  I subtract out the skipped tests.
<particle> i don't have a list of skipped tests
<particle> ah, you must be using a different version of Test::Harness
<jonathan> OK, going to study for a while, and then back to hack on Rakudo more afterwards.
<pmichaud> I get:
<pmichaud> All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 42 subtests skipped.
<pmichaud> Files=1, Tests=44,  4 wallclock secs ( 4.01 cusr +  0.05 csys =  4.06 CPU)
<pmichaud> (I just did 'make localtest')
<pmichaud> so, if that was the results for spectest_regression, I'd report 44 - 42 == 2
% cotto-work has joined #parrot
<cotto-work> you'd think that Microsoft would know how to prevent brownouts
<cotto-work> you'd be wrong
<particle> cotto-work: not working on a laptop there?
<cotto-work> no
<particle> laptop++
<cotto-work> agreed
<cotto-work> reliable power++
<cotto-work> (reliable power)++
* pmichaud wonders about kid power.
<cotto-work> now I get to go to lunch, wondering if my machines will be up when I get back
<PerlJam> Install power-generating playgrounds at schools around the country.   Kids at play == power for the school (or local community)
<particle> PerlJam: somebody designed something like that for africa
<particle> one of those things that spins, with bars on top that you can push or hold on to
<PerlJam> (that somebody)++
<particle> it powers a well pump
<particle> kids playing = water for community
<cotto-work> yay.  It's still up.
% Ivatar has joined #parrot
<dalek> r28107 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * 'make coretest' now runs tests in t/00-parrot, t/01-sanity
<dalek> : * 'make codetest' runs Parrot's coding standards tests
<dalek> : * 'make test'     runs coretest and codetest
<dalek> : * 'make fulltest' runs coretest, spectest_regression, and codetest
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28107
<dalek> r28108 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Fix properties, trailing spaces, c file coda on src/pmc/mutablevar.pmc
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28108
<dalek> r28109 | coke++ | trunk:
<dalek> : 
<dalek> : > The attached patch fix a warning in optimized build in
<dalek> : > src/exceptions.c:Parrot_print_backtrace by moving a variable
<dalek> : > declaration inside the conditional branch that uses it.
<dalek> : Courtesy NotFound++ via RT#55296 
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28109
<moritz> file_metadata.t fails on languages/perl6/t/pmc/mutablevar.t
<pmichaud> moritz: is that fixed in 28108?
<moritz> pmichaud: no
<pmichaud> oh, guess not.
<dalek> r28110 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Fix properties on perl6/t/pmc/mutablevar.t (moritz++)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28110
% Zaba has joined #parrot
% ruoso has joined #parrot
<dalek> r28111 | coke++ | trunk:
<dalek> : 
<dalek> : Eliminate a magic constant and replace it with a magic define.
<dalek> : (RT#45953)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28111
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<dalek> r28112 | particle++ | trunk:
<dalek> : [rakudo] improve some error messages, and improve maintainability a bit
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28112
<jonathan> back
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% davidfetter has joined #parrot
<dalek> r28113 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] flesh out algorithm a little more, add points 5, 6, and 7.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28113
<dalek> r28114 | jonathan++ | trunk:
<dalek> : [rakudo] Implement VAR($x) and .VAR macros.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28114
% cjfields has joined #parrot
% purl has left purl!purl@sentient.life
% purl has joined #parrot
<dalek> r28115 | jonathan++ | trunk:
<dalek> : [rakudo] Make readonly return false when not set - scalars are normally rw - and implement rw defined in terms of ro.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28115
<pmichaud>  elsif $key eq 'VAR' {
<pmichaud> 	888 	$past := PAST::Op.new(
<pmichaud> 	889 	:inline("%r = new 'MutableVAR', %0\n"),
<pmichaud> 	890 	:node($/)
<pmichaud> 	891 	);
<pmichaud> 	892 	}
<pmichaud> looks like it's missing a %0 child.
<jonathan> nope, gets unshifted on further up.
<jonathan> It's in dotty, which is a postfix.
<jonathan> Though it was also wrong anyway - we can't just do something like this. As VAR is meant to hand back what it was given unless it was a scalar. Fixing that now.
<dalek> r28116 | jonathan++ | trunk:
<dalek> : [rakudo] Make VAR and .VAR just give what was given to them, unless it's a scalar, per S12.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28116
<dalek> r28117 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] improve init function, deinit, comments.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28117
% cjfields_ has joined #parrot
% cjfields has left cjfields!~cjfields@cjfields.igb.uiuc.edu
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
* jonathan tries to cram the S12 roles section fully into his head
<pmichaud> ENOSPACE
<jonathan> Tell me about it.
<purl> it is probably quite literally a Big Fucking Rock
<pmichaud> S12 roles are just too big for me :-)
<jonathan> It's not so bad.
<jonathan> There's some tricky bits.
<pmichaud> oh, I thought that about a lot of things when reading the synopses.  Like S09.  :-)
<jonathan> But there's a decent bit of stuff that just de-sugars to simpler things.
<pmichaud> yes.
<jonathan> Hmm.
<jonathan> So on generics, I wish it was a tad more explicit
<jonathan> But it seems
<jonathan> role Pet[::Petfood = TableScraps] {
<jonathan> The = here is just defining a default value. It's just parameter syntax, but types, not variables.
<jonathan> Well, default type.
<jonathan> role Pet[::ID;; $tag] { # one type param, one variable param
<jonathan> $myobj does Array[:of(Int)](@initial)
<jonathan> So from this, I would assume that in the square brackets, you can put a list of type parameters, if you have many.
<jonathan> And a list of variable parameters in the parens afterwards.
<jonathan> This only shows it for mix-in style stuff.
<jonathan> Put I assume you can
<jonathan> class Dog does Pet[:PetFood(PedigreeChum)] { ... }
<jonathan> s/Put/But/
% cjfields_ has left cjfields_!~cjfields@cjfields.igb.uiuc.edu
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% Zaba_ has joined #parrot
<particle> jonathan: can you make rw = !ro instead of using ?:
<particle> or, does RETURN (INTVAL !ro); work?
<particle> that probably doesn't work, but i don't know that macro well enough
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<jonathan> Pretty sure that kinda thing doesn't work.
<particle> rw = !ro should work though
<jonathan> I'm also not sure if I should be returning a PMC rather than an INTVAL - one of Bool::True or Bool::False
<jonathan> Yeah, coulda done in that way...just like to be explicit about exactly what will be returned.
<particle> probably should be a Bool
<jonathan> Yeah
<jonathan> pmichaud: readonly and rw methods on a Scalar should return a Bool?
<pmichaud> I don't know for sure.
<jonathan> :-)
% Zaba has joined #parrot
<particle> i think those methods are asking a boolean question
<particle> you should get a boolean answer
<pmichaud> normally I'd say yes, but    :a    is the same as :a(1)
<pmichaud> and :!a is the same as :a(0)
<pmichaud> so for some things our "boolean" interpretations are still 1 and 0
<particle> perhaps that should be :!a is same as :a(Bool::False)
<particle> or, :a(+Bool::False)
<pmichaud> well, :a(+Bool::False)  is the same as :a(0)
<jonathan> I'm pretty sure the synopsis explicitly says 1 or 0 for colonpair syntax.
<particle> that gets rid of some magic numbers from the spec
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<pmichaud> yes.  I started to switch colonpairs to use Bool::True and Bool::False, but then noticed the synopsis said 1 and 0
<jonathan> It wasn't what I'd have guessed, but generally I just implement what the spec says. :-)
<davidfetter> re
<pmichaud> same here. :-)
<davidfetter> i just got a talk slot at YAPC::NA
<davidfetter> (not on parrot)
<davidfetter> anybody know where i can find some crash space at this late date?
% japhb has left japhb!~geoff@76-191-190-8.dsl.static.sonic.net
<pmichaud> there are still rooms at YAPC::NA
<pmichaud> a message just went out about that.
<particle> what mailing list aren't i on?
* davidfetter didn't get that
<particle> i haven't heard any yapc news
<pmichaud> http://conferences.mongueurs.net/yn2008/news/198
<pmichaud> I have the yapc news in my RSS aggregator (Google Reader)
% sjansen has joined #parrot
<davidfetter> the parrot hack thing is the weekend before, right?
<jhorwitz> davidfetter: yes.  what are you talking about?
<davidfetter> DBI-Link
<davidfetter> and the stuff inside pg the crew and i are doing to make it better
<davidfetter> it's written in pl/perlU
<jhorwitz> nice
<jhorwitz> we will have many beers.  :)
<davidfetter> mmm...beers
* davidfetter hopes to hit up some of that chicago music scene
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<dalek> r28118 | jonathan++ | trunk:
<dalek> : [rakudo] Make us able to use role names as type constraints again. We may have to revisit whether we want to register a Role proto at some point in the future; this gets things fixed for now.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28118
<jhorwitz> pmichaud: ping
<pmichaud> pong
<jhorwitz> metaclass question
% Zaba has joined #parrot
<pmichaud> .WHAT ?
<purl> .WHAT is, like, like blessed
<jhorwitz> i was using Protomaker to make generic parrot objects available to perl6.  doesn't work now -- is there an easy way to make P6Object do the same?
<pmichaud> yes
<pmichaud> ummmmm.
<jhorwitz> :)
<pmichaud> try  P6metaobject.register('MyClass')
<jhorwitz> should i create the class w/ new_class as well?
<jhorwitz> or leave as is
<pmichaud> if the class already exists, don't (re-)create it with new_class
<jhorwitz> ok
<pmichaud> if you want to use new_class to create the class, that works though.
<pmichaud> did you see my blog post about P6object ?
<jhorwitz> yes, particle pointed me to that
<jhorwitz> worked with it til i got confused.  :)
<jhorwitz> $P0.'register'('Apache::RequestRec') gives Null PMC access in get_string() at runtime/parrot/library/P6object.pir:306
<jhorwitz> gotta run soon, but i can do some more snooping later tonight.
% japhb has joined #parrot
<cotto-work> .HOW?
* jhorwitz wonders .WHY?
<Auzon> .WHO is on :first?
<pmichaud> is Apache::RequestRec a Parrot class?
<dalek> r28119 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Bring the grammar a bit closer to STD.pm by using <.eat_terminator>
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28119
<pmichaud> and is it 'Apache::RequestRec'  or  ['Apache';'RequestRec']   ?
<jhorwitz> pmichaud: ['Apache'; 'RequestRec'] is
<pmichaud> ahhhhh
<jhorwitz> i read that it handles :: for me, but obviously this has clued you into something...
<pmichaud> well, P6object splits '::'  for the protoobjects, but it doesn't rename the class.
<pmichaud> however, you can do
<pmichaud> $P0 = get_class ['Apache';'RequestRec']
<pmichaud> $P1.'register'($P0)
<pmichaud> i.e., pass the class object itself instead of a string name representation
% Zaba_ has joined #parrot
<pmichaud> but I should get 'Apache::RequestRec' to dtrt and split if needed.
<pmichaud> I wonder if using P6object would now make it easy to get PGE::* and PAST::* to be  ['PGE';*] and ['PAST';*]
<pmichaud> instead of the string constant names.
<pmichaud> that would make for a very nice consistency.  :-)
<jhorwitz> closer, but now i get: Method 'item' not found for invocant of class 'Apache;RequestRec'
<jhorwitz> while evaling the perl6
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<pmichaud> I should probably add that to P6object
<jhorwitz> i have to run -- msg me if you have something else for me to try.  thanks pm.
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<jonathan> pmichaud: If you're doing some inline PIR, is there a way to say %r is an integer register?
% davidfetter has left davidfetter!~davidfett@start.fetter.org
<dalek> r28120 | jonathan++ | trunk:
<dalek> : [rakudo] We should only initialize scalars with protoobjects; if it has a type that is a role or a constraint, it's just a Failure object.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28120
% teknomunk has joined #parrot
<pmichaud> jonathan: yes, by passing a signature.
<pmichaud> :inline(" %r = add %0, %1 "), :signature("III")
<pmichaud> %r, %0, and %1 are all I registers
<pmichaud> (the 0 and 1 arguments get coerced to I registers if they aren't already.)
% iblechbot has left iblechbot!~iblechbot@14.16-dial.augustakom.net
<pmichaud> (%r becomes a unique I register that is the result of the node.)
<jonathan> Ah!
<jonathan> Neato, I'll go tidy my last patch. :-)
<pmichaud> even better, we can add 'isa' to the set of pirops
<pmichaud> then it can be  :pirop(isa)
<pmichaud> and you don't need the :inline at all.
<pmichaud> or the casts.
<jonathan> Where'd I do that?
<jonathan> In PCT somewhere?
<pmichaud> yes, in src/PAST/Compiler.pir
<pmichaud> add an entry for    piropsig['isa'] = 'IP~'
<jonathan> hmmm...I did
<jonathan>                         PAST::Op.new(
<jonathan>                             :inline("    %r = isa %0, 'P6protoobject'\n"),
<jonathan>                             :signature('IP'),
<jonathan>                             $type
<jonathan>                         ),
<jonathan> And got
<jonathan> Method 'signature' not found for invocant of class 'PAST::Op'
% Limbic_Region has joined #parrot
<pmichaud> oh, maybe it's piropsig
<pmichaud> :piropsig
<pmichaud> that's probably it.
<Limbic_Region> pmichaud - unless things have changed yesterday, parrot fails to build on Win32/MinGW due to PGE
<Limbic_Region> and
<Limbic_Region> Win32/Cygwin hangs forever in the rakudo spectest
<pmichaud> "parrot fails to build due to PGE"  usually means you need to check out a fresh copy of Parrot.
<Limbic_Region> nope
<pmichaud> I.e., it's not a PGE bug, it's just that PGE is the first parrot program that runs in the build.
<Limbic_Region> I always do a realclean
<moritz> Limbic_Region: that loop is a known issue with utf8 parsing
<pmichaud> not realclean.
<jonathan> Heh, piropsig ain't it either. :-)
<pmichaud> fresh checkout.
<Limbic_Region> why would I need to do a fresh checkout?
<pmichaud> we don't know.
<pmichaud> but realclean isn't real clean for some reason.
<Limbic_Region> that makes little sense since I don't do anything other than build parrot and run the rakudo test suite
<moritz> Limbic_Region: 'make fulltest' for a non-hanging test
<Limbic_Region> thanks mortiz
<pmichaud> Limbic_Region: agreed.  But you're not the first person to report this problem, and in each case a fresh checkout has solved it (where 'make realclean' didn't).
<moritz> Limbic_Region: tools/update_passing_test_data.pl circumvents the problem by deleting the looping test files :/
* Limbic_Region debates isolating what isn't cleaned in realclean that makes a fresh checkout work
<moritz> Limbic_Region: check out a fresh copy, and do a diff
<moritz> between the tainted but real-cleaned and the fresh checkout
<Limbic_Region> yeah, I knew what you meant
<moritz> perhapse delete all .svn dirs first
<Limbic_Region> I am just debating on if I feel like doing so is all
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<pmichaud> jonathan: oh, I was wrong.  I don't have signatures on :inline nodes yet
<pmichaud> however, you can do
<pmichaud>     :pirop('isa IP~')
<pmichaud> (no inline)
<jonathan> Just added it to PAST compiler
<pmichaud> and that will generate an 'isa $Ix, $Px, *'  instruction
<pmichaud> or you can add it to PAST compiler :-)
<bacek> morning everybody
* bacek impressed by backlog
<pmichaud> jonathan: the problem with   my $type_pir := " %r = new %0, %1\n setprop %r, 'type', %2\n";   is that it won't work if we switch $?PERL6SCALAR back to 'Failure'
% Zaba has joined #parrot
<jonathan> pmichaud: Hmm. True.
<dalek> r28121 | jonathan++ | trunk:
<dalek> : [pct] Add isa to known pirops.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28121
<jonathan> Are we wanting to do that, now we've got mutables passing all tests anyway?
<pmichaud> that's not necessarily bad, though, if we're very comfortable that Perl6Scalar will be permanent.
<pmichaud> we can leave it that way for now.  Maybe fix the comments at the top so that we know what else to change .
<jonathan> I suggest let's leave it in for a week or two and see how it goes with Perl6Scalar.
<pmichaud> okay.
<jonathan> And yes, comment is good idea. Will do now.
<particle> Limbic_Region: pmichaud: the realclean/new co problem is something in c2str.pl
<pmichaud> ah yes, of course.
<particle> i suspect that if you delete all_cstring.str it may be cleaned up
<particle> not sure if realclean deletes that file
<particle> i can't find 'all_cstring' in Makefile anywhere
<dalek> r28122 | jonathan++ | trunk:
<dalek> : [rakudo] Tidy up use of isa thanks to adding isa as a known pirop in PCT.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28122
<jonathan> OK, I think I'll probably leave it there for today and write some report to post.
<pmichaud> sure.
<jonathan> Didn't get much done on roles, as I'd hoped.
<pmichaud> oh, for future reference, in piropsig we keep the pirops in alphabetical order.
<jonathan> Oh. Oops. :-)
<pmichaud> (but I'll fix that later, if you don't)
<pmichaud> "Free karma!"
<dalek> r28123 | jonathan++ | trunk:
<dalek> : [pct] Patch for the preservation of alphabetical ordering of pirops.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28123
<jonathan> Free karma indeed.
<jonathan> karma jonathan
<purl> jonathan has karma of 630
<dalek> r28124 | particle++ | trunk:
<dalek> : [rakudo] improve eval_lives_ok and eval_dies_ok, courtesy of Ronald Schmidt <ronaldxs@software-path.com>
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28124
<jonathan> Geck, I'm not even four figures yet.
% Zaba_ has joined #parrot
<pmichaud> here's a nice competition:
<pmichaud> karma particle
<purl> particle has karma of 1343
<pmichaud> karma pmichaud
<purl> pmichaud has karma of 1345
<bacek> karma c
<purl> c has karma of 6957
<bacek> :)
<particle> ooh
<particle> i'd better do some commits!
% davidfetter has joined #parrot
<bacek> particle, go for it! :)
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<bacek> But there is some successor of "C Language" that helps 'c' a lot :) 
<davidfetter> anybody got examples of using parrot's stuff to replace lexx/yacc ?
<davidfetter> as in, replacing it in an extant code base
* bacek wanders can we generate something else from PAST/POST but PIR.
% Zaba has joined #parrot
<moritz> davidfetter: do you want to parse stuff with PGE?
<davidfetter> moritz, well, i have fuzzy, inchoate ideas about removing some of postgres's grammatical pain using parrot somehow
<davidfetter> "fuzzy, inchoate" is perhaps generous ;)
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<moritz> davidfetter: but PGE doesn't emit C atm, so you'd have a parrot depency
<davidfetter> hrm
<davidfetter> that would be a sticking point
<moritz> btw I think that SQL is intrinsically evil to parse
<moritz> it's just not structured, really
<davidfetter> meh
<davidfetter> i think part of its evilness is the hardness from tools like yacc to see more than one step forward
<moritz> but why? LR[1] = LR[k] for k > 1
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
<cotto-work> davidfetter, I'm looking at doing something like that with PHP's grammar, but I'm currently at the "wtf have I gotten myself into" stage
<particle> oh, that can last a long time.
<particle> beer helps.
<cotto-work> I'm thinking it will.
<cotto-work> but not at work
<davidfetter> cotto-work, i don't think SQL's grammar is quite as insane as php's
<davidfetter> for one thing, there's EBNF for it up through SQL:2008
<jonathan> pmichaud: How hard is / have you pondered parsing adverbs for operators?
<jonathan> for 1..100 :by(2) -> { }
<davidfetter> picture a dim bulb flickering over my head
<davidfetter> so 'by' would be the adverb for '..' ?
<jonathan> davidfetter: Yes.
% cxreg has left cxreg!~count@62.f9.1243.static.theplanet.com
<pmichaud> I've pondered adverbs only a little bit.
<pmichaud> I think we need protoregexes to make that work reliably.
<jonathan> OK, but a protoregex dependency rather than an LTM one. That's a nice thing. :-)
% IllvilJa has joined #parrot
<pmichaud> I've been doing a lot of thinking about ltm in my "off" time -- I think it might not be as difficult as initially feared.
<jonathan> A lot of Perl 6 stuff keeps ending up this way... :-)
<pmichaud> actually, might not even need protoregex, now that I look at it some more.
<pmichaud> but do need some introspection on operator precedence parsing
<pmichaud> (which we also need to get   $a = 1, $b = 2   to parse properly)
<pmichaud> looks like STD.pm might be incomplete there, though.
<jonathan> I think STD.pm is missing some stuff relating to does also.
<jonathan> And property declaration
<jonathan> my int property blah;
<pmichaud> could be. I know it was missing trait_auxiliary:does
% davidfetter has left davidfetter!~davidfett@start.fetter.org
<pmichaud> (at least I _think_ it was trait_auxiliary.  I'll have to check the irc logs.)
<jonathan> If you can confirm it is a trait_auxiliary, I'll do the grammar clean-ups etc next time around.
% davidfetter has joined #parrot
<Whiteknight> in RT, how do I indicate when one ticket relies on a previous one?
<pmichaud> "Links"
<Whiteknight> thanks!
% peepsalot has left peepsalot!~peepsalot@bwext.kpimdp.com
<pmichaud> jonathan:  (does)   http://irclog.perlgeek.de/perl6/2008-05-31#i_321390
<pmichaud> audreyt pmichaud: "does" is parsed as trait_auxiliary, mentioned around S12:1436 (or did I miss what you were asking about?)
<pmichaud> and TimToady confirmed that a bit later, although I forget where.
<pmichaud> afk, family stuff.
% Ivatar has left Ivatar!~graham@tu055.demon.co.uk
% cxreg has joined #parrot
<cotto-work> protoregexes
<cotto-work> protoregex?
* davidfetter tries to picture, "the ascent of regex"
<davidfetter> maybe with a kleene star on the left side...
% gmansi has left gmansi!~gmansi@190.55.35.246
<TimToady> jonathan: I'm not sure I believe in property declarations anymore, given that I'd forgotten about them myself...
<jonathan> TimToady: OK, well, I'll leave it to you to decide whether to drop it from S12 or not. Were my ramblings about parametric types along the right lines?
<jonathan> (A bit earlier in the backscroll)
<cotto-work> jonathan, does one of your presentations explain protoregexes?
<TimToady> I think only the [] can officially be part of the role name
<TimToady> iirc the () was only an initial value
<jonathan> cotto-work: No, because I haven't come up with a good way to explain them yet... :-)
<jonathan> TimToady: Can you have multiple type parameters inside the []?
<TimToady> yes
<jonathan> And can you say class Dog does Pet[:PetFood(PedigreeChum), :WalkingMechanism(Leash)) { ... }
<TimToady> it's just a regular signature on some level
<jonathan> erm
<particle> the name "protoregex" makes them sound like undefined regexes, somewhat like "protoobjects" are undefined objects
<jonathan> With the missing ] in there
<jonathan> class Dog does Pet[:PetFood(PedigreeChum), :WalkingMechanism(Leash)] { ... }
<TimToady> if it matches the signature, sure
% gmansi has joined #parrot
<jonathan> OK, but you are only allowed one value in the (...)?
<TimToady> has to be something coercable, I think
<jonathan> Sorry, I'm not sure what you mean by that.
% tetragon has joined #parrot
<jonathan> From S12: role Pet[::ID;; $tag] {
<jonathan> Here $tag is just a variable. How do we initialize this?
<TimToady> Pet[MyId, $mytag]
<TimToady> just like extra args in a multi call
<TimToady> it's the same ;;
<jonathan> OK, or as named Pet[:ID(MyId), :tag($mytag)] I guess
<jonathan> And should I read:
<jonathan> "A role applied with does may be parameterized with an initializer in parentheses, but only if the role supplies exactly one attribute to the mixin class"
<jonathan> To mean that you can only use the does RoleName($x) form for runtime mix-in?
<jonathan> Or you can do it with a class to, subject to the role having just one attribute?
<jonathan> s/to/too/
<TimToady> at the time I intended it only for run time
<jonathan> And now? ;-)
<TimToady> my brane isn't working well enough right now to decide anything critical  :/
<jonathan> OK.
<jonathan> I think you've given me enough to hurt my head over implementing. :-)
<jonathan> Are you planning for "but" to stay pretty much as is?
<TimToady> er, how is it?  :)
<jonathan> $a = 0 but answer(42) is basically $a = ($anonymous = 0) does answer(42);
<jonathan> for 0 but True style things.
<TimToady> yes, "but" implies a copy, which is done by your assignment there
<TimToady> except we might need to force clone on non-value types
<jonathan> OK, makes sense.
<jonathan> Alright, thanks for the clarifications. I'll leave off your branes a bit. :-)
<jonathan> And should probably sleep sometime soonish...
% slightlyoff has joined #parrot
% slightlyoff has left #parrot
% sjansen has left sjansen!~sjansen@64.207.31.107
* japhb ponders why it is that Perl 6 is attracting mathematician zombies ....
<jonathan> Progress report: http://use.perl.org/~JonathanWorthington/journal/36600
<jonathan> And now I will sleep. Night, all.
<davidfetter> 'night, jonathan 
% bacek_ has joined #parrot
% clunker9_ has joined #parrot
% clunker3 has left clunker3!~IRC@procura.xs4all.nl
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% AndyA has left AndyA!~andy@82.152.157.85
% clunker9_ is now known as clunker3
% AndyA has joined #parrot
% cotto-work has left cotto-work!~cotto@tide534.microsoft.com
% japhb has left japhb!~geoff@208.201.228.107
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% Andy has left Andy!~AndyL@host3130.follett.com
% jhorwitz has left jhorwitz!~chatzilla@96.245.16.45
% japhb has joined #parrot
<dalek> r28125 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Improved List.reduce (bacek++)
<dalek> : * Patch courtesy Vasily Chekalkin <bacek  at bacek.com>, RT#55368
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28125
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% TiMBuS has joined #parrot
% ank has left ank!~ank@ppp121-44-210-24.lns1.hba1.internode.on.net
% ank has joined #parrot
<bacek_> summon pmichaud 
<bacek_> spell failed...
<purl> failed... looks funny
<particle> what's up?
<purl> The Canadian Dollar
<particle> no shizzle, purl
<purl> particle: huh?
<bacek_> msg pmichaud 'Is it good idea to reimplement List.(map, grep, reduce, first,...) as free function which accepts Sub and Iterator.
% purl has left purl!purl@sentient.life
<bacek_> it will making of lazy lists more easy.
<bacek_> particle: almost Lunch time. 
<tetragon> Hrm... decided to try running "make spectest", and a segfault fell out
<particle> tetragon: which test?
<tetragon> And it actually has SIGSEGV in the crash report, instead of the usual SIGBUS
<tetragon> particle: I think it came from t/spec/S12-class/basic.t
<particle> that's unexpected
<tetragon> The trace I have when I tried to reproduce it is different to the one that popped out during make
<tetragon> I'll paste my reproduction attempt
<tetragon> It had a double free
<nopaste> "tetragon" at 69.196.141.26 pasted "Fun with attempting to reproduce a spectest crash" (163 lines) at http://nopaste.snit.ch/13184
<particle> tetragon: you're running svn head, i assume?
<tetragon> Yes, current as of a couple hours ago
<tetragon> r28124
<pmichaud> bacek_: how exactly do you mean?
* bacek_ sub 'sort' :method  .return '!sort'
<particle> tetragon: definitely want a parrotbug filed on that
% Patterner has joined #parrot
* tetragon is busy hooking gdb up to the crash
<bacek_> sub 'sort' method .param pmc e .return '!sort'(e, self.'iterator'())
<tetragon> And it's now sitting in malloc_error_break
<bacek_> s/sort/grep/
<pmichaud> why would we need a separate function for that?
<bacek_> say (1..5).grep { $_ % 2)
<particle> tetragon: if you run ../../parrot perl6.pbc t/spec/... do you get that segfault?
<particle> ...or is perl6 there a link?
<particle> naw, can't be link or alias
<pmichaud> i.e., why can't 'sort' return the generator directly?
<pmichaud> that's more what I would expect.
<pmichaud> er, grep.
<pmichaud> (since sort isn't really lazy)
<bacek_> > say (1..5).grep({ $_ % 2})
<nopaste> "tetragon" at 69.196.141.26 pasted "Yay, gdb at the breakpoint suggested by Apple libc" (49 lines) at http://nopaste.snit.ch/13185
<bacek_> Method 'grep' not found for invocant of class 'Range'
<tetragon> particle: No crash
<particle> tetragon: after Parrot_exit! i'm the only one who's seen that before
* particle hugs tetragon
<particle> finally, that bug has been reproduced!
<particle> ...and not on win32+msvc
<bacek_> pmichaud: i agreed that 'grep' should return generator.
<tetragon> This time on OS X 10.5/ppc
<pmichaud> bacek_: I'll have to think about it a bit.
<pmichaud> bacek_: it's a reasonable approach, but I'm not quite sure that it's "right"
<tetragon> particle: So new ticket, or is there an existing one to append to?
<particle> isn't List the lazy one?
<particle> tetragon: new ticket please
* tetragon now wonders which test it was that actually crashed during spectest
<bacek_> pmichaud: software isn't cut from stone :) We can change it later
<bacek_> actually '!grep' will return generator. So every other classes can get benefit from calling it
<dalek> r28126 | coke++ | trunk:
<dalek> : From RT#55358
<dalek> : > The static function get_op is declared but not defined in several
<dalek> : > files, because the declaration is unconditionally generated in
<dalek> : > Ops2c/Utils.pm
<dalek> : NotFound++, this silences a few warnings when building with --cage. 
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28126
<tetragon> particle: You want anything from the gdb session I have open?
<particle> tetragon: sorry, i'm too distracted right now, preparing for soccer
<pmichaud> List is lazy, yes, but so is Range
<particle> yes, range is lazy too
<Whiteknight> List and Range need to get off their asses and find jobs
<particle> you're one to talk, Whiteknight
<pmichaud> :-P
<Whiteknight> ...:(
<particle> :)
<particle> pmichaud: Range will for sure have a generator
* Whiteknight got hit where it hurts. He'll shut up now
<particle> Range needs a generator that works from either end
% Patterner has left Patterner!~Psyche@e177230180.adsl.alicedsl.de
% Psyche^ has joined #parrot
% Psyche^ is now known as Patterner
% purl has joined #parrot
<dalek> r28127 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] some work on flags, state, resume.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28127
<tetragon> The crash I was trying to find was in t/spec/S12-class/inheritance-class-methods.t
<bacek_> particle: +1 for Range geneartor.
<bacek_> reverse (1..10) should be lazy
<nopaste> "tetragon" at 69.196.141.26 pasted "spectest crash I was trying to manually trigger" (161 lines) at http://nopaste.snit.ch/13186
% Maddingu1 has joined #parrot
% bgeron_ has joined #parrot
% skv_ has joined #parrot
% mj41_ has joined #parrot
% askie_ has joined #parrot
% jq- has joined #parrot
% Psyche^ has joined #parrot
% pmichaud_ has joined #parrot
% jonathan_ has joined #parrot
% cosimo_ has joined #parrot
% d4l3k_ has joined #parrot
% cognominal_ has joined #parrot
% Patterner has left Patterner!~Psyche@e177227215.adsl.alicedsl.de
% AndyA has left AndyA!~andy@82.152.157.85
% ruoso has left ruoso!~ruoso@81.84.157.134
% cosimo has left cosimo!~cosimo@pat-tdc.opera.com
% skv has left skv!~skv_@87.242.97.68
% ilbot2 has left ilbot2!moritz@faui2k3.org
% mj41 has left mj41!~chatzilla@pc-jurosz.ro.vutbr.cz
% TonyC has left TonyC!~tony@202-154-105-237.people.net.au
% cognominal has left cognominal!~cognomina@82.67.232.89
% bgeron has left bgeron!bgeron@toad.stack.nl
% pmichaud has left pmichaud!pmichaud@feather.perl6.nl
% dalek has left dalek!dalek@feather.perl6.nl
% Maddingue has left Maddingue!~Maddingue@profane.mongueurs.net
% wolverian has left wolverian!wolverian@193.200.132.135
% leo has left leo!lt@193.200.132.135
% jonathan has left jonathan!jonathan@193.200.132.135
% askie has left askie!~askie@81.171.100.208
% cizra has left cizra!~cizra@gw.tdng.ttu.ee
% vany has left vany!~vany@shustrik.urh.ru
% integral has left integral!bsmith@adsl-212-20-244-147.lumison.co.uk
% jq has left jq!~jquelin@merlin.mongueurs.net
% Psyche^ is now known as Patterner
% ilbot2 has joined #parrot
% d4l3k_ is now known as dalek
% AndyA has joined #parrot
% wolverian has joined #parrot
% leo has joined #parrot
% integral has joined #parrot
% ruoso has joined #parrot
% cizra has joined #parrot
% vany has joined #parrot
<pmichaud_> actually, a range really *is* a generator of sorts
% DietCoke has joined #parrot
<DietCoke> if I want to test something in the jit core on feather, is TEST_PROG_ARGS=-j prove t/path/to/file.t sufficient?
<DietCoke> (do I have to specifically config with --jitcapable? (doing that now just in case.))
<bacek_> pmichaud_: +1.
<purl> 1
% tetragon has left tetragon!~seneca@69-196-141-26.dsl.teksavvy.com
% Zaba_ has joined #parrot
<cotto_home> If anyone ever talks about PHP's design, they're wrong.
<cotto_home> There isn't one.
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<Patterner> "Repeating 5 year old mistakes"
<cotto_home> there wasn't an excuse for this mess ever, much less 5 years ago
<cotto_home> of course, it'll totally be worth it once I can load a CPAN module from PHP
<cotto_home> php?
<Auzon> purl, php?
<purl> php is really badly designed or swahili for "child molestor" or  or Philippine pesos or the best or PHP: Hardly Programming or brought to you by the teletubbies or proof there is no god or http://xrl.us/t6wx or more modular than perl or the little transgender brother of perl or a WOMBAT or http://tnx.nl/php or easy or or was better when it was a templating system or blamed on Rasmus Lerdorf
<Patterner> A bit biased one might think.
<cotto_home> purl, php is also taking the worse-is-better approach to dazzling new depths
<purl> i'm sorry, but that's too long, cotto_home
<cotto_home> stupid bot
<purl> Up yours, too, bruddah!
<Auzon> dumb bot.
<purl> Go away or I'll replace you with a small and useless factoid!
* Auzon enjoys poking purl
<Whiteknight> haha, the "swahili for 'child molestor'" one had me actually laughing out loud
<cotto_home> do what you know how to, I guess
<cotto_home> (in response to the bot)
<Auzon> :)
<cotto_home> purl, php is also taking worse-is-better to dazzling new depths
<purl> that is too long, cotto_home
<cotto_home> grrr
<cotto_home> purl, php is also taking worse-is-better to new depths
<purl> that is too long, cotto_home
<cotto_home> purl, nvb?
<purl> no idea, cotto_home
<cotto_home> purl, nvb is not very bright
<purl> OK, cotto_home.
<cotto_home> purl, purl is nvb
<purl> ...but purl is a buggy piece of shit or a flooterbuck or a douchebag or an autonomic handjob system, well beyond the need for human intervention or a retard or a trannybot or a fuckslut in GumbyBRAIN's mind or going alone. or almost an anagram of Donaudampfschiffahrtskapitaensmuetzenkordel or a perv or an auto-triage bot or a she or a smartass or the sixth beatle. or http://github.com\/dagbrown\/flooterbuck\/...
<cotto_home> purl, purl is also nvb
<purl> okay, cotto_home.
<cotto_home> purl, purl?
<purl> rumour has it i am a buggy piece of shit or a flooterbuck or a douchebag or an autonomic handjob system, well beyond the need for human intervention or a retard or a trannybot or a fuckslut in GumbyBRAIN's mind or going alone. or almost an anagram of Donaudampfschiffahrtskapitaensmuetzenkordel or a perv or an auto-triage bot or a she or a smartass or the sixth beatle. or http://github.com\\\ or nvb
<cotto_home> If I can't make it do what I want, I can at least make it insult itself.
% Ademan_ has joined #parrot
% Ademan has left Ademan!~dan@h-68-167-207-98.snfccasy.dynamic.covad.net
<Auzon> purl, auzon?
<purl> you are, like, primarily working on rakudo test suite, yes
<Auzon> It must've learned that on its own.
<cotto_home> I am doing stuff
<cotto_home> purl, cotto_home?
<purl> somebody said cotto_home was doing stuff
<Auzon> purl, karma?
<purl> karma is just as useful as the Perlmonks XP :-) or at http://ircxory.jrock.us/
% tetragon has joined #parrot
<Auzon> purl, forget me
<purl> Auzon: I forgot me
<Auzon> purl, I am working on the Perl 6 Test Suite that lives in the Pugs repo
<purl> ...but auzon is primarily working on rakudo test suite, yes?...
<Auzon> no purl, I am working on the Perl 6 Test Suite that lives in the Pugs repo
<purl> okay, Auzon.
<Auzon> purl, auzon?
<purl> you are working on the Perl 6 Test Suite that lives in the Pugs repo
<tetragon> purl, Auzon?
<purl> i think Auzon is working on the Perl 6 Test Suite that lives in the Pugs repo
<Auzon> purl, I am also watches a task file at pugs/t/TASKS
<purl> okay, Auzon.
<Auzon> purl, auzon?
<purl> you are working on the Perl 6 Test Suite that lives in the Pugs repo or watches a task file at pugs/t/TASKS
<japhb> cognominal_, vany: New OpenGL portability patch for you two up on RT #55228
<japhb> y'all are seriously making me work for it, aren't ya?
% dcat_ has left dcat_!~dirtycat@ip70-188-6-59.rn.hr.cox.net
<tetragon> japhb: Just so you know, normal OS X boxes don't have /usr/include/GL
<japhb> tetragon: yes, I know.  er ... and?
<tetragon> But they can have a number of different sets in /Developer/SDKs (which are normally only used if you're targetting a specific release)
<japhb> yep, noticed that from cognominal's hell
<tetragon> japhb: I looked at the ticket and you mentioned that you weren't sent /usr/include/GL
<japhb> tetragon: Ah, gotcha, now I see where you're going
<tetragon> My Macintel has the headers for 10.3.9
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<tetragon> (And the 10.4 that is actually in use)
<japhb> Apparently, cognominal's box *did* have a /usr/include/GL, which included headers for non-core GL stuff, like GLEW.  And GLEW was what was killing his configure.
<tetragon> You can't count on any mac having headers in /opt/local.  The ones that do obtained them via (Darwin|Mac)ports
<tetragon> What I saw in the ticket was /opt/local/include, so getting it through darwinports
<japhb> I'm not even searching /opt/local/ ... should I?  Is that "polite" on Mac OS X?  Right now, I'm only doing /usr/include/GL/, /usr/local/include/GL/, and the Mac OS X Frameworks directories
<japhb> Oh, and the Win32 $ENV{INCLUDE} path
<tetragon> I normally don't deal with anything there as I work from source (found fink and darwinports too annoying)
* japhb wonders what crazy moon directories Solaris will want to use ....
<japhb> tetragon: nodnod
% tetragon has left tetragon!~seneca@216.126.67.44
<DietCoke> (searching) ... why not just search those paths that have already been identified as potential search paths?
<DietCoke> you shouldn't be duplicating that logic in your little slice of config.
<japhb> DietCoke: explain, please.  kid51 told me back in the early days that Configure currently has no way to track locations of where system headers can be found.
<japhb> [OT] Oh ZOT!  No wonder this $day_job sanity checking code is always returning false ... I forgot to add an "is sane" case.  Sheesh.  Been debugging that for half an hour ...
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% cotto-work has joined #parrot
% teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net
<DietCoke> japhb: perhaps it should?
<DietCoke> though if it's currently being stored anywhere, no need to refactor it to make your stuff work.
<DietCoke> not being.
<DietCoke> (but I know, for example, darwin is already probing for fink/darwinports)
<japhb> DietCoke: yes,  I believe there are some probes for non-standard locations (as with, as you say, fink/darwinports) ... but no probing or storage of "standard" locations.
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
<japhb> In general, I think the config system needs some refactoring, but it's a task I'm putting off for the moment ....
<japhb> For one thing, I need some more experience with the various pain points before I'm qualified to do a refactoring that doesn't just trade one set of problems for another.
<japhb> (Though I admit that the 'make clean' versus 'make realclean' issue is really starting to bug me.)
<DietCoke> well, if you're dabbling in config, that's unfortunately to be expected at the moment. 
<DietCoke> though it seems a reconfig should be fine in most cases.
<japhb> Oh, I always do 'make realclean' anyway (old habit) ... it's the problem reports from other people who just did a 'make clean' after I committed an OpenGL change and something didn't work. It's a bug in the config/build process design, not a bug in my code per se, but I get the bug anyway.
<DietCoke> ah, that. I addressed some of that in my response to you a few days ago.
<japhb> I mean, if even someone who has been at it as long as you sometimes trips over that, there's a problem.
<DietCoke> oh, definitely.
<japhb> DietCoke: yep, that's what I was referring to.
<japhb> I'm leaving your ticket open at the moment while I ruminate on what I want to do about it.  (How much do I want to bite off)
<DietCoke> most of my rant belongs in a new ticket(s). =-)
<japhb> true
<japhb> If you feel like opening a new ticket with the rant, and resolving the old one, that's fine by me.  Just let me know what the new RT # is (or add me as a watcher or whatever the RT equivalent is)
<japhb> Because even if someone else does the work, it's still going to have a major effect on the OpenGL stuff.
% bacek has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% Patterner has left Patterner!~Psyche@e177227215.adsl.alicedsl.de
% Psyche^ has joined #parrot
% Psyche^ is now known as Patterner
% uniejo has joined #parrot
% Maddingu1 is now known as Maddingue
% Zaba has joined #parrot