% iblechbot has joined #parrot
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
% Debolaz has joined #parrot
% AndyA has left AndyA!~andy@82.152.157.85
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% nopaste has left nopaste!~opaste@202-154-105-237.people.net.au
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-200-70.dynamic.mnet-online.de
% lichtkind has joined #parrot
% kj has joined #parrot
% lichtkind_ has joined #parrot
% Psyche^ has joined #parrot
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
% lichtkind has left lichtkind!~chatzilla@d83-189-55-18.cust.tele2.de
% Patterner has left Patterner!~Psyche@e177231181.adsl.alicedsl.de
% ilbot2 has left ilbot2!moritz@faui2k3.org
% lathos has left lathos!~simon@morison.arjam.net
% Psyche^ is now known as Patterner
% lichtkind_ is now known as lichtkind
% ilbot2 has joined #parrot
% lathos has joined #parrot
% AndyA has joined #parrot
% IllvilJa has joined #parrot
% ruoso has joined #parrot
% ask_ has joined #parrot
% davidfetter has joined #parrot
% ask_ has left ask_!~ask@pat-tdc.opera.com
% ask_ has joined #parrot
% ruoso has left ruoso!~ruoso@195.23.92.2
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
% ruoso has joined #parrot
% kid51 has joined #parrot
% kid51 has left kid51!~jkeen@pool-71-247-44-219.nycmny.east.verizon.net
% skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net
% moritz has joined #parrot
* Coke yawns
* Debolaz ponders yawning too
* moritz wonders why rakudo's List.reverse method is so weird
<moritz> my @a = ('foo'); say @a.reverse
<moritz> oof
% tetragon has left tetragon!~seneca@gw-312-705.somanetworks.com
<particle> stop yawning and get to work!@
<moritz> anyway, I added a test to the pugs test suite, so it will be caught at some point
* particle can look at it after rebuilding parrot
<particle> t/codingstd/perlcritic.......................Undefined subroutine &Perl::Critic::Policy::NamingConventions::ProhibitAmbiguousNames::default_forbidden_words called at t/codingstd/perlcritic.t line 141.
<particle> # Looks like your test died before it could output anything.
<particle> anyone know something about that?
% cognominal has left cognominal!~cognomina@82.67.232.89
<Coke> Yup.
<dalek> r26659 | particle++ | trunk:
<dalek> : [RELEASE] add some info to META.yml
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26659
<Coke> I updated that test recently to add that test.
<Coke> er, rephrase: to call that particular method.
<Coke> perhaps it was only added in a version so recent you do not have it?
<particle> a version of Perl::Critic?
<Coke> no, that particular policy.
<Coke> ... which may be bundled with P:C, sure.
<particle> perhaps. iunno how to test for that
<particle> ok
<particle> c:\usr\local\parrot\trunk>perl -MPerl::Critic -e"print $Perl::Critic::VERSION"
<particle> 1.080
<Coke> Worked for me before I committed it: Basically, I was telling it to prohibit everything it normally does, except to allow the name 'abstract' as a name.
<Debolaz> Is there a timeline for when parrot is expected to be production ready?
<particle> Debolaz: we're trying to reach 1.0 this year, but don't have all the dates mapped out to make that happen yet
<Coke> 1.031.03
<Coke> er, 1.03
<particle> let's require 1.03 then, and i'll upgrade
% dalek has left dalek!dalek@feather.perl6.nl
% dalek has joined #parrot
<Coke> is 1.03 > 1.080 ? freaky.
* diakopter sets the throttling to 1 bit/second.  hopefully botnix will interpret that as 1 message/second.
<Coke> m
<Coke> e
<Coke>  
<Coke> t
<Coke> o
<Coke> o
<diakopter> point taken, the variable name is 'bps', when it should be 'Bps'
* particle needs a perl module that can read an exchange (outlook) inbox
<particle> suggestions?
<purl> suggestions are welcome.
<diakopter> particle: see the FILE-FORMAT.htm file in this .zip: http://www.marklyon.org/gmail/readpst.zip
<diakopter> particle: did you mean read PST/OST files or access Exchange via MAPI
<particle> mapi, more likely.
% skids has joined #parrot
% pjcj has left pjcj!~pjcj@84-73-177-217.dclient.hispeed.ch
% gryphon has joined #parrot
<Coke> any cygwin users here?
<particle> i've heard of cygwin
<particle> got it installed. should probably update it to latest, and update parrot there
<Coke> I am now able to build parrot, but building all dies on one of the PIR files
<particle> like, parrot segfaults?
<Coke> ./parrot.exe -o runtime/parrot/library/PGE/P6Grammar.pbc runtime/parrot/library/
<Coke> PGE/P6Grammar.pir
<Coke> error:imcc:syntax error, unexpected $end in file 'runtime/parrot/library/PGE/P6Grammar.pir' line 373
<pmichaud> very odd
<Coke> hurm. i think this might be a result of using tortoisesvn vs. cygwin svn.
<pmichaud> that file is going away in a few minutes anyway :-)
<diakopter> tortoisesvn has a toggle for unix eol... 
<pmichaud> particle:  are you okay with eliminating languages/tap ?
<Coke> pmichaud: well, if you can make it go away, then I can have this fail on another file. That would be good. =-)
<particle> i wanna save the grammar, as it's close to correct
<particle> it can go in examples/pge
<pmichaud> particle will do
<pmichaud> excellent idea
* particle updates cygwin
* pmichaud updates in preparation for removing pgc, P6Grammar, P6Regex
<Coke> diakopter: where is that toggle?
* particle updates parrot on cygwin
<Coke> I get that error on a few files. If I set the eol-style on one of those files to 'unix' instead of 'native', it works.
% paco has joined #parrot
<Coke> ... but not all of them. (Crow.pir fails too.)
<diakopter> Coke: It's a system-wide toggle, unfortunately, I think.  I didn't know about the per-file one.  It's been a year or two since I used TortoiseSVN
<moritz> the per-file is stored on the svn, and not specific to toroisesvn
<diakopter> oh; there's a checkbox in the TortoiseSVN config window.  I dunno which tab/area.
<Coke> diakopter: If I go to tortoisesvn->settings-> ... I dont see line endings in any tabs except general -> subversion configuration file.
* Coke checks the svn-book
<diakopter> Infinoid: I think dalek always skips notification of the first new revision it sees after it awakens.
<diakopter> (r26659 in this case)
<Infinoid> yes.  that's because botnix doesn't call the shutdown() method when you kill it, so it doesn't save the previous value
<Infinoid> so it autodetects it, by finding the max() of the current rss contents.
<diakopter> ah.  I wonder how to gracefully shutdown botnix. :)
<diakopter> svc -d dalekbot  is what I've been doing
<Infinoid> I don't actually know.  I've been using SIGTERM, which wasn't so graceful
<tewk> particle, Coke: Latest GSoC Application submitted and published http://docs.google.com/Doc?id=dgbncnxx_9d2n6q2nq
<Infinoid> anyway, you can put an "} else { $newestrev-- }" near the bottom of process_rss() if you want it to output the newest rev on startup
<Infinoid> the way I did initially for debugging.
* particle wishes google supported diffs between submission versions
<Coke> if only they had some kind of document management system that allowed that...
<Infinoid> kdiff3 Works For Me, but its a lot of infrastructure
<Infinoid> oh, SoC submissions.  nevermind.
<particle> luckily, tewk uses google docs before submitting, so we can check it there
<particle> tewk++
<Coke> wow, TPF up to 20 submissions.
<particle> yeah, they just keep pouring in!
<particle> only 4 parrot and 1 perl 6, though
<Infinoid> diakopter: oh, better idea!  you can just write out the latest rev after every process_rss() run.  assuming botnix writes the file immediately, that should work perfectly
<particle> tewk: looks good to me
% Andy has joined #parrot
<dalek> r26660 | pmichaud++ | trunk:
<dalek> : Preparation for removing P6Regex from trunk (RT#48028):
<dalek> : * Remove outdated TAP.pg from examples/pge/
<dalek> : * Preserve languages/tap/src/TAP_grammar.pg in examples/pge
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26660
<dalek> r26661 | pmichaud++ | trunk:
<dalek> : [tap]:
<dalek> : * Remove languages/tap from trunk, can be rebuilt using new language tools.
<dalek> : * Grammar is preserved in examples/pge/grammars/ .
<dalek> : * Changed status of tap in LANGUAGES_STATUS.pod.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26661
<dalek> r26662 | pmichaud++ | trunk:
<dalek> : [tap]:
<dalek> : * Remove tap from Parrot configuration scripts.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26662
* Coke is surprised that nothing exploded after his immc change. whee!
<particle> using my cygwin build script, parrot build successfully
<particle> #!/bin/sh -x
<particle> PATH=$PATH:`pwd`/blib/lib
<particle> export PATH
<particle> perl Configure.pl
<particle> make
<purl> i heard #!/bin/sh -x was the same as running 'set -x' as the first command, if that helps
% cognominal has joined #parrot
% cognominal has left cognominal!~cognomina@82.67.232.89
<particle> make test fails miserably, though
<Coke> particle: what is your default text file type?
% skids has left skids!bri@charon.clarku.edu
% sjansen has joined #parrot
% skids has joined #parrot
<particle> probably unix. how do i tell you?
<Coke> run cygwin setup and see what it defaults to?
<particle> Unix / binary (RECOMMENDED)
<Coke> hurm.
<Coke> what subversion client did you use? tortoisesvn?
<Coke> or cygwins?
<Coke> (or some other way of grabbing source.)
<particle> cygwin's svn package and 'svn up'
<particle> iirc using windows svn with cygwin is broken
* Coke tries to config this properly...
% rdice has joined #parrot
% Theory has joined #parrot
<Coke> particle: (*@#&$@#(*&$
<Coke> yah. avoiding tortoisesvn, it builds fine.
<Coke> I will add tha to the readme before I close the ticket.
<Tene> Argh!
<Tene> I don't trust my normal laptop anymore, so I borrowed my girl's for this week, and it suddenly won't power on at all.
<Coke> tene: don't ever touch my pacemaker.
<Coke> not that I have one yet.
<dalek> r26663 | coke++ | trunk:
<dalek> : [docs]
<dalek> : Cygwin does, in fact, build, if you follow these steps.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26663
<Coke> particle: I only have 4 failures. nothing major.
% pjcj has joined #parrot
<dalek> r26664 | pmichaud++ | trunk:
<dalek> : [pge]:
<dalek> : * Remove deprecated P6Regex, P6Grammar, and pgc.pir from trunk.
<dalek> : * Resolves RT#48028 and RT#48026.
<dalek> : * Updated NEWS, DEPRECATED.pod
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26664
<Coke> pmichaud++
<Tene> My treo is just a bit too weak to consider compiling parrot on.
* Coke waits for chromatic to figure out how much lighter parrot is.
<dalek> r26665 | pmichaud++ | trunk:
<dalek> : [pge]:
<dalek> : * Missed a P6Regex --> Perl6Regex conversion in pgegrep.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26665
<pmichaud> looks like we might need a "svn:ignore" for src/exec_dep.c ?  Is that a new file?
<pmichaud> anyway, time for me to reward myself with lunch :-)
<Coke> odd. is that a generated file? the comments don't seem to think so.
<pmichaud> it just showed up.  realclean doesn't remove it
<pmichaud> I'll remove it manually and rebuild... one moment
<Coke> /usr/bin/perl.exe -MExtUtils::Command -e cp src/jit/i386/exec_dep.c src/exec_dep.c
<Coke> do we really want to be doing a copy?
<particle> yes
<particle> we really want a copy
% iblechbot has joined #parrot
<particle> it's part of the jit system, which gets copied depending on your platfrom
<particle> unless you're proposing to generate those files during configure?
% kj has joined #parrot
% barney has joined #parrot
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% cognominal has joined #parrot
% IllvilJa has joined #parrot
% davidfetter has joined #parrot
% Psyche^ has joined #parrot
% jq has left jq!~jquelin@merlin.mongueurs.net
% jq has joined #parrot
% Patterner has left Patterner!~Psyche@e177231181.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<dalek> r26666 | bernhard++ | trunk:
<dalek> : Update copyright years.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26666
% jjore is now known as zz_jjore
% zz_jjore is now known as jjore
* particle notes the horrible inefficiencies in t/steps/*.t and sighs
<particle> holy code duplication!
% cotto_work has joined #parrot
<Infinoid> particle: and you're cleaning that up, right? :)
<Coke> particle: (copy) uh, why not just link in the one we care about?
<dalek> r26667 | bernhard++ | trunk:
<dalek> : Make t/codingstd/c_parens.t happy.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26667
<dalek> r26668 | bernhard++ | trunk:
<dalek> : [HQ9+]
<dalek> : Use the stringified Match object for implementing 'quine'.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26668
<particle> links don't work on all platforms
% peeps[work] has joined #parrot
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
<Coke> no, just build the file we want and link in the resulting .o; not a symlink.
<Coke> (or hard link, or anything)
<pmichaud> http://www.pmichaud.com/sandbox/commits.gif
<pmichaud> trend line is trend of commits Nov 2006-Oct 2007
<pmichaud> red is commits Nov 2007 to present
<particle> is that based on the data from the tool i wrote?
<pmichaud> no, it's from the svn commit logs
<particle> tools/util/gen_release_info.pl - generate release info for graphs and charts
% davidfetter has joined #parrot
* Coke wonders if he can make another google doc with widgets that does something similar.
<pmichaud> I did this chart in openoffice calc, was pretty easy once I knew what I was doing :-)
% peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com
<particle> my script takes the revision of the release tag
<particle> so it's commits between releases as opposed to some arbitrary date
<cotto_work> Infinoid, I can occasionally get make -j to fail.
<cotto_work> ./src/pmc/role.pmc:52:27: error: pmc_namespace.h: No such file or directory
<cotto_work> That looks like the offending line
<cotto_work> I can nopaste more output if you're interested
<Coke> aha. I can fix that.
<pmichaud> I wanted to use first-of-each-month so I could get reasonable labels on the x-axis
<pmichaud> I could probably do that with release date as well
<pmichaud> (i.e., show the release dates on the x-axis)
<Infinoid> cotto_work: how many jobs are you running with?
<cotto_work> as many as make feels like spawning
<particle> if you can show the release dates on a constant time scale, that's better
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
<cotto_work> I'm running make -j
<particle> *consistent
<Infinoid> ah.  I don't feel like putting my laptop in swap hell, so I've limited myself to -j10
<Coke> cotto_work: do me a favor, submit a ticket: do to that right is going to involve a programmatic change, not just declaring a dependency.
<cotto_work> np
<particle> doesn't -j default to #procs+1?
<cotto_work> If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously.
<Coke> basically, pmc/role.c is depending only pmc/role.pmc, when it should also depend on any .h's, *especially* the ones that are generated.
<cotto_work> (from the man page)
<pmichaud> yes, I can get the release dates on a consistent time scale
<Infinoid> no, given a sufficiently parallizable Makefile it defaults to "all your RAM are belong to us"
<Infinoid> I'm getting a failure in t/compilers/imcc/syn/regressions.t
<particle> ah. well 6G must be enough ram that i never run into problems.
<Coke> Infinoid: I just touched that file. which one, #2?
<Infinoid> yes
<Infinoid> #1 segfaults, but is marked as TODO
<Infinoid> #2 wants the nonexistent 'div_i_ic_ic' op
<dalek> r26669 | bernhard++ | trunk:
<dalek> : [HQ9+]
<dalek> : Implement '+' with 'postfix:++'
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26669
<Coke> DOH.
<Coke> checking.
<purl> somebody said checking. was that necessary? I'm accessing it via http://localhost/~jkeroes/cgi-bin/test.cgi
<Infinoid> purl, forget checking
<purl> Infinoid, I didn't have anything matching checking
<Infinoid> purl, forget checking.
<purl> Infinoid, I didn't have anything matching checking
<Infinoid> cotto_work: is it consistent at all?  or 1 chance in 10, or...?
<cotto_work> I'd guess it fails ~20% of the time
* Infinoid runs 100 builds in a for loop
<Coke> Infinoid: the failure makes sense.
<Coke> that dependency is not listed.
<Coke> if you do a make realclean, then try to make src/pmc/role.c, it should fail.
<Infinoid> s/c$/o/
<Coke> er, right.
<Infinoid> Coke++
<Coke> the thing that generates the deps list in the makefile for pmcs needs to take the includes into a ccount.
<Coke> Infinoid: I cannot duplicate that error on feather (regressions.t)
<Infinoid> do we do a deps pass at Configure.pl time?
<Coke> doing a realclean and trying again...
<Coke> Infinoid: for pmcs, yes.
<Infinoid> maybe I'm putting this stuff in the wrong place, then
<Infinoid> Coke: I just rebuilt (with -j1) and reproduced t/compilers/imcc/syn/regressions.t in r26668.
<Infinoid> my only local modification is some explicit deps for role.pmc
<Infinoid> nopaste seems to be down
% ask_ has left ask_!~ask@pat-tdc.opera.com
<Coke> Infinoid: what os?
<Infinoid> Linux x86-64
<Infinoid> http://pastebin.com/d82c35a1
<Coke> It makes sense, it's the same kind of thing I was skipping. those opcodes don't exist, presumably because we optimized them all away.
<Infinoid> I didn't pass any arguments to Configure.pl.  should I?
<Coke> for which now?
<Infinoid> for the failure in test 2 of t/compilers/imcc/syn/regressions.t
<Coke> no. I think my solution to the const folding is flawed. :|
<Infinoid> is parrot's optimization non-portable somehow?
<Infinoid> its odd that I'd see an issue when you aren't.
<Coke> yah, that's odd. but now that you're seeing it, I think I should be seeing it. :|
* Infinoid tries a couple other boxes to see how specific to his laptop it is
* Coke does a realclean to be sure.
<Coke> wiiiierd.
<Coke> jit?
<purl> rumour has it jit is a Just In Time compiler.  Or just more Java hype. or new Parrot hype
<Infinoid> I didn't think x86-64 had jit
<Coke> maybe that's the issue. =-)
* Infinoid is jit-clueless
<Coke> do me a favor and reopen the ticket I closed. :|
<Infinoid> hold on, trying on a couple of x86-32 boxes with nearly identical software setups
<Infinoid> is there a --without-jit or the like?
<Infinoid> passes on x86-32 default config
<Coke> or you could TODO the test on that one platform and put the ticket number into the todo. =-)
<Infinoid> if you don't think it'll show up anywhere else, I can do that
<Infinoid> if I back out r26657, the test still fails, but with a different error and a TODO tag.  so that wasn't as insightful as I had hoped :)
<Infinoid> is x86-64 the only supported platform missing jit?  can I somehow test for jit-ness, instead of making a list of broken platforms?
<Coke> Infinoid: note that the test changed slightly.
<pmichaud> I have a patch to add shift/unshift/push/pop/elems methods to RPA.  Should I commit it directly, or submit it to RT for review/discussion?
<particle> commit, then comment on list
<pmichaud> sounds good to me.
<Coke> i would say post the patch, but I think c already gave it a +1.
<pmichaud> he did
<Coke> I am inclined to vote against, but not strongly.
% peeps[work] has joined #parrot
<Infinoid> +0.33333333
<purl> 0.33333333
% grim_fandango has joined #parrot
<pmichaud> okay, I'll apply and comment.
<Infinoid> hmm.  amd64 does have a --jitcapable flag I'm supposed to pass, which supposedly turns jit on for me.  it has no effect on the test.
<Coke> k. was a wild stab.
<dalek> r26670 | pmichaud++ | trunk:
<dalek> : * Add shift, unshift, push, pop, and elems methods to ResizablePMCArray.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26670
% particle has left particle!~particle@c-24-19-3-148.hsd1.wa.comcast.net
<Infinoid> Coke: #43048 reopened, sorry :)
<Coke> sokay
% paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net
% paco_ has joined #parrot
% paco_ is now known as paco
% ruoso has left ruoso!~ruoso@195.23.92.2
% particle has joined #parrot
% particle has left particle!~particle@c-24-19-3-148.hsd1.mn.comcast.net
% particle has joined #parrot
% lichtkind has left lichtkind!~chatzilla@d83-189-55-18.cust.tele2.de
<Coke> Infinoid: what does $I0 = 0; $II = 1/ $I0 generate on your machine?
<Coke> (that should avoid the bad opcode but generate the div by zero error.)
<Infinoid> $II or $I1?
<Infinoid> error:imcc:'$II' is not a valid register name
<Infinoid> Divide by zero
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% Theory has joined #parrot
% barney has left barney!~bernhard@dslb-084-058-152-143.pools.arcor-ip.net
<dalek> r26671 | pmichaud++ | trunk:
<dalek> : * Fix coding standards oops noted by chromatic++ .
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26671
<Coke> weird.
<Infinoid> so yeah, that fixes the test for me
<tewk> There should be a syntax to expose a vtable call as a METHOD in pmcs.
<tewk> ie shift unshift etc
<pmichaud> that would be cool
<pmichaud> we already have a way in PIR of designating a method as a vtable entry
<tewk> It shouldn't be that hard, codegen like that is really what pmc2c.pl is for
<tewk> We should take the same sort of syntax as pir :method(method_export_name) or something
<particle> VTABLE METHOD get_bool
<particle> that'd be my vote
<pmichaud> no, we need a way to specify the method name
<pmichaud> i.e., I want 'shift', not 'shift_pmc'
<pmichaud> also, the METHODs need to conform to PCC
<particle> VTABLE METHOD("true") get_bool(...)
<pmichaud> (including autoboxing)
<pmichaud> so perhaps we really need the opposite
<pmichaud> METHOD VTABLE('get_bool') true(...)
<pmichaud> that would match imcc :-)
<particle> works for me, modulo the c syntax nit
<pmichaud> actually, now that I think of it, VTABLE METHOD("foo")   might make more sense
<pmichaud> creates a vtable entry and a corresponding wrapper method
<tewk> right
<pmichaud> ah well, I'll let you pmc2c.pl magicians handle it :-)
<particle> how do i get the length of a match inside a p5 regex?
<particle> $_ = 'foo: some variable-length text'; s/foo: (.*)/X*<length of $1>/
<pmichaud> probably use the /e flag
<Tene> particle: (?{ ... })
<Tene> or, yeah, /e
<particle> ah, right
<Coke> anyone know of an OS DRY-detector that works on something other than java? (CPD says you can just give it a file extension, but it fails to work.)
<Tene> oh, (?{}) might not be right...
<Coke> (or do I need to write one.)
% Ademan has left Ademan!~dan@h-68-164-168-66.snfccasy.dynamic.covad.net
% Ademan has joined #parrot
<Infinoid> DRY?
<purl> i heard DRY was Don't Repeat Yourself
<pmichaud> particle:  on gen_release_info.pl, might it make more sense to simply have a file that gets updated as part of release steps, rather than re-querying the svn repo? 
<particle> sure, that could work, too
<Coke> I have a project at work where this would be extremely useful. But I can see it being helpful for parrot too. =-)
<Coke> pmichaud: does that imply storing that data in the repo?
<pmichaud> yes
<Coke> -1: the data is already IN the repo.
<pmichaud> in an easily parseable form?
<particle> it's metadata
<pmichaud> we could fix up the ChangeLog to provide what we're looking for
<pmichaud> we already have date + committer lines there -- we would just need release number and revision number
<pmichaud> (release number is there too, but not as easy to get to at the moment)
<pmichaud> changelog entries could be    2008.03.18   bernhard   0.6.0    r26142
* pmichaud notices that he forgot to update ChangeLog as part of the 0.5.3.  Bad pmichaud, no cookie.
<particle> extracting from the repo avoids human errors like yours
<pmichaud> we'd be more likely to notice the human error :-)
<pmichaud> anyway, it was just a thought.  I suppose bandwidth and electrons are cheap :-)
% skids has left skids!bri@charon.clarku.edu
% skids has joined #parrot
% skids has left skids!bri@charon.clarku.edu
% skids has joined #parrot
<dalek> r26672 | pmichaud++ | trunk:
<dalek> : * Forgot to update the ChangeLog when I did the 0.5.3 release (pmichaud--).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26672
<pmichaud> particle: ping
% lola22 has joined #parrot
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167933634.dsl.bell.ca
% lola22 has left lola22!~lola22@d033.dhcp212-198-248.noos.fr
% ruoso has joined #parrot
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-201-247.dynamic.mnet-online.de
* jonathan yawns
% Senaka has joined #parrot
<Senaka> hi Infinoid
<Senaka> where can I find info on how to submit a patch to a bug?
% skids has left skids!bri@charon.clarku.edu
<pmichaud> for parrot?
<Senaka> yes
<pmichaud> http://svn.perl.org/parrot/trunk/docs/submissions.pod
<Senaka> thanks
<pmichaud> purl, submissions is http://svn.perl.org/parrot/trunk/docs/submissions.pod
<purl> OK, pmichaud.
% iblechbot has joined #parrot
<dalek> r26673 | jonathan++ | trunk:
<dalek> : [PCT] Generalize iterator code in for loop to use iter rather than to create an Iterator object. This means that objects that want to supply their own iterators can do so.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26673
<cotto_work> purl, submissions is also http://www.parrotcode.org/docs/submissions.html
<purl> okay, cotto_work.
<pmichaud> there's an iter opcode?
<Senaka> ARGIN is used for a const input variable right?
<dalek> r26674 | jonathan++ | trunk:
<dalek> : [rakudo] Make rand actually likely to generate a different sequence of numbers between runs.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26674
% cotto_work has left cotto_work!~cotto@tide502.microsoft.com
<pmichaud> jonathan: ping
% cotto_work has joined #parrot
<jonathan> pmichaud: pong
<jonathan> Yes, there is.
<pmichaud> re-seeding on each call to 'rand' is likely wrong
<dalek> r26675 | jonathan++ | trunk:
<dalek> : [rakudo] More work on IO. Now we can iterate over a file handle and $*IN, $*OUT and $*ERR are available.
<jonathan> Probably.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26675
<purl> Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look harder.
<dalek> r26676 | jonathan++ | trunk:
<dalek> : [rakudo] Bring STATUS document somewhat more up to date.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26676
<jonathan> I don't know what the right way to do it is, and I didn't really care much at the time, other than making my "guess the number" IO example program work. :-)
% ask_ has joined #parrot
<pmichaud> the problem with re-seeding based on time is that if rand is called multiple times quickly, it will always return the same number
<jonathan> Yeah, you're right.
<jonathan> My comment was entirely accurate. ;-)
<pmichaud> normally we seed once at the beginning of the process
<jonathan> Makes sense.
<jonathan> Can change it.
<pmichaud> I didn't know there was an iter opcode, that's cool.
<jonathan> Not sure the time is the right thing to seed it with.
<jonathan> Yeah, iter opcode calls the get_iter vtable method.
<pmichaud> yes, time has its own problems with seeding as well, but it's less wrong than re-seeding on every call :-)
% cotto_work has left cotto_work!~cotto@tide502.microsoft.com
<jonathan> Which is in turn less wrong, that not seeding at all and always getting the same number to guess in your guess the number game. :-)
<jonathan> Will post on rakudo.org :-)
% cotto_work has joined #parrot
* PerlJam hands jonathan a cup of entropy
* jonathan wishes it was a cup of beer
<PerlJam> I'd think you'd want a pint rather than a cup :)
<jonathan> A stein is even better, you can get a litre in one of those.
<jonathan> pmichaud: Hope the IO stuff looks vaguely OK.
<jonathan> It's at least part of an answer, to the discussion in the last conference call about the lack of it.
<Senaka> pmichaud: patch sent
<Senaka> thanks
<pmichaud> jonathan++  # great work
<Coke> This is a Python opcode. ## This should probably be removed then, neh?
<jonathan> Coke: Que opcode?
<jonathan> s/que/what/
<Coke> slice
% Senaka has left #parrot
<jonathan> Didn't know it existed.
<jonathan> pmichaud: You still planning to come to YAPC::EU?
<jonathan> Someone should talk about Rakudo progress there.
* Coke hopes to go this year.
<Coke> can be the backup if so.
<Coke> ->
<pmichaud> jonathan: I'm coming if it can be funded somehow
<jonathan> I'm happy to give it.
<pmichaud> (and perhaps even if it isn't)
<jonathan> But need to get submissions in before the deadline.
<pmichaud> deadline is in may, yes?
<jonathan> Yeah, sure, but I'm away on vacation when the deadline is, so just trying to be organized.
<jonathan> I intend to speak at YAPC::EU, it's just helpful to know if one of my talks will be the Rakudo one, so I know how much else I need to dream up.
<pmichaud> I think I can work my talk(s) around any that you want to give
<pmichaud> if you send me a copy of your submission, I'll try to be sure not to conflict :-)
% paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net
% rrando has left rrando!~jrt4@c-24-18-106-126.hsd1.mn.comcast.net
% AndyA has left AndyA!~andy@82.152.157.85
% paco has joined #parrot
<particle> pmichaud:  have you submitted anything for yapc::na?
<jonathan> I guess there should be a general "Rakudo Update" talk.
<pmichaud> particle:  yes
<particle> i'm thinking rakudo's 'main' is starting to look cluttered
% japhb has left japhb!~geoff@76-191-190-8.dsl.static.sonic.net
<jonathan> Which while I'm very happy to do, feels like I'm nabbing off with your talk.
<particle> i think the new io code should be in a 'create_std_io_handles' sub
<jonathan> Since you're the Rakudo dev lead.
% AndyA has joined #parrot
<jonathan> particle: Feel free to refactor.
<particle> pmichaud: same as oscon?
<pmichaud> particle:  I basically did the same as osc.... right
<particle> ok. we can split that, too, like oscon
<pmichaud> but I also sent additional comments
<particle> it's a good way to polish it up
<pmichaud> just a sec while I check
<pmichaud> jonathan: I'm more than happy to let others who are qualified do a "Rakudo Update" talk, unless the community really expects to hear it from me
<pmichaud> I can find plenty of other talks
<pmichaud> but I think that talks about the process of contributing to Rakudo could be even better
<pmichaud> for example, I _really_ enjoyed your .net on parrot talk last year at oscon
<pmichaud> I think a talk about junctions in Rakudo, or objects/classes, or any of those might be interesting
<pmichaud> particle:  here's the comment I added to my talk proposals
<pmichaud> At the conference I'm wanting to do 2 or 3 talks regarding Rakudo (the Parrot implementation of Perl 6) and the new Parrot Compiler Toolkit. I'm submitting potential abstracts here, but I can easily change my talks to other relevant topics if there are others proposing a topic similar to this one.
<pmichaud> so if others propose talks substantially the same as what I proposed, I'm willing to change my talks
<particle> ok. any timeline on the talks?
<particle> that might help josh et al with slot-picking
<jonathan> pmichaud: The European Perl Community have heard me talk a lot already from me about Perl 6 classes and roles - I've run that talk for a while...
<pmichaud> I think I did 45 mins for the Rakudo update and 70 mins for PCT
<jonathan> The difference now being that, a lot of what I showed in the talk is implemented.
<pmichaud> jonathan: good point, I forgot you already did those :-)
<jonathan> Junctions - yes, *but* only if they're implemented.
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<jonathan> Like, properly. By YAPC::EU. :-)
<pmichaud> oh, I was thinking of turning my attention to junctions again soon
<jonathan> And for that, we need the type hierarchy refactor, and type based MMD.
<jonathan> And that in turn I am pretty sure, means we need to start using .HLL.
<pmichaud> I don't think we need HLL for that.  The type-based MMD we have already isn't sufficient?
<particle> pmichaud: did you update the makefile template when you ripped out P6Regex?
<pmichaud> particle:  I think I did, yes.  I might've missed something.  You might need to re-configure :_)
<particle> that's what i'll try next
<particle> i have a broken build atm
<pmichaud> yes, several makefiles got updated
* teknomunk is away: Gone away for now.
% teknomunk is now known as teknomunk_afk
<pmichaud> jonathan: anyway, I'm flexible on talks.  In many ways I'd like to do the "State of Rakudo" talk (and it may be expected of me if I'm in attendance) but I'm also wanting to let as many other people as possible give talks
<jonathan> pmichaud: I'm trying to remember my reasoning; I did think through a chunk of this stuff.
% teknomunk_afk has left teknomunk_afk!~teknomunk@ubuntubob.residential.okstate.edu
<pmichaud> I'm being called for dinner .. bbl
<jonathan> ok
% rdice has joined #parrot
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
% jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se
% jan has joined #parrot
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
% paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net
% Limbic_Region has joined #parrot
% skids has joined #parrot
% kid51 has joined #parrot
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
% wknight8111 has joined #parrot
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-200-93.dynamic.mnet-online.de
% particle has left particle!~particle@c-24-19-3-148.hsd1.wa.comcast.net
% peepsalot has left peepsalot!~peeps@67.9.161.48
% peepsalot has joined #parrot
% tetragon has joined #parrot
% liona29 has joined #parrot
% liona29 has left liona29!~liona29@d033.dhcp212-198-248.noos.fr
% slightlyoff has joined #parrot
<dalek> r26677 | coke++ | trunk:
<dalek> : [build]
<dalek> : pmc's used to depend on PCCMETHOD generation module: now that PCCMETHOD is spelled
<dalek> : 'METHOD', update this so the makefile dep is properly generated again.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26677
% Sartak has left Sartak!~sartak@69.25.196.249
<Infinoid> before I forget to mention it, ewilhelm++ ewilhelm++ ewilhelm++ # for all the SoC cat-herding
<Coke> Infinoid: I am working on the pmc deps.
<Coke> just fixed another one that got broken during pdd17.
<Infinoid> Coke: are you having to add them by hand?  I was meaning to figure out if its possible to automate all that stuff
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
% peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com
<cotto_work> it looks like the explicit pmc_* includes in several of the PMCs are unnecessary
<cotto_work> the only necessary ones seem to be pmc_class in object.pmc and pmc_object in class.pmc
<Coke> http://pastebin.com/m65451335
<cotto_work> none of the others are needed for a successful build, and I'm confirming that make test is still happy
<Coke> Infinoid: there. nearly done.
<Coke> testing now on linux & windows.
% Sartak has joined #parrot
<Coke> whoops. moment...
<cotto_work> make test is happy
<Infinoid> hmm.  aren't they all "pmc_<something>.h"?
<cotto_work> (apart from some unrelated codingstd stuff)
<cotto_work> Infinoid, yes afaict
<Infinoid> the patch looks awesome, but I'm wondering if it will catch some extra headers you didn't want
<Infinoid> guess if it builds, that's proof that it didn't. :)
% ruoso has left ruoso!~ruoso@81.84.156.87
<Coke> why don't I want *all* the headers?
<Coke> the pmc's depend on parrot/parrot.h - if that isn't included...
<Coke> that patch is borked, btw. moment.
<Infinoid> Coke: depending on things in /usr/include/ is bad
<Coke> http://pastebin.com/d18e2f195
<Infinoid> (especially if you then prepend a "src/pmc/" to them)
<Coke> ok. moment.
<Infinoid> don't worry too much... if everything built, that means nothing depends on external headers, which is a good thing
<Coke> nothing does.
<Coke> but moment.
% Sartak has left Sartak!~sartak@69.25.196.249
% Sartak has joined #parrot
<Coke> one of these depends on a .str file.
<Coke> one of them includes ../src/io/io_private.h - where is that path relative from?
<Infinoid> relative to the location of the source file
<Infinoid> (or header file, whatever file contains the #include line)
<Coke> that's in one of the pmcs.
<Coke> src/pmc/../src/io/io_private.h isn't right. =-)
<Infinoid> yeah, that does look wrong
<Coke> but it must compile or we'd have seen it before, neh?
<Coke> oh. duh, it's relative to ./include
<Infinoid> is it split out by pmc2c?
<Infinoid> or just relying on the -Iinclude?
% darbelo has joined #parrot
<Coke> the latter
<purl> the latter is better
% rdice has joined #parrot
<Coke> http://pastebin.com/de49c558 has an updated patch that builds on linux.
<Coke> otto... I'm working on this right now.
<cotto_work> thanks
<Coke> oh, that's from 6 hours ago. =-)
% kid51 has left kid51!~jkeen@pool-70-107-19-158.ny325.east.verizon.net
<Coke> cotto_work: try that patch.
<Coke> that generates a proper dep line for src/pmc/role.o
<Coke> (testing on windows...)
<cotto_work> did you notice that most of those includes are unnecessary/redundant?
<Coke> nope! =-)
<Coke> checking.
<Coke> like what?
<Coke> include/parrot/parrot.h ?
<cotto_work> all the pmc_* includes except pmc_{object|class}.h in {class|object}.pmc
<cotto_work> parrot make and make test run fine if all the other includes are commented out
<cotto_work> s/parrot//
<Infinoid> cotto++
<Coke> just because it's a dep on a static file doesn't mean it's not a dep.
<Coke> I'm putting in *all* the missing deps that file has, regardless of whether it's a generated file or not.
<Coke> doesn't matter for joe-parrot-builder, but for a developer who is changing one of the included .h files, that's important.
<Infinoid> for build deps, sure, but isn't cotto talking about the #include lines themselves?
<Coke> that's SEP. =-)
<cotto_work> yes, I'm talking about the explicit #includes in the .pmc files
<Infinoid> ok.  but if it doesn't include the other file, it doesn't need a build dep either
<Coke> well, if those are removed, then the deps will vanish the next time someone builds the makefile. =-)
<Infinoid> ok :)
% particle has joined #parrot
<tetragon> Bleh, parrot stopped building
<Coke> recent revision? what os?
<tetragon> OS X 10.5.2, ppc
<tetragon> Current rev
<Coke> can you nopaste/pastebin the build error?
<tetragon> And I know the manual changes I have to do to the makefiles didn't kill the missing rule
<Coke> I did just change somethign that gens the makefile, so it's a likely culprit.
<Coke> which revision?
<Coke> (i mean, do you have a before and after?)
<Coke> particle: can you test something for me on windows? applying a patch is murder.
<particle> k
<tetragon> Just after, it built a couple days ago 
<Coke> http://pastebin.com/de49c558 
<tetragon> http://pastebin.com/m47e4d2b8
<Coke> tetragon: you shouldn't be compiling jit at all, methinks.
<tetragon> I'm not explicitly telling it to do that
<Limbic_Region> Coke - I have access to Win32/MinGW and Win32/Cygwin if testing all variations is required
<Coke> I figured, but I'm fairly certain jit is still borked on ppc, so I'm not sure why it's building.
<tetragon> Hrm... some of the darwin stuff is using deprecated functions
<Coke> Limbic_Region: Doubtful, but if you're feeling paranoid...
<Coke> tetragon: yup. open ticket on that somewhere.
<Coke> (patches welcome, in a not at all snarky way.)
<Limbic_Region> nope, just offering what little contribution I provide these days
<tetragon> I was preparing to see if I could convince this thing to build without requiring manual Makefile edits
* tetragon grumbles about Apple's /usr/bin/perl being built as a universal binary
<Coke> tetragon: you shouldn't need manual edits at all. :|
<Coke> ah, is that why?
<tetragon> Back when builds still worked for me, it would trip over i386 assembly
<Coke> probably a matter of smartening up the darwin hints file to pick one or the other and not both.
<cotto_work> Coke, I'm not seeing any build failures so far.
<tetragon> Apple's perl includes '-arch i386 -arch ppc' in its build flags, which causes parrot to try to build itself as universal
<particle> coke: realcleaned, applied patch, configured, building now
<Coke> particle: danke.
<particle> build succeeds. testing now
* particle bets the t/configure tests are as repetitive as the t/steps tests
<Coke> particle: if the build worked, it worked.
<particle> sure. commit it. i'm still gonna test it :)
<particle> course, i can't test nmake -j
<particle> that's not a valid option :(
<Infinoid> hmm, I should test -j on mingw sometime
<dalek> r26678 | chromatic++ | trunk:
<dalek> : [GC] Fixed build for --gc=libc (Senaka Fernando, RT #52332).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26678
* particle wonders when our svn revision will surpass our rt number
<tetragon> Coke: Some people would want both -arch flags
<Coke> tetragon: well, sure, if it built... but if it doesn't...
<tetragon> Coke: I haven't tested on my Intel yet...
<tetragon> Coke: I find universal builds tend to work there better than on ppc
<cotto_work> looks like the make race condition is gone
<cotto_work> as am I
<cotto_work> thanks for fixing that
<dalek> r26679 | coke++ | trunk:
<dalek> : [build]
<dalek> : Resolve #52316 ([BUG] undeclared dependency between role and namespace PMCs).
<dalek> : cotto++ for diagnosis.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26679
% slightlyoff has left slightlyoff!~slightlyo@204.14.154.209
* Coke goes to find the old open ticket about the darwin deprecation so he can merge the new bug with the old one...
<particle> # Trailing space or tab char found in the following files:
<particle> # C:\usr\local\parrot\trunk\config\auto\pmc.pm 131
* Coke grumbles.
* Coke can't find the old ticket he is sure that is a duplicate of. ah well.
<Tene> Coke: open a ticket about it.
<Coke> you funny. :p
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
<Tene> I certainly think so. :)
<tetragon> I found a build from a couple days ago.  It has jit built
<dalek> r26680 | coke++ | trunk:
<dalek> : [codingstd]
<dalek> : remove trailing whitespace introduced by myself and other villians.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26680
<Coke> tetragon: hokay.
<dalek> r26681 | coke++ | trunk:
<dalek> : [oops]
<dalek> : Undo accidental commit included in  r26680. Villians, indeed.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26681
* Coke wonders if anyone has thought about how we're going to do MMD without type ids.
% grim_fandango has joined #parrot
% arbingersys has joined #parrot
<wknight8111> what is MMD?
<purl> i think MMD is the media database...do not hurt
<wknight8111> thanks purl, you're a lifesaver
% arbingersys has left arbingersys!~jar@75-167-146-8.bois.qwest.net
<Infinoid> purl: no, MMD is multi-method dispatch
<purl> okay, Infinoid.
<wknight8111> Multi-method dispatch? looking that up now....
<wknight8111> haha, it's reassuring when the documentation says "Part or all of this document is outdated"
<Infinoid> if you have multiple methods of the same name, MMD is the process of finding out which one to call, based on the types of arguments you've passed
<wknight8111> oh. Suddenly I see what coke is worried about
<wknight8111> without explicit data types, matching prototypes is going to suck mad nutz
<Infinoid> type ids would help, indeed
<wknight8111> excuse my internet slang
<Infinoid> :)
<Infinoid> making MMD as easy (and foolproof) as possible would seem like a good thing, to me.
<Infinoid> purl, without explicit data types, matching prototypes?
<purl> well, without explicit data types, matching prototypes is going to suck mad nutz
<Infinoid> sorry, had to.
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% contingencyplan has joined #parrot
<dalek> r26682 | duff++ | trunk:
<dalek> : [config] git URL might not be https and it might not be of trunk
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26682
% grim_fandango_ has joined #parrot
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167933634.dsl.bell.ca
<dalek> r26683 | infinoid++ | trunk:
<dalek> : [raduko] minor change to pass t/codingstd/trailing_space.t
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26683
<Infinoid> Coke: should I check in your amd64 t/compilers/imcc/syn/regressions.t workaround?
* Infinoid doesn't want to paper over the fact that something is weird on amd64, but maybe the open ticket is enough.
% rdice has left rdice!~richarddi@CPE001217e365c7-CM00159a01d44c.cpe.net.cable.rogers.com
<wknight8111> what is weird about amd64?
<wknight8111> i guess i haven't read enough bug reports yet
<Infinoid> something is being optimized differently enough to break a test
<Infinoid> see the last post on http://rt.perl.org/rt3/Ticket/Display.html?id=43048
<Infinoid> I'm not too familiar with IMCC (thankfully), but apparently all situations where the "div_i_ic_ic" was to be useful are supposed to have been optimized away.  so it was considered fair game to remove the op.  which uncovered the fact that apparently it isn't being optimized away on amd64, though everything seems great on x86
<Infinoid> or something like that.
<wknight8111> that is weird that PIR would behave differently on the two platforms. 
<Infinoid> sounds like a bug, doesn't it?
% Ademan has left Ademan!~dan@h-68-164-168-66.snfccasy.dynamic.covad.net
% Ademan has joined #parrot
<wknight8111> maybe amd64 has some strange floating point bug, like a problem representing 0.0
<wknight8111> of course, it's rarely productive to assume that the error lies in the hardware
<Infinoid> hah.  well, this is an Intel chip, so I wouldn't put it past them
<wknight8111> i would like to see a hex dump of the floating point results out of the imcc parser, see if it's generating the proper values for 0.0
<Infinoid> I would have thought such a bug would have been discovered, advertized and worked around by now.
<Infinoid> but then again, very little of the stuff I do uses floating point at all.
<Infinoid> if you give me a command line I can run, I will run it
<Infinoid> (as I said, I'm IMCC-clueless)
<wknight8111> i wouldn't know how to do it either, i'm not big on imcc internals either
<Infinoid> ./parrot --target=imcc-parse-results-thingy
<wknight8111> and i dont have an amd64 laying around here, so i cant play with it
<Infinoid> that's odd.
<Infinoid> nopaste?
<purl> i guess 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
<Infinoid> http://rafb.net/p/w27OrL16.html
<Infinoid> apparently div_x_xc_xc is shorthand for a class of ops that includes div_i_ic_ic ?
<Infinoid> with -D I can see that parrot did attempt compile time constant folding, and got a real_exception (Divide by zero)
<Infinoid> so presumably it fell back on the runtime op
<Infinoid> and the same thing happened on x86, except for the runtime failure
<Infinoid> parrot's debugging flags aren't helping.  time for gdb...
<Infinoid> looks like gdb loves continuations almost as much as I do.
<Infinoid> ok.... here's where behavior starts to diverge
<Infinoid> compilers/imcc/parser_util.c line 648:         ins = IMCC_subst_constants_umix(interp, unit, name, r, n + 1);
<Infinoid> oops, try again
<Infinoid> compilers/imcc/parser_util.c line 653:         ins = IMCC_subst_constants(interp, unit, name, r, n + 1, &ok);
<Infinoid> both x86 and amd64 return NULL
<Infinoid> however, x86 sets &ok to 11, amd64 leaves it set to 0.
<Infinoid> I'm actually not sure whether that ok=11 thing was a stack smash, or somehow valid.
<Infinoid> longjmp--
% liona29 has joined #parrot
% davidfetter has joined #parrot
<tetragon> The make rule that my system is tripping over didn't exist a couple days ago
% liona29 has left liona29!~liona29@d033.dhcp212-198-248.noos.fr
<Infinoid> which rule?
<tetragon> $(SRC_DIR)/exec_dep.c
* Infinoid fixed some Makefile stuff for "make -j", and possibly broke some other stuff
<tetragon> It works in i386 since the file src/jit/i386/exec_dep.c exists, but there is no file by an equivalent name for ppc
<Infinoid> and jit is somehow being detected on your platform, despite being ppc?
<tetragon> There is a jit directory for ppc and it built on the weekend
<tetragon> Anyway, the build is proceeding smoothly with the new rule commented out 
<tetragon> And if an equivalent rule gets pumped out no matter which platform, I can already see that ARM'll break
<Infinoid> when in doubt, blame chromatic.  do you think it could have been r26636 ?
<Infinoid> that's where i386/exec_dep.c was created, and a corresponding ppc/exec_dep.c wasn't.
<Infinoid> and that's where the rule was added, too
<tetragon> Build didn't complete, fell over the missing object exec_dep.o
<Infinoid> http://www.parrotvm.org/svn/parrot/revision?rev=26636
<tetragon> Looks like chromatic can be blamed
<tetragon> That commit appears to fit the bill
<Infinoid> svn merge -r26636:26635 .
<Infinoid> if that fixes it, flame away :)
<Infinoid> (you'll need a realclean/reconfigure after that)
<tetragon> The majority of the commit looks to be moving exec_dep.h contents into exec_dep.c
* Infinoid looks at RT#47289
<Infinoid> aaw, I don't know that we can blame chromatic after all.  not fully, at least. :(
% petdance has joined #parrot
* Infinoid reopens it
* tetragon notes that her build is now at jit
<Infinoid> any luck?
<tetragon> I determined that I forgot to clean the tree sufficiently before that build
<tetragon> (Where that build is the one that had just reached jit)
<tetragon> At the very least, my -arch flag stripping is working
<tetragon> I don't have to edit every generated makefile in the tree to remove them
<tetragon> But I'm back at jit
<Infinoid> ok.  please post a followup to RT #47289 when you've finished your testing
<tetragon> It succeeded in building jit
<tetragon> Now I just have to wait the rest out
<Infinoid> I reopened that ticket and posted a description of the problem
% chromatic has joined #parrot
<chromatic> I think I can fix the JIT problem.
<Infinoid> great!
<chromatic> Which platform has the problem?
<Infinoid> ppc
<chromatic> Good.
<tetragon> There are others that do, but not encountered yet
<Infinoid> good luck with it, I'm outta here.
<Infinoid> thanks for the quick response, chromatic
% jrockway has left jrockway!~jrockway@dsl092-134-178.chi1.dsl.speakeasy.net
<chromatic> You're welcome.
<tetragon> With that merge, parrot built
% jrockway has joined #parrot
<chromatic> It looks like ARM will also have the problem.
<tetragon> The ARM I have laying around has neither Perl nor gcc on it
<chromatic> I know what the problem is there too, fortunately.
<chromatic> r26684 should work unmodified for you.
<tetragon> The appropriate .c files weren't created?
<dalek> r26684 | chromatic++ | trunk:
<dalek> : [JIT] Fixed the JIT build on PPC accidentally broken in r26636.  This also
<dalek> : finishes more of what RT #47289 tried to accomplish.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26684
<chromatic> Right.
<tetragon> I'll test in a few minutes, need to relocate my computer
% tetragon has left tetragon!~seneca@206-248-175-68.dsl.teksavvy.com
% grim_fandango_ has left grim_fandango_!~matt@bas2-kingston08-1167933634.dsl.bell.ca
<dalek> r26685 | chromatic++ | trunk:
<dalek> : [JIT] Fixed the JIT build on ARM accidentally broken in r26636.  This also
<dalek> : finishes more of what RT #47289 tried to accomplish.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26685
% TonyC has left TonyC!~tony@202-154-105-237.people.net.au
% tetragon has joined #parrot
<tetragon> chromatic: Build failed
<tetragon> Syntax error
<tetragon> http://pastebin.com/m4f813132
<tetragon> I'm taking a quick look at it
<chromatic> Me too.
<tetragon> Is it just me, or do both clauses of #if JIT_CGP in exec_dep.h have identical contents
<chromatic> What if you include "jit.h" in src/jit/ppc/exec_dep.h?
<chromatic> Good catch.
<tetragon> Same error, error message line numbers offset by one
<chromatic> How about also jit_emit.h?
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<tetragon> Same error, offset two
<chromatic> It doesn't understand Parrot_jit_info_t, but that's defined in jit.h.
<chromatic> Can you do 'make realclean; perl Configure.pl; make' again?
<chromatic> make -j <n> should be fine
<tetragon> Don't worry, this little ppc only has one cpu
<chromatic> Still goes faster this way.
<tetragon> On this box, the thing that recently sped it up the most was tweaking it to automatically strip out the -arch flags it got from Perl 5
<tetragon> Same error
<chromatic> Bizarre.
<purl> vous avez dit "bizarre" ?
<chromatic> oui
<chromatic> I'll have to pull out my PPC and try it then.
<ewilhelm> when did parallel make start working?
<tetragon> Grr... When I went from "make -j2" to a plain old "make" it decided to rebuild
<tetragon> (Not rebuild as in start working)
<chromatic> Infinoid and Coke made it work in the past couple of days.
<tetragon> Actually, I'm trying a change to the file that I think will fix it
<ewilhelm> sweet.  Infinoid++; Coke++
* ewilhelm mentions distcc
<chromatic> Yeah, if you want to have multiple machines running simultaneously.
<ewilhelm> heh, does it work on ppc?
<ewilhelm> you could get about 10 of those for $200 now or so right?
<chromatic> If you want to burn that much electricity yeah!
<tetragon> And i386 works?
<chromatic> Yes.
<ewilhelm> (hmm... put a cross-compiler on your real machine and use the ppc just for disk)
<chromatic> Scratch-that Computing indeed!
<tetragon> It works now
<tetragon> I stuck #include "parrot/parrot.h" into exec_dep.c
<tetragon> http://pastebin.com/m7bddf9d2
<chromatic> That's all it took?
<tetragon> Yes
<chromatic> Alright, I'll patch the other files.
<tetragon> Wait... linker failed
<tetragon> ld: duplicate symbol _ppc_flush_line in src/jit.o and src/exec_dep.o
<tetragon> The symbol is definitely in both, text section
<chromatic> It's in jit_emit.h
<tetragon> I'll remove that #include from exec_dep.h
<tetragon> Now the compile fails
<chromatic> Remove both includes from exec_dep.h and copy the #include block from src/jit/i386/exec_dep.c into src/jit/ppc/exec_dep.c
<chromatic> lines 18 - 22
<tetragon> compile succeeds
<tetragon> Looks like the link succeeded
<chromatic> Now the real test
<chromatic> TEST_PROG_ARGS=1 prove t/op/*.t
<chromatic> (provided you're using bash or a bash-workalike)
<tetragon> I'm on a Mac, I get bash by default
<tetragon> And I get a whole stack of failing tests
<chromatic> It was tcsh for a while.
<tetragon> They switched to bash a couple major releases ago
<chromatic> Er, I mean
<chromatic> TEST_PROG_ARGS=-j prove t/op/*.t
<tetragon> Not nearly as many failing tests
<chromatic> That's better.
<tetragon> I got one sigbus so far
<chromatic> Not too surprising.
<tetragon> Either in t/op/interp.t or t/op/jit.t
<tetragon> And one test unexpectedly succeeded
<chromatic> info.t?
<chromatic> debuginfo.t?
<tetragon> Need to run them individually
<tetragon> Neither
<tetragon> Wait, it was debuginfo
<chromatic> I'll apply these changes for PPC and ARM, and hopefully that'll solve the compilation problem everywhere.
<tetragon> And the sigbus was interp.t
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
<tetragon> And I got the same sigbus before these changes (and it's on a TODO test)
<chromatic> What's the TODO message?
<tetragon> not ok 3 - runinterp - works with printing # TODO something funky here
<chromatic> There's a forehead slapper.
<dalek> r26686 | chromatic++ | trunk:
<dalek> : [JIT] Really fixed JIT for PPC and ARM (thanks to Seneca Cunningham).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26686
<tetragon> I can put up the trace
<tetragon> http://pastebin.com/m6db3bd3f
<tetragon> And the prove -v output
<tetragon> http://pastebin.com/m7593b46e
<chromatic> The constant string is invalid for some reason.
<chromatic> ... probably not getting copied correctly from the parent interpreter.
<chromatic> ... due to some crazy system-dependent weirdness.
<chromatic> ... because it works on x86.
<tetragon> You're the one on the funky little-endian box
% TonyC has joined #parrot
<tetragon> Time to drop some coredumps
<chromatic> I fully admit that the x86 is a patch on a patch on a patch on the 4004, which is the best engineering the '60s had to offer (despite coming out in the '70s), but might I just add that cross-platform arch-independent JIT sucks?
<tetragon> I now have a coredump of the crash
<chromatic> I'm pretty sure I know where it is.
<chromatic> Do you mind filing these crashes as bugs?
<tetragon> Even the TODOs?  I think I currently have seven of them
<chromatic> If they succeed, bring them up here.
<chromatic> Otherwise they're groovy.
<tetragon> Most of the sigbus crashes are on TODO
<tetragon> I don't think there are any non-TODO ones left
<chromatic> That's probably good... but we should probably fix them at some point.
<chromatic> How about this.
<chromatic> If there aren't any RT numbers in the TODO descriptions, file them and I'll add the ticket numbers.
<chromatic> That way we'll *know* know they're there, instead of just thinking knowing.
<dalek> r26687 | chromatic++ | trunk:
<dalek> : [pobj] Removed a blatant lie from the STRING struct comments.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26687
% teknomunk has joined #parrot
% petdance has left petdance!~Andy@64.81.227.163
<tetragon> I'm outright failing t/compilers/imcc/syn/regressions.t
<tetragon> The non-TODO fails, and the TODO crashes
<chromatic> Coke made some recent changes there.
<tetragon> The TODO already has an RT number on it
<tetragon> Someone else had that one crash
<chromatic> Excellent.
<tetragon> That ticket doesn't have a stack trace, though
<tetragon> (41097)
<chromatic> Feel free to reply with one if you like.
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
% peepsalot has left peepsalot!~peeps@67.9.161.48
% iblechbot has joined #parrot