Dmitriy Iassenev wrote:
>> As I'm sure most people on this list are aware, there hasn't been a
>> whole lot of activity in Luabind lately. The last update to SVN trunk
>> was 6 months ago and that was fixing a typo in the documentation. I
>> gather that the primary developers have been very busy, but it'd be nice
>> to get a released version that works with Lua 5.1. I'd prefer to avoid
>> forking the project, but I understand if the Rasterbar folks don't want
>> just anyone messing around with their code.
>> Hopefully we can work something out at least to get a version 0.7.1 out
>> that works with Lua 5.1. I'm perfectly willing to help out in any way I
>> can, of course.
> I would like to give my improvements into the luabind SVN, since
> authors of luabind are too busy for 3 years I use their product. If
> there will be no active development, the project will be dead in a few
> years. Now I use their branch beta7-devel-rc4 with my improvements:
> * STL independent code (all the containers are configured in
> * memory allocator independent code (all the allocations use specified
> * possibility to walk through the luabind internal structures (this
> enables us to see what stuff is actually exported to Lua via
> luabind. BTW I would like to add feature to add comments in the
> class/method/enum registration, since then we can provide "manual"
> on the exported stuff)
> * several fixed bugs
> I also would like to fix some bugs in the nearest future (if the class
> is exported with the wrapper and in the lua there are 2 classes who
> are inherited from it sequentially, then the second class virtual
> function call will be with the crash).
> I think the whole luabind community will be happy if there will be the
> moderator of the development process and if we decide what rules
> should be for the code which developer would like to submit. And it
> would be really cool for the rest of developers to present their ideas,
> since we could build luabind roadmap then and go through it (btw
> authors of luabind would be the best moderators, I suppose they have a
> free day in a month?)
> Yours respectfully,
> Dmitriy Iassenev, iassenev@...
> Phone (mobile): +380958392212
> ICQ: 72752187
> GSC Game World - Ukraine, Kyiv
> http://www.stalker-game.com, http://www.gsc-game.com
I would definitely like to see your fixes go into Luabind. Plus, you
seem familiar enough with the internals of the code to be able to help
interested parties who are not so familiar with that code to get up to
speed on it.
Ultimately, if the primary developers aren't willing or able to help a
community-led effort to improve Luabind, then we can fork the code. It's
licensed under MIT, so we can certainly take an SVN image and create a
new SourceForge project for it. Or a LuaForge one, depending on which we
feel is better (I prefer SourceForge since it's bigger, but I'm not
picky). I would rather that the primary developers stay involved, but if
they can't, then we shouldn't let this great piece of code die out.
As for the build system (that someone mentioned), I would say that it
needs to be made more friendly period. I suggest Premake, which is an
excellent tool for platform-neutral build systems. Plus, it's based on
Lua (it builds makefiles/Visual Studio projects/etc, so you still use
your normal tools), so we're all familiar with the language ;)
But as I mentioned, the first effort to getting a community driven
Luabind development to work is to document the internals as best we can.
It's very confusing code for someone, and open source development works
best when a programmer of average skill can walk into a codebase and fix
that one problem that's bugging him. Being able to understand what the
internals are doing is a first step towards that.
Fortunately, that Trac wiki still exists
(http://code.rasterbar.com/luabind) and you can still register to login
and access it. So we do, for the time being, have a centralized place to
document Luabind's internals.