% barney has joined #parrot
% masak has joined #parrot
% verve has left verve!a5847f73@67.207.141.120
% leo has left leo!lt@feather.perl6.nl
% leo has joined #parrot
<dalek> r29839 | bernhard++ | trunk:
<dalek> : [codingstd] Fix POD.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29839
% bacek has left bacek!~bacek@mcas-151.usr.optusnet.com.au
% donaldh has joined #parrot
<jonathan> morning all
<purl> afternoon, jonathan
<jonathan> Rakudo day! :-)
<moritz> YaY
<jonathan> Just gotta re-bandage my leg, then I'll get down to work. :-)
<moritz> rakudo approaches the 2000 passing test mark
<Casan> morning jonathan, keep fighting there.
<moritz> and with working IO we might hit the 2000 today if Auzon++ manages to get the regex tests running ;)
<donaldh> oooh, working IO
<masak> jonathan++ # rakudo day!
<jonathan> (hitting 2000)++
% Ademan has joined #parrot
% kj has joined #parrot
<jonathan> Hmm. Fixing IO iterator is trickier than it first appears. :-|
<moritz> jonathan: it would already help to have $handle.eof working
<jonathan> moritz: That can be done. It's not that I can't make for =$fh { ... } work, it's that I can't do it without breaking one other spec-test.
% barney has left barney!~bernhard@p549A3839.dip0.t-ipconnect.de
% ruoso has left ruoso!~ruoso@201009046064.user.veloxzone.com.br
<jonathan> moritz: my $fh = open "README"; while !$fh.eof { say =$fh }; $fh.close(); # now works
<jonathan> If the changes for that haven't broken any tests (shouldn't have), I'll ci.
<moritz> jonathan++
<jonathan> moritz: I'm thinking if you have two file handles $fh1 and $fh2, you should be able to write things like for =$fh1, =$fh2 -> $x { say $x }
<jonathan> To iterate through both of them.
<jonathan> Does that fit with your understanding?
<moritz> yes
<moritz> =$fh2 returns a lazy list in list context
<moritz> so you're just iterating over lists
<jonathan> Yeah
<jonathan> We don't really have lazy lists at the moment, though.
<moritz> the iterator cludge is just a premature optimization in the absence of lazy lists
<jonathan> The other thing is that, at the moment, for =$fh { } doesn't actually put the iterator prefix:= returns into list context, but instead calls 'list'(...) to make the list.
<jonathan> However, we can't change that to actually call .list to do list context
<jonathan> Because then for [1,2,3] { } does the wrong thing.
<jonathan> Essentially, we need our own iterator, I think, that iterates any iterators contained immediately in the list we're iterating over.
<jonathan> But in some senses, I guess that'd make for a big chunk of lazy lists. :-)
<moritz> why not just let =$fh return a list of all items, and do the optimizations once we have lazy lists?
<jonathan> The problem is that =$fh is context sensitive
<moritz> and we have no contexts yet
<jonathan> If I make it return a list of all items, then I break =$fh
<jonathan> We do.
<dalek> r29840 | jonathan++ | trunk:
<dalek> : [rakudo] Implement .eof on file handles, and make IOIterator do something closer to the write thing in item/string contexts.
<moritz> do we? can a sub determine its context? how?
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29840
<jonathan> OK, we don't have *this* piece, but we do have .item, .list and .hash.
<jonathan> And $(...), @(...)...
<moritz> but as long as a sub can't determine its context it feels a bit like fake ;-)
% Whiteknight has joined #parrot
% TiMBuS has left TiMBuS!~Hurf@123-243-167-27.static.tpgi.com.au
% tuxdna has left tuxdna!~tuxdna@122.163.239.166
% lurker has joined #parrot
% Ademan has left Ademan!~dan@h-67-101-42-129.snfccasy.dynamic.covad.net
<nopaste> "moritz" at 89.13.199.231 pasted "IO.eof - wtf?" (19 lines) at http://nopaste.snit.ch/13684
<moritz> jonathan: is that "works as designed"?
<jonathan> moritz: Works as Parrot is designed, perhaps... ;-)
<jonathan> I'd have expected it to not have the final line either.
<dalek> r29841 | jonathan++ | trunk:
<dalek> : [rakudo] Make self work in nested lexical scopes in a method.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29841
% ruoso has joined #parrot
% lurker has left lurker!~chatzilla@clq70.neoplus.adsl.tpnet.pl
% timbunce has joined #parrot
% timbunce has left timbunce!~timbo@86-41-197-131.b-ras1.lmk.limerick.eircom.net
<jonathan> OK, time for me to have some lunch, and then I have Slovak class, then I'm back for the rest of the day/evening hacking on Rakudo.
% pancake has joined #parrot
<pancake> io
<pancake> i have generated a callgrind graph of parrot running a perl6 hello world
<pancake> this can maybe help to find the bottlenecks
<pancake> http://news.nopcode.org/callgrind.out.7299.gz
<pancake> gunzip + kcachegrind <file>
<moritz> pancake: ERROR 403: Forbidden.
<pancake> ^R
<moritz> works now
% donaldh_ has joined #parrot
% donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com
% donaldh_ is now known as donaldh
% rurban_ has joined #parrot
% rurban has left rurban!~chatzilla@212-183-48-157.adsl.highway.telekom.at
% rurban_ is now known as rurban
<dalek> r29842 | coke++ | trunk:
<dalek> : [tcl] revert patch, use 'String' as our object's base class once more to avoid problems. Leave a note.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29842
<dalek> r29843 | coke++ | trunk:
<dalek> : [tcl] use our list PMC preferentially, even internally.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29843
% iblechbot has left iblechbot!~iblechbot@94.17-dial.augustakom.net
% gryphon__ has joined #parrot
<dalek> r29844 | coke++ | trunk:
<dalek> : [tcl] Convert internal usage of String, Integer to tcl PMC variants.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29844
% paco has joined #parrot
* jonathan returns
<jonathan> pmichaud: Awake/around yet?
% iblechbot has joined #parrot
% uniejo has left uniejo!~uniejo@193.88.64.250
<masak> are heredocs in STD.pm?
% AndyAway has left AndyAway!~AndyL@host3130.follett.com
<moritz> masak: yes, think so
<masak> ok
<moritz> token ws { ... | <.vws> <.heredoc> }
<masak> the need for them in rakudo isn't pressing (since multiline strings work fine) but would be a nice addition
<masak> so heredocs are parsed as whitespace?
<moritz> I think it's best to wait for the Big Grammar Refactor
% gmansi has left gmansi!~gmansi@190.55.38.59
% Andy has joined #parrot
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-207-49.dynamic.mnet-online.de
% gmansi has joined #parrot
<masak> moritz: so, tell me more about this Big Grammar Refactor? :)
<masak> does it hurt?
% gmansi has left gmansi!~gmansi@190.55.38.59
<moritz> yes ;-)
<moritz> masak: the following is 80% speculation...
<moritz> masak: TimToady refactored STD.pm to handle DSLs by copying the grammar, and modifying the copy
<moritz> masak: and since rakudo's grammar follows STD, it might do the same thing
<masak> aha
<moritz> masak: also, STD.pm is based on proto regexes, rakudo on simple alternation
<moritz> pmichaud already announce that he *will* change that
<masak> I've heard the term "proto regexes" before, but I don't know what they are
% gmansi has joined #parrot
<moritz> it's a bunch of regexes with the same name, but parameterized by a symbol
<moritz> and they match as an alternation
<moritz> so multi foo:sym<a> { <sym> }; multi foo:sym<b> { <sym> }; makes '<foo>' match a|b
<moritz> with the small difference that you can add alternatives simply by subclassing, and adding more methods /tokens / whatever
<dalek> r29845 | jonathan++ | trunk:
<dalek> : [rakudo] Implement get_bool vtable method in Object, such that it tests definedness. This means things like 'ok Foo.new' used in some spectests can work.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29845
<moritz> s/multi/multi token/ actually
<moritz> and it means that you can modify a symbol without altering the parse tree, for example you can say multi:sym<a> { 'c' } # it looks the same in the parse tree, because foo:sym<a> matched, but it actually matched c and not a
<pmichaud> pong
<jonathan> pmichaud: hi! :-)
<jonathan> pmichaud: I'm ready to discuss/work on refactoring variable declaration or type registry, if you're free to discuss that first.
<particle> 76/142
<purl> 0.535211267605634
<jonathan> pmichaud: Also, got a couple of smaller questions/issues.
<particle> wow. parallel branch runs configure tests in half the time
<jonathan> particle: On Win32?
<particle> ayep
<jonathan> Nice!
<donaldh> schweet.
<particle> i'm formulating a mail for the list
<pmichaud> smaller questions/issues might be better first
<jonathan> OK
<jonathan> First, just trying to get some of the delegation tests (for handles) to pass. Already handles is implemented, so we can cover some of the cases, but running into a couple of other things the test exercises.
<jonathan> The first one is that if you do "ok !try{ something that dies }", if what's in try dies then you get a null PMC exception.
<jonathan> Because the block never returns a value.
<jonathan> I'm not seeing an especially neat way to deal with this.
% cjfields has joined #parrot
<pmichaud> try needs refactoring anyway
<pmichaud> I'm kinda waiting for the new exceptions stuff before going too far with that.  But we might be able to fix it earlier.
<pmichaud> but actually { something that dies }  should probably return a Failure object
<jonathan> Well, it never gets chance, is the real issue.
<pmichaud> -or-
% jhorwitz has joined #parrot
<pmichaud> try should detect that it didn't get something back from the block, and generate a failure object
<nopaste> "donaldh" at 144.254.89.228 pasted "patch for t/doc/pod.t on Cygwin" (23 lines) at http://nopaste.snit.ch/13689
<donaldh> Does anyone want to give ^ a try on another platform?
<jonathan> pmichaud: I'm trying the second of those...and failing to find the correct incantation. :-Z
<donaldh> The test was complaining on Cygwin because -e pbc_to_exe returns true when pbc_to_exe.exe exists
<pmichaud> jonathan: where does the null PMC arise, exactly?  The argument to prefix:! ?
<jonathan> Yes
<jonathan> Ah
<Infinoid> donaldh: trying on linux/amd64
<pmichaud> well, if an exception occurs, then we know we get into the catch portion of the 'try' PAST node
<donaldh> Infinoid++
* moritz tries on linux/i368 (32 bit)
<pmichaud> try should then wrap the exception into a Failure object and return it.
<moritz> but the byte lenght shouldn'T make a difference
<jonathan> Yes, but assigning something back to the register that the result of the block woulda been assigned to, is the tricky bit.
<pmichaud> ....?
<purl> dot dot dot *yawn* dot
<pmichaud> you lost me there
<donaldh> Infinoid: I have simplified the test to use -T instead of -e & -B & an additional check for $file . $PConfig{exe}
<jonathan> $P23 = "_block16"()
<jonathan> We have no way, that I can see, to refer to $P23 inside the catch PIR.
<Infinoid> donaldh: doesn't seem to break the test here
<pmichaud> oh, I think you're just saying that PAST's 'try' block needs better return value handling
<Infinoid> passes without the patch, passes with the patch.
<pmichaud> which is entirely possible.
<jonathan> That would probably be the easiest solution.
<donaldh> Infinoid: I'd expect that ;-)
<moritz> donaldh: second test fails with 568 files without DESCRIPTION - is that intended?
<donaldh> Always did I think.
<pmichaud> I wasn't dealing with try blocks as rvalues when I wrote the original 'try' code, I don't think.
<jonathan> Aha, OK.
<donaldh> I'm not really up for posting a patch to 568 files ;-)
<pmichaud> but the entire fail/try/exception system needs a bit of a rework
<moritz> uhm, why not? ;-)
<donaldh> s/posting/pasting/
<Infinoid> if you can't paste, post :)
<jonathan> Would you rather we just leave this until the re-work post-pdd25cx?
<pmichaud> I might be able to get that later today
<jonathan> OK.
<pmichaud> it's not a hard fix
<moritz> donaldh: ah, it's marked as TODO, I haven't seen that
<donaldh> phew.
<jonathan> OK, sounds good.
<jonathan> I also tried to get file I/O in better shape. When various refactors were done, for =$fh { ... } got broken.
<jonathan> Notably, because for now calls list(...)
<jonathan> Which is probably right, but doesn't play out too well, since we get a list with one element, which is an iterator.
<cjfields> how far off are lazy lists?
<jonathan> I tried switching it to call .list, so we get a value there in list context. Then the IO iterator could just return itself in .list.
<pmichaud> no, .list would be wrong.
<jonathan> But then for [1,2,3] { } fails.
<jonathan> Yes.
<jonathan> I found that out. :-)
<pmichaud> short-term fix would be to update flatten to recognize IOIterator, the way it currently does Ranges (which are also lazy)
<jonathan> Would that not mean we flatten the entire iterator?
<jonathan> (Works for reading from files, not so well from $*IN)
<jonathan> (flatten the entire iterator = read from it...)
<jonathan> (read everything from it)
<pmichaud> checking.
<pmichaud> no.
<pmichaud> Currently the flatten code calls .list on Range objects
<pmichaud> I don't think it actually flattens the Range object.  (The .list method on Range might do that, but the flatten code doesn't do it)
<pmichaud> so, if flatten encountered an IOIterator, then it would call .list on it
<jonathan> The .list method on Range does.
<moritz> we just need freakin' lazy lists for it, and we need the pdd25cx branch for that
<jonathan> (does flatten it)
<jonathan> So we'd boil down to the same thing - it'd work for files (though we'd end up reading the lot before we started looping), but would hang for $*IN.
<jonathan> OTOH, it doesn't work at all at the moment...
<particle> PLEASE TEST THE PDD25CX BRANCH. submit results to the ticket allison posted.
<pmichaud> ..."hang for $*IN"
<pmichaud> ?
<jonathan> pmichaud: for =$*IN { .say }
<particle> also test hlls with that branch. it'll help it get merged faster.
<pmichaud> oh, I see.  okay.
<dalek> r29846 | infinoid++ | trunk:
<dalek> : [t] Apply patch from donaldh++ to fix a test on cygwin.
<dalek> : (-e pbc_to_exe is true for pbc_to_exe.exe on cygwin, which confuses the test)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29846
<jonathan> If you are calling .list, this will try and get all values from the iterator...but it never gets to eof.
<jonathan> The other thing that occured to me, is we could just implement our own iterator, which I guess we'll need to do anyway as part of the lazy lists work, that can iterate over an iterators it immediately finds occuring in the list.
<moritz> donaldh++
<jonathan> s/an/any/
<pmichaud> jonathan: I think that's just a lazy list.  :-)
<donaldh> What's on the pdd25cx branch?
<jonathan> pmichaud: Yeah, we'd have done a good part of lazy lists by then, I guess. ;-)
<pmichaud> does lazy lists require pdd25cx ?
<jonathan> Though of course, not for indexing into them.
<jonathan> I didn't know of any lazy list dependency on pdd25cx.
<pmichaud> me either.
<jonathan> gather/take may require pdd25cx
<moritz> donaldh: reworked dependency branch
<pmichaud> yes, gather/take requires pdd25cx
<jonathan> But lazy lists more generally don't.
<jonathan> Hmm. I'm tempted to JFII.
<pmichaud> so lazy implementations of some functions will require gather/take
<moritz> then I was wrong - if I had to implement lazy lists, I'd do most if it with gather /take
<jonathan> OK, but to get file handles and ranges lazy on iteration, is a smaller and easier step.
<jonathan> Well, ranges needn't change for now - file handles are what really needs this.
<dalek> r29847 | moritz++ | trunk:
<dalek> : [rakudo] add more IO tests to spectest_regression 
<dalek> : most of them are TODO right now
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29847
<jonathan> Ooh, moritz++
<jonathan> moritz:  S16-io/basic-open.
<jonathan> Missing a t?
<moritz> jonathan: yes, will fix
<dalek> r29848 | moritz++ | trunk:
<dalek> : [rakudo] fixed typo in spectest_regression.data, moritz--, jonathan++
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29848
<pmichaud> I'm thinking about how lazy lists will end up working with ResizablePMCArray
<jonathan> In the sense of, is it an "isa" or a "has a"?
<pmichaud> in the sense of -- how do we make sure everything works correctly when Parrot hands us an RPA instead of a List
<pmichaud> (e.g., :slurpy)
<jonathan> Could we have a case where that happens and we have an iterator in the list that we should be iterating?
<particle> pmichaud: how is that lazy?
<particle> RPAs aren't lazy, i mean
<jonathan> If not, get_iter on ResizablePMCArray can just return its iterator, we iterate it, and it works out, I think.
<pmichaud> particle:  RPAs aren't lazy, correct.  That's why it's a problem.
<pmichaud> if we get an RPA with lazy elements, we can't just return those elements
<jonathan> True - will that conceivably happen?
<particle> oh, yeah, you'll probably have to override get_iter
<pmichaud> jonathan: sure, anytime we use :slurpy
<particle> mixin a role for that
% davidfetter has left davidfetter!~davidfett@start.fetter.org
<jonathan> Ah, like we get something like sub foo (*@foo) { ... }; foo(1..10, 20..Inf)
<pmichaud> I've been wanting to get .HLL type mapping working, so that Parrot would at least give us a List instead of an PRA
<pmichaud> *RPA
<jonathan> Yes, but that's blocking on various things, IIRC.
<pmichaud> other possibility might be to generate code to recast all slurpy params into Lists explicitly.  But I'm not sure that will be very robust -- quite a few might slip through the cracks.
<pmichaud> oh, it might work out if we just implement a separate .list and/or .iterator method for RPA
<pmichaud> that returns what we want.
<jonathan> .sub 'iterator' :vtable('get_iter')
<jonathan> That'd probably work.
<pmichaud> we have to be *very* careful about trying to override get_iter in RPA
% sjansen has joined #parrot
<pmichaud> because we'd be doing that for all of Parrot, not just Rakudo.
<jonathan> Ah, yes. :-|
<jonathan> http://rt.perl.org/rt3/Ticket/Display.html?id=49812 only has http://rt.perl.org/rt3/Ticket/Display.html?id=56650 as a dependency.
<pmichaud> it's the same problem we have with overriding get_string in Object
<jonathan> Does that mean that the second of those is the only blocker to being able to use .HLL?
<pmichaud> no
<pmichaud> p6object still needs its refactor.
<jonathan> OK, but I meant Parrot guts issue.
<pmichaud> I'm not sure if HLL type mapping is working yet for :slurpy
<pmichaud> Coke had a ticket about that recently.
<jonathan> HLL map of :slurpy's ResizablePMCArrayresolved
<jonathan> It's marked resolved as of 13 days ago.
<pmichaud> ticket number?
<jonathan> 56958
<pmichaud> looks like there might
<pmichaud> be other issues with non-PMC classes, but that's a different test and a
<pmichaud> different RT.
<pmichaud> (quote from ticket)
<jonathan> Ugh.
<jonathan> If we can't use non-PMC classes in the HLL_map, it's a tad useless to us.
<pmichaud> so, we could at least use a test for that for now.  :-)
<pmichaud> just a sec, I'm distracted going over itinerary details for tomorrow's travels
<jonathan> ok
<particle> jonathan: we don't need to do much to get a semantic analysis phase in rakudo (re: 57336)
<particle> heck, we're doing some semantic analysis inside the parse->past code now
% rdice has joined #parrot
<pmichaud> parse->past is the semantic analysis, isn't it?  ;-)
<particle> hi ho richard!
<particle> how's life with baby?
<jonathan> I suspect it'd be useful, to have a second "CHECK" phase, rather than tyring to clump it all into one. :-)
<particle> yeah
<particle> very easy to do
<moritz> TGE for PAST-nodes?
<particle> we can use nqp
<jonathan> OK, great.
<particle> see perl6.pir:44
<pmichaud> wait, I'm confused.
<pmichaud> okay, I de-confused myself.
<pmichaud> I'm not convinced I like the second "CHECK" phase, though.
<pmichaud> but I haven't thought about it that much yet.
<pmichaud> but "second CHECK phase" sounds wrong to me.
<particle> i want a phase for tree-ssa, but that might be after past
<pmichaud> ...tree-ssa?
<particle> tree based static single assignment
<particle> gcc does it
<pmichaud> ...what is that?
<particle> their tree language is called 'gimple' i think
<particle> ssa tracks assignments of variables
<particle> it's an optimization strategy
<particle> lemme get you a link
<pmichaud> does it work in a dynamic language?
<jonathan> pmichaud: SSA is a form where you re-arrange code into a format where a variable/register is only ever assigned to once, which makes certain types of analysis (that can in turn lead to optimization) easier.
<particle> http://gcc.releasenotes.org/summit/2003/Tree%20SSA%20-%20A%20New%20optimization%20infrastructure.pdf
<particle> yes, it's good for dynamic languages
<jonathan> That is, you don't actually emit the code like that, but you get a tree representing it in such a form so you can do such analysis.
<pmichaud> why does this sound premature to me?  ;-)
<particle> i want to add it as an optimization step to pct
<pmichaud> particle:  this week, this month, this year, ...?
<particle> before 1.0
<particle> it's not blocking on anything
<particle> it can happen anytime
<pmichaud> no, but spending tuits on it causes other things to block
<particle> so anybody with tuits can help, if they're not working on anything else
<pmichaud> if we have spare tuits around, then yes, great.  and yes, it belongs in pct.  And that can go in as a separate phase for pct, no problem.
<pmichaud> I thought you were referring to rakudo specifically.
<particle> no
* particle has his parrot hat on
<jonathan> pmichaud: Got a fix for 56650
<jonathan> Smoking it now to make sure, there's no collateral damage.
<pmichaud> okay, great.  We were going to fix it by fixing class creation.
<jonathan> (that is, don't get exicted yet)
<jonathan> I fixed it in init_pmc insdie the class PMC.
<pmichaud> the way that classes get stored in the name registry was messed up.
<pmichaud> it would include the HLL name as part of the class name
<jonathan> Yeah
<jonathan> I fixed that.
<particle> should it always include the hll name, including 'parrot' ?
<pmichaud> for now it should never include the hll name
<pmichaud> otherwise we have a lot of stuff to deprecate and repair
<particle> so how do you tell rakudo's Integer from parrot's Integer?
<pmichaud> there's not currently a way to do that.  That's a different bug
<pmichaud> (looking up ticket number)
<particle> maybe we should have a special marker to signify that namespace keys should be relative to current hll rather than root
<pmichaud> #43419
<pmichaud> I think that what is more likely to happen is
<pmichaud> (1) always use namespaces to refer to classes (no ambiguity)
<pmichaud> (2) use protoobject-based items, and make all HLL classes anonymous
<pmichaud> although #2 is problematic because it's hard to stick methods into an anonymous class
<pmichaud> so what we really end up doing is using mangled names for the HLL-specific classes
<pmichaud> such as Perl6Object, Perl6String, etc.
<jonathan> pmichaud: It passed all tests.
<pmichaud> but at least as PCT/rakudo are currently designed, the HLL never really sees a Parrot class name.
<particle> (sorry, phone)
<pmichaud> jonathan++
* jonathan finally does something successful today.
<pmichaud> yay!
<jonathan> So far I've failed to fix try and failed to fix for =$fh { ... }
<jonathan> Did implement .eof on file handles, though.
<pmichaud> well, let's at least make tickets for those that explain the blockers.
<dalek> r29849 | jonathan++ | trunk:
<dalek> : [core] Fix RT #56650 (class created from namespace fails MMD).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29849
<pmichaud> or add the blocker information to the tickets.
<pmichaud> or make tickets for the blockers, and then link the tickets.
% iblechbot has joined #parrot
% donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com
<jonathan> Do you want me to try and get some custom iterator set up for lists, to try and handle file handles better?
<pmichaud> I think I'd rather just implement lazy lists.
<masak> will 'multi' in a grammar mean 'multi regex' or something, eventually?
<jonathan> OK, I kinda saw doing that as a step towards lazy lists.
<pmichaud> I don't think lazy lists need custom iterators
<jonathan> They need some kind of iterator.
<pmichaud> a list can just clone itself.
<jonathan> OK, in that case the list just is the iterator.
<pmichaud> correct.
* jonathan senses this will be a big refactor.
<pmichaud> we might be able to do a specialized iterator as an optimization, but I see that coming later.
<pmichaud> I think it's not so bad, except for the RPA stuff
% masak has left masak!~user@130.238.45.242
<jonathan> Now the MMD bug is fixed, how far do you think .HLL is?
<pmichaud> not far.  I'll have to re-try my p6object conversion
<jonathan> OK.
<jonathan> So best to wait on lazy lists until .HLL is done, and we're not getting RPAs?
<pmichaud> I think we'll still get RPAs, so .HLL probably shouldn't be a dependency.  Instead we need to figure out how to handle RPAs when we get them.
<jonathan> Hmm.
<jonathan> When we can't reply on an RPA being fully evaluated, that's really tricky.
<jonathan> *rely
<pmichaud> I think the answer is to convert RPAs to Lists when we find them, or at least keep track of when they occur
<jonathan> *nod*
<jonathan> I guess we can only see how well that will work out by giving it a go.
<jonathan> At least once .HLL is in place, we eliminate the primary source of RPAs (from :slurpy)
<pmichaud> the other source of RPAs will be arrays from matches
<pmichaud> although those probably won't be lazy for a while yet
<pmichaud> we need to update the roadmap, and make it a little more detailed
<pmichaud> and identify some of these dependencies
<jonathan> Yes, and probably break down some of the big items too.
<jonathan> * class, role, objects
<jonathan> * regex, token, rule, grammar
<jonathan> Those two are pretty wide-ranging. We have progress on all of them.
<pmichaud> a good thing to do would be to place most of the skip/todo items from spectest regression into the roadmap
<pmichaud> or, at least the major ones
<jonathan> As in, work out why they skip and list the features we need to get them to pass?
<pmichaud> well, most of the skips already have reasonable messages
<pmichaud> (and I've been changing them to reasonable messages when they're incorrect or imprecise)
<pmichaud> but yes, list the features we need to get them to pass.  Perhaps create tickets for them or for the features.
% Andy has left Andy!~AndyL@host3130.follett.com
<jonathan> Hmm. Did we get rid of #pure?
<pmichaud> Schwern submitted a patch that eliminated #pure, yes.
<pmichaud> We couldn't find the reason for it.
<moritz> that slows down autounfudge a bit :/
<jonathan> There goes my easy way of looking through, in one file, which spectests have skips. ;-)
<pmichaud> schwern was arguing for rgrep
<pmichaud> instead of manually maintaining #pure
<pmichaud> even 'ack' ought to be able to do it.
<pmichaud> it's okay to create a tool and/or make target for that
<pmichaud> but a good first approximation is   ack '/\#\?rakudo/' t/spec
<pmichaud> or for just a list of files,   ack -l ...
<pmichaud> and, of course, the way I find skipped tests is to run  tools/test_summary.pl
<jonathan> That's rather useful. :-)
<moritz> but it takes quite some time
<pmichaud> jonathan: your fix to #56650 isn't the approach I was planning to take.
% Andy has joined #parrot
<jonathan> pmichaud: In a, "re-do it another way" kidna way?
<pmichaud> I'm just looking to see if I see any difficulties
<jonathan> OK
<jonathan> What were you planning?
<pmichaud> to fix lines 191-212
<pmichaud> which is where the bug _really_ is.
<jonathan> Hmm
<jonathan> That would work to, I think.
<pmichaud> the problem is when init_class_from_hash gets called with a namespace argumnent
<jonathan> Yes, I see...
<jonathan> OK, done, smoking
<pmichaud> #parrotsketch in 98?
<jonathan> 'twas a vintage year.
<jonathan> pmichaud: Working on making list of features used in spectests to go in the roadmap.
<pmichaud> excellent.
<pmichaud> I'm going to have to run errands in a bit.
<jonathan> OK
<jonathan> I noticed STD.pm has some type registry stuff in it.
<pmichaud> and there is so much background noise in the house at the moment that I'm having trouble concentrating :-(
<pmichaud> (housekeepers, two kids, wife, and dog)
<jonathan> I figure doing something very similar is a good approach.
<jonathan> Plenty of noise-emitters!
<pmichaud> STD.pm has type lookups, does it have anything else?
<jonathan> Two weeks until pre-YAPC hacking. We can find somewhere quiet for that.
<jonathan> It has a sub for putting stuff into the type registry
* particle is back
<jonathan> Which is called from a few places.
<pmichaud> I hadn't noticed that.  what sub?
<jonathan> add_type
<particle> i'm disappointed to see #pure go away without discussion that involved me
<particle> (or moritz)
<jonathan> Oh, actually it's a method.
<jonathan> Though it never touches the invocant, or any attributes, so it may as well have been a sub.
<pmichaud> particle:  it's an easy revert.
<pmichaud> I didn't feel like arguing the point much with schwern.
<pmichaud> especially since I wasn't sure why they were needed either
<particle> well, for example, to run a test as pure even though it has #?rakudo markers in it
<pmichaud> as part of spectest_regression?
<particle> sure, or localtest
<pmichaud> I can't imagine ever wanting to do that in spectest_regression
<pmichaud> afaik we didn't take out the capability to have #pure in localtest
<particle> ok, i haven't reviewed the patch, so i don't know the extent of the changes
<particle> or whether they're right or wrong
<pmichaud> the main point of the patch was to enable   "make t/spec/S29-num/foo.t"
<pmichaud> which runs a single test
<pmichaud> (fudging as needed)
<particle> what does that have to do with #pure?
<pmichaud> why do we need #pure in the first place?
<particle> the idea:
<dalek> r29850 | jonathan++ | trunk:
<dalek> : [rakudo] A different fix for the class created from namespace and MMD bug.
<particle> tests may optionally be marked as #fudge or #pure...
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29850
<particle> the default (for now) is #fudge...
<pmichaud> jonathan: all of the calls to add_sub are doing so on the cursor object, which would seem to be a different method from the add_sub that is in STD.pm
<pmichaud> jonathan: we might need to ask TimToady about that
<particle> but the user can override the behavior of fudge by specifying #fudge or #pure in the .data file.
<pmichaud> particle: how many times have we needed to override the behavior?
<pmichaud> (in spectest_regression.data)
<pmichaud> in localtest.data, I can understand it and fully support it, yes.
<particle> if it's in one data file, why not all?
<jonathan> pmichaud: You mean add_type?
<particle> i'd like to be very specific in spectest_regression. once they're all pure, we don't need fudge
<pmichaud> because in spectest_regression it means we're having to maintain a flag that can be automatically determined
<pmichaud> particle:  but isn't that "make spectest"?
<particle> we don't *need* no specify the flag in spectest_regression
<pmichaud> jonathan: yes, add_type
<particle> oh, wait. did the patch simply remove the flags from the data file?
<pmichaud> particle:  I don't know -- I didn't check that far.
<pmichaud> I know it at least removed the flags from the data file.  I don't know that it removed the flag handling code.
<pmichaud> I don't mind if the flag handling code returns, if that's the case -- as long as we don't break the other testing changes.
<pmichaud> easier still might be to not use flags at all
<particle> fudge is a preprocessor. i don't trust it.
<particle> i want the ability to override
<pmichaud> I don't think we need the ability to override in spectest_regression
<particle> fine with me
<pmichaud> especially if "fudge" is the default
<pmichaud> in localtest.data, I think overriding makes sense
<particle> well, that can be easily changed
<particle> (fudge as default)
<pmichaud> I don't think we'll ever switch spectest_regression from having fudge as its default
% kj has left kj!~IceChat7@193.1.100.105
<pmichaud> if the list of files were known and static, perhaps we might do that, but since we're constantly adding (fudged) test files to _regression, we'll likely keep fudge as the default
<pmichaud> eventually we'll get to the point that either (1) we're no longer adding files to spectest_regression, in which case it's just 'spectest', or (2) we're running things unfudged, in which case it's just 'spectest'.
<particle> depends on the percentage of files that run pure in spectest_regression, i think
<particle> if more run pure, that should be default
% cjfields_ has joined #parrot
% cjfields_ has left cjfields_!~cjfields@cjfields.igb.uiuc.edu
% cjfields has left cjfields!~cjfields@newrad.igb.uiuc.edu
<pmichaud> but fudge already leaves files as 'pure' if there isn't any fudging taking place
<moritz> I liked the pure marking, but I can live without them
<particle> if there aren't any '#?rakudo' markers, it leaves it as pure, yes
<particle> no matter.
<particle> spectest_regression can live without the markers.
% DietCoke has joined #parrot
% DietCoke is now known as DietCoke_afk
<moritz> then we might just as well delete tools/fudge_purity_inspector.pl
<particle> unless we use it for other localtest
% cjfields has joined #parrot
<particle> s/other//
<particle> svn diff -c 29782
<pmichaud> we could certainly modify test_summary.pl to report the fudged/pure tests
<particle> it does remove #fudge/pure mark detection entirely
<pmichaud> feel free to add it back in... but I do like schwern's overall option handling better
<pmichaud> the decision to have global fudge/pure should come from the --fudge option
<pmichaud> if --fudge, then default all tests to being fudged
<pmichaud> if no --fudge, then default all tests to being pure
<particle> there's no way to run a single test without fudge, as schwern has it
<moritz> ../../parrot perl6.pbc path/to/test.t # ;-/
<pmichaud> as I said, feel free to add #pure option back in.  I just don't think we need to maintain the markers in spectest_regression
<pmichaud> and I'd like to avoid adding more options to t/harness
<pmichaud> my suggestion would be to refactor the lines
<pmichaud> if ($do_fudge) { @tfiles = fudge(@tfiles);
<pmichaud> }
% chromatic has joined #parrot
<jonathan> pmichaud: I'm thinking this test is not right:
<jonathan>     my $h;
<jonathan>     sub some_sub_2 ($arg) { $h = $h ~ $arg; };
<jonathan>     for (0 .. 5) { .some_sub_2 };
<jonathan> (we never fall back to a sub any more?)
<pmichaud> correct, method fallback to sub is gone
<pmichaud> (per TimToady at OSCON)
<particle> yep
<pmichaud> actually, it was pre-OSCON, because I even committed a Synopsis patch to eliminate it.
<jonathan> OK
<jonathan> Will eliminate the test.
<pmichaud> there are a lot of those.
<pmichaud> okay, lunchtime for me.
<pmichaud> bb in 56 for #ps
<jonathan> kk
<Tene> ocrap #ps.
<Tene> QUICK I NEED SOME COMMITS
<Tene> svn rm languages/tcl
<moritz> lol
<cotto> you can misspell something and then fix it
<cotto> that'd give you two
<moritz> it would "solve" some of the pdd25cx problems (svn rm languages/tcl)
* DietCoke_afk wonder why everyone always hates on tcl.
% DietCoke_afk is now known as DietCoke
<chromatic> It was a slow Lisp with weirder syntax for a long time.
<DietCoke> ... fine, "partcl"
<Tene> DietCoke: I wasn't picking on tcl, I was picking on you.
<DietCoke> as penance, where's my patch?
<Tene> Um... hey, look, cardinal has a failing test!
<Tene> I should go fix that!
* particle thinks tene owes dietcoke a dinner
<Tene> Well, I will be in NYC in a couple of weeks.
* Infinoid gives DietCoke a free patch
<dalek> r29851 | infinoid++ | trunk:
<dalek> : [tcl] Fix trailing whitespace.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29851
<DietCoke> NYC is a bit of a haul for dinner. =-)
<dalek> r29852 | tene++ | trunk:
<dalek> : [cardinal]
<dalek> : * Track a change in P6Object for calling methods on the metaclass.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29852
<Tene> DietCoke: but it would be *free* dinner!
<DietCoke> You probably don't have anything I can eat. :|
<DietCoke> Infinoid++
<DietCoke> purl, 236.5-205
<purl> 31.5
<DietCoke> purl, 31.5/77
<purl> 0.409090909090909
<moritz> pmichaud, jonathan, particle: anybody motivated to review RT #56700 ?
<Tene> We really need to persuade one of the bots to provide links for ticket numbers.
<Infinoid> I could write a dalek script for that
<DietCoke> someone did that and it was booted as being too spammy, as I recall.
<jonathan> moritz: I think that one has been discussed some, and some PCT changes for namespaces are forthcoming to make this possible.
<DietCoke> (perhaps because it failed spammily)
<Infinoid> was that Whiteknight's bot?
<moritz> jonathan: ok, thanks
<cotto> I thought it was booted for being too spammy for other output
<moritz> another one I'm looking at: RT #57068
<moritz> it seems to duplicate effort, and use '!EXPORT' instead
<nopaste> "Infinoid" at 96.238.213.50 pasted "[PATCH] silence some "switch missing default case" warnings" (88 lines) at http://nopaste.snit.ch/13690
<Infinoid> DietCoke: any objection to that nopaste?  I doubt it adds any value, but it silences some warnings.
<particle> the ticket links exist on the irc log moritz runs, right moritz?
<moritz> particle: yes
<jonathan> moritz: I'm not sure export quite cuts it here, because we want a version that doesn't take a file handle.
<jonathan> But it should probably just look up $*IN and invoke the printf method on that.
<Infinoid> DietCoke: hmm, and causes some test failures.  Guess you're relying on silent passthrough for those switch statements
% pancake has left pancake!~pancake@core.fluendo.com
<DietCoke> Infinoid: where are the failures, t/cmd_binary ?
<Infinoid> lots of places.  far more failures than there were without the patch
<moritz> jonathan: should I just commit the method form, and ask for a re-worked form of the function?
* Infinoid is making a gentler version of the patch :)
<dalek> r29853 | jonathan++ | trunk:
<dalek> : [rakudo] Updates to the ROADMAP, including a list of many smaller tasks that are needed to allow us to skip less tests in spectest_regression.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29853
<DietCoke> ah, many places. (gentler) hokay.
<jonathan> moritz: Yes, or just write it to do get_hll_global '$OUT' and call .printf on the return value.
<jonathan> moritz: Should be less characters to type to change that, than to type them asking for a new patch. ;-)
<DietCoke> anyone looking to play with PCT, a tcl conversion would not be unwelcome. =-)
<DietCoke> (well, a patch. I don't want to lose .HLL yet.)
<DietCoke> bah. nevermind. if you're bored, check the the TODO file. ^_-
<Infinoid> there are a few failing tests here in partcl, even without my patches.  are those known failures?
<Infinoid> or is everything expected to work?
<DietCoke> everything is expected to work.
<DietCoke> What's failing for you?
<dalek> r29854 | coke++ | trunk:
<dalek> : [tcl] use more truth.
<Infinoid> I'll paste that in a moment
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29854
<nopaste> "Infinoid" at 96.238.213.50 pasted "[PATCH] silence some "switch missing default case" warnings (gentle version)" (82 lines) at http://nopaste.snit.ch/13691
<moritz> jonathan: has method fallback been oficially removed yet?
<nopaste> "Infinoid" at 96.238.213.50 pasted "partcl test results (3 failed scripts)" (103 lines) at http://nopaste.snit.ch/13692
<DietCoke> ok. note that the lsort failure is a non-failure.
<DietCoke> the other two, looks like runtime/builtins/join is not compiling for some reason.
<Infinoid> I am doing a fresh build after svn update
<jonathan> moritz: Yes.
<jonathan> 19:32 <@pmichaud> correct, method fallback to sub is gone
<jonathan> 19:32 <@pmichaud> (per TimToady at OSCON)
<DietCoke> Ah. I think I see the problem, and it would depend on a hash ordering, so I can see why it hasn't hit me. moment.
<moritz> so not in the specs yet :/
<jonathan> 19:32 <@pmichaud> actually, it was pre-OSCON, because I even committed a Synopsis patch to eliminate it.
<jonathan> So if there is any remaining references in the synopses, they should be reported.
<moritz> jonathan: I get a test failure in S02-builtin_data_types/range :(
<DietCoke> Infinoid: try now.
<dalek> r29855 | coke++ | trunk:
<dalek> : [tcl] add in missing namespace/HLL directives ; depending on how runtime/builtins.pir gets generated, these could have broken the runtime. (infinoid++)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29855
<dalek> r29856 | coke++ | trunk:
<dalek> : [tcl] don't bother saving the return value if we're never going to look at it.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29856
<moritz> I commited it wihtout change because the duplicate code isn'T really much
<dalek> r29857 | moritz++ | trunk:
<dalek> : [rakudo] implement sprintf. Patch courtesy of Carl Mäsak <cmasak at gmail.com>
<dalek> : masak++
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29857
<jonathan> moritz: Oh? That's odd...
<jonathan> C:\Consulting\parrot\trunk\languages\perl6>perl t\harness t\spec\S02-builtin_dat
<jonathan> a_types\range.rakudo
<jonathan> t\spec\S02-builtin_data_types\range....ok
<chromatic> #ps in 3
<moritz> t/spec/S02-builtin_data_types/range......................Missing '}' at line 168, near ""
<moritz> current instr.: 'parrot;PGE::Util;die' pc 120 (runtime/parrot/library/PGE/Util.pir:82)
<jonathan> Hmm
<moritz> let me try again
<particle> moritz: perhaps remove t/spec and regen?
<Infinoid> DietCoke: looks like cmd_join.t worked, waiting for the rest of it...
<jonathan> moritz: Even doing a clean run of spectest_regression, t\spec\S02-builtin_data_types\range...............ok
<moritz> now cleaning and trying again
<jonathan> And no local patches.
<moritz> perhaps it was a local fuckup
<jonathan> OMFG SWEARING
<jonathan> ;-)
<pmichaud> back
<jonathan> pmichaud: Checked in a bunch of stuff to ROADMAP.
<Tene> OY?G
<Infinoid> DietCoke: all passed, except for the cmd_lsort continuation weirdness.
<DietCoke> ok. that is expected.
<chromatic> #ps time
<DietCoke> (and sadly, not fixed by pdd25cx)
<pmichaud> #56700:  the patch doesn't really follow STD.pm
<Infinoid> assuming they don't break anything, any objection to the (gentler) default cases patch?
<DietCoke> Infinoid: no, removing warnings good.
<Infinoid> great, retesting now.
<pmichaud> I thought we already had sprintf in Rakudo?
<pmichaud> (r29857)
<paco> seems that make spectest_regression stopped to work (at least for me)
<paco> En la revisión 21616.
<paco> /usr/bin/perl t/harness --fudge --keep-exit-code --tests-from-file=t/spectest_regression.data <--- sleeps here ..
<dalek> r29858 | infinoid++ | trunk:
<dalek> : [tcl] Fix some "switch missing default case" warnings.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29858
<chromatic> "enlightening conversation" means "why version numbers are stupid"
<moritz> lol
% cjfields_ has joined #parrot
* DietCoke sees that particle has already taken over.
* DietCoke wanders away, then.
% purl has left purl!~purl@florence.kuiki.net
<paco> NotFound: #ps 
% cjfields has left cjfields!~cjfields@newrad.igb.uiuc.edu
% purl has joined #parrot
% rurban has left rurban!~chatzilla@212-183-53-112.adsl.highway.telekom.at
<cotto> paco: #parrotsketch
% purl has left purl!~purl@florence.kuiki.net
% Ivatar has joined #parrot
% confound has left confound!hdp@floe.aq
% confound has joined #parrot
% gryphon__ has left gryphon__!~gryphon@dsl-209-221-185-54.zipcon.net
% purl has joined #parrot
<cotto> patch monster?
<Infinoid> reviewer and committer of other people's patches
<pmichaud> I think that #44471 can be rejected.
<DietCoke> I think the only reason to use :anon with a :vtable was so you could also use :method, neh?
<DietCoke> (and now that you don't need to do that, I don't see a point to :vtable :anon)
<chromatic> Right.
<pmichaud> I think the original post was expecting to use the sub name
% ruoso has left ruoso!~ruoso@201.45.49.162
<pmichaud> with the changes discussed on saturday, though, it'll be a non issue
<pmichaud> (because :vtable implies :anon)
<DietCoke> ... there were changes discussed ?
<pmichaud> yes.
<particle> they'll be in allison's coming commit of pdd19
<pmichaud> I thought it was already committed
<pmichaud> I know I reviewed something.
<pmichaud> maybe it was just a m/l message
* DietCoke makes a snarky comment about discussion on list. =-)
<DietCoke> more likely a private mail message. last things I have from allison are yapc:eu 2008 yesterday, and then hackathaon space on 7/26
<pmichaud> RT #53302
* jonathan afk for 15 mins or so - dinner
<pmichaud> anyway, I suspect the current way to create an anonymous vtable entry is     .sub "" :anon :vtable('get_integer')
<pmichaud> shall I just stick these comments as replies to the tickets?
<pmichaud> I guess I'll do that.
<pmichaud> to avoid snarky comments about discussion on list.  =-)
<moritz> usr/bin/perl t/harness --fudge --keep-exit-code --tests-from-file=t/spectest_regression.data # this line hangs for me from time to time
<moritz> it seems to expect input from STDIN
<pmichaud> as in "stops running?"
<pmichaud> it doesn't process any tests?
<moritz> as in "last output that I see untild I press Ctrl+D"
<pmichaud> this is from the 'make spectest_regression' target?
<moritz> yes
<pmichaud> but it happens only sometimes?
<pmichaud> odd.
<moritz> it happens the first time after a clean checkout or other serious changes
<moritz> when I hit Ctrl+D once, it runs fine on the next invocation
<pmichaud> sounds like it's missing a file or directory or something
<moritz> yes, but they all exist
<moritz> try 'rm t/spec/S02-builtin_data_types/range.rakudo; make spectest_regression' - does that work for you?
<pmichaud> I'm not at a point where I can easily test :-(
<moritz> :/
<pmichaud> I can get there in about 15 mins though
<moritz> I'll test a few more things here locally
<jonathan> moritz: Trying deleting that file, and giving it another run
<jonathan> Will let you know what I see
<moritz> when I delete the line with S02-builtin_data_types/range.t
<moritz> from spectest_regression.data all works fine
<moritz> when I don't, and rm -rf t/spec && make spectest_regression it hangs
<moritz> maybe fudge tries to read from <> somewhere?
<jonathan> t\spec\S02-builtin_data_types\range...............ok 22/79 skipped: various reasons
<jonathan> Hmm
<jonathan> I need to grab something quickly from the supermarket before it closes - back soon...
<dalek> r29859 | allison++ | trunk:
<dalek> : [pdd] Architectural review of PIR PDD.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29859
<DietCoke> someone please open a ticket for this new deprecation note:
<DietCoke> {{DEPRECATION NOTE: PIR will no longer support the old PASM-style syntax
<DietCoke> for registers without dollar signs: C<In>, C<Sn>, C<Nn>, C<Pn>.}}
<DietCoke> (and add the ticket # back into the PDD)
<dalek> r29860 | allison++ | trunk:
<dalek> : [pdd] Resolving a few more TODOs in the PIR PDD.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29860
<DietCoke> and this:
<DietCoke> =item .HLL <hll_name>, <hll_lib> [deprecated]
<DietCoke> An old form of the .HLL directive that also loaded a shared lib for the
<DietCoke> HLL. Use C<.loadlib> instead.
<DietCoke> (also, the PDD uses that second deprecated syntax shortly after the warning.)
<dalek> r29861 | allison++ | trunk:
<dalek> : [pdd] Launching the PIR PDD out of draft.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29861
* DietCoke does wonder how it can be out of draft when there are so many {{NOTES}} in it.
<DietCoke> and outstanding questions.
<particle> take a look at the io pdd
<DietCoke> ... doesn't mean we should -keep- doing that. =-)
% DietCoke has left DietCoke!coke@feather.perl6.nl
<chromatic> Some questions we can't answer until we have some implementation.
<pmichaud> moritz: I get the hang on spectest_regression also (on fresh checkout)
<jonathan> back
<jonathan> Do you know where it's hanging?
<pmichaud> at the do_fudge step in the harness (still probing)
<jonathan> OK
<jonathan> I'd help, but I can't reproduce it here.
<pmichaud> it's hanging in fudgeall
<pmichaud> oh wait
<pmichaud> it might not even be getting there
<pmichaud> okay, it's getting there, and hanging when fudging range.t
<particle> if only we could skip it with #pure or something ;)
<particle> see what make t/.../range.t does
<moritz> just calling ./fudge rakudo S02-builtin_data_types/range.t doesn't hang, though
% paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net
<pmichaud> it's actually calling   fudge --keep-exit-code rakudo t/spec/.../range.t
<jonathan> Hmm.
<jonathan> I did change that file, intending to un-todo a few tests that Rakudo could pass.
<jonathan> #?rakudo 5 skip 'range reverse not in spec'
<jonathan> Valid directive?
<moritz> jonathan: but whatever you did to that poor file, why on earth should fudge start to hang?
% paco has joined #parrot
<moritz> valid directive, but not true
<pmichaud> fudge _does_ do while (<>)
<moritz> it *is* in the spec, and defined to be the empty range
<jonathan> moritz: the line below: ### pmichaud, 2008-07-04:  XXX  no spec for .reverse
<jonathan> If it is spec'd now, we should change this/check the tests.
<moritz> jonathan: oh, I thought you meant 4..1
<jonathan> No, it means .reverse method
<jonathan> My comment maybe shoulda had a "." in there to make things clearer.
<pmichaud> I've been trying to use  "Range.reverse"
<moritz> I see that TimToady used quite some <> magic :/
<jonathan> moritz: Where?
<jonathan> Oh, in fudge?
<moritz> jonathan: in fudge
<moritz> @ARGV = ($IN);
<moritz> so all should be well if $IN is what we think it is
<pmichaud> for some reason the while (<>)  isn't seeing @ARGV
<pmichaud> if I print @ARGV just before the while (<>) ... it's correct.
<moritz> I don't even get to the first debugging print statement I made :(
<pmichaud> moritz: are you printing to STDERR ?
<moritz> no, that's the problem
<pmichaud> right... fudgeall and fudge are called from backticks, so their STDOUT is captured
<pmichaud> it does start processing range.t, up to the first test after the #?rakudo skip line that jonathan added
<moritz> uhm, should reading from <> empty @ARGV?
<pmichaud> @ARGV isn't empty, when I run it.
<pmichaud> i.e., I'm actually getting lines from range.t
<moritz> I added a few 'warn Dumper \@ARGV' lines, and it's empty sometimes
<jonathan> This isn't because you #? has to be in the leftmost column?
<jonathan> *the
% AndyA has left AndyA!~andy@ca93nt.hexten.net
<pmichaud> it shouldn't matter
<jonathan> I thought not.
<pmichaud> but there's something about the #?rakudo skip lines that fudge doesn't like
<pmichaud> commenting out the first causes me to hang on the second
<moritz> is $ARGS tied to @ARGV somehow?
<moritz> no, that was $ARG
<pmichaud> it's something to do with the skip lines jonathan added.
<pmichaud> if I take them out, processing works fine.
<jonathan> I removed one and added one, I believe.
<pmichaud> #    #?rakudo 2 skip '.reverse on ranges'
% AndyA has joined #parrot
<pmichaud> ...how about that one?
<jonathan> (The one I removed covered both some tests that passed in Rakudo and some that failed)
<pmichaud> #    #?rakudo skip 'XXX test error -- result should be undef?'
<pmichaud> those are the ones that are causing issues for fudge
<Auzon> Those aren't recognized by fudge, I think
<jonathan> It was around the .reverse that I did the changes.
<pmichaud> Auzon: ...?
<purl> Yada yada yada hasn't been implemented yet! (unless you run bleadperl)
<jonathan> The entire block "# simple .to, .from" before was marked as skip
<jonathan> I moved the #?rakudo directive inside the block and tweaked the number.
<Auzon> pmichaud: Fudge requires the ? right after the # mark or it's just a comment
<jonathan> (since .from and .to work)
<pmichaud> Auzon: oh.  the extra #'s in my pastes were where I commented out the skip lines
<pmichaud> if I remove those, then fudge hangs on what's left
<pmichaud> oops, I have to run.  I'll follow up on it later.  It's something about the range.t test that is causing the problem, though.
<pmichaud> bbiaw
<jonathan> OK
<jonathan> I have another update to that file anyway (removing one of the fudge directives, since I've made more tests pass)
<dalek> r29862 | jonathan++ | trunk:
<dalek> : [rakudo] Make range smart-matching accept the same or equivalent range as well as a single value within the range.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29862
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-206-168.dynamic.mnet-online.de
% sjansen has left sjansen!~sjansen@169.139.177.61
<moritz> in ROADMAP, Make junctions in boolean context return a junction of True/False
<moritz> is that actually correct?
<moritz> if you do this, 'if "a" eq any(<a b>)' and 'if !"a" eq any(<a b>)' will both be true
<jonathan> Doens't !"a" do prefix:! on "a"?
<moritz> I'd expect it to have a low precedence
<moritz> anyway, I meant !("a" eq any(<a  b>)
<jonathan> OK
<jonathan> Comment was based on comment from pm in RT#56630, but I may have mis-understood
<jonathan> I see your point. Hmm.
<jonathan> Think is that we should be able to rely on auto-threading to carry us through.
<jonathan> if !("a" eq any(<a b>)) -> if !(any("a" eq "a", "a" eq "b")) -> if !any(True, False) -> if any(False,True)
<jonathan> -> True
<jonathan> Hmm. :-S
% donaldh has joined #parrot
<moritz> "Collapsing to a single
<moritz> true/false value should happen when a Junction is used in a boolean context."
<jonathan> Yeah
<jonathan> Oh
<jonathan> ! enforces boolean context
<moritz> prefix:<!> actually does provide boolean context
<jonathan> !any(True, False) -> !True -> False
% teknomunk has joined #parrot
% paco has left #parrot
% paco_ has joined #parrot
* jonathan gets at least another 36 spec tests to pass with an implementation of infix:===
<moritz> YaY
% paco_ is now known as paco
<jonathan> t\spec\S03-operators\value_equivalence............dubious Test returned status 1 (wstat 256, 0x100) after all the subtests completed successfully
<jonathan> moritz: Seen this before? Any ideas?
<moritz> jonathan: yes, in other tests
<jonathan> It gave all tests successful with perl t\harness
<moritz> jonathan: usually some GC f*ckup
<jonathan> sh*t.
<dalek> r29863 | allison++ | pdd25cx:
<dalek> : [pdd25cx] Bringing the pdd25cx branch up-to-date with trunk r29862.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29863
<jonathan> Oh, no, it does the same with t\harness too; I'd run it with perl6.pbc before
<particle> is it fudged?
<jonathan> particle: Yup
<particle> all fudged tests return 1
<particle> even if all tests pass
<jonathan> particle: OK, but normally in spectest_regression you don't then get a warning about it.
<particle> yes, because of --keep-exit-code
<particle> or whatever it's called
<jonathan> Right. But I'm getting the "dubious" in running spectest_regression
<particle> ah.
<particle> :(
<jonathan> And it doesn't segfault or anything when run under the debugger.
<jonathan> Just says it exited with code 1
<chromatic> Something sets the exit code then.
<chromatic> T*::Harness expects that an exit code of 0 means everything's okay.
<chromatic> Anything else indicates some form of oopsie.
<moritz> jonathan: did you try to run the .rakudo manually?
<jonathan> chromatic: It's meant to be exiting with a code of 1; fudged tests do.
<jonathan> moritz: Yes; it all looks fine doing that.
<jonathan> It's only when I run it under the harness.
<jonathan> Hmm, the harness says "Test returned status 1" too. Oddness.
<chromatic> The harness doesn't know that 1 means everything's okay.
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<jonathan> chromatic: The harness used in make spectest_regression is modified to know that 1 means that.
<dalek> r29864 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] update to trunk r29862
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29864
<chromatic> Alright then.
<jonathan> chromatic: Normally, this works out fine; we have other tests doing this. For some reason, one that I've just added to the spectest_regression list ends up giving the warning. :-(
<pmichaud> what's the spec that gives rise to r29862?
<particle> what happens if schwern's patch is reverted?
% Debolaz has joined #parrot
<pmichaud> (equivalence of ranges)
<pmichaud> (dubious): I  get that a lot in the test harness
% cjfields_ has left cjfields_!~cjfields@cjfields.igb.uiuc.edu
<dalek> r29865 | jonathan++ | trunk:
<dalek> : [rakudo] Basic implementation of the === and !=== operators, plus WHICH defined one some immutable types. Does enough to pass all non-fudged tests in S03-operators/value_equivalence.t.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29865
% iblechbot has joined #parrot
<jonathan> pmichaud: It was in the spec test, and looked familiar; now I go look at the spec, I don't see it.
<pmichaud> right, that's one of the reasons I hadn't implemented it yet.  But I also hadn't had a chance to ask about it on p6l.
<jonathan> I was probably thiking of "Array     Array     arrays are comparable"
<pmichaud> but Range != Array
<jonathan> Oh, sure.
<pmichaud> I think we have to be a little bit pessimistic about assuming the spectests are correct
<jonathan> I wasn't saying that makes it correct, just what I was probably thinking of.
<pmichaud> can we get a p6l clarification or attach a ticket to get one?
<jonathan> I'm writing to p6l now.
<jonathan> pmichaud: Written; will update the spectest/implementation if I get a response back saying the spec is right and the test is wrong.
<jonathan> pmichaud: On the dubious test - since it's the only one doing that here for me, I'm a bit wary about adding it to spectest_regression.data, even though it is passing all un-fudged. Thoughts?
<jonathan> (all un-fudged tests, that is)
<pmichaud> I've seen "dubious" on other spectest_regression tests -- push.t gives that for me a lot
<pmichaud> I also get exceptions on the exit code
<jonathan> OK
<pmichaud> (RT#56630):  My primary point about boolean context was simply that the comparison operators currently in Junction.pir are wrong.
<jonathan> In that they should return a junction?
<pmichaud> yes
<jonathan> Makes sense.
<pmichaud> but yes, the underlying thought is also that most of the operators and items defined in Junction.pir should be handled via the normal dispatch and not as special-purpose functions
<jonathan> That involves writing out own dispatcher. :-)
<pmichaud> we're going to have to do that, yes.
<pmichaud> I left a question with TimToady on saturday asking about how we autothread method calls over junctional invocants
<jonathan> Junctional invocants = $junc.foo?
<pmichaud> yes.
<jonathan> I think you that's always a call on Junction.
<moritz> that's what i'd expect too
<jonathan> Otherwise, $junc.values maybe doesn't work.
<pmichaud> right
<pmichaud> but that's not what TimToady answered
<jonathan> Oh, damm.
<jonathan> :-S
<pmichaud> because it means we can't do    (1|2).exp
<jonathan> Hmm
<pmichaud> so we were speculating about something like  $junc.JUNCTION.values, similar to VAR on scalars
<jonathan> I guess if you're expecting to be able to use a junction anywhre you'd use a normal value, that kinda hurts...
<jonathan> That's ugly, though consistent-ish.
<Whiteknight> I would rather it be consistently not ugly :)
<jonathan> (and easy to implement...)
<pmichaud> autothreading method calls over junctions sounds... interesting, though.
<jonathan> With a custom dispatcher, I'm not thinking it'll be too horrible.
<pmichaud> right... but it means we can't do method calls on junctions through parrot's normal dispatch
<pmichaud> unless we override find_method somehow or something like that.
<jonathan> Yes...
<pmichaud> anyway, it also means that most of the existing spectests that do   $junction.values or $junction.pick are wrong.
<jonathan> Actually, it may not be so bad. Because $j.foo will call foo on Junction.
<jonathan> And then it can hit the fallback
<pmichaud> there is no fallback.
<jonathan> (because There Is No Foo)
<pmichaud> method fallbacks are gone now.
<jonathan> As in, the Perl 6 equivalent to AUTOLOAD
<pmichaud> yes, I was thinking it'd have to be autoload-ish.
<jonathan> Which sees the name, and gets the parameters.
<jonathan> And threads the call through the values in the junction.
<jonathan> We don't have a nice way to do AUTOLOAD style thing in Parrot right now.
<pmichaud> how does one do autoload-ish stuffin Parrot?
<pmichaud> oh.
<pmichaud> you answered my question as I was typing it :-)
<jonathan> We could either teach Parrot how to do it (by doing Stuff in find_method)
<pmichaud> surely it's been considered already, though?
<jonathan> Or stick it in our custom dispatcher.
<jonathan> find_method can return the AUTOLOAD on failing to find anything.
<pmichaud> right.
<pmichaud> or dynamically generate a method :-)
<jonathan> But they you have the slightly tricky issue of, how does it actually get the name of the thing we originally planned to call...
<pmichaud> if we dynamically generate the method we can put it in there :-)
<jonathan> Mwaha. :-)
<jonathan> Dynamically generated bytecode. :-)
<pmichaud> I wonder if there's a way for a method to determine how it was invoked?  (i.e., what name was used?)
<pmichaud> that would make it easier.
<jonathan> No, which goes back to the usual issue of find_method / invoke are split.
<jonathan> (The null PMC access in invoke that we used to get, was because we didn't know the name any more of what we find_method or find_name'd)
<jonathan> It's also the same reason that find_method currently can't do MMD, and we thus invoke on the multi..
<jonathan> (The args ain't promised to be available, at find_method time)
<pmichaud> ...but methods are invoked with callmethodcc, not invoke
<pmichaud> it's not the same
<pmichaud> subroutine calls are invoked using find_name_not_null + invoke, yes.
<pmichaud> method calls are invoked using callmethodcc, which has the name as part of the invocation
<jonathan> OK, but the callmethodcc op does a find_method, and then an invoke inside.
<pmichaud> okay.  but we could potentially squirrel away the invoke name somewhere.
<jonathan> You're right though, we do in callmethodcc emit a good error message rather than the Null PMC in invoke. That was for subroutine calls.
<pmichaud> btw, allison also said on saturday that we would see about changing things so that   foo.$P0(...)  would dtrt if $P0 is a String
<pmichaud> (or does 'string')
<jonathan> Does that not do the right thing now?
<pmichaud> currently it expects $P0 to be an invocable PMC
<jonathan> Ah.
<jonathan> That could make some code neater.
<pmichaud> yes, that's why I asked for it.
<pmichaud> and she said "oh, I was about to ask you about that as well."  :-)
<jonathan> :-)
<jonathan> Will Allison be at YAPC::EU, do you know?
<pmichaud> same for sub invocation -- i.e.,   $P0(...)  when $P0 is a String
<pmichaud> yes, she's at YAPC::EU
<jonathan> Cool.
<pmichaud> she's even planning to attend the hackathon, remember?  ;-)
<jonathan> I'm starting to think I already knew this... ;-)
<pmichaud> (from email, about dates when we would be there for pre/post-yapc hacking)
<jonathan> Oh, yes!
<pmichaud> :-D
<pmichaud> that may be a _really_ good time to get all of our dispatch and parameter issues worked out
<pmichaud> including mmd
<jonathan> Yes, agree.
<jonathan> I think I'm going to see if I can spend some of my MMD time towards the end of the week, going over the spec closely, writing tests, and coming up with any questions I need answered.
<pmichaud> that would be excellent.
<jonathan> So at least the algorithm is nice and clear.
<pmichaud> I think that would be extremely wise.
<pmichaud> I also think it will yield big dividends when we get to implementation
<jonathan> Yes, agree.
<jonathan> Also, Parrot needs to be able to HLL_map MultiSub.
<pmichaud> that sounds really.... scary
<pmichaud> but I don't disagree.
<jonathan> Not really - I think in fact the MMD PDD requires it.
<pmichaud> oh, in that case I'm less scared.
<jonathan> "An alternate multiple dispatch matching algorithm may be plugged in by subclassing MultiSub and overriding invoke."
<jonathan> So that's exactly what I plan to do.
<pmichaud> oh yes, of course.
<pmichaud> that works for me then.
<jonathan> But it follows on, that you need to have a way to have your multis of the right PMC type.
<jonathan> So if you can get HLL working, it makes my life a little easier.
<pmichaud> I can do that, yes.
<jonathan> If you can't, I can work around this.
<jonathan> We also need to think a bit on signatures at some point too. :-S
<pmichaud> correct
<jonathan> Last time we tried that, we got kinda bogged down.
<pmichaud> I'm beginning to think that PIR will never have sufficient pragma flags for us to do everything we want to do, so that we'll have to make it all part of :init/:load
<jonathan> I think, because I was primarily interested in them being introspectable data, because that's what I need for MMD.
<pmichaud> do you need them more introspectable than simply arity and types of args?
<jonathan> No.
<jonathan> Well
<jonathan> Yes and no. :-)
<pmichaud> so :multi is sufficient as a first cut?
<jonathan> I'm struggling to think of a good way to get enough information into multi.
<pmichaud> well, that's why I said "first cut"
<jonathan> There can be many constraints.
<pmichaud> however
<jonathan> Which may be class or role names, etc.
% ruoso has joined #parrot
<pmichaud> I'm starting to think that for Rakudo we should just have a Junction of constraints, and have the dispatcher smart-match against that
<jonathan> The MMD algorithm requires a bit more of us than "is it a match"
<pmichaud> agreed
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-198-181.dynamic.mnet-online.de
<pmichaud> where's the Perl 6 mmd sort speced?
<jonathan> First, we need to consider classes and roles, and we use constraints (subset types) later.
<jonathan> S12
<pmichaud> okay, I'll need to re-review that
<jonathan> Starts at heading "Multisubs and Multimethods"
<pmichaud> anyway, I agree that signatures will end up as introspectable types.  For a variety of reasons I think I'd like to avoid :immediate if we can.  
<pmichaud> (it may be that we cannot, but that's what I'd like to shoot for to begin with)
<jonathan> The fact that it is in the way of PBC generation (I *think* that's what you said?) makes me kinda keen to do away with them too.
<pmichaud> yes
<pmichaud> going back to the roadmap a bit, I think that PBC generation is my highest priority at the moment
<pmichaud> I think that depends on .HLL a bit, as well as getting :load/:init fixed
<jonathan> The reason I used them was because they provide a sure-fire way to make sure you attach things to the Right Sub.
<jonathan> (Because you make it the :outer)
<pmichaud> yes, "the Right Sub" is also a bit of an issue for me.  I think we might need a way to uniquely identify subs outside of just names.  
<pmichaud> :lexid is close, but this goes beyond just lexicals.
<jonathan> We already created one of those and called it lexid, but it seems it could be more widely applicable.
<pmichaud> basically :lexid is almost equivalent to "longname"
<jonathan> Also, lexid is not generated until POST-time.
<pmichaud> I did that as a short-term measure
<pmichaud> there's nothing to prevent :lexid from being part of the PAST
<jonathan> If we're going to attach something to a sub based upon that, we need either POST to be able to help us link the two up or move it up.
<pmichaud> it's the same approach that gets used now for anonymous subs
<jonathan> Yes, to PAST, as you mentioned.
<pmichaud> PAST doesn't contain a name, but the POST generates one.
<jonathan> OK.
<jonathan> But Rakudo could feasibly generate the names.
<pmichaud> correct
<pmichaud> and :lexids
<jonathan> Right, which is what we're interested in here.
<pmichaud> which is why I think that :lexid might be more correctly thought of as a longname equivalent
<jonathan> Then the missing bit of the puzzle, is a lookup by lexid.
<pmichaud> ....and a way to do that efficiently. :-)
<jonathan> Yeah. :-|
<jonathan> Thing is, we kinda want a hash of lexid => sub
<jonathan> But we only care about having it at startup.
<pmichaud> I wonder if the Eval PMC could help here
<pmichaud> since the Eval PMC has an array of Sub PMCs
<jonathan> You can likely make it easy (if this ain't already possible) to iterate all of it's subs. We can also trivially expose the lexid.
<pmichaud> yup
<jonathan> Then we can even just build our hash in one iteration in PIR.
<jonathan> In the :init :load
<jonathan> Do our lookups in it
<jonathan> Then let the GC have its way with it after :init :load.
<pmichaud> yes, that has some possibilities
<jonathan> Oh
<jonathan> But the Eval PMC ain't available in the :init :load?
<pmichaud> currently, no, but we might be able to fix that as well.
<jonathan> Even in the PBC version?
<pmichaud> I really have to get the whole :init/:load process mapped out
<pmichaud> there's been so much "workaround" stuff done to get things to work that I have to go back and decide which parts are "real" and which parts are "workaround"
<jonathan> Really we want to walk the constants table attached to the current bytecode segment.
<jonathan> This will contain, if we eval'd, the Sub PMCs that we evaluated.
<jonathan> And if we're loading a PBC, will contain the Sub PMCs we compiled and had in the PMC.
<pmichaud> true.  For example, I didn't realize until a week or two ago that :immediate subs get replaced in the bytecode by whatever they return
<jonathan> Yes. I wasn't using them so much for this purpose, though.
<pmichaud> but it's very handy for building the signature object we need
<pmichaud> instead of building it at load time
<pmichaud> (assuming we can get a reasonable representation.)
<jonathan> Yes, that's another reason :immediate is good - we do compile time at, well, compile time.
<jonathan> I think in reality, we can do stuff in :init :load now, and move some of it to :immediate as a kind of "optimization" later.
<pmichaud> yes, we can certainly do that.
<jonathan> Once we get issues with :immediate in Parrot straightened out.
<jonathan> (Which evidently exist, since they're geting in our way...)
<pmichaud> Anyway, I hate to rush off but I have to get some other stuff done today.
<jonathan> Well, in your way. :-)
<pmichaud> I _should_ have some Parrot hacking time tomorrow.  After that it's spotty until August 9th
<jonathan> OK, it's half midnight here so I should maybe call it a night.
<jonathan> OK, I'll likely be on IRC a bit tomorrow too.
<pmichaud> my time tomorrow will be early (before noon localtime) -- after that it's off to the airport
<jonathan> Vacation?
<purl> Vacation is good for the soul, and allows one to learn JDK 1.2 or or GET REAL it's a VACATION or an alien concept to formerly underpaid beleaguered perl hackers whose time is long overdue
* jonathan suggests NOT learning JDK 1.2 on vacation.
<pmichaud> yes, vacation
<purl> it has been said that vacation is good for the soul, and allows one to learn JDK 1.2 or or GET REAL it's a VACATION or an alien concept to formerly underpaid beleaguered perl hackers whose time is long overdue
<jonathan> Nice. Enjoy. :-)
% donaldh has left donaldh!~chatzilla@host213-123-171-12.in-addr.btopenworld.com
* jonathan rests - report tomorrow
<Tene> 'night
% Ivatar has left Ivatar!~graham@tu055.demon.co.uk
% cesar has joined #parrot
<cesar> Hi
<cesar> It seems the code for Software Transactional Memory remained almost the same since 2006
<cesar> I'm a MSc student with interest in parallel computing
<cesar> and I would like to contribute ...
<cesar> is there anyone here who had worked on that?
% cesar has left cesar!~pcalcina@kama.ime.usp.br
% cesar has joined #parrot
<cotto> cesar, if nobody here can help you right now, you can subscribe to parrot-porters and ask there.
<cesar> cott: ok, I'll try it, thanks
<cotto> the amount of activity on #parrot varies greatly
<Whiteknight> cesar, what suggestions do you have about the STM system?
<Whiteknight> I'm peripherally familiar with it
<cesar> I would like to begin testing another approaches described in literacy
<Whiteknight> I don't know how pluggable the system is. That is, I don't know if you can easily write an alternative without mangling the existing code
<Whiteknight> Although if you wrote up an alternative, you could separate it with an #ifdef
<cesar> I started by reviewing the code, and the paper the implementation is based on, just beginning with it
<Whiteknight> I'm not as familiar with stm as I would like. I'll have to read that paper myself
<Whiteknight> Actually, if you understand that file pretty well, it needs a lot of function-level documentation
<Whiteknight> all the "RT#48260: Not yet documented!!" notes need to be replaced by documentation
<Whiteknight> I may work on that myself, if you don't want to do it
<cesar> I plan to use the VM as bed of the research and I'll like that part of the resulting work be useful for the project
<Whiteknight> very nice. good luck
% cesar has left cesar!~pcalcina@kama.ime.usp.br
% cesa1 has joined #parrot
<chromatic> cesa1, the implementation has some drawbacks.  Allison and I have long planned to review it.
% bacek has joined #parrot
<cesa1> I would like to help
<Whiteknight> cesa1++
<cotto> cesa2?
<Tene> heh
<cotto> cesar++
<cesa1> there's a lot of variations in literacy ... but we could find the best choice of them that suites the parrot interests
% cesa1 has left #parrot
% davidfetter has joined #parrot
<pmichaud> generic planning note:  my plan at the moment is to get standalone/precompiled modules working in Rakudo tomorrow while on the plane
<pmichaud> (long flights, so lots of time to hack)
<pmichaud> this will involve changes to PCT, P6object, and rakudo
<pmichaud> </note>
<particle> pmichaud: if you have anything you would like me to report to sixperl, let me know
<pmichaud> particle: I expect I may be on the early part of the sixperl call
<particle> fab
<pmichaud> sixperl is at 15:00, flight is at 15:40
<pmichaud> so I will probably go ahead and call in at 15:00 and give brief report
<particle> hope mute works well on your mobile :)
<pmichaud> it does on my headset -- I use that all the time on the call :-)
<pmichaud> (which means you perhaps haven't noticed it :-)
<pmichaud> I will likely miss next week's call
<pmichaud> depends on cell services wherever we happen to be
<pmichaud> I was thinking I'd miss the week after that too, but given the time differences I'm now thinking I'll likely make it :-)
% kid51 has joined #parrot
% Schwern has left Schwern!~schwern@069-064-236-003.pdx.net
% Theory has left Theory!~Theory@c-67-160-131-113.hsd1.wa.comcast.net
% Limbic_Region has joined #parrot
% petdance has joined #parrot
% s1n has joined #parrot
<s1n> i'm trying to add something to rakudo and i'm getting an error about how get_bool is not implemented, sifted through parrot's Class.pir and didn't see it
<s1n> am i looking in the right place? i'm very new to writing pir stuff
<kid51> This is a good place.  It just depends on who's on channel at any given time.  Could you paste your error?
<kid51> purl paste?
<purl> paste is (see: nopaste) or like glue but a little safer to sniff. or http://nopaste.snit.ch:8001/ or http://scsys.co.uk:8001/ anywhere shadowpaste is or mmm, sticky paste or You there! Eating the paste. or <see> 2 girls, 1 paste
<s1n> yeah hang on a sec
<nopaste> "s1n" at 75.16.180.101 pasted "get_bool error" (3 lines) at http://nopaste.snit.ch/13700
* kid51 personally can't help you much on that, but there may be others.
<s1n> i don't really know what i'm doing with pir, i just figured i'd dive in head-first and i'm having trouble understand who has what implemented
<Whiteknight> There is a readme file or roadmap file somwehere that details the progress
<Whiteknight> i dont remember the name of it exactly
<bacek> roadmap?
<purl> roadmap is http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-11/msg00115.html
<bacek> wrong roadmap
<bacek> rakido roadmap?
<bacek> rakudo roadmap?
<purl> rakudo roadmap is http://svn.perl.org/parrot/trunk/languages/perl6/ROADMAP
<bacek> oh
<bacek> Whiteknight: this one?
<purl> i think this one is bugged too now
<bacek> s1n: what you tried to add to get this error?
% particle1 has joined #parrot
% particle has left particle!~particle@c-98-232-28-49.hsd1.wa.comcast.net
<s1n> bacek: i wanted to see if i could add clone to Object.pir, which is where I assumed it was needed for S12-classes/basic.t
<s1n> bacek: i was just actually trying to add the method before i filled in the implementation
<bacek> s1n: no. rakudo/parrot already has clone().
<bacek> s1n: and you hide originally implemented one.
<bacek> clone is vtable method from parrot. So, it almost shouldn't be implemented manually in rakudo.
<s1n> what is a vtable method?
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
<nopaste> "s1n" at 75.16.180.101 pasted "missing clone" (6 lines) at http://nopaste.snit.ch/13701
<s1n> it's not finding clone, so i'm curious what a vtable method is and why it's not being found
<s1n> bacek: i've more or less have this problem with some other 'vtable methods' that don't seem to be implemented
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<bacek> s1n: ah. ok. my bad..
<bacek> Just look ad src/classes/Range.pir. It has clone implemented
<dalek> r29866 | pmichaud++ | trunk:
<dalek> : [rakudo]: spectest-progress update: 113 files, 1902 passing tests
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29866
<s1n> bacek: yeah i tried just copying that .sub, not doing really anything and that's how i got that get_bool error
<s1n> bacek: hmm, range seems to have done something that resembles overriding the vtable get_bool method
<s1n> bacek: okay, i've got the clone method defined properly, can you explain what a vtable method is?
% Patterner has left Patterner!~Psyche@e177225207.adsl.alicedsl.de
<particle1> s1n: read docs/pdds/pdd17_pmc.pod
% particle1 is now known as particle
<s1n> bacek: wow, that's a huge doc
% jhorwitz has left jhorwitz!~chatzilla@96.245.16.64
% daizisheng has joined #parrot
<dalek> r29867 | jkeenan++ | trunk:
<dalek> : [configure] Merging 'parallel' branch into trunk.  This:
<dalek> : (a) Reduces the number of configuration step tests (t/steps/*.t) from 227 to
<dalek> : 74 as planned in http://rt.perl.org/rt3/Ticket/Display.html?id=56716.
<dalek> : (b) Provides the first meaningful tests of the gen::* configuration step
<dalek> : classes.
<dalek> : (c) Provides two new functions in Parrot::Configure::Test,
<dalek> : rerun_defaults_for_testing() and test_step_constructor_and_description(),
<dalek> : which are useful in the steps tests.
<dalek> : (d) Provides two new methods in Parrot::Configure, pcfreeze() and replenish(),
<dalek> : which are also useful in the steps tests.  They are wrappers around Storable
<purl> okay, dalek.
<dalek> : functions and are used to test the Parrot::Configure object multiple times
<dalek> : within a file notwithstanding the fact that it is a singleton.
<dalek> : (e) Improves POD and inline commentary within the config step tests.
% Patterner has joined #parrot
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29867
<dalek> r29868 | jkeenan++ | parallel:
<dalek> : Branch has been merged with trunk and is no longer needed at HEAD.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29868
<dalek> r29869 | jkeenan++ | parallel-29266:
<dalek> : Branch to which tag corresponded has been merged with trunk.  Tag may be deleted.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29869
* kid51 must sleep
<purl> $kid51->sleep(8 * 3600);
% kid51 has left kid51!~jkeen@68.237.19.130
% grim_fandango has joined #parrot
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1128671702.dsl.bell.ca
% Theory has joined #parrot
% Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net
% Theory has joined #parrot
% Ademan has joined #parrot
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net
% integral has left integral!bsmith@adsl-212-20-244-147.lumison.co.uk
% Psyche^ has joined #parrot
% Patterner has left Patterner!~Psyche@e177224000.adsl.alicedsl.de
% Psyche^ is now known as Patterner
% Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net
% Theory has joined #parrot
% petdance has left petdance!~Andy@uniqua.petdance.com
% uniejo has joined #parrot
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
% brettles has joined #parrot
% integral has joined #parrot