luabind

James Porter 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.
>
> On a related note, I did find some messages in the archives discussing a 
> switch to Trac for Luabind, which apparently is the preferred project 
> manager (it even has a Wiki!): http://code.rasterbar.com/luabind
>
> Does anyone have any thoughts about getting Luabind back into "active" 
> development?
>
> - James
>   
Not really.

The current developers, as they themselves have stated, are too busy to 
adequately maintain Luabind. And yet, they tend to be rather... stingy 
with regard to information about Luabind's internals. And template 
metaprogramming code, particularly in the standard C++ style, can be 
incredibly obtuse. It would take an extraordinary person to sift through 
Luabind's code and learn enough to be able to maintain it. 
Unfortunately, no such person has come along.

If there were just a good guide as to how all of this works, and why it 
is done in a certain way, then other developers could jump in and take 
responsibility for portions of the code.

Jason McKesson wrote:
> The current developers, as they themselves have stated, are too busy to 
> adequately maintain Luabind. And yet, they tend to be rather... stingy 
> with regard to information about Luabind's internals. And template 
> metaprogramming code, particularly in the standard C++ style, can be 
> incredibly obtuse. It would take an extraordinary person to sift through 
> Luabind's code and learn enough to be able to maintain it. 
> Unfortunately, no such person has come along.
> 
> If there were just a good guide as to how all of this works, and why it 
> is done in a certain way, then other developers could jump in and take 
> responsibility for portions of the code.

I suppose I could write up what I know of the Luabind internals. I don't 
think I know enough to, say, build Luabind from scratch, but I think 
I've got a broad understanding of what goes on under the hood. I've been 
modifying the Luabind code bit by bit over the last several months. Even 
just some basic notes might help.

I haven't done anything TOO extensive, but I've overhauled the exception 
handling scheme (this required a small patch to Lua itself though), and 
added a couple general- and special-purpose function policies, as well 
as miscellaneous bugfixes.

There's also the Boost Language Binding newsgroup, which I confess I 
haven't actually looked at in any depth, though it does explicitly state 
that Luabind is a discussion topic:

http://www.boost.org/more/mailing_lists.htm#langbinding

- James

I am willing to help out in any way that I can. I tried to get people 
interested in reviving Luabind a few months ago and we actually did make 
some noticeable improvements (particularly, wiki entries in trac). I 
can't spend much time doing development but I am willing to do testing 
and perhaps creating a better build setup for *nix systems. And yeah I 
agree, the original dev's were a bit stingy when we last brought this up 
and almost seemed opposed to having external people come in and work on 
development IIRC. But they can't have it both ways; you can't maintain 
an iron grip over a project's development unless you continue to 
actively develop it.


I think the best thing to do is to grant SVN access to the people who 
are capable of making improvements in Luabind, and seeing what happens. 
If for some reason the code goes all to hell, hey that's what SVN is for 
and we can rollback if necessary. But I too am very anxious for a Lua 
5.1 compatible release, because Luabind is holding my own project back 
on Lua 5.0 and of all the dozen or so libraries we used, Luabind was the 
one we had the most difficulties with supporting our last release (June 
2007).


- Tyler

James Porter wrote:
> Jason McKesson wrote:
>   
>> The current developers, as they themselves have stated, are too busy to 
>> adequately maintain Luabind. And yet, they tend to be rather... stingy 
>> with regard to information about Luabind's internals. And template 
>> metaprogramming code, particularly in the standard C++ style, can be 
>> incredibly obtuse. It would take an extraordinary person to sift through 
>> Luabind's code and learn enough to be able to maintain it. 
>> Unfortunately, no such person has come along.
>>
>> If there were just a good guide as to how all of this works, and why it 
>> is done in a certain way, then other developers could jump in and take 
>> responsibility for portions of the code.
>>     
>
> I suppose I could write up what I know of the Luabind internals. I don't 
> think I know enough to, say, build Luabind from scratch, but I think 
> I've got a broad understanding of what goes on under the hood. I've been 
> modifying the Luabind code bit by bit over the last several months. Even 
> just some basic notes might help.
>
> I haven't done anything TOO extensive, but I've overhauled the exception 
> handling scheme (this required a small patch to Lua itself though), and 
> added a couple general- and special-purpose function policies, as well 
> as miscellaneous bugfixes.
>
> There's also the Boost Language Binding newsgroup, which I confess I 
> haven't actually looked at in any depth, though it does explicitly state 
> that Luabind is a discussion topic:
>
> http://www.boost.org/more/mailing_lists.htm#langbinding
>
> - James
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> luabind-user mailing list
> luabind-user@...
> https://lists.sourceforge.net/lists/listinfo/luabind-user
>

> 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
  config.hpp)
* memory allocator independent code (all the allocations use specified
  allocator)
* 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

James,

I'd love to see more activity, too. I'm using Luabind in two projects and
it's used a lot. While I made only very minor modifications to the Luabind
sources (mainly due to compatibility and some obvious shortcomings, imho)
I use a lot of its features and would be able to make some time to
test-drive in-development versions with our codebase.

Stephan

On Do, 25.10.2007, 03:32, James Porter 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.
>
> On a related note, I did find some messages in the archives discussing a
> switch to Trac for Luabind, which apparently is the preferred project
> manager (it even has a Wiki!): http://code.rasterbar.com/luabind
>
> Does anyone have any thoughts about getting Luabind back into "active"
> development?
>
> - James
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> luabind-user mailing list
> luabind-user@...
> https://lists.sourceforge.net/lists/listinfo/luabind-user
>

It seems like pretty much everyone is on the same page with this, so 
assuming the original developers get on board too, we should be set. 
Whether or not they're actually willing is another thing entirely, but 
there's always the (not very desirable) option of forking the project.

I'm not sure if the original developers actually monitor this list, or 
if it would be better to contact them directly. Any ideas?

- James

Stephan Kaiser wrote:
> James,
> 
> I'd love to see more activity, too. I'm using Luabind in two projects and
> it's used a lot. While I made only very minor modifications to the Luabind
> sources (mainly due to compatibility and some obvious shortcomings, imho)
> I use a lot of its features and would be able to make some time to
> test-drive in-development versions with our codebase.
> 
> Stephan

"James Porter" wrote:

> There's also the Boost Language Binding newsgroup, which I confess I
> haven't actually looked at in any depth, though it does explicitly state
> that Luabind is a discussion topic:
>
> http://www.boost.org/more/mailing_lists.htm#langbinding
>

Boost.Langbinding was an attempt to create common infrastructure
on which already existing Boost.Python, Luabind could be based
and new libraries could be build.

It is dormant for few years and, AFAIK, didn't release any files.

/Pavel

Pavel Vozenilek wrote:
> "James Porter" wrote:
> 
>> There's also the Boost Language Binding newsgroup, which I confess I
>> haven't actually looked at in any depth, though it does explicitly state
>> that Luabind is a discussion topic:
>>
>> http://www.boost.org/more/mailing_lists.htm#langbinding
>>
> 
> Boost.Langbinding was an attempt to create common infrastructure
> on which already existing Boost.Python, Luabind could be based
> and new libraries could be build.
> 
> It is dormant for few years and, AFAIK, didn't release any files.

In the recent past I started putting together a brief design and 
development plan in preparation for getting funding to continue that 
development <http://svn.boost.org/trac/boost/wiki/Langbinding>. 
Unfortunately I never got Dave and Daniel to document the existing code 
sufficiently for me to figure out what needed to get done. And now it's 
not just them who are busy, but I'm also way busy. Strange part is that 
this Winter I'll need to use Luabind for my own project, so perhaps I'll 
have to branch and take my changes to the Boost sandbox.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

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
>   config.hpp)
> * memory allocator independent code (all the allocations use specified
>   allocator)
> * 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.

I'm pretty sure Luabind requires all variable types to be registered 
with it before binding them to Lua. You may have to bind TestFunc using 
plain Lua.

- James

framebuffer wrote:
> Hello,
> 
> I have a C++ function that takes a generic pointer void *pData as a
> parameter.
> 
> void TestFunc(void *pData);
> 
> When I call the function from lua like TestFunc(0) I get the following
> error:
[snip]

Looks like you found a bug! The return statement for two-variable calls 
to luabind::object::operator() is wrong. It's supposed to return an 
object of type

   call_proxy<Derived,boost::tuples::tuple<A0 const*, A1 const*> >

but instead returns an object of type

   call_proxy<object,boost::tuples::tuple<A0 const*, A1 const*> >

The offending text is on line 301 of object.hpp, at least in my copy of 
the source.

- James

framebuffer wrote:
> Hello, I have a lua script as follows:
> 
[snip]
> Also, passing no parameters obviously works fine
> StateAcON["Execute"] = function()
> (*pStates)["Execute"]();
> 
> Does luabind allows us to send two parameters to functions? or do I have to
> wrap them in a structure?
> 
> I am using the latest luabind trunk with lua 5.1.2, boost 1.34
> 
> Thanks for the help.
> fb.

Thanks you James, your solution worked like a charm!


James Porter-2 wrote:
> 
> Looks like you found a bug! The return statement for two-variable calls 
> to luabind::object::operator() is wrong. It's supposed to return an 
> object of type
> 
>    call_proxy<Derived,boost::tuples::tuple<A0 const*, A1 const*> >
> 
> but instead returns an object of type
> 
>    call_proxy<object,boost::tuples::tuple<A0 const*, A1 const*> >
> 
> The offending text is on line 301 of object.hpp, at least in my copy of 
> the source.
> 
> - James
> 
> framebuffer wrote:
>> Hello, I have a lua script as follows:
>> 
> [snip]
>> Also, passing no parameters obviously works fine
>> StateAcON["Execute"] = function()
>> (*pStates)["Execute"]();
>> 
>> Does luabind allows us to send two parameters to functions? or do I have
>> to
>> wrap them in a structure?
>> 
>> I am using the latest luabind trunk with lua 5.1.2, boost 1.34
>> 
>> Thanks for the help.
>> fb.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> luabind-user mailing list
> luabind-user@...
> https://lists.sourceforge.net/lists/listinfo/luabind-user
> 
> 

-- 
View this message in context: http://www.nabble.com/Passing-more-than-one-parameters-to-a-function-in-a-table-tf4634416.html#a13310216
Sent from the Lua C++ Bind mailing list archive at Nabble.com.