% TonyC has left TonyC!~tony@202-154-105-237.people.net.au
% nopaste has left nopaste!~opaste@202-154-105-237.people.net.au
% nopaste has joined #parrot
% iblechbot has joined #parrot
% davidfetter has left davidfetter!~davidfett@start.fetter.org
<dalek> r26587 | fperrad++ | trunk:
<dalek> : [Lua] PAST-pm deprecation
<dalek> : - test_lex uses PCT/PAST
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26587
% wknight8111 has joined #parrot
% skv has joined #parrot
% kj has joined #parrot
<dalek> r26588 | fperrad++ | trunk:
<dalek> : [Lua]
<dalek> : - fix POD
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26588
% TonyC has joined #parrot
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% ruoso has joined #parrot
% dalek has left dalek!dalek@feather.perl6.nl
% dalek has joined #parrot
% skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net
<dalek> test of self-flood prevention
<dalek> test of self-flood prevention
<dalek> test of self-flood prevention
<dalek> test of self-flood prevention
<dalek> test of self-flood prevention
<dalek> test of self-flood prevention
<dalek> test of self-flood prevention
<diakopter> oh good, it works for separate messages
% skv has left skv!~skv@87.242.97.68
<Coke> oh, dalek still knows the branch. excellent.
% particle has joined #parrot
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-197-18.dynamic.mnet-online.de
% wknight8111 has joined #parrot
<Coke> particl1: hio
<particle> hey there
<particle> harumph, my nicks switched
<pmichaud> particl1:  good morning!
<purl> morning jackass
<kj> purl's not too nice today...
<pmichaud> purl often seems to be that way towards my comments... for example
<purl> pmichaud: huh?
<pmichaud> hello, all
<pmichaud> morning, all
<pmichaud> oh, I guess they're gone :-)
<pmichaud> good.
* pmichaud spits at purl.
<Infinoid> good morning pmichaud :)
% kid51 has joined #parrot
% iblechbot has joined #parrot
% lidden has left lidden!~stefan@puce.campus.luth.se
% lidden has joined #parrot
% skids has joined #parrot
% gryphon has joined #parrot
* Coke wonders if he ever opened a ticket about the smoke.
<kid51> Any smoke in particular?
% particle has left particle!~JGay@32.136.56.254
<Coke> go here: http://smoke.parrotcode.org/smoke/ :: look at the last visible text on the screen.
<Coke> (the coda is in the wrong spot. removing it breaks the coda test, putting somewhere else might fail the coda test. (not sure.)
<Coke> (if so, the coda test should probably be smarter.)
<kid51> Yup, that's been there for a long time.  I have an RT open which calls for revamping the smoke reports, but it didn't include that particular.
<Coke> ah. moving it just before the __DATA__ block is fine, codingstd test still passes.
<Coke> ... whoops, wrong coda test, moment...
<dalek> r26589 | coke++ | trunk:
<dalek> : [codingstd]
<dalek> : Move the perl coda out of the DATA segment: in there, it's visible
<dalek> : on the server in the HTML. This file continues to pass the codingstd test.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26589
<Coke> dalek, you on a hair trigger there?
<diakopter> dalek polls the rss every 30 seconds
% kid51 has left kid51!~jkeen@toronto-hs-216-138-231-37.s-ip.magma.ca
<Coke> /Users/coke/research/parrot/tools/util/gen_release_info.pl is missing the perl coda, if someone wishes for a quick win.
<diakopter> oooo I think dalek is actually throttling its posts
* diakopter high-fives Infinoid
<Coke> hearing no takers, I'll add the coda.
<diakopter> Coke: I would've, but I don't have a commitbit.
<diakopter> course, I haven't asked for one.
% rdice has joined #parrot
<Infinoid> looking good so far
<dalek> r26590 | coke++ | trunk:
<dalek> : [codingstd]
<dalek> : remove unused 'use'
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26590
<dalek> r26591 | coke++ | trunk:
<dalek> : [codingstd]
<dalek> : - add the perl coda to one file that didn't have it...
<dalek> : - ignore the perl6 files in nqp when running critic tests...
<dalek> : - perlcritic now passes all tests. Adding back to the default set of 
<dalek> :   codingstd tests.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26591
<Infinoid> Coke++ # was wondering why perlcritic wasn't in that set already
<diakopter> one disadvantage of the new system is that it doesn't force SVN::Web to precache the diff page.  So the first (few) person(s) to hit it experience a few-second delay.
<Infinoid> you could always fork off a "fetch" process right after writing the log to the channel
<Infinoid> or right before, if you wanted to guarantee a clean precache
<Infinoid> hmm.  "guarantee" is too strong a word.  but if you don't fork, it could idle out like svnbotl did
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
% rdice has joined #parrot
<pmichaud> how long does it take to do the precaching?
<pmichaud> maybe fork off a precache, wait five seconds, then write log to chan
<Infinoid> probably depends greatly on the size of the diff
<pmichaud> we don't need *immediate* notification of changes.  :-)
<Infinoid> think I'd prefer to make SVN::Web smarter so that it doesn't generate the same data multiple times in parallel
<dalek> r26592 | coke++ | trunk:
<dalek> : [codingstd]
<dalek> : Only generate diag output about this test if we're actually going 
<dalek> : to run the test.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26592
<Infinoid> if threads::shared stuff is valid in mod_perl, that should be pretty easy to do
<Infinoid> diakopter: that should reduce the overhead, right?
<Infinoid> hmm.  different problem, but still useful.
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
% turrepurre has joined #parrot
% kj has joined #parrot
% Theory has joined #parrot
% peeps[work] has joined #parrot
<dalek> r26593 | coke++ | trunk:
<dalek> : [codingstd]
<dalek> : Relax one of the not-yet passing perlcritic rules slightly
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26593
% Theory has left Theory!~Theory@207.109.95.2
% jjore is now known as zz_jjore
% zz_jjore is now known as jjore
% Theory has joined #parrot
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
% AndyA has left AndyA!~andy@82.152.157.85
% IllvilJa has joined #parrot
% kid51 has joined #parrot
<kid51> Coke:  ping
<Coke> pong
<kid51> Last night we had a Parrot/Rakudo build fest at Toronto.pm.  I have lots of data to report.
<kid51> Some of it is build/test logs on OSes that we haven't seen before.
<Coke> sweet.
<kid51> Some of it is failures on OSes that we see all the time, together with some diagnoses.
<Coke> You gonna open some tickets to track progress and/or hit the list?
<kid51> Particularly for tracking by OS, I was thinking of opening them up as RTs rather than simply as posts to the list.
<Coke> certainly for the failures, ya.
<Coke> (there is an "what os did this happen on" setting as well.
<kid51> I think I'll open up one ticket, intended to be open-ended, which simply says "Secure user feedback on build-install."  Then have other more specific tickets refer to that one.
<kid51> So the successful builds will close right away -- but we'll have a tag for that OS.  The ones that failed will be bug reports.  Okay?
<Coke> ... it's verbose, but fine.
% Theory has left Theory!~Theory@207.109.95.2
<Coke> thanks!
<wknight8111> If i'm interested in requesting a commit-bit, I have to fill out a CLA first, correct?
<Coke> it's a prereq to getting a bit, not to asking about it. =-)
<Coke> I would say anyone that gets accepted into SOC is probably going to get one (and branch to do their work in.)
<dalek> r26594 | pmichaud++ | trunk:
<dalek> : [tge]:
<dalek> : * Convert TGE to use Perl6Grammar and Perl6Regex instead of 
<dalek> :   deprecated pgc/P6Regex (RT#48028).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26594
<dalek> r26595 | pmichaud++ | trunk:
<dalek> : [json]:
<dalek> : * Convert JSON to use Perl6Regex and Perl6Grammar instead of the
<dalek> :   deprecated P6Regex and pgc tools (RT#48028).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26595
<Coke> seen js?
<purl> I haven't seen 'js', Coke.  There are too many close matches to list.
<Coke> seen kj?
<purl> kj was last seen on #parrot 5 hours and 32 minutes ago, saying: purl's not too nice today... 
% contingencyplan has joined #parrot
% chromatic has joined #parrot
<chromatic> pmichaud, ping
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
<pmichaud> chromatic: pong
<chromatic> I'm updating Pheme to use P6Regex; any advice?
<pmichaud> the biggest thing is to remember that non-word characters all require quoting
<chromatic> Or Perl6Grammar, whichever it is.
<chromatic> How about the quote token?
<pmichaud> normally it's commas, quotes, and hyphens that get overlooked
<pmichaud> checking
<pmichaud> it needs to be backwhacked
<pmichaud> token quote { \' }
<pmichaud> and the semi in token ws
<pmichaud> should be quoted or backwhacked
<pmichaud> the only other item is that any old-non-capturing rules  <?ws>  become <.ws> in the new syntax
<chromatic> Ah, I missed the semicolon.
<chromatic> Everything else I had.
<pmichaud> I don't see much else in the pheme grammar that needs convering
<chromatic> Scheme wins one.
<pmichaud> in the makefile, just change pgc.pir to use runtime/parrot/library/PGE/Perl6Grammar.pbc and it'll compile to the Perl6Regex syntax
<chromatic> Already done.
<pmichaud> that should be about it, then :-)
<chromatic> Thanks!
<dalek> r26596 | chromatic++ | trunk:
<dalek> : [Pheme] Converted grammar from pgc to Perl6Grammar.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26596
% Psyche^ has joined #parrot
% contingencyplan has joined #parrot
<cognominal> is there a parrot libray that does the equivalent of a perl6/unix unlink(). or system() as a cop out?
% Patterner has left Patterner!~Psyche@e177227052.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<dalek> r26597 | pmichaud++ | trunk:
<dalek> : [nqp]:
<dalek> : * Add some useful operators such as ++, --, &lt;, &lt;=, &gt;, &gt;=.
<dalek> : * Patch courtesy Klass-Jan Stol &lt;parrotcode@gmail.com&gt;  (kjs++)
<dalek> : * (some Pm modifications to patch before applying)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26597
<Infinoid> diakopter: might want to remove html escapes from the log message...
<pmichaud> s/remove/unescape/
<diakopter> Infinoid: I bet that's an option in XML::RAI
% slightlyoff has joined #parrot
<diakopter> maybe not
<Infinoid> I don't see one in XML::RSS::Parser (its backend) either
<diakopter> HTML::Entities it is, then :]
<Infinoid> you sound like you know what you're doing
<diakopter> :P
% dalek has left dalek!dalek@feather.perl6.nl
% dalek has joined #parrot
<jonathan> Ooh, we haz new SVN bot?
<diakopter> it's a teency bit smarter
% ruoso has left ruoso!~ruoso@195.23.92.2
<wknight8111> I HAS A NEW_SVNBOT  </lolcode>
<wknight8111> actually, i don't have one, but it isn't valid lolcode to say that YOU HAS one
<diakopter> well hmm.  why isn't it getting 26598
<Tene> Although perhaps it should be!
<Infinoid> heh
<Infinoid> "YOU HAS" == export
<dalek> r26599 | jonathan++ | trunk:
<dalek> : [rakudo] Start sticking in some bits of file I/O. open, which returns the new IO object, and has methods .print, .say and .close. prefix:= added too, but looks like Parrot IO iterator maybe isn't done yet. It's a start, anyway.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26599
<jonathan> diakopter: It looks like it missed my previous patch.
<jonathan> WHERE'S MY KARMA?! :'(
<Infinoid> jonathan++
<diakopter> jonathan++
<cotto_work> jonathan++
<jonathan> Phew!
<Infinoid> karma plus interest :)
<purl> plus interest :) has neutral karma
<Infinoid> karma jonathan
<purl> jonathan has karma of 444
<wknight8111> karma wknight8111
<purl> wknight8111 has karma of 7
<wknight8111> yay! positive integer!
<cotto_work> karma cotto
<purl> cotto has karma of 1
<cotto_work> karma cotto_home
<purl> cotto_home has karma of 1
<cotto_work> karma cotto_work
<purl> cotto_work has neutral karma
<diakopter> I must've killed it right after it logged the grabbing of 26598, but before it posted it to the channel
<Infinoid> probably.
<purl> Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look harder.
<Infinoid> purl: you sound like a volunteer
<purl> Infinoid: i'm not following you...
<Infinoid> purl: then lead!
<purl> Infinoid: sorry...
<jonathan> That's a palindromically pleasing number.
<jonathan> I'd best not check in anything else.
<cotto_work> or check in 10 things at once
<Infinoid> svnbotl got confused by lots of checkins at once, but dalek won't :)
<jonathan> Cool. :-)
<jonathan> Ah well, that at least gets the start of some I/O support for Rakudo.
<Infinoid> awesome
<Infinoid> jonathan++ # to annoy him into making 9 more checkins
<jonathan> Well, got a wedding tomorrow and seeing friends tonight and on Sunday, so probably not any this weekend.
<jonathan> I'm hackathoning next weekend though. :-)
<jonathan> OK, gotta go, happy hacking.
<Infinoid> seeya!
<Tene> Okay, anyone feel like talking to me about this getattribute thing?
<chromatic> What about it?
<Coke> pmichaud++ chromatic++ # ripping more stuff out.
<cognominal> jonathan++
<Tene> Nevermind, that does work as I expected.
<wknight8111> I wish I could hackathon all weekend. real life is the pits
<cognominal> how do I generate a .pbc from a .p6 file?  the -o seems ununplemented. And getting a pbc from a pir file generated by  --state=pir gets me "No such called depth"
<Coke> cognominal: ../../parrot perl6.pbc --target=pir foo.p6 | ../../parrot -o foo.pbc -
<Coke> untested. =-)
<Coke> Do we have any IMCC hackers about?
<Coke> wondering if we can a patch for 48024 so we can see how close we're getting. Most of the usages of that syntax have been ripped out.
<cognominal> ok , one must gives the -o foo.pbc before the  foo.pir. makes sense.
<cotto_work> seen allison
<purl> allison was last seen on #parrot 17 days ago, saying: jonathan: yes, it's there now  [Mar 11 12:56:49 2008]
<chromatic> Coke, I can't find anything specific to IMCC which parses them specially.
<chromatic> I think they're macros.
<dalek> r26600 | coke++ | trunk:
<dalek> : [json]
<dalek> : RT #52200
<dalek> : Use the more natural rule name 'value' instead of 'thing',
<dalek> : now that it works.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26600
<Coke> ... Doh.
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-200-192.dynamic.mnet-online.de
<Coke> that ticket really means "remove the new_p_i" opcode.
<Coke> and new_p_i_p, presumably.
<chromatic> But something in IMCC parses it.
<Coke> the .Integer ? yah, but I can remove the opcodes separately.
<Coke> (trying that now.)
<Coke> only one thing in the build depended on it (src/pic.c), struck that...
<dalek> r26601 | tene++ | trunk:
<dalek> : Fix lolcode for functions that don't have parameters.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26601
<Tene> Okay, wtf, did I stop working on lolcode before I actually finished what I was trying to do?
<Tene> Could what was there have ever actually worked?
<Tene> Still doesn't actually work for functions that *do* have parameters.
<Coke> pretty sure it did at one point yes. I blame the merge back of the pmc stuff.
<Coke> at one point, at least most tests passed...
<Coke> but it's probably quicker to fix them to figure out when they broken. :|
% iblechbot has joined #parrot
<Coke> #   Failed test 'no trailing whitespace'
<Coke> #   at t/codingstd/trailing_space.t line 50.
<Coke> # Trailing space or tab char found in the following files:
<Coke> # /home/coke/sandbox/parrot/languages/perl6/src/builtins/io.pir 110
<nopaste> "coke" at 72.228.52.192 pasted "test results of removing new_p_i and new_p_i_p .." (11 lines) at http://nopaste.snit.ch/12590
<chromatic> That's not bad at all.
<Tene> I wrote a >100-line messy pir routine without any comments?
* Coke fixes one of those.
<dalek> r26602 | coke++ | trunk:
<dalek> : new_p_i is [DEPRECATED], remove it.
<dalek> :  
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26602
<Coke> dalek, you can ignore trailing blank lines, you know.
<Infinoid> if that's our biggest complaint for a plugin that's less than 24 hours old, we're doing well :)
<Coke> Infinoid++ # ok, sheesh. =-)
<Coke> chromatic: looks like t/pmc/pmc.t can just remove all the tests that use new_p_i, since they're testing behavior of *that* opcode.
<Coke> (but I won't commit that just yet.)
<chromatic> Yeah, that's about the last one to commit.
<Coke> hurm. I assume find_type_i_p is also deprecated by this.
<Coke> is that a reasonable assumption?
<chromatic> Aha, found it in IMCC.
<chromatic> Coke, play with that patch and you'll find some targets for optimizations.
<dalek> r26603 | coke++ | trunk:
<dalek> : new_p_i is [DEPRECATED], remove it.
<purl> i already had it that way, dalek.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26603
* Infinoid blinks
* Coke feeds the bot, even with commits.
<cotto_work> botsnakc
<cotto_work> botsnack
<purl> :)
<Coke> which patch, the one from a few days ago? yah.
<Coke> chromatic: http://www.coleda.com/tmp/remove_new_int.diff
% kid51 has left kid51!~jkeen@toronto-hs-216-138-231-37.s-ip.magma.ca
<Coke> chromatic: ah, *that* patch. danke.
<chromatic> The nice part is that it removes code from IMCC.
<chromatic> The sad part is that it doesn't remove more.
<Coke> make
<Coke> ww
<Coke> applying that to my work in progress...
<Tene> Okay, the big problem was that I apparently reorganized the grammar a bit in an older commit and never fixed the actions to match.
<Coke> chromatic: Excellent, yes, this will let me do some major cleanups.
% sjansen has joined #parrot
<dalek> r26604 | tene++ | trunk:
<dalek> : Fix the last test failure.
<dalek> : Add tests for functions that have parameters.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26604
<Tene> ... oh, right, I have to do extra things when I add a new file.
<Tene> I'll remember that eventually.
<dalek> r26605 | tene++ | trunk:
<dalek> : Fix MANIFEST.  I'll remember this someday.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26605
<Coke> anyone know what the right way to do:     .const .Sub temp = "_default_combiner"
<Coke> is, without ".Sub" ?
<Tene> pdd19 includes the line:
<Tene> .const .Sub $P0 = "_sub_label"
<Coke> yes, but .Sub is going away, so... =-)
<Tene> '.const .sub foo = "_..."' appears in many places in the tree.
<Tene> What does it do now anyway?
<Tene> Okay, looks like I've got another hour left before this exam is over, and I've closed the lolcode ticket.
<Coke> give that man another ticket!
<Coke> ... or did you want a kewpie doll this time?
<Tene> Heh.
<Tene> obtw, my laptop screen died again.  I can't get it to come back up by plugging in an external monitor anymore.
<dalek> r26606 | coke++ | trunk:
<dalek> : [codingstd] avoid trailing whitespace
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26606
<Tene> "coke's laptop repairs"--
<Coke> chromatic: there, cleaned up the ones that come first in the build process before the first .const .Sub. =-)
<dalek> r26607 | coke++ | trunk:
<dalek> : use of type ids (e.g. ".Integer") is [DEPRECATED]
<dalek> : Avoid using them in some PIR modules.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26607
<chromatic> Does .const 'Sub' not work?
<Coke> error:imcc:syntax error, unexpected STRINGC, expecting INTV or FLOATV or STRINGV or PMCV (''Sub'')
<chromatic> Hm.
% GeJ_ has joined #parrot
<chromatic> I'll poke at that shortly.
% turrepurre_ has joined #parrot
<Coke> sehr gut.
<Coke> I am wondering why we're using that, rather than just a runtime find_
<chromatic> Maybe it gets optimized into the bytecode.
% szbalint_ has joined #parrot
% Psyche^ has joined #parrot
% jq- has joined #parrot
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-205-242.dynamic.mnet-online.de
% Patterner has left Patterner!~Psyche@e177234088.adsl.alicedsl.de
% turrepurre has left turrepurre!~chatzilla@90-229-128-103-no52.tbcn.telia.com
% TonyC has left TonyC!~tony@202-154-105-237.people.net.au
% nopaste has left nopaste!~opaste@202-154-105-237.people.net.au
% GeJ has left GeJ!~geraud@edna.nealab.net
% ruz has left ruz!~cubic@85.112.113.222
% lathos has left lathos!~simon@morison.arjam.net
% jq has left jq!~jquelin@merlin.mongueurs.net
% MagNET has left MagNET!MagNET@Hunger.hu
% szbalint has left szbalint!comet@dev.perl.hu
% Psyche^ is now known as Patterner
% daxelrod has joined #parrot
<Coke> well, if we have to convert them to runtime lookups to remove the .Foo, c'est le vie.
<chromatic> I'm not sure what they're doing.
<Coke> ok. i think I have all the .Foo stuff in library removed modulo .const .Sub, commit to following pending a test run.... but later. next is compilers/
% ruz has joined #parrot
<Coke> (i'm using make in the patched version to find the stumbling blocks, copying the edited files over to a pristine parrot, and then testing from there, and just commenting out any use of .const .Sub to get the thing to build in original working copy.)
<chromatic> ... nothing but net.
<Coke> more of a "does that seem like a reasonable approach." ^_^
<chromatic> I'd generate and apply a patch instead of copying files, but six of one...
% japhb has joined #parrot
% nopaste has joined #parrot
<dalek> r26608 | coke++ | trunk:
<dalek> : use of type ids (e.g. ".Integer") is [DEPRECATED]
<purl> i already had it that way, dalek.
<dalek> : Avoid using them in some PIR modules: especially when checking for Undef,
<dalek> : better to use the opcode than the explicit type check.
<dalek> : (also fix one grammar-o in a comment)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26608
<Coke> -> later
% TonyC has joined #parrot
<wknight8111> can we use .include (or something similar) in grammar and NQP files?
<chromatic> As inline PIR perhaps.
<chromatic> I don't believe PGE or NQP support that yet.
<wknight8111> okay, that's what I thought
<wknight8111> thanks
<Tene> ... oh, that isdecl() change I made to lolcode is probably wrong.
<Tene> I need to remember to test that when I get home.
% MagNET has joined #parrot
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<Tene> Yep, wrong.
<Tene> The two easy choices I can see are "empty redeclaration stomps on the old value" and "declaration without assignment is an error"
<Tene> I'm unsure how to get the "empty redeclaration doesn't stomp on the old value" behavior currently tested for while still allowing declaration without assignment.
% skids has left skids!bri@charon.clarku.edu
<japhb> NCI/extending question: How can C code (called as NCI from PIR, *not* an op) get the current interpreter?  Yes, I could have the PIR code do '$P1 = getinterp; myfunc($P1, real_args ...)' everywhere, but that seems ugly -- especially as getinterp returns a PMC-wrapped interp, so all of the C functions need to unwrap it.
<chromatic> Unless you pass the interpreter as an argument, you can't.
<chromatic> (without performing evil magic I won't guarantee will work)
<japhb> chromatic: er, why not?
<chromatic> You'll have to root around in the call stack to find a likely pointer.
<japhb> Since the C code is called synchronously from PIR, the interp is guaranteed to be the same (no problem with current interp getting swapped out from under it)
<japhb> Is there really no current interp anymore?
<chromatic> "the same" as what?
<chromatic> Perhaps I'm misunderstanding your question.
<chromatic> 1) you have a C function which does not take the interpreter or anything which contains the interpreter as an argument
<chromatic> 2) you invoke that C function through NCI
% davidfetter has joined #parrot
<chromatic> 3) within that function, you want a pointer to the interpreter which invoked that C function through NCI
<chromatic> Is that the question?
<japhb> yes
<chromatic> That's the same question as "How do I use the equivalent of Tcl's upvar in C?"
<japhb> Like I said, manually passing the current interpreter from PIR through NCI will certainly work, it's just ugly.
<chromatic> It's not uglier than the alternative, sadly.
<japhb> ah
<japhb> well, OK then, thanks
<chromatic> You're welcome!
<chromatic> I mean, I can imagine ways to do it, but none of them are robust and some of them are at least very platform specific.
% Andy has left Andy!~AndyL@host3130.follett.com
<Infinoid> sounds like the sort of thing TLS was invented for, but that doesn't make TLS any less ugly
<chromatic> It's just a global variable by any other name.
% daxelrod has left daxelrod!~daxelrod@pikachu-33.dynamic.rpi.edu
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
<Infinoid> eh... it's a different kind of scope.  I got to learn all about it when working on some threaded p5 xs stuff, and I still have scars from that.
<Infinoid> a C library being called from one parrot interpreter, which has wired a callback into another parrot interpreter, would break gloriously with TLS-stored interpreters
% peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com
% lathos has joined #parrot
% skids has joined #parrot
% szbalint_ is now known as szbalint
% mmcleric has joined #parrot
% slightlyoff has left slightlyoff!~slightlyo@204.14.154.209
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
% sirstan has joined #parrot
% sirstan has left sirstan!~graham@host86-129-217-149.range86-129.btcentralplus.com
<pmichaud> (.Sub versus find_):   the reason for using const .Sub is because it's the only way to get the address of an :anon subroutine at compile time.  If a subroutine is marked :anon, then you can't do a runtime lookup
<pmichaud> s/address/PMC
% tetragon has joined #parrot
% Limbic_Region has joined #parrot
% Theory has joined #parrot
% mmcleric has left mmcleric!~chatzilla@213.148.16.237
% lathos has left lathos!~simon@morison.arjam.net
% mmcleric has joined #parrot
<tetragon> I've been having make test failures with Parrot from svn, some of which involve SIGBUS, some of which don't.  I killed the test suite shortly after the imcc tests (which where the ones crashing hard were), and was wondering about a starting point for tracking some of that stuff down
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
<chromatic> A backtrace would help.
<tetragon> So, where's the preferred pastebin?
<tetragon> My system traps those things
<pmichaud> nopaste?
<purl> hmmm... nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://paste.husk.org/ or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or don't bother me while I'm eating
<nopaste> "tetragon" at 206.248.175.68 pasted "CrashReporter log for one SIGBUS of a few" (73 lines) at http://nopaste.snit.ch/12591
<chromatic> Can you run the failing program with parrot -t and correlate it to a line or two of PIR or PASM/
<tetragon> It's part of the test suite
<tetragon> I can try to determine one of the crashing bits of code
<tetragon> I have three other traces from today, they aren't all the same
<chromatic> Is this a fresh checkout?
<tetragon> Yes
<tetragon> I've identified one of the crashing tests
<chromatic> No previous builds in this directory?
<tetragon> I can redo it in another directory
<tetragon> Getting it to build on this system is a bit on the interesting side to begin with
<chromatic> Sometimes we get strange errors if we invalidate bytecode and rebuild without cleaning out already-generated bytecode.
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
<tetragon> One of the SIGBUS tests is test 32 of  t/compilers/imcc/syn/macro.t
* tetragon is waiting for another tree of parrot to finish downloading
<tetragon> It both failed the test in terms of output and in terms of crashing
<chromatic> Parrot should never crash.
<chromatic> That's the part that concerns me the most.
<tetragon> I can paste that instances prove -v output and the trace
% rdice has joined #parrot
<tetragon> SIGBUS on a copy I pulled out of svn a few minutes ago
% AndyA has joined #parrot
% skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net
* Infinoid watches everything break with "make -j" again
<Infinoid> someday, I will Do Something about that
<chromatic> Fixing the .str generation should do it.
<chromatic> It's race condition city in there.
<Infinoid> first time around, got a missing headerfile.  second time around (this time with just "make"), it built but got a "Null PMC access in invoke" later on
<Infinoid> I am highly motivated at the moment, lets see if I can wrap my head around it
<tetragon> I identified one of the other SIGBUS-causing tests
<tetragon> Although, that one does mention "TODO segfaults"
<Infinoid> awesome.
<tetragon> The test even passes because it's marked TODO
<Infinoid> which test?
<tetragon> That one is t/compilers/imcc/syn/regressions.t
<tetragon> (Only has one test)
<Infinoid> segfaults here too
<tetragon> Right now I'm trying to find a crashing test that isn't marked TODO
<Coke> pmichaud: (.const sub, anon) - there are a LOT of cases where this syntax is used on a non-anon sub.
% mmcleric has left mmcleric!~chatzilla@213.148.16.237
<tetragon> Although, I fail many cases without crashing
<chromatic> Coke, I've almost fixed that in IMCC.
* Coke returns, nearly human.
<tetragon> My build seems to be putting noops in places the test script isn't expecting any
<Coke> tetragon: has anyone suggested "make realclean" to you yet? any local diffs? 
<tetragon> This is straight off of svn
<chromatic> We went through that, Coke.
<Coke> roger roger.
<purl> roger roger is what those silly combat-droids say in Star Wars.
<Coke> purl, scooby snack!
<purl> Rank roo, Coke!
<Coke> chromatic: pick a number from 1 to 10.
<chromatic> okay.
<Coke> was it 7, +- 1?
<chromatic> It was 4.
<Coke> well, there's my problem.
<jjuran> What, that you can't read minds?
<Infinoid> we need an rt# for that
<Coke> ah, excellent choice. thank you.
* Coke should probably do something other than random number generator for selecting an injection site.
<Coke> chromatic: pick a number from 1 to 10.
<chromatic> Okay.
<Coke> was it 7, +- 1?
<chromatic> It was 2.4
<Coke> yah. definitely need a better scheme. 4 would have been funnier, though.
* Coke sees what else he can rip out of parrot.
<Coke> pmichaud: if you just want to *invoke* the anon, you can do it by name.
<tetragon> One of the crashing test scripts is t/op/01-parse_ops.t
<Coke> can you nopaste the output of prove -v t/op/01-parse_ops.t ?
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<tetragon> There is nothing unusual in prove's output
<Coke> if it's not unusual, how is it crashing?
<tetragon> All the tests pass
<tetragon> But parrot is crashing
<Coke> ... so it's crashing, but it's passing all tests? and prove -v shows you nothing unusual?
<tetragon> That's right
<Coke> for TODO tests, that's fine.
<Coke> (ish)
<tetragon> It's not a TODO test
<Coke> ok. which if the 335 tests is crashing?
<Coke> s/if/of
<tetragon> I'm not sure yet
<tetragon> Is each test a separate parrot process?
* Coke peeks at that file... yes.
<diakopter> Infinoid: http://rafb.net/p/Uqc0iZ64.html
<Coke> you can run them individually :
<dalek> r26609 | infinoid++ | trunk:
<dalek> : [lolcode] languages/lolcode/t/06-functionparams.t:
<dalek> : fix up svn metadata to pass t/distro/file_metadata.t
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26609
<diakopter> spooky
<Infinoid> damn I'm good.
<tetragon> Coke: Then it's either 334 or 335, going by the pause as the crash reporter gather's its data
<Coke> t/op/01-parse_ops_150.pasm, e.g.
<Coke> so, ./parrot t/op/01-parse_ops_150.pasm
<Coke> lemme know which one crashes.
<chromatic> Coke, new patch for RT #48024 submitted.
<tetragon> It's 335
<tetragon> I can paste the stack trace
<Coke> freaky. if I run it from the command line, it segfaults here, too, but my test harness doesn't seem to care.
<chromatic> Which, 334 or 335?
<Coke> 335
<Coke> 334 seems fine
<tetragon> Only reason I notice is that OS X pops up a stack trace whenever anything dies in an untoward manner
<chromatic> Hm, me too.
<chromatic> Interesting.
<Coke> hurm. it's "end\nyield".
<Coke> tetragon: heh. I shut that off at some point. =-)
<Coke> I can see why it passes, no expected output.
<Coke> tetragon: can you open a ticket for us to track this on?
<Coke> parrotbug?
<purl> parrotbug is mailto:parrotbug@parrotcode.org or http://svn.perl.org/parrot/trunk/docs/submissions.pod
<chromatic> Ugh:
<chromatic> 0xb7ec987f in INS (interp=0x804f008, unit=0x8240fd8, name=0x824e410 "yield", 
<chromatic>     fmt=0x0, r=0x8240468, n=0, keyvec=0, emit=1)
<chromatic>     at compilers/imcc/parser_util.c:749
<chromatic> 749             IMCC_INFO(interp)->cur_unit->instructions->symregs[0]->pcc_sub->calls_a_sub
<Coke> basically just "./parrot t/...." segfaults. stack trace would be nice.
<Coke> but not entirely necessarily, since chromatic is already 1 step ahead of us...
<Coke> chromatic: I thankfully am ignorant enough not to know why that's as ugly as it is.
<chromatic> Try figuring out which one of those is an invalid pointer.
<Coke> I bet xcode's GUI gdb could tell you.
<Coke> ... if I knew how to use it.
<Coke> hey, tetragon...
<Coke> ;=)
<tetragon> Yes?
<chromatic> I think you lick the screen until the colorful candy buttons do something.
<Coke> chromatic: they use lsd in the phosphors.
<tetragon> In my experience, it's more curse the candy buttons and drop down to the terminal
<Coke> tetragon: just wondering if you were familiar enough with xcode to use the nice builtin debugger which would might tell us which of those structures was dead.
<Coke> but based on your last send, guessing no.
<tetragon> I can try... but I've never really dealt with any of the graphical tools other than Quartz Composer
* tetragon pulls out Instruments
<tetragon> Argh... it really is designed for a larger screen than my laptop has
<Coke> chromatic: I wonder if it might be easier for us to have this patch conversation in a branch.
<nopaste> "chromatic" at 63.105.17.30 pasted "Fix t/op/01-parse_ops_335.pasm segfault" (15 lines) at http://nopaste.snit.ch/12592
<chromatic> The deprecate_me_harder branch?
<Coke> BWAHAAHAHA
<Coke> I finally convinced gmail and feather to get the damn patch applied.
<Coke> but nah, this patch to remove the .FOOs can be done independently of killing the things that use them.
<chromatic> Some can and some can't.
<chromatic> The .const .Sub change needs parser support.
<Coke> which is not covered in your patch?
% Theory has joined #parrot
<Coke> hey, your patch removes a XXX from imcc. nice.
<chromatic> My second patch adds parser support.
<chromatic> Which is the XXX?
<Coke> -            /* XXX: free valp->s if already used? Sounds like a good idea, */
<chromatic> Ah, nice.
<Coke> Here's my results after running make test with your patch: -            /* XXX: free valp->s if already used? Sounds like a good idea, */
<Coke> er,
<Coke> Files=560, Tests=11071, 273 wallclock secs ( 0.80 usr  1.27 sys + 127.63 cusr 38.83 csys = 168.53 CPU)
<Coke> Result: FAIL
<Coke> Failed 12/560 test programs. 22/11071 subtests failed.
<chromatic> Sounds like mine.
<chromatic> A few other PMC constants to clean up.
% skids has joined #parrot
<pmichaud> Coke:  In PGE I don't want to invoke the .Sub immediately -- I need to store it somewhere so it can be invoked later
<Coke> k
<chromatic> pmichaud, don't worry; we saved the semantics (if not the syntax)
<pmichaud> I'm not tied to the syntax.  :-)   But I definitely do need the ability to grab the PMC for anonymous subs in the current impl of PGE
<chromatic> It'll stick around.
<Coke> chromatic: Ok. this looks good enough here, that I think combined with my patch, we might able to knock this out this weekend. why don't we branch so we can rip it all out and see how it looks.
<chromatic> Be my guest!
<Coke> k.
<pmichaud> chromatic++ Coke++
<chromatic> I had to patch a parser.  I don't deserve to have to create a branch.
<pmichaud> I need to grab some dinner... bbl
<chromatic> bungee-pumpking
<Coke> ok. but we'll make someone else merge it to trunk when we finish.
<chromatic> one, two, three NOT IT
<Coke> NOT IT!
* Coke goes back through the buffer... patrick. ha!
<chromatic> particle
<purl> mailto:jerry.gay@gmail.com
<pmichaud> ???
<chromatic> If you're not used to it now, Patrick... sheesh!
* pmichaud (totally lost)
<Coke> this looks right, neh:
<Coke> svn copy -r https://svn.perl.org/parrot/trunk https://svn.perl.org/parrot/branches/type_ids -m "Creating branch to try to remove type ids"
<Coke> s/try to //
<pmichaud> I don't think you need the -r
<pmichaud> oh wait, maybe you do
<Coke> no, you're right. -r needs a revision. like HEAD. or you can leave it off.
<Coke> see, good thing I checked.
<chromatic> Decapitate that command!
<Coke> ... orf with it's HEAD?
<pmichaud> okay, I really need dinner.  bbiaw
<Coke> AGIH!
<Coke> its! damnit.
* Coke goes to boil his fingers.
<dalek> r26610 | coke++ | type_ids:
<dalek> : Creating branch to remove type idse
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26610
<chromatic> idse?
<chromatic> bidse
<chromatic> spider?
<purl> o/` LADIES AND GENTELMEN!  Goobity coo coo goo coooooo!  Goobity coo coo goo coooooo!    Spider (he is our hero) Spider (get rid of) Spider (STEP ON SPIDER!) Spider (we love you spider)  I promise not to kill you (awwwwwwwwwwwwwwwwww) Spider (we love you spider) Spider (get rid of) Spider (must... stop) Spider (he is our hero) awwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww o/`
<chromatic> Huh.  I recognize that song.
<Coke> ... where the hell did the e come from?
* Coke checks his slide rule.
<Coke> the command line ended in ... type ids"e 
* Coke blames tachyons.
% rdice has left rdice!~richarddi@CPE001217e365c7-CM00159a01d44c.cpe.net.cable.rogers.com
<dalek> r26611 | coke++ | type_ids:
<dalek> : Remove IMCC support for the generated type IDs, ala: .Integer
<dalek> : Change .const .Sub syntax to .const 'Sub'
<dalek> : Courtesy chromatic++, RT #48024
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26611
<chromatic> hey waitaminute
<chromatic> commit sniper
<dalek> r26612 | chromatic++ | type_ids:
<dalek> : [src] Removed an unrelated change accidentally commited in r26611.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26612
<tetragon> As for another crash on a non-TODO test, test 61 of t/pmc/namespace.t
<tetragon> It also doesn't cause any failures visible in prove -v output
<chromatic> tetragon, did my nopaste from a few minutes ago fix the previous crash for you?
<tetragon> Haven't tested yet, was waiting for a clean tree to copy across
<Coke> chromatic: sorry. :|
<chromatic> don't worry about it
<chromatic> I'm just glad I didn't have to create a branch AND patch a parser.
<Coke> =-)
<tetragon> ./parrot t/pmc/namespace_61.pir doesn't crash, to trigger it you also need to pass in -O/
<Coke> chromatic: I think I got the easy half.
<chromatic> Looks like it.
<Coke> Haven't heard any object really about the revision thing.
<Coke> should also be able to rip that out this weekend.
% lathos has joined #parrot
<dalek> r26613 | coke++ | type_ids:
<dalek> : Rip out the variants of the new opcode
<dalek> : that let you create a pmc based on an integer type.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26613
<dalek> r26614 | chromatic++ | type_ids:
<dalek> : [t] Replaced some uses of PMC type ids with PMC names.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26614
<tetragon> Test 3 of t/dynoplibs/myops.t crashes without causing any failures visible to prove
<chromatic> Confirmed.
<chromatic> Can you file bugs for these?
<tetragon> I'm moving the crash reports off to the desktop with mail
<tetragon> Right now the build testing the patch is happening
<Coke> chromatic: I don't see any salvaging of the current incarnation of t/op/info.t
<chromatic> I haven't looked yet.
<Coke> if you concur, feel free to rm it.
<chromatic> I already removed one test in t/pmc/fixedpmcarray.t
<chromatic> working on the Continuation tests now.
<Coke> the t/pmc/pmc.t test is relying on the typeof_i_p opcode which has to be defunct. once I get the ok, I can rip out those opcodes, too.
<Coke> (and then a whole other bunch of tests.)
<dalek> r26615 | chromatic++ | type_ids:
<dalek> : [t] Fixed two more tests which relied on type ids.
<dalek> : One of the FixedIntegerArray tests specifically tested an opcode which uses
<dalek> : type IDs, so it's gone now.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26615
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
<dalek> r26616 | coke++ | type_ids:
<dalek> : Update some "new Integer" syntax that got missed.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26616
<tetragon> chromatic: Patch stops the failure of test 335 of t/op/01-parse_ops.t
<Coke> chromatic++ # all the hard work on the type ids.
<chromatic> Hey, you started it.
<Coke> Yes, but I never could have finished it. Thanks.
<Coke> Alright. I'm going to go sleep, and hope the Architect fairy answers my question by the time I have the computer to myself for a few hours again.
<tetragon> What does the option '-O/' mean to parrot?
<chromatic> I think it's an error, but I'm not sure.
<tetragon> It's being passed into it in t/pmc/namespace.t
<dalek> r26617 | chromatic++ | type_ids:
<dalek> : [t] Removed PMC type ids from remaining failing tests.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26617
<tetragon> Test 61 crashes with -O/, and works without
<chromatic> What's passing in -O/?
<tetragon> Something, I'm trying to track it down
<dalek> r26618 | coke++ | type_ids:
<dalek> : [docs] minor cleanups to the book elminating some dead syntax.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26618
% Andy has joined #parrot
<tetragon> I see why parrot is being passed -O/
<tetragon> The optimization flag is being determined based upon the filename
<tetragon> I keep my source trees in /opt
<tetragon> That results in it pulling the / out of the test script's path instead of the intended behaviour of pulling it out of the filename (of which a few are of the form required for this)
<tetragon> (See lines 773 - 786 of lib/Parrot/Test.pm for details)
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
<Infinoid> wow, that sounds like a nice hard-to-find bug
<Infinoid> tetragon++
<tetragon> And for final confirmation, I'm doing a build in /tmp
* tetragon grumbles about having to fix the Makefiles on every tree
% cout_ has left cout_!~cout@c-68-58-247-49.hsd1.sc.comcast.net
<Infinoid> huh.  make -j2 apparently worked as of r21613
% cout has joined #parrot
<Infinoid> ...and r26309 broke it (that was the pdd17pmc branch merge)
<chromatic> Bleh.
<chromatic> Try debugging something in *that*.
* Infinoid starts by stripping out all the changes except for Makefile and c2str stuff
* Infinoid fails horribly
* Infinoid starts bisecting in the pdd17pmc branch history, instead
<cout>  ~.
% AndyA has left AndyA!~andy@82.152.157.85
% AndyA has joined #parrot
% mncharity has joined #parrot
% mncharity has left #parrot
% Theory has joined #parrot
% peepsalot has left peepsalot!~peeps@cpe-67-9-161-48.austin.res.rr.com
% peepsalot has joined #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net
% tetragon has left tetragon!~seneca@206-248-175-68.dsl.teksavvy.com
% Student has joined #parrot
% Student has left Student!~Magical@5ac86067.bb.sky.com
% tetragon has joined #parrot
% drbean has left #parrot
<Infinoid> and (of course) the change that broke "make -j2" is buried within a set of 400 revs that don't build
<chromatic> Most of those should have built.
<chromatic> Most of them built for me anyway.
% Andy has left Andy!~Andy@64.81.227.163
<tetragon> So, when running make test from /tmp (not /opt), I now get only seven crashes, and they're all on tests marked TODO
<Tene> Hm.  I'm getting a 'make' failure that I wasn't getting earlier.
* Tene fresh-checkout.