On Wed, Jun 19, 2013 at 2:02 PM, Nick Wellnhofer <[email protected]> wrote: > Yes, the possibility that the first definition of a method could be moved to > a parent class is the main reason why we need all those offset variables. > But it's just an implementation detail. It would be nice to find a better > solution, but the current approach doesn't pose any serious problems.
Part of what's driving this line of development is that I've personally spent a good part of the last year studying language implementation and other low-level computer science topics and I'm circling back to see if any of the new techniques I've learned suggest any improvements. My take so far is that the original "inside-out vtable" concept turns out to have been fundamentally sound, and that among Nick's vast contributions over the last year have been fixes for what were the most glaring flaws in this specific corner of the codebase (more optimal symbol export, linking portability, etc.). I think it's going to be hard to improve much more without a life-changing architectural shift such as implementing a JIT. In the meantime, it's not a huge amount of work to explore the short menu of options available to us given our current constraints. (And it's super fun!) > I don't think that the uptake of Lucy has anything to do with complexity, > actual or perceived. The critical factor, in my opinion, is that we only > support Perl. I don't want to start a discussion about the future of Perl, > but it's a fact that Perl usage is declining and that there are very few new > projects written in Perl. The good thing is that our architecture has been > designed to support multiple host languages via Clownfish. Supporting other > languages like Python or Ruby still means a lot of work, but I think we have > made some considerable progress in that area. Resilience in the face of host language popularity swings is a potential selling point for Clownfish as we compete for module developer interest. > My current focus is about making Clownfish a stand-alone and great product. > And for Clownfish, solving the fragile ABI problem would be an incredibly > important feature. You're right that there's not much direct benefit to > Lucy. Well, it's not possible to write independent compiled extensions against Lucy 0.3.x, so I'd argue that there's significant benefit. > I agree that we shouldn't strive for perfection and release early but often. > Even if the Lucy core is basically unchanged from 0.3, I'm looking forward > to a 0.4 release. The C library might spark some interest and I'd love to > see a stand-alone Clownfish release on CPAN. It's been a long time since our last release -- almost a year. That's not normal for an Apache project. If we go much longer, we can expect some questions from the Board after our next report. Maybe we should have made some bugfix releases to the 0.3 branch; we didn't manage to lock it down 100% on CPAN testers. I think I've mentioned this before, but we might also consider a time-based release schedule in the future. However, I'd also say that having a small team working on Clownfish during these early stages helps to keep focus. I'll be happy if more devs join later, but I'm happy now! Marvin Humphrey
