wxlua-users — wxLua list for users and developers

Re: [Wxlua-users] wxLua Compiles and works in Linux

[John L. <jla...@gm...>]

> NOTE: where do we want to install wxLua libraries and headers on unix ?
> $PREFIX/lib and $PREFIX/include seem a nice place for me, but we can cons=
ider also
> $PREFIX/lib/wxlua and $PREFIX/include/wxlua, specially if our lua headers=
/libs could give
> problems to other builds of lua installed in the same prefix...

I guess we need to put them in $PREFIX/wxlua so the user just does -I
$PREFIX/wxlua in their Makefiles if they install it and or just -I
path/to/wxlua/modules if they didn't and it'll work both ways.

eg.
modules/lua/include/*.h
modules/wxbind/include/*.h
modules/wxlua/include/*.h
modules/wxluadebug/include/*.h
modules/wxluasocket/include/*.h

go to
$PREFIX/wxlua/include/*.h
$PREFIX/wxlua/wxbind/*.h
$PREFIX/wxlua/wxlua/*.h
$PREFIX/wxlua/wxluadebug/*.h
$PREFIX/wxlua/wxluasocket/*.h

I don't know about the libs, maybe we can give them the same naming
semantics as wxWidgets with our own version number so they won't
conflct with anyone and then just dump them into the $PREFIX/libs.

For example in modules/wxlua/src/Makefile

WXLIBBASE  =3D $(shell wx-config --basename)
WXRELEASE  =3D $(shell wx-config --release)

lib$(WXLIBBASE)_wxlua-$(WXRELEASE)
   =3D libwx_gtk2ud_wxlua-2.7.so.1.5.0

LIBVERSION_CURRENT=3D1
LIBVERSION_REVISION=3D5
LIBVERSION_AGE=3D0

Where the 1.5.0 are just currently arbitrarily defined in
modules/wxlua/src/Makefile. How can we define these to be available
for both the Makefiles and also the C++ code so we don't have to have
them defined over and over again?

> PS: I added wxLua link to wikipedia page for wxWidgets; I wonder if
> 1) we should move the page which is currently at http://www.luascript.the=
rsgb.net/ to
> http://wxlua.sourceforge.net
>   or
> 2) make a redirection from http://wxlua.sourceforge.net to http://www.lua=
script.thersgb.net/

Can we have it point to both? We need to make a release once we get it
to compile everywhere. Maybe in the next month.

-John

Re: [Wxlua-users] wxLua Compiles and works in Linux

[John L. <jla...@gm...>]

On 11/20/05, Francesco Montorsi <f18...@ya...> wrote:
> > The build system is not perfect yet; I'm trying to look what's wrong in
> > the bakefiles looking in your hand-written Makefile...
> I've found that both with your hand-written makefile and my bakefile I ge=
t these errors:
> ./../modules/wxbind/include/wxbind.h:64:30: error: wx/fl/controlbar.h: No=
 such file or
> directory
...
> when compiling modules/wxlua/src/internal.cpp; I understand that these ar=
e because I
> haven't compiled & installed FL from wxWidgets.
> However my bindings/wxwidgets/luasetup.h script says

Ok, so I just run configure in a sub dir of wxWidgets and don't
install it, so the includes in wxbind.h all exist in original
wxWidgets tree, but we should get this working for the case where you
install it too.

cd wxWidgets/config_gtk2
../configure \
--prefix=3D/home/john/wx/wxWidgets/wxCVS/wxWidgets/config_gtk2 \
--enable-optimise=3Dno \
...

> #define wxLUA_USE_FL 0
> but for some reason, internal.cpp includes luasetup.h.in:
> #include "../../../bindings/wxwidgets/luasetup.h.in" // get the base libr=
ary setup parameters
> which instead has a:
> #define wxLUA_USE_FL 1

I think the solution to making it possible to have multiple version of
the wxlua bindings for different projects lies in making the compiler
include luasetup.h for us.

In modules/wxbind/src/Makefile I've done this.

WXLUASETUP =3D luasetup.h
...
.cpp.o:
        $(CXX) -include $(WXLUASETUP) -c $(CXXFLAGS) $(APPEXTRADEFS)-o $@ $=
<

so when you run
$make WXLUASETUP=3D../path/to/your/luasetup.h
you can use your own luasetup.h file.

I couldn't find the equivalent for gcc's "-include" using nmake (MS's
compiler). Does anyone know if *all* compilers have this capability? I
assume yes?

If they all do, then we can remove all #include "luasetup.h" and add
this at the top of modules/wxbind/include/wxbind.h

#ifndef __WXLUA_SETUP__ // <-- set when luasetup.h is parsed
    #error "You must include luasetup.h on the command line for you compile=
r"

// In order to support multiple builds of the wxlua bindings, each
having different
//  bindings included, you must include the file "luasetup.h" on the
command line
//  when you compile. Please see docs/?? (not written)
// gmake : $make WXLUASETUP=3D../path/to/your/luasetup.h
// nmake : $nmake.exe -f makefile.vc ???
// and so on
#endif // __WXLUA_SETUP__

This should be pretty self explanitory. We could be less strict and
just #include a default luasetup.h, but people could get compile
errors and if they don't read the docs (not yet written) and get
frustrated.

We also need to do the same for the output library path and name, so
people can override them on the commandline or their own Makefiles for
their project.

See also wxbind/src/Makefile (these should be renamed to WXBIND_TARGET_LIB.=
..)
TARGET_LIBNAME =3D lib$(WXLIBBASE)_wxluabind-$(WXRELEASE)
TARGET_LIBDIR  =3D $(WXDIR)/lib

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

So... the one question remains, do all compilers support something
equivalent to gcc's "-include" directive? Also, can bakefile handle
this sort of thing?

Regards,
    John Labenski

Re: [Wxlua-users] wxLua Compiles and works in Linux

[Francesco M. <f18...@ya...>]

Hi,

> The build system is not perfect yet; I'm trying to look what's wrong in 
> the bakefiles looking in your hand-written Makefile...
I've found that both with your hand-written makefile and my bakefile I get these errors:
./../modules/wxbind/include/wxbind.h:64:30: error: wx/fl/controlbar.h: No such file or 
directory
./../modules/wxbind/include/wxbind.h:65:27: error: wx/fl/dyntbar.h: No such file or directory
./../modules/wxbind/include/wxbind.h:66:30: error: wx/fl/updatesmgr.h: No such file or 
directory
./../modules/wxbind/include/wxbind.h:67:30: error: wx/fl/hintanimpl.h: No such file or 
directory
./../modules/wxbind/include/wxbind.h:68:30: error: wx/fl/barhintspl.h: No such file or 
directory

when compiling modules/wxlua/src/internal.cpp; I understand that these are because I 
haven't compiled & installed FL from wxWidgets.
However my bindings/wxwidgets/luasetup.h script says

#define wxLUA_USE_FL 0

but for some reason, internal.cpp includes luasetup.h.in:

#include "../../../bindings/wxwidgets/luasetup.h.in" // get the base library setup parameters

which instead has a:

#define wxLUA_USE_FL 1

I'm not sure what should be done to fix the problem....

Francesco

Re: [Wxlua-users] wxLua Compiles and works in Linux

[Francesco M. <f18...@ya...>]

Hi,

John Labenski wrote:
> wxLua now compiles and works completely in Linux. All you need to do is
> $cd wxLua/apps/wxlua/src
> $make bindings # generate cpp files from .i files in modules/wxbind
> $make # compile EVERYTHING needed for wxLua
Good !
I've just updated the bakefile build system to be able to build wxLua also from unix.
Much of the stuff was borrowed from wxCode build system: that's allow us to support all 
types/configurations of wxWidgets builds on at least MSW, linux, MacOS.

The build system is not perfect yet; I'm trying to look what's wrong in the bakefiles 
looking in your hand-written Makefile...



> The "make bindings" will eventually become unnecessary since the
> bindings have all the appropropriate #ifdefs to compile on any
> platform and version of wxWidgets, but I'd like to test a little more.
ok


> The previous problem was with the lines
> %win %class wxMessageDialog, wxDialog FIXME THIS DOES NOT WORK CURRENTLY
> %gtk|%mac %class %noclassinfo wxMessageDialog, wxDialog
> ...
> in dialogs.i that caused a problem in generating the wrappers.
> 
> I will try my hand with the bakefiles and get it going in MSW in the
> next few days.
perfect; now that I'm basically a linux user, I can help easily to keep unix version 
tested; if you keep win32 build system tested, then everything should work at 100% ;)


> 
> **************************************
> 
> wxLua devs, I am going to switch to using the SF version of wxLua
> exclusively, so lets try to keep the CVS always in a working state
> (accidents and little oops aside, we're human after all). I don't mind
> if any changes are made, even if they're significant and not backwards
> compatible, just write to the list before committing any changes so
> we'll know how to update own own stuff. If no one responds in a couple
> days, just ensure that the wxLua sample app works completely,
> including the samples and assume that no one minds. Remember, nothing
> is set in stone since the user group of wxLua (at least from the c++
> end) is pretty small, I think the lua side should probably remain the
> same as much as possible.
I agree; only I need some time to get bakefile build system completely working.

NOTE: where do we want to install wxLua libraries and headers on unix ?
$PREFIX/lib and $PREFIX/include seem a nice place for me, but we can consider also 
$PREFIX/lib/wxlua and $PREFIX/include/wxlua, specially if our lua headers/libs could give 
problems to other builds of lua installed in the same prefix...

Francesco


PS: I added wxLua link to wikipedia page for wxWidgets; I wonder if
1) we should move the page which is currently at http://www.luascript.thersgb.net/ to 
http://wxlua.sourceforge.net
  or
2) make a redirection from http://wxlua.sourceforge.net to http://www.luascript.thersgb.net/

?

[Wxlua-users] wxLua Compiles and works in Linux

[John L. <jla...@gm...>]

wxLua now compiles and works completely in Linux. All you need to do is
$cd wxLua/apps/wxlua/src
$make bindings # generate cpp files from .i files in modules/wxbind
$make # compile EVERYTHING needed for wxLua

The "make bindings" will eventually become unnecessary since the
bindings have all the appropropriate #ifdefs to compile on any
platform and version of wxWidgets, but I'd like to test a little more.

The previous problem was with the lines
%win %class wxMessageDialog, wxDialog FIXME THIS DOES NOT WORK CURRENTLY
%gtk|%mac %class %noclassinfo wxMessageDialog, wxDialog
...
in dialogs.i that caused a problem in generating the wrappers.

I will try my hand with the bakefiles and get it going in MSW in the
next few days.

**************************************

wxLua devs, I am going to switch to using the SF version of wxLua
exclusively, so lets try to keep the CVS always in a working state
(accidents and little oops aside, we're human after all). I don't mind
if any changes are made, even if they're significant and not backwards
compatible, just write to the list before committing any changes so
we'll know how to update own own stuff. If no one responds in a couple
days, just ensure that the wxLua sample app works completely,
including the samples and assume that no one minds. Remember, nothing
is set in stone since the user group of wxLua (at least from the c++
end) is pretty small, I think the lua side should probably remain the
same as much as possible.

TODO:
1) Create wxLuaState with is a C++ wrapper around the C lua_State with
all the functions in internals.cpp as members. This will be a lower
level class than the wxLuaInterpreter which will be changed to have a
wxLuaState as a member and add the events and whatnot. The wxLuaState
will contain all the variables in wxLuaStateVariables (which will be
removed) and provide an easy way to do lookups for the state variables
from the lua_State. I think the wrappers can benefit from this
immensely as well as anybody using wxLua from C++.

2) Preface wxLua to everything in C++, for consistency and clarity.

3) We might as well try to take advantage of the wxPython docs (eg.
the little notes in the wxWidgets C++ docs stating how things are
different). This will make it easier for wxLua users to know all the
differences because we don't overload functions (though we could).
This can happen as you come across them and definitely for any newly
added classes.

For example in C++
wxWindow::ConvertPixelsToDialog
wxPoint ConvertPixelsToDialog(const wxPoint& pt)
wxSize ConvertPixelsToDialog(const wxSize& sz)

wxPython note: In place of a single overloaded method name, wxPython
implements the following methods:
ConvertDialogPointToPixels(point) Accepts and returns a wxPoint
ConvertDialogSizeToPixels(size) Accepts and returns a wxSize

4) Really get the debugging to work much better and get good
backtraces when "terror" is called in C.

5) I have some lua code that makes writing lua programs much easier,
string manipulation and whatnot. Pretty basic stuff, but I think it's
a huge timesaver. I'll add it somewhere and feel free to add your own.
We can have both lua code to do stuff and our own non-wxWidgets
bindings to make lua a little more powerful. You can use the program
bin2c.c or the bin2c.lua that I've just added to turn lua code into a
unsigned char array to be compiled.

**************************************

For a reference on what to compile and link to, look at
apps/wxlua/src/Makefile and Makefile_import.

Regards,
    John Labenski

ps. Sorry about taking so long to get the SF version of wxLua going.

Re: [Wxlua-users] CVS updated to work... sort of

[John L. <jla...@gm...>]

Ray, to hold us over for a bit, could you please take a look at the
current genwxbind.lua file. It doesn't seem to want to wrap
wxICON_QUESTION and some other %defines for some reason. I cannot seem
to figure out why and currently there's some debugging code in it to
show you what the problem is.

Look for the FIXME lines, you should be able to see that in the
function ParseData(interfaceData) the %define wxICON_QUESTION is
parsed (from dialogs.i), but mysteriously by the time it gets to
GenerateLuaLanguageBinding(interface) it's gone.  I've added a
function DumpTable and have tried to compare some of the %defines that
do work with those that don't, but I cannot see any difference.

I have changed the code slightly to not write directly to the files,
but rather to fill a table with the code and compare with the existing
file to save on compilation time, but the functions where the problem
seems to be should be pretty much the way you had them.

All you need to do is run genwxbind.lua in the bindings dir. You can
look at apps/wxlua/src/Makefile_import to see what the proper command
like would be for MSW or just run make -f Makefile_import directly in
linux. The output is put into modules/wxbind/src and the error.txt
file (where my debugging stuff is written) is in bindings/wxwidgets.

Just about everything works, execept for genwxbind missing some %defines.

Thanks,
    John Labenski

Re: [Wxlua-users] CVS updated to work... sort of

[John L. <jla...@gm...>]

On 11/17/05, Ray Gilbert <ray...@sc...> wrote:
> I am still working on generating a new set of interfaces directly from
> wx head cvs. I am making progress, but nothing stable yet.

Good. You had mentioned that these interface files are in XML, is that righ=
t?

> Trying to figure out the best way to handle issues involving base
> classes that vary according to implementation (e.g. using wxGeneric vs
> native)

Which classes give you a problem?

As an aside, but I'm guessing that this is kinda' along the same lines
as your problem, I've been wondering if I should ask on wx-dev if
wxWidgets should rename all the classes to follow something like this.

wxListCtrlBase (for example)
    msw wxListCtrlMSW
    gtk wxListCtrlGTK
    univ wxListCtrlUniv
    generic wxListCtrlGeneric (and GTK would be typedefed to this)
    etc...

and then using #defines typdef wxListCtrl to the appropriate class.
This way, in MSW for example, you could use wxListCtrlGeneric and
wxListCtrlMSW (the latter of which would be typedefed to just
wxListCtrl.

> wxLua tends to only create luac functions for prototypes in lua
> metatable, if not found it then goes to base class metatable.

This seems reasonable, if not the best way to do it.

> My current thought is simply merge all base class calls up to main class
> metatable and ignore base class redirection - thereby avoiding bad
> casts.

Maybe this could be worked around somehow with our own code, if there
aren't too many of them. Maybe add something like this to the
interface files, where we can add C++ to the generated files directly.

%verbatim (or %inline)
#if __WXGTK__
typedef wxXXXGeneric wxXXX
#elseif __WXMSW__
...
#endif
%endverbatum

-John Labenski

RE: [Wxlua-users] CVS updated to work... sort of

[Ray G. <ray...@sc...>]

I am still working on generating a new set of interfaces directly from
wx head cvs. I am making progress, but nothing stable yet.=20

Trying to figure out the best way to handle issues involving base
classes that vary according to implementation (e.g. using wxGeneric vs
native)

wxLua tends to only create luac functions for prototypes in lua
metatable, if not found it then goes to base class metatable.

My current thought is simply merge all base class calls up to main class
metatable and ignore base class redirection - thereby avoiding bad
casts.

This of coarse will be at the cost of code bloat.

Ray

-----Original Message-----
From: wxl...@li...
[mailto:wxl...@li...] On Behalf Of John
Labenski
Sent: Thursday, 17 November 2005 17:02
To: wxl...@li...
Subject: [Wxlua-users] CVS updated to work... sort of

I've fixed the handling of %if statements for enums and added the
bindings for "builtin" (global) functions like wxYield. I'm using
wxWidgets CVS head, but when I updated the interface files I looked at
the 2.6 headers, so it should work for that too. It compiles without
error in GCC 4, but still needs some work and the Makefiles need some
tweaking. If you want to try it use the Makefile in the apps/wxlua/src
dir, gcc in linux only.

Current bugs: (in Linux, wx27 CVS HEAD)

Segfaults if you run the wxLua sample directly and you can't get a
backtrace, this will probably be hard to figure out, but with some
luck...
$./wxLua
wxLua: Expected enum number for parameter 6.wxLua: Error while running
chunkwxLua: Error while running chunk

Runs if you do
$./wxLua ../../../samples/editor.wx.lua
wxLua: Error while running chunk
wxLua: Unexpected user defined data type for parameter 2.

Open the "grid" sample and then

The menu item "Run"
wxLua: Error while running chunk
../../../samples/editor.wx.lua:1645: attempt to call field `wxExecute'
(a nil value)
stack traceback:
        ../../../samples/editor.wx.lua:1645: in function
<../../../samples/editor.wx.lua:1635>

But if you do "Debug" and then "Continue" it does show and even works!

I'll try to clean it up a little more, fix these problems, and I think
we should be workable in just a short time.

-John Labenski


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id=16845&op=3Dick
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users

[Wxlua-users] CVS updated to work... sort of

[John L. <jla...@gm...>]

I've fixed the handling of %if statements for enums and added the
bindings for "builtin" (global) functions like wxYield. I'm using
wxWidgets CVS head, but when I updated the interface files I looked at
the 2.6 headers, so it should work for that too. It compiles without
error in GCC 4, but still needs some work and the Makefiles need some
tweaking. If you want to try it use the Makefile in the apps/wxlua/src
dir, gcc in linux only.

Current bugs: (in Linux, wx27 CVS HEAD)

Segfaults if you run the wxLua sample directly and you can't get a
backtrace, this will probably be hard to figure out, but with some
luck...
$./wxLua
wxLua: Expected enum number for parameter 6.wxLua: Error while running
chunkwxLua: Error while running chunk

Runs if you do
$./wxLua ../../../samples/editor.wx.lua
wxLua: Error while running chunk
wxLua: Unexpected user defined data type for parameter 2.

Open the "grid" sample and then

The menu item "Run"
wxLua: Error while running chunk
../../../samples/editor.wx.lua:1645: attempt to call field `wxExecute'
(a nil value)
stack traceback:
        ../../../samples/editor.wx.lua:1645: in function
<../../../samples/editor.wx.lua:1635>

But if you do "Debug" and then "Continue" it does show and even works!

I'll try to clean it up a little more, fix these problems, and I think
we should be workable in just a short time.

-John Labenski

Re: [Wxlua-users] compiling wxLua against wxWidgets 2.6, possible?

[John L. <jla...@gm...>]

> Just two short questions. Does the publicly available version wxLua 2.61
> compile with wxWidgets 2.6? Because the version number implies it.

The version at http://www.luascript.thersgb.net/ does I believe.

> What about the current CVS version? I saw that wxLuaWrap.lua does not han=
dle
> wxWidgets version numbers of 2.6 or higher.

I've started hacking away at it again (as of yesterday) and it almost
works. We're using genwxbind.lua now, but it doesn't handle %builtin
(eg. static functions) or %if conditions for enums. It's been slow
going, but I think I'm almost to the point where I understand it. I
hope to get it done in a few days, I don't want to commit what I've
done yet since it contains a lot of debugging stuff right now.

Regards,
    John Labenski

[Wxlua-users] compiling wxLua against wxWidgets 2.6, possible?

[Steffen I. <itt...@ph...>]

Hi there!

Just two short questions. Does the publicly available version wxLua 2.61
compile with wxWidgets 2.6? Because the version number implies it.

What about the current CVS version? I saw that wxLuaWrap.lua does not handle
wxWidgets version numbers of 2.6 or higher.

Thanks for answering my questions.

Steffenj

RE: [Wxlua-users] Is there anybody out there?

[Ray G. <ray...@sc...>]

Still here,

I have so little time to work on this, dealing with new babies and what
not. Generally, the only time I have is when commuting on train to work
:(

Parser project report:
Junked using *.i, instead have got an xml format. I have written the
code to use ctags and read the header files to create the xml file
directly from wx headers. I have got a wx_base.xml. This is easier to
load and interpret from code generator. I am currently reworking the
code generator to work with the xml file.

Ray

-----Original Message-----
From: wxl...@li...
[mailto:wxl...@li...] On Behalf Of Crow
Sent: Saturday, 1 October 2005 11:25
To: wxl...@li...
Subject: [Wxlua-users] Is there anybody out there?

The silence is deafening. :)


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users

Re: [Wxlua-users] Is there anybody out there?

[John L. <jla...@gm...>]

> >I'm still here waiting to complet the bakefile build system as soon as R=
ay as completed
> >the wxcode parser... ;)

I just started a new job in a new state and await my DSL, so I just
have sporadic use of the internet at work... Soonish I'll get back to
programming, near the end of this month.

-John Labenski

Re: [Wxlua-users] Is there anybody out there?

[Crow <xo...@bl...>]

Woah, life! >:) Good to hear. While most of the core details go over my head I try to folow at least a bit. I wreote something (DX7 sysex file editor) in wxLua, and I'm hoping other people discover wxLua and write stuff. Maybe as winter draws in, things will move on.

Actually I think something happened to the mailing list for a while, that questing mail of mine got sent to all just now, but came from me many days ago. Looks like something restarted somewhere.



Francesco Montorsi <f18...@ya...> wrote:
(02/10/2005 20:44)

>I'm still here waiting to complet the bakefile build system as soon as Ray as completed 
>the wxcode parser... ;)
>
>Francesco
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>Wxlua-users mailing list
>Wxl...@li...
>https://lists.sourceforge.net/lists/listinfo/wxlua-users

Re: [Wxlua-users] Is there anybody out there?

[Francesco M. <f18...@ya...>]

Crow wrote:
> The silence is deafening. :)
I'm still here waiting to complet the bakefile build system as soon as Ray as completed 
the wxcode parser... ;)

Francesco

[Wxlua-users] Is there anybody out there?

[Crow <xo...@bl...>]

The silence is deafening. :)

Re: [Wxlua-users] extending GLFW with wx / using wxlua as library in a c-project

[John L. <jla...@gm...>]

On 9/3/05, Eike Decker <ei...@cu...> wrote:
> Hi
> Thanks for the answer and positive feedback on a C compatible header.
> I am sorry that I haven't described the full "problem" in my last
> request, but I didn't thought it was necessary, but it seems to be more
> complicated than I thought (surprise surprise).

It always is... :(
=20
> The project I talked about is a 3D engine that can be extended by using
> lua and it looks currently quite nice
> (http://chilli.degnet.de/~e_decker/lux/index.php/Main/Screenshots -

Looks nice.

> website is under construction...). - anyhow: We are currently using GLFW
> as windowenvironment for OpenGL which replaced Glut (we want to be
> plattformindependent). Now, the idea about wx was, that we could use it
> to extend the engine with GUI elements for making editors, etc.

wxLua would be perfect for this, except for the problems...

> I have now tried out the loadlib function in lua to load the dll like thi=
s:
>  luaopen =3D loadlib("wxLua.dll", "wxLua")
>=20
> unfortunately, calling luaopen in lua itself crashs the application
> somewhere deeply in the dll and I can't debug this. Meanwhile I am also
> not sure anymore if it is really possible to extend the engine this way
> since we need our own mainloop. I guess that creating a new window using
> WX makes the engine crash since GLFW did this before - but it's only a
> guess, I haven't spend too much time on this window-stuff programming...

wxLua relies on the wxWidgets main loop and I don't think that this is
avoidable because of the required notification events.

Typically you create a wxApp instance that initializes the wxWidgets
main loop. (this is a good site for the wxWidgets docs)
http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin_wxappoverview.htm=
l#wxappoverview

However I have seen people handle initializing the mainloop their own way, =
see
http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin_wxapp.html#wxappm=
ainloop
Also search for IMPLEMENT_APP_NO_MAIN on google
http://lists.wxwidgets.org/archive/wx-users/msg33172.html

"To use your own "int main()" you'll need to use the
IMPLEMENT_APP_NO_MAIN() macro and use wxEntry. On the wiki there's a
topic about using wxWidgets in DLLs which is somewhat similar to
this."
http://wiki.wxwidgets.org/wiki.pl?Creating_A_DLL_Of_An_Application

** I have never tried to use DLLs nor anything like this so I can't be
of much help, but maybe the above will get you started and give you
some ideas.

> As a possibility, we could switch from GLFW to WX - but this would cause
> much more work on this (a little bit minor) problem than we wanted to spe=
nd.

Switching over to wxWidgets is an option, it'll add a lot of features,
some useful data structures, and whatnot, but might be a lot of work.

> Any creative ideas how to solve this problem without spending too much
> work in rewriting the C core of the engine?

As as aside, I don't want to start a war here, but C++ is perfect for
GUI libs because you can encapsulate the data for a window in a class
and use inheritance to reuse code. A button for example, has fore,
back colours, size, position and of course so would a generic window,
the button just adds a member for the label.

You can always compile C w/ C++ if you do this when including headers
extern "C"
{
    #include "cheader.h"
}

I don't know much about the loss in performance of compiling C code as
C++, but what what I've seen (Great computer language shootout IIRC)
it wasn't too significant.

Good luck,
    John Labenski

[Wxlua-users] extending GLFW with wx / using wxlua as library in a c-project

[Eike D. <ei...@cu...>]

Hi
Thanks for the answer and positive feedback on a C compatible header.
I am sorry that I haven't described the full "problem" in my last 
request, but I didn't thought it was necessary, but it seems to be more 
complicated than I thought (surprise surprise).

The project I talked about is a 3D engine that can be extended by using 
lua and it looks currently quite nice 
(http://chilli.degnet.de/~e_decker/lux/index.php/Main/Screenshots - 
website is under construction...). - anyhow: We are currently using GLFW 
as windowenvironment for OpenGL which replaced Glut (we want to be 
plattformindependent). Now, the idea about wx was, that we could use it 
to extend the engine with GUI elements for making editors, etc.

I have now tried out the loadlib function in lua to load the dll like this:
 luaopen = loadlib("wxLua.dll", "wxLua")

unfortunately, calling luaopen in lua itself crashs the application 
somewhere deeply in the dll and I can't debug this. Meanwhile I am also 
not sure anymore if it is really possible to extend the engine this way 
since we need our own mainloop. I guess that creating a new window using 
WX makes the engine crash since GLFW did this before - but it's only a 
guess, I haven't spend too much time on this window-stuff programming...

As a possibility, we could switch from GLFW to WX - but this would cause 
much more work on this (a little bit minor) problem than we wanted to spend.

Any creative ideas how to solve this problem without spending too much 
work in rewriting the C core of the engine?

Thanks in advance
Eike Decker

Re: [Wxlua-users] using wxlua as library in a c-project

[Francesco M. <f18...@ya...>]

Hi,

>>* I am using windows and mingw as compiler and make throws strange
>>errormessages if I run make (making lua was no problem that way):
>>
>>process_begin: CreateProcess((null), wx-config --basename, ...) failed.
>>process_begin: CreateProcess((null), wx-config --release, ...) failed.
>> ...
> 
> 
> These are looking for the 'wx-config' scripts, is it in your path?
> They should have been created by running configure in the wxWidgets
> root dir. I have never tried mingw, but I'm assuming it would be the
> same as using gcc in linux.
that's not so easy: wx-config cannot be used with mingw.
mingw's make is like any other win32 make and thus does not understand command 
substitution as unix makes do.

which makefile did you try ?
try to go in wxLua\build\msw and type

mingw32-make -fmakefile.gcc

Francesco

Re: [Wxlua-users] using wxlua as library in a c-project

[John L. <jla...@gm...>]

On 9/2/05, Eike Decker <ei...@cu...> wrote:
> Hi there
>=20
> I would like to include wxLua in a C project as a lib, offering an easy
> and simple way to create windows, buttons and so on, without switching
> to C++.
> Using wxLua looks like a simple solution here, since the few functions
> could be easily called from C and lua could take care about all that GUI
> stuff using wxWidgets once the application starts.

wxLua should fit the bill.

Try this version, there's a "Modules" directory that's for making a
DLL. I do not know if that's what your looking for, but maybe it's a
start. See below about the current status at SourceForge.
http://www.luascript.thersgb.net/
=20
> Unfortunatly, I am encountering some problems:
>=20
> * The current header is in c++ style (although it could be easily
> converted to a C-like form)

We could add a separate header for C, wxWidgets is a C++ library and
so wxLua, which uses many wxWidgets functions, is also C++.

> * I am using windows and mingw as compiler and make throws strange
> errormessages if I run make (making lua was no problem that way):
>=20
> process_begin: CreateProcess((null), wx-config --basename, ...) failed.
> process_begin: CreateProcess((null), wx-config --release, ...) failed.
>  ...

These are looking for the 'wx-config' scripts, is it in your path?
They should have been created by running configure in the wxWidgets
root dir. I have never tried mingw, but I'm assuming it would be the
same as using gcc in linux.

> I think I compiled the wxwidget library in a correct way (at least it did=
n't complain when I compiled it as DLL), but somehow I can't create a lib f=
rom wxLua.
>=20
> It would be really nice if someone knew what steps have to be done in my =
case (the website describes linux and windows using VC++). It would be even=
 better if some default libs could be downloaded for developers, including =
a C compatible header.

We'll have to wait for things to get stabilized before making a
release. Currently the CVS version on SF is broken. There are issues
with properly wrapping enums and static functions. A member is working
on completing a set of new wrappers, so fixing the current ones have
been put on hold until then. Hopefully we'll get it together soon.

Regards,
    John Labenski

[Wxlua-users] using wxlua as library in a c-project

[Eike D. <ei...@cu...>]

Hi there

I would like to include wxLua in a C project as a lib, offering an easy 
and simple way to create windows, buttons and so on, without switching 
to C++.
Using wxLua looks like a simple solution here, since the few functions 
could be easily called from C and lua could take care about all that GUI 
stuff using wxWidgets once the application starts.

Unfortunatly, I am encountering some problems:

* The current header is in c++ style (although it could be easily 
converted to a C-like form)
* I am using windows and mingw as compiler and make throws strange 
errormessages if I run make (making lua was no problem that way):

process_begin: CreateProcess((null), wx-config --basename, ...) failed.
process_begin: CreateProcess((null), wx-config --release, ...) failed.
 ...

I think I compiled the wxwidget library in a correct way (at least it didn't complain when I compiled it as DLL), but somehow I can't create a lib from wxLua.

It would be really nice if someone knew what steps have to be done in my case (the website describes linux and windows using VC++). It would be even better if some default libs could be downloaded for developers, including a C compatible header.

Thanks in advance

Eike Decker

Re: [Wxlua-users] DX7-EDIT. A wxLua program.

[Crow <xo...@bl...>]

John Labenski <jla...@gm...> wrote:
(19/08/2005 19:05)

>
>Looks very impressive, I'll check it out this weekend, does it even
>run if you don't have a Yamaha DX7 keyboard?
>

Yes. :) That's one of the cool things about it, you can work with SysEx files in the ansence of any hardware other than host machine for DX7-EDIT, but there's no substitute for using a synthesiser to get the full sense of why this might be truly useful. If you were ever thinking about getting an FM synthesizer, I'd suggest the FS1R, there is never likely to be a better one, unless someone starts where that left off. It's a small 1 unit rack, but it's not cheap or commonly found.

>One thing I noticed about the code though, you used absolute sizes for
>things. You may want to use wxSizers in case someone uses a different
>(larger) default font size. You can use wxGlade,
>http://wxglade.sourceforge.net/ , to get a good idea how sizers work
>by creating different things and looking at the output. It should be
>easy to translate it from either c++ or python to wxLua. I think you
>can even keep the code the same, just add the controls to the sizers
>you create at the end of each page. This will keep the code pretty
>clean.
>

I know.. I decided early on to do this though, for now. I wanted a very compact GUI. I thought that maybe sizers might cause some problems I can't even predict as easily as I can the effects of a large font in this thing, so I decided to let this go and see what kind of feedback I get, and once I see what sorts of problems happen, I'll test sizers and changes to fixed sizes too, to see what will work. So much of this thing started out with fixed sizes, the only thing to do, for now, was to be consistent. :)

Re: [Wxlua-users] DX7-EDIT. A wxLua program.

[John L. <jla...@gm...>]

On 8/19/05, Crow <xo...@bl...> wrote:
> DX7-Edit is a MIDI SysEx File for Yamaha 6 operator FM synthesisers, and =
for anything that can use the standard SysEx message format for either bank=
s or single voices.
>=20
> It's working, though no doubt capable of improvements, especially as it's=
 stretching the use of wxLua just a tad.. :) Also, I tend to make my own er=
ror tests and such, and I think Lua itself offers things in built-in functi=
ons, so I'll be optimising stuff there, once I'm ready to look deeply at th=
is thing again.

Looks very impressive, I'll check it out this weekend, does it even
run if you don't have a Yamaha DX7 keyboard?

One thing I noticed about the code though, you used absolute sizes for
things. You may want to use wxSizers in case someone uses a different
(larger) default font size. You can use wxGlade,
http://wxglade.sourceforge.net/ , to get a good idea how sizers work
by creating different things and looking at the output. It should be
easy to translate it from either c++ or python to wxLua. I think you
can even keep the code the same, just add the controls to the sizers
you create at the end of each page. This will keep the code pretty
clean.

Regards,
    John Labenski

[Wxlua-users] DX7-EDIT. A wxLua program.

[Crow <xo...@bl...>]

DX7-Edit is a MIDI SysEx File for Yamaha 6 operator FM synthesisers, and for anything that can use the standard SysEx message format for either banks or single voices.

It's working, though no doubt capable of improvements, especially as it's stretching the use of wxLua just a tad.. :) Also, I tend to make my own error tests and such, and I think Lua itself offers things in built-in functions, so I'll be optimising stuff there, once I'm ready to look deeply at this thing again.

Go here for a guide and some links:  http://www.lostgallifreyan.pwp.blueyonder.co.uk

Thanks John (Labenski), you've helped a lot with ideas and questions answered. I hope this thing stimulates a bit of action from other people using wxLua, and maybe stimulates someone able to make a MIDI library for wxLua, perhaps. I've posted access to DX7-EDIT on my oubliette of a LiveJournal too, so there might be some attention coming via that if it's read by anyone at all. :)

Other than that I'll leave it to Google to index the pages somehow, it is good at that, better than I am.

Re: [Wxlua-users] RegisterBindings later

[klaas.holwerda <kho...@xs...>]

Hi John,

Oke i will wait some more. I just had some time to work on it now :-(
And to bad, wxArt2D its bakefiles can not really be finished, since 
wxLua does not have them yet.  And Francesco liked to have wxLua done 
first, because that made think a bit simpler, which i agree. I am 
affraid there is nothing i can do.

But if Ray is still busy with it, i just wait. I hope he takes into 
account the ideas that came up here. And it would be nice to get some 
idea of what it is going to be.

I will keep the Cmake files that i have now in a save place, so i will 
have little effort to add them later on.

Just for the record.
I have to conclude that wxLua as it is in CVS is not working properly 
right now, at least i can't get it compiled (without correction), and if 
compiled wxLua standalone does not work for me.

Regards,

Klaas

John Labenski wrote:

>Klaas, I hope the waiting doesn't put you out too much, any lua code
>you write will still work so you can work on that using the older
>wxLua...
>  
>