% bacek_ has joined #parrot
<bacek_> hi again
<purl> oh, you're back!
% Zaba_ has joined #parrot
% Auzon has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net
% Zaba has joined #parrot
% luca_ has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% luca_ has left luca_!~lucax@78.13.109.216
% mire has joined #parrot
% mire has left mire!~Frodo@111-173-222-85.adsl.verat.net
% tetragon has left tetragon!~seneca@216.126.67.44
% avar has left avar!avar@u.nix.is
% bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
% bacek has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% bacek has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
% Zaba has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% bacek has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
% Whiteknight has joined #parrot
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-197-167.dynamic.mnet-online.de
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% rdice has joined #parrot
% masak has joined #parrot
<pmichaud> pong
<moritz> d'oh, S29-str/comb.t only passes because all tests are fudged
<jonathan> pmichaud: Did you think mutables were enabled in trunk, or disabled?
<jonathan> As the value at the top of actions.pm is set to what the comment says it should be to use them.
<jonathan> But in reality, they weren't actually being used.
<pmichaud> I haven't had a chance to update the comment
<pmichaud> why are they not actually being used?
<jonathan> Because MMD was dispatching infix:= to Object.pir's one, which did copy.
<pmichaud> I'm not using MMD, I'm using method calls.
<jonathan> I discovered then when implementing ro, rw, and copy for parameters...
<jonathan> Hmm
<pmichaud> it's   $target.infix=($source)   instead of infix:=($target, $source)
<masak> jonathan: how come `./perl6 -e '$_'` gives the error "too few arguments passed (0) - 1 params expected"?
<jonathan> Somehow, we were ending up calling Object.pir's infix:= when it looked like it was a Perl6Scalar invocant.
<pmichaud> well, keep in mind that Object.infix:= can be called in some situations, such as values held in arrays
<jonathan> Sure
<jonathan> It was something in parameter passing though, I think.
<jonathan> Or maybe I was confused.
<jonathan> I was hunting an GC bug at the time too. ;-)
<jonathan> Which I have a patch to fix.
<pmichaud> parameter passing doesn't go through infix:= yet -- although it will need to.  That is high on my hit list
<jonathan> OK.
<jonathan> I will put in my is rw, is ro, is copy stuff for parameters.
<jonathan> Got it working nicely here.
% tetragon has joined #parrot
<pmichaud> excellent
<jonathan> Well, on the laptop.
<purl> on the laptop is fine.
<jonathan> OK, I need to eat lunch.
<masak> purl: forget on the laptop
<purl> masak: I forgot on the laptop
<jonathan> masak: Please submit a ticket about that.
<masak> jonathan: oki
<jonathan> I'm not sure why you'd usefully want to do what you just suggested. :)
<jonathan> But I doubt that you're gettign the error you should be.
<moritz> $_ = 1; $_ # gives the same error
<masak> jonathan: what I did was the minimal test case I produced
<masak> I got the error in a larger script
<moritz> > $_ = 1; say $_
<moritz> even that is errornous
<pmichaud> I think it's that $_ is causing the outer sub to have a parameter
<masak> how sinister
<pmichaud> yes, it's a rakudo bug
<masak> purl: parrotbug
<purl> well, parrotbug is mailto:parrotbug@parrotcode.org or http://svn.perl.org/parrot/trunk/docs/submissions.pod or see also "rakudobug"
<masak> purl: raukobug
<purl> masak: i'm not following you...
<masak> ehm
<masak> purl: rakudobug
<purl> rumour has it rakudobug is mailto:rakudobug@perl.org
<masak> rumor has it right
<bacek> summon pmichaud 
<pmichaud> pong
<bacek> pmichaud, hi there.
<bacek> You broke 'List.map' :)
<bacek> mmd cant dispatch __add to Failure
<pmichaud> I did?  Or perhaps it was already broken and we just exposed the bug :-)
<bacek> No :) We discussed it few days before (using Undef vs Failure in map)
<pmichaud> is map using Failure?
<bacek> yes... 
<bacek> 67199850 (pmichaud 2008-05-29 16:23:40 +0000 379)     elem = new 'Failure'
<pmichaud> I thought that was used only in the case where we had an insufficient number of arguments
<pmichaud> which isn't (shouldn't be) the case in 06:02 <bacek_>  is ~(1,2,3,4).map({ $^a + $^b + $^c + $^d }), "10",  "map() works with 4-ary functions";
<bacek> exactly. But MMD can't add 1 and Failure. But it can add 1 and Undef
<jonathan> I ran across this the other day
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<jonathan> more subtle
<jonathan> my @a = 1,2,3; my $total; for @a -> { $total += $_ }
<jonathan> ok, really eating now :-)
<pmichaud> yes, I know about that one.  I'm not sure what to do about Parrot's opcode mmd
<pmichaud> I also get similar things with can't concat  Perl6Str, Str
% jhorwitz has joined #parrot
<bacek> I'm currently deep in mmd dispatcher trying to fix it.
<bacek> But it's not-so-easy-to-fix :)
<pmichaud> correct --  I'm not sure I understand the intent of Parrot's design there.
% Zaba has joined #parrot
% DietCoke has joined #parrot
* DietCoke ~~
<bacek> $ ../../parrot perl6.pbc 
<bacek> > say Failure + 1;
<bacek> Segmentation fault
<purl> (Core dumped)
<bacek> ouch...
<masak> bacek: same with most any class I could come up with
<bacek> masak, yes... I see...
<bacek> mmd--
<masak> karma mmd
<purl> mmd has karma of -3
<masak> mmd--
<bacek> :)
<pmichaud> hmmmmm
<pmichaud> perhaps we need to be using 'add' instead of n_add
<pmichaud> still doesn't solve the Failure + 1 problem, though.
<nopaste> "pmichaud" at 76.183.97.54 pasted "Failure + 1, small case" (12 lines) at http://nopaste.snit.ch/13144
<pmichaud> jonathan: is there a particular reason why $IN, $ERR, $OUT, etc. are created as part of 'main' and not 'onload'   in perl6.pbc ?
<nopaste> "bacek" at 202.7.166.175 pasted "workaroung for 'Failure + 1'" (11 lines) at http://nopaste.snit.ch/13145
<dalek> r28022 | jonathan++ | trunk:
<dalek> : [core] Fix a GC bug. A sub did not cause its current context to be marked, meaning that in turn the outer context wasn't marked. This caused LexPad instances to get collected and the memory re-used, leading to all manner of weird errors in find_name.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28022
<pmichaud> (r28022)  wow.  nice catch.   jonathan++
<dalek> r28023 | jonathan++ | trunk:
<dalek> : [rakudo] Implement smart matching on junctions. Additionally, do some fixes to make say (1|2).WHAT work.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28023
<dalek> r28024 | jonathan++ | trunk:
<dalek> : [rakudo] Fix name-o.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28024
<bacek> pmichaud, btw, about last changes in Test.pm. Should lines 81-82 be actually skip(1, ...) instead of proclaim(1,...)?
% tetragon has left tetragon!~seneca@216.126.67.44
<dalek> r28025 | jonathan++ | trunk:
<dalek> : [rakudo] Make Mutable PMC aware of ro property. Also fix GC and memory leak in it.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28025
<pmichaud> bacek:  yes.
<bacek> pmichaud, fix it please :)
<pmichaud> and I think it should really be   skip($reason, 1)    instead of skip(1, $reason) .... but I need to check with particle for that.
<dalek> r28026 | jonathan++ | trunk:
<dalek> : [rakudo] Make is ro, is rw and is copy work on subroutine parameters. The default is now is ro, so trying to assign to a parameter not declared is rw or is copy will be an error.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28026
<jonathan> pmichaud: ($*IN and friends) Not that I can think of, though it must happen after the IO type has been created.
<pmichaud> maybe it should be part of IO initialization then?
<jonathan> OK, that's all my airport patches checked in. :-)
<pmichaud> i.e., 'onload' in IO.pir ?
<jonathan> Yes, that would work too.
<moritz> segfault with r28026 in /00-parrot/04-op-cmp.t
<pmichaud> bacek: r28027
<dalek> r28027 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Fix optional argument forms of skip() in Test.pm.  (bacek++)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28027
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
<pmichaud> jonathan: (junction .ACCEPTS)    why isn't    foo ~~ (2|3)   simply the same as   (foo ~~ 2) | (foo ~~ 3)     ?
<masak> btw, I noticed that 'grammars' was both in the ROADMAP (as things yet to be done) and STATUS (as things implemented by the compiler). if someone provides a clarifying statement about what is implemented and what isn't, I can turn it into a patch
<pmichaud> for ROADMAP I think we need some way of marking progress for each of the items on the roadmap
<pmichaud> i.e., perhaps ROADMAP and STATUS should be combined to show both.
<masak> yes.
<jonathan> pmichaud: It should be
<pmichaud> your patch seems to booleanify it
<jonathan> Oh?
<jonathan> Smart-match doesn't return a boolean?
<pmichaud> no.
<jonathan> OK, that's news to me.
<jonathan> What should it return?
<pmichaud> smart match may be used in boolean context, but it's not always a boolean return value
<pmichaud> (I think)
<jonathan> OK
<particle> jonathan: have you built parrot lately?
% avar has joined #parrot
<jonathan> I think the trunk I just checked in a patch against was from Saturday.
<jonathan> Had no connection yesterday, and been doing other stuff so far today.
<particle>         ..\..\parrot.exe ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir  --output=PGE\builtins_gen.pir PGE\builtins.pg
<particle> Null PMC access in invoke()
<particle> current instr.: 'parrot;PGE::Perl6Grammar::Compiler;compile' pc 200 (..\..\runtime\parrot\library\PGE\Perl6Grammar.pir:157)
<particle> i can't build with HEAD
<particle> since about saturday sometime
<jonathan> Ouch.
<particle> gotta start work now, so can't look for a bit
<jonathan> On Win32?
<particle> yep
<jonathan> OK, ouch indeed.
<jonathan> I can't look right now either - need to do a bit of $DAYJOB before heading off to the Vienna.pm meeting.
<particle> ok, i'll look as soon as i have time
<pmichaud> jonathan: you may be right about smartmatch returning a boolean
<pmichaud> (just looking at the table)
<jonathan> pmichaud: BTW, any votes for what day I do my Rakudo day this week?
<pmichaud> all my days are open at the moment.
<jonathan> OK
<jonathan> I can't do tomorrow, other than that Wed/Thu/Fri are all fine.
<pmichaud> although wed-fri may be less desirable because kids will be home (school ends wednesday noon)
<pmichaud> :-)
<dalek> r28028 | allison++ | pdd25cx:
<dalek> : [pdd25cx] Move PGE off of bsr/ret.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28028
<pmichaud> but I think wed-fri will work fine.
<jonathan> Maybe Friday? The novelty of the kids not being at school maybe wears off by then? ;-)
% Auzon has left Auzon!~ak9@24-171-76-148.dhcp.mtvr.il.charter.com
<DietCoke> pmichaud: that commit message from allison: did she coordinate that with you?
<pmichaud> DietCoke: no, but it's in a branch, and I'm looking at it now. 
<pmichaud> it looks pretty innocuous.
<pmichaud> I would start to be concerned about the pdd25 branch diverging from trunk... but that's allison's problem at the moment :-)
<pmichaud> I also hope that taking continuations isn't much slower than the existing bsr/ret
<pmichaud> the whole reason for using bsr/ret was speed.
<particle> well, luckily, it's a drop-in replacemnet
<particle> even when spelled correctly
<dalek> r28029 | allison++ | pdd25cx:
<dalek> : [pdd25cx] Fix vtable call in branchcc op.
<particle> so it should be easy to bounce back and forth and benchmark
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28029
% jan has left jan!~chatzilla@bdv75-4-82-226-115-243.fbx.proxad.net
<pmichaud> it may all end up being re-done in C anyway.
<jhorwitz> hm, t/00-parrot/05-var-array and t/00-parrot/05-var hang for me
<jhorwitz> repeated calls to mark_context() at src/sub.c:65, then dies at pobject_lives()
<jonathan> Oh, ouch.
<jonathan> Hmm.
<jhorwitz> jonathan: x86_64, will paste backtrace
<jhorwitz> 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
<clunker3> http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
<jonathan> Thanks.
<particle> pmichaud: have a minute to replicate my pge build bug?
<pmichaud> particle: I can try, yes.
<nopaste> "jhorwitz" at 96.245.16.45 pasted "jonathan: test backtrace" (16 lines) at http://nopaste.snit.ch/13146
<particle> cd compilers/pge
<particle> rm PGE/builtins_gen.pir
<DietCoke> (diverge) she's been keeping it relatively updated to trunk. moreso than I have with the type_ids branch. =-)
<particle> ../../parrot --runcore=gcdebug ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg
<pmichaud> particle: okay, finished.
<particle> no Null PMC access in invoke() ??
<pmichaud> particle: no
<particle> aargh!
% gryphon has joined #parrot
<pmichaud> do I need to svn up or something?  Although I did that this morning (but not after jonathan's latest patches)
<particle> no, it's been happening for a few days
<particle> maybe you need to have less of parrot built? iunno
<particle> i'm booting ubuntu to check
<pmichaud> jonathan:  if (!PMC_IS_NULL(ro) && VTABLE_get_integer(INTERP, ro) != 0)
<pmichaud> perhaps the second part should be VTABLE_get_bool ?
<particle> get_bool++
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% iblechbot has joined #parrot
<jonathan> pmichaud: Yes, probably.
<purl> Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look harder.
<masak> purl, forget probably
<purl> masak, I didn't have anything matching probably
<masak> purl, forget yes, probably
<purl> masak, I didn't have anything matching yes, probably
<jonathan> jhorwitz: Looks related to the GC fix I did, but that issue didn't show up here.
<jonathan> Will have a closer look later.
<jhorwitz> k
% Whiteknight has joined #parrot
% ank has left ank!~ank@ppp121-44-210-24.lns1.hba1.internode.on.net
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<jhorwitz> jonathan: seems to me that this code in mark_context(): "if (ctx->caller_ctx) mark_context(interp, ctx->caller_ctx);" would recurse infinitely
<dalek> r28030 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] updating to trunk r28029
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28030
<pmichaud> I'm getting infinite loop in make spectest_regression, also.
<moritz> and I'm getting segfaults before that
% Zaba has joined #parrot
<pmichaud> t/spec/S02-literals/autoref has been running for over a minute now.
* bacek getting segfaults too...
<jhorwitz> pmichaud: based on the backtrace i guess my stack is getting smashed after X iterations (X being very large)
<bacek> I'm suspect r28026 
<jonathan> OK, rip it out.
<jonathan> I'll work out something better that doens't loop.
<jonathan> The real work was in figuring out why we had the GC problem, not the patch...
<pmichaud> which one should be reverted?
<pmichaud> r28026 seems to be the ro/rw/copy patch, so I don't think that's it.
<jhorwitz> i believe it's r28022
<pmichaud> yeah, that seems likely.  I'll try that.
<jonathan> pmichaud: The GC one.
<pmichaud> the GC bug in sub?  (as opposed to GC in mutable?)
<jonathan> Yes
<jonathan> r28022 
<jhorwitz> is there a way to test if the context has been marked already?
<pmichaud> okay, reverted, building, testing, then committing.
<jonathan> jhorwitz: No...they're not GC'able objects.
<jhorwitz> crap
<jhorwitz> why is nothing easy?  ;-)
* jonathan hopes this isn't going to be the start of a very nasty discovery about context handling.
<particle> don't make me wake chromatic
<particle> ...please!
<jonathan> particle: I'll have another look when I get time.
<jonathan> I understand the GC bug part of the problem, if not the context part yet.
<pmichaud> it *might* end up being a non-issue in allison's pdd25 branch
<pmichaud> since a lot of that stuff is being reworked/re-examined.
<particle> ooh, allison is up, bet we could summon her
<pmichaud> after reverting r28022, I get a ton of "cannot morph Perl6Scalar" errors in spectest_regression
<jonathan> pmichaud: That's a result of some copy rather than assign operations, though I didn't think I'd checked in the patch that actually caused this to show.
<pmichaud> looks like it did.
<pmichaud> what should i do?
<jonathan> s/copy/assign/ in a few places, like the undefine sub for one.
<jonathan> It may be the new paramter handling that caused this to show.
<pmichaud> unfortunately, I have to take a break in a few minutes.
<pmichaud> (a break from rakudo, that is.)
<jonathan> OK, I have to leave for Vienna.pm meeting in like 5 mins.
<pmichaud> grph.
* jonathan didn't expect his patches to break *this* much. :-(
% Zaba_ has joined #parrot
<dalek> r28031 | pmichaud++ | trunk:
<dalek> : [core]:
<dalek> : * Revert r28022 from jonathan, which was causing rakudo to get caught
<dalek> :   in infinite loops.  We'll need to revisit this patch later.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28031
<pmichaud> well, I need to skip out for a bit, but can probably look at it again in 30-45 minutes from now.
<bacek> jonathan, fortunately there is many people that can blame you in couple of minutes after commit :)
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<cognominal> jonathan, did the rest of your trip back went well?
<jonathan> cognominal: Not really...there were delays, meaning I missed last bus back from the airport...and nobody around to suggest what to do.
<jonathan> Note it was the bus by the company who did the flight. So they had to know there were people arriving late.
<jonathan> So ended up having to get a taxi back. Which was...none-cheap.
<cognominal> ouch
<jonathan> Next time, I'll just take the train.
% avar has left avar!avar@u.nix.is
% avar has joined #parrot
<jonathan> OK, time to go to Vienna.pm meeting...
<cognominal> well, I got to spend more time with you and learning more about rakudo
<jonathan> Yes, true. And I got to write some patches...that have broken lots. :-(
<jonathan> OK, best go...don't want to miss the train!
<cognominal> good luck
<purl> good luck is all I can say.
% avar has left avar!avar@u.nix.is
% IllvilJa has joined #parrot
% avar has joined #parrot
% Zaba has joined #parrot
* DietCoke grumbles at the build system.
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<Whiteknight> what don't you like about the build system?
<DietCoke> at the moment, that I am unable to merge in changes from trunk to a branch. =-)
<DietCoke> (it breaks the build.)
<DietCoke> (this is regarding generating the ops.num file)
<DietCoke> I think I found a dance that lets me continue. whee.
% Zaba_ has joined #parrot
<DietCoke> hurm. I bet the pure PIR tests we have are never being tested in any core other than the default.
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
<Whiteknight> Yes, I've discovered that merging from trunk to a branch is a total pain
<pmichaud> I tend to not do it.
<pmichaud> but I'm in a situation where I don't have to :-)
<pmichaud> I didn't get to write about this in the email, but what I'll sometimes do is
<pmichaud> svn co trunk
<pmichaud> cd languages/perl6
<pmichaud> svn switch branches/mybranch/languages/perl6
<DietCoke> well, the problem isn't the merging, perse, it's that I did one thing in the branch, something else in the trunk, and the tools that regenerate the generated file don't seem to cope with doing both.
<pmichaud> that way languages/perl6 is coming from the branch, while the rest of my working copy is from parrot trunk
<DietCoke> In general, I don't find merging painful at all. but the fact that we keep generated files checked in confuses things, and the fact that we don't have an easy, consistent way to regen them all exacerbates it.
<Whiteknight> pmichaud, that's actually a very novel solution! Since most of my work is happening in include/Parrot/ and src/gc/, that would save me a lot of hassle
<DietCoke> (which is why I want --maintainer to update *all* generated files that are checked in)
<Whiteknight> especially since most of my merge conflicts occur in the overly-active languages/perl6
<DietCoke> the problem with that approach is that no one else can easily work on your branch.
<DietCoke> (unless they follow the same convention)
<DietCoke> at that point, why not just make your branch be the languages/perl6 dir?
% davidfetter has joined #parrot
<pmichaud> Whiteknight: yes, in your case you could do a checkout of your branch, and then   svn switch trunk/languages
<Tene> overly-active?  maybe we need to rate-limit pmichaud?  ;)
% rdice has joined #parrot
<pmichaud> but yes, that does mean that languages/ in the branch is not up-to-date, if anyone else tries to work in the branch.  For most branches there are only 1 or 2 people working in the branch so coordination isn't always an issue.
<pmichaud> hey, I'm not the only committer to languages/perl6 !
<dalek> r28032 | coke++ | type_ids:
<dalek> : svn merge -r26989:27250
<dalek> : from trunk into the type_ids branch
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28032
<DietCoke> ... that commit hasn't finished yet. annoying.
<DietCoke> (from my perspective)
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
* DietCoke starts up the next merge chunk.
<DietCoke> (sorry to do that in two chunks, but I needed to resolve my ops.skip problem and i wanted to do it with a smaller merge.)
<pmichaud> commits are cheap.
% Zaba has joined #parrot
<particle> DO NOT rate limit pmichaud!!! :)
<particle> i don't understand why you have any merge conflicts in languages, Whiteknight, unless you're making changes there in your branch
<jhorwitz> you cannot stop pmichaud's commits.  you can only hope to contain them.
<dalek> r28033 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Temporarily revert r28026 so that trunk works while I refactor
<dalek> :   parameter handling in a branch.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28033
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<particle> pmichaud: in runtime/parrot/library/PGE/Perl6Grammar.pir ~line 157:
<particle>     .local pmc stmtrule
<particle>     stmtrule = get_hll_global ['PGE::Perl6Grammar'], 'statement'
<particle>   stmt_loop:
<particle>     match = stmtrule(match)
<particle> Null PMC access in invoke
<particle> why would stmtrule be null?
<davidfetter> Those comments are out there. They can't be bargained with!  They can't be reasoned with!  They doesn't feel pity, or remorse, or fear. And they absolutely will not stop, ever...
<pmichaud> stmtrule would be null if ['PGE::Perl6Grammar'], 'statement' doesn't exist.
<particle> yes, obviously. that's the question i should have asked
<particle> i'd like to have a sensible error message for the case when statement doesn't exist
<particle> i'm compiling TGE/builtins.pg here
<pmichaud> but that shouldn't happen.
<particle> so, something's funky.
<particle> right
<pmichaud> have you tried with -G?
<particle> yes, no effect
<pmichaud> windows or linux?
<particle> and it doesn't fail for you even with gcdebug
<particle> windows
<particle> a much better platform for finding gc and null bugs
<particle> ...don't ask me why...
<NotFound> Why?
<particle> i'll do the svn update -r dance now
* jhorwitz loves/hates x86_64 for finding all his bugs
% Andy has joined #parrot
<particle> x86_64 sucks/rocks
<pmichaud> particle:  Perl6Grammar.pir:119 is the one that establishes the 'statement' rule and symbol.
% bacek has joined #parrot
<pmichaud> that's part of the 'onload' sub.
<pmichaud> so, either that call is not working, or 'onload' isn't onloading, or something else is clearing out the 'statement' rule by the time the other code executes
<particle>     unless null $P0 goto not_null
<particle>     say "WTF!?!?!?!? 'statement' is NULL"
<particle>   not_null:
<particle> doesn't trigger that line
<particle> so, $P0 isn't null after the call to p6regex
<pmichaud> ...$P0 ?
<particle>     $P0 = p6regex($S0, 'grammar'=>'PGE::Perl6Grammar', 'name'=>'statement', 'w'=>1)
<pmichaud> oh, you could still be getting a value back for $P0 
<particle> ah. hrm
<pmichaud> try testing ['PGE::Perl6Grammar'], 'statement' at that point.
% Theory has joined #parrot
% Zaba_ has joined #parrot
<particle> yep, it's null
<dalek> r28034 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Temporarily switch off of using Perl6Scalar until we figure out
<dalek> :   the assign/morph issue.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28034
<pmichaud> okay, if it's null there, that means that p6regex isn't doing its job
<pmichaud> try adding 'target'=>'pir' to the set of options, and then say $P0
<pmichaud> so
<pmichaud>    $P0 = p6regex($S0, 'grammar'=>'PGE::Perl6Grammar', 'name'=>'statement', 'w'=>1, 'target'=>'pir')
<pmichaud>    say $P0
<particle> blank line
<purl> blank line is one that containt nothing but s
<pmichaud> try displaying $S0 before the call
<particle> $S0 contains the heredoc text
<particle> ...beforehand, and $P0 blank after
<pmichaud> so.... for some reason p6regex isn't compiling the regex properly
<particle> but it's still returning non-null $P0
<particle> that seems fishy to me
<pmichaud> normally p6regex compiles all the way down to bytecode
<pmichaud> i.e., it compiles to PIR, then runs the PIR compiler on that
<pmichaud> the 'target'=>'pir' _should_ have caused it to stop at the PIR step, and then displayed the PIR that was generated
<particle> i can try parse
<pmichaud> to display the parse you'll need to call _dumper($P0)
<pmichaud> instead of say
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<particle> gotta load_bytecode, too
<particle> what should i load, PGE/Dumper.pbc?
<pmichaud> yes, and dumper.pbc
<particle> parse exists, moving on to PAST
<particle> "VAR1" => PMC 'Eval' { ... }
<particle> does that mean it worked?
<pmichaud> that means that 'target=parse' didn't.
<pmichaud> oh, sorry, missed "parse exists"
<pmichaud> PGE doesn't compile to PAST
<pmichaud> try target=exp
<particle> ah, right
<particle> exp, okay
<particle> "VAR1" => PMC 'Eval' { ... }
<pmichaud> checking.
<purl> checking is not the hard part here. ;-)
<pmichaud> target='pge::exp'
<pmichaud> (I'll be glad when I can refactor PGE to be more hllcompiler-like)
* particle too
<particle> ok, i get a tree back for pge::exp
<particle> next step?
<purl> next step is PROFIT.
<particle> sorry, couldn't resist :)
<pmichaud> target='pir', but leave it as _dumper
<particle> "VAR1" => ""
<pmichaud> that is seriously bogus.
<particle> can i give you any nopasted output to help?
<pmichaud> how about turn on tracing just before the call to p6regex?
<pmichaud> might be a big long, though.
<pmichaud> s/big/bit/
<particle> 'tis
<particle> will do
<particle> seems likely to overflow my buffer (9999 lines)
<pmichaud> maybe email it to me, or post it somewhere?
<particle> yo want the whole trace?
<pmichaud> I'm thinking
<pmichaud> is this particular error blocking your build (because it won't build TGE?)
<particle> yes
<particle> i can't work on rakudo or mk_language_shell
<particle> unless i revert to saturday's build
<pmichaud> you're realcleaned and up-to-date on everything?
<particle> ayep
<pmichaud> so, something broke on saturday
<particle> i'm looking at the logs
<pmichaud> do we know which .... right.  It would help to know which item broke the build.  I'll look too for candidates.
<particle> svn log -r {20080530}:HEAD --verbose | gvim -
<pmichaud> try r27970
<particle> config/building now
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
<pmichaud> that should pass.  If it doesn't, that's a huge clue.
<pmichaud> fwiw, nothing has changed in PGE itself since 20080530
<particle> yeah, i know :(
<pmichaud> my next guess would be chromatic's changes on early sunday   --- so try r27988
<pmichaud> (er, that would be "late Saturday" for your timezone)
<pmichaud> ("early Sunday" in mine :-)
<particle> 27970 failed
<pmichaud> okay, that's a huge clue.
<pmichaud> do you know what revision number succeeds?
<particle> no, i'm gonna try 33 now
<particle> if that doesn't work, i'll go back to friday
<pmichaud> not a lot happened on friday, either.
<pmichaud> I mean, -r '{20080530}:head'  includes any commits that were made on Friday
<particle> ah
<particle> well, 33 is from friday, thoun
<particle> er. then.
<pmichaud> correct.
<pmichaud> r27933 | pmichaud | 2008-05-29 23:35:34 -0500 (Thu, 29 May 2008) | 3 lines
<particle> seems to still fail
<pmichaud> 33 fails?
<particle> i didn't do a realclean
<pmichaud> you almost _have_ to do a realclean for this
<NotFound> Some of that changes are patches from me.
<particle> yeah, am doing now
% jan has joined #parrot
<pmichaud> I'm going to need lunch soon :-(
<Whiteknight> hear hear!
<particle> here here! :)
<pmichaud> particle: are you doing realclean on 33 or 70?  Did you do realclean on 70 before?
<dalek> r28035 | pmichaud++ | rakudoparam:
<dalek> : [rakudo]:
<dalek> : * New branch for refactoring parameter variables.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28035
<particle> i did realclean 70
<pmichaud> okay, so my "big clue" stands.
<particle> just realcleaned 33 and got failure
<particle> "VAR1" => ""
<particle> WTF!?!?!?!? 'statement' is NULL
<particle> Null PMC access in invoke()NMAKE : fatal error U1077: '
<pmichaud> you didn't revert the P6Grammar stuff?
<particle> no, should i?
<particle> statement is still null
<pmichaud> does 'svn status' show that as the only modified file?
<pmichaud> (in all of trunk?)
<particle> yes
<particle> except languages/perl6/t/harness
<pmichaud> okay, that should be safe.
<particle> but that's totally unrelated
<pmichaud> so, how far back should we go?
<particle> i'll try 27900
<particle> that only changes the class and object pmcs
<pmichaud> that could be it, though.
<pmichaud> (scanning log)
<pmichaud> you did a commit on r27921, so presumably it was working for you then
<pmichaud> also r27932
<pmichaud> er, r279*23*
<pmichaud> but nothing of significance changed from r27923 to r27930
<pmichaud> er, 
<pmichaud> but nothing of significance changed from r27923 to r27933
<pmichaud> well, I had better get some lunch -- haven't eaten since early yesterday
<particle> ~~
<pmichaud> bbiaw
<DietCoke> has someone changed imcc recently?
<Whiteknight> I changed it a while back with the ".namespace []" thing. 
<DietCoke> nevermind, another merge related issue with generated files. =-)
<DietCoke> (had to delete imclexer.c to get it to regen.)
<DietCoke> ... worse, had to re-touch the .l and .y files to insure those changes were more fresh than the other changes brought in from the merger.
% masak has left masak!~user@130.238.45.242
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot
<dalek> r28036 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] updating to trunk r28035. A number of merge conflicts that I wanted to tackle today and not leave until tomorrow.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28036
<Whiteknight> yeah, i had to do the same when I regenerated those files, had to touch them to ensure they were newer, so make would operate on them
<DietCoke> one of the reasons I'd like --maintainer to just regen _everything_ when we use it. =-)
<particle> that imcc problem is very old, if not well-known
<DietCoke> I'll be happy if we can remove them as build dependencies. =-)
<particle> create a replacement for imcc that doesn't use .l and .y files, and we can do that
% jjore is now known as zz_jjore
% zz_jjore is now known as jjore
<dalek> r28037 | coke++ | type_ids:
<dalek> : svn merge -r27251:28031
<dalek> : Merge from trunk to the type_ids branch
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28037
% cjfields has joined #parrot
<cjfields> pmichaud: regarding Str and trans(), I have noticed in PDD28 that trans() may be deprecated
<cjfields> http://www.parrotcode.org/docs/pdd/pdd28_strings.html#Methods
% ambs has joined #parrot
<pmichaud> cjfields: no problem, we can always roll our own if we need it
<moritz> actually that's one of the things that could easily be implemented in perl 6
<moritz> so I'll wait until that's possible, then I'll have a go at it
<cjfields> That's what I'm thinking.  Probably will be ... d'oh moritz beat me to it
<moritz> cjfields: or you do it then, and I'll try to implement currying instead
<moritz> cjfields: I don't think we'll have a shortage of things to be implemented in pure perl ;)
<cjfields> Okay.  I have toyed with adding it in PIR (via Str.pir).  Where would we add it in perl6?
* moritz starts a list of things that can easily be implemented in Perl 6
<pmichaud> I don't have that worked out yet
<pmichaud> but I'm getting very close.  
<moritz> cjfields: it's not yet possible to write runtime/prelude in perl 6
<pmichaud> I just need MD5 or some sort of uuid generator that PCT can use.
<pmichaud> I might break down and use Digest::MD5 as it is now rather than wait for a cleaner version.
<pmichaud> could always clean it up or fix it later.
<cjfields> I have already started a simple p6 version of trans() so it wouldn't be too hard to add it in
<pmichaud> I'd say go with the p6 version if we have one
% AndyA has left AndyA!~andy@82.152.157.85
<pmichaud> we might want to implement the 'yada' soon.
<cjfields> agree, the 'yada' would be nice
<DietCoke> whee. pdd25cx is now dying with a segfault building PGE.
% AndyA has joined #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% barney has joined #parrot
* DietCoke rants about the metadata failures in the merges in the type_ids branch in languages/perl6
<DietCoke> There's a good reason to do them as one commit. :P
<spinclad> purl, literal probably. 
<purl> spinclad: probably. =is= <reply> Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look harder.
<spinclad> purl, literal probably.
<purl> spinclad: probably. =is= <reply> Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look harder.
<spinclad> purl, forget probably. 
<purl> spinclad: I forgot probably.
* DietCoke imagines all the other purl users on this server are quite unhappy with our mods.
<spinclad> no more snarks! no more character!
<DietCoke> even better, the property failure I'm getting isn't a result of the last few merges. which means i missed a merge somewhere.
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
* DietCoke grumbles.
% Zaba has joined #parrot
<spinclad> i could reinstate probably. ...
<cotto_work> seen allison
<purl> allison was last seen on #parrot 12 days and 21 hours ago, saying: I've seen that, Infinoid++,  [May 20 13:48:40 2008]
<spinclad> surely that would help with merge problems...
<pmichaud> ....sigh... big pct addition coming up
* pmichaud takes a short walk first.
% slightlyoff has joined #parrot
% autarch has joined #parrot
% autarch has left #parrot
% slightlyoff has left #parrot
% sjansen has joined #parrot
% TimToady has left TimToady!~larry@209.9.237.164
% TimToady has joined #parrot
* DietCoke wonders if TimToady is a poisonous toad.
<TimToady> .oO(ribbit)
* particle tapes a "lick me" sign on TimToady's back
<ambs> DietCoke, done :-P
<DietCoke> ambs, thanks. =-)
<DietCoke> Coke is also a pest.
<purl> okay, DietCoke.
<DietCoke> particle: ewwwwwwwwwwww
<pmichaud> DietCoke: must be a west coast sort of thing.  :-)
<ambs> DietCoke, a big pest! :-P
<particle> pmichaud: a fresh co of parrot builds. go figure.
% Theory has joined #parrot
<pmichaud> something was out of whack then :-)
<particle> i wish i knew what.
<particle> coke: what do you think about a script that generates MANIFEST from svn??
<particle> could we use it to remove MANIFEST?
<pmichaud> don't we already have one?
<pmichaud> isn't that what mk_manifest_and_skip does?
<DietCoke> yes.
<pmichaud> particle has a good point then -- why not just do that at release time instead of in every ci?
<DietCoke> I think particle might mean as a post-commit hook.
<particle> not post-commit hook
<DietCoke> don't ask me. I already opened the MANIFEST must die ticket years ago.
<particle> svn del MANIFEST
* barney never understood what MANIFEST in the repos is used for
<pmichaud> I think we do a MANIFEST check only if DEVELOPING doesn't exist.
<pmichaud> (in configure)
<DietCoke> no, the manifest check is done all the time.
<DietCoke> it's VERY noticable on windows, for example. =-)
<pmichaud> right, I think we *should* do a MANIFEST check only if DEVELOPING doesn't exist.
<pmichaud> otoh, having a manifest check is nice to make sure you got a complete svn checkout
<particle> how about a makefile target to generate MANIFEST if it doesn't exist
<pmichaud> particle:  still skipping the configure check?
<pmichaud> because at the time Configure.pl runs, Makefile doesn't exist.
<particle> yes, but reconfigure could check it
<pmichaud> how about if Configure generates a MANIFEST, and makefile checks it
<pmichaud> or Configure generates a MANIFEST if it doesn't exist
<pmichaud> and then does a normal manicheck
<pmichaud> or....
<particle> if perl Configure.pl --release generated MANIFEST, and make release checked it, that'd be great
<pmichaud> particle:  there have been sometimes where MANIFEST has let me know that some needed file is missing from my repository
<barney> pmichaud: I'm happy with 'svn status', showing the state of the checkout
<pmichaud> s/repository/working copy
<pmichaud> barney:  sure, but if I'm doing make realclean; perl Configure.pl; make    and some file is missing from the repo, I might not notice it.
<particle> pmichaud: there have been times when MANIFEST has let me know that somebody has added a file to his working copy but hasn't checked it in yet after they regenerated MANIFEST
<pmichaud> otoh, something probably wouldn't build, either, so...
<particle> there are false positives and false negatives
<pmichaud> particle: in other words, you're saying that someone added a file to working copy, regenerated MANIFEST, and checked in MANIFEST but not the other file
<particle> yes
<particle> i'm working on two changes
<pmichaud> yes, I have that situation too.
<particle> one, i'm ready to commit
<particle> yep
<pmichaud> what can't "make release" generate MANIFEST ;-)?
<pmichaud> i.e., why would perl Configure.pl --release have to do it?
<particle> in order to do the config checking
* pmichaud checks 'make release'
<particle> but, heck, make release can run reconfigure --step=manicheck
<particle> or whatever it's called
<particle> some tests do rely on MANIFEST being around, iirc
<particle> so there will be breakage, but it should be fixable
<pmichaud> okay, I suggest a different approach
<pmichaud> simply have the Configure.pl step make a MANIFEST if DEVELOPING exists
<pmichaud> but leave MANIFEST in the repo
<particle> huh?
<pmichaud> the only time that MANIFEST is a really a problem is when using Configure.pl
<particle> we need manifest when developing *doesn't* exist
<pmichaud> *make* a manifest
<pmichaud> not check it
<pmichaud> you just said that some tests do rely on MANIFEST being around
<pmichaud> so, let Configure.pl create it if we're in an svn checkout
<DietCoke> MANIFEST is used for a ton of things, yes.
<pmichaud> that way it'll be up-to-date
<pmichaud> and it'll get committed at the next ci
<DietCoke> (distro tests, coding standard tests...)
<pmichaud> (if there are any changes)
<particle> well, it means that you can't do 'make test' reliably without Configure.pl
<pmichaud> but it won't carp if someone is working from an SVN repo and the current MANIFEST is incorrect
<particle> because MANIFEST will be out 
<particle> out-
<particle> aargh
<DietCoke> we also have to consider whether or not we're supporting dev outside of svn.
<particle> *out of date
<DietCoke> http://rt.perl.org/rt3/Ticket/Display.html?id=41386
* ambs . o O ( spammers )
% cjfields has left cjfields!~cjfields@newrad.igb.uiuc.edu
<DietCoke> so if you want to resurrect this thread, actually resurrect *this thread*. =-)
% sjansen has left sjansen!~sjansen@64.207.31.107
<pmichaud> the following tests appear to depend or use manifest
<pmichaud> 6 tests in t/configure/
<pmichaud> doc/pod.t
<pmichaud> native_pbc/number.t
<pmichaud> all of the tests in t/manifest/
<pmichaud> t/codingstd/gmt_utc.t
<pmichaud> t/codingstd/pod_todo.t
<pmichaud> t/codingstd/linelength.t
<pmichaud> t/codingstd/perlcritic.t
<pmichaud> codingstd/filenames.t
<pmichaud> t/distro/manifest.t  t/distro/file_metadata.t
<pmichaud> a couple of tests in t/steps/
<pmichaud> that's all.
<DietCoke> google++
<ambs> google++ # units conversion
<nopaste> "barney" at 84.58.148.48 pasted "weird difference between say and print" (17 lines) at http://nopaste.snit.ch/13147
<DietCoke> does one have a newline? <duck>
<DietCoke> yup. given the completely different code paths there, that's not entirely surprising.
<DietCoke> i'd open a ticket on it, though, because it still seems wrong.
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
% braceta has joined #parrot
% davidfetter has joined #parrot
* barney created ticket RT#55196
% smash has joined #parrot
<smash> hello everyone
<davidfetter> oi, smash 
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
<smash> wasn't Configure.pl suposed to pick up and create Makefiles for new languages added via tools/dev/mk_language_shell.pl ?
<DietCoke> it creates the root.in; you might have to rerun the config step to gen the actual makefile. mebbe.
<DietCoke> "should"
<purl> "should" is, like, maybe putting it a little strongly, but who cares
<smash> correct
<smash> i did all that, still no makefile
<pmichaud> no, Configure.pl doesn't do that
<pmichaud> mk_language_shell.pl doesn't do anything to modify the Configure.pl system
<DietCoke> configure.pl doesn't create a makefile? when did that change?
<pmichaud> Configure.pl only creates makefiles for the languages it's told to create makefiles for
<pmichaud> as given by config/gen/makefiles/languages.in, I think
<pmichaud> mk_languages_shell doesn't modify that list.
<smash> last time i used mk_language_shell.pl i only had to rerun Configure.pl and make on the new language
<DietCoke> oh. the shell is deficient and doesn't update the global lgnaugaes target?
<pmichaud> well, I could be wrong about that, then.
<pmichaud> I don't think the shell should update the global languages target.
<smash> pmichaud: i'm not 100% sure either
<pmichaud> not unless we know that the newly created language is also going to be committed into the repo
<pmichaud> the last step in mk_language_shell is      system("$reconfigure --step=gen::languages --languages=$lclang");
<pmichaud> that cause the Makefile to be automatically created
<pmichaud> but it doesn't cause Configure.pl to do it if re-run again.
<pmichaud> (I don't think it does that.)
<pmichaud> similarly, using mk_language_shell to create a language and then executing "make realclean" from Parrot root doesn't realclean the language shell, because Parrot's Makefile doesn't know about it.
<pmichaud> this all comes from a philosophy that there should be less coupling between Parrot's build system and the languages, not more.
<DietCoke> yes, but fixing it in pieces is confusing.
<DietCoke> the coupling is already there, and we're not hooking into it.
<pmichaud> because the hooks are very fragile/poor
<pmichaud> mk_language_shell just gets you a directory and gets you started
<pmichaud> it does not add the directory to the repo
<pmichaud> it does not add files to MANIFEST
<pmichaud> it does not update the Configure.pl targets (because then we'd want an equivalent abandon_language_script)
<pmichaud> (and we don't want a "svn commit" to accidentally check in Configure.pl that contains targets for a language that is not in the repo)
% sjansen has joined #parrot
<smash> bah
<smash> if you specify the language path it *won't* create you the makefile
<smash> that system line is under an unless ($ARGV[1]) {
<pmichaud> right, because the gen::languages step is useless unless the directory is languages/something
<dalek> r28038 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] added some basics for a dod run function. Mostly comments explaining what I would like to do and what I don't know how to do.
<pmichaud> gen:languages doesn't know how to do anything else.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28038
<DietCoke> putting all the steps necessary to add it to the repo seems like a good idea, even if we disagree about when it should be run.
<smash> yes, but you can alwasy specify languages/something
<smash> *always
<pmichaud> you're welcome to improve the script.  Just don't break it.  :-)
<smash> hehe
<smash> better way to run it is plain: $ perl tools/dev/mk_language_shell.pl Foo
<smash> that way you get the makefile and are good to go
<DietCoke> if I don't make it back for PS tomorrow, one of the usual suspects please stand in for me.
% DietCoke has left DietCoke!~coke@cpe-72-228-52-192.nycap.res.rr.com
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167934907.dsl.bell.ca
<smash> "After populating the language directory, the script attempts to
<smash> run tools/dev/reconfigure.pl "
<barney> I won't make it to PS tomorrow, Frankfurt.pm meeting,   Nothing to report.
<smash> _only_ if you don't specify the 2nd argument !!
% cjfields has joined #parrot
<dalek> r28039 | bernhard++ | trunk:
<dalek> : #54148: [NEW] Add tools/util/dump-pbc.pl (weave PIR source and PBC disassembly)
<dalek> : Add testscript tools/util/dump_pbc.pl with a sanity test.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28039
<dalek> r28040 | smash++ | trunk:
<dalek> : [dev/tools]
<dalek> :  * don't wonder why makefiles are not created no more
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28040
% barney has left barney!~bernhard@dslb-084-058-148-048.pools.arcor-ip.net
* smash &
% jan has left jan!~chatzilla@bdv75-4-82-226-115-243.fbx.proxad.net
% cjfields_ has joined #parrot
% jan has joined #parrot
% braceta has left braceta!~Braceta@adsl-b3-196-185.telepac.pt
% cjfields has left cjfields!~cjfields@newrad.igb.uiuc.edu
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
% Auzon has joined #parrot
% cjfields_ has left cjfields_!~cjfields@cjfields.igb.uiuc.edu
% rdice has joined #parrot
% jhorwitz has left jhorwitz!~chatzilla@96.245.16.45
% japhb has left japhb!~geoff@76-191-190-8.dsl.static.sonic.net
% davidfetter has joined #parrot
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% japhb has joined #parrot
% paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net
% Theory has left Theory!~Theory@207.173.77.239
% cjfields has joined #parrot
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-201-161.dynamic.mnet-online.de
% Andy has left Andy!~AndyL@host3130.follett.com
% kid51 has joined #parrot
% Limbic_Region has joined #parrot
* jonathan is back from Vienna
% cjfields has left cjfields!~cjfields@cjfields.igb.uiuc.edu
<kid51> jonathan:  Do you sometimes wake up and wonder which country you're in?
<jonathan> kid51: Yes.
<jonathan> However, Vienna is only 1 hour from here...I live very near to the Austrain border.
<kid51> ... and where do you live, so to speak?
<jonathan> Bratislava, capital of Slovakia.
<kid51> Ah, but IIRC you're from the UK?
<jonathan> Yes.
<kid51> Well, then you're the first Slovak I've ever met
<jonathan> First person living in Slovakia. ;-)
% teknomunk has joined #parrot
<jonathan> But yeah, it's a less usual place to go and live.
<kid51> Did you originally move there for work?
* kid51 has reached the point in life where he's beginning to regret having worked in only one country.
<kid51> ... and, for the most part, in one city.
<kid51> But we don't have EU passports here.
<jonathan> I work from home, so I can live pretty much wherever, though being outside of Europe would be tricky for time-zone reasons.
<Limbic_Region> well, I have lived and worked in various places in the US - but only lived/worked outside the US in S. Korea (1.5 years)
<jonathan> Here is well located for getting to a lot of the rest of Europe.
<jonathan> I've generally been quite fond of central/east europe, fancied trying to learn a Slavic language and was pretty taken by Bratislava when I visited, so I figured I'd come hre for six months and see how it goes.
<jonathan> If I get to like it, I'll likely stay for a while.
<jonathan> And yes, EU makes it very easy to do things like this. :-)
<Limbic_Region> what is the work visa situation - do you have to pay local taxes?
* Limbic_Region should have waited
<kid51> jonathan:  Yes, particularly since the east-to-west span of what is thought of as 'Europe' has expanded so much since 1989
<Eevee> that is definitely cool
<jonathan> There's no work visa, since it's all EU.
<Eevee> although alas you are the *second* person living in slovakia I know of
<jonathan> Taxes - gets fun, but the countries are all in tax agreements such that if the UK and Slovakia thought they should tax me, then I can count the smaller tax bill paid in one country as a write-off against the other.
<kid51> Anyone on channel now who was a Mac with 10.5 on intel?
<jonathan> pmichaud: ping
% Zaba has joined #parrot
% mire has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% mire has left mire!~Frodo@19-169-222-85.adsl.verat.net
% sjansen has left sjansen!~sjansen@64.207.31.107
% tetragon has joined #parrot
% scrottie has joined #parrot
<scrottie> pmichaud, if you don't mind, /msg me or find me on #moose if you wake up and see this.
% rdice has joined #parrot
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
% Theory has joined #parrot
% ank has joined #parrot
% mj41 has left mj41!chatzilla@pc-jurosz.ro.vutbr.cz
% ank has left ank!~ank@ppp121-44-210-24.lns1.hba1.internode.on.net
% ank has joined #parrot
% AndyA has left AndyA!~andy@82.152.157.85
% AndyA has joined #parrot
% bacek_ has joined #parrot
% workbench has left workbench!~workbench@adsl-068-213-211-142.sip.bct.bellsouth.net
% workbench has joined #parrot
% bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au
% bacek_ has joined #parrot
<bacek_> morning everyone
% japhb has left japhb!~geoff@208.201.228.107
% kid51 has left kid51!~jkeen@pool-70-107-11-27.ny325.east.verizon.net
% japhb has joined #parrot
% smash has left smash!~smash@gil.di.uminho.pt
<cotto_work> pmichaud++ for the P6object post
<scrottie> pmichaud-- # for being an idle-butt
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
% TiMBuS has joined #parrot
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
<dalek> r28041 | coke++ | trunk:
<dalek> : [codingstd]
<dalek> : make t\codingstd\trailing_space pass.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28041
<cotto_home> karma pmichaud
<purl> pmichaud has karma of 1324
<cotto_home> seen scrottie 
<purl> scrottie was last seen on #parrot 1 hour and 50 minutes ago, saying: pmichaud-- # for being an idle-butt 
<cotto_home> karma pmichaud
<purl> pmichaud has karma of 1324
<ank> karma police
<purl> Arrest this man!
<cotto_home> (karma police)++
% cjfields has joined #parrot
% cjfields has left #parrot
% niteice has joined #parrot
% tetragon has left tetragon!~seneca@69-196-141-26.dsl.teksavvy.com
% tetragon has joined #parrot
<Infinoid> karma chameleon
<purl> It comes and goes.
<Auzon> instant karma?
<purl> Auzon++
<Auzon> woah
<Infinoid> JIT karma
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<cotto_home> test #9 in t/examples/tutorial.t is failing
<dalek> r28042 | coke++ | trunk:
<dalek> : [docs] point more accurately at LWN
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28042
% nopaste has left nopaste!~opaste@202-154-105-237.people.net.au
% TonyC has left TonyC!~tony@202-154-105-237.people.net.au
% TonyC has joined #parrot
% nopaste has joined #parrot
<nopaste> "bacek" at 211.29.157.151 pasted "Fix of List.reduce for pmichaud to commit" (35 lines) at http://nopaste.snit.ch/13148
% tetragon has left tetragon!~seneca@gw-312-705.somanetworks.com
% jan has left jan!~chatzilla@bdv75-4-82-226-115-243.fbx.proxad.net
% uniejo has joined #parrot
<nopaste> "bacek" at 211.29.157.151 pasted "Refactored version List.reduce for pmichaud to review." (103 lines) at http://nopaste.snit.ch/13149
% scrottie has left #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% UltraDM has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot