% Coke has joined #parrotsketch
% Coke has left #parrotsketch
% avar has left avar!~avar@dsl-228-236.hive.is
% avar has joined #parrotsketch
% smash has joined #parrotsketch
% jonathan_ has joined #parrotsketch
% bernhard has joined #parrotsketch
% chromatic has joined #parrotsketch
% allison has joined #parrotsketch
% rdice has joined #parrotsketch
<chromatic> Who's here today?
<allison> hi all
* bernhard is here
* rdice is here, nothing to say, just interested in the goings-on
* jonathan_ is here
<smash> hi all
<chromatic> Okay.  We lack a Coke, so I'm in charge.
<chromatic> allison, what's new?
<allison> ah, bitten by alphabetical order again
<allison> I've been working on the PMC PDD
<allison> nearly ready to move that out of draft
<allison> also on the object implementation
<allison> we seem to be failing about a third of the old object system tests with the new object system
<allison> I haven't broken them down yet by which pieces are missing
<allison> EOR
<chromatic> Okay, my turn.
<chromatic> I fixed a couple of bugs.  The optimized build now passes all of its tests, at least on x86 Linux with GCC.
<chromatic> I also enabled symbol hiding on Linux with GCC, and fixed the resulting bugs.  This should (when it gets compiling again elsewhere) help us get more tests passing on Windows.  I need help figuring out how to disable it on GCC 3.x and earlier though.
<chromatic> I filed three bug reports related to some very dodgy C tests.  I hope someone can look at them.
<chromatic> Next, bernhard?
<bernhard> Inching forward with languages/lisp
<bernhard> That's it
<chromatic> jonathan_?
<jonathan_> * Scandinavia is beautiful, Russia is crazy, England is all boring and rainy.
<jonathan_> * Gave Parrot talks at Oslo and Trondheim during my trip, to folks of varying Perlness; also had conversations with some academics in Stockholm - possibility of a Parrot talk at the dynamic languages bit of OOPSLA.
<jonathan_> * Digging back into Parrot this week
<jonathan_> * Fixed the build on Windows last night...'twas br0ked
<jonathan_> * Reading bits of the mailing list posts over the last month that look interesting
<jonathan_> * Want stuff to look at
<jonathan_> .end
<chromatic> Sorry!  That was me with the b0rking.
<chromatic> Any leo?
<jonathan_> No worries, it's at least partly fixed. :-)
<chromatic> smash?
<smash> built packages for fedora
<smash> http://parrot.homelinux.org/packages/
<smash> asked coke to add link to parrotcode.org
<smash> tweaks to parrot.spec
<smash> EOR
<chromatic> tewk?
<chromatic> No tewk, at least at the moment.
<tewk> New Pmc2c branch is successfully generating pmcs, finishing cleanup in that branch.
<tewk> New PDD15 is failing old object system tests, because it doesn't delegate vtable calls to vtables implemented in PIR.
<chromatic> May I point you at jonathan_ and vice versa?
<allison> tewk: ah!
<tewk> Pmc2c should autogenerate the thunking code to get object.pmc to call vtables implemeneted in PIR.
<tewk> Hence the trip down the Pmc2c cleanup road.
<jonathan_> tewk: Agree.
<tewk> EOR
<chromatic> Alright.  Question time.
<chromatic> Question 1: how broken is the build now after my hack-n-slash?
<chromatic> 1b: if it's not broken anymore, did we regain any ground on Windows?
<jonathan_> Windows didn't build a Parrot executable for me last night, it now does that, but nci_test.c fails to compile now.
<jonathan_> Not looked into that yet.
<chromatic> Does r18672 help?  Francois checked in a fix.
<chromatic> If Parrot builds again, there are some tests in t/src/ that get skipped right now but might pass again for Windows.
<jonathan_> I'll svn up and try.
% Andy has joined #parrotsketch
<chromatic> Question #2: does anyone know how PARROT_API should work?
<chromatic> 2b: If so, can you write up something in docs/dev/ about it?
<jonathan_> I introduced it.
<jonathan_> Basically, we used to build a huge export list.
<jonathan_> A .def file
<chromatic> I'm mostly curious about how to use it correctly.
<jonathan_> But that was kinda quirky, so instead all things that were to be exported and visible outside of libparrot were marked PARROT_API
<jonathan_> The only platform where I'm aware it does something is Windows, but that may have changed.
<chromatic> Yeah, I changed it on Linux with GCC.
<jonathan_> Basically, on Windows it maps to __declspec(dllexport)
<jonathan_> Inside the lib
<jonathan_> So that the symbols get exported by the linker.
<chromatic> GCC 4 can now hide unexported symbols, so if we don't mark things appropriately there, we'll know that we've broken Windows.
<jonathan_> That's nice to have.
<chromatic> I think we can get rid of libnci_test.def too, if this works.
<jonathan_> Yes, I worked on this to get rid of the .def file.
<jonathan_> But if we can get rid of another one, great.
<chromatic> Would you mind writing up a very short description of what it is and where to put it, for docs/dev?
<jonathan_> Sure.
<jonathan_> Though were to put it is an interesting question.
<jonathan_> *where
<jonathan_> In that, it kinda defines the Parrot API.
<jonathan_> Which is a design decision rather than just ad hoc "throw it where we need it" kinda thing.
<chromatic> I meant in the header files versus the source files or wherever, not on which symbols.
<jonathan_> Oh, I see.
<jonathan_> Sure, can do that.
<chromatic> Thank you.
<chromatic> Other questions?
<jonathan_> 1) What happened while I was away that I should really know about?
<jonathan_> 2) Anyone got anything specific they'd like me to spend my Parrot time on?
<chromatic> 2 - PDD15 is probably the most important new code.
<allison> 1 - Nothing earthshakingly drastic, you've been on periodically, enough to keep up-to-date
<chromatic> My life would be much easier if someone who understood argument passing looked at "Why You Can Only Call Sub PMCs from C".
<jonathan_> chromatic: I saw that post, it's on my "interesting posts to try and look into" list. :-)
<tewk> jonathan_: I checked in t/pdd15oo/ test which are just the old oo tests using the new pdd15.
<jonathan_> tewk: Aha, OK.
<jonathan_> How bad is it?
<tewk> Trying to get a new Pmc2c checked in to fix the vtable in PIR delegate stuff cleanly.
<jonathan_> OK
<tewk> Not bad, we are just still missing stuff such as inherting from PMC's and defining vtables.
<jonathan_> How well is the inter-object universe stuff (which inheriting from PMCs is a part of) defined?
<jonathan_> I didn't spot much detail in PDD17, but was a little tired when I read it.
<allison> jonathan: still in progress
<jonathan_> OK.
<tewk> allison++ has a pretty good email on list about the compromises of compile time pmc role composition.
<jonathan_> How far along the right lines was my proposal on that stuff?
<allison> so, I'm not sure having manually generating all the vtable entries in Object PMC is the best way to handle delegation to PIR defined vtables
<tewk> I tend to agree with the conclusions there.
<allison> mainly because we may  have to do more to allow defaulting back to the inherited low-level vtable entries for Classes that inherit from a low-level PMC and override some vtable entries in PIR
<tewk> allison: If object pmc inherits from delegate, Pmc2c will put them in automatically.
<tewk> Pmc2c will also handle overrides due to pmc inheritance.
<allison> that's one of the things we were trying to move away from, requiring that inheritance act as delegation
<tewk> Well we can add a new pmclass directive and get more of a default mixin behavior if you want.
<allison> it may ultimately prove impossible
<jonathan_> Things also get messy if you want to write an object system in PIR. What if, for example, you want to implement a WobObject in PIR, with its own method finding implementation. So it's an instance of the Object PMC really since it's an Object, but how do you override the find_method vtable method etc.
<allison> right, that's the problem with making delegation a manual thing
<jonathan_> allison: I'm not sure you can get away from delegation in some form; objects from different class systems can't *really* inherit from each other. Partly because they don't understand each others concept of how state is stored. That differs a lot between low level PMCs and high level language objects.
<allison> alek storm had a patch, I didn't agree with the whole thing, but he had implemented the check for override as part of system wide dispatch, rather than custom to each PMC
<allison> jonathan: yes, but the question is where you put the interface layer between the two
<jonathan_> Is there a ticket number? I think I need to see the code to grok that...
<tewk> Lets be clear here, delegete pmc is different from deleg_pmc,  all that the delegate pmc does right now is add needed vtables.  deleg_pmc does actual delegation from an object to an inherited pmc.
<allison> it could just as easily be a proxy Class entered in the high-level class's inheritance hierarchy
<jonathan_> Essentially the thing I was calling MetaPMC?
<allison> proxy class knowing how to respond as an ordinary class, but internally operate on a low-level PMC
<allison> jonathan: similar
<jonathan_> The problem is more with the instances than the classes, I think.
<jonathan_> Which in a truely metamodel world sounds wrong, I know. :_)
<allison> Alek's patches: RT#42905
<allison> that's a fairly vague statement
<allison> would like more details, but perhaps we should move to #parrot?
<jonathan_> Perhaps.
<chromatic> Are there any further questions?
<chromatic> Allison suggested one of the STM files as our FOTW.
<allison> I'm thinking src/pmc/stmvar.pmc
<chromatic> Are the FOTWs valuable?
<allison> or maybe src/stm/backend.c
<allison> I think they're valuable
<allison> even if we only make a handful of fixes to the file, it's still progress on the battle against entropy
<chromatic> Let's do the backend file this week.
<allison> Alrighty, thanks everybody! Moving to #parrot
% chromatic has left #parrotsketch
% jonathan_ has left #parrotsketch
% Andy has left #parrotsketch
% rdice has left #parrotsketch
% bernhard has left bernhard!~bernhard@p549A2E0D.dip0.t-ipconnect.de
% allison has left allison!~chatzilla@63.105.17.30
% allison has joined #parrotsketch
% integral has left integral!bsmith@adsl-212-20-244-147.lumison.co.uk
% integral has joined #parrotsketch