% davidfetter has left davidfetter!~davidfett@start.fetter.org
% uniejo has joined #parrot
% marmic has left marmic!~chatzilla@89-253-66-101.customers.ownit.se
% kj has joined #parrot
% marmic has joined #parrot
% jrt4 has left jrt4!~bojangles@c-24-18-106-126.hsd1.mn.comcast.net
% jrt4 has joined #parrot
<svnbotl> r26531 | fperrad++ | trunk:
<svnbotl> : [pct]
<svnbotl> : update doc
<svnbotl> r26532 | fperrad++ | trunk:
<svnbotl> : [Lua]
<svnbotl> : minor refactor
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26532
% iblechbot has joined #parrot
% contingencyplan has left contingencyplan!~contingen@76.186.27.146
% ruoso has joined #parrot
% wknight8111 has joined #parrot
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% IllvilJa has joined #parrot
% skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net
% rdice has joined #parrot
% rdice has left rdice!~richarddi@CPE001217e365c7-CM00159a01d44c.cpe.net.cable.rogers.com
% marmic has left marmic!~chatzilla@89-253-66-101.customers.ownit.se
% marmic has joined #parrot
<bgeron> Coke: ah, I thought you were, sorry :)
<bgeron> I'll mail soon then (at school now)
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-201-147.dynamic.mnet-online.de
% skids has joined #parrot
% particl1 has joined #parrot
% gryphon has joined #parrot
% jq has left jq!~jquelin@merlin.mongueurs.net
% jq has joined #parrot
% wknight8111 has joined #parrot
% iblechbot has joined #parrot
% rdice has joined #parrot
% Andy has joined #parrot
% lathos has left lathos!~simon@morison.arjam.net
% davidfetter has joined #parrot
% avar has left avar!avar@u.nix.is
% avar has joined #parrot
% lathos has joined #parrot
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
<Coke> lathos: hio. Any feedback on the feedback, or is that in allison's court now?
<lathos> Allison is editing it all up.
<Coke> ok.
<svnbotl> r26533 | kjs++ | trunk:
<svnbotl> : [pct] Fix some NQP in the comments, to make it actually work, if needed. So, no changes are made to executable code, only to the NQP in the comments that is implemented in PIR. This as a preparation of a possible bootstrap of NQP. 
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26533
<pmichaud> kjs++
<kj> oh hi patrick. Congrats on your marriage!
<pmichaud> thanks!
<pmichaud> we're very happy :-)
% sjansen has joined #parrot
<kj> that's good to hear :-)
<kj> and good to see you back on #parrot :-)
<kj> I tried to bootstrap NQP this afternoon. I got it working mostly, but I couldn't use this version to compile my tutorial language.
<pmichaud> glad to be back 
<kj> there are some parts that must be fixed before it can work.
<Coke> http://groups.google.com/group/perl.cpan.testers/msg/3173bc9642dfc981?hl=en&&q=parrot+-site%3Aperl.org+-site%3Aparrotcode.org+-site%3Acpan.org+-perl.perl6+-perl.cvs :: fail report on parrot 0.6.0
<shorten> Coke's url is at http://xrl.us/bh8k6
<particl1> kj: care to share your attempts in the form of a branch?
<pmichaud> just make it a subdir of compilers/nqp
<pmichaud> as opposed to a branch
<pmichaud> I'm not in a great hurry to have self-hosted nqp as the primary implementation, but it would be very useful to have it in compilers/nqp for testing and comparison
<Coke> lathos: can you remove the very old version of parrot you have on CPAN?
<Coke> (0.0.4)
<Coke> (I see cpan testers are still dutifully testing it.)
<kj> pmichaud: I made languages/nqp; that's easier to set up
<pmichaud> hmmm
<pmichaud> that might confuse people
<kj> but maybe a subdir of nqp is easier
<kj> yea
<kj> s/easier/more clear/
<pmichaud> they should of course continue to use the same grammar -- only the actions implementation is different
<kj> it's pretty much the same; except for some operators: I implemented them as PIR subs instead of the inline stuff
<pmichaud> that won't work though
<pmichaud> the operators need to be inline because NQP assumes there's no runtime
<kj> ah ok
<kj> well, I had trouble getting it to work
<pmichaud> i.e., when rakudo uses NQP to compile its actions methods, those methods can't assume that NQP runtime operators are available
<kj> mm right
<kj> I see
<kj> ok, so that should be fixed then.
<pmichaud> anyway, I think a 'selfhost' version of NQP in compilers/nqp would be useful
<pmichaud> it could use the same test suite
<kj> How should I add it?
<pmichaud> for now, a 'selfhost' subdir of compilers/nqp would seem to be okay
<pmichaud> or even an actions.nqp file instead of actions.pir
<kj> and within that, a directory structure as generated by tools/dev/mk_language_shell?
<kj> or just all files in that selfhost dir
<pmichaud> no, I wouldn't recreate the directory structure
<kj> actions.pl right?
<pmichaud> again, the only difference between a self-hosted nqp and the current version of NQP is the source of the actions
<pmichaud> so I think we'd only need a separate actions file, and perhaps a different nqp.pir
<particl1> or make it an option to pass to nqp.pir
<pmichaud> (that included the compiled form of actions instead of the pir version that is included now)
<pmichaud> (option to pass)  that sounds tricky
<pmichaud> because we'd have to know which set of action methods to load
<pmichaud> could have two action objects, I suspect
<pmichaud> one that uses the PIR-generated action methods, one that has the nqp-generated ones
<pmichaud> and then the option to nqp simply says which object to use in the HLLCompiler
<kj> i see
<pmichaud> but for now I'd do it as two separate executables
<pmichaud> where the only difference is the source of the actions, and possibly a separate nqp.pir
<pmichaud> I have to run errands -- bbl
<pmichaud> parrotsketch in 85, yes?
<pmichaud> oh, wait.  18:30 UTC, yes?  so that would be 145
<pmichaud> okay, that gives me plenty of time
<pmichaud> bbiab
% Theory has joined #parrot
<particl1> i'll be missing parrotsketch today
<particl1> report posted.
<Infinoid> wknight8111: ping
<wknight8111> hello
<purl> que tal, wknight8111.
<wknight8111> que tal, purl
<purl> bonjour, wknight8111.
<Infinoid> hi!  what do you think we should do about RT #51988?
<wknight8111> ...let me look it up
<Infinoid> its the _dup thing
<Infinoid> I'm not really sure what the motivation is... the patch breaks on linux, but does it fix warnings on win32?  if so, we might want to do something conditional there
<wknight8111> Win32 warns that "dup" is deprecated and we should use "_dup" instead
<wknight8111> it's a small matter, and just because it's deprecated doesnt mean it's an error, yet
<Infinoid> but it probably will be, someday
<Infinoid> fair enough.  what do you think about putting the #define in an #ifdef WIN32, or the like?
<svnbotl> r26534 | kjs++ | trunk:
<svnbotl> : [nqp] add initial actions file for NQP, written in NQP. Update MANIFEST.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26534
<particl1> #define Parrot_dup
<wknight8111> we could make a simple macro, #ifdef _WSV_CRT #define DUPLICATE _dup ....
<wknight8111> right, something like that
* Infinoid will test with mingw, to see whether the warning is msvc-specific or not
<wknight8111> i should have done it with mingw too, before I submitted. I thought the patch was going to be mostly harmless
<Infinoid> don't worry about that.  it got us thinking about it, which is a very good thing :)
<Infinoid> so far, it sounds like... Parrot_dup is defined to dup() on most platforms, and _dup() on MSVC
<Infinoid> that will make everyone happy.  right?
<wknight8111> makes me happy
<particl1> smoke testing will bear that out
<particl1> sounds good, though
<Infinoid> sounds like a good start, then
<nopaste> "Infinoid" at 75.5.247.241 pasted "rt51988-try1.diff" (49 lines) at http://nopaste.snit.ch/12570
<Infinoid> wknight8111: any chance you can try that on msvc and see if it warns?
<Infinoid> (that define probably isn't in the right place, but first things first)
<kj> wknight8111: hi, you asked for my squaak implementation, no?
<svnbotl> r26535 | kjs++ | trunk:
<svnbotl> : [nqp] update the TODO file to add some notes about the bootstrap version, so I don't forget these.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26535
<wknight8111> kj, you sent it to me. thanks
<wknight8111> Sure, i'll try building now
% jrt4 has left jrt4!~bojangles@c-24-18-106-126.hsd1.mn.comcast.net
% chromatic has joined #parrot
% kid51 has joined #parrot
<particl1>  /usr/bin/ld: crt1.o: No such file: No such file or directory
<particl1>  collect2: ld returned 1 exit status
<particl1> what's that mean i'm missing?
<Infinoid> either gcc or glibc :)
<particl1> i have gcc
<particl1> what's the debian pkg name for glibc?
<Infinoid> probably libc6-dev is what you're after
<Infinoid> do other C programs compile successfully?
<Infinoid> debian has a nice "build-essential" package that covers all that stuff
<particl1> sudo apt-get install build-essential
<particl1> Infinoid++
<wknight8111> darn, it didn't work. I must have messed up the macro. What should I test for, _MSV_CRT?
<jonathan> Parrot Sketch is about 1 hour away, right?
<kid51>  Damn, I forgot that it's localtime changed when we went to DST.
<Coke> jonathan: believe so, yes.
<Coke> so how does one get ops in a discussion where no one has ops?
<kid51> 1830 GMT correct?
<chromatic> Yes.
<kid51> Coke:  I think you have to know one of the #perl ops.
<Coke> Crap. YA week of "didn't really do anything."
% particl1 has left particl1!~JGay@32.138.59.170
<Infinoid> wknight8111: no idea.  _MSC_VER seems to be used elsewhere 
<wknight8111> Infinoid, that's what I was thinking about. That's probably it
<wknight8111> ...building again...
<Coke> chromatic: didn't you run some of the SDL stuff recently?
<chromatic> I had it working with PDD 15.
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
<Coke> http://rt.perl.org/rt3//Ticket/Display.html?id=48727 :: remove classoffset opcode :: except that SDL is using it.
<chromatic> Which file?
<purl> well, Which file is that error in
<Coke> though I think that classoffset already throws an exception, so the examples *can't* work.
<cognominal> jonathan, thx for reviewing my patch. I am studying  STD.pm to steer in the right direction
% kid51 has left kid51!~jkeen@toronto-hs-216-138-231-37.s-ip.magma.ca
<Coke> in examples/sdl/{minesweeper,tetris}
<chromatic> Those should be easy to fix.
<chromatic> I'll work on them.
<Coke> danke.
<Coke> (one more deprecation gone.)
% kj has joined #parrot
<jonathan> cognominal: Welcome. :-) I'm going to try and sort out some of the remaining colonpair bits. :-)
<cognominal> also,   :a is :a(0) not  :a(Bool::True)
<cognominal> I don't know if you have corrected
% barney has joined #parrot
<Infinoid> wknight8111: *sigh*.  my winxp installation is broken, not going to be able to test mingw for a while, sorry
<cognominal> I am trying to understand namespaces too cuz HLLCompiler currently compiles in the global namespace
<jonathan> cognominal: :a is equivalent to :a(1), you mean?
<cognominal> yes
<jonathan> Yup, just saw the bit of S02 that says that, you're completely right.
<cognominal> you did it equivalent to :a(True) and I followed suit which was wrong
<cognominal> easy mistake
<Coke> [18:45:32] t/postconfigure/03-revision....................1/8
<Coke> has been sitting there for some time on feather (svn checkout)
<Coke> (local mods)
<Coke> ... ah session died. whoops)
<Coke> whoa! no, not dead, ^C started it going again. 
<jonathan> cognominal: Fixing it now.
<jonathan> But got some other patches locally related to colonpairs that are halfway through too. :_)
<wknight8111> Yes, that fix killed the warning on cl.exe
<wknight8111> i actually don't have mingw here, so I can't test it now
<cognominal> jonathan, will you be able to make it to Albi  may 30 and 31?
<cognominal>  http://conferences.mongueurs.net/fpw2008/
<cognominal> or anyone here who wants to talk anything related to parrot
<jonathan> cognominal: 'fraid not - I've already had vacation planned for those dates since before FPW was announced.
<jonathan> Shame, because FPW is a good time.
<Infinoid> wknight8111: thanks, I'll sort this out and check it in, and test mingw later on when I have the chance
<jonathan> say (:a).perl
<jonathan> :a
<jonathan> say (:!a).perl
<jonathan> :!a
<jonathan> my $a = 'foo'; say (:$a).perl
<Infinoid> I don't think this will break mingw, I'm mainly just curious if the warning shows up there too.
<jonathan> :a<foo>
<jonathan> Woo. :-)
<cognominal> cool
<jonathan> The .perl method is thanks to you. Plus a couple of little tweaks. :-)
<cognominal> and  :a(2) ?
<jonathan> Not implemented yet.
<cognominal> I don't think parens are necessary
<cognominal> in (:a).perl
<svnbotl> r26536 | chromatic++ | trunk:
<svnbotl> : [examples] Rewrote away classoffset indexed attribute access in Mines::Field.
<svnbotl> r26537 | coke++ | trunk:
<svnbotl> : [deprecated]
<svnbotl> : Remove deprecated vtable entry "subtype". No tests fail.
<svnbotl> : Resolves RT#48569
<svnbotl> r26538 | jonathan++ | trunk:
<svnbotl> : [rakudo] Add .perl method for Pair class. Patch courtesy of cognominal++, with some tweaks from moi.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26538
<jonathan> cognominal: Yep, it works without too.
<cognominal> in fact,  I did not realize that test were working in parrot , I bundled them but commented them out in my patch
<cognominal> btw it seems that in perl6  the left side of a => must be a bareword
<cognominal> if I trust STD.pm
<cognominal> jonathan, I don't know if that affect your last patch
<svnbotl> r26539 | jonathan++ | trunk:
<svnbotl> : [rakudo] Add missing desigilname token to the grammar.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26539
<cognominal> jonathan, .return is supported as long it is not buried in a block?
<jonathan> cognominal: My reading of STD.pm is the same, yes, it's an <ident> there.
<jonathan> .return in what context?
<cognominal> it would not work in inner block in code generated by rakudo?
<jonathan> Not if you actually want to return from the outer block, no.
<jonathan> We haven't got support for return like that yet.
<cognominal> the code generated should trhow and catch an appropriate exception?
<Coke> yes.
<cognominal> jonathan, in the .perl, it seems that the fatarrow is not necessarily a naked string?
<cognominal> I mean the string in the left of =>
<jonathan> Yeah. That could do with a fix.
<jonathan> Guess in that case you have to instantiate a Pair object.
<svnbotl> r26540 | jonathan++ | trunk:
<svnbotl> : [rakudo] Fix :a and :!a to meet S02.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26540
<jonathan> Oh, fatarrow is already implemented.
* jonathan may have done it, but he sure doesn't remember doing it
<jonathan> (whoeverdidit)++
<cognominal> you did it I think
<jonathan> oops, self-karma.
<jonathan> :-)
% marmic has left marmic!~chatzilla@89-253-66-101.customers.ownit.se
<cognominal> I think that when heredoc will be implemented, rakudo will be able to compile itself
<kj> w.r.t. the returning of subroutines and exceptions: It seems to me that it doesn't work with the current infrastructure, does it?
<svnbotl> r26541 | jonathan++ | trunk:
<svnbotl> : [rakudo] Implement simple varname case for colonpairs, e.g. :$foo.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26541
<jonathan> kj: I believe not, no.
<kj> I mean the PCC and flags like :flat and :slurpy. Whenver you "throw" something, it is converted into an Exception object
<cognominal> I forgot that
<kj> so that should be adjusted
% cotto_work has left cotto_work!~cotto@tide503.microsoft.com
<Coke> why is Parrot_exit defined in both embed.h and exit.h ?
<pmichaud> cognominal: (heredoc) -- do we need full heredocs, or just the limited form that NQP is currently using?
% cotto_work has joined #parrot
<cognominal> that depends if you want to aim toward perl6 or toward self-bootstrapping
% kid51 has joined #parrot
<chromatic> Coke, silly duplication I suspect.
<pmichaud> well, I've already commented that self-bootstrapping isn't my highest priority at the moment :-)
<svnbotl> r26542 | chromatic++ | trunk:
<svnbotl> : [examples] Removed deprecated classoffset opcode from Tetris example.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26542
<Coke> chromatic: so I'm guessing remove it from embed.h and see if anything breaks?
<Infinoid> won't embedders want to exit cleanly too?
% purl has left purl!purl@sentient.life
% purl has joined #parrot
<Coke> I'm getting build warnings from it being re-declared, so something is including both embed.h and exit.h
<Coke> is the problem with the thing doing the including?
<chromatic> embed.h seems right to me.
<chromatic> #ps in one
<cognominal> pmichaud, can you see a better way to patch the problem described in http://rt.perl.org/rt3/Public/Bug/Display.html?id=49758
<svnbotl> r26543 | rblasch++ | trunk:
<svnbotl> : Updated PLATFORMS for GNU/OpenSolaris (NexentaOS).
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26543
<pmichaud> cognominal: I think the patch avoids the problem but doesn't actually fix the underlying problem
<pmichaud> the underlying problem probably has something to do with the way that subs are being generated or managed
<pmichaud> otoh, Parrot really should never produce a "Bus error"
<chromatic> I've been slowly removing buses from Parrot over the past year.
<Coke> we're going to a complete mass transit system.
<cognominal> :)
<pmichaud> I didn't see in the ticket itself, but does the problem persist if parrot is invoked with -G ?
<cognominal> better than a complete mess
<cognominal> never tried -G
* Coke wolf whistles at pmichaud's honeymoon comment.
<cognominal> I think as I said in the thread of the bug report, that the rakudo shell should not wraps a block as part of the eval but that a separate issue even if related
<chromatic> If someone can reproduce the problem in simple PIR, I'll fix the seggie.
* Coke wolf whistles at pmichaud's pictures comment.
<pmichaud> right now PCT only knows how to create subs
<cognominal> the problem is that the interpreter should not do a bus error on a missing outer block
<cognominal> what I did is to avoid generating the reference to the missing outer block
<pmichaud> well, PCT should certainly not generate an :outer flag on a block that doesn't have an outer
<cognominal> so that's very easy to reproduce with simple pir
<chromatic> Throw a test case my way and that'll be one fewer segfault.
<cognominal> pmichaud, I agree but the interpetor should to better than a bus error
<pmichaud> correct
<pmichaud> er, correct if you mean that Parrot should do better than a bus error
<cognominal> what is the way to die in pmc code?
<chromatic> Throw an exception object.
<Infinoid> Andy: ping
<Andy> sir
<Infinoid> hi!  do you know what the difference between PARROT_HAS_SNPRINTF and PARROT_HAS_C99_SNPRINTF is?
<Andy> no.
<chromatic> For a piece of candy would you figure it out?
<pmichaud> how about a Scooby Snack?
<purl> Rank roo, pmichaud!
<Infinoid> wknight8111 reported RT #51980 to consolidate the two, but I'm not sure whether we want to.  (His win32 platform defines the first but not the second; my linux platform defines both.)
<wknight8111> never discount the possibility that i'm stupid and sleep-deprived
<Infinoid> wknight8111: it would be nice to know what the difference is and whether it's important, your solution might be spot-on :)
% Psyche^ has joined #parrot
<Infinoid> ok.  since noone admits to having anything to do with snprintf, its fair game to rip it apart and see who complains. :)
% Patterner has left Patterner!~Psyche@d121052.adsl.hansenet.de
% Psyche^ is now known as Patterner
<chromatic> That's why we have the tests.
<chromatic> And may I add, you who are about to die, the rest of us salute you.
* Infinoid cracks up
<chromatic> What, varargs, memory management, and IO all smooshed together don't worry you?
<Infinoid> if snprintf does any IO, I've really broken it
<chromatic> I'm thinking of sfnprintf perhaps.
<Coke> kid51: have you tried re-installing the developer tools from apple?
<Coke> (on the chance that the custom gcc 4 overwrote some system file somewhere?)
<svnbotl> r26544 | jonathan++ | trunk:
<svnbotl> : [rakudo] Implement pairs of the form :a(...) (postcircumfix:()).
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26544
<kid51> Coke:  If I get time I will try that.
<Coke> I also wonder if that particular config step is ignoring your explicit settings you've passed to configure.
% mire has joined #parrot
<chromatic> If it's the shell script I just looked at, the MACOS_INSTALLATION_TARGET environment variable isn't getting set correctly.
<chromatic> It persists through the Configuration process, but it's not present for the make process (and the linking process).
<kid51> Coke:  I'm pretty sure it's not.  I can track those with Parrot::Configure::Trace
<kid51> chromatic:  The problem is in the configuration process.  I can build and test successfully (though perhaps the resulting parrot executable is different).
<wknight8111> what does the warning mean "Null PMC acces in invoke()"?
<chromatic> You tried to invoke something that's not a Sub.
<cognominal> that it tries to find a routine and fails
<kid51> chromatic:  Besides:  What allison had me set was this:
<kid51> [trad] 516 $ echo $MACOSX_DEPLOYMENT_TARGET
<kid51> 10.3
<chromatic> In your .bashrc or .tcshrc or .profile?
<kid51> .bashrc
<cognominal> ... so you get a null PMC on subsequent invoking
<wknight8111> okay thanks. now i need to debug and figure out what i'm doing wrong
<davidfetter> anybody know when yapc::na's going to announce which talks made it?
<kid51> barney:  Does my patch in http://rt.perl.org/rt3/Ticket/Display.html?id=51860 work for you re manifest tests?
<kid51> davidfetter:  IIRC Josh extended deadline to Mar 31, so decisions should be made soon after.
<davidfetter> thanks :)
<Coke> So far, only kid51 has updated that wiki page (so says my RSS feed)
* davidfetter can most easily make travel plans when he knows he'll be speaking
<Coke> (regarding talks)
% contingencyplan has joined #parrot
<barney> kid51: Yes, I've closed that ticket. Thanks.
<kid51> Yes, and I would like some co-leaders to bring off that session.
<kid51> barney:  Thanks.
<Coke> kid51: depending on when that session is, I will of course be there.
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
* PerlJam makes a(nother) mental note to read kjs' PCT tutorial
<kj> PerlJam: You're editor for the perl review right?
<PerlJam> not I
<PerlJam> that's bdf
<kj> oh sorry I thought that was you ;-)
<PerlJam> kj: Are there no back links to the other episodes (I just glanced at #9)
<PerlJam> ?
<kj> no. that's a good point.
<kj> not sure how to do that ...
<kj> something with http....#episode8 I think, right?
<PerlJam> beats me :)
<kj> oh. I'm not really into html 
% peeps[work] has joined #parrot
% contingencyplan has joined #parrot
<cotto_work> kj, when someone's looking at individual episodes, there are links to the next/prev episodes at the bottom
<cognominal> normally   imcc trips when compiling a sub with a fake outer:   compilers/imcc/pbc.c:969:        IMCC_fatal(interp, 1, "Undefined :outer sub '%s'.\n",
<cognominal> but apparently that's different within an eval
% barney has left barney!~bernhard@dslb-084-058-189-173.pools.arcor-ip.net
<kj> cotto_work: you mean newer and older post?
<cotto_work> eys
<cotto_work> s/ey/ye/
<kj> that works kinda, but it's not ideal
<kj> i mean, it's not clear what those posts are
<kj> but it's not a big deal I think
<pmichaud> imcc gets called differently from within parrot than as parrot
<pmichaud> for example, try compiling a string using the object that comes back from   $P0 = compreg 'PIR'
<pmichaud> I had a post (perhaps a ticket) that illustrated this -- just a sec
% marmic has joined #parrot
* Coke needs a tagline description of parrotblog.org
<chromatic> It's a blog.  For parrots.
<Coke> ... right. committing...
<pmichaud> https://rt.perl.org/rt3/Ticket/Display.html?id=47956
<pmichaud> shows an example where invoking imcc as "parrot" and using the internal compreg "PIR" compiler produces different results
<kid51> Coke:  apropos parrotblog.org.  Couple of weeks ago, I posted on list re difference between that site and planetparrot.  Didn't get any replies.
<cognominal> pmichaud: interesting
<pmichaud> difference between planetparrot and parrotblog:
<pmichaud> planetparrot is an aggregation of feeds/blogs that are related to parrot (could come from multiple sources)
<pmichaud> parrotblog is a place where people can blog about parrot that isn't use.perl (i.e., some parrot news might not be appropriate for a perl-only forum, or perhaps should have a larger reach)
* jonathan really should get around to writing a Rakudo-related blog post sometime soon.
<Coke> kid51: I have that request starred to entice me to reply once my waiting for allison times out. =-)
<Coke> planet parrot is an aggregate of any parrot-related blogs.
<Coke> parrotblog is, er, for, um, parrot related bloggin?
* Coke seems pmichaud has already opined on this.
% ruoso has left ruoso!~ruoso@195.23.92.2
<kid51> It would be good to get that distinction added to the Resources page at parrotcode.org
<Coke>    <small>A blog dedicated to Parrot news, tutorials, and more</small>
<Coke> vs. 
<Coke>    <small>An aggregator of select Parrot-related blogs</small>
<Coke> that ok?
<purl> NO, it isn't
<pmichaud> for the second
<pmichaud> "An aggregator of blogs from Parrot-related contributors"
<Coke> t/postconfigure/03-revision seems to be hanging pretty regularly now on feather.
<pmichaud> since planetparrot doesn't seem to distinguish non-parrot posts from parrot posts
<pmichaud> or better
<pmichaud> "An aggregator of blogs from selected Parrot contributors"
<Coke> +1
<purl> 1
<cotto_work> +1 1
<Coke> and 04-revision.
<Coke> any other feedback before i commit this version?
<Coke> pmichaud's version.
<svnbotl> r26545 | coke++ | trunk:
<svnbotl> : [icc]
<svnbotl> : RT #52028 ([PATCH] Do not split macro invocations that use CONST_STRING into multiple lines)
<svnbotl> : Matt Kraai++
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26545
% kid51 has left kid51!~jkeen@toronto-hs-216-138-231-37.s-ip.magma.ca
<jonathan> pmichaud: Got a moment to give me hints on a parsing bug?
<pmichaud> sure
<jonathan> This works:
<jonathan> my $x = <-> $a { say $a; }; $x(42);
<jonathan> 42
<jonathan> But this doesn't:
<jonathan> my $x = -> $a { say $a; }; $x(42);
<jonathan> Statement not terminated properly at line 1, near "= -> $a { "
<jonathan> I am pretty sure, it's trying to parse that as prefix:- or something.
<jonathan> But can't confirm that in any way (not sure how).
<pmichaud> it's undoubtedly seeing that as prefix:-
<kj> isn't -> a prefix op too?
<pmichaud> no, it's part of the <pblock> rule
<pmichaud> the best workaround I can come up with for now would be to create a prefix:-> that "fails"
<jonathan> Issue with longest token rule and bottom-up parsing is my guess?
<pmichaud> yes
<jonathan> I don't understand PGE anything close to enough to know where to start fixing that.
<pmichaud> well, PGE is likely going to need some massive redesign for longest token rule, and for that I need to look at TimToady's work on his parser
<jonathan> I'm not blocking on it as such, so if you can see it being fixed on the scale of weeks then it's fair enough.
<jonathan> Ah, OK.
<pmichaud> I can see us being able to create a prefix:-> workaround fairly quickly
<jonathan> Maybe a workaround is the way to go.
<Coke> Ugh. So we now have stuff on the web in the wiki, combust, the repository, and the blog.
<pmichaud> I don't have a good time estimate for longest token rule.
<jonathan> Sure, it looks to me like a *serious* amount of work.
<pmichaud> well, fortunately TimToady has one working (at least to some degree) already, so if I have a template/design to follow I'm hoping it won't be too onerous
<jonathan> Here's hoping. :-)
<pmichaud> if I had to come up with it myself, I'd be a lot more pessimistic about it
<jonathan> What are you thinking of working on next Rakudo wise, beyond catching up on what @other have been doing?
<pmichaud> refactoring classes and protoobjects, with an eye towards .HLL
<pmichaud> other items would be regex/rule/token, and getting 'return' to work
<pmichaud> (since 'return' is needed for PCT completion)
<jonathan> OK, cool.
<jonathan> They are things I'm less comfortable working on, so I'm happy to not have to worry about them. :-)
<pmichaud> anything you'd particularly like to see me work on ?  ;-)
<pmichaud> I do take requests :-)
<jonathan> Actually, the above list is pretty much what I would have asked for.
<kj> i think the control stuff like break/continue/return is interesting, but needs better parrot support
<kj> it would be on My Wishlist ;-)
<pmichaud> I think parrot is pretty close, it's just PCT that needs to support it
<pmichaud> simply being able to throw exceptions is all that I need parrot to do
<pmichaud> (throw exceptions with a payload, that is)
<jonathan> I take requests too, if there's anything in Rakudo you want me to look at.
<kj> ok. I don't really see how it would work frankly, as you have to wrap stuff in exceptions
<kj> not very efficient anyway
<pmichaud> however, it would be very nice if Parrot had something equivalent to Perl's "Capture" object that can package up positional and named arguments into a single PMC
<jonathan> My plans for next stuff is to get fatarrow and colonpair passing named parameters.
<jonathan> Hmm, a capture PMC.
<purl> it has been said that a capture pmc is quite useful, similar to a DOM tree
<pmichaud> there's already a Capture pmc in Parrot, but it's broken.  It needs to be re-done with the new pdd17 model in mind
<pmichaud> and the Capture object that PGE/PCT uses is written entirely in PIR, so it's a bit slow
<jonathan> Does the one that PAG and PCT use have the correct semantics?
<Coke> control-flow-exceptions: we should standardize on how we do this for HLL interop.
<jonathan> s/PAG/PGE/
<pmichaud> Coke: that's what I'm intending for PCT, yes
<pmichaud> jonathan: there are a few minor changes to be made, but essentially the semantics are correct, yes.
<Coke> right now tcl is just throwing exceptions and using one of the slots to store the control-flow type.
<Coke> (corresponding to the values at: http://www.tcl.tk/man/tcl8.5/TclCmd/return.htm)
<Coke> ->
<kj> it'd be nice if under the hood, so in PIR, return statements are still return statements, and not exceptions. Even if they're using the exception mechanism
<jonathan> pmichaud: Where can I find the PIR version?
<purl> the PIR version is gone i think
<pmichaud> jonathan: runtime/parrot/library/Parrot/Capture_PIR.pir
<pmichaud> kj: that's my intent
<nopaste> "cognominal" at 82.67.232.89 pasted "unsucessful fix" (21 lines) at http://nopaste.snit.ch/12571
<pmichaud> kj: there will likely be a 'return' op node in PCT
<kj> right. but what I meant is, that there's also PIR syntax hiding the exception stuff
<cognominal> I try that but it still fails :(
<jonathan> pmichaud: Thanks, will keep that in mind as something to work on soon.
<pmichaud> oh, I don't think the PIR version of 'return' needs to be exception-based
<pmichaud> we already have 'throw' for that :-)
<pmichaud> on phone
<chromatic> Where's the Capture PMC?
<purl> the Capture PMC is probably quite useful, similar to a DOM tree
<pmichaud> src/pmc/capture.pmc, I think
<chromatic> Hm, I updated it if it's there.
<pmichaud> oh, perhaps I need to re-test it then
<chromatic> It may still be broken, but it should at least compile correctly.
<pmichaud> well, it may work, but I was under the impression that the new PMC implementation would allow us to be more efficient in implementing stuff like this (i.e., a capture needs a separate Hash and Array component)
<pmichaud> previously it was somewhat complex because there was really only one data slot
<chromatic> Yeah, that's doable.
% cotto_work has left cotto_work!~cotto@tide535.microsoft.com
% skids has left skids!bri@charon.clarku.edu
% Limbic_Region has joined #parrot
<jonathan> Wheee..
<jonathan> class Foo { has $.a; }
<jonathan> my $x = Foo.new(a => 42); say $x.a;
<jonathan> 42
<kj> jonathan++
<kj> seems like rakudo is nearing completion :-P
<kj> I have no clue how much more must be implemented...
<jonathan> You haven't seen the Perl 6 spec, have you? :-P
<cognominal> :)
<kj> I scrolled through it and thought: too much for me
<kj> :-)
% cotto_work has joined #parrot
<kj> then again, pure size doesn't say anything
<cognominal> jonathan, what is the perl6 incantation to ask to use registers for lexical variables?
<cognominal> cuz lexpads are costly
<cognominal> there must be a way otherwise why native types
<jonathan> kj: There's still a *lot* to do in Rakudo.
<PerlJam> cognominal: I doubt any such mechanism is specced.
<jonathan> cognominal: my int $x; # should, one day, be a Parrot int register
<jonathan> The lowercase types are the native ones.
<kj> jonathan: yeah i didn't expect otherwise; but it's very difficult to get any clue about which parts. At least for outsiders like myself
<jonathan> However, that's not implemented at the moment.
<cognominal> I know that :)
<PerlJam> oh.  /me was thinking of registers as in the C sense.  Silly me.
<cognominal> but some day someone will want to do fibonacci with radkudo
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<svnbotl> r26546 | jonathan++ | trunk:
<svnbotl> : [rakudo] Treat pairs in parameter lists as named arguments.
<svnbotl> r26547 | jonathan++ | trunk:
<svnbotl> : [rakudo] Fix new method for Object.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26547
<jonathan> kj: At the moment, it'd probably be easier to point out the bits that are implemented, than the bits that aren't. ;-) But a version of the spec that had the bits that Rakudo implements highlighted green or something, or that it partially implements that are buggy in yello, would be cool to have.
% jrt4 has joined #parrot
<kj> jonathan: yeah, that'd be cool. When selecting grammar bits to implement, do you look at the spec?
<kj> I mean, how do you decide what to do
<PerlJam> jonathan: I've thought it would be cool if you could somehow do that with STD.pm vs. grammar.pm  (but that's just parsed, not implemented)
<jonathan> I'm going for a breadth-first approach at the moment, which basically means I'm trying to get little bits of all sorts implemented.
<jonathan> Part of it is certainly driven, by, which bits of the spec do I look at and have a good idea of how to implement.
<jonathan> I'm also trying to get a lot of the common cases covered, though.
<PerlJam> kj: When ever I attempt to hack on rakudo, I look at STD.pm and I try to make grammer.pm look more like STD.pm  :)
<kj> mm I don't even know how to get at the STD.pm
<jonathan> So when I give Perl 6 talks, I can say "and you can run this in Rakudo today". :-)
<PerlJam> kj: invariably though, I run into problems hacking the corresponding actions.pm part as I don't do it enough for it to be comfortable.
<PerlJam> kj: it's in the pugs repo
<jonathan> kj: http://svn.pugscode.org/pugs/src/perl6/STD.pm
<svnbotl> r26548 | infinoid++ | trunk:
<svnbotl> : [io] Apply patch similar in spirit to RT #51988
<svnbotl> : Hopefully this will resolve warnings on win32/msvc.  I'm pretty sure it won't
<svnbotl> : affect any other platform.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26548
<kj> is it me, or is this a very complex spec? :-P
<chromatic> It's not just you.
<PerlJam> kj: This is "perl 6", not "python 3000"  :-D
<kj> ha ha ;-)
<chromatic> You mean Python 2.7?
<PerlJam> whatever they're calling it these days
<kj> i think it's "3" these days...
<kj> it seems to me that the spec contains executable code to parse this... Am i right in that?
<PerlJam> kj: read the comments
<jonathan> Happily, someone++ already did named params. So this works now too...
<jonathan> sub foo (:$bar) { say $bar; }
<jonathan> foo(bar => 42);
<jonathan> 42
<jonathan> And foo(:bar(42)) of course.
<kj> :bar(42) is same as bar=>42?
<jonathan> Yes.
<kj> just as in PIR, kinda
% mire has left mire!~Frodo@139-174-222-85.adsl.verat.net
<kj> a Perl 6 specification tutorial wouldn't be useless ;-) (hint, hint)
<jonathan> kj: What would you want it to cover?
<cognominal> jonathan : default_statement should be   $<sym>=[default| '*']  
<kj> jonathan: well I guess it's just a bit confusing how this stuff works. It's not just anohter grammar specification, like any other language. This is way more complex. 
<kj> and I don't understand why all this complexity...
<pmichaud> why should default_statement include '*' ?
* cognominal searches the relevant synopsis
<jonathan> pmichaud: I don't think it should. But when * is equivalent to default
<jonathan> But that waits until we implement Worreva.
<pmichaud> jonathan: yes, in which case it's a when_statement :-)
<jonathan> Right.
<jonathan> And I don't think it's a special case either.
<jonathan> Just that the Whatever type has a very simple ACCEPTS method. :-)
<pmichaud> correct
<jonathan> token whatever { '*' {*} }
<jonathan> Hmm, should that just instantiate the Whatever class?
<pmichaud> seems reasonable enough for now.  Either that or return the Whatever protoobject, or a singleton instance of Whatever
<cognominal> oops
<cognominal> it reads  default  { ... } is exactly equivalent to  when * {...}
<jonathan> The protoobject makes sense.
<pmichaud> right... but 'when * { ... }' is an example of a when_statement, not a default statement
<cognominal> yes, I was wrong
<pmichaud> well, I don't know what sort of definedness we need for '*'
<jonathan> Well, I'll stub it in enough to make when * work... :-)
<pmichaud> sounds great :-)
<cognominal> I can't remember every synopsis :(
<pmichaud> neither can I, which is why I had to look it up also :)
<jonathan> cognominal: If you could, I'd be terrified of you.
<cognominal> I have seen you arenot omniscient either :)
% mire has joined #parrot
<jonathan> Oh, hmm. While whatever is defined in STD.pm, it's not mentioned nearly anywhere else in the grammar.
% skids has joined #parrot
<cognominal> * means many different things in many place, that's the ultimate joker
<jonathan> Well, I'm not implementing all of it's meanings before I go to bed. :-P
<pmichaud> I think the concept of 'whatever' is often more context-sensitive than syntax
<jonathan> That's my impression from S02.
<jonathan> I remember seeing Whatever for the first time at some YAPC::EU in a Larry keynote and thinking "wow, that's nice...but I wouldn't want to be implementing that". Ah well...
<skids> jonathan: http://www.perlfoundation.org/perl6/index.cgi?witch_star
<cognominal> variables with a + twigil are dynamically scoped?
<cognominal> I see them in many places in STD.pm?
<pmichaud> they're contextual variables
<pmichaud> which means we look up the call stack to find the scope in which it's defined
<cognominal> ok, that's what I call dynamical scope
% spez has joined #parrot
<cognominal> some lisp did that too
<cognominal> so we do both lexical and dynamic
<pmichaud> the variable in the outer caller scope also has to be defined with the 'context' trait
<pmichaud> yes, we do both lexical and dynamic
<jonathan> I haven't thought much about how to implement those just yet. :-)
<pmichaud> oh, it's easy -- PCT is going to implement dynamic scope
<pmichaud> essentially we just use getinterp and traverse the caller stack looking for a matching lexical
<jonathan> Oh, wow. It's easy.
<jonathan> :-)
<jonathan> skids: Thanks. :-)
<pmichaud> (we'll have to do some trickery to handle the 'context' trait and skip over entries that aren't 'context'... but we can work that out)
<jonathan> Hmm, getting PCT to do that neatly could be fun.
<jonathan> As in, in a language-independent way.
<pmichaud> I'm thinking it's just a PAST::Var of :scope('context')
<jonathan> Or we could just replace its 'dynamic' with our own by fiddling the namespace. :-)
<jonathan> Or that.
<jonathan> Oh, fiddling the namespace breaks other languages we want to compile. Forget that.
<pmichaud> and PCT will convert that to call a subroutine that handles the callstack
<pmichaud> note that it's not really namespace related
<pmichaud> or, for that matter, I could just leave it up to the HLL to define its own method for grabbing a context var
<jonathan> I was referring to putting a new Sub into the namespace entry for 'dynamic' in the PCT namespace. ;-)
<jonathan> But it's wrong, wrong wrong.
<pmichaud> ohhhh
<pmichaud> no, the way to do that is to subclass PAST::Var (or whatever) and add a new method
<purl> okay, pmichaud.
<jonathan> :-)
<jonathan> Oh yes, I know how to do OOP.
* jonathan shouldn't try and think about anything much when he's this tired
<pmichaud> afk for a while
<jonathan> say *.WHAT;
<jonathan> Whatever
<jonathan> woo
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
<wknight8111> in PIR, i would use the 'exit' keyword to exit the program, right?
<wknight8111> because i'm calling exit, and nothing happens
<jonathan> wknight8111: Try end instead
<wknight8111> like "end 0"?
<jonathan> Just end
<wknight8111> ok
% peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com
<kj> wknight8111: it's "exit 1" and "end"
<wknight8111> that works like a charm. Thanks
<kj> so exit takes an integer arg
<wknight8111> i was doing exit, nothing happened
<kj> exit 1 didnt' work?
<wknight8111> no
<kj> mmm. i don't remember whether i used that.. prob not then
<wknight8111> it doesnt error either, it just ignores the command
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-198-176.dynamic.mnet-online.de
<chromatic> There's an end op and an exit I op
<wknight8111> i'll stick with "end", but the exit thing should probably be fixed
<chromatic> Okay, I can't find the exit op, just its documentation.
<pmichaud> there's a test for it
<pmichaud> t/pmc/exception.t
<wknight8111> i found the exit command in the perl6 builtins/control.pir, so that might be worth testing
* jonathan remembered to update MANIFEST, for once.
<pmichaud> looks like it's in core.ops
<chromatic> Ah, there it is.
<chromatic> Somehow I couldn't find it.
<pmichaud> wknight8111: could you nopaste the code you were using to test exit?
<pmichaud> or else file a ticket for it?
<wknight8111> it's rediculously simple: .sub 'exit' exit 1 .end
<pmichaud> so how do you know it's not working?
<wknight8111> because when I call that function, it doesnt exit
<wknight8111> when i switch the "exit 1" to "end", it exits
<pmichaud> oh
<jonathan> Does exit just set the exit code?
<jonathan> And end actually ends the program?
<pmichaud> according to core.ops, it throws an exception
<jonathan> Ah.
<pmichaud> inline op exit(in INT) { do_exception(interp, EXCEPT_exit, $1);
<pmichaud> }
<pmichaud> so if there's something catching exceptions, then it would be caught/handled
<pmichaud> in rakudo's case, that means that the interactive mode wouldn't "exit"
<pmichaud> (or in anything using PCT's interactive mode)
<svnbotl> r26549 | jonathan++ | trunk:
<svnbotl> : [rakudo] Add the Whatever class and * syntax for it, and give it an ACCEPTS method so when * { ... } always runs.
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26549
<wknight8111> okay, so that must be the problem then. I was testing it interactively
% rdice has joined #parrot
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
<pmichaud> right.  PCT's interactive mode catches exceptions so that a syntax error or floating point error doesn't exit Parrot
<pmichaud> but it's not smart enough yet to distinguish an "exit" exception from others
<pmichaud> (although I thought it was smart enough to do that...)
<wknight8111> is there a flag we can test to determine if we are running interactively?
<pmichaud> not really
<wknight8111> fair enough
<Limbic_Region> wknight8111 - implement -T
<pmichaud> I just double-checked -- HLLCompiler just catches all exceptions in interactive mode, but doesn't check the type of exception to decide if it should be rethrown
<Limbic_Region> er, -t
<cognominal> hum, how STD.pm does hash composers?
<pmichaud> block
<pmichaud> { a => 3, b => 4 }    is just a block
<jonathan> OK, now Whatever's stubbed in, I'll get some sleep. :-)
<cognominal> jonathan++
<cognominal> but, it is executed immediately
<jonathan> night all
<cognominal> g'night jonathan
<pmichaud> it's not executed immediately when used as an rvalue
<pmichaud> my %a = { a => 3, b => 4 }
<pmichaud> information about hash composers is in S04, starting with "Anywhere a term is expected, a block is taken ... "
<cognominal> but it seems that it is a hash composer only if the first expression is pair or hash like
<pmichaud> correct.  If the closure contains only a comma-separated list starting with a pair or hash, the closure is treated as a hash composer
<pmichaud> (or if the closure is empty)
<pmichaud> either way, it parses as a closure (which is what STD.pm is all about)
<cognominal> immediatly meaning at affection time
<cognominal> affectation!
<pmichaud> it's up to something outside of STD.pm to decide if the closure is a hash composer or a closure
<pmichaud> (in rakudo, this will be the action methods of noun or term, probably)
<cognominal> hum what is the english word for affectation?
<cognominal> assignment!
<purl> well, assignment is different in scalar contexts than in array context
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
<cognominal> I suppose that actions.pm should look into the block content
<cognominal> currently > my %a = { a => b }; gives  Statement not terminated properly at line 1, near "=> b };\n"
<cognominal> hum that the fat comma
<pmichaud> actions.pm will look into the block content when the block is being used as a term/noun, probably
<cognominal> btw STD.pm says an ident at the left of a => but the example in S04  contain  "a" => 1
<pmichaud> it should allow ident or term.  but fatcomma in std.pm might be handling only barewords on the lhs, leaving infix:=> to handle the other cases
<pmichaud> (I haven't looked)
<cognominal> I think it can be legitimate to assign a block to a scalar
<cognominal> ha, ok. I get it. this business of expressions handled outside the "main grammar trick me
<cognominal> I just figured out how the assignment gets a different precedence according to the list or scalar context
% kid51 has joined #parrot
<cognominal> should follow jonathan's example and go to bed...
<wknight8111> bed is for the weak
<wknight8111> I wish some of the PCT error messages were a little more descriptive. This debugging is an uphill battle
<cognominal> I am past the age when I feel I have to prove somehow my manhood.
<wknight8111> I agree, i'm headed to bed before too long myself
<wknight8111> :)
* kid51 muses, "Let me see; where is my manhood?  I think I left it around here somewhere."
* Infinoid doesn't help kid51 with that
<wknight8111> urg. I'm getting the error "Lexical '0' not found" for every single statement.
<Infinoid> is it looking for a lexical variable of that name?
<wknight8111> most of the statements don't have any variables at all
<wknight8111> "5+4" -> "Lexical '0' not found"
<Infinoid> that's in raduko?
<wknight8111> no, in an octave port that I'm working on
<wknight8111> I am going to find some spare time this week and hack in some better error messages into PCT
<Infinoid> is --target=past implemented on the perl6 layer, or on the parrot layer?
<Infinoid> 'coz it sounds really useful here.
<wknight8111> i think i fixed that last error. I'm getting a new error now
<wknight8111> new = good
<Infinoid> heh :)
<Infinoid> it is either progress or congress, depending on whether you've moved on to the next one or introduced an earlier one :)
<wknight8111> right. either way i've narrowed it down
<Coke> (exit getting caught) see languages/tclsh/src/tclsh.pir line 181 for how to handle that.
<wknight8111> okay, thanks
<Coke> (Those macros are defined in .../src/macros.pir)
<chromatic> Infinoid, it's in HLLCompiler.
% slightlyoff has joined #parrot
% spez has left #parrot
<cotto_home> is INTVAL_SIZE a good way to check if I'm on a 64-bit system (in C code)?
<Infinoid> cotto_home: looks good to me, it's defined to 8 on my x86-64 linux box
<cotto_home> thanks
% petdance has joined #parrot
% particl1 has joined #parrot
% slightlyoff_ has joined #parrot
% slightlyoff has left slightlyoff!~slightlyo@204.14.154.209
% grim_fandango has joined #parrot
% petdance has left petdance!~Andy@64.81.227.163
% petdance has joined #parrot
<Coke> Anyone here have a comment as to whether or not languages should be adhere to parrot's "try not to use non-core/bundled" modules credo? Seems like they should be able to set more requirements (and have) than parrot itself. (RT #51916)
<Infinoid> my own priority would be to maximize code reuse and minimize developer work, therefore, anything on CPAN is fair game.  But I am neither a core developer, nor a languages guy.
<kid51> I think they'll have to go into Bundle::Parrot ... which I actually know little about.
% peepsalot has left peepsalot!~peeps@cpe-67-9-161-48.austin.res.rr.com
<Limbic_Region> Coke - get p5 on parrot working and then it is all fair game :-D
% peepsalot has joined #parrot
<kid51> But who exactly is working on "p5 on parrot"?
<Limbic_Region> well, the ponie project is dead as a door nail AFAIK
<Limbic_Region> but nicholas still seems to make p5 core changes that seem to be in preparation for p5 on parrot
<Limbic_Region> mostly, I was speaking tongue in cheek (note the smiley)
<Limbic_Region> and on that note, I am out - TTFN
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
<Coke> kid51: I have commit privs on Bundle::Parrot : it's just a Bundle.
<Coke> Bundle?
<purl> hmmm... Bundle is just a directory.
<Coke> bundle is also a special kind of CPAN thingee that just says "install these other modules"
<purl> okay, Coke.
<Coke> Someone with some C-fu could probably apply #46597
<kid51> Then could you add Parse::Yapp to Bundle::Parrot?
% particl2 has joined #parrot
<Coke> I could. I hesitate to add stuff that parrot itself doesn't require.
<Coke> I'm not refusing, just hesitating. =-)
* Infinoid looks at #46597
<kid51> Well, then do we need a Bundle::Parrot::Languages ?
<Coke> Iunno. I suspect I should just give up and add it to B:P; can you respond to the ticket to the list and ask for feedback? See if anyone other than I has any concerns?
% particl1 has left particl1!~JGay@32.139.203.156
* Coke triages a bunch of the new tickets and adds [TAG]s
% particl2 has left particl2!~JGay@32.136.102.218
% rdice has left rdice!~richarddi@CPE001217e365c7-CM00159a01d44c.cpe.net.cable.rogers.com
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167929772.dsl.bell.ca
* Coke wonders if rt.perl.org just fell off the map
<Infinoid> works great here
* Infinoid resolves RT#46597
<svnbotl> r26550 | infinoid++ | trunk:
<svnbotl> : [raduko] reformat slightly to pass t/codingstd/cuddled_else.t
<svnbotl> r26551 | infinoid++ | trunk:
<svnbotl> : [src] "indexes" argument to Parrot_init_arg_indexes_and_sig_pmc should be NULLOK.
<svnbotl> : This patch inspired by RT #46597.  bgeron++
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% contingencyplan has left contingencyplan!~contingen@76.186.27.146
% contingencyplan has joined #parrot
% kid51 has left kid51!~jkeen@toronto-hs-216-138-231-37.s-ip.magma.ca
<Coke> Infinoid: danke.
<svnbotl> r26552 | coke++ | trunk:
<svnbotl> : [docs]
<svnbotl> : Fix typo & remove "This section intentionally left blank."
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26552
% mire has left mire!~Frodo@37-174-222-85.adsl.verat.net
<svnbotl> r26553 | coke++ | trunk:
<svnbotl> : [DEPRECATED]
<svnbotl> : The pmc_namespace vtable was deprecated, the get_namespace vtable was
<svnbotl> : its replacement: Here's a rename which resolves both tickets
<svnbotl> : (now merged into RT#48144). 
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26553
<chromatic> Hey Coke, want to profile some PIR?
<Coke> Sure.
<chromatic> Okay, let me mail my patch and instructions to the list.
% svnbotl has left svnbotl!diakopter@feather.perl6.nl
% Auzon has joined #parrot
<chromatic> There you go.
% svnbotl has joined #parrot
% slightlyoff_ has left slightlyoff_!~slightlyo@204.14.154.209
% AndyA has left AndyA!~andy@82.152.157.85
<Coke> chromatic: not seeing it. will probably have to wait until tomorrow anyway.
* Coke has fun ripping things out.
% AndyA has joined #parrot
% ewilhelm has left #parrot
<svnbotl> r26559 | coke++ | trunk:
<svnbotl> : [DEPRECATED]
<svnbotl> : remote int variants of getattribute/setattribute opcodes that were already
<svnbotl> : throwing exceptions anyway. (RT #48729)
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26559
<chromatic> It should be in the list archives now.
% Ozama has joined #parrot
<Ozama> alguem ae tem bd
<Ozama> ?
<svnbotl> r26560 | coke++ | trunk:
<svnbotl> : [DEPRECATED]
<svnbotl> : use less qw(.);
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26560
<Coke> Ozama: I'm sorry, I don't recognize that language.
* Coke guesses portuguese, and we do have a native speaker, but I'm not sure he's about.
<Coke> ->
<svnbotl> r26561 | coke++ | trunk:
<svnbotl> : [DEPRECATED] [pynie]
<svnbotl> : use less qw(.);
<svnbotl> diff: http://parrotvm.org/svn/parrot/revision/?rev=26561
% Ademan has left Ademan!~dan@h-68-164-168-66.snfccasy.dynamic.covad.net
% petdance has left petdance!~Andy@64.81.227.163
% skv_ has joined #parrot
% skv has left skv!~skv_@87.242.97.68
% skv_ is now known as skv
% Ozama has left Ozama!~Ozama@81.193.133.245