That means I am staying in Europe and might hit YAPC::EU or Italian Perl Workshop, which has the benefit of being in Italy and I have never seen the leaning tower.
So today we succeeded and we released, it should propagate on CPAN over the next couple of hours.
Status is pretty good, the current ponie will use hashes and arrays and lvalues hidden in PMCs, and it will pass over 80% of miniperl tests. However there seems to be some random memory corruption happening with arrays when they are being resized after something has happened to them. AvARRAY ends up pointing directly into an parrot managed arena.
The annoying thing is that most test pass, but a random selection of things fail, and they fail int he pad code because of the array issue, but no array tests fail, meaning there is most likely a lack of tests for how array resizing works.
One good thing is I sent a ponie related patch to p5p to clear up some nasty macros.
Essentially I have a solution for using PMCs for arrays simply by hiding the XPVAV behind an interface, and have all the macros return pointers into the structure. Now this allows the perl internals only to function with perl5array pmcs and not general pmcs, but for the the time being there is not much to do about it. Most parts of the perl internals assume total access to the internals of an array, this includes pad and stack handling code, the correct solution is for them to use the official API and not hack things directly, the reason they are not doing so is of course 'speed' reasons (or in some cases, because they do really really evil things). So for the time being, you will only be able to use perl5array pmcs in there, further ahead we should be able to, at least for most operations, be able to use any Parrot PMC that works as a container. (The question on how much XS code depends on the internals of arrays/hashes need to be looked at too).
Hopefully, by end of next week, arrays should be working fully again with tie calls going through a PMC switch and using a perl5tie pmc instead.
After a few more people joined in we went off to a mexican resturant which was nice, ended up in bed at midnight after being up close to 24 hours.
Then on saturday we got picked up by Jeremey White and taken to the hotel, it was a lot of small speeches, discussion and interesting approaches on how to fix things, and when the mythical 1.0 release will happen. The big thing is that Office really runs except clippy.
Right now there is demos and talk about winebuild, which is ofcourse what I think is most interesting, and then after this it will be a demo of ReactOS by the core ReactOS team. But first pizza.
At work I have recently been dabbing a bit into wine, you know, the ultra cool opensource implementation of the Win32 API. So I suggested to the company that instead of going to all boring (in the sense I heard most of the talks by now) perl conferences again, I switch one and hit Wine Conf, after an hours thinking I got the ok and now I am off to fly to Minneapolis on Friday the 29th of January, see wine hackers for the weekend and then fly back early morning on Monday the 2nd of February!
Maybe some perl people live in the area? Maybe some time on sunday to meet up?
I had a working hack of LVALUE types, barely, that kind of did interesting things. Most importantly it did compile miniperl. However life is never easy, a certain excellent french perl hacker, yes Rafael you, had changed LVALUE types since I last looked at them to be used in tie magic. So when you are fetching a tied value today, you actually get a LVALUE type with a undocumented 't' type, but this LVALUE type still uses tie magic instead of lvalue magic.
Implementing a emulation layer for tie magic seems fairly hopeless to me since tie magic is the most advanced type of magic and also since I am going totally rip it out when I redo hashes and arrays.
Obviously, the solution is simple, just rearrange the schedule a bit and RIP out hashes and arrays and implement them using PMCs instead, and this is exactly what I am going to do. So instead of January release there will be a leap day release (end of February) with lvalues, arrays and hashes being implemented using PMCs. This will be followed by a end of april - middle of may release which will have all SV types converted to PMCs, this release should be tested out in the wild against CPAN modules. Fixes to this release should lead up to a conference season release where the PMC conversion is declared to be done. This will let us focus on the next step, opcode to bytecode conversion.
Since nothing goes on in the ponie mailing list, there are no summarises, I have decided (after gnat and acme forced me
Over the last 4 months or so that I have been working on ponie (august, september, october, november) not much seems to have happen, quickly a first snapshot was released with an integrated perl/parrot build system, and a couple of emails to the parrot internal mailing list. However, several things have actually happened.
Ponie has pushed parrots embedding and extending API to a point where you can actually do things with parrot without including all of the parrot header files. It has also gotten build system that seems to be reliable to changes in parrot, there hasn't been a need to change it in quite a while.
The current plan is to implement perls LVALUEs using a PMC, since perls LVALUEs don't actually store any date, just pass on to whatever is behind the lvalue, (using magic today) this should be a somewhat limited thing to do that only touches specific ares of the core. So still being able to compile miniperl and run minitest without LVALUES is very very handy.
The current cvs version will in fact create a Perl5_LV PMC when you create a lvalue in perl (little treasure hunt, can anyone list all the ways to get a LVALUE reference type in perl), it will then die a horrible death because it attempts to use a SvPVX and fails with a FIXME error message. The use of macros as lvalues in C, (SvPVX(foo) = bar), was a bit difficult to find a way to emulate using functions. However, thanks to Nicholas Clark and Abhijit who told me that I can do #define SvPVX *(&Perl_svpvx((sv))) to make a lvalue function call. This will make it possible to emulate things properly in XSUBs. (All of the core will get their usage of lvalue macros rewritten however).