% teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net
% purl has left purl!purl@sentient.life
% Ademan has left Ademan!~dan@h-68-164-169-20.snfccasy.dynamic.covad.net
% magnachef has joined #parrot
% Ademan has joined #parrot
% KVirker has joined #parrot
% KVirker has left #parrot
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
% stupidbot has joined #parrot
% bacek has joined #parrot
<dalek> r28999 | fperrad++ | trunk:
<dalek> : [install] pipp
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=28999
% bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au
<dalek> r29000 | fperrad++ | trunk:
<dalek> : [smoke] add pipp
<dalek> : - remove plumhead
<dalek> : - remove trailing space
<dalek> : - add Perl coda
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29000
% jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se
<dalek> r29001 | fperrad++ | trunk:
<dalek> : [Pipp] recursive count is not implemented
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29001
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
% stupidbot has left stupidbot!bacek@123-243-38-218.tpgi.com.au
<dalek> r29002 | fperrad++ | trunk:
<dalek> : [Pipp] complete ctype
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29002
% stupidbot has joined #parrot
% MeGaMiC has joined #parrot
% MeGaMiC has left MeGaMiC!~megamic@ppp59-167-49-196.lns2.cbr1.internode.on.net
% bacek has joined #parrot
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
% bacek has joined #parrot
<bacek> evening everyone
<moritz> good localtime() bacek ;)
<bacek> moritz: :)
<bacek> rt #56214
<stupidbot> Error calling said() for rt: Malformed RT response received from http://rt.perl.org/rt3/
<bacek> stupid bot...
<bacek> I've disable this function for now...
<bacek> message pmichaud index2.diff from RT#56214 waiting for your opinion
<bacek> purl?
<spinclad> s/message/msg/ maybe?
<spinclad> purl, messages?
<spinclad> ENOPURL
% barney has joined #parrot
% rurban has joined #parrot
<rurban> Shouldn't contain the languages/*/Makefile a install target? I'd need it for the examples and docs
% gmansi_ has left gmansi_!~gmansi@190.55.35.246
% kj has joined #parrot
% vhold has joined #parrot
<barney> They probably should have an 'install' target. But nobody bothered yet.
<dalek> r29003 | bernhard++ | trunk:
<dalek> : [Pipp]
<dalek> : Add a TODO test for contants.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29003
% Whiteknight has joined #parrot
% davidfetter has joined #parrot
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% contingencyplan has joined #parrot
% kid51 has joined #parrot
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% contingencyplan has joined #parrot
% rdice has joined #parrot
<rurban> cygwin needs to add an import lib. How does mingw does that?
<rurban> in root.in I'd need just to add something like after LIBPARRTO_SHARED LD : #CONDITIONED_LINE(win32):	----out-implib libparrot.dll.a \
<rurban> The problem is just the ldflags line in pkgconfig and config_lib.pasm. -lparrot
<rurban> linking to a dll alone works fine, but this would need to change those two settings. Generating the import lib seems to be easier.
<rurban> All assumed from a packaged version via reallyinstall.
% confound_ is now known as confound
<dalek> r29004 | bernhard++ | trunk:
<dalek> : [Pipp]
<dalek> : Implement define() and constant().
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29004
<rurban> BTW: does #CONDITIONED_LINE(win32) contain cygwin also?
<rurban> nope.
<kid51> barney:  There was a message posted to list requesting that commit messages contain more than just the subsystem -- that they include some description as well.  (Some problem with a git tool.)
<barney> rurban you can ask      ./parrot_config  win32  
<barney> kdi51: do you mean int the first line of the message  ?
<moritz> that's what the git tools expect, yes
<rurban> barney: I only got cygchkdll for cygwin. good enough.
<barney> I see
% acalhoon has left acalhoon!~acalhoon@74-131-25-177.dhcp.insightbb.com
% tetragon has joined #parrot
<kid51> barney:  Yes.  See a post by G Broadwell in past day.  (Just passing the message along; I have no preference, myself.)
* kid51 only started to indicate a subsystem in commit messages in the past few days :-)
<tetragon> kid51: At some point in the near future, I'll be temporarily unable to do any PPC testing.  (near future is defined as when Apple can ship an LCD panel to Toronto without damaging it)
<kid51> Thanks for the update.  I've been nudging people who participated in buildfest at YAPC to try out all your patches, but am experiencing the herding cats problem.
<dalek> r29005 | bernhard++ | trunk:
<dalek> : [Pipp PHC] Add support for constants.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29005
<tetragon> I'm half-tempted to check the boxes at the Apple store for Xcode and do 10.5 Intel testing there
<moritz> bacek: are you around?
<bacek> moritz: little bit
<bacek> for.t?
<moritz> bacek: with your latest index() patch, will the returned failure be a StrPos?
<bacek> not yet.
<bacek> actually I thinks that StrPos is redundant... (Int|Failure) junction is enough for any use-cases...
<bacek> perl6: my Int $a = 0; say defined $a;
<polyglotbot> OUTPUT[1␤]
* barney is going to enjoy the sun at the Isar
<moritz> bacek: only as long as we don't implement character levels
<moritz> barney: Munich?
<bacek> so, for index() we need something like my $p = $b.index(foo); if defined $p ...
<barney> Yes
<moritz> bacek: I'm going to apply your patch and extend the tests a bit
% barney has left barney!~bernhard@p549A1F58.dip0.t-ipconnect.de
<dalek> r29006 | moritz++ | trunk:
<dalek> : [rakudo] implement Str.index, patch curtesy by bacek++ (Vasily Chekalkin)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29006
<dalek> r29007 | moritz++ | trunk:
<dalek> : [rakudo] add S29-str/index.t to spectest_regression.
<dalek> : bacek++ for implementing
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29007
% kid51 has left kid51!~jkeen@pool-70-107-7-97.ny325.east.verizon.net
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
% skv has joined #parrot
% allison has left allison!~chatzilla@ppp-71-139-37-118.dsl.snfc21.pacbell.net
% TiMBuS has left TiMBuS!~Hurf@123-243-167-27.static.tpgi.com.au
<dalek> r29008 | pmichaud++ | trunk:
<dalek> : [rakudo]: coding stds in src/classes/Str.pir .
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29008
% rdice has joined #parrot
<moritz> parrot doesn't seem to implement complex log() function
<pmichaud> it's possible.
<moritz> I tried to cargo-cult a log(Complex) impelementation in the same way that exp() is done, and it still returns 0 always
<moritz> oh wait, it does seem to be implemented
<moritz> and it seems to be correct (at least from a glance at the src/pmc/complex.pmc file)
<pmichaud> nopaste diff ?
<nopaste> "moritz" at 89.13.212.252 pasted "complex log() and log10() for rakudo - not working" (53 lines) at http://nopaste.snit.ch/13453
<pmichaud> log10 doesn't appear to be implemented in complex.pmc
<moritz> yes, but if parrot is clever enough it just dispatches to log(x)/log(10)
<pmichaud> I don't think parrot is that clever
<moritz> that would explain whay log10 doesn't work, but what about log()?
<moritz> btw I fear the complex log10 tests are a bit wrong ;)
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
<moritz> ... not anymore ;)
<pmichaud> what test file?
% tetragon has left tetragon!~seneca@76-10-148-120.dsl.teksavvy.com
<moritz> spec/S29-num/log.t
<nopaste> "pmichaud" at 76.183.97.54 pasted "log on complex seems to work" (14 lines) at http://nopaste.snit.ch/13454
<pmichaud> log10 fails
<nopaste> "pmichaud" at 76.183.97.54 pasted "log10 fails" (15 lines) at http://nopaste.snit.ch/13455
<pmichaud> I'm not sure why your patch doesn't work, unless it's due to Parrot MMD somehow.
<DietCoke> is ln an opcode or a method dispatch?
<DietCoke> (method dispatch is going away)
<pmichaud> it's a pseudo-opcode that does method dispatch
<pmichaud> DietCoke: do you plan to replace it with a real opcode, or eliminate it entirely?
<DietCoke> nothing in core was using it. in the no_builtin_methods branch, it's just gone. I can add opcodes for anything that was a builtin for which an opcode is needed.
<DietCoke> but I didn't want to bother adding opcodes for things that weren't used.
<pmichaud> adding an opcode might be tricky
<pmichaud> and I'd be initially against that approach
<DietCoke> as am I. Good. switch to explicit methods. =-)
<DietCoke> (may be why the log10 isn't working, that may not be in the list in src/builtin.c on trunk.
<pmichaud> log10 isn't implemented in complex.pmc
<DietCoke> ah. (yah, it's in the list, so that'd do it.)
<DietCoke> so far, the only opcodes I added were the 4 say variants.
<pmichaud> if we write an opcode for 'ln', we also have to do opcodes for 
<pmichaud>         "abs", "neg", "not", "fact", "sqrt", "ceil", "floor"
<pmichaud>         "acos", "asec", "asin",
<pmichaud>         "atan", "cos", "cosh", "exp", "ln", "log10", "log2", "sec",
<pmichaud>         "sech", "sin", "sinh", "tan", "tanh", "fact"
<DietCoke> yup. note that I think most of those already have _n_n variants.
<pmichaud> and that seems like a horribly lot of opcodes to generate if they're just going to be turned into method calls
<DietCoke> I'll all for dropping them, no arguments here.
<pmichaud> okay
<DietCoke> I was only considering it on the off chance you were going to ask for them.
<pmichaud> right now I'm on a "get rid of unneeded opcodes" bias
<DietCoke> You can switch over to the method syntax now.
<DietCoke> (if you want, you can try out the branch and see what breaks in perl6 there.
<DietCoke> (this whole thing, btw, is just to help me kill the getclass opcode. =-)
<pmichaud> I'm trying to focus on $_ handling today
<pmichaud> I was going to do it yesterday but family events kept me from really getting into it
<pmichaud> moritz:  instead of    a = ln a
<pmichaud> try
<pmichaud> a = a.'ln'()
<pmichaud> that switches it from being an opcode to a method call
% Whiteknight has joined #parrot
<moritz> pmichaud: no luck here
<pmichaud> hrm
<pmichaud> I suspect mmd issues then
<moritz> pmichaud: but focus on $_ first, that's much more important atm ;)
<pmichaud> I agree
* DietCoke has about a dozen checkouts of parrot on feather. Oy.
<dalek> r29009 | coke++ | no_builtin_methods:
<dalek> : Remove targets related to src/builtin.c
<dalek> : Add in some -j protection from trunk.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29009
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
<DietCoke> what generates this line in src/gen_builtins.pir for perl6: .sub 'exp' :multi(Complex)
<moritz> DietCoke: that's from src/classes/Complex.pir
<moritz> gen_builtins.pir seems to be the concatenation of src/classes/* and src/builtins/*
% rurban has left rurban!~rurban@212-183-58-223.adsl.highway.telekom.at
% rurban has joined #parrot
<DietCoke> ok. with a small change to Complex, all internal tests pass. checking the regression tests...
<nopaste> "coke" at 65.91.151.194 pasted "Use explicit method syntax..." (22 lines) at http://nopaste.snit.ch/13456
<dalek> r29010 | pmichaud++ | trunk:
<dalek> : [rakudo]: spectest-progress update: 83 files, 1365 passing tests
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29010
<DietCoke> (though looking at that, I'm wondering why I passed the argument in one case, and not the other.
<DietCoke> presumably I'll find out if something fails in the regression. =-)
<pmichaud> should _not_ be passing the argument, I suspect.
<DietCoke> eh, these methods are wierd, at least on the base float.
<pmichaud> we aren't calling the methods on the base float, though.
<pmichaud> rakudo's floating point sqrt currently uses sqrt_n_n
<DietCoke> ok. are these getting called on the root Complex object?
<pmichaud> probably not
<pmichaud> looks like it's a subclass of Complex
<DietCoke> ok. with that small patch, no problems with assuming any other builtins.
<pmichaud> excellent.  DietCoke++
<pmichaud> Coke++
<DietCoke> so, just figure out which PMC is actually getting those invoked to figure out if you need to pass it. if it's like Complex in core, you don't need 'em.
<pmichaud> (just to get all the karmas in the right slots :-)
<pmichaud> Float requires that it be passed?
<pmichaud> that's.....odd
<pmichaud> and perhaps even wrong.
<DietCoke> ah, no. I was confusing it with the string methods.
<pmichaud> okay
<DietCoke> (some of which require you pass IN a string to work on.)
<DietCoke> (even though, clearly, you've already got one.)
<pmichaud> okay, I'm going to focus on $_ for a while, so I might not answer unrelated questions :-)
<pmichaud> I might not even make any snide remarks :-)
<moritz> snide remarks = sneaky side remarks? ;-)
<pmichaud> <no remark here>
% rdice has joined #parrot
<particle> $_
<moritz> particle: implicit remark? ;-)
<pmichaud> .that_would_be_this
<moritz> pmichaud: you lost ;)
<pmichaud> I said *might*
<pmichaud> besides, $_ is clearly on topic  :-)
<particle> i'm just encouraging conversation about the current topic
<dalek> r29011 | pmichaud++ | rakvar:
<dalek> : drop branch to re-sync it with trunk
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29011
<dalek> r29012 | pmichaud++ | rakvar:
<dalek> : Recreate branch from trunk
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29012
% rjbs has left #parrot
% confound has left confound!~hdp@glaive.weftsoar.net
% confound has joined #parrot
% gmansi has joined #parrot
% Ontolog has joined #parrot
<dalek> r29013 | fperrad++ | trunk:
<dalek> : [Pipp] file_get_contents & readfile
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29013
<Ontolog> oh cool I'm logged publicly?
<pmichaud> http://irclog.perlgeek.de/parrot/today
<moritz> and http://irclog.perlgeek.de/perl6/today for #perl6
% AndyAway is now known as Andy
<dalek> r29014 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] changes to header allocators. Better separation between aggregate and non-aggregate types
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29014
% crapuleux is now known as cognominal
<dalek> r29015 | Whiteknight++ | gsoc_pdd09:
<dalek> : [gsoc_pdd09] updating to trunk r29014
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29015
<rurban> I've prepared now a patch which renames pdb to parrot_pdb - conflicts with existing pdb binaries. (python, ...)
<DietCoke> feather going down shortly.
<moritz> hard disk failure
<DietCoke> save early save oftne.
<moritz> commit often. (wait, that doesn't help if the svn repo is on feather... ;-)
<Whiteknight> is the repo mirrored anywhere?
% leo has left leo!lt@feather.perl6.nl
% PerlJam has left PerlJam!duff@193.200.132.135
% Juerd has left Juerd!juerd@193.200.132.135
% pmichaud has left pmichaud!pmichaud@feather.perl6.nl
% jonathan has left jonathan!jonathan@feather.perl6.nl
% dalek has left dalek!dalek@feather.perl6.nl
% polyglotbot has left polyglotbot!~evalbot@feather3.perl6.nl
<Infinoid> I didn't think the svn repo was on feather
% wolverian has left wolverian!wolverian@feather.perl6.nl
<DietCoke> ours isn't, no.
<particle> pugs repo is on feather
<particle> so, no spectest updates for a while
<particle> i hope moritz can deal with that :)
<moritz> particle: I'm writing the "how to add tests" howto, it'll take some time to finish before I want to commit it ;)
<cotto_home> moritz, are you putting something about make cover in there to see what still needs to be tested?
<moritz> cotto_home: Perl 6 spectest, not parrot tests :/
<cotto_home> gotcha
<particle> unless cotto_home has developed a coverage testing engine for perl 6...
<cotto_home> no such luck
% cjfields has joined #parrot
% james has joined #parrot
% rob has joined #parrot
% jan has joined #parrot
% magnachef has left magnachef!~magnachef@cpe-74-78-109-88.buffalo.res.rr.com
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% wolverian has joined #parrot
% dalek has joined #parrot
% leo has joined #parrot
% polyglotbot has joined #parrot
% cosimo has left cosimo!~cosimo@pat-tdc.opera.com
% pmichaud has joined #parrot
% PerlJam has joined #parrot
% rob has left #parrot
% Whiteknight has joined #parrot
% Ademan has left Ademan!~dan@h-68-167-207-191.snfccasy.dynamic.covad.net
<DietCoke> how can I easily do a diff of "stuff I've changed on branch foo as compared to trunk". do a reverse merge then an svn diff of my work dir?
% Ontolog has left Ontolog!~cdavaz@121.235.241.215
% Ontolog has joined #parrot
<particle> you wanna diff against head, or base?
<DietCoke> welp, I was thinking base originally,but since it would have to be applied against head... I'll just do it this way. =-)
% Juerd has joined #parrot
<particle> okie, that'll work
<DietCoke> hurm. annoying. I want -all the changes on that branch-, but I still have to specify start/end revisions.
<particle> svn log --stop-on-copy
<particle> that'll get you the rev number for branch creation
<DietCoke> I can get it, it's just annoying that svn merge isn't doing that -for- me. =-)
* DietCoke tells himself "this is still better than CVS." =-)
<moritz> DietCoke: that's one of the many reason why SVN sucks
% james has left #parrot
<dalek> r29018 | Whiteknight++ | vtable_self:
<dalek> : Creating branch to work giving vtable functions the self keyword
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29018
<DietCoke> hurm. now the merge seems to be picking up things it shouldn't.
<DietCoke> in a check out of trunk, I was running:
<DietCoke> svn merge -r28930:HEAD https://svn.perl.org/parrot/branches/no_builtin_methods/ .
<DietCoke> where 28929 is the revision that created the branch.
<DietCoke> moritz: in this case, most of the suck could be handled by a small wrapper script.
<moritz> DietCoke: or by native support for branches ;)
% Casan has joined #parrot
% sjansen has joined #parrot
% Casan has left Casan!~IceChat7@users163.kollegienet.dk
<particle> DietCoke: then why didn't you use 28929 in the merge?
% Ademan has joined #parrot
% jonathan has joined #parrot
<particle> see docs/project/committer_guide.pod
% magnachef has joined #parrot
<dalek> r29019 | Whiteknight++ | vtable_self:
<dalek> : [vtable_has_self] uploading initial patch to IMCC grammar. Modification to one test for desired behavior.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29019
% Theory has joined #parrot
% barney has joined #parrot
% Theory has left Theory!~Theory@72-254-45-237.client.stsn.net
% Theory has joined #parrot
<DietCoke> particle: doesn't seem to impact the update in the merge of wrong stuff.
<DietCoke> U    runtime/parrot/library/CGI/QueryHash.pir
<DietCoke> (If that was ever changed on branch, it was only because i merged changes from trunk.)
<japhb> Thank you, kid51 and moritz, for speaking up on behalf of git tools in the wee hours today.
<japhb> DietCoke: I think you're beginning to see why adherents to other source controls say that SVN merge is insane ....
<rurban> I'm ready now with my cygwin perl package and will update the Bug#56544 with the final install_files.pl patch.
% DietCoke has left #parrot
% kj has left kj!~IceChat7@193.1.100.105
<particle> rurban++
<rurban> we will see how useful the layout will be. I just put all the languages with the exe's and the docs and examples into one big parrot-languages package
<rurban> just parrot-perl6 is seperate. I didn't like it to be named as in fedora: "parrot-rakudo"
% Theory has left Theory!~Theory@72-254-45-237.client.stsn.net
<dalek> r29020 | pmichaud++ | rakvar:
<dalek> : [rakudo] implicit part 1
<dalek> : * Eliminate incorrect declarations from statement_block
<dalek> : * Add declare_implicit_var to allow controlled addition of implicit vars
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29020
<dalek> r29021 | bernhard++ | trunk:
<dalek> : [Pipp PHC] Fiddle with the SEA-rule. Pass hello_11.php.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29021
% tco has joined #parrot
<dalek> r29022 | pmichaud++ | rakvar:
<dalek> : [rakudo]: implicit vars #2
<dalek> : * Eliminate __MAYBE_NEED_TOPIC_FIXUP
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29022
<dalek> r29023 | pmichaud++ | rakvar:
<dalek> : [rakudo]:  implicit vars #3
<dalek> : * Anything that parses with a signature goes into $?BLOCK_SIGNATURED,
<dalek> :   even if the signature is empty or non-existent
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29023
% desertmax has joined #parrot
<dalek> r29024 | bernhard++ | trunk:
<dalek> : [Pipp PCT] Use correct sub for string concatenation.
<dalek> : Pass two more test cases in hello.t
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29024
% masak has left masak!~user@130.238.45.242
% AndyA has left AndyA!~andy@ca93nt.hexten.net
<dalek> r29025 | pmichaud++ | rakvar:
<dalek> : [rakudo]: implicit vars #4
<dalek> : * Change routine_def to initialize $_, $/, $! to be scalars
<dalek> : * $! and $/ in pblocks default to OUTER::<$!> or OUTER::<$/>
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29025
<dalek> r29026 | bernhard++ | trunk:
<dalek> : [Pipp PCT] use correct subs for string comparison.
<dalek> : Pass some more TODO tests.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29026
% silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net
<particle> pmichaud: how do you specify unlimited outer? i suggest either 0 or '*'
<particle> 0 would allow max to stay an int
<pmichaud> it's strictly internal at this point
<pmichaud> it will either be MAX_INT or -1, though
<pmichaud> because 0 will be used to indicate "search caller's scope"
% nnunley_ is now known as nnunley
<particle> i thought 1 was caller's scope
<particle> hrmm
<pmichaud> 1 is caller's outer scope
<particle> yeah, took another read to see that
<pmichaud> I don't have the params in yet for it (because don't want to add them if I don't need them), but the idea will be that !OUTER can specify the min and max depths
<particle> ##  start with caller's outer scope (i.e., outer depth is 2)
<particle> .local int depth
<particle> depth = 2
<pmichaud> with default of both being 1
<particle> that's a confusing comment
% peepsalot has joined #parrot
<pmichaud> the current scope is inside of !OUTER
<pmichaud> depth 1 is the caller's scope
<pmichaud> depth 2 is the caller's outer scope
<particle> yes, i see that.
<particle> however, the api comment refers to caller's immediate outer scope as 1
<pmichaud> ...api comment?
<pmichaud> oh, right
<particle> C<max> parameter specifies the maximum outer to search -- the default value of 1 will search the caller's immediate outer scope and no farther. 
<particle> so you have a magic number of 1 inside the sub
% slightlyoff has joined #parrot
<particle> you add to depth
<pmichaud> when I do    '!OUTER'('$foo', 3)     it means that I want to search up to 3 outer scopes from the current one
<pmichaud> which means I search up to 4 outer scopes from within !OUTER
% slightlyoff has left #parrot
<pmichaud> I can change depth to read    depth = min+1
<particle> yes, that's what i'd like :)
<particle> also, does it make sense to rename BLOCK_SIGNATURED to ROUTINE? the first isn't a very clear name, but i'm not certain the second is precise
<pmichaud> not every signatured block is a Routine
<pmichaud> for example,  -> $a { ... }    has a signature but isn't a routine
<particle> yeah, that's what i was thinking :(
% cjfields has left #parrot
<particle> and POINTY_OR_ROUTINE is ugly too
<pmichaud> and what I'm really getting at is that a PAST::Block has already been started, because we parsed a signature
<pmichaud> as opposed to creating a new PAST::Block at this point (e.g., for a bare curly)
<dalek> r29027 | pmichaud++ | rakvar:
<dalek> : [rakudo]:  implicit vars #5
<dalek> : * Change comment and definition of depth in !OUTER, per particle++
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29027
<particle> thanks, pmichaud++
<Tene> Hmm... I should push this stuff up before I forget about it.
<dalek> r29028 | tene++ | trunk:
<dalek> : [lolcode]
<dalek> : * Store params in $?BLOCK symtable.
<dalek> : * Store subs in $?BLOCK symtable.
<dalek> : * Start building a parse tree for expressions at compile time.
<dalek> : * Minor PCT typo fix.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29028
<Tene> pmichaud: I was looking into examining the lexical environment to find vars and subs that the compiler doesn't know about for lolcode, and I realized that in normal cases, the compiler is already running in the same environment that the compiled code will run in, so I can just do normal lookups instead of passing something in, afaict.  Can you confirm or deny that this is a sane plan?
<rurban> I cannot see jesse. I cannot mail to parrotbug@parrotcode.org from seamonkey my latest cygwin realinstall fixes. Not with attachments and not without.
<rurban> Should I just send them to the -porters list instead?
<NotFound> Tene: looks not sane to me, that way the code will no work same way when running a generated pbc.
<moritz> rurban: yes
<pmichaud> Tene:  it depends on the structure of the compiler
<cotto-work> particle, ping
<pmichaud> However, in some cases it is reasonable for the compiler to look at the existing environment for hints
<pmichaud> for example, things like eval() can do that
<cotto-work> the meeting is cancelled
<cotto-work> I'm really sorry to do that, but one Anandeep is sick and needs to be there
<particle> cotto-work: ack! oh, well
<particle> then i can start my vacation earlier
<Tene> >
<Tene> > Thanks.
<Tene> >
<Tene> > -Daniel
<Tene> >
<Tene> > ________________________________
<Tene> >
<Tene> > From: Stephen Weeks [mailto:sweeks@gurulabs.com]
<Tene> > Sent: Wed 7/2/2008 11:14 PM
<Tene> > To: Daniel Lyman
<Tene> > Subject: Re: RE : [Fwd: RE: fooru kernel module problem in GL250]
<Tene> >
<Tene> >
<Tene> >
% Tene has left #parrot
<Whiteknight> ...?
<NotFound> Wrong paste target?
<moritz> seems like ;)
% Tene has joined #parrot
<dalek> r29029 | Whiteknight++ | vtable_self:
<dalek> : [vtable_has_self] added some comments around to help me find my way through this IMCC mess.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29029
* Tene fail.
<moritz> Whiteknight++ # gsoc_pdd09 branch builds cleanly
<Tene> moritz: does it run, though?  I thought he said it didn't run yet.
<Whiteknight> it builds!?!
<Whiteknight> I mean, it didn't last time I checked
<moritz> Tene: it doesn't, "make test" segfaults on PGE.pbc
<Whiteknight> okay, that's more like it. That's it's been doing for me
<moritz> Whiteknight: I just updated, 'make realclean; perl Configure.pl && make -j 2', and it compiled ;)
<Whiteknight> what platform are you guys one?
<Whiteknight> s/one/on/
<moritz> Debian (32 bit i386)
<Whiteknight> holy crap, same as me
* Whiteknight has to go try it again now
<moritz> from a cross-platform development POV it's a boring platform
<moritz> because all the platform dependent failures happen on other OSses ;)
<NotFound> moritz: or at least, we do don't know if the problems we have are platform dependant, we fix anyway.
<Whiteknight> moritz, you're saying that it compiled all the way through? did it build PGE.pbc?
<dalek> r29030 | pmichaud++ | rakvar:
<dalek> : [rakudo]: implicit vars #6
<dalek> : Make subroutines to handle implicit vars in immediate blocks (e.g., 'if')
<dalek> : and in function blocks (e.g., 'for').
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29030
<moritz> Whiteknight: I think that the last output from 'make' was not an error
<moritz> Whiteknight: then I did a "make test", and it complained about PGE.pbc
<Whiteknight> I'm double-checking now. but if it works then it's a miracle
<moritz> trying again to confirm
<moritz> no error message in the last few lines, but 'make' had an exit status of 2
<Whiteknight> yeah, the -j hides the failure on PGE.pb
<Whiteknight> scroll up a bit and you can see the segfault
* moritz tries again without -j2 and without ccache
<particle> pmichaud: this refactor and enhancement is looking really good so far
<moritz> pmichaud: when you're done with your branch the autounfudge tool will really help ;-)
<particle> moritz: svn diff exists on windows, can you use that instead of diff?
<moritz> particle: don't think so, the files are not under version control
<Auzon> You can get GNU diff for Win32.
<moritz> particle: (unless you find a way to hijack svn diff for arbitrary files)
<dalek> r29031 | bernhard++ | trunk:
<dalek> : [Pipp PCT] Start to use optok parsing.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29031
<particle> i have diff on win32, but it's hard to make that a requirement
<moritz> particle: is it worse than requiring Algorithm::Diff and a custom workaround?
<particle> yes, it's worse
<particle> cpan requirements are better than non-cpan
<particle> from my pov. don't know how patrick feels
<moritz> ok, I'll see if I can find some tuits to work around it
<particle> write a diff util in rakudo
<particle> :)
% DietCoke has joined #parrot
<NotFound> Or in lolcode.
* DietCoke tries to summon dietcoke
<Tene> lolcode doesn't have IO yet.
<NotFound> Even better ;)
* DietCoke tries to summon dietcoke, one more time.
<PerlJam> What's Pipp?  Is that the new name for plumhead?
<Tene> Yes.
<PerlJam> cool
<rurban> moritz: I got now enough tuits to send email to parrotbug :)
<cotto-work> pipp is <reply>Pipp is Parrot's PHP
<rurban> moritz: problem was the missing -- bla --- bla markers
<cotto-work> purl, pipp is <reply>Pipp is Parrot's PHP
<cotto-work> purl--
% DietCoke has left DietCoke!~coke@cpe-72-228-52-192.nycap.res.rr.com
<rurban> I have to package the new clisp-2.46 now, and come then back to parrot. I believe some there are still some dynlib problems with wrong dll names for cygwin.
* particle heads for the rain forest. happy fourth! &
<cotto-work> take pictures!
<dalek> r29032 | fperrad++ | trunk:
<dalek> : [Pipp] add PMC PhpResource
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29032
<dalek> r29033 | bernhard++ | trunk:
<dalek> : [Pipp PCT] Add bitwise ops to optok parsing.
<dalek> : However readded tests are still TODO.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29033
<cotto-work> barney, does fperrad know that I've got an out-of-tree phparray implementation?
<cotto-work> I'd hate for there to be duplication on something like that
<barney> cotto: I don't know. Maybe we should do a #pippsketch
<cotto-work> getting him to hang out on #parrot would be sufficient
<barney> That's right.
<cotto-work> do you know why he doesn't?  His English seemed fine over email.
<barney> Probably simply personal taste
<PerlJam> cotto-work: why out-of-tree?  :)
<cotto-work> there's no accounting for taste
<cotto-work> I wrote some of it during working hours and need to get the legal dep't to clear it before I can commit
<PerlJam> oh.
<cotto-work> yeah
* barney is calling it a day
% barney has left barney!~bernhard@p549A1F58.dip0.t-ipconnect.de
% iblechbot has joined #parrot
<Whiteknight> Is there a way to determine whether a given PMC has an overridden Invoke vtable method?
<Whiteknight> or, whether it's invoke vtable is defined in PIR?
<Tene> Hmm... I wonder if I committed something I shouldn't have committed.
<pmichaud> ...now to see how much of spectest_regression is broken with my changes.
<dalek> r29034 | tene++ | trunk:
<dalek> : [lolcode]
<dalek> : * Oops, left some debug statements in.  Remove them.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29034
<Whiteknight> will the find_method vtable function find a vtable method if it exists, or will it only find methods?
<pmichaud> it only finds methods
<Whiteknight> is there something I can do to look up a vtable method then, given it's name?
<pmichaud> vtable methods aren't callable directly from pir, unless they're indicated via :method or are otherwise treated as a sub
<Tene> What is the consequence of running load_bytecode on the same pbc multiple times?
<pmichaud> tene:  if it's the same pathname each time, only the first load occurs.  Later ones are short-circuited.
<Tene> Fantastic.
<Whiteknight> okay, I think i'm thinking about the wrong problem
<pmichaud> parrot doesn't distinguish between  'foo.pir' and 'foo.pbc'  (those would each be loaded)
<pmichaud> and likely   'path/to/foo.pbc' and 'foo.pbc' would cause a double-load also
<pmichaud> we had some discussion years ago about embedding a uuid into the .pbc files to detect it based on the file..... but that didn't happen
<pmichaud> Whiteknight: if I define a vtable method in PIR as      .sub 'foo' :method :vtable('get_boolean')
<pmichaud> then I can only get to it as a method by using   $P0.'foo'
<pmichaud> er
<pmichaud> then I can only get to it as a method by using   $P0.'foo'()   --- i.e., find_method will only find the 'foo' entry
<nopaste> "tene" at 67.137.148.11 pasted "handle :lang in eval()" (47 lines) at http://nopaste.snit.ch/13457
<Whiteknight> pmichaud, I'm trying to fix invokations of the type $P0(), which calls the invoke vtable method
<pmichaud> Whiteknight: yes, I remember those being somewhat broken.  :-|
<Tene> That's a bit hackish, but it works until we actually have a registry solution of some sort.
<pmichaud> ...but I thought they were fixed now.  at least when I tested it a couple of months ago it seemed to do what I wanted
<Whiteknight> I think IMCC generates a callmethod opcode for that, and I think I can implement the solution directly in the opcode itself if I can figure out what I need
<Whiteknight> it probably works now, I'm trying to implement a patch where :vtable functions have the "self" keyword
<pmichaud> ....why would $P0() generate a callmethod opcode?  that seems....wrong
<Whiteknight> maybe it generates an invoke opcode, I'm having trouble reading this IMCC source
<pmichaud> invoke opcode would be correct, yes.
<Whiteknight> either way, I'll figure it out
<pmichaud> Whiteknight++
* pmichaud gets a stunned look
<pmichaud> <stunned look>....spectest_regression passed with my changes on the first attempt.</stunned>
<Tene> Nice.
<Whiteknight> pmichaud++
<pmichaud> that's.... scary.
<Tene> pmichaud: does it pass *more* tests, though?
<pmichaud> good scary, but still scary.
% rurban_ has joined #parrot
<pmichaud> Tene: if I remove a few 'skip' markers it might :-)
<PerlJam> pm: clearly your changes weren't broad and sweeping enough  :)
<pmichaud> I guess not.
<pmichaud> I guess I need broader and sweepier changes.
% rurban_ has left rurban_!~chatzilla@212-183-48-21.adsl.highway.telekom.at
<Tene> pmichaud: will you have tuits to look at that eval patch for me?
% allison has joined #parrot
% rurban has left rurban!~rurban@212-183-58-26.adsl.highway.telekom.at
<Tene> Seems to work fine with lolcode, but cardinal gives me some weird errors I need to look at.
<pmichaud> what if the name of the compiler doesn't match the name of the pbc?
<pmichaud> perhaps rakudo should have a registry of :lang values, at least short-term.
<Tene> That's too architectural for me to propose.
<Whiteknight> philosophical question: Instead of treating the "self" of a method as just the first in a list of arguments, could we create an interp->arg_self field and pass it in there separately?
<Tene> tcl gives me 'Null PMC access in find_method' and cardinal gives me "push_pmc() not implemented in class 'Sub'"
* Tene tries lua
<pmichaud> I really like the fact that self is the first argument
<pmichaud> it fits well for Rakudo and PGE
<dalek> r29035 | moritz++ | trunk:
<dalek> : [rakudo] added S03-operators/arith.t to spectest_regression. Auzon++
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29035
<dalek> r29036 | fperrad++ | trunk:
<dalek> : [Pipp] fopen, fclose & fpassthru
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29036
<Whiteknight> okay
<Tene> lua gives me "Unknown PMC type to thaw 0"
<Whiteknight> okay, let me ask from a different angle. If I overwrite the invoke vtable of the Sub pmc, what does that look like internally? How does parrot know whether to call the PIR method or the C method?
<Tene> APL works, except for encoding issues.
<pmichaud> I don't think you can overwrite 'invoke' of the Sub pmc, except via a subclass of Sub
<pmichaud> that's like saying  "how can I overwrite the get_integer vtable of the Integer pmc"
<Whiteknight> oh, I see what you are saying, so you cant have both a PIR and a C version of the same vtable method in the same class? That makes a little bit more sense
<pmichaud> I'm not even sure it's possible to overwrite a vtable method of a PMC class
<pmichaud> (from PIR)
<pmichaud> ...but if you can, then it would seem to replace any existing vtable method for that PMC class
<Whiteknight> okay, so that's only possible for PIR-defined classes and subclasses?
<pmichaud> I think so.  I'm not the architect, but that's my expectation.
% AndyA has joined #parrot
<Whiteknight> okay, so would you know if, at the C level, that there is a way to determine whether a particular vtable method is defined in C or PIR?
<Tene> Ooo... I get "continuation jumping runloops" trying to eval php from rakudo.
<pmichaud> Tene: I suspect that :lang on eval may need to wait on pdd25cx, then
<pmichaud> if not for rakudo (and others) to start using .HLL
<pmichaud> Whiteknight: I'm sure there's a way to find out if a vtable method is defined in C or PIR, but it seems like one shouldn't need to check that
% desertmax has left desertmax!~markus@62-47-167-219.adsl.highway.telekom.at
<Whiteknight> pmichaud, you would think so. PIR-defined vtable methods need to be passed the "self" argument, whereas C-defined versions already have it
<Whiteknight> "invoke methods"
<pmichaud> ...but wouldn't this be the same code that is already handling :method flags?
<Whiteknight> no. $P0() calls the invoke opcode, not the callmethod one
<pmichaud> let me put it another way
<pmichaud> currently if I do   
<pmichaud> .sub 'foo' :method :vtable('get_boolean')
<pmichaud> and then later do
<pmichaud> $I0 = istrue $P0
<pmichaud> then my 'foo' method gets invoked, and self is properly set to $P0
<pmichaud> note that there's no "callmethod" opcode here.
<pmichaud> so _something_ is already handling this.
<Whiteknight> okay, I think I'm explaining it wrong
<Whiteknight> I'm talking about the "invoke" vtable method only, not get_boolean or any others
<Whiteknight> if I have ".sub invoke :vtable", without the :method, the invoke function should have a "self" argument 
<pmichaud> ...but if you wrote   ".sub invoke :vtable :method"  it would work, right?
<Whiteknight> probably, yes
<pmichaud> that's what I mean "it's the same code that is already handling :method flags"
<pmichaud> we just want it to happen for :vtable even when :method isn't present.
<pmichaud> i.e., ":method" is in some sense redundant here --- every :vtable effectively implies :method
<Whiteknight> exactly. But IMCC can't determine whether "$P0()" calls a custom vtable override, however
<pmichaud> I don't think IMCC is what should be determining that.
<pmichaud> that seems like it's part of the vm itself
<Whiteknight> But IMCC sets up the code to pass the arguments, including the "self" argument
<pmichaud> ohhhhhhhh
<Whiteknight> so, based on syntax, if I call "foo.bar()" IMCC passes "foo" as the first argument to "bar"
<pmichaud> this gets back to my point earlier
<pmichaud> $I0 = istrue $P0
<Whiteknight> but If I call "$P0()" It won't pass $P0 as the first argument to it's invoke vtable
<pmichaud> IMCC doesn't have to know that $P0 is to be the first argument to 'foo' -- something else is doing that.
<pmichaud> same goes for $P0()
<pmichaud> IMCC shouldn't be responsible for passing the additional argument
<Whiteknight> Right, which is why I'm trying to find a more appropriate place to do it
<pmichaud> instead, the invoke opcode needs to be smart enough to say "oh, I'm going to a PIR vtable method, so pass the thing being invoked as its first argument."
<Whiteknight> Exactly, and if the invoke vtable method is a PIR function, we need to pass the invoked object as the "self" parameter first
<Whiteknight> currently, this is not happening, unless we do :method too
<pmichaud> and if    .sub 'invoke' :vtable :method    already works, then the 'invoke' opcode already has the logic for doing that
<pmichaud> (otherwise it wouldn't work.)
<Whiteknight> let me test quickly that it actually does work as I am expecting...
<pmichaud> yes, it's entirely possible that it doesn't work.
<Whiteknight> no, it doesnt work
<Whiteknight> nopaste?
<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/
<pmichaud> okay, so it's the invoke opcode that likely needs work
<pmichaud> but IMCC should always generate the same code for $P0()    (since IMCC can't know what $P0 is)
<Whiteknight> right, that's the conclusion I'm slowly arriving at
<Whiteknight> Yeah, I spent a lot of time reading through IMCC before I realized that
<pmichaud> ....actually, it's not even the opcode that needs to do it
<pmichaud> it's the invoke vtable method that needs to do it
<pmichaud> just a sec
<Whiteknight> http://rafb.net/p/nCAxGE45.html
<Whiteknight> this shows you what I'm trying to do, basically
<Whiteknight> i have the basics up and running in branches/vtable_has_self
<pmichaud> I get "invoke() not implemented in class 'Foo'"
<pmichaud> ah, missing a namespace
<nopaste> "tene" at 67.137.148.11 pasted "parrot dies on loading perl6.pbc and cardinal.pbc" (8 lines) at http://nopaste.snit.ch/13459
<pmichaud> okay, now I get "too few arguments"
<pmichaud> so :method doesn't help here
<Whiteknight>  right, it's attempting to slurp up "self" as the first argument, but a self was never passed
<Whiteknight> in C, it's always called self->vtable->invoke(interp, self, next_addr), so it has the self.
<pmichaud> I think the culprit is  src/pmc/object.pmc:528-529
% AndyA has left AndyA!~andy@ca93nt.hexten.net
<pmichaud> it could also be the invoke vtable method in Sub
<Whiteknight> is "object.pmc" a top-level class?
<pmichaud> yes.
<pmichaud> it's the base class for all PIR-class objects
<Whiteknight> I've been hunting for this kind of thing all day
<Whiteknight> and you find it in like 30 seconds
<pmichaud> I have a few years advantage in parrot
<pmichaud> also, I was recently in the invoke code when trying to figure out the lexical issues a couple of weeks ago :-)
<Whiteknight> so if I push on another argument in that place you pointed out, you think that will solve (or approximately solve) my problem?
% AndyA has joined #parrot
<pmichaud> I'm not sure.  I'm thinking maybe not.
<Whiteknight> well, I'm going to try it anyway
<pmichaud> there's got to be another step involved here somewhere
<Whiteknight> why do you say that?
<pmichaud> I'm trying to figure out how the 'istrue' opcode manages to set 'self'
<pmichaud> istrue just becomes a call to the get_bool vtable method
<pmichaud> and somehow that vtable method manages to set self when calling a PIR-based method
<Whiteknight> does is_true have self in trunk?
<pmichaud> lost me there.
<Whiteknight> IMCC currently doesnt parse the keyword "self" unless the :method tag is on a sub
<pmichaud> right, I mean when :method is present it works somehow
<pmichaud> and I don't mean from the IMCC perspective
<Whiteknight> okay
<pmichaud> I mean from the vtable activation perspective
<pmichaud> somehow when the get_boolean vtable method is activated, it manages to pass the PMC as the first argument to the corresponding PIR sub
<pmichaud> (which IMCC then picks up as :self because of the :method flag)
<pmichaud> er, s/:self/self/
<Whiteknight> so the question is, how does istrue pass that first argument?
<pmichaud> more precisely, how does get_boolean do it.
<pmichaud> (or get_integer, or get_pmc_indexed_keyed, or any of the other vtable methods besides 'invoke')
<pmichaud> the 'invoke' vtable method seems to be the only one that isn't passing a first argument as 'self'
<Whiteknight> I think it's because of the way IMCC parses it
<pmichaud> nononononono
<pmichaud> you're too fixated on IMCC, I think :-)
<Whiteknight> That has to be a component of if
<pmichaud> (easy to do :-)
<Whiteknight> or, problems in IMCC lead to workarounds elsewhere
<pmichaud> all that IMCC needs to do is recognize that when :vtable is present that it needs to recognize self
<pmichaud> in the same way that it does for :method
<pmichaud> but that doesn't change at all the way the vtable methods are *invoked*
<Whiteknight> well, it does that now in my branch
<pmichaud> because IMCC doesn't invoke vtable methods
<pmichaud> in particular, IMCC has no control over what arguments are sent to vtable methods -- all it does is say what to do with them when they're received
<Whiteknight> I think I see your point
<Whiteknight> so then it does come down to a problem with the invoke vtable method not passing it's "self" correctly
<pmichaud> correct
<pmichaud> do we have an example of an 'invoke' vtable method written in PIR that works?
<pmichaud> (either with or without :method?)
<Whiteknight> well, no. 
<pmichaud> well, there ya go.  :-)
<Whiteknight> all current tests are written using the "vtable doesnt have self" rule, so all the tests for it break when we add it because there aren't enough arguments floating around
<pmichaud> getting IMCC to recognize :self with :vtable is probably a separate issue from getting the invoke vtable method to properly pass self.
<pmichaud> ...they are?
<pmichaud> whoa
* pmichaud checks
% AndyA has left AndyA!~andy@ca93nt.hexten.net
<Whiteknight> Yeah, t/pmc/parrotobject.t has about 3 or 4 tests that die when we enable "self" parsing
<Whiteknight> t/pmc/namespace.t has one also
<pmichaud> oh, but that's not "all current tests"
<pmichaud> most of the tests in t/   for :vtable have :method also, which means that they recognize 'self'
<pmichaud> ack ':vtable' t
<Tene> pmichaud: is it that .HLL works fine but isn't used by most HLLs, or is .HLL not fully implemented?
<Whiteknight> Most are testing the "init" vtable, all the ones testing the invoke vtable without :method fail
<pmichaud> Tene: it's that PCT isn't HLL aware yet, and we have to work out the symbol export/import issues
<Tene> Hmm.  Okay.
<pmichaud> Whiteknight: I think the first goal should be to get :vtable to be able to pass the present set of tests (that are currently passing) without requiring :method
<Tene> So now I need to learn about .HLL
<pmichaud> Tene:  in particular, when a language adds .HLL, then all of its symbols appear in a namespace separate from other HLLs
<Whiteknight> pmichaud, that's what I'm working on now. But without proper "self" passing, all the tests don't get enough arguments.
<pmichaud> Whiteknight: right, so it's just a matter of getting imcc to recognize that :vtable should cause self
<pmichaud> but those tests that aren't currently passing (such as invoke :vtable) probably won't start passing because of that
<Whiteknight> I have that done already. IMCC recognizes self in :vtables in my branch
<Whiteknight> but allowing the keyword isn't the same as making sure a value gets passed for it
<Tene> pmichaud: would making PCT be .HLL-aware be a pretty significant redesign of PCT, or just a modification?
% AndyA has joined #parrot
<pmichaud> Tene: significant -- I'll explain in a second
* Tene can wait. :)
<pmichaud> Whiteknight: I think we're in pretty close agreement (more)
<pmichaud> I'm saying that having :vtable work without :method for the existing tests that pass is worth committing.
<pmichaud> I'm also saying that getting self to work on those vtable methods where it's not presently working is probably a separate bug/issue
<pmichaud> in other words
<pmichaud> if I can write
<pmichaud> .sub 'foo' :vtable('get_boolean')    # note, no :method
<pmichaud> and have the istrue opcode dtrt and that 'foo' has a self symbol locally defined, then that's really what the original ticket was trying to address
<Whiteknight> ok
<Whiteknight> I don't like committing things that break tests though!
<pmichaud> which tests break?
<pmichaud> I guess that's the part I don't quite understand.
<moritz> pmichaud: how's your rakvar branch going?
<dalek> r29037 | moritz++ | trunk:
<dalek> : [rakudo] add S04-statements/repeat.t to spectest_regression
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29037
<Whiteknight> t/pmc/parrotobject.t and t/pmc/namespace.t
<pmichaud> moritz: very well.  All of the spectest_regression tests still pass.
<pmichaud> Whiteknight: ohhhhhhhhhhhh
<pmichaud> i get it, i get it
<pmichaud> I can help there I think, just s ec
<moritz> pmichaud: Woot!
<pmichaud> moritz: yes, I'm a little taken aback and surprised.  I've had to double-check to make sure I'm not accidentally running spectest_regression from trunk :-)
<pmichaud> moritz: once I get .implicit_invocant  working I'll merge back to trunk.
<moritz> pmichaud++
<pmichaud> Whiteknight: for   the :vtable test in t/pmc/namespace.t, I will argue that the test itself is incorrect.  It should require a string parameter.
<Whiteknight> yes, I've modified that one in my branch already. It's the ones in t/pmc/parrotobject.t that are eluding me
<pmichaud> okay, let me look at those.
<pmichaud> ...what ticket started this whole mess again?  ;_)
% clunker3__ has joined #parrot
<Whiteknight> #47674
<pmichaud> okay
<pmichaud> I think allison sent you down a false trail in trying to look at expand_pcc_sub_call
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-197-27.dynamic.mnet-online.de
<pmichaud> I could be wrong about that, but that's my guess
% clunker3 has left clunker3!~IRC@procura.xs4all.nl
% allison has left allison!~chatzilla@68-248-62-131.ded.ameritech.net
<Whiteknight> yes, it was a bit of a false trail. It looked enticing, but it just wasn't correct
% teknomunk has joined #parrot
% clunker3__ is now known as clunker3
% tco has left tco!~ToddOlson@purrr.cit.cornell.edu
<pmichaud> sorry, got interrupted here
<Whiteknight> I think I have it mostly figured out, I can't determine how to push a new argument onto the argument list, however
<pmichaud> vtable arguments are fixed
<Whiteknight> no, I mean the arguments passed to the PIR vtable method
<pmichaud> oh, that.  yeah, I don't know how that happens either.
<pmichaud> anyway, I think we're well beyond the edge of my knowledge now -- hope I didn't throw you onto any more false trails
<Whiteknight> looking at the seg_args and get_params opcodes, I still can't figure out how
<Whiteknight> it's okay, I think I'm going to have to send Allison an email about it
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
<pmichaud> Tene:  (HLL)   Parrot has a number of HLL namespaces
<pmichaud> right now PCT and PGE both live in the 'parrot' HLL namespace
<pmichaud> (and that's where they're likely to remain)
* Tene listens.
<pmichaud> but things like rakudo and tcl and lolcode and the like should really live in their own namespaces
<Tene> Right.
<pmichaud> which means that when we got to look up  a symbol like  PAST::Op, we have to either (1) know to go look for it in the 'parrot' HLL namespace, because that's where PCT lives, or (2)  import the PCT symbols into the current HLL namespace
<pmichaud> s/got/go/
<pmichaud> same for PGE and P6object
<pmichaud> in fact, with P6object, when we go to create a new class, we want the protoobjects for that new class to be created in the caller's HLL namespace, not in P6object's
<pmichaud> as well as any methods that get created or imported
<pmichaud> for the choice between (1) and (2) above, currently I'm thinking the best option will be to import the PCT symbols into the current HLL namespace
<pmichaud> but I'd like to have a way of doing that which doesn't require each HLL to specify all of the symbols that ought to be imported
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
<bacek> morning everyone
* Tene nods.
<pmichaud> I'm planning to create a branch to get rakudo into its own HLL -- that might actually be a good task for as soon as I get the lexicals worked out
<pmichaud> at the same time we could play with getting other languages into their own HLL as well (and do it in the same branch)
<Tene> pmichaud: is there currently a way to get the caller's HLL namespace?
<pmichaud> I suspect via getinterp there may be.  It's one of those things I need to look at.
<pmichaud> if you wanted to figure that out it'd be a big help :-)
<pmichaud> although it wouldn't surprise me if Tcl already does it :-P
<pmichaud> (Tcl being the best example of using .HLL that we have to date)
<Tene>   $P0 = getinterp
<Tene>   ns  = $P0['namespace'; 1]
<Tene> in tcl
<Tene> Let's see what's in there.
<pmichaud> does that get namespace or hll namespace?
<pmichaud> we really want/need the hll namespace
<pmichaud> _alternatively_
<pmichaud> we could pass the hllnamespace to p6object
<pmichaud> and it would just store it there.
<Tene> Oh, true.
<Tene> That might be nice as an option anyway.
<pmichaud> yes.
<pmichaud> but somehow I still think it's useful if p6object is hll aware
<Tene> Looks like no.
<NotFound> Someone has at hand some pir that fails because of gc problem?
<Tene> pmichaud: getinterp['namespace'].get_name()[0] ha sit
<Tene> s/ha sit/has it/
% Ademan has left Ademan!~dan@h-68-167-207-191.snfccasy.dynamic.covad.net
<pmichaud> Tene++
<pmichaud> afk for a while # going out for dinner
<Tene> However, that's the *current* namespace, not of the caller.
* Tene finds of caller
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<Tene> getinterp['namespace';1].get_name()[0] has caller's
<bacek> nopaste?
<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/
<nopaste> "bacek" at 202.7.166.165 pasted "infix:xx= implementation for moritz/pmichaud (S03-operators/repeat.t is #pure after this patch)" (22 lines) at http://nopaste.snit.ch/13461
<bacek> afk # $dayjob->accept($self)
% Ademan has joined #parrot
<moritz> that patch leads us to the question: should we implement all those combined infix + asignment operators manually, or should we wait for another big refactor and generated them automatically?
% peepsalot has left peepsalot!~peepsalot@bwext.kpimdp.com
% silug has joined #parrot
* moritz temporarily retires to his bed
* Tene go home now.
% teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net
% slightlyoff has joined #parrot
% slightlyoff has left #parrot
% AndyA has left AndyA!~andy@ca93nt.hexten.net
% rdice has joined #parrot
% tetragon has joined #parrot
% AndyA has joined #parrot
<pmichaud> (implement combined ops):  I think for ops that we have specific (and likely used) tests for, we can go ahead and generate the manually.  But I wouldn't make any special effort to generate them all, as eventually they'll be done automagically.
% bacek_ has joined #parrot
<japhb> pmichaud: Will the automatic generation for op/assign just create "A = A op B"?  If so, that's an efficiency problem.  Nice as a fallback, but not what I'd want for the standard set ....
<pmichaud> automatic generation will create A = A op B for those ops that aren't already previously defined.
<pmichaud> i.e., it'll be a fallback
% AndyA has left AndyA!~andy@ca93nt.hexten.net
% Casan has joined #parrot
% AndyA has joined #parrot
% nopaste has left nopaste!~opaste@202-154-105-237.people.net.au
% clochette has joined #parrot
% clochette has left clochette!~clochette@212-198-248-33.rev.numericable.fr
% nopaste has joined #parrot
% Casan has left Casan!~IceChat7@users163.kollegienet.dk
% Coleoid has joined #parrot
% kid51 has joined #parrot
<Coleoid> I'm trying to build parrot on win32, and it's dying on 'stack_common.o: no such file or directory'.
<Coleoid> I was getting further, earlier, say last week, when I could create a working rakudo exe...
<Coleoid> But I svn upped, and now it stops here, even after a make clean.  Any ideas, anyone?
% Theory has joined #parrot
<kid51> Here's an idea that probably *won't* apply in this case:  'make realclean' before 'svn up'.  'realclean' removes files created during both configuration and build; 'clean' only deletes files built during build.  That being said, I suspect your problems are more rakudo-specific and/or more win32-specific -- and I'm not expert on either.
<Coleoid> Well, thanks--I'll take even ideas that (probably) won't apply here...  I'm learning, so it all goes in the hopper.
<Coleoid> So are there tricks to 'perl Configure.pl' that might help me out?
<kid51> Let me ask something more specific:  Is your failure occuring during Parrot's 'make' or during make perl6?
<Coleoid> During parrot's make.
<kid51> Oh, then  I misunderstood.
<kid51> But in that case, I would first try: make realclean;svn up;perl Configure.pl;make
<kid51> ... if only to rule out possibility that your error was caused by some transient bug that has been fixed by an updated commit.
* kid51 is now following his own advice -- but on Linux
<kid51> Where's that nasty bot purl?
<Coleoid> purl, make?
<kid51> Taking a very long weekend?
<kid51> No she's not there.  Wasn't there this morning IIRC.
<Coleoid> Nothing new when I updated...
<Coleoid> Rebuilding...
* kid51 successfully configured and built on Linux -- but then I'm successful 99% of the time there.
<kid51> If you get a make error, paste it.
<Coleoid> Which paste is preferred here?
<kid51> If purl were here, she'd list all of them.
<Coleoid> :D
<kid51> Try http://nopaste.snit.ch
<kid51> (our 'nopaste' bot's home)
<kid51> Even after 'make', I have no file with name matching 'stack_common' on Linux.
<Coleoid> Hey, the make succeeded, big smile.  Now 'make test'.
<Coleoid> Or more literally, "mingw32-make test", but same thing.  Except to my carpal tunnels, who lodge a faint protest.
<kid51> googling for 'stack_common.o' shows that it is a Parrot-related file.  It was mentioned in RT 56012 on Jun 19.
<Coleoid> So your 'realclean' suggestion may have been the ticket.
<Whiteknight> stack_common.c was removed this week from the build
<Coleoid> ...
<Whiteknight> you need to svn update to get the most recent version, and then make realclean to delete the old makefile
* bacek_ wander why S29-str/uc.t not in spectest_regression.
<Coleoid> ...so that Configure.pl will create one without the obsolete ref to stack_common?
<Whiteknight> yes, exactly
<Coleoid> 'make test' failed.
<kid51> Whiteknight beat me to it.
<Coleoid> Mostly successful.
<kid51> Which tests failed?  You can post those.
<nopaste> "Coleoid" at 76.251.83.159 pasted "'make test' parrot failure on win32" (21 lines) at http://nopaste.snit.ch/13463
<Coleoid> These were the only clear failures.
<kid51> Whiteknight:  Based on latest post, you may be able to resolve http://rt.perl.org/rt3/Ticket/Display.html?id=53394
<Coleoid> Others had 'skipped' comments.
<kid51> ... that is, unless what Coleoid just posted re t/examples/pir.t is relevant to that ticket.
<kid51> Coleoid:  Glad you posted that, since one of those tests I just committed last night!
<Coleoid> :D
<Coleoid> I'm glad to post more about my config, or try to tweak it.
<kid51> Can you paste the output of perl -V
<kid51> ... and your SVN revision number?
<kid51> I've pasted your paste into http://rt.perl.org/rt3/Ticket/Display.html?id=43334
<nopaste> "bacek" at 211.29.157.151 pasted "Fix exporting sqrt/exp in Complex (for pmichaud/moritz)" (14 lines) at http://nopaste.snit.ch/13464
<nopaste> "Coleoid" at 76.251.83.159 pasted "Coleoid 'perl -V'" (48 lines) at http://nopaste.snit.ch/13465
<Coleoid> ... SVN revision number.
<Coleoid> I was at 1.4.6.  I'll double-check.  Now that there's a prebuilt 1.5.0 out for win32, I'm happy to upgrade...
<kid51> No, I meant Parrot's version number.
<kid51> Also, when you ran perl Configure.pl, what was the output for the following step:
<kid51> Determining whether ICU is installed...................................
<Coleoid> How do I get parrot's version #?
<kid51> Among other ways, it should appear in your Configure.pl output immediately ahead of the step I just mentioned.
<kid51> Also:  svn up or svn info
<nopaste> "Coleoid" at 76.251.83.159 pasted "Coleoid 'perl Configure.pl'" (90 lines) at http://nopaste.snit.ch/13466
<nopaste> "Coleoid" at 76.251.83.159 pasted "SVN up and SVN info" (14 lines) at http://nopaste.snit.ch/13467
<kid51> okay, so you're at HEAD and you don't have ICU installed.  I will try to diagnose.
<Coleoid> Having ICU complicates?
<kid51> No, that configuration step probes your system to see if ICU is installed.  There are various command-line options you could have specified as well, but I assume that you did not.  So the tests in t/steps/auto_icu*.t are designed to exercise all the nooks and crannies of that code, e.g., to see if we can reach all of the return points.  So if you don't have ICU installed, the tests mock both installed and not-installed cases.  If
<kid51>  I've written the tests correctly, they should pass on *any* OS.
<kid51> For example, I do not have ICU on my iBook.  So the actual configuration step reports "no" -- just like yours.  But the test of the mocked situation passes on my iBook, but fails on your win32.
<kid51> See http://thenceforward.net/parrot/coverage/configure-build/config-auto-icu-pm.html for coverage results
<kid51> I have to get some dinner BBL
% kid51 is now known as kid51_at_dinner
<bacek_> purl?
<bacek_> she's gone...
<Coleoid> Good summary.  So the test is reporting 'no' in each case, but in mine it's failing with an unexpected "expected: 'failed'",
<bacek_> pmichaud: moritz: I've created correct patch for Complex.sqrt|exp. Attached to RT #56230 
<Coleoid> Which sounds like a test-framework issue.
<Coleoid> bacek_:  She's off at an early beach party.
<bacek_> drinking with Bender again...
<Coleoid> :D  Working on her 'I hate humans' levitator speech.
% Ademan has left Ademan!~dan@h-67-101-101-92.snfccasy.dynamic.covad.net
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
% stupidbot has left stupidbot!bacek@123-243-38-218.tpgi.com.au
% stupidbot has joined #parrot
% Ademan has joined #parrot
% Coleoid has left Coleoid!~Coleoid@adsl-76-251-83-159.dsl.bltnin.sbcglobal.net
% bacek has joined #parrot
% Coleoid has joined #parrot
<kid51_at_dinner> Coleoid:  Can you try the following:  perl Configure.pl --verbose-step=auto::icu
% kid51_at_dinner is now known as kid51
<Coleoid> Sure--a moment...
<dalek> r29038 | pmichaud++ | rakvar:
<dalek> : [rakudo]: implicit vars #7
<dalek> : Refactor <dotty> a bit.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29038
<nopaste> "Coleoid" at 76.251.83.159 pasted "win32 'perl Configure.pl --verbose-step=auto::icu'" (93 lines) at http://nopaste.snit.ch/13468
<Coleoid> Success.  The make'
<Coleoid> succeeded too.
<Coleoid> make test running.
<kid51> Well, it doesn't actually address the problem you reported.  That problem will not impede 'make' (which is, of course, a good thing).
<Coleoid> Is this specifically for the 'got no, expected failed' problem?  Because that recurred, though 'make test' isn't finished yet.
<nopaste> "Coleoid" at 76.251.83.159 pasted "win32 still failing ICU test" (8 lines) at http://nopaste.snit.ch/13469
<Coleoid> Sorry.  :/
<nopaste> "kid51" at 71.247.42.135 pasted "Coleoid: Try this patch for config/auto/icu.pm (re-run perl Configure.pl --verbose-step=auto::icu" (15 lines) at http://nopaste.snit.ch/13470
<Coleoid> trying...
<kid51> To diagnose and cure this test failure, you don't need to run 'make test'.  It's a test of the configuration system, which exists before 'make' creates the parrot executable.
<kid51> Wait, that patch is actually insufficient.
<Coleoid> Okay, applied patch, waiting for another.
<nopaste> "kid51" at 71.247.42.135 pasted "Better diagnostic patch for config/auto/icu.pm" (15 lines) at http://nopaste.snit.ch/13471
<kid51> Do svn revert config/auto/icu.pm before applying 2nd patch.
<Coleoid> I'm eyeballing/handpatching--I undid the earlier as I pasted in the newer.
<Coleoid> So having altered the icu.pm, I should Configure.pl again?
<kid51> Yes, with --verbose-step=auto::icu as command-line option
<Coleoid> ((It's grievous, I know, but if I wait until I get all the tools, I'll be here 'til I'm fifty before I contribute.))
* kid51 by definition > 50
<Coleoid> :D
<Coleoid> By definition != kid?
<kid51> 'patch' is *very* useful, albeit imperfect.  You can probably get a GNUWin32 version.
<kid51> http://gnuwin32.sourceforge.net/packages/patch.htm
<Coleoid> I expect so.  Or I may already have one, given I've installed mingw32 and cygwin.
% bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au
<kid51> Well, IIUC, cygwin is like a different environment.  I would expect it to have a 'patch' program.  But I wouldn't necessarily expect GNUwin32 'patch' to work inside cygwin.
<kid51> But, then, I haven't used cygwin in > 5 years.
% stupidbot has left stupidbot!bacek@123-243-38-218.tpgi.com.au
<nopaste> "Coleoid" at 76.251.83.159 pasted "Configure.pl, after realclean and patched icu.pm" (97 lines) at http://nopaste.snit.ch/13473
% stupidbot has joined #parrot
<Coleoid> Kicked off 'make' in the meantime.  Back in a minute.
% Ademan has left Ademan!~dan@h-67-101-146-23.snfccasy.dynamic.covad.net
% bacek has joined #parrot
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
<Coleoid> make without errors.
<nopaste> "kid51" at 71.247.42.135 pasted "config/auto/icu.pm: Take 3" (49 lines) at http://nopaste.snit.ch/13474
<Coleoid> Now you said ' make test' wasn't useful, here?
<Coleoid> I'll apply patch 3...
* Coleoid examines patch 3, boggles quietly.
<Coleoid> Okay, so how do I use 'patch'?
<Coleoid> :D
<kid51> No.  The fact that t/steps/auto_icu-04.t is an element of 'make test' is something of an artifact.   All the tests in t/configure and t/steps should, in principle, be run *before* Configure.pl (which, in turn, is of course run before 'make').  You can do that with perl Configure.pl --test=configure.
<kid51> patch -p0 config/auto/icu.pm < /path/to/patch
<Coleoid> Thanks.  Attempting.
<kid51> Of course, you should do svn revert before applying ... because I'm pulling the patch against HEAD.
<Coleoid> Will do.
<kid51> or perhaps on Win32:  patch -p0 config/auto/icu.pm < C:\\path\to\patch
<Coleoid> applied as 'patch -p0 config\auto\icu.pm <p3.txt'
% Ademan has joined #parrot
<Coleoid> ...grrr.
<Coleoid> Including a bit more context, as it looks a bit odd all around:
<nopaste> "Coleoid" at 76.251.83.159 pasted "Configure.pl, after patch 3." (41 lines) at http://nopaste.snit.ch/13475
<Coleoid> That was with the '--test=configure' argument.
<kid51> Ah, I perhaps you should have said:  perl Configure.pl --test=configure --verbose-step=auto::icu
<kid51> To save time, can you just re-run:  perl Configure.pl --verbose-step=auto::icu
% TiMBuS has joined #parrot
% Theory has left Theory!~Theory@207.102.78.66
<nopaste> "Coleoid" at 76.251.83.159 pasted "Post patch3 of icu.pm, 'perl Configure.pl --verbose-step=auto::icu'" (102 lines) at http://nopaste.snit.ch/13476
<Coleoid> Thanks for all of your help so far.  I hope this gets the error unraveled.
<Coleoid> Out now, LMK if I can help later.
<dalek> r29039 | jkeenan++ | trunk:
<dalek> : TODO-ing test based on error report from Coleoid.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29039
<dalek> r29040 | pmichaud++ | rakvar:
<dalek> : [rakudo]:  implicit vars #8
<dalek> : * Move '.*', '.?', '.+' into Object
<dalek> : * Enable .implicit_method .
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29040
<bacek_> pmichaud++ # And go sleep! It's late/early! :)
% kid51 has left kid51!~jkeen@pool-71-247-42-135.nycmny.east.verizon.net
<pmichaud> only 23:10 here.
<pmichaud> and I'm wanting to merge the branch back to trunk
<bacek_> pmichaud: ok... My math ability faded...
% cotto_home has left cotto_home!~cotto@96-26-202-243.sea.clearwire-dns.net
% Ademan has left Ademan!~dan@h-67-101-44-52.snfccasy.dynamic.covad.net
<dalek> r29041 | pmichaud++ | trunk:
<dalek> : [pct]:  merge from rakvar branch
<dalek> : * Allow the name attribute for 'call' and 'callmethod' nodes
<dalek> :   to contain a PAST tree, which is then evaluated to produce
<dalek> :   the name of the sub/method to be invoked.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29041
<dalek> r29042 | pmichaud++ | trunk:
<dalek> : [rakudo]:  merge rakvar branch into trunk
<dalek> : * Better handling of $_, $!, $/ initialization in blocks and routines.
<dalek> : * Refactor <dotty> and <methodop>
<dalek> : * .implicit_method now works
<dalek> : * Move .?, .*, .+ handlers into Object.
<dalek> : * all spectest_regression tests still pass
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29042
<bacek_> pmichaud++ # one ++ is not enough for this commit :)
% Ademan has joined #parrot
% Ademan has left Ademan!~dan@h-67-101-43-99.snfccasy.dynamic.covad.net
% Ademan has joined #parrot
<bacek_> perl6: say -1.abs;
<polyglotbot> OUTPUT[Method 'abs' not found for invocant of class 'Int'␤current instr.: '_block11' pc 31 (EVAL_10:17)␤called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:469)␤called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1088 (src/PCT/HLLCompiler.pir:598)␤called from Sub
<polyglotbot> ..'parrot;PCT::HLLCompiler;command_line' pc 1267 (src/P...
% tetragon has left tetragon!~seneca@76-10-148-120.dsl.teksavvy.com
<pmichaud> yes, I'm working on it now.
<pmichaud> as soon as my spectest runs I'll commit.
<pmichaud> lots of the builtins need refactoring now.
<pmichaud> I'm also going to change the file structure a bit
% Psyche^ has joined #parrot
% Patterner has left Patterner!~Psyche@e177225010.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<bacek_> pmichaud: BTW, mutating_listops are evil... We can't implement 'true lazy lists' if we want them...
<pmichaud> what do you mean by 'mutating listop' and 'true lazy lists'  ?
<bacek_> map {  $_=2*$_ } @list;
<bacek_> list is something like (1..100000);
<pmichaud> oh, that's no problem
<pmichaud> 'map' is just a gather/take sequence
<bacek_> without mutating lisops we can just clone Range and iterate over it.
<dalek> r29043 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Update C<abs> function and method
<dalek> : * Start refactoring builtin methods and functions
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29043
<nopaste> "bacek" at 211.29.157.151 pasted "Failing spectest_regression." (17 lines) at http://nopaste.snit.ch/13477
<bacek_> t/spec/S12-methods/calling_syntax.t
<pmichaud>  did you rebuild parrot, or at least pct?
<pmichaud> that looks like pct wasn't updated.
<pmichaud> bbiab
<bacek_> pmichaud: probably no...
<bacek_> shame on me...
<bacek_> pmichaud: http://rt.perl.org/rt3/Ticket/Display.html?id=56230 (there proper fix for Complex.sqrt and exp).
<dalek> r29044 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * move more builtins into src/builtins/num.pir
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29044
<dalek> r29045 | pmichaud++ | trunk:
<dalek> : [rakudo]:  update Complex.exp and Complex.sqrt
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29045
% Ademan has left Ademan!~dan@h-67-101-46-173.snfccasy.dynamic.covad.net
% barney has joined #parrot
% barney has left barney!~bernhard@p549A0443.dip0.t-ipconnect.de
% masak has joined #parrot
<dalek> r29046 | pmichaud++ | trunk:
<dalek> : [rakudo]:  More builtin method refactors.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=29046
% Ademan has joined #parrot