% iblechbot has joined #parrot
<dalek> r26853 | fperrad++ | trunk:
<dalek> : [docs]
<dalek> : since r26756, list_unjitted.pl moved in tools/dev
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26853
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% IllvilJa has joined #parrot
% Senaka has joined #parrot
<Senaka> purl: seen infinoid
<purl> infinoid was last seen on #parrot 4 hours and 44 minutes ago, saying: which one was failing? 
<Senaka> hi all... when is the #parrot-sketch meeting? in GMT?
% cosimo_ has joined #parrot
% cosimo_ has left cosimo_!~cosimo@pat-tdc.opera.com
% cosimo has joined #parrot
<Senaka> ok got it
<Senaka> purl: parrotsketch
<purl> i think parrotsketch is 18:30 UTC, Tuesdays or a weekly status meeting for parrot design team
% ruoso has joined #parrot
% Debolaz_ has joined #parrot
% particle has left particle!~particle@c-24-19-3-148.hsd1.wa.comcast.net
% Maddingu1 has joined #parrot
% skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net
% Khisanth has left Khisanth!~Khisanth@pool-68-237-111-126.ny325.east.verizon.net
% Maddingue has left Maddingue!~Maddingue@profane.mongueurs.net
% Debolaz has left Debolaz!~root@nat.andersberle.com
% skids has joined #parrot
% Maddingu1 is now known as Maddingue
% particle has joined #parrot
% ruz has left ruz!~cubic@85.112.113.222
% ruz has joined #parrot
% Khisanth has joined #parrot
% AndyA has joined #parrot
% tetragon has joined #parrot
% skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net
% skids has joined #parrot
% Senaka has left Senaka!~senaka@124.43.208.245
% ambs has joined #parrot
<rotty> how do the lib/Parrot/Test/<Language.pm> files relate to the test harness?
% AndyA_ has joined #parrot
% AndyA has left AndyA!~andy@mail.detnorsketeatret.no
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-197-227.dynamic.mnet-online.de
% tetragon has left tetragon!~seneca@CPE0040d001f62f-CM000a736592a8.cpe.net.cable.rogers.com
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
% AndyA has joined #parrot
% AndyA_ has left AndyA_!~andy@mail.detnorsketeatret.no
% paco has joined #parrot
% AndyA_ has joined #parrot
% AndyA has left AndyA!~andy@mail.detnorsketeatret.no
% Daveman has joined #parrot
% Ademan_ has joined #parrot
% iblechbot has joined #parrot
% Dave has left Dave!~dave@pool-141-150-77-248.mad.east.verizon.net
% Ademan has left Ademan!~dan@h-68-164-168-66.snfccasy.dynamic.covad.net
% skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net
% ambs has joined #parrot
<rotty> seen barney?
<purl> barney was last seen on #parrot 15 hours and 22 minutes ago, saying: calling it a day, looking forward to rotty's patches 
<ambs> seen merlyn?
<purl> merlyn was last seen on #moose 18 days and 14 hours ago, saying: ... http://methodsandmessages.vox.com/library/post/the-year-of-smalltalk.html  [Mar 20 15:09:20 2008]
<ambs> :-S
% iblechbot has left iblechbot!~iblechbot@241.18-dial.augustakom.net
% Daveman has left Daveman!~dave@pool-141-153-233-27.mad.east.verizon.net
% AndyA_ has left AndyA_!~andy@mail.detnorsketeatret.no
% Daveman has joined #parrot
% kj has joined #parrot
<dalek> r26854 | fperrad++ | trunk:
<dalek> : [Lua]
<dalek> : - fix table.sort()
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26854
% wknight8111 has joined #parrot
% skids has joined #parrot
<wknight8111> anybody else try to build this morning on r26854?
<pmichaud> I was just about to do so :-)
<pmichaud> takes about 2 min
* ambs svnups
<pmichaud> seems to work fine here
<pmichaud> at least, I was able to build okay
<paco> making
<ambs> builds ok
<diakopter> I just smoked r26843 on several platforms
<diakopter> oops r26853
<ambs> this is not smoking yet, but with the heat it should smoke soon O:-)
<wknight8111> I ran it just now on the latest, and make is complaining about a cyclic dependency
<pmichaud> wknight8111: what platform?  have you recently done a 'make realclean'?
<wknight8111> i did nmake realclean, configure, nmake. 
<wknight8111> #52596
<wknight8111> did it twice, actually. same result both times
<particle> nopaste?
<purl> i think nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://paste.husk.org/ or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or don't bother me while I'm eating
<nopaste> "ambs" at 77.54.92.255 pasted "Test Summary Report - Mac OS 10.5.2" (10 lines) at http://nopaste.snit.ch/12647
<ambs> 1 test failing
<paco> on linux  make smoke ok
<nopaste> "wknight8111" at 71.230.33.251 pasted "Build error on r26854" (56 lines) at http://nopaste.snit.ch/12648
<Coke> wknight8111: bah. that's my fault: gmake apparently says 'oh, that's a circular dep, I'll drop it.'
<Coke> hang on.
<purl> i guess hang on. is this from the command prompt, or from within the ide?
<wknight8111> okay, thanks
<rotty> why does the test harness execute this: [perl -le '... some code...'] ?
% Ademan_ has left Ademan_!~dan@h-68-164-168-66.snfccasy.dynamic.covad.net
% Theory has joined #parrot
% AndyA has joined #parrot
<Coke> wknight8111: is it possible to get nmake to *tell* us what the circular dep is?
% rdice has joined #parrot
% iblechbot has joined #parrot
<pmichaud> coke:   http://nopaste.snit.ch/12648
<pmichaud> says it's src\pmc\pmc_fixedintegeraray.h
<Coke> ... that tells us one node in the cycle. =-)
<pmichaud> ah
<Coke> wknight8111: can you try removing the dep of src/pmc/pmc_fixedintegerarray.h from src/pmc/pmc_fixedintegerarray.dump and rebuild?
<Coke> ah, I can at least get the error message with 'make src/pmc/fixedintegerarray.o'
<ambs> me too
<diakopter> Coke: in languages-smoke on linux, it was hanging up on tcl/t/cmd_expr.t for a very long time
% Ademan_ has joined #parrot
<Coke> diakopter: yes, it's slow.
<wknight8111> I dont think nmake can be more verbose, I'll check the options
<wknight8111> no, it doesnt have a more verbose error reporting mode
<Coke> wknight8111: fixed, I think.
<Coke> sadly, I had a patch very similar to that which i threw out yesterday because it didn't seem to be needed on my box. Thanks for the report.
<dalek> r26855 | coke++ | trunk:
<dalek> : [build]
<dalek> : Avoid circular dependency for fixedintegerarray: while it's used for METHODs,
<dalek> : we can't have it require it to be built before it's built.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26855
<wknight8111> let me try updating to that and see if it fixes my problem
<ambs> seems to build ok
* ambs makes real clean and tries from scratch
<Coke> you'd need a reconfig at least.
% AndyA_ has joined #parrot
% AndyA has left AndyA!~andy@mail.detnorsketeatret.no
<ambs> ccache++
<Coke> ... make -j ++ ++ ++ 
<ambs> Coke: does parrot compile with -j already?
<Coke> yes.
<Coke> if it doesn't, tell me.
<ambs> nice
<paco> I can compile with -j
<particle> can we config with -j ;)
<ambs> nice
<Coke> particle: we could if we switched our config to a makefile.
<Coke> config dep management.
<particle> P::FM could be used
<Infinoid> make -f Configure.mk -j
<Infinoid> make -j
<particle> but, really, || test is where we need to go
<Infinoid> make test -j
<nopaste> "particle" at 24.19.3.148 pasted "infinoid: that stack trace i promised you" (37 lines) at http://nopaste.snit.ch/12650
* particle has a mexican jumping interp
<particle> libparrot.dll!runops_slow_core(parrot_interp_t * interp=0x0000000000000000, ...
<particle> whee!
<cognominal> scary
<Infinoid> stack smash?
<particle> this is life with parrot on x86_64-msvc
<Infinoid> that almost looks like a buggy stack dumper.
<Infinoid> thanks for the paste
<particle> if i step through a program, i can watch the interp move around
<particle> it's not the dumper that's buggy
% AndyA_ has left AndyA_!~andy@mail.detnorsketeatret.no
% AndyA has joined #parrot
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
<wknight8111> yeah, build worked this time! Thanks Coke++
% AndyA has left AndyA!~andy@mail.detnorsketeatret.no
% AndyA has joined #parrot
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% contingencyplan has joined #parrot
% Debolaz_ is now known as Debolaz
% ask_ has left ask_!~ask@pat-tdc.opera.com
% ask_ has joined #parrot
% cognominal has left cognominal!~cognomina@82.67.232.89
% peeps[work] has joined #parrot
% cognominal has joined #parrot
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% grim_fandango has joined #parrot
% contingencyplan has joined #parrot
% TonyC has left TonyC!~tony@202-154-105-237.people.net.au
% nopaste has left nopaste!~opaste@202-154-105-237.people.net.au
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167929677.dsl.bell.ca
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% Theory has joined #parrot
<Coke> wknight8111: heh. break the build, fix teh build, get karma. =-)
<rotty> karma rotty?
<purl> rotty has neutral karma
<particle> rotty++
<particle> ...and it begins.
<rotty> karma rotty?
<purl> rotty has karma of 1
<rotty> :)
<rotty> thanks
<particle> karma particle
<purl> particle has karma of 1277
% nopaste has joined #parrot
* particle waits for 1337
<particle> karma coke
<purl> coke has karma of 1837
<particle> karma must be age-based :P
<purl> must be age-based :p has neutral karma
<particle> purl is so stupid.
<cotto_work> purl, purl?
<purl> i heard i was going alone. or almost an anagram of Donaudampfschiffahrtskapitaensmuetzenkordel or a perv or an auto-triage bot or a she or so stupid or a smartass or the sixth beatle. or http://www.infobot.org or dumb or a butt sniffer
% sjansen has joined #parrot
<wknight8111> purl is definitely a butt sniffer
<wknight8111> purl, purl?
<purl> i am going alone. or almost an anagram of Donaudampfschiffahrtskapitaensmuetzenkordel or a perv or an auto-triage bot or a she or so stupid or a smartass or the sixth beatle. or http://www.infobot.org or dumb or a butt sniffer
<wknight8111> it's the small things in life
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% contingencyplan has joined #parrot
% kj has joined #parrot
% kj has left #parrot
<particle> Tests=11110
<particle> yay! parrot has thirty tests now.
<Tene> hehe
<wknight8111> how often is the documentation on parrotcode.org updated to reflect the current file documentation?
<particle> every hour or so iirc
<particle> or maybe it's daily. coke would know
<wknight8111> oh, i didn't realize it was so frequent. I was under the impression that some of the files were a little out-of-date
% particl1 has joined #parrot
% particle has left particle!~particle@c-24-19-3-148.hsd1.mn.comcast.net
% particl1 is now known as particle
<particle> opbots, names
% Daveman is now known as Dave
% ambs has joined #parrot
<jonathan> particle: I can't make parrotsketch, will you be there? If so, I can paste you my report in /msg
<particle> paste it to #parrotsketch
<particle> it's logged, after all :)
<jonathan> oh, good idea ;-)
<jonathan> well, mention I left it there :)
<particle> sure
<jonathan> don't want to look like I'm slacking ;-)
<jonathan> ok, done
<jonathan> gotta go - dinner with $DAYJOB folks
<particle> ~~
* Infinoid gets back from the dentist with half his face numb 
<particle> ...as long as it's not the top half...
<pmichaud> I always noticed that major portions of my wallet were missing... :)
<Coke> docs on the website are cached for 24 hours usually.
* particle welcomes our viewers who have just returned from scrollbackland
* Coke fires up his UTC clock.
<pmichaud> 17:33 here
<Coke> hai.
<ambs> 18:33 here
<pmichaud> ambs, your UTC clock is an hour off :-)
<Coke> PS in about an hour, or your parrot is free.
<Coke> it's 18:33 in london. =-)
<ambs> Coke: and portugal
<purl> portugal is .pt
* Coke is guessing they just went to DST or something.
<ambs> yes
<pmichaud> 18:33 in london, yes.  but it's still 17:33 (now 17:34) UTC
<ambs> for one week or two. Can't remember
% ruoso has left ruoso!~ruoso@195.23.92.2
<Coke> ambs;OH. you meant here==where you are, not here==utc from your standpoint. =-)
<ambs> pmichaud: true
<pmichaud> utc is the same everywhere
<Coke> english is hard.
<Coke> wknight8111: don't respond to the autoreply, respond to the ticket. =-)
<wknight8111> man, I'm bad at this whole system
<wknight8111> I need to be banned from all this
<Coke> nbd. just that no one else has your original autoreply, so it shows as two threads now. =-)
<rotty> why does the test harness evaluate "perl -le "print join qq[\n], @INC" ?
<Infinoid> are you asking what it does?
<rotty> what it does and why it's there
<Infinoid> it's grabbing perl's module search-path
<avar> if it's screwing with your non-p5 harness_perl you might be interested in the hack I used in kp6 to get around that
<rotty> Infinoid: it does that even when the "exec" parameter to the harness is set to something different from perl, which will not work
<rotty> avar: kp6?
<purl> somebody said kp6 was mean as an infrastrucure to implement STD
<Infinoid> rotty: where?  having trouble grepping for that
<avar> kindaperl6
<rotty> avar: where is the kp6 code? it's neither under languages nor compilers...
<pmichaud> kp6 is in the pugs repo
<rotty> Infinoid: don't know, I also could not find the causing place...
<Infinoid> hmm.
<pmichaud> who (if anyone) is working on parrot's test harness at the moment?
<avar> I basically did exit 0 if "@ARGV" =~ /perl -le "print ... /
<avar> in the kp6 executable, there may be a better way around it
<Infinoid> rotty: oh, it looks like test harness boilerplate.  its in Test::Harness::Straps (that's /usr/lib/perl5/5.10.0/Test/Harness/Straps.pm on my system)
<Coke> kp6 is also "kinda perl 6"
<purl> okay, Coke.
<rotty> can someone fix the Parrot harness to not invoke that boilerplate if exec is not perl?
* rotty is a Perl noob
<Coke> how are you running the parrot harness if your exec is not perl?
<Infinoid> its a side effect of using the normal perl Test::Harness, which was written with perl in mind.  I'm not sure what's the best way to tackle that
* avar suggests his way of doing it:)
<avar> or write a shellscript wrapper around your program
<rotty> Coke: use Parrot::Test::Harness language => 'eclectus', exec => [ 'petite', '--script' ],
<Coke> ah.
<rotty> Infinoid: can't one somehow override that behaviour in Parrot::Test::Harness ?
<Infinoid> rotty: considering your command line is straight from the Parrot::Test::Harness SYNOPSIS, it would probably be a good idea to make it work *somehow* :)
<pmichaud> rotty:  what problem are you looking at/trying to address?
<pmichaud> (high level)
<rotty> pmichaud: running tests with an interpreter that is not perl
<pmichaud> rotty:  languages/perl6 does it
<pmichaud> as does languages/abc
<rotty> pmichaud: these use `compiler => ...', not `exec => ...'
<pmichaud> so, you need it to run tests with an interpreter that is neither perl nor parrot
<rotty> pmichaud: exactly
<pmichaud> and exec => doesn't work?
<rotty> pmichaud: it sorta does, but there is an spurious invocation of the interpreter with args only suited for Perl
<pmichaud> rotty:  okay.  I think I remember seeing a problem like that somewhere before.
<pmichaud> I'm of the opinion that we should re-do parrot's test harness from scratch
<particle> starting... now.
<pmichaud> I was going to ask questions about it during #ps today
<pmichaud> should we stick to Test::Harness, or move to TAP::Harness?
<Infinoid> if you're going to design a new one from scratch, please *please* design it with parallel execution in mind
<pmichaud> we still need Test::TAP::HTMLMatrix?  What dependencies do we have?
<Coke> ... isn't ewilhelm already on this?
<particle> ewilhelm or AndyA can tell us a bit about how TAP::Harness fairs on the platforms we care about
<Coke> we only need tth for our existing smoke setup, which we've already discussed dumping.
<particle> or whether they think it's ready to support our needs. i'm fairly certain the answer is "yes"
<pmichaud> Coke: perhaps, but my impression is that ewilhelm is more interested in helping someone else build the parrot harness as opposed to building it himself
<particle> the folks in oslo were working on the yaml diagnostics for tap
<particle> i don't know how long until we have a framework built around it that we can use for smoke
<pmichaud> well, my reason for wanting to support tth is so that we can get a public "here's what passes" display for rakudo
% kj has joined #parrot
<Infinoid> can we do that on the server side?
<Infinoid> one less dependency that way :)
<pmichaud> Infinoid: can we do... what? ... on the server side?
<Infinoid> the public "here's what passes" display
<pmichaud> so, the local make smoke passes the test results to a server which then formats it into html?
<pmichaud> in other words, we just need a tap => html tool or something?
<Infinoid> maybe I'm confused.  how does yaml tie into this?
<pmichaud> I don't understand that part either :-)
<Infinoid> if you guys want to support yaml, you can.  it can be converted to html later if needed
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
<particle> Infinoid: the tap infrastructure is destined to support yaml
<particle> so the output would be yaml already
<particle> then it's a matter of writing something that merges the yaml streams and converts to html
<pmichaud> does it need to be yaml?  why not just parse the tap output?
<Coke> "why not just use something that already exists". =-)
<pmichaud> coke:  what do we have that exists and works?
<Coke> smolder?
<purl> smolder is http://sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP).
% AndyA_ has joined #parrot
% AndyA has left AndyA!~andy@mail.detnorsketeatret.no
<pmichaud> smolder looks promising
% chromatic has joined #parrot
% AndyA_ has left AndyA_!~andy@mail.detnorsketeatret.no
<particle> smolder++
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-205-194.dynamic.mnet-online.de
<ambs> seen merlyn
<purl> merlyn was last seen on #moose 18 days and 20 hours ago, saying: ... http://methodsandmessages.vox.com/library/post/the-year-of-smalltalk.html  [Mar 20 15:09:20 2008]
<chromatic> #ps time
<particle> merlyn doesn't hang out gere
<particle> here
<rotty> Infinoid++
<ambs> particle: I know, but purl stands on #perl
<ambs> O:-)
<Infinoid> rotty: what did I do?
<rotty> you told me about Test::Harness::Straps :)
% Senaka has joined #parrot
% Senaka has left Senaka!~senaka@124.43.227.54
% Senaka has joined #parrot
% Senaka has left #parrot
% rdice_ has joined #parrot
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<dalek> r26856 | fperrad++ | trunk:
<dalek> : [Lua]
<dalek> : - fix random library
<dalek> : - add tests
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26856
<nopaste> "particle" at 24.19.3.148 pasted "sizes" (10 lines) at http://nopaste.snit.ch/12652
<mj41> smolder or my TapTinder .... http://mj41.cz/wiki/TapTinder :-)
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
<particle> hrmm... taptinder.
<nopaste> "chromatic" at 63.105.17.30 pasted "Does This Fix 64-bit Pointer Size Problems in UnManagedStruct?" (282 lines) at http://nopaste.snit.ch/12653
<Coke> chromatic++ # managing PS.
<chromatic> The src/mmd.c assertion checks for four-byte pointer alignment, I think.
<chromatic> I'm trying to decide if it has endian problems.  I don't think so.
<chromatic> I don't know a portable way to check if a pointer is properly aligned though.  I suspect the compiler won't let you make one that isn't.
<chromatic> (or it's a bad compiler)
<Coke> chromatic: you have a few tickets assigned to you that may be leftovers. Can you ditch anything that's assigned to you that you don't want?
<chromatic> ditch or fix?
<Coke> well, fix would be best, but if they're ones you're not going to get to them soon, ditching them is probably better.
<particle> Figuring out how to pack() Parrot's types...Configure.pl:  Unable to find an integer type that fits a pointer.
<Infinoid> particle: how is your perl built?
* particle tees his configure and make output for 64bit
<particle> Infinoid: it's activestate's 64bit build
<particle> i can get details. do you want -V ?
<Infinoid> no thanks, pack() should have something, we're just detecting it wrong
<nopaste> "particle" at 24.19.3.148 pasted "perl -V" (93 lines) at http://nopaste.snit.ch/12654
<particle> well, there it is anyway
<Infinoid> twist my arm a little harder. :)
<particle> nopaste.pl++
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net
% Theory has joined #parrot
<Infinoid> wait, what?
<purl> wait, is -L "follow link" or "gimme information about the link proper"...
<Infinoid>     intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
<Infinoid> your sizeof(long) isn't sizeof(void*)
<nopaste> "particle" at 24.19.3.148 pasted "configure output" (86 lines) at http://nopaste.snit.ch/12655
<particle> that's correct.
<chromatic> There's one problem then.
<particle> it's how the platform's designed. don't blame me
<particle> gotta love that long long isn't c89
<Infinoid> purl, forget wait,
<purl> Infinoid: I forgot wait,
<particle> so there's no way to fully support c89 on this platform
<spinclad> there's no uint64 or such?
<particle> http://msdn2.microsoft.com/en-us/library/aa384264(VS.85).aspx
<rotty> seen barney?
<purl> barney was last seen on #parrot 22 hours and 47 minutes ago, saying: calling it a day, looking forward to rotty's patches 
% ambs has joined #parrot
<Infinoid> weird that activestate 64bit is built with use64bitint=define, yet intsize and longsize are both 4
<particle> oh, god, no. trying to install parrot 0.4.12?
* Coke is replying.
<Coke> btw, someone forgot to update parrothist.pod
<Infinoid> particle: perl -e 'my $var = pack("q", 1); print(length($var), "\n")'
<Infinoid> does that print 8?
<Coke> ... or, I'm an idiot.
* Coke checks.
<Coke> idiot. check.
<Infinoid> t/codingstd/idiot.t..... ok (idiot detected)
<particle> Infinoid: 8
% Psyche^ has joined #parrot
% allison has joined #parrot
<Infinoid> ok, that's the packtype we need, now to get it detected properly
<particle> t/project/architect.t...ok (allison detected)
<confound> haha
<allison> hi particle
<allison> I was able to get my driver's license and vehicle registration changed, fingers crossed that the license will arrive in the mail before I leave the country next Wednesday
<particle> one step forward....
% Patterner has left Patterner!~Psyche@e177224219.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<Coke> what's the new VM for perl6? Chuck Norris. One punch and your code will run in half the time.
<allison> :)
<pmichaud> is that going to be the name of the next release?  ;-)
<pmichaud> s/the next/a future/
* Infinoid suggests "and boy are its arms tired"
<allison> 0.6.1 codename "Chuck Norris"
<cotto_work> shouldn't that name be saved for a more mature release?
<Infinoid> hah
<allison> 62.99.99
<ambs> lol
<chromatic> Re: pa-risc, I vote for removing the lines 1974-1976 in src/mmd.c
<allison> those were bad years anyway ;)
<ambs> lololol
* ambs wasn't around yet
<particle> that's why they were so bad
<pmichaud> (1974-76)  I agree.  I was quite pleased when the 80s finally rolled around
<chromatic> ITYM "Morning in America"
<chromatic> Oh hey, here's the problem.
<chromatic> include/parrot/parrot.h:142-153
<chromatic> If pointers and intvals are the same size, hooray!
<chromatic> Otherwise if pointers and longs are the same size, hooray!
<particle> egad.
<chromatic> Otherwise, pointers and unsigned ints are the same size!  They must be!  What else might they be?
<confound> heh
<Infinoid> I think win64 needs to use hugeintval here
<chromatic> I think something needs to use "IT'S NOT AN INT OKAY?" there.
<particle> why not check to see if INT64 is defined?
<pmichaud> argggh, I've been reading perl too long.  At first I thought all those lines were comments.  :-|
<ambs> lololol
<particle> let's set up a trigger to prevent pmichaud from committing c code
<Coke> sachmet?
<confound> Coke: not here
<nopaste> "Infinoid" at 96.238.213.50 pasted "particle: so... does "long long" work? (possible_win64_fix.diff)" (86 lines) at http://nopaste.snit.ch/12656
<Infinoid> particle: I'm looking at the "Figuring out how to pack() Parrot's types...Configure.pl:  Unable to find an integer type that fits a pointer." line from your Configure.pl output.
<Coke> confound: I was asking purl.
<confound> oh, sorry.
<Coke> np. =-)
<nopaste> "particle" at 24.19.3.148 pasted "configure output, post patch" (85 lines) at http://nopaste.snit.ch/12657
<Infinoid> you know, I'm not sure the "ptrconst" value probed for is ever actually used
<Infinoid> but I guess that fixed it.  thanks for testing, particle
<particle> i'm rebuilding now
<particle> lots of conversion and pointer truncation warnings still remain
<Infinoid> "ack -a" only reports the detection, testsuite, and generated config output.  ptrconst isn't ever used, that I can see
* Infinoid fixed something worthless!  o/
<particle> priceless.
<ambs> hehehe
<Coke> if it's never used can we rip it out now?
<nopaste> "chromatic" at 63.105.17.30 pasted "Avoid (Some) Pointer Cast Truncations" (15 lines) at http://nopaste.snit.ch/12658
<chromatic> Does this help, particle?
<Infinoid> Coke: might as well, and see what breaks.
<Coke> ... is there an easy way for me to get a list of every generated file in the repo?
<Infinoid> MANIFEST.generated ?
<purl> it has been said that MANIFEST.generated is wrong.
<Coke> ... hurm. svn st, mebbe.
<rotty> barney has commit acess right?
<chromatic> right
<Infinoid> svn st --no-ignore | cut -c 8-
<Infinoid> (that will also include local modifications.)
* rotty anticipates barneys review of his patches
* rotty notes that StGit rocks for managing a patch series
<particle> chromatic: perhaps some, but still src\ops\experimental.ops(51) : warning C4312: 'type cast' : conversion from 'opcode_t' to 'FLOATVAL *' of greater size
<particle> zillions of opcode_t and size_t warnings
* ambs makes test one more time, as he does not know enough about parrot atm.
<chromatic> opcode_t is Parrot_Opcode which is a typdef'd long for me.
<chromatic> Hm.
<chromatic> Maybe I need to fire up the 64-bit box in the other room and cajole it.
<Infinoid> and long is 4 bytes on win64
<nopaste> "particle" at 24.19.3.148 pasted "partial nmake output after patches" (1400 lines) at http://nopaste.snit.ch/12659
<Coke> Infinoid: I'm taking that list and running the same dependency checker that I used on the PMC .o files.
<Coke> hopefully this will rule out any non-race-condition based deps.
<wknight8111> is there a way in nqp to initialize an array at once? like @array := (1, 2, 3);?
<particle> wknight8111: no
<wknight8111> that's what I figured.
<wknight8111> thanks
<particle> no list context
<pmichaud> that might actually change a bit in a future pct revision
<pmichaud> i.e., @array := (1, 2, 3);  might work
<pmichaud> but not much else will -- i.e., hash initialization will still require individual elements
<wknight8111> I'm trying to write up a simple example of an octal-bin converter, as an intro to PGE. I'm using a lookup table for the conversion
<wknight8111> I was just hoping for an easy way to do it
<pmichaud> I tend to use strings for that sort of stuff. :-)
<particle> that's what i was thinking
<wknight8111> oh you're right. I could do that, couldn't I?
* wknight8111 isn't too bright
<particle> you'll fit right in.
<ambs> Files=565, Tests=11150, 333 wallclock secs (224.10 cusr + 49.19 csys = 273.29 CPU)
<ambs> :D
* Coke finds some missing deps. whee!
<particle> coke++
% ruoso has joined #parrot
* Coke will let this run and fix them later.
<wknight8111> is there a way to turn PAST off? I'm writing a little program that parses input, but doesnt form a tree or anything
<pmichaud> could just use --target=parse
<pmichaud> depends on what you mean by "turn PAST off", I guess.
<chromatic> Try to move in after the first date, for another option.
<wknight8111> well, I dont want to make any PAST nodes, but when I run the program I get the rror "Unable to obtain PAST from program::Grammar"
<pmichaud> the program is written in nqp?
<wknight8111> So i've been including an empty "make PAST::Stmts.new()" line
<wknight8111> yes
<pmichaud> did you try it with --target=parse?
<wknight8111> I'm trying to demonstrate PGE, so I have a grammar, and a little NQP that prints out if the input is valid or not
<wknight8111> --target==parse prints out the whole parse tree, which I dont want either
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
<particle> languages\perl6\src\utils\perl6doc\actions.pm
% AndyA has joined #parrot
% iblechbot has joined #parrot
<wknight8111> this is such a stupid little program. I'm going to forget about it for a while. thanks
<particle> wknight8111: the file i pointed you to will show you how to print from PAST
<particle> that's what perl6doc does now
<Coke> I am interested in consolidating Makefiles.
<Coke> (do we really need a separate Makefile for compilers/*, e.g.)
* particle thinks the root Makefile is way to long
<pmichaud> I find the separate makefiles easier to manage
* particle used to work on projects where every directory had a makefile
<Coke> you can have separate *input* makefiles, that's fine.
<pmichaud> do you mean to consolidate multiple *.in files into a single Makefile?
<Coke> yes.
<pmichaud> I don't like it -- too much potential for action-at-a-distance
<pmichaud> unless we have a really well defined set of macros and things that we know exist in the root makefile
<pmichaud> (and that other makefiles don't touch)
<particle> .include is your friend
<Infinoid> does nmake understand .include?
<particle> it has an include syntax.
<particle> !INCLUDE
<Coke> ... action at a distance??
<pmichaud> if I'm modifying pge.in, the rules I add coule affect other .in files in the master Makefile
<pmichaud> s/coule/could/
<Coke> the separate makefiles we have now prevent using -j on the various subdirectories, and prevent having an understanding of all the dependencies.
<Infinoid> I dislike having included Makefiles - wherever the included makefile is in a different directory, all the relative paths are wrong.
<rotty> what would be the advantage of compiling to NQP instead of PAST?
<Infinoid> however, I dislike having separate "make" invocations even more, because as Coke says, it breaks -j.
<Coke> Infinoid: we could fix that if we did the includes at compile time.
<Coke> er...
<Coke> at *configure* time.
<Coke> when we're already massaging the heck of the .in files.
<Infinoid> that works for me
<pmichaud> I'm not sure that having a single makefile means we understand all of the dependencies, but I'll pass on that
<pmichaud> personally, -j doesn't seem all that important to me
<pmichaud> but that doesn't mean it's unimportant to others, I guess
<pmichaud> rotty:  (compiling to NQP versus PAST)  -- I'm not sure I understand the question?
<particle> || test is more important than || make, becausue test takes way longer
<Infinoid> t/codingstd/linelengths.tap: t/codingstd/linelengths.t $(PARROT)
<Infinoid> it doesn't get much uglier than that. :)
* pmichaud misses the ugliness
<particle> times 623 is the ugliness, i think he means
<Infinoid> yeah, what I just proposed is horrid
<pmichaud> yes, I'd accept that as being ugly :-)
<pmichaud> .t.tap seems better :-)
* Infinoid looks forward to a rewritten harness
<particle> of course we won't use make to manage || test
<rotty> pmichaud: barney said the next step for eclectus would be to compile to NQP instead of PAST, and I'm not sure that this will be an advantage
<Infinoid> at least make wouldn't have blatant perly assumptions about the language of a test script
<particle> nqp instead of pir? or past?
<rotty> nqp instead of PAST
<pmichaud> rotty:  I agree -- but I would guess (and this is just a guess) that he meant to use NQP to create PAST instead of some other transformation
<rotty> pmichaud: no, as the compiler is implemented in Scheme ;)
<particle> yeah, that's what i think barney meant, too
<particle> barney likes playing with multiple back-end implementations
% Andy has left Andy!~AndyL@host3130.follett.com
<pmichaud> rotty:  then perhaps he means to use nqp instead of scheme
<pmichaud> rotty:  but you know his statement better than I do
<pmichaud> I'm not sure compiling to nqp would be better... but it might not be bad either
<rotty> pmichaud: I doubt that (switching to NQP), as (AFAIU) the eclectus language is about a compiler implemented in Scheme
<rotty> well, I'll ask barney when he turns up
<pmichaud> rotty:  yes, we'd have to ask barney then
<Coke> looking at the makefile for PGE... the rules for PGE.pbc seem overly complicated.
<pmichaud> first we remove any existing PGE.pbc
<Coke> ... why?
<pmichaud> because if a later step in the build fails, we don't want the old copy sitting around where someone thinks it passed
<Coke> if you have properly spec'd dependencies, make should handle all of this for you.
<Coke> no?
<purl> well, maybe.
<pmichaud> no.
<Coke> aside from "the build failed." which should be a pretty big clue. =-)
<pmichaud> except that it's all too easy to overlook
<pmichaud> I kept overlooking it, which is why I put the rm in there
<Coke> ok. why do you build PGE twice?
<Coke> and RM it twice?
<pmichaud> it's a staged library (more)
<pmichaud> the 'name' rule is written as a perl6 rule (from PGE/builtins.pg)
<pmichaud> so in order to compile it, we have to have a working copy of PGE
<Infinoid> miniPGE?
<pmichaud> so we build a copy of PGE with no builtins, then use that copy of PGE to compile the builtin rules, then recompile PGE with the builtin rules
% skids has left skids!bri@charon.clarku.edu
<Infinoid> we can serialize that nicely, if we can call the two versions different filenames
<Coke> ja.
<chromatic> You should port PGE to JavaScript, then use it to build itself with no rules, then use it to build itself with rules, and then use it to remove PGE.pbc.
<chromatic> I think a Perl 6 compiler magically falls out of there around step 7.
<pmichaud> except that the program that compiles the builtins (Perl6Grammar.pir) expects to load PGE.pbc
<pmichaud> so if we have a miniPGE, we also need a miniPerl6Grammar.pir
<Coke> we can tweak it to take a param.
<pmichaud> and this is all important.... why?
<chromatic> Is it worth it to take a param though?
<Coke> pmichaud: because we need someone other than you to be able to maintain the makefile. =-)
<pmichaud> I can add comments into the makefile
<Coke> that would be most helpful.
<pmichaud> but creating a separate minipge seems to me to be more maintenance hassle than what exists now
<Tene> pmichaud: can you write a makefile to add the comments for you?
<Coke> *thwap*
<pmichaud> and what exists now is fairly robust in that it doesn't leave partially-built pge.pbc files around that might get used
<Coke> neither would Infinoid's version.
<pmichaud> yes, it would
<pmichaud> at least it would on my system
<pmichaud> because   if building PGE.pbc fails, the makefile doesn't automatically remove $(PARROT_LIBRARY)/PGE.pbc
<Coke> not if you spec'd the dependencies properly and didnt' reuse the same name.
<Infinoid> when all else fails, output to PGE.pbc.tmp and rename it into place
<Tene> Oh!  We should differentiate based on case!  PGE.pbe and pge.pbc.
<Infinoid> Tene: yeah!  and you could have one letter per stage... so it looks like its inflating
<Infinoid> pge.pbc
<Infinoid> Pge.pbc
<Infinoid> PGe.pbc
<pmichaud> Makefiles don't automatically remove their targets if they fail to build
<Tene> Best idea ever.
<chromatic> Parrot writes out unfinished PBC files if they fail to build?
<chromatic> Or am I misunderstanding?
<pmichaud> parrot doesn't destroy existing pbc files
<Coke> I think pmichaud is targetting the case where you've already built once.
<pmichaud> which may have come from a previous build
<Infinoid> which is fine, unless something has changed, in which you should depend on something
* pmichaud points to the dependency in the rule above
<chromatic> Okay, I thought it might be that.
<pmichaud> I have a dependency in place for $(PARROT_LIBRARY)/PGE.pbc
<Coke> but if the build fails, it *fails*.
<pmichaud> but if one of the sources changes, I'm not guaranteed that PARROT_LIBRARY/PGE.pbc isn't the old version
<Coke> pmichaud: if the make succeeds, you should be.
<pmichaud> (if the make fails)
<Coke> then the make *fails*.
<Infinoid> and PGE.pbc's timestamp isn't bumped
<pmichaud> right but the old library is stilla round
<Tene> Coke: he said earlier that he kept failing to notice that the make failed.
<particle> have all depend on clean
<Infinoid> heh
<Infinoid> by the way, if pmichaud's caution is warranted, it's probably necessary for more than just PGE.pbc.
<pmichaud> this is only weird because we have two separate places for PGE.pbc to live
<Coke> which we shouldn't.
<Coke> (which is another issue.)
<pmichaud> so, you think PGE should be in runtime/parrot/library ?
<Infinoid> fixing one thing at a time sounds easier
<Coke> if that's where we're running it from, yes.
<Coke> what does the compile in compilers do?
<pmichaud> nqp and past also?
<Coke> er..
<Coke> the 'copy'
<purl> the 'copy' is, like, named 'clone'
<Coke> If these are core components of parrot, they should be in a core location.
<Coke> library seems reasonable to me, yes.
<pmichaud> tge?
<purl> i think tge is slooooow. or the tree grammar engine or how you transform a PGE Match Hierarchy into PIR code.
<Coke> anything in compilers, yes.
<pmichaud> imcc?
<purl> rumour has it imcc is the c of parrot or the problem or the intermediate code compiler
<Coke> does imcc have any generated PBC files?
<pmichaud> it's obviously core
<pmichaud> so it belongs in.... src?
<Coke> let me stop you from enumerating: "everything in compilers/ that generates a PBC should probably generate that PBC into the library."
<pmichaud> and their makefiles should be part of root.in?
<Coke> that's a separate issue, but yes, I think os.
<Coke> "so"
<pmichaud> what if PGE simply compiled direct to $(PARROT_LIBRARY)/PGE.pbc ?
<pmichaud> and didn't create the copy in compilers/pge/  ?
<Coke> I'm not entirely sure why it's not already doing that.
<Coke> +1
<purl> 1
* Coke smacks uprl.
<Coke> I am having definite transposition issues today. :(
<particle> uprl yours!
<chromatic> If PGE put its finished PBC in $(PARROT_LIBRARY), it could build the stage 1 PBC in the local directory and use that for the stage 2 build.
<chromatic> ... provided we can convince Parrot to prefer that PBC over the one in $(PARROT_LIBRARY).
<pmichaud> right
<chromatic> ... which eventually we should be able to do anyway.
<pmichaud> that's the issue I came up with
<particle> is there a reason to keep stage 1 around?
<particle> if stage 2 builds, remove stage 1
<pmichaud> as it is now stage 1 isn't kept around
<Infinoid> doing that keeps it less confusing
<Coke> it's an intermediate build file. we keep a lot of those around.
<Coke> (src/pmc/string.c)
<particle> no reason to keep those
<Infinoid> make might try to rebuild if it discovers the intermediate file isn't there
<particle> except for debugging
<particle> but .c is a text file
<pmichaud> correct, if the intermediate isn't present, make will rebuild the target
<particle> only if the source is newer than the target
* Infinoid isn't convinced, and goes off to test that.
<Coke> I need to head out. Regards.
<pmichaud> well, this would presume that the target lists the intermediate as a dependency
<pmichaud> so if the intermediate is gone, then make treats it as being out of date and rebuilds it, then uses it to rebuild the target
<pmichaud> try it with a .o file sometime -- remove the .o, and make will rebuild it and then rebuild the target
<Infinoid> just tested, GNU make rebuilds a toplevel target if an intermediate target it depends on is removed
<pmichaud> yes
<pmichaud> this is exactly how make is supposed to work
<pmichaud> (see my .o example)
<Infinoid> yeah
<Infinoid> so... keep the intermediate around.  if it's too confusing to have two PGE.pbc files in two directories with different attributes, call the intermediate miniPGE.pbc
<pmichaud> that doesn't work
<pmichaud> because Perl6Grammar.pir expects to find PGE.pbc
<Infinoid> so we live with the confusion?  or overwrite the original?
<pmichaud> if it's a major pain I'll rework the makefile so that there's only one PGE.pbc (in library)
<Infinoid> I doubt it matters, as long as library is where parrot looks first
<pmichaud> however, keep in mind that if PGE fails to build at some point (and it's often hard to notice because it's in the middle of the long root build), then you end up with an incomplete PGE.pbc and things start failing
<chromatic> I'm still not sure what the point of rejigging the makefile is at this particular moment.
<pmichaud> me neither
<wknight8111> http://aegis.sourceforge.net/auug97.pdf
<chromatic> ... but I can imagine a couple of ways where it's possible.
<wknight8111> link contains lots of good information about make
% Limbic_Region has joined #parrot
<particle> coke's aiming to make make -j make faster
<Infinoid> pmichaud: how would you feel about removing it upon failure, rather than removing it upon rebuild?
<pmichaud> hmmm?
<Infinoid> something along the lines of: $(CC) -o PGE.pbc <stuff> || (rm PGE.pbc; exit 1)
<pmichaud> if we can be certain that they remove on failure, sure
<Infinoid> if that can be made portable
<Infinoid> heh.  s/CC/PARROT/
<pmichaud> and make sure that Parrot's exit codes always make sense for -o
<Infinoid> which it probably should anyway
<pmichaud> it should, but I'm not sure that it does
<Infinoid> do we test that yet?  sounds useful.
<pmichaud> thus I kept overlooking that the PGE build was failing
<Infinoid> understandable
<Infinoid> in that case, make would overlook it too
<pmichaud> well, make was overlooking it, so I did
<Infinoid> all right.  tonight I'll write a test
<pmichaud> I should also note that in the case of PGE, having -j isn't going to help much because it's a sequential process anyway
<pmichaud> even if we list the dependencies "right"
<pmichaud> there's no opportunity for parallel build in PGE
<pmichaud> the Makefile is essentially a build script that is in the form of a Makefile, with one target.
<pmichaud> increasing the number of targets isn't going to suddenly discover parallelism where it doesn't exist (in PGE's case)
<Infinoid> right, but that doesn't mean a single all-knowing make couldn't build non-PGE things at the same time
<pmichaud> ahhh, having sub-makefiles prevents -j from working?
<pmichaud> I figured it just meant those sub-makefiles couldn't participate in being likewise ||
<Infinoid> having sub-makefiles makes it more difficult
<Infinoid> one moment, let me dig up a svn rev number
<Infinoid> ok, sorry, that wasn't as relevant as I had hoped
<pmichaud> also, I have trouble seeing what might build in parallel with PGE that can't already do so with the present Makefile
<Infinoid> the whole compilers/PGE directory is currently treated as a single big dependency, which isn't really that far from the truth
<pmichaud> exactly
<pmichaud> and tge depends on pge
<pmichaud> nqp depends on pct and pge
<pmichaud> json depends on pge
<Infinoid> so... once pge is done, pct and tge could be built in parallel, and then nqp and json could be built in parallel?
<pmichaud> actually, I think that pct and pge can be in parallel, then tge and json and nqp
<Infinoid> currently, the compilers.dummy rule of the Makefile will build those 5 in serial.
<pmichaud> right
<pmichaud> I'd change it to be
<pmichaud> compilers: compilers.pge compilers.pct compilers.tge compilers.json compilers.nqp
<pmichaud> then have separate $(MAKE) for each of those
<pmichaud> compilers.pge:  $(MAKE) compilers/pge
<pmichaud> compilers.tge: compilers.pge   \n  $(MAKE) compilers/tge
<pmichaud> etc.
<Infinoid> yeah, something along those lines
<Infinoid> also, I had to fix a faulty dependency in this area, a week or two ago.  the dependencies implied libparrot could be built in parallel with pge, rather than libparrot being a dependency of pge
<Infinoid> see the latter half of http://www.parrotvm.org/svn/parrot/revision?rev=26643
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-205-218.dynamic.mnet-online.de
<pmichaud> oh, that looks like a total pain
<pmichaud> because GEN_LIBRARY includes components that depend on PGE.... well, maybe not to build
<pmichaud> it seems weird that we would build $(LIBRARY_DIR)/PGE/Util.pbc prior to building PGE itself :-)
<Infinoid> see, whenever I see something like that, my makefile-rewriting finger starts itching.
<pmichaud> a n y w a y
<pmichaud> if you all want to refactor the makefiles, I have no problem with it as long as everything works
<Infinoid> that's a reasonable goal :)
<chromatic> PGE depends on libparrot though.
<pmichaud> building PGE also depends on Parrot/HLLCompiler.pbc
<pmichaud> (for now)
<pmichaud> I do have a problem with increasing the options or number of source code files that are needed to build PGE
<pmichaud> i.e., if I have to maintain separate Perl6Grammar.pir files or various option switches, that seems like a Net Lose.
% rdice_ has left rdice_!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<pmichaud> I could also eliminate the 2-stage PGE build by simply hand-coding the builtins.pg file as PIR rules
<pmichaud> (there's only one rule in there at the moment)
<pmichaud> but if we ever decide we want a library of standard rules to be part of PGE and that those are coded using regexes as source, we'd need a multi-stage build again
<Infinoid> if we have to move or copy stuff around to maintain atomicity, it should still all come from one source file... anything else is a DRY fail.
<pmichaud> I think that adding options that are only used for building is also some sort of fail
<chromatic> Definitely agreed.
* Infinoid starts adding things to t/run/exit.t
<pmichaud> afk, dinner
<Infinoid> thanks for the discussion, pm
<dalek> r26857 | bernhard++ | trunk:
<dalek> : Regenerate MANIFEST.SKIP
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26857
% barney has joined #parrot
<dalek> r26858 | bernhard++ | trunk:
<dalek> : #52556: [PATCH] Eclectus: simplify PAST generation a bit
<dalek> : Courtesy of Andreas Rottmann
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26858
<rotty> hey! :)
<rotty> hello barney 
<barney> Hi, just coming home from Frankfurt.pm meeting
<rotty> barney: just as an aside: please apply my patches verbatim or reject them (I'm managing them with StGit)
% kid51 has joined #parrot
% skids has joined #parrot
* jonathan yawns after a long day's work negotiating
<jonathan> Four hour flight and airport boringness tomorrow. May get some more Rakudo hacking in.
<barney> rotty: Yes, applying the patches is easier when they are in form as mentioned in submissions.pod
<skids> jonathan: suggestion, if it's easy -- An error message of "Type blah refuses to be assigned type blah " maybe with a "due to where statement" tacked on for refinements -- would be much more useful than "Type check failed".
<rotty> barney: what did I do wrong? I did have a look at submissions.pod...
<Infinoid> git patches need to be applied with patch -p1, not patch -p0
<barney> the usual 'patch' does not know about the 'a' and 'b' dirs
<rotty> yes, I did not deem this important
<Infinoid> its a git-ism.  I guess I'm used to it.
<rotty> (as you can just use -p1)
<barney> I just tried that. perhaps I mistyped
<Infinoid> it should work... -p1 tells it to strip the a/ and b/
<jonathan> skids: Completely agree, the first two parts are maybe easy, though for anonymous refinement types it's a tad harder.
% peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com
<jonathan> But yeah, needs better error message.
<jonathan> I'll see what I can do.
<jonathan> Thanks for the feedback. :-)
% iblechbot has joined #parrot
<skids> thanks for the types ;-)
<particle> jonathan: you can use "<anon>" for anonymous types until we have something better
<dalek> r26859 | bernhard++ | trunk:
<dalek> : #52588: [PATCH] Eclectus: refactor Perl test wrappers
<dalek> : Courtesy of Andreas Rottmann.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26859
<jonathan> particle: Sure, good idea.
<barney> rotty: yes 'patch -p1' works fine
<rotty> :-)
<particle> that'd be a nice detail to document somewhere
<jonathan> particle: actions.pm is getting kinda...big. What would you think to trying to refactor some of the larger actions a bit to use various subs, and putting those into a separate .pm file or files? It's just that it takes a little while to compile. 
<jonathan> By "what would you think to", I'm not asking you to do it - just asking what you think of the idea. :-)
<particle> jonathan: i'm not against the idea, as long as they're well-factored
<jonathan> Sure
<jonathan> Well, actions.pm is close to hitting the minute mark to compile on this laptop.
<jonathan> And yes, I know that really means I need a new laptop...
<dalek> r26860 | bernhard++ | trunk:
<dalek> : #52592: [PATCH] Eclectus: Replace brackets with parens
<dalek> : Courtesy of Andreas Rottmann.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26860
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-198-247.dynamic.mnet-online.de
<rotty> barney: what reason do you want to switch to generating NQP instead of PAST for?
* particle heads out for a bike ride &
<barney> I want to keep the PAST, just change the PAST-generation code from PIR to NQP.
<barney> Just because the syntax is nicer, not so many temporary variables
<rotty> ah, I see
<barney> The PAST generating code can be one big nested constructor
<rotty> btw, what do you think about using riaxpander to do the macro expansion stuff for us?
<rotty> riaxpander is http://mumble.net/~campbell/darcs/riaxpander/
<rotty> s/is/is at/
<rotty> btw, there is a good overview of Scheme macro systems at http://lists.gnu.org/archive/html/chicken-users/2008-04/msg00013.html
<shorten> rotty's url is at http://xrl.us/bi4y6
% schmalbe has joined #parrot
<schmalbe> rotty: I'll take a look at it tomorrow.      
<rotty> barney: are you ok with a subdirectory for each Scheme we support for bootstrapping, or should that be layed out differently?
<rotty> schmalbe: ok
<schmalbe> subdirs seem sane.  Have you checked with Ikarus?
<rotty> schmalbe: Ikarus doesn't run on my main machine (it needs SSE2 or something)
<rotty> (so, no)
<dalek> r26861 | bernhard++ | trunk:
<dalek> : #52600: [PATCH] Eclectus: now works also with Guile
<dalek> : Courtesy of Andreas Rottmann.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26861
% barney has left barney!~bernhard@dslb-084-058-173-232.pools.arcor-ip.net
<rotty> schmalbe: we should probably select a few (maybe 3) implementations for bootstrapping, to keep the overhead low
<dalek> r26862 | bernhard++ | trunk:
<dalek> : [Eclectus]
<dalek> : Set SVN properties for newly added files.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26862
<rotty> I'm very much for dumping Petite chez, its command-line interface is *very* limited
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
<schmalbe> Do you recommend Guile ?
<rotty> schmalbe: Guile has some problems with macros and modules; Gauche is better in that respect
<dalek> r26863 | bernhard++ | trunk:
<dalek> : Give credit to Andreas Rottmann.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26863
<rotty> (I'm not sure this matters for our purposes, but if we want to use riaxpander, it might)
* schmalbe deprecates Petite Chez Scheme for Eclectus 
<rotty> dalek: are you aware of the harness "-le" problem?
<rotty> oh, that should have been schmalbe: ...
<schmalbe> rotty: Are you on IRC tomorrow?
<rotty> the current eclectus codebase is not very much suited for compilers because of the way the test harness works, btw
<rotty> schmalbe: yes
<schmalbe> Can we do some planning this evening? (Barney realizes it's past midnight) 
<rotty> schmalbe: sure
* schmalbe calls it a day
<schmalbe> Cool
<rotty> :-)
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% schmalbe has left schmalbe!~bernhard@dslb-084-058-136-186.pools.arcor-ip.net
% TonyC has joined #parrot
% nopaste has left nopaste!~opaste@202-154-105-237.people.net.au
% TonyC has left TonyC!~tony@202-154-105-237.people.net.au
% nopaste has joined #parrot
% rdice has joined #parrot
<Infinoid> kid51: (re: Perl::Critic disappearing) you could always try the brute force method
<nopaste> "Infinoid" at 96.238.213.50 pasted "make perlcritic.t dump @INC to stderr" (12 lines) at http://nopaste.snit.ch/12660
<Infinoid> if there's anything weird like the search path being truncated, or another rev of perl being invoked, it'll show up there.
<kid51> Infinoid:  What does 'brute force' mean in this context?  (the problem seems to be with make test as much as Perl::Critic)
<kid51> On another subject:  Do you have anything to add re http://rt.perl.org/rt3/Ticket/Display.html?id=52154 -- the ticket having to do with pulling 'svk' and 'git' related code out of Parrot::Revision?
<kid51> Coke will have to make a decision, because it's one of those things where we can't make everybody happy.
% TonyC has joined #parrot
<Infinoid> kid51: by "brute force", I meant: attack the problem of "why can't it find my module" head-on, by verifying the environmental things that could affect module loading
% tetragon has joined #parrot
<Infinoid> does bitcard have any "don't forget about my login" related preferences?
<nopaste> "kid51" at 71.247.48.190 pasted "'prove' finds Perl::Critic with no problem; why not 'make test'?" (19 lines) at http://nopaste.snit.ch/12662
<kid51> Infinoid:  Don't know; unfamiliar with Bitcard except it simplest usage.
<kid51> Would that have a bearing on problem at hand?
<Infinoid> just an annoyance at being bounced to a page that doesn't have "Reply" buttons, no big deal
% ruoso has left ruoso!~ruoso@81.84.156.87
<Infinoid> hmm.  I don't really feel too strongly about #52154.  if the concensus is to keep svn around, I won't challenge it, as long as everything else is simplified
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
% cognominal has left cognominal!~cognomina@82.67.232.89
% paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net
% paco has joined #parrot
<Infinoid> you could pretty easily parse the svn rev out of "svn info".  but the same argument could be made of Configure.pl doing so
<Infinoid> I think the main issue was the pain of having to support svk, git, git-svn, and that is being addressed
<Infinoid> so ... do you want me to post that to the ticket?
<kid51> Yes, please post whether you agree with the patch or not and what any outstanding issues may be.  (Asking you 'cause I remember our conversation on IRC 2 weeks ago about this.)
<Infinoid> re: Data::Dumper, ok, that's bizarre.
<kid51> Now, something equally bizarre ... but a pattern is developing:
<nopaste> "kid51" at 71.247.48.190 pasted "Where t/*.t files do an 'eval {require ...}' to locate a Perl module" (12 lines) at http://nopaste.snit.ch/12663
<Infinoid> ok, I've cast my vote
<kid51> Ooh, I've got a hunch!
<Infinoid> it almost looks like the harness is doing something that breaks the *first* use, or require, or whatever, in interesting ways
<Infinoid> I got a weird warning from YAML::Syck in that patch I nopasted earlier, too.
<Infinoid> something about a barename only being used once, possible typo
<Infinoid> what's the hunch?
<kid51> My hunch:  Note that there's no semicolon after Perl::Critic -- nor is there one after Moose in that other test.
<Infinoid> hmm.  do BEGIN blocks get concatenated together before execution?
<kid51> But why 'make test' would gag there when 'prove' and 't/harness' don't, I cannot explain.
<chromatic> The semicolon issue is a red herring.
<chromatic> The final statement in a block does not require a semicolon in Perl 5.
<kid51> Okay, then what color is the herring?
<chromatic> Red.
* kid51 set himself up for that one.
<chromatic> Dump @INC to STDERR from the test file and see what's different between runs.
<Infinoid> chromatic: http://nopaste.snit.ch/12662  (standalone)
<Infinoid> kid51: does "perl t/harness t/codingstd/perlcritic.t" look the same?
<kid51> It looks same as 'prove' i.e., it locates Perl::Critic and runs the file without complaint.
<Infinoid> so, the harness is fine, something from the Makefile maybe?
<kid51> for use of perl t/harness, see my post to list of 17:18:09 PDT
<Infinoid> on my box, "make test" actually runs: /usr/bin/perl5.10.0 t/harness --gc-debug --running-make-test
<chromatic> `which perl`
<Infinoid> /usr/bin/perl  (symlink to perl5.10.0)
<chromatic> Are you seeing this craziness too?
<Infinoid> no.
<kid51> chromatic:  When I include the semicolon, 'make test' runs t/codingstd/perlcritic.t without complaint!
<chromatic> That's unique.
<chromatic> $ perl
<chromatic> eval { require CGI::Cookie };
<chromatic> print $@;
<chromatic> print $INC{'CGI/Cookie.pm'}
<chromatic> /usr/local/share/perl/5.8.8/CGI/Cookie.pm
<kid51> Note:  I realize that I don't actually have Moose installed
<kid51> Well, I guess it can't hurt to put that semicolon after 'require Perl::Critic' -- correct?
<chromatic> Correct, but I fear it's covering up some sort of weirdness elsewhere.
<kid51> Shall I commit, or do you want to explore further?
<Infinoid> c, can you reproduce?
<chromatic> No, I can't.
<Infinoid> like I said, I don't see this craziness, but I do see other craziness.  like, warnings from modules that normally load silently.
<kid51> Infinoid:  You see such warnings ... when?
<chromatic> I only get that from Text::Balanced.
<Infinoid> Name "YAML::Syck::ImplicitBinary" used only once: possible typo at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/YAML/Syck.pm line 65.
<Infinoid> I get that under perl t/harness, but not under prove.
* kid51 doesn't have YAML::Syck installed anywhere.
<chromatic> prove -v
* Infinoid can't even begin to explain this.
<chromatic> I mean prove --version
<Infinoid> no warning under prove -v
<Infinoid> oh
<Infinoid> prove v2.64, using Test::Harness v2.64 and Perl v5.10.0
<chromatic> TAP::Harness v3.02 and Perl v5.8.8
<chromatic> Hm, I thought 5.10 included TAP::Harness 3.
<nopaste> "kid51" at 71.247.48.190 pasted "patch to assure that 'make test' locates Perl::Critic" (27 lines) at http://nopaste.snit.ch/12665
<kid51> Guys, I gotta step away.  If you want to (literally) patch the problem, there's a suitable patch.
% kid51 is now known as kid51_afk
<Infinoid> 5.10 does not seem to include TAP::Harness
% kid51_afk has left kid51_afk!~jkeen@pool-71-247-48-190.nycmny.east.verizon.net
<chromatic> Maybe it just missed the cutoff.
<chromatic> Do you see the weirdness with TAP::Harness?
% Ademan_ has left Ademan_!~dan@h-68-164-168-66.snfccasy.dynamic.covad.net
% silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net
% Ademan_ has joined #parrot
<pmichaud> anyone think we can close rt#51732?
<chromatic> I'm sure it was a lacking realclean.
<Infinoid> chromatic: yes, I still see the weirdness with TAP::Harness v3.10
<Infinoid> but I still don't know whether my weirdness is related to kid51's weirdness.
<chromatic> The missing semicolon is bizarre.
<Infinoid> what do you think our possibilities of coming up with a oneliner that reproduces it are?
<chromatic> Pretty low, unless it includes an -I
% rdice has left rdice!~richarddi@CPE001217e365c7-CM00159a01d44c.cpe.net.cable.rogers.com
% kid51 has joined #parrot
<Coke> (makefile) I'm aiming to get all the dependencies worked out. having -j work is a nice side effect there.
<Coke> kid51: are you sure you're using prove and perl from the same distro?
<kid51> My Perl is 5.10, compiled from source the day it came out.  My prove is that associated with most recent Test::Harness (3.10)
<kid51> Darwin:  [jimk] 503 $ prove --version
<kid51> TAP::Harness v3.10 and Perl v5.10.0
<Coke> was that test::harness installed against the same perl?
<kid51> Linux:  [li11-226:~] 501 $ prove --version
<kid51> TAP::Harness v3.09 and Perl v5.10.0
<Coke> (just that would explain the library discrepancies.)
<kid51> Yes.  Because TAP::Harness 3.10 is more recent than Perl 5.10.
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net
<kid51> But note that this error only occurred during 'make test' and only when perlcritic.t read:  eval { require Perl::Critic };
<kid51> But it occurred, albeit with different output, on 2 different OSES.
<kid51> OSES.
<kid51> OSes.
<kid51> Also, note that since perlcritic.t was only very recently included in 'make test', I wouldn't have noticed this problem, say, 3 months ago.
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<pmichaud> kid51: do you think we can close rt#51732?  (I'm reviewing tickets in my inbox and happened across this one.)
<Infinoid> are you using perl 5.10 on both OSes?
<kid51> Yes.  But here's some new data.
<nopaste> "kid51" at 71.247.48.190 pasted "Using the 'vendor' Perl and prove on Darwin to run perlcritic.t" (8 lines) at http://nopaste.snit.ch/12666
<chromatic> That depends on where you have P::C installed and what's in @INC.
<kid51> That's the first case where I can use a version of 'prove' to simulate the results with make test.
<kid51> Err, let's see.
<Infinoid> that one's probably because P::C is installed in /usr/local/lib/perl5/site_perl/5.10.0/Perl/Critic.pm
<Infinoid> I doubt that's in 5.8.6's search path.  do you have another copy installed?
<kid51> Yes.  the @INC for 5.8.6 does not include the directory where P::C is installed.
<Infinoid> sorry
<tetragon> I'm installing P::C right now on my Darwin install
<tetragon> (it used to be there, but was lost in a system upgrade)
<kid51> tetragon:  All those dependencies are fun, right?
<tetragon> hehe
<tetragon> I think people grumble about LedgerSMB's dependencies more
<kid51> I met Elliot, the current maintainer of P::C, when I was at the mini-hackathon in Chicago in December.
<kid51> Nice guy, but I still hate modules where the cpan shell forces me to say yes 3 times.
<kid51> Mainly 'cause it's sitting on PPI.
% Theory has joined #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
<kid51> So, would my 'make test' -- on either OS -- for some reason not know to look in the @INC associated with 5.10?
<kid51> And why would a semicolon make a difference?
<kid51> Perhaps with 5.10 you need the last semicolon in a block???
<tetragon> Incidentally, vendor Perl on OS X 10.5 picks up on the P::C I just installed with prove
<tetragon> And that test is swamping my system
<kid51> which test?
<tetragon> t/codingstd/perlcritic.t
<chromatic> Unless something changed the parser in a backwards-incompatible way, the semicolon isn't the problem.
<kid51> Really?  It's not particularly speedy on my iBook G4, but there are others slower.
<tetragon> It has finished
<chromatic> It's pretty IO intensive.
<tetragon> And subtest 3 failed
<tetragon> It was consuming all CPU
<kid51> The question we've been discussing is that 'make test' on my boxes fails to locate Perl::Critic and therefore SKIPs that test.
<tetragon> The failed subtest looks like it was my modifications
<kid51> Oooooh.
<tetragon> I patched config/init/defaults.pm so that I wouldn't have to remove all the -arch flags from all the Makefiles
<kid51> Ah, yes, *that* patch :)
<dalek> r26864 | coke++ | trunk:
<dalek> : Add a TODO test for #46499: [RFE] Allow comment lines in PIR .param list
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26864
% Eevee has joined #parrot
% kid51 has left kid51!~jkeen@pool-71-247-48-190.nycmny.east.verizon.net
% silug has joined #parrot
% silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net
<dalek> r26865 | infinoid++ | trunk:
<dalek> : [t] Make sure parrot returns non-zero on parse failure, and doesn't generate
<dalek> : an output file.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26865
<Infinoid> pmichaud: so far, parrot's return value looks good.  but my test case is pretty simple, and might need expanding.
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
<pmichaud> Infinoid++
% tetragon has left tetragon!~seneca@CPE0040d001f62f-CM000a736592a8.cpe.net.cable.rogers.com
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% allison has joined #parrot
<chromatic> http://www.cs.dartmouth.edu/reports/abstracts/TR2001-404/
<dalek> r26866 | pmichaud++ | trunk:
<dalek> : [pct]:
<dalek> : * Allow --encoding=fixed_8 to work for HLLCompiler.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26866
% silug has joined #parrot
<dalek> r26867 | pmichaud++ | trunk:
<dalek> : [rakudo]:
<dalek> : * Since actions.pm doesn't have any non-ascii characters in it yet,
<dalek> :   we can tell NQP to compile using fixed_8 instead of the utf8 default.
<dalek> :   This gives us a 28% (101 versus 141 sec) speed improvement on 
<dalek> :   my box.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26867
% silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net
<chromatic> Nice.
<chromatic> I'll take temporary victories until we can fix the real things.
% iblechbot has joined #parrot
% uniejo has joined #parrot
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-200-240.dynamic.mnet-online.de
% Theory has joined #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net