% iblechbot has joined #parrot
% patspam has left patspam!~patspam@ppp59-167-137-64.lns3.mel6.internode.on.net
% razvanm has joined #parrot
% shamu has joined #parrot
% slightlyoff has left slightlyoff!~slightlyo@204.14.154.209
% irclogbot has joined #parrot
% moritz has joined #parrot
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% ruoso has joined #parrot
% IllvilJa has joined #parrot
% mj41 has joined #parrot
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% wknight8111 has joined #parrot
% Psyche^ has joined #parrot
% Patterner has left Patterner!~Psyche@e177236179.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<dalek> r27115 | fperrad++ | trunk:
<dalek> : [gettext]
<dalek> : - fix build on MinGW32
<dalek> : - more consistent with gmp.pm and others
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27115
% kid51 has joined #parrot
<kid51> Does anyone know what packages are needed to install OpenGL on Debian Linux?
<Zaba> what do you mean by installing OpenGL?
<kid51> Installing it such that configuration steps auto::opengl and gen::opengl detect it and work it into Parrot -- as we've been doing the past several days.
<kid51> We established that OpenGL "comes with" Mac OS X -- so I've used it successfully on my iBook.  But I tried to do so yesterday on an Ubuntu box and failed to get to the spinning triangle.
<kid51> When I did apt-cache search opengl, many selections came up but it wasn't entirely clear what packages I needed to add for this purpose.
<Zaba> you need opengl headers, I think
<Zaba> well and of course drivers appropriate for hardware which provide libGL, which you most likely have already.
<Zaba> /bin/sh: line 1:  6886 Segmentation fault      ./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
<Zaba> hmm, works after make clean
<Zaba> (as usual)
<rotty> kid51: apparently, you need at least mesa-common-dev (as this contains GL/gl.h)
% shamu has left shamu!~krishna@c-67-161-28-111.hsd1.ca.comcast.net
<tetragon> kid51: freeglut-dev is a package that provides the required header
<kid51> Thanks.
<kid51> tetragon:  Just got an error on Mac similar to the one you posted in 53170.  I just posted my build log.
<tetragon> I'm abot to test the patch
<Zaba> hmm
<Zaba> in perl6, are there exception objects?
<tetragon> kid51: I got r27101 to build with chromatic's patch
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<Zaba> hmm
* Zaba runs rakudo on spec test
<tetragon> kid51: It built, but I got the same crash during test
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-196-134.dynamic.mnet-online.de
<tetragon> kid51: t/op/sprintf.t test 174 is crashing with chromatic's patch
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
* tetragon looks up where to set the watchpoint
% Zaba_ is now known as Zaba
<Zaba> rakudo is not very good on spec tests so far, it seems..
% mj41 has left mj41!chatzilla@pc-jurosz.ro.vutbr.cz
* Zaba would really like to contribute if he just knew how to code in pir properly
<dalek> r27116 | fperrad++ | trunk:
<dalek> : [digest]
<dalek> : - rename gen::digest to gen::crypto
<dalek> : - add tests for gen::crypto
<dalek> :  Courtesy of kid51
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27116
<kid51> Zaba:  You're not alone in that!
<Zaba> I mostly code perl5 myself
<kid51> me too; it meets all my personal and day-job needs 
<Zaba> what puzzles me is that there are so much ??s in failed tests list
<Zaba> kid51, though I really like perl6 from what I read about/in it
<kid51> Which failed tests lists?  Those for parrot, or those for perl6?
<Zaba> perl6, spectest
<kid51> I only began to go into languages/perl6/ recently, so I mostly don't know what I'm talking about.  But I think that most of those tests were imported from the now-suspended Pugs project.  So we expect to have many failures there as yet.
<Zaba> yes, there are many
<Zaba> but only few actually state total tests/which of them failed
<kid51> Unlike the Parrot tests, where if we have a failure (e.g., the one tetragon just reported), it needs immediate attention.
<Zaba> perl6 mostly fails with 'syntax error's on those pugs tests
<Zaba> kid51, so was pugs officially suspended and is no more being worked on?
<pmichaud> (explanation of '??')   if there's a "syntax error" in a test, then we can't run it to find out how many tests there are, thus ?? gets reported.
<pmichaud> where "syntax error" can mean either that it's really an error or that rakudo simply doesn't know how to parse that particular construct yet
<Zaba> seems like it was mostly rakudo
<pmichaud> sure, that's probably the case
<Zaba> for example, "}\n\n{" seems to have confused it in some of those tests
<pmichaud> but yes, if a file has a syntax error in it, we never even get to see the "1..23" that tells us there are 23 tests that were supposed to run.
<Zaba> I see.
<pmichaud> however, given the new fudge and test organization, we really ought to be able to drastically reduce the ??s
<Zaba> sounds quite good :>
<pmichaud> so this is a very useful observation
<Zaba> { say "test"; } { say "moep"; }
<pmichaud> that's not valid Perl 6
<Zaba> this is not a valid perl6 code, is it?
<Zaba> but with a semicolon there between } and { it is, right?
<pmichaud> yes.
<Zaba> so sub { something } more code requires a semicolon after } in perl6 too, right?
% skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net
<pmichaud> if it's being followed by something on the same line, yes
<pmichaud> sub foo { something } \n { say "bar"; }    # ok
<pmichaud> sub foo { something } { say "bar"; }   # error
<pmichaud> sub foo { something }; { say "bar"; }  # ok
<Zaba> I see.
<Zaba> that makes perfect sense.. more sense than perl5's way even
<Zaba> does rakudo implement type checking currently?
<kid51> pmichaud:  At our buildfest in NYC last week, someone who got to Hello World asked, "So where do I find the Perl 6 syntax?" -- and I didn't have a quick answer.
<pmichaud> kid51:  closest answer at the moment is the synopses, I think
<pmichaud> Zaba: rakudo has limited support for type checking -- jonathan's been adding it
<Zaba> pmichaud, limited in what?
<Coke> tetragon: "make -j2" should work. If you find that a "make" works when "make -j2" don't, open a bug ticket.
<pmichaud> limited in that it doesn't quite work everywhere, and some constructs it doesn't understand yet
<pmichaud> for example, I don't know if it understands things like  Dog|Cat yet
<tetragon> Coke: I haven't found that -j2 affects anything except backscroll readablilty
<GeJ> tewk++
% tetragon has left tetragon!~seneca@216.126.67.44
<GeJ> I was trying to create some bindings this week-end for some Enlightenment library and spent a couple of hours how to create the dlfunc calls.
* kid51 to $job
% kid51 has left kid51!~jkeen@pool-70-107-5-62.ny325.east.verizon.net
<GeJ> ncigen seems really interesting.
<Zaba> ncigen?
% wknight8111 has joined #parrot
% tetragon has joined #parrot
<GeJ> http://code.google.com/soc/2008/perl/appinfo.html?csaid=DF96A07990EB6EC1
<shorten> GeJ's url is at http://xrl.us/bjons
<wknight8111> seen chromatic
<purl> chromatic was last seen on #parrot 3 days and 9 hours ago, saying: Nice work.  [Apr 18 21:01:53 2008]
% shamu has joined #parrot
% contingencyplan has joined #parrot
% contingencyplan_ has left contingencyplan_!~contingen@cpe-76-186-27-146.tx.res.rr.com
% tetragon has left tetragon!~seneca@69-196-138-185.dsl.teksavvy.com
<dalek> r27117 | fperrad++ | trunk:
<dalek> : [digest]
<dalek> : - allows SHA256 & SHA512 when OpenSSL 0.9.8
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27117
<Infinoid> msg kid51 http://packages.ubuntu.com/freeglut3-dev (if you haven't already sorted that out)
<purl> Message for kid51 stored.
% bpphillips-1 has joined #parrot
<Coke> Infinoid: another patch for you regarding the ops syntax : http://rt.perl.org/rt3/Ticket/Display.html?id=52570
% jhorwitz has joined #parrot
<Infinoid> Aaw, for me?  You shouldn't have.
<Coke> =-0
<Coke> er, =-)
<Infinoid> I think this has been an especially volatile week for parrot development
<Infinoid> lots of big changes, lots of stuff going on
<Coke> While I disagree, I let it accept ":flag1:flag2" for now. I just happened to write them all with the space.
<Coke> For the first time in some time, I had to resolve a conflict on that patch, so yah. =-)
<Infinoid> patch fails to apply cleanly, rejects hunks in src/ops/pmc.ops and src/ops/debug.ops, even with r27116 (the rev the patch was apparently generated from)
<Infinoid> but I'm still able to read through the patch
<Infinoid> I like it.
% skids has joined #parrot
% sjansen has joined #parrot
<Coke> I may need to re-up.
<Infinoid> the only addition I'd consider is making $flags a hashref populated by the parsing code, and using exists($flags{pic}) instead of regexes
<Infinoid> seems cleaner, and makes things look more like pmc2c.
<Zaba> Infinoid, that indeed looks cleaner
<Infinoid> well, exists($$flags{pic}) or exists($flags->{pic}) if you prefer... whatever.
<Coke> Infinoid: I think that can go in as a separate patch.
<Infinoid> agreed
<Zaba> hmm
<Zaba> some crypto tests fail here
<Zaba> (parrot)
<Coke> the failures are just copyrights.
<Zaba> t/codingstd/trailing_space.t    1   256     1    1  1
<Zaba> t/steps/auto_crypto-03.t        5  1280    17    5  10-12 15-16
<Zaba> hm
<Zaba> there's some trailing whitespace in config/gen/crypto.pm line 72
* Infinoid fixes that
<dalek> r27118 | infinoid++ | trunk:
<dalek> : [digets] Remove some trailing whitespace introduced by r27117.
<dalek> : Zaba++ for reporting it.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27118
<Zaba> and about crypto.. mhm
<Zaba> I assume the problem's on my side
<Infinoid> not necessarily.  r27117 changed crypto
% iblechbot has joined #parrot
<Zaba> shall I pastebin prove -v output?
% Andy has joined #parrot
<Coke> ... DOH.
<Coke> I'm trying to figure out why that file is showing binary. the mime type is "plain/text"
<dalek> r27119 | coke++ | trunk:
<dalek> : The mime type is 'text/plain', not 'plain/text'
<dalek> : (ugh, do we need to update the file_metadata test?)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27119
% ccube has joined #parrot
% sjansen has left sjansen!~sjansen@75-169-120-213.slkc.qwest.net
* Coke wonders what mime type "text/script" is supposed to be.
% ambs has joined #parrot
<ambs> seen alias
<purl> alias was last seen on #perl 7 hours and 54 minutes ago, saying: job done 
<ambs> seen merlyn
<purl> merlyn was last seen on #moose 32 days and 16 hours ago, saying: ... http://methodsandmessages.vox.com/library/post/the-year-of-smalltalk.html  [Mar 20 15:09:20 2008]
% rdice has joined #parrot
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
<dalek> r27120 | coke++ | trunk:
<dalek> : A file of type "plain/text" (instead of text/plain) 
<dalek> : was added to the repo recently, confusing svn
<dalek> : into thinking it was binary.
<dalek> : Test for this by checking all the mime types (which we already had to do
<dalek> : anyway..) against an explicit list of those we allow... which is basically
<dalek> : all the sane types I found in the repo.
<dalek> : Remove the one remaining obviously wrong file type this exposed.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27120
<dalek> r27121 | coke++ | trunk:
<dalek> : [codingstd] Nothing to see here, move along.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27121
% mj41 has joined #parrot
% ambs has left ambs!~ambs@siglab.di.uminho.pt
% jalbo has joined #parrot
<jalbo> Hello.
<Coke> jalbo: hio
<Tene> jalbo: hi
% gryphon has joined #parrot
% Theory has joined #parrot
<Zaba> hmm
<Zaba> t/distro/file_metadata.t    2   512     5    2  3-4
<Zaba> http://rafb.net/p/xLNi9D82.html
<jalbo> I'm having same error.
<Zaba> seems like some svn attributes are messed..
* Infinoid just fixed that :)
<dalek> r27122 | infinoid++ | trunk:
<dalek> : [tcl] Fix file metadata for pkgIndex.tcl.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27122
<nopaste> "Infinoid" at 96.238.213.50 pasted "crypto failures on linux/amd64" (36 lines) at http://nopaste.snit.ch/12760
<Infinoid> Zaba: are those the same failures you are seeing?
<Zaba> wait
<jalbo> Doing testing now...
* Zaba too
<Zaba> Infinoid, yes, exactly
<Infinoid> hmm.  not actually a failure in crypto, just in the config tests for crypto
<Infinoid> oh, and r27118 =~ s/digets/digest/
<jalbo> No, I was still in previous build, updating now.
<Coke> Infinoid: what change did you make there?
<Coke> as I just ran that test locally and got no errors pre commit.
<Infinoid> Coke: I followed the advice given by file_metadata.t:
<Infinoid> svn ps svn:keywords "Author Date Id Revision" languages/tcl/library/msgcat/pkgIndex.tcl
<Infinoid> svn ps svn:eol-style native languages/tcl/library/msgcat/pkgIndex.tcl
<particle> iirc those don't fail until the file has been committed
<Infinoid> I've noticed that file_metadata.t ignores my new files unless I update MANIFEST first
<Coke> That's not a new file.
<Infinoid> well, I don't know then
<Coke> particle: odd, because svn pg should return the *local* values, and therefore should fail.
<Infinoid> particle: mk_manifest_and_skip.pl will cause it to start noticing your files without having to commit
<Infinoid> I've been doing that for the new stub pmcs I've been adding to the pdd13pbc branch, and it's been working well.
<Coke> I'm not sure that's the right fix for files that are copied wholesale into the repo, but I'm pretty sure that one isn't going to matter, so nevermind.
<particle> when's the oscon hackathon? weekend before, or after?
<Coke> (the patch to .tcl)
<Coke> Infinoid: thanks for the cleanup
<Infinoid> np, nice that the test told me what to do :)
<pmichaud> oscon hackathon (if any) is after oscon, iirc
<pmichaud> before oscon is too difficult to arrange with other oscon events
<pmichaud> (at any rate, I can't make it before oscon, as I'll be vacationing in northern calif and oregon :-)
<Infinoid> pmichaud: if you come through the Lake Tahoe area, I'll buy you a beer.
<Infinoid> hmm.  maybe codingstd/distro tests which know how to fix it (like file_metadata.t and trailing_space.t) should have an option to do so.  t/codingstd/trailing_space.t --cleanup
<Infinoid> t/distro/file_metadata.t --jfdi
<jalbo> Updated to 27122, no metadata errors now.
<jalbo> t/steps/auto_crypto-03.t                   (Wstat: 1280 Tests: 17 Failed: 5)
<jalbo>   Failed test number(s):  10-12, 15-16
<jalbo>   Non-zero exit status: 5
<pmichaud> Infinoid: mmmm, Lake Tahoe.  So far we not going quite that far east.
<Infinoid> fair enough.  its not the most convenient place to drive to
<pmichaud> but it's awful pretty when you get there :-)
<Coke> Infinoid: I'd rather not have it do that. If we're going to do that, let's move to commit hooks.
<Infinoid> Coke: even better :)
<pmichaud> I just wrote a short shell script that fixes metadata settings
<pmichaud> so when file_metadata.t carps, I just invoke the shell command to fix it :-)
<Infinoid> file_metadata.t is nice for giving you the commands you need to run
<Infinoid> unfortunately, the trailing space and tab tests require manual editing, and I guess I'm just lazy.
<particle> we can employ perltidy and a 'make tidy' target
<particle> and obtw why don't you write pirtidy while you're at it
<particle> we already have a parser, in languages/pir
% razvanm has left razvanm!~razvan@85.183.0.99
% slightlyoff has joined #parrot
<Infinoid> eh.  a simple s/\s+$//; s/\t/        /g is sufficient
<Coke> there is a pirtidy.pl already.
<Coke> (but it's written in perl, not PIR0
<wknight8111> does it need to be written in PIR?
<particle> no
<particle> *but*
<particle> it'd be nice to have something that can take a parse tree and spit out re-formatted source
<particle> given a ruleset, for *any* hll
% AndyA has left AndyA!~andy@82.152.157.85
<particle> it could be written in nqp
<cognominal> should that mean annotation convention for the grammar?
<cognominal> like "is indent" or "has indent"
<particle> i'd like to have a library, written in nqp or pir, which takes rules (like perltidy) and applies them to a parse tree generated from PCT
<particle> so, that means it could be used for ruby, js, perl 6, etc
<Infinoid> "does prettyprint"
<Infinoid> or maybe that's something else
<particle> so is, has, does are all at the language's syntax level
<particle> that's not something i care about *yet*
<particle> but certainly could be useful in perl 6 to specify somehow
<cognominal> hum can we derive a grammar without changing rules but adding 'deparsing rules' annotations
<particle> as long as there's a way to store them in the parse tree, yes
<particle> then use an action file to emit the prettified source
<cognominal> btw, I am working on a parsing tree trimmer to make the parsing tree shorter and more readable
<cognominal> 160 line for a 27 chars programs does not make it  very useful grammar debugging tool.
<particle> nice
% shamu has left shamu!~krishna@c-67-161-28-111.hsd1.ca.comcast.net
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<particle> who made a mess of the imcc parser?
<particle> lots of warnings
<Infinoid> I regenerated imclexer.c a few days ago
% Zaba has joined #parrot
% chromatic has joined #parrot
<nopaste> "particle" at 24.19.3.148 pasted "messy imcc parser warnings" (43 lines) at http://nopaste.snit.ch/12761
<nopaste> "jalbo" at 213.96.228.50 pasted "Drop :const in isa and getclass, http://rt.perl.org/rt3//Public/Bug/Display.html?id=53066" (153 lines) at http://nopaste.snit.ch/12762
<jalbo> I'm testing this changes, all tests pass here.
<Infinoid> is that new?  imcparser.c hasn't been touched in a while
<particle> i don't know, i haven't built parrot in a while
<particle> compilers\imcc\instructions.c(141) : error C2059: syntax error : '}'
<particle> it could be that i'm noticing it only because my build failed shortly afterwards
% ruoso has left ruoso!~ruoso@195.23.92.2
<particle> i don't think c likes having empty curly brackets
% cjfields has joined #parrot
<particle> coverity... what's going on with that lately?
<chromatic> No scans since mid-February.
<chromatic> I've sent David a few messages here and there, but haven't heard back.
% sjansen has joined #parrot
<Coke> particle: c c or c chromatic?
<particle> ok, as long as somebody's on top of it
<chromatic> I'm on top of the big nothing happening anyway.
<particle> i know i can count on you.
<particle> care to fix my build?
<Coke> anyone aside from Infinoid have feedback on the ops syntax update?
<pmichaud> I haven't been following it closely, but :flag1 :flag2 is my preference
<Coke> in general, no one seems to complain about having to not write goto NEXT(); =-)
<wknight8111> where can we get more information about the update? I haven't read anything about it
<chromatic> particle, what's your build problem?  Is it the same as tetragon's?
<Coke> wknight8111: mailing list: :"[PATCH] Simplify ops syntax"
<wknight8111> thanks coke
<Coke> it's a minor thing. i figured if it was hated, someone would have spoken up.
<particle> compilers\imcc\instructions.c(141) : error C2059: syntax error : '}'
<chromatic> Hm, an empty array initializer.
<pmichaud> oh, that's mine.
<pmichaud> I did that when removing restoreall/saveall
<particle> ah. that's who i should blame
<pmichaud> I'll fix it... just a sec.
<chromatic> You can delete more code in there.  Nice.
<pmichaud> well, I didn't want to get rid of it entirely in this case
<pmichaud> in case we ever re-introduce an opcode that needs special handling and is of the 'read' sort.
<pmichaud> otoh, if we wanted to get rid of cleari, clearn, clearp, clears then this might be a good time to do it :-)
<dalek> r27123 | jkeenan++ | trunk:
<dalek> : Temporarily disabling tests in response to Mark Glines' report of test failures in http://rt.perl.org/rt3/Ticket/Display.html?id=53126.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27123
<Infinoid> Zaba++'s report, actually.  I'm just a routing protocol.
<chromatic> pmichaud, I meant the loop over reads.
<pmichaud> right, I was planning to leave it there in the code.  But I'll comment it out.
<chromatic> Why comment it out?  It's dead code.
<pmichaud> it might come back if we get another special "read" op?
<chromatic> Is that likely?
<pmichaud> I hope not.  But I guess we could eliminate r_special as well, then?
<pmichaud> (just looking into that)
<chromatic> Looks like it.
<pmichaud> so, we'd just be left with w_special then for the clear[isnp] ops.  Sounds good to me.
* pmichaud grabs his trusty Acme Code Ripper (TM)
<pmichaud> removing r_special does seem to rip out a fair amount of code
<pmichaud> I'll do it in two stages -- one to get code compiling again, another to do a more thorough cleaning.
<chromatic> Perfect.
<purl> if it seems perfect, your understanding is less than perfect.
<chromatic> One fewer global in IMCC is also very good.
<cognominal> Coke: "anyone aside from Infinoid have feedback on the ops syntax update?". Are these flags yet  used anywhere. If yes were?
<Coke> cognominal: I'm adding in :flow; the only other one I see in use is :pic
<pmichaud> (just a rebuild and make test away from committing.)
<Coke> cognominal: mainly trying to add :flow, not remove other dead flags.
<cognominal> I don't say they are dead, I ask if they are used yet.
<cognominal> I see their use for a restricted parrot.
<particle> coke: after i build parrot successfully based on patrick's fix, commit it and i'll test
<particle> the security pdd is on the list of things todo
% ambs has joined #parrot
<cognominal> well, in the mean time there is obvious stuff like a restricted parrot cannot open files and sockets
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
<Infinoid> is that something I'll have to care about, for the new .pbc file writing code?
<chromatic> No.
<Infinoid> great.
<dalek> r27124 | allison++ | trunk:
<dalek> : [pdd] Add interface specification to Strings PDD.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27124
<dalek> r27125 | allison++ | trunk:
<dalek> : [pmc] Correcting bad documentation in the String PMC found while working on the
<dalek> : Strings PDD.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27125
% allison has joined #parrot
<mj41> hi, does anybody use http://tt.perl6.cz/ ? or is it still useless? :-)
% ambs has joined #parrot
<pmichaud> re-testing... ran into a test failure (svn up hopefully fixes it)
<dalek> r27126 | allison++ | trunk:
<dalek> : [pdd] Removing obsolete documentation from datatypes PDD, since the updated
<dalek> : content exists in other PDDs.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27126
<pmichaud> particle: r27127
<dalek> r27127 | pmichaud++ | trunk:
<dalek> : [imcc]:
<dalek> : * Fix empty const array introduced by removing saveall/restoreall.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27127
* particle rebuilds
<pmichaud> someone want to double-check me.... is the "ins_reads2" function in instructions.c actually *used* anywhere?
<pmichaud> oh, I found it.
<pmichaud> okay.
<pmichaud> oh, no I didn't.  back to earlier question.. is it actually *used* anywhere?
<pmichaud> aha.  It's not used anywhere because I dead-code removed it last night.
<pmichaud> cool, more ripping.  :-)
<chromatic> Always nice.
<pmichaud> hmmm, that's not it.  checking more.
<pmichaud> looks like that function was never called.
% barney has joined #parrot
<dalek> r27128 | allison++ | trunk:
<dalek> : [pdd] Launching the Strings PDD out of draft.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27128
% Ivatar has joined #parrot
<particle> parrot's failing a lot of tests now
<chromatic> Did you make realclean recently?
<dalek> r27129 | pmichaud++ | trunk:
<dalek> : [imcc]:
<pmichaud> there was a PBC_COMPAT update last night as a result of eliminating saveall/restoreall
<dalek> : * More dead code removal.  The ins_reads2 function is never called,
<dalek> :   so we get rid of it and the r_special array.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27129
<Infinoid> All tests successful here on r27127
* Infinoid does it again
<pmichaud> all tests successful here on r27129.
<chromatic> #ps in 3
<particle> Failed 45/580 test scripts. 216/11212 subtests failed.
<ambs> particle, what arch?
* Coke guesses winders.
<particle> msvc
<ambs> Coke, yeah, I guessed that as well after asking
<Coke> chromatic: that's not quite what I meant, but by all means, you can lead this dance. =-)
<Coke> watch out, I will CRUSH your toes if you're not careful.
<chromatic> I'm actually a good dancer.
<chromatic> Well, okay.  Adequate.
<ambs> yay!
<ambs> /bin/sh: line 1:  8911 Segmentation fault      ./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
<Coke> ugh, I hate that error.
<chromatic> is this after a make realclean?
<Coke> (if so, did you build with -j ?)
% davidfetter has joined #parrot
<ambs> chromatic, not yet. doing it now
<Coke> .flanders!
<chromatic> Yeah, if PBC files depended on PBC_COMPAT we might be able to avoid this somewhat.
<Coke> generated PBC file? I can do that.
<Coke> (and static ones as well.)
<Infinoid> (we have static PBC files?)
<chromatic> the native PBC tests
<Coke> we're skipping those atm, neh?
<chromatic> Yeah, too much PBC_COMPAT churn.
<Ivatar> hmm, I had problems with miniparrot yesterday... seems to be fixed now.
<chromatic> I was getting sick of fixing them for kid51.
<ambs> and yes, make clean solved it
<nopaste> "particle" at 24.19.3.148 pasted "win32 build output and test failures (long)" (5856 lines) at http://nopaste.snit.ch/12763
<Infinoid> I suppose I'll have to update those when I change the .pbc file format
<Coke> now that "make -j" works, perhaps we can address the next level of "why do I have to make realclean".
<Coke> (one of which is the generated pbc fils.)
<ambs> hehehe
<chromatic> s/one/most/
<Coke> pmichaud: if you record it on my voicemail I can transcribe it for you. =-)
<ccube> Why is the Array class a subclass of ResizablePMCArray instead of the other way around?
<pmichaud> Array is fixed size
<pmichaud> it's easier to create a fixed size object from a variable-sized one than vice-versa :-)
<Coke> I don't think it used to be that way, diddit?
<chromatic> As long as I can remember, so at least ten minutes.
<ccube> So to check for a container I need to isa against ResizablePMCArray instead of Array
<pmichaud> better is probably "does array"
<Coke> array.pmc's pmcclass doesn't extend anything.
<pmichaud> as opposed to isa.  there might be multiple container base classes, as opposed to one master one.
<ccube> From a pedagogical standpoint the more fundamental class should have a more fundamental name
<Coke> RPA extends FPA which doesn't extend anything.
<ccube> Call what is currently ResizablePMCArray Array, and call Array FixedArray
<Coke> ccube: can we argue about one thing at a time? easier for us old timers. =-)
<Coke> array does not subclass RPA, that I can see.
<ccube> Well what is a better way to check if can create an iterator on a given PMC?
<pmichaud> $I0 = does $P0, 'array'
<ccube> I was checking by isa 'Array' and isa 'Hash'
<Coke> don't do that.
<ccube> does that work for hashes too
<Coke> does $P0, 'hash'
<pmichaud> $I0 = does $P0, 'hash'
<ccube> isa is deprecated?
<pmichaud> no, but isa checks class hierachy, as opposed to a role
<Coke> I don't think so.
<particle> ccube: get_iter $P0
<particle> ...ask the pmc for it's iterator
<pmichaud> whether or not a PMC can have an iterator on it is part of its interface or role, not what class it happens to be
<ccube> ok, does that return NULL pmc when you can't iterate over $P0?
<ambs> All tests successful, 26 tests and 570 subtests skipped.
<ambs> (27129)
<Coke> (that's easy enough to check, btw.)
<particle> ccube: look it up
<ccube> yep
<ccube> i'm checking
<ccube> get_iter is experimental ?
<particle> is it? it's been around forever
<particle> i guess we can move it out of experimental.
<ccube> in src/ops/experimental.ops - not in docs
<particle> lemme check the pdd
<pmichaud> I think get_iter is experimental, otherwise I'd have been using it more often instead of   $P0 = new 'Iterator', $P1
<particle> =item nextkey_keyed
<particle>   PMC* nextkey_keyed(INTERP, PMC* self, PMC* key, INTVAL what)
<particle>   PMC* nextkey_keyed_int(INTERP, PMC* self, INTVAL key, INTVAL what)
<particle>   PMC* nextkey_keyed_str(INTERP, PMC* self, STRING* key, INTVAL what)
<particle> Advance to the next position while iterating through an aggregate. [NOTE: this
<particle> feature needs review together with the Iterator PMC.]
<particle> that note at the bottom means it's not settled yet
<particle> so, use get_iter, until we replace it
<ccube> get_iter doesn't appear to be an op. it's not in include/parrot/oplib/ops.h
<Coke> at this point, somethings presence in experimental.ops isn't really an indication of its status.
<chromatic> Yeah, no one's moved them around in ages.
<particle> right
<ccube> It isn't an op at all, looks like a vtable method
<particle> the pmc pdd includes nextkey_keyed, though
<particle> get_iter is an op
<Coke> it's just "iter".
<Coke> particle: doesn't seem to be.
<particle> ah, right.
<particle> 'iter'
<particle> get_iter is the vtable function, iter is the op
<particle> $P1 = iter $P0
<particle> stupid me--
<ccube> hmm, iter called on a string PMC returns a true iterator, then my code fails when I try to reference index it
<Coke> ISTR String used to support iterator, doing char-by-char.
<Coke> what does it do on an Int?
<ccube> don't know yet
<ccube> but if you can't call shift on it they I believe you shouldn't get an object from iter that tests true
<particle> iterator pmc is a ball of mud
<chromatic> Just for fun, if someone has time, try getting a PMC keyed iterator on a NameSpace.
<ccube> That's what I'm trying to do
<ccube> I am writing a simple class information program that is running into all sorts of problems
<chromatic> The NameSpace PMC tests don't test that.
<ccube> it found that nice bug yesterday where key_string was passing the buck to Parrot_Key_get_string and Parrot_Key_get_string was passing the buck back to key_string - blew the stack
<ccube> a hazard of the buck passing style of programming
<chromatic> Yeah, I tried to fix that up, and now I think there's something funky in NameSpace's key handling.
<dalek> r27130 | infinoid++ | trunk:
<dalek> : [PMC] Back out vtable consting patches r27028 and r27029, per design discussion in #parrotsketch.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27130
<dalek> r27131 | infinoid++ | trunk:
<dalek> : [core] Un-const a caller of VTABLE_isa.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27131
<ccube> Is a there a tool that can tell you when functions are unintentionally calling each other recursively?
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
<chromatic> It's not really unintentional.  As far as I can tell, it's just NameSpace producing a bad Key.
<ccube> Well if intentional, you need to create a bottom
<chromatic> If NameSpace produced the right type of Key, it wouldn't happen.
<chromatic> I think it's a bug.
<chromatic> I don't know exactly where it is, but there's my prediction.
<ccube> yes, I would call blowing the stack a bug
<Infinoid> r27131 broke the build, forgot to update the prototype too.  fixing...
<ccube> Why are you calling a function that's just going to call you without changing anything?
<chromatic> It's not going to call back directly, ccube.  It's a bug.
<dalek> r27132 | infinoid++ | trunk:
<dalek> : [core] Remove const from the prototype too.  Infinoid--
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27132
<Coke> particle: you going to announce the SOC stuff?
<particle> on #ps?
<Coke> <nod>
<particle> okies.
<Coke> particle: can I go ahead and commit the ops syntax stuff?
<particle> coke: ok, can't make anything worse
<ccube> hmm, Hash  reports that it doesn't hash or Hash, NameSpace neither, ResizablePMCArray says it doesn't array or Array
<ccube> so it looks like I'm back to isa
<dalek> allison@perl.org | milestones:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?milestones
<Coke> ccube... can you provide a test, please?
<nopaste> "coke" at 72.228.52.192 pasted "ccube : this prints '1' for me." (5 lines) at http://nopaste.snit.ch/12764
<nopaste> "ccube" at 74.70.96.161 pasted "does fails" (80 lines) at http://nopaste.snit.ch/12765
<Coke> ccube: try "array", not "Array"
<ccube> tried that first
<Coke> "hash" not "Hash"
<ccube> tried that first too
<Coke> see my test.
<Coke> try that.
<ccube> maybe it works for a newly generated Hash, but not one you get in the tree that results from inspect
<particle> s/does/provides/ maybe?
<chromatic> No, provides is only for PMCs in the .pmc file.
<nopaste> "chromatic" at 63.105.17.30 pasted "does on RPA, Array, Hash, and OrderedHash" (26 lines) at http://nopaste.snit.ch/12766
<Coke> particle: committed.
<purl> The chicken is involved, but the pig is *committed*.
<dalek> r27133 | coke++ | trunk:
<dalek> : Apply patch in RT #52570 to simplify ops a bit, and make the syntax for
<dalek> : flags/classes a bit more rigorous.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27133
<nopaste> "coke" at 72.228.52.192 pasted "ccube: this prints "Hash\n1"" (8 lines) at http://nopaste.snit.ch/12767
<particle> Infinoid: what if you build a static parrot, and want to run postgres?
<Infinoid> particle: both schemes use "loadlib", so if "loadlib" doesn't exist, you're SOL either way
<Infinoid> I guess my question is whether those things should be pir-only or not, assuming that's possible
<dalek> allison@perl.org | milestones:
<dalek> link: http://www.perlfoundation.org/parrot/index.cgi?milestones
<ccube> coke, try it on the Hash you get from the PMC returned by inspect, like I am doing (I have done s/Array/array/ and s/Hash/hash/)
<Coke> ccube: I did that.
<Coke> as I demonstrated in the example.
<Coke> http://nopaste.snit.ch/12767
<Coke> so inspect seems to be returning a 'Hash', which does 'hash'.
<chromatic> Does loadlib not exist in a static Parrot?
<Coke> (parrotsketch) is someone translating us into spanish?
<ccube> yes, but with $P1 = inspect $P0 try it on $P2 = $P1['methods']
<particle> si y no.
<Coke> ccube: see, these details help. =-)
<particle> huh? what?
<particle> ccube: can you nopaste an example?
<particle> holy unreachable code, batman!
<ccube> take the program I pasted earlier and change Array to array and Hash to hash and try it
<Coke> ccube: which class are you inspecting?
<ccube> Any
<ccube> but I have tried Class and Array
<ccube> and NameSpace
<purl> hmmm... NameSpace is XSLT, other stuff isn't
<Coke> if I do 'methods' I get a null PMC back.
<pmichaud> Array might not have any methods on it.
<ccube> I wouldn't be asking you guys to debug my program for me if I didn't think it would help parrot
<Infinoid> purl, forget NameSpace
<purl> Infinoid: I forgot namespace
<pmichaud> Also, Array isn't really a "Class".  It's a PMCProxy :-)
<pmichaud> If this sounds confusing, it's because it is.  :-|
<szbalint> chromatic: yeah, those kinds of blog posts are good. Keep them coming!
<Coke> ccube: what do you expect that program to output?
<particle> coke: i get millions of warnings when building ops files
<pmichaud> I'm not sure if it's possible to inspect Class, Array, or Namespace
<ccube> print what inspect returns and if the object is a container print what it contains recursively (up to MaxDepth)
<particle> Class has an inspect method
<pmichaud> ccube:  perhaps Data::Dumper would do this, also?
<ccube> (that is the objects in the inspect hash)
<ccube> I am trying to learn parrot not dump data
<particle> runtime/parrot/include/Data/Dumper.pir
<particle> load_library 'Data/Dumper.pbc' or whatever
<ccube> I am trying to find out how given ops work
<pmichaud> ccube:  understood -- was just pointing that Data::Dumper does much the same thing.  You could look at how it does things.
<particle> data::dumper doesn't use inspect, for sure
<ccube> so I shouldn't use inspect?
<particle> there are tests  for inspect for class and object pmcs
<Coke> ccube: so the bug is that if you inspect something, and it has a methods key, you're not seeing any values?
<ccube> no - inspect returns a hash container and I call my display_container function on that if any of the VALUES in the container are containers, then recursively display them
<Coke> and it's doing that. what's the problem?
<ccube> that's the intention
<Coke> methods is a Hash, you find that. then what breaks?
<ccube> for me the version I pasted does not disply NameSpace or methods
<nopaste> "particle" at 24.19.3.148 pasted "win32 build output after coke's commit" (7177 lines) at http://nopaste.snit.ch/12768
<ccube> when I was using isa, it did (at least for Hashes)
<Coke> the version you pasted is broken.
<ccube> In what respect ?
<Coke> if you fix the 'Array' -> 'array', and 'Hash' -> 'hash' for does, how is your output then not correct?
<ccube> I said that I had done that locally
<ccube> same result
<Coke> yes, but then you said 'the code you pasted'. the more precise you are, the easier it is to help you. =-)
<Coke> Ok. I see .const string Indent='     '
<Coke> .const int MaxDepth = 6
<Coke> .sub main :main
<Coke> 	.param pmc argv
<Coke> 	.local int argc
<Coke> 	argc = argv
<Coke> 	if argc >= 2 goto ok
<Coke> 	die "Need to provide a classname"
<Coke> ok:	
<Coke> 	.local string classname
<Coke> 	classname = argv[1]
<Coke> 	$P0 = get_class classname
<Coke> 	$I0 = defined $P0
<Coke> 	if $I0 goto valid
<Coke> 	die "Invalid classname"
<Coke> valid:
<Coke> 	$P1 = inspect $P0
<Coke> 	$I0 = 0
<Coke> 	display_container($P1, $I0)
* particle points to NOPASTE
<Coke> .end
<Coke> GAH.
<Coke> sorry.
<Coke> I see: "methods: Hash". What is wrong with this?
<Coke> it was an accident. I know about nopaste.. thanks for your understanding. :P
<pmichaud> $I2 = does $P2, 'Hash'
<pmichaud> I see no $P2 here.
<Coke> (that certainly changes the output. =-)
<ccube> coke, yes I FIRST tried 'array' and 'hash' as you said, that didn't work so I tried 'Array' and "Hash', that's what I pasted, the I went back to 'array' and 'hash' again
<Coke> pmichaud has found your typo. Enjoy.
<pmichaud> ccube:  $I2 = does $P2, 'Hash'   # I see no $P2 here.
<pmichaud> (and yes, 'Hash' should be 'hash')
% barney has left barney!~bernhard@dslb-084-058-102-180.pools.arcor-ip.net
<ccube> ok, that let me fix that
<pmichaud> also note that
<pmichaud> $P1 = box[$S0]
<pmichaud> is likely wrong if box is an array container as opposed to a hash container
<pmichaud> if box is a Hash or hash-like object, then shifting over the iterator returns keys in the hash
<Infinoid> japhb: I was not criticizing your approach, quite the opposite.  I'm just wondering whether NCI will improve to the point that this stuff becomes easier :)
<pmichaud> but if box is an Array or array-like object, then shifting over the iterator returns the elements of the container
<Infinoid> japhb: sounds like OpenGL is an interesting test case for NCI.
<pmichaud> and so when box is an array-like container, we can't use the shifted elements of the iterator as keys to the container
<ccube> gee, i thought the point of an iterator was to act the same over all containers
<ccube> so I have to have a separate display_hash and display_array?
<chromatic> Yeah, but hashes and arrays are somewhat different.
<pmichaud> iterating over a hash is effectively the same as iterating over hash.keys()
<japhb> Infinoid: Oh, I didn't at *all* take your question as criticism.  I read it as an honest set of questions.
<japhb> Infinoid: Yes, it appears I keep pushing the NCI limits.  :-)
<pmichaud> japhb++ # push limits
<particle> tewk++ # expand limits
<ccube> ok guys, thanks for the help
<Infinoid> japhb: if it makes you feel any better, libfuse will be fun too.  It was a PITA with perl5 - it wants to call multiple callbacks in multiple threads at once, from threads it creates internally, without calling a thread-context initializer function first
% ccube has left ccube!~ccube@cpe-74-70-96-161.nycap.res.rr.com
<Coke> particle: please resend your nopaste link.
<particle> nopaste: "particle" at 24.19.3.148 pasted "win32 build output after coke's commit" (7177 lines) at http://nopaste.snit.ch/12768
<japhb> Infinoid: EWWW.
<Infinoid> so I had to play nasty games with TLS and store away a copy of perl's context structure, to dup as needed
<japhb> Infinoid: it sounds like libfuse's design is pretty hateful to bindings writers.
<chromatic> Any shared library that doesn't use opaque pointers is hateful to bindings writers.
<Infinoid> I am amazed that it works at all.  The bindings explicitly disabled multithreaded operation for years, which kinda sucks for a filesystem. :)
<japhb> quite
<particle> every thread has a different operating system
<japhb> As it is, I haven't solved the threading issue with the GLUT callbacks -- GLUT very deeply assumes global state is a design feature for its target audience
<particle> err, filesystem.
<particle> (joking while eating)--
<Infinoid> hopefully not :)
<japhb> must go AFK for a bit, bbl if you need me ...
<Coke> particle: unless ($flags =~ /\b:flow\b) ; # fails to match when $flags contains the string ":flow". hurmm.m
<Coke> (so it's always running the condition)
<Coke> meaning it's always adding goto NEXT(), which is why you have your warnings.
<particle> \: ??
<Infinoid> removing the leading \b makes it match
<pmichaud> \b:flow\b is probably wrong, yes
<pmichaud> as that would mean that there has to be a word character prior to the :
<Infinoid> the : itself is a good delimiter for the left side :)
<Coke> ... what Infinoid said.
<Coke> testing now.
<Coke> a holdover from the "," version.
<pmichaud> if you want to enforce spaces, then   \s:flow\b
<Coke> (and it still builds, compiles, and passes all tests.
<Coke> pmichaud: can't.
<dalek> r27134 | coke++ | trunk:
<dalek> : Fix re that checked for :flow tag (holdover from previous iteration).
<dalek> : The RE failed, which means the goto NExT() was added everywhere, which results
<dalek> : in unreachable code on any ops that were tagged :flow.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27134
* particle rebuilds
* particle reconfigs, then rebuilds
<particle> same
<particle> c:\usr\local\parrot\trunk\src\ops\io.ops(71) : warning C4702: unreachable code
<particle> c:\usr\local\parrot\trunk\src\ops\io.ops(71) : warning C4702: unreachable code
<particle> c:\usr\local\parrot\trunk\src\ops\io.ops(72) : warning C4702: unreachable code
<particle> c:\usr\local\parrot\trunk\src\ops\io.ops(71) : warning C4702: unreachable code
<particle> c:\usr\local\parrot\trunk\src\ops\io.ops(72) : warning C4702: unreachable code
<particle> c:\usr\local\parrot\trunk\src\ops\io.ops(73) : warning C4702: unreachable code
<particle> etc
<Coke> are you still getting one at core.ops(53) ?
<particle> no
<Coke> then those are different. hang on.
<particle> the first is core.ops(154)
<Coke> do you swear these errors didn't used to occur? =-)
<particle> i so swear.
<Coke> Parrot_load_bytecode_sc seems to end with two goto NEXT()'s.
<particle> the mail arrives, and for the 3rd day in a row, i visit catalogchoice.com
<ambs> lol
<Coke> aha.
<Coke> particle: I think the generated code is being passed to the multiple variants of an opcode.
<Coke> so when it's added once, it's then copied and then added again.
<Coke> hoisting the :flow check out of the loop will probably do it. checking...
<particle> i'll check the .c file
<Coke> yup, that seems to generate proper code.
% ruoso has joined #parrot
<Coke> particle: re-up, try again.
<dalek> r27135 | coke++ | trunk:
<dalek> : [ops]
<dalek> : Only add the implicit goto NEXT(); once per opcode, instead of accumulating
<dalek> : it once per variant.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27135
<particle> c:\usr\local\parrot\trunk\src\ops\object.ops(81) : warning C4702: unreachable code
<Coke> (and thanks for catching the warnings) - I am used to seeing warnings, so I'm not sure I would have noticed this ("make test passes? whee!")
<particle> many fewer warnings, but still ~20
<Coke> probably YA bug.
<particle> most in object.ops, some in string.ops
<Coke> ah. some of these aren't marked as ":flow" when they should be!
<Coke> can you nopaste the list? will make it easier to track down.
<nopaste> "particle" at 24.19.3.148 pasted "win32 build output after r27135" (83 lines) at http://nopaste.snit.ch/12769
* japhb BAK, if there was any remaining NCI/OpenGL discussion
<particle> is it done yet? :P
<Coke> be so nice if those warnings told me the OP name. =-)
<japhb> particle: thbbt.  :-)
<japhb> You can blame stomach flu for lack of progress, unfortunately
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<Coke> particle: that should kill some more, let me know what's left. :|
<particle> object.ops 565, 570, 575, 580, 585
<dalek> r27136 | coke++ | trunk:
<dalek> : [ops]
<dalek> : Mark some :flow ops as such.
<dalek> : Delete some superfluous goto NEXT();
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27136
<Coke> particle: that's the copyright section. :P
<particle> don't blame me
<particle> ops2c must be reporting faulty numbers
<particle> however, i can tell you they don't warn in core_ops_switch
<particle> just core_ops
<Coke> I'm guessing its: opcode_t *
<Coke> Parrot_pic_infix___ic_p_p (opcode_t *cur_opcode, PARROT_INTERP)  {
<Coke> PANIC(interp, "How did you do that");return 0;
<Coke> }
% rdice has joined #parrot
<dalek> r27137 | kjs++ | trunk:
<dalek> : [src] localize variables by adding 'else' clause, and remove some newlines within 1 statement, after which it's still well under 80 columns.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27137
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<particle> maybe. return 0 should go
<Coke> hah! I bet that was broken before! =-)
<Coke> particle: concur. You wanna commit that one?
<Coke> lib/Parrot/Op.pm line 394
<Coke> Though that whole thing seems fishy in the first place.
<particle> testing now
<particle> no warnings with that change
<Coke> particle:++
<Coke> particle++ #even.
<particle> coke++ # DRY - making op bodies smaller
<particle> however, i kinda feel the attribute should be the exception and not the rule
<Coke> sorry it took a few iterations. Thanks for the feedback.
<Coke> particle: it is!
<particle> really? i thought most ops had goto NEXT()
<Coke> goto NEXT(); is added by default. if it is present, it's not added.
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
<particle> ah.
<particle> perfect.
<purl> La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever
<Coke> at least better.
<Coke> next step is to look at all the flags we are declaring. I am tempted to make it a fixed list and die on the build if one that isn't kosher is specified.
<Coke> ... and then we can remove the ones that are crufty and will never be implemented.
<particle> speak with allison if it looks like any are security related
<particle> i'd like to have an op security model that groups ops into categories
<particle> then we can specify by category which ops to enable/disable or flag as unsafe
<particle> as well as being able to specify by name
<dalek> r27138 | kjs++ | trunk:
<dalek> : [src] localize variables and align assignment operators.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27138
<dalek> r27139 | particle++ | trunk:
<dalek> : [ops2c] silence final msvc warnings by removing unreachable code in generated PANIC() macro - coke++
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27139
<jonathan> This week's "why I missed parrotsketch" excuse: I was on a plane, and too stingy to pay for expensive airport wifi to pre-file.
<Coke> jonathan: FAIL!
<Coke> seen obra?
<purl> obra was last seen on #perl 14 days and 2 hours ago, saying: what dist did you try to install that showed the problem?  [Apr  8 11:58:05 2008]
<jonathan> how does one get purl to tell them the messages?
<Coke> messages?
<purl> To access purl's messages, msg me with the word "messages".
<jonathan> Cool, thanks.
<jonathan> Infinoid: will get to your questions when more than 5% of my braincells are working, which should hopefully happen after I've slept.
<Infinoid> no worries, I've got enough to keep me busy
<particle> jonathan: expect loads of test failures with trunk head
<particle> i'm hoping to find out why soon
<particle> but i'm sleepy too
<jonathan> particle: wasn't planning on doing anything tonight...
<jonathan> Last few days have generally been very busy seeing people, and then sleeping early on a night because I've felt a tad under the weather.
<jonathan> Managed to catch a cold within a couple of days of being in the UK.
% jhorwitz has left jhorwitz!~chatzilla@96.245.16.45
<particle> Failed 45/580 test scripts. 216/11212 subtests failed.
% bpphillips-1 has left bpphillips-1!d157b003@67.207.141.120
<ambs> good night
<purl> sleep well too
% ambs has left #parrot
% jalbo has left jalbo!~julian@50.Red-213-96-228.staticIP.rima-tde.net
% AndyA has joined #parrot
% cjfields has left cjfields!~cjfields@cjfields.life.uiuc.edu
% allison has left allison!~chatzilla@dsl-241-117-199.telkomadsl.co.za
% mire has joined #parrot
<particle> seems that "print $S" isn't causing parrot to error on win32
<particle> instead, it segfaults.
<Infinoid> bonus!
<Infinoid> limited time offer, low low prices.
<particle> hrm. interesting.
<nopaste> "particle" at 24.19.3.148 pasted "bt of seggy with parrot t/compilers/imcc/syn/symbols_1.pir" (14 lines) at http://nopaste.snit.ch/12770
<Infinoid> intl.dll?  gettext?
* Infinoid wonders if he broke particle with r27065
<particle> you did
<particle> i've attempted to fix locally
<Infinoid> hmm.  you could always reintroduce the typo... :)
% Limbic_Region has joined #parrot
<wknight8111> it's an extension of "if it ain't broke, don't fix it"
<wknight8111> "if fixing it breaks it, don't fix it"
<Infinoid> fixing the typo fixed RT #53112
<Infinoid> and apparently, broke msvc.
<Patterner> "FixedIntegerArray: Can't resize! current instr.: 'parrot;PGE::Util;__onload' pc -1 ((unknown file):-1)"   parrot Perl6Grammar.pir PGE/builtins.pg
% skids has left skids!bri@charon.clarku.edu
<particle> Patterner: did you realclean lately?
<Patterner> yes
<Patterner> r27139
<particle> harumph.
<particle> ah. this looks much better with the typo in place
<particle> ok, now i know what to fix
<Limbic_Region> thanks to whomever fixed the Win32/Cygwin bug preventing the build
<Limbic_Region> both Win32/MinGW and Win32/Cygwin are now stuck in nqp after parrot.exe is successfully linked
<Limbic_Region> which means perl6.exe can't be built either :-(
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-201-169.dynamic.mnet-online.de
% kid51 has joined #parrot
% tetragon has joined #parrot
* tetragon realises that she still has a gdb session open on the r27081 crash
<kid51> tetragon:  Was there any resolution of that problem we were looking at this morning?
<tetragon> The crash?  Not as of last I checked (this morning)
% Ivatar has left Ivatar!~graham@tu055.demon.co.uk
<tetragon> Really should finish looking up everything I need to be able to set a usable watchpoint for chromatic
% cognominal has left #parrot
% cognominal has joined #parrot
% skids has joined #parrot
<tetragon> Crash still happening for me on a clean r27139
% Andy has left Andy!~AndyL@host3130.follett.com
% ruoso has left ruoso!~ruoso@a81-84-242-82.cpe.netcabo.pt
% TonyC has joined #parrot
<Coke> tetragon: is this a crash resulting in a failing test?
<Coke> (or build)
<tetragon> Yes
<Coke> (which)
<tetragon> Both :-)
<tetragon> Build on its own, test with a patch from chromatic (but it's the same mechanism)
<tetragon> Ticket #53170
<Coke> seen chromatic?
<purl> chromatic was last seen on #parrot 4 hours and 47 minutes ago, saying: Any shared library that doesn't use opaque pointers is hateful to bindings writers. 
<chromatic> I'm looking at it.
<tetragon> chromatic: Any hints on that watchpoint?
<Coke> chromatic: pick a release number that predates your earliest recent speed improvements?
<Coke> s/release/revision/
<Coke> (or a date. want to compare tcl speed; seems much better, want to prove it.)
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
<chromatic> 26920 was my first big improvement.
<Coke> checking...
<Coke> make test | optimized build | r26900 | 2m47.244s
<Coke> make test | optimized build | r27122 | 1m44.511s
<Coke> (2+47/60)/(1+44/60)
<purl> 1.60576923076923
<Coke> chromatic++
<chromatic> There are still more to go.
<Coke> mmm. just glad to know that all the slowness in partcl ain't me.
<chromatic> There's plenty of slowness to go around.
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
<tetragon> chromatic: For the watchpoint on cc->dynamic_state, what should it be set on so that I don't have it falling out of scope on me?
% contingencyplan has joined #parrot
% Ademan has left Ademan!~dan@h-67-101-102-194.snfccasy.dynamic.covad.net
<chromatic> You can sometimes do a watchpoint on the memory address.
<chromatic> watch *(cc->dynamic_state)
<Coke> 22.077 / 0.043
<purl> 513.418604651163
<Coke> yay, down to 2**9 times slower than tclsh8.5; that's a few orders of magnitude. =-)
<Coke> chromatic++
<tetragon> That still falls out of scope
<particle> coke: Now that the hard part is over, all you have to do is sit back, relax, and hope that San Diego Zoo officials don't notice the uncanny physical resemblance.
<particle> ...my onion horoscope.
<chromatic> At that point I usually edit the source code to add in a static pointer, set a breakpoint for the crashy one, and use the set command in the debugger, then put the watchpoint on that value.
<tetragon> I was just firing up a memory debugger
<tetragon> But it's more oriented towards finding leaks
<chromatic> undefined reference to `offset_fixup'
<chromatic> Has anyone seen that?
<Infinoid> particle: still odd that there are so many parrot hacker birthdays so close together
<Coke> sounds like something that could conceivably be related to my ops twiddling.
<tetragon> Closest I've seen in my build logs is "src/exec_dep.h:32: warning: ?offset_fixup? used but never defined"
<chromatic> That does sound familiar.  I'm building on Linux PPC.
<Coke> ... hurm. that is also MY horoscope.
<Coke> (which I'm guessing particle knew)
<Infinoid> and mine
<dalek> r27140 | jkeenan++ | gencrypto:
<dalek> : Patch submitted to trunk; no need to retain branch.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27140
<dalek> r27141 | jkeenan++ | gencrypto-27092:
<dalek> : Branch corresponding to tag has been deleted; no need to retain tag.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27141
% Ademan has joined #parrot
<chromatic> Hm, segfault when building PGE's src/Grammar_gen.pir
<chromatic> That should sound familiar.
<tetragon> Your patch in the ticket stops that instance of segfault, moving it over to sprintf tests
% mire has left mire!~Frodo@148-169-222-85.adsl.verat.net
<chromatic> 0x0fc3b704 in pobject_lives (interp=0x10018040, obj=0x11) at src/gc/dod.c:190
<chromatic> Yeah, looking really familiar.
<dalek> r27142 | jkeenan++ | trunk:
<dalek> : Renumber tests to preserve sequence.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27142
<dalek> r27143 | jkeenan++ | trunk:
<dalek> : Update (renumber) references to file name within file.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27143
% particle has left particle!~particle@c-24-19-3-148.hsd1.wa.comcast.net
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% guru has joined #parrot
<chromatic> Aha.
<nopaste> "chromatic" at 63.105.17.30 pasted "Yet Another Stack Chunk Refcounting Patch Update for tetragon" (94 lines) at http://nopaste.snit.ch/12772
<chromatic> tetragon, can you try this patch instead of the previous version?
<Tene> So, does it still seems feasible for all parrot-hosted languages to eventually be able to use all of Perl 5 CPAN?
% kid51 has left kid51!~jkeen@pool-68-237-13-88.ny325.east.verizon.net
<chromatic> If their semantics support it.
* Infinoid tries to imagine what the XS->parrot bridge would look like
<chromatic> A dog's breakfast.
<chromatic> Althought Nicholas had some ideas of macro redefinitions.
<Tene> Just making sure I'm not spreading misinformation.  Embedded Perl 5 interpreter specced for 1.0?
<Infinoid> XS is heavily macroized, but things have been done over so much, there's 3 ways to do everything
<chromatic> Not on the list I've seen yet, Tene.
<Infinoid> would be fun to thumb our noses at it by making all the refcounting stuff into noops, though. :)
<Tene> chromatic++ # questions--
% guru has left guru!~guru@bas3-toronto02-1279463571.dsl.bell.ca
* tetragon starts a build with the new patch
<chromatic> I'm most of the way through a full test run, and everything's golden here.
% Andy has joined #parrot
<tetragon> make completed without crash.  Now for the tests
<tetragon> Only the usual crashes so far
<chromatic> The usual crashes?
<tetragon> t/compilers/imcc/syn/macro 32
<tetragon> t/op/interp 3
<tetragon> t/pmc/io 1
<chromatic> Are those TODOs just popping up your SIGBUS window?
<tetragon> Are the three of the six I've hit so far
<tetragon> These ones are
<chromatic> That's a good sign.
<tetragon> The only non-TODO is the one I just hit, t/dynoplibs/myops.t, test 3 (which passes in spite of this)
<tetragon> (ticket #52222)
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<tetragon> Triangle still spins in the OpenGL example
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<chromatic> I'm tracking down a similar crash in one of the Rakudo tests.
% chromatic is now known as chromatic_away
% Zaba has joined #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<Infinoid> heh
<Infinoid> japhb: your example has become a tester's favorite :)
% AndyA has left AndyA!~andy@82.152.157.85
% AndyA has joined #parrot
% tetragon has left tetragon!~seneca@69-196-138-185.dsl.teksavvy.com
% Theory has joined #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% tetragon has joined #parrot
<japhb> Infinoid: :-)  And people discount the value of emotionally satisfying positive feedback ....
<japhb> Am I the only one whose eyes have completely glazed over by the Perl 6 type theory discussions?
<chromatic_away> No.
<nopaste> "chromatic" at 63.105.17.30 pasted "One More Stack Patch for tetragon" (148 lines) at http://nopaste.snit.ch/12773
<chromatic_away> This one works for me, tetragon.
<tetragon> chromatic_away: So the tests finished, and only the usual six crashes happened
<tetragon> This supercedes the previous?
<chromatic_away> Yes.
<chromatic_away> The previous gave me a crash in one of the Rakudo tests.
<tetragon> Of my usual six, the least reliable is t/stm/runtime.t 4.
<tetragon> It sometimes doesn't crash, and when it does, it isn't always the same thread
<Tene> make -j 2 works currently, or no?
<Tene> Guess i'll find out. :)
<chromatic_away> It should.
<tetragon> I haven't had any problems with -j2, beyond less readable console output during the build
<tetragon> Well, didn't crash during build
* Tene considers hacking in an explicit load of sdl and gl to rakudo.pir in a private branch.
% Psyche^ has joined #parrot
% Patterner has left Patterner!~Psyche@e177113126.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<Infinoid> I've been using -j8, just to front-load the I/O a little more
<Infinoid> works great.
<tetragon> chromatic_away: Works for me as well as the previous.  Neither hit any atypical crashes
<japhb> Tene: hmmm, what?
% Andy has left Andy!~Andy@64.81.227.163
<chromatic_away> Thanks, tetragon.  I've just committed r27144.
<dalek> r27144 | chromatic++ | trunk:
<dalek> : [src] The PMC struct and the Stack_Chunk_t struct aren't isomorphic enough on
<dalek> : non-x86 processors, so the stack chunk recycling scheme needs an explicit
<dalek> : reference count rather than re-using the first int slot in the PObj union.
<dalek> : This appears to fix RT #53170, reported by Seneca Cunningham.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27144
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% uniejo has joined #parrot
% UltraDM has joined #parrot
% chromatic_away has left chromatic_away!~chromatic@sub17-30.member.dsl-only.net