% integral has left integral!bsmith@adsl-212-20-244-147.lumison.co.uk
% integral has joined #parrotsketch
% pmichaud has joined #parrotsketch
% jisom has joined #parrotsketch
% allison has joined #parrotsketch
% chromatic has joined #parrotsketch
% Andy has joined #parrotsketch
<chromatic> Morning/afternoon/localtime() all
<pmichaud> good afternoon!
<particle> good gmtime()
<chromatic> Who else do we have today?
<pmichaud> well, good gmtime() would be "good evening", yes?  ;-)
<particle> pm: not for those reading at home later :)
<chromatic> Shall we begin?
<chromatic> Andy?
<Andy> I've been perlbuzzing.
<Andy> So the only thing I did was
<Andy> to get attribute detection pretty much working.
<Andy> Next, I'll be doing -W flag detection, which is the REAL goal, because  that lets us add -W flags with impunity
<Andy> And now, back to my fires at work.
<particle> i have a feeling i'll be a guinea pig
<chromatic> allison?
<Andy> particle: Shouldn't be.
<particle> andy: great! let's sync up later.
<allison> I've been absorbed by producing a book this week, so not much on the Parrot front. That should go to print in the next day or so, and then I'll be full-time on Parrot for a while.
<allison> EOR
<chromatic> chromatic?
<chromatic> I've been writing a third article on Parrot; this is more about programming PIR.
<chromatic> I'd like to get feedback on it.
<chromatic> Otherwise, I hope to make one small change to the GC that should improve correctness, then work on the interpreter thawing problem again.
<chromatic> jisom?
<jisom> improvement on the amd64 jit, looked into osx i386 jit possibilities, which will require some of the work being done in the amd64 jit, waiting for reports of people testing it
<chromatic> particle?
<particle> ~ simplified PCCMETHOD syntax
<particle> ~ my todo list is much longer than my accomplishments list this week
<particle> ~ need to provide kid51 with ideas on cross-compilation
<particle> ~ thinking about optimizations that can be done in tree form (ast, ost, etc.) want to talk to pmichaud about implementing an optimization infrastructure for pct
<particle> ~ hoping to take a closer look at nqp soon and start extending it
<particle> .end
<chromatic> pmichaud?
<pmichaud> * PGE: Switched <before> and <after> built-ins to use updated
<pmichaud>   Perl 6 regex syntax.
<pmichaud> * Added proper statement termination to NQP
<pmichaud> ** (we can also use this for perl6)
<pmichaud> * NQP now has "if", "unless" statements (perlDreamer++)
<pmichaud> * NQP/PAST/POST can now create subroutine calls with keyword arguments
<pmichaud> * Applied various patches
<pmichaud> * Fixed a problem with file_metadata.t
<pmichaud> For this week:
<pmichaud> * Saturday bug day
<pmichaud> * Add method calls and named parameters to NQP
<pmichaud> ** This will largely complete NQP so that it can be used to write
<pmichaud>    transformations
<pmichaud> * Update 'abc' to use NQP
<pmichaud> * Start updating 'perl6' to use NQP
<pmichaud> * Prepare for next week's Parrot release (still needs a name)
<pmichaud> oops!  "Add method calls" should be "Add method definitions"
<pmichaud> (we already have method calls)
<pmichaud> EOR
<chromatic> spinclad?
<chromatic> tewk?
<chromatic> Anyone I missed?
<particle> chromatic: i have feedback on your second article. more than one person has shown up in #parrot based on that one, with enthusiasm and questions. chromatic++
<chromatic> Really?
<chromatic> I haven't seen it and didn't realize it was in print yet.
<particle> specifically, your last linux magazine article
<chromatic> Suh-weet.
<chromatic> Okay, let's go to question time.  Queue up.
* pmichaud enqueues
<chromatic> pmichaud the first
<pmichaud> jisom: (amd64 + testing)  -- what sort of testing needs to be done?  And is it only for AMD processors, or would intel x86_64 processors work also?
<jisom> should work on intel's processors, if the archname's x86_64 or amd64 it should work fine, just need to reconfigure with --jitcapable as I haven't yet set it to be compiled in by default
<jisom> I have no known cases of it being tested outside of my freebsd box
<pmichaud> okay, I'll try it out on my kubuntu box (x86_64, although kubuntu reports amd64)
<pmichaud> end of my question
<particle> pmi: any general goals for this release we can help with?
<particle> i suggest 'reduce compiler warnings'
<pmichaud> particle:  I hadn't come up with any general goals for the release, other than hoping that oo support would be available.  I'll try that out soon.  I would like to see the compiler warnings reduced, definitely.
<chromatic> Any further questions?
<particle> anybody familiar with cmake?
<particle> http://www.cmake.org/
<chromatic> The KDE folks are.
<particle> it's been proposed to me privately as a possible configure system enhancement/replacement
<particle> it's output is makefiles, so we'd still use a native make or msvc projects.
<chromatic> Seems reasonable to consider to me.
<particle> i think so too.
<particle> i'm coming around to the idea of "let's just assume we have perl" during configure.
<chromatic> Me too.
<particle> it means we can nuke miniparrot (at least i'm pretty sure it does)
<jisom> I'm guessing windows doesn't have awk, sed, or sh?
<particle> okay, that's it for me. i hope to have some tuits this week, but now that i'm older i need naps more often
<particle> jisom: we have perl, why do we need those? :)
<particle> jisom: not pre-installed.
<particle> and don't expect them to Just Work.
<jisom> well, when FreeBSD took out perl from their "core" a lot of stuff was rewritten using awk and sed, they're standard, on any unix(part of the unix standard is having awk, sed, and sh)..
<allison> particle: but, we can't assume we have Perl
<particle> allison: why not? if we can cross-compile, we can assume perl on the platform doing the compiling
<jisom> our configure doesn't assume we have a compiler :-p
<allison> because we're replacing Perl
<allison> so, assuming we have it now will bite us big-time down the road
<chromatic> We do have it now though.
<allison> we do, but if we start to optimize for using all perl in the build system, we'll be come more and more dependent on it
<particle> a parrot 2.0 will likely have some kind of bootstrapped thingy to replace our perl 5 assumptions
<allison> hrm...
<particle> allison: i'm proposing we consider cmake for the config engine, and use perl for funky automation
<particle> customization, etc.
<allison> okay, I was just going to ask "is there anything besides Perl we can depend on instead?"
<jisom> cmake doesn't mention much about support for the bsd's
<chromatic> If we're going to consider Cmake, we should really ask the KDE people.  Portability is important for them.
<jisom> more of a "we got the major players" portable
<allison> BSD is important for us
<jisom> "Unix Makefiles"  - This generator generates Makefiles for make under Unix and also for cygwin (i.e. with Unix paths) -- That's gmake
<allison> I'm still okay with using perl for scattered bits of funky automation, we just want to keep it as minimal as possible
<jisom> so that would require gmake to be installed, which would be less portable than our current makefile
<particle> (minimal perl for parrot build)++
<jisom> here's a quick question, how do we test the basics of parrot, i.e. syntax and opcodes, without a perl or parrot?
<particle> test parrot without parrot?
<allison> perl tests perl with perl
<allison> parrot tests parrot with parrot
<allison> you can't really run syntax and opcode tests until parrot is built anyway
<jisom> perl doesn't do any "now we're decently sure perl's ok, use perl for testing now"?
<allison> nope, the test suite is pure perl
<particle> right.
<chromatic> It sounds like we're wrapping up here.  Shall we adjourn?
<pmichaud> adjourn++
<particle> cya
% chromatic has left #parrotsketch
% pmichaud has left #parrotsketch
% jisom has left jisom!~jisom@74-134-230-123.dhcp.insightbb.com
% allison has left allison!~chatzilla@c-24-21-59-142.hsd1.mn.comcast.net
% Andy has left #parrotsketch