Menu
▾
▴
wxlua-users
|
From: klaas.holwerda <kho...@xs...> - 2005-08-01 01:32:11
|
included from in internal.cpp Where is it? BTW i read the thread on binding with you and Francesco, i think i get it. There is no bindings library yet. It is all application specific. ( like in apps/wxlua ). Still a bit confused what is in the bakefiles on this wxbind sources. Klaas |
|
From: John L. <jla...@gm...> - 2005-08-01 03:27:18
|
On 7/31/05, klaas.holwerda <kho...@xs...> wrote:
> included from in internal.cpp
>=20
> Where is it?
see my other message, it's generated on the fly by running wxluawrap.lua.
=20
> BTW i read the thread on binding with you and Francesco, i think i get it=
.
> There is no bindings library yet.
> It is all application specific. ( like in apps/wxlua ).
Right.
> Still a bit confused what is in the bakefiles on this wxbind sources.
I don't know about the bakefiles, but just to clarify the reasoning I
think the only workable solution for having multiple versions of the
wrapper libraries is to make people compile them in their own project.
For example, the standalone wxlua ide should wrap everything, all the
wxLUA_USE_XXX are 1. However for using wxLua in your own project you
might want to turn some of them off. I will want to be able to compile
both of them without too much problem for debugging so I don't want to
have to compile the wrapper lib for the standalone program, have to
edit something and recompile it for an embedded program. You shouldn't
have to edit anything.
I hope this makes sense,
John Labenski
|
|
From: k. h. <kla...@nl...> - 2005-08-01 08:51:36
|
John Labenski wrote:
>On 7/31/05, klaas.holwerda <kho...@xs...> wrote:
>
>
>>included from in internal.cpp
>>
>>Where is it?
>>
>>
>
>see my other message, it's generated on the fly by running wxluawrap.lua.
>
>
But that is confusing, i mean i thought that ..../modules/wxlua would be
a library by itself.
But if it needs wxbind.h which is not yet generated??
I think we should have to a default binding library.
And if the user wants has own specific set, he can do so.
>I don't know about the bakefiles, but just to clarify the reasoning I
>think the only workable solution for having multiple versions of the
>wrapper libraries is to make people compile them in their own project.
>
>
Right now that is true, but if we change wxLuaWrap.lua here and there,
we can have several wrapper trees ( one for the wxLua and one for a
thirdparty lib (e.g. wxArt2DLua) and one for the user app ).
More imported several generated Cpp files, one for each tree. The idea
was to generate a sort of namespace for the each tree.
So have a table of the next and not just one:
WXLUACLASS *GetClassList(size_t &count)
{
static WXLUACLASS ClassList[] =
{
I once looked at that, but stopped when the ctags came about.
I wonder if the *.i files will stay even if using ctags approach or
whatever way of generating the *.i files?
If the *.i files will go, and there will be a speration in bindings
libraries anyway, i will not spend time on the above.
>For example, the standalone wxlua ide should wrap everything, all the
>wxLUA_USE_XXX are 1.
>
Right, this i see a s a default binding library.
> However for using wxLua in your own project you
>might want to turn some of them off.
>
I can understand, it would be ideal if this can be done at runtime?
If not there is only one solution, one has to switch them off, and
recompile the library.
If this is inclusive the user wrappers/bindings, is for me just a matter
of organizing things.
> I will want to be able to compile
>both of them without too much problem for debugging so I don't want to
>have to compile the wrapper lib for the standalone program, have to
>edit something and recompile it for an embedded program.
>
To this is only possible, if that is done at runtime.
Else you will have to compile a library of the standalone, and another
for the user app containing less bindings.
Do i miss something?
Still it is of course a could thing to be able to use several luasetup.h
files.
So when i see in internal.cpp a line like this, i am lost ;-)
#include "../../../bindings/wxwidgets/luasetup.h.in" // get the base
library
It says include a file, which normally is meant to be configured??
It seems wxluawrap.lua is doing that step, but still internal.cpp
includes all.
Is that because it will be always a subset?
> You shouldn't
>have to edit anything.
>
>
Do you mean that for the moment having several luasetup.in files, one
leading to one libary another to another library would be oke?
This is the situation i had sofar in wxArt2D, several luasetup.h.in
files, which are configured to the build tree as several luasetup.h
files. But now i realize that the luasetup.h is never used, it is
generated by wxluawrap.lua from luasetup.h.in too.
Where is the generated luasetup.h meant for?
>I hope this makes sense,
>
>
>
Not all ;-)
But with your help i might be able to understand what is the current
situation, and next think about what we really want and how.
To me it is clear that when one wants to disable functionality of a
default distributed wxLua library, this can only de done at run time.
Which to me would not be a problem, since i never bother about size.
Next to this we can of course make a system that generates based on an
application luasetup.h, a new set of cpp files ( seperated by wxlua,
thridparty, userapp based on some sort of namespace in that setup.h file.)
This would than lead to a new wxLua_userapp library, meant only for that
application, and does contain only code that was meant to be used by the
application.
One thing for sure, we need to aim for a speration in *.cpp files
containing wrapping code. Currently adding one extra lua command to my
app, takes long compilation time, and therefore is bad in a debug cylce.
What do you think, or do you have something else in mind.
Thanks,
Klaas
Unclassified
|
|
From: John L. <jla...@gm...> - 2005-08-01 18:31:37
|
On 8/1/05, k. holwerda <kla...@nl...> wrote:
> But that is confusing, i mean i thought that ..../modules/wxlua would be
> a library by itself.
> But if it needs wxbind.h which is not yet generated??
Yes the code can be pregenerated, but lets not put it into CVS until
we're happy with it since it's easy to generate on the fly. We can
remove the dependence on wxbind.h eventually, see below.
> Right now that is true, but if we change wxLuaWrap.lua here and there,
> we can have several wrapper trees ( one for the wxLua and one for a
> thirdparty lib (e.g. wxArt2DLua) and one for the user app ).
> More imported several generated Cpp files, one for each tree. The idea
> was to generate a sort of namespace for the each tree.
That is the idea, we can make wxluawrap.lua generate bindings for any
given set of .i files.
=20
> So have a table of the next and not just one:
> WXLUACLASS *GetClassList(size_t &count)
> {
> static WXLUACLASS ClassList[] =3D
> {
I think that in order to make all the bindings independent we should
use a class with static members. Change wxLuaBinding to something like
this
class wxLuaBinding
{
wxLuaBinding() {}
static size_t GetBindingCount() { return ms_nameSpaceArray.GetCount();=
}
static wxString GetNameSpace(size_t n) { return ms_nameSpaceArray[n]; =
}
static WXLUACLASS* GetClasses(size_t n) { return
(WXLUACLASS*)ms_classArray[n]; }
static WXLUAEVENT* GetEvents(size_t n) { return
(WXLUAEVENT*)ms_eventArray[n];
...
=20
// all arrays are the SAME size even if they have NULL pointers
static wxArrayString ms_nameSpaceArray;
static wxArrayPtrVoid ms_classArray;
static wxArrayInt ms_classCountArray;
static wxArrayPtrVoid ms_eventArray;
static wxArrayInt ms_eventCountArray;
static wxArrayPtrVoid ms_defineArray;
static wxArrayInt ms_defineCountArray;
...
}
in the cpp wrapper files for wxWidgets (or your binding) have this
class wxLuaBinding_wx : public wxLuaWrappers
{
wxLuaBinding_wx(void* classes, int class_count, void* events,
int event_count, void* defines, int define_count)
{
ms_nameSpaceArray.Add(wxT("wx"));
ms_classArray.Add(classes);
ms_classCountArray.Add(class_count);
ms_eventArray.Add(events);
ms_eventCountArray.Add(event_count);
ms_defineArray.Add(defines);
ms_defineCountArray.Add(define_count);
}
}
// now add them by creating a dummy instance of the class who's only
purpose is to add the structs to the arrays. this way no special
functions have to be called.
wxLuaBinding_wx dummy_instance(just use the structs themselves here
and the WXSIZEOF them);
Now from *anywhere* in your program (probably only used internally
though) you just call this (with appropriate checks first).
wxLuaBinding::GetClasses(index of wrapper)[index into classes].whatever;
=20
Now the wrappers are completely independent and are added at your
program's startup depending on what you linked to. If you don't link
to any, it's just as well since the arrays will be empty and you get
no wrappers. There's no special functions to know the names of ahead
of time and everything is created on the fly depending on what you
link to. You just have to make sure that you get the link order right,
link to wxlua before any bindings.
This is trivial to implement, but is a fairly big change to
wxluawrap.lua and internals.h/cpp, so I was waiting for Ray so we
wouldn't have two different wxluawrap.lua files that had to be merged
again...
> I once looked at that, but stopped when the ctags came about.
> I wonder if the *.i files will stay even if using ctags approach or
> whatever way of generating the *.i files?
> If the *.i files will go, and there will be a speration in bindings
> libraries anyway, i will not spend time on the above.
No the .i files will probably stay since the generator will be used
for your own wrappers and it should work to recreate it's own wrappers
as a test.
> To this is only possible, if that is done at runtime.
> Else you will have to compile a library of the standalone, and another
> for the user app containing less bindings.
> Do i miss something?
>
> Still it is of course a could thing to be able to use several luasetup.h
> files.
This is exactly what I was thinking, you copy the makefile (buildfile)
from the wxbind dir into your program's dir, change paths accordingly
and then run it. Now you've generated your own library of wxLua's
wxwidgets bindings specificly for your program's needs. I can think of
no other way.
=20
> So when i see in internal.cpp a line like this, i am lost ;-)
>=20
> #include "../../../bindings/wxwidgets/luasetup.h.in" // get the base
> library
>=20
> It says include a file, which normally is meant to be configured??
> It seems wxluawrap.lua is doing that step, but still internal.cpp
> includes all.
> Is that because it will be always a subset?
That was a hack I believe, using the above static functions in
wxLuaBinding we should be able to remove that include as well as the
include for wxbind.h since we will get all the info we need from the
static functions in wxLuaBinding. In fact there will be NO public
header for the wrapper libs as any information about them is set
internaly through wxLuaBinding.
Does this make more sense, even though we probably shouldn't do it yet
(until we know if there are better wrappers or now)... this is how I
envision it will work.
John Labenski
|
|
From: klaas.holwerda <kho...@xs...> - 2005-08-01 22:14:53
|
John Labenski wrote: >Does this make more sense, even though we probably shouldn't do it yet >(until we know if there are better wrappers or now)... this is how I >envision it will work. > > I do understand more or less what you write. But i do not understand why the wxLuaBinding i see now, is not good enough, which i think is the case from what you have in mind. Don't get me wrong, i do not critisize :-), just don't understand. e.g. i see in wxbind.h class wx_binding and next bool bind_wx( .. ) Where did this wxLuaBinding class come from, it is not in my wxArt2D version, so i assume Ray or you made it? What is the current system capable of? Or where is it not good enough, i don't have a clue :-(? How does your idea differ from what is there now? Sorry John this is all new to me, so i have to study a bit more, to be able to answer if i understand or not. But if you can tell me a bit more on what is there, i think i will get it quicker ;-) Thanks, Klaas |
|
From: John L. <jla...@gm...> - 2005-08-01 23:04:47
|
On 8/1/05, klaas.holwerda <kho...@xs...> wrote:
> I do understand more or less what you write. But i do not understand why
> the wxLuaBinding i see now, is not good enough, which i think is the
> case from what you have in mind. Don't get me wrong, i do not critisize
> :-), just don't understand.
> e.g. i see in wxbind.h
> class wx_binding
>=20
> Where did this wxLuaBinding class come from, it is not in my wxArt2D
> version, so i assume Ray or you made it?
Ray did, it's in modules/wxlua/include/internal.h and src/internal.cpp.
The only problem is that in internal.cpp you have to know the name of
the binding class in order to call it. This means that you can't
compile without it. It also makes the #include "wxbind.h" necessary. I
was just thinking out loud about how to dynamicly create a list of
bindings and use the string namespace to differentiate between them.
Now that I check it out a little more, it'd be much easier to to just have =
a=20
static wxArrayString wxLuaBinding::ms_arrayBindingClassNames;
every subclassed binding just adds it's own classname once to the
binding list. Now that you know the class names of the bindings, each
wxLuaStateVariables can create and add them to the m_bindings list by
running
wxObject * wxCreateDynamicObject(const wxString& className)
All you need to have is that each subclassed wxLuaBinding class have
DECLARE/IMPLEMENT_DYNAMIC_CLASS. Again, maybe this isn't perfect or
even a good idea, I'm just thinking about how people can most simply
add their own wrappers without having to modify anything in wxlua.
As you can see, I really haven't played with the current system that
much since I don't know how they'll change. I won't commit anything
without consulting others, I just wanted to throw the idea out there.
Regards,
John Labenski
|
|
From: k. h. <kla...@nl...> - 2005-08-02 11:33:41
|
Hi,
John Labenski wrote:
>The only problem is that in internal.cpp you have to know the name of
>the binding class in order to call it. This means that you can't
>compile without it.
>
See my lattest thread. I think that this binding is added to early,
maybe someone does not even want that wx binding.
wxLuaStateVariables::wxLuaStateVariables()
{
.....................
m_bindings.Append(new wx_Binding());
}
> It also makes the #include "wxbind.h" necessary.
>
Not if removed there, and added at e.g. wxLuaInterpreter level or even
wx(LuaStandalone)App level.
Using the function bind_wx( m_luaState ).
This is all fine if the statevars->RegisterBindings(m_luaState, true)
is done a bit later.
>I
>was just thinking out loud about how to dynamicly create a list of
>bindings and use the string namespace to differentiate between them.
>
>
Right, which i think is already possible??
>Now that I check it out a little more, it'd be much easier to to just have a
>static wxArrayString wxLuaBinding::ms_arrayBindingClassNames;
>every subclassed binding just adds it's own classname once to the
>binding list. Now that you know the class names of the bindings, each
>wxLuaStateVariables can create and add them to the m_bindings list by
>running
>
>wxObject * wxCreateDynamicObject(const wxString& className)
>
>
Sure this is indeed better then a string, since at least all bindings
classes will be unique.
I use this trick all over wxArt2D, works nice. e.g. i load xml from a
file and create the objects in it like this.
> I'm just thinking about how people can most simply
>add their own wrappers without having to modify anything in wxlua.
>
>
This is already the case now i think, what do you think they need to
add/change?
>As you can see, I really haven't played with the current system that
>much since I don't know how they'll change. I won't commit anything
>without consulting others, I just wanted to throw the idea out there.
>
>
I think at least that it is better to use the classname of the binding
class to test if it is there or not.
So as you suggest above.
Regards,
Klaas
Unclassified
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X