wxlua-users Mailing List for wxLua (Page 4)

klaas.holwerda ha scritto:
> Francesco Montorsi wrote:
>> Hi,
>>   before I forget this - what about subscribing wxLua project at 
>> LuaForge and then disable all services and use as homepage wxlua.sf.net ?
> I think that is a good idea, it is only for subscribing right, not 
> really move all?
right - just to make wxLua more visible ;)

Francesco

Hi,

I am not quite sure that this is bug in wxLua or wxWidgets  or I am doing something wrong. Maybe it is in wxWidgets (I think).

The problem is the XRC can not load a panel ; .

To illustrate, I have a very simple xrc  like this:

<?xml version="1.0" encoding="UTF-8"?>
<resource version="2.3.0.1" xmlns="http://www.wxwidgets.org/wxxrc">
    <object class="wxFrame" name="ID_FRAME" subclass="t">
        <style>wxCAPTION|wxRESIZE_BORDER|wxSYSTEM_MENU|wxCLOSE_BOX</style>
        <size>400,300</size>
        <title>t</title>
        <object class="wxPanel" name="ID_PANEL">
            <style>wxSUNKEN_BORDER|wxTAB_TRAVERSAL</style>
        </object>
    </object>
</resource>

suppose the xrc file name below is correct (the above one)
lua script:

local frame=nil
res = wx.wxXmlResourceGetDefault()
res:InitAllHandlers()
local xrcFilename = "./test.xrc" 
res:Load(xrcFilename)
frame = wx.wxFrame(wx.wxNull, wx.wxID_ANY, "My Frame")

res:LoadFrame(frame, wx.wxNull, "ID_FRAME")
local myPanel=wx.wxPanel(wx.wxNull, wx.wxID_ANY)
res:LoadPanelCreate(myPanel, frame, "ID_PANEL" )

If you run this script wxlua report error:

XRC resource 'ID_PANEL' (class 'wxPanel') not found
As you see in xrc file ID_PANEL is the panel, why not find it?

Viewing examples of wxwidgets and wxlua dealing with XRC, it seems that everybody use dialog instead of frame + panel, so maybe no one got that problem so far. 

Any comment?
Cheers,





S.KIEU
		
---------------------------------
On Yahoo!7 
  360°:  Your own space to share what you want with who you want!

* wxWidgets 2.6.3 Patch 2 compiled as multi DLL lib non-unicode
  * wxLua 2.6.2.0 using DLL Debug Multilib
  * WindowsXP
  *.NET 2003 (VC++ 7.1)
     =20
   Just downloaded wxLua and was trying to build it using wxLua.dsw project=
 from msw folder and I got allot of warnings and errors. Project mod_lua_li=
b compiles cleanly but when it gets to mod_wxluadebug I get this:
   =20
   \  wxLua\  modules\  wxluadebug\  src\  staktree.cpp(110) : warning C427=
3: 'ms_classInfo' : inconsistent dll linkage
   \  wxLua\  modules\  wxluadebug\  src\  staktree.cpp(110) : error C2491:=
 'wxLuaStackDialog::ms_classInfo' : definition of dllimport static data mem=
ber not allowed
   \  wxLua\  modules\  wxluadebug\  src\  staktree.cpp(110) : warning C427=
3: 'wxLuaStackDialog::GetClassInfo' : inconsistent dll linkage
   \  wxLua\  modules\  wxluadebug\  src\  staktree.cpp(112) : warning C427=
3: 'sm_eventTable' : inconsistent dll linkage
  =E2=80=A6
  And many more, which I will skip it for now, since it=E2=80=99s basically=
 the same. I hope I=E2=80=99m missing something very simple here.
   =20
   -Edgar
  =20

Francesco Montorsi wrote:
> Hi,
>   before I forget this - what about subscribing wxLua project at 
> LuaForge and then disable all services and use as homepage wxlua.sf.net ?
I think that is a good idea, it is only for subscribing right, not 
really move all?

Klaas

Hi,
   I did various changes and now using SHARED=1 option wxLua compiles 
smoothly as a dll also on windows.

Nonetheless, there are two problems:

1) the wx.dll which is created by MSVC, generates the following error 
when used through luamodule.wx.lua sample:

"Cannot find a required procedure"

(the message is localized so I'm translating it)... maybe that's because 
wx.dll is a dll which in reality does not contain any code apart from 
wxLua\modules\luamodule\src\luamodule.cpp (it's just 34K IIRC) ?
Nonetheless it should force lua to import all other DLLs from which it 
depends (wxlua* and wx* ones)...

Unfortunately I've upgraded to latest Mingw which gives an internal 
error when compiling wx_bind.cpp and borland is giving me strange errors 
about wxLUA_DECLARE_ENCAPSULATION so I can't verify if this happens also 
with other win32 compilers...


2) setting the #define wxLuaDebugServer to 1 in wxluasetup.h generates a 
dependency of wxbind module to the wxluasocket (and thus also to 
wxluadebug) module. Is this a good thing to do ?
Shouldn't we keep all wxLuaDebugServer stuff in the wxluasocket module?


Thanks,
Francesco

Hi,
   before I forget this - what about subscribing wxLua project at 
LuaForge and then disable all services and use as homepage wxlua.sf.net ?

This way wxLua would be more easily discovered by lua developers...

Francesco

John Labenski ha scritto:
>> > -> all DLLs/.so of wxLua/lib if they built wxLua as a shared library
>> > (SHARED=1)
>> > -> wx.so/.dll if they built wxLua as a static library (SHARED=0).
>> >    In fact, wx.so/.dll should be built regardless of the SHARED option
>> > value: when SHARED==1, it will just be a super-small file which tells
>> > the OS to load the other .so/.dll libraries; when SHARED==0, it will be
>> > a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.
>> >
>> > What do you think ?
as a reply to my own thought - it's wrong: luamodule should never be 
built when SHARED==0. In fact, as written at 
http://lua-users.org/wiki/BuildingModules, our wx.dll/.so would embed in 
that case a duplicated copy of lua core, which must be avoided.
Thus I'll set luamodule buildable only when SHARED==1


> Sounds good, would this account for the possibility of someone getting
> the wxWidgets2.6.3.rpm so they have their .so files and build wxLua
> (or someday we provide our own rpm that depends on the wxWidgets rpm)
> then we'd just want our .so libs to link to the rpm's libs. Or is this
> way too much to ask.
This is definitevely possible and is the whole sense of building shared 
libraries. On Unix it already works (I'm using wxLua shared libs against 
Ubuntu's shared build of wxGTK 2.6.1).


> >> Trying to get wx.dll working on Win32, too, I've found a lot of problems
>> in building the DLLs of wxLua.
>>
>> In particular, it looks like the different modules need somehow stuff
>> which is in other modules to link so that I ended up to compile first
>> all files and then link them all together in a single monolithic DLL
>> library.
> 
> It should be all top down from wxLuaSocket->wxLuaDebug->wxLua, no deps
> the other way around.
Well, looking at docs/install.html and to current Makefiles (which I'm 
sure they work on linux), the link order is:

wxlua, [wxbindstc, ] wxbind, wxluasocket, wxluadebug, lua

where library X depends from libraries listed on its right (e.g. 
wxluasocket depends on wxluadebug and lua).

maybe it would be more correct to write that:

    wxlua depends from:          lua
    wxbind depends from:         lua
    wxbindstc depends from:      wxbind, lua
    wxluadebug depends from:     wxlua, lua
    wxluasocket depends from:    wxluadebug, wxlua, lua

I realize that I've never asked such important question and that these 
relations should definitevely be cleared.... please correct the above 
schema.


> 
>> This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol
>> while for various reasons they should use different ones for the
>> different modules.
> 
> I had no idea. This is not a problem, we just need wxlsockdefs.h and
> wxldebugdefs.h or something like that for each.
I'll look about it and let you know. This will be also a good occasion 
to learn more about wxLua internals :))


>> Since, in my personal experience, building as DLL can be a BIG pain (you
>> have to be very careful about WXDLLIMPEXP symbols, inter-module
>> dependencies and in general in the entire build system), I propose to
>> make wxLua buildable as a set of modules when SHARED==0 and as a single
>> monolithic DLL library when SHARED==1.
>>
>> What do you think ?
> 
> I have never tried to build anything as a DLL except by accident. It's
> probably a shame that I separated out the wxluadebug and wxluasocket
> stuff from wxlua since it's so tiny compared to wxWidgets that the
> size savings of not having them is quite negligible and it's a hassle
> dealing with so many tiny parts.
that's partially true... OTOH they solve quite different tasks so that, 
at least logically, having them separate is a good thing...


> 
>> Also, what about moving "luamodule" dir to wxLua\modules ? Can I commit
>> that change ?
> 
> I see it more as an app? It's an end product of wxLua to be used by a
> user and it links to the other libs just like an app, even though it's
> a lib.
well, also other libs link to other libs when built as DLL :)
I think it would be confusing for the user to have all modules' output 
placed in wxLua\lib and apps' output partially in wxLua\bin and 
wxLua\lib....

An application is something the user can run... an executable; luamodule 
produces a library which is usable more or less like all other wxLua 
libraries (if we say that luamodule is like an app, why not say that 
also for e.g. wxbind? :))


> I thought it belonged in apps since you can't link to it unlike
> the other wxLua modules.
The link happens dinamically but is always a link...

> Sure, it's called module, but that's just
> lua's name for "require" libs.
> 
> I'm off for the next couple days, if you still think it's a good idea, 
> fine.
Ok, I'll try to fix the DLL build adding 
WXDLLIMPEXP_{WXBIND|WXBINDSTC|WXLUA|WXLUADEBUG|WXLUASOCKET} and then 
eventually commit them.

> 
> -------
> 
> I also had this in mind, the wxLuaFreeze and luamodule program may
> want to be compiled with smaller sets of the wxWidgets bindings. This
> is back to the old question of how to deal with different wxluasetup.h
> files, the wxLua app should always have everything. 
I thought this issue was solved using the WXLUASETUP_DIR and 
WXLUABINDLIB_DIR options; if someone wants a minimal version of wxLua 
without affecting the wxLua executable he needs to keep its wxluasetup.h 
in its own project folder instead of modifying 
wxLua\modules\wxbind\setup\wxluasetup.h...

>Also, the
> luamodule must have WXLUA_LUA_NEWTHREAD not #defined to use with a
> stock version of the lua executable and again the wxLua program
> *should* have it.
ok, I'll then add a new target to the makefiles, "lua", which builds the 
verbatim version of lua 5.1 and then make luamodule build against it.

I could then add also a "lua" <exe> target so that in the end, building 
wxLua one would get:

in bin\:
   wxlua-lua[.exe]  <-- the lua interpreter with WXLUA_LUA_NEWTHREAD
   lua5.1[.exe]     <-- the lua interpreter WITHOUT WXLUA_LUA_NEWTHREAD

in lib\:
   wxlua_gtk2d_lua-2.7[.so/.dll]  <-- lua core with WXLUA_LUA_NEWTHREAD
   lua5.1[.so/.dll]  <-- lua core WITHOUT WXLUA_LUA_NEWTHREAD

the names lua5.1[.exe] and lua5.1[.so/.dll] are intentionally the same 
of the LuaBinaries project since we should not fear to overwrite the 
system's installations of these things since they will be identic to the 
ones provided by the LuaBinaries project...


> Of course you (I) don't want to have to compile wxLua w/ everything,
> clean out the libs and rebuild, if you're a developer this can get
> really annoying. Maybe the wxLuaFreeze and luamodule should just
> compile the cpp files to their own private object files and be done
> with it. There's nothing worse than compiling something with wrong
> build options or #defines and when you get to end the linker complains
> about missing parts, you've got to completely restart and people might
> just get confused/annoyed and give up.
> 
> Additionally the wxLuaFreeze and luamodule might as well be linked to
> the object files directly since they really ought to be monolithic
> since they're distributable.
well, wxLuaFreeze is monolithic when compiled with SHARED==0.
luamodule OTOH *needs* to be non-monolithic (i.e. it needs not to have 
lua core code inside it - see beginning of this reply).

When compiled with SHARED==1, you get a wxLuaFreeze which depends from 
wxLua dlls but that's what the user expects I think...


> 
> -------
> 
> Finally, can we output the object files into unique dirs for each
> build setting. IIRC they're put in the same place for debug and
> release in MSVC and configure w/ gmake, but I could be wrong, I can't
> check right now.
yes, I'll do it.


> 
> Thanks for all your work Francesco, it'd be a pretty sorry state of
> affairs without you.
Thanks for your great work on wxLua, which unfortunately I haven't 
managed to integrate with my other projects yet :(

BTW, wxLuaSudoku sample is now so complete, nice and native-looking 
that we could really propose it as a stock game of Gnome ;)

Francesco

Josh Turpen ha scritto:
> 
> I see I'm not the only one having problems.  In order for other binary 
> modules to work with wxLua, wxLua needs to link against a seperate 
> Lua.DLL, a DLL which the modules also link against. 
I know - it's the same issue described at

http://lua-users.org/wiki/BuildingModules

(see "Do Not Link Modules to the Lua Core Libraries"), right ?



> In the current 
> binary release of wxLua the only way to make it work is to rebuild all 
> of the modules and have them link against wxLua.dll to get the lua symbols.
> 
> Please please please add/fix the SHARED options to the build system :)
Just for curiosity: how did you manage to rebuild all modules ?
Hacking the makefiles ?


> 
> 
> I have 3D rendering working inside a wxFrame using wxLua and IrrLua. 
> 
> http://irrlua.sourceforge.net/14.wxWindow.lua
very interesting project !
Maybe we should add a "projects using wxLua" section in wxLuaWebsite...


> 
>   Unfortunately it only works with wxLua 2.4 due to the linking issues 
> I've described above, which this SHARED option would solve.
> 
>   Linking against the LuaBinaries would be best of all.  If everybody 
> links against the same binaries, all of our modules will play together 
> without the need for a recompile somewhere.  Just download the .DLL/.so 
> and go.
I think it should be not very difficult to reach this compatibility: we 
just need to build luamodule against the verbatim version of lua.

Francesco

On 5/19/06, Francesco Montorsi <f18...@ya...> wrote:
> > Ok, another thing which now comes to my mind: "luamodule" directory
> > should probably be moved too, in wxLua/modules. In fact, it does not
> > build any application at all, just a .so/.dll

See below, but the .so/.dll is a distributable usable product, like an app?

> > BTW: I'd organize the thing as:
> > -> wx.so/dll is always placed in wxLua/lib (even if, in Unix, you're
> > building from a different build folder, e.g. wxLua/mybuild)

Sure.

> > -> luamodule.wx.lua sample uses
> > package.cpath = ";;../lib/?.so;..\lib\?.dll"
> > before the call to require("wx")
> >
> > -> on Unix, wx.so is installed in  $prefix/lib/lua/5.1

Ok.

> > Now, developers using wxLua which want to ship an application entirely
> > written in wxLua, which uses the require("wx") notation, will just need
> > to ship:
> >
> > -> all DLLs/.so of wxLua/lib if they built wxLua as a shared library
> > (SHARED=1)
> > -> wx.so/.dll if they built wxLua as a static library (SHARED=0).
> >    In fact, wx.so/.dll should be built regardless of the SHARED option
> > value: when SHARED==1, it will just be a super-small file which tells
> > the OS to load the other .so/.dll libraries; when SHARED==0, it will be
> > a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.
> >
> > What do you think ?

Sounds good, would this account for the possibility of someone getting
the wxWidgets2.6.3.rpm so they have their .so files and build wxLua
(or someday we provide our own rpm that depends on the wxWidgets rpm)
then we'd just want our .so libs to link to the rpm's libs. Or is this
way too much to ask.

> Trying to get wx.dll working on Win32, too, I've found a lot of problems
> in building the DLLs of wxLua.
>
> In particular, it looks like the different modules need somehow stuff
> which is in other modules to link so that I ended up to compile first
> all files and then link them all together in a single monolithic DLL
> library.

It should be all top down from wxLuaSocket->wxLuaDebug->wxLua, no deps
the other way around.

> This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol
> while for various reasons they should use different ones for the
> different modules.

I had no idea. This is not a problem, we just need wxlsockdefs.h and
wxldebugdefs.h or something like that for each.

> Since, in my personal experience, building as DLL can be a BIG pain (you
> have to be very careful about WXDLLIMPEXP symbols, inter-module
> dependencies and in general in the entire build system), I propose to
> make wxLua buildable as a set of modules when SHARED==0 and as a single
> monolithic DLL library when SHARED==1.
>
> What do you think ?

I have never tried to build anything as a DLL except by accident. It's
probably a shame that I separated out the wxluadebug and wxluasocket
stuff from wxlua since it's so tiny compared to wxWidgets that the
size savings of not having them is quite negligible and it's a hassle
dealing with so many tiny parts.

> Also, what about moving "luamodule" dir to wxLua\modules ? Can I commit
> that change ?

I see it more as an app? It's an end product of wxLua to be used by a
user and it links to the other libs just like an app, even though it's
a lib. I thought it belonged in apps since you can't link to it unlike
the other wxLua modules. Sure, it's called module, but that's just
lua's name for "require" libs.

I'm off for the next couple days, if you still think it's a good idea, fine.

-------

I also had this in mind, the wxLuaFreeze and luamodule program may
want to be compiled with smaller sets of the wxWidgets bindings. This
is back to the old question of how to deal with different wxluasetup.h
files, the wxLua app should always have everything. Also, the
luamodule must have WXLUA_LUA_NEWTHREAD not #defined to use with a
stock version of the lua executable and again the wxLua program
*should* have it.

Of course you (I) don't want to have to compile wxLua w/ everything,
clean out the libs and rebuild, if you're a developer this can get
really annoying. Maybe the wxLuaFreeze and luamodule should just
compile the cpp files to their own private object files and be done
with it. There's nothing worse than compiling something with wrong
build options or #defines and when you get to end the linker complains
about missing parts, you've got to completely restart and people might
just get confused/annoyed and give up.

Additionally the wxLuaFreeze and luamodule might as well be linked to
the object files directly since they really ought to be monolithic
since they're distributable.

-------

Finally, can we output the object files into unique dirs for each
build setting. IIRC they're put in the same place for debug and
release in MSVC and configure w/ gmake, but I could be wrong, I can't
check right now.

Thanks for all your work Francesco, it'd be a pretty sorry state of
affairs without you.
    John Labenski

I see I'm not the only one having problems.  In order for other binary modules to work with wxLua, wxLua needs to link against a seperate Lua.DLL, a DLL which the modules also link against.  In the current binary release of wxLua the only way to make it work is to rebuild all of the modules and have them link against wxLua.dll to get the lua symbols.

Please please please add/fix the SHARED options to the build system :)


I have 3D rendering working inside a wxFrame using wxLua and IrrLua.  

http://irrlua.sourceforge.net/14.wxWindow.lua

  Unfortunately it only works with wxLua 2.4 due to the linking issues I've described above, which this SHARED option would solve.

  Linking against the LuaBinaries would be best of all.  If everybody links against the same binaries, all of our modules will play together without the need for a recompile somewhere.  Just download the .DLL/.so and go.

" Trying to get wx.dll working on Win32, too, I've found a lot of problems 
in building the DLLs of wxLua.

In particular, it looks like the different modules need somehow stuff 
which is in other modules to link so that I ended up to compile first 
all files and then link them all together in a single monolithic DLL 
library.

This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol while for various reasons they should use different ones for the 
different modules.

Since, in my personal experience, building as DLL can be a BIG pain (you 
have to be very careful about WXDLLIMPEXP symbols, inter-module 
dependencies and in general in the entire build system), I propose to 
make wxLua buildable as a set of modules when SHARED==0 and as a single 
monolithic DLL library when SHARED==1.

What do you think ? "





		
---------------------------------
Ring'em or ping'em. Make  PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice.

Francesco Montorsi ha scritto:
> John Labenski ha scritto:
>> On 5/17/06, Francesco Montorsi 
>> <f18...@ya...> wrote:
>>> Hi,
>>>     I'm experimenting with wx module and I've got a few proposals for 
>>> it:
>>>
>>> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
>>> isn't it ? Shouldn't then go in wxLua/samples ?
>>> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
>>
>> Eh... I think these are pretty specialized. But, you're probably
>> right, once things work they should be moved. I just put them into the
>> dir where I generated the shared lib since I was having trouble with
>> the paths for require.
> Ok, another thing which now comes to my mind: "luamodule" directory 
> should probably be moved too, in wxLua/modules. In fact, it does not 
> build any application at all, just a .so/.dll
> 
> BTW: I'd organize the thing as:
> -> wx.so/dll is always placed in wxLua/lib (even if, in Unix, you're 
> building from a different build folder, e.g. wxLua/mybuild)
> 
> -> luamodule.wx.lua sample uses
> package.cpath = ";;../lib/?.so;..\lib\?.dll"
> before the call to require("wx")
> 
> -> on Unix, wx.so is installed in  $prefix/lib/lua/5.1
> 
> Now, developers using wxLua which want to ship an application entirely 
> written in wxLua, which uses the require("wx") notation, will just need 
> to ship:
> 
> -> all DLLs/.so of wxLua/lib if they built wxLua as a shared library 
> (SHARED=1)
> -> wx.so/.dll if they built wxLua as a static library (SHARED=0).
>    In fact, wx.so/.dll should be built regardless of the SHARED option 
> value: when SHARED==1, it will just be a super-small file which tells 
> the OS to load the other .so/.dll libraries; when SHARED==0, it will be 
> a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.
> 
> What do you think ?
Trying to get wx.dll working on Win32, too, I've found a lot of problems 
in building the DLLs of wxLua.

In particular, it looks like the different modules need somehow stuff 
which is in other modules to link so that I ended up to compile first 
all files and then link them all together in a single monolithic DLL 
library.

This is 99% because all modules use the same WXMAKINGDLL_WXLUA symbol 
while for various reasons they should use different ones for the 
different modules.

Since, in my personal experience, building as DLL can be a BIG pain (you 
have to be very careful about WXDLLIMPEXP symbols, inter-module 
dependencies and in general in the entire build system), I propose to 
make wxLua buildable as a set of modules when SHARED==0 and as a single 
monolithic DLL library when SHARED==1.

What do you think ?

Also, what about moving "luamodule" dir to wxLua\modules ? Can I commit 
that change ?

Thanks,
Francesco

T24gNS8xOS8wNiwgSGFra2kgRG9ndXNhbiA8ZG9ndXNhbmhAdHIubmV0PiB3cm90ZToKPiBGcmFu
Y2VzY28gTW9udG9yc2kgeWF6bf3+Ogo+ID4gSm9obiBMYWJlbnNraSBoYSBzY3JpdHRvOgo+ID4+
IEluIGdvaW5nIHRocm91Z2ggdGhlIHRoZSBpbnRlcmZhY2UgZmlsZXMgSSd2ZSBub3RpY2VkIHRo
YXQgdGhlcmUgYXJlIGEKPiA+PiBmZXcgbmFtaW5nIGluY29uc2lzdGVuY2llcyBmb3IgQysrIG92
ZXJsb2FkZWQgZnVuY3Rpb25zIGFuZAo+ID4+IGNvbnN0cnVjdG9ycy4gVHlwaWNhbGx5IHRoZXkg
aGF2ZSB0aGUgbmFtZXMgdGhhdCB3eFB5dGhvbiB1c2VzICh3aGVyZQo+ID4+IG5vdGVkIGluIHRo
ZSBkb2NzKSBhbmQgZm9yIHRoZSBtb3N0IHBhcnQgYXJlIGZpbmUsIGJ1dC4uLgo+ID4+Cj4gPj4g
U2luY2Ugd2UgY2FuIG92ZXJsb2FkZWQgZnVuY3Rpb24gaW4gd3hMdWEgZGlyZWN0bHkgKHVzdWFs
bHkpIHdlIGRvbid0Cj4gPj4gYWN0dWFsbHkgbmVlZCB0byBnaXZlIHRoZW0gdW5pcXVlIG5hbWVz
LCBob3dldmVyIHRoZXkgbmVlZCBzb21lIHNvcnQKPiA+PiBvZiBuYW1lIGZvciB0aGUgQyBmdW5j
dGlvbiBhbmQgbWlnaHQgYXMgd2VsbCBiZSBhY2Nlc3NpYmxlIGluIHd4THVhCj4gPj4gdXNpbmcg
dGhhdCBuYW1lIGFzIHdlbGwgYXMgdGhlIG92ZXJsb2FkZWQgd2F5Lgo+ID4gaG93ZXZlciBJJ20g
bm90IHN1cmUgdGhhdCBoYXZpbmcgdHdvIHBvc3NpYmxlIG5hbWVzIChlLmcuIEluc2VydEl0ZW0g
YW5kCj4gPiBJbnNlcnRJdGVtU3RyaW5nKSBmb3IgdGhlIHNhbWUgZnVuY3Rpb25zIChpbiBsdWEg
c2NyaXB0cykgaXMgYSBnb29kCj4gPiB0aGluZzogaXQgcHJvYmFibHkgbWVhbnMgdGhlcmUgd2ls
bCBiZSBzY3JpcHRzIHdpdGggYSBtZXNzeSBtaXggb2YgdGhlCj4gPiB0d28uLi4KClRoaXMgaXMg
dHJ1ZSwgaG9wZWZ1bGx5IHBlb3BsZSB3aWxsIGp1c3QgdXNlIHRoZSBvdmVybG9hZGVkIG1ldGhv
ZHMgYXMKc2hvd24gaW4gdGhlIHNhbXBsZXMgKHRvZG8pLiBUaGVyZSdzIHN0aWxsIHNvbWUgd29y
ayB0byBiZSBkb25lIHdpdGgKdGhlIG92ZXJsb2FkZWQgZnVuY3Rpb25zLCBsaWtlIHN0YXRpYyBm
dW5jdGlvbnMgZG9uJ3Qgd29yaywgYnV0IEkKZG9uJ3QgZm9yc2VlIGFueXRoaW5nIHRoYXQgc2hv
dWxkIG1ha2UgaXQgaW1wb3NzaWJsZS4KCj4gPj4gU3VnZ2VzdGVkIHJ1bGVzIGZvciByZW5hbWlu
ZzoKPiA+PiAxKSBNb3N0ICJjb21tb25seSB1c2VkIiBvciBkZWZhdWx0IGZ1bmN0aW9uIGdldHMg
YWN0dWFsIG5hbWUKPiA+PiAyKSBGdW5jdGlvbiBuYW1lcyB1c2UgdGhlIG9yaWdpbmFsIG5hbWUg
KyBbV2l0aF1bRGF0YSB0eXBlXQo+ID4+IGV4LiBBcHBlbmQoaW50IG4pLCBBcHBlbmQod3hTdHJp
bmcgcykgLT4gQXBwZW5kU3RyaW5nKHMpCj4gPj4gZXguIEFwcGVuZChpbnQgbiksIEFwcGVuZChp
bnQgbiwgU3R1ZmYgcykgLT4gQXBwZW5kV2l0aFN0dWZmKG4sIHMpCj4gPj4gMykgQ2xhc3MgY29u
c3RydWN0b3JzIHN0YXJ0IHdpdGggdGhlIENsYXNzTmFtZSArIEZyb21bRGF0YSB0eXBlXQo+ID4+
IERlZmF1bHQgY29uc3RydWN0b3JzIGFyZSBhbHdheXMgd3hDbGFzc05hbWVEZWZhdWx0KCkKPiA+
PiBDb3B5IGNvbnN0cnVjdG9ycyBhcmUgYWx3YXlzIHd4Q2xhc3NOYW1lQ29weShjb25zdCB3eENs
YXNzTmFtZSYgYykKPiA+Pgo+ID4+IE9idmlvdXNseSB0aGVyZSB3aWxsIGJlIGV4Y2VwdGlvbnMg
b3IgY2FzZXMgd2hlcmUgdGhlIG5hbWUgbWF5IHNvdW5kCj4gPj4gYXdrd2FyZCwgYnV0IHRoZSBu
dW1iZXIgb2YgdGhlc2Ugd2lsbCBiZSBzbWFsbC4KPiA+IEkgYWdyZWU6IGJldHRlciBmb2xsb3cg
YSB1bmlxdWUgcmF0aW9uYWwgcnVsZS4gVGhpcyB3aWxsIHJlZHVjZSB0aGUKPiA+IG51bWJlciBv
ZiB0aW1lcyB0aGUgdXNlciBpcyBmb3JjZWQgdG8gbG9vayBpbiB0aGUgbWFudWFsIHRvIGZpbmQg
dGhlCj4gPiByaWdodCBuYW1lIG9mIGEgZnVuY3Rpb24uCgpHb29kLCBJJ20gZ2xhZCB5b3UgYWdy
ZWUuIEFnYWluLCBmb3IgdGhlIG1vc3QgcGFydCB0aGV5IGZvbGxvdyB0aGUKYWJvdmUgInJ1bGVz
IiwgYnV0IHRoZXJlJ3Mgc29tZSBvZGRiYWxscy4KCj4gPj4gSG9wZWZ1bGx5IHlvdSBjYW4gc2Vl
IHRoYXQgdGhlIG5hbWluZyByaWdodCBub3cgY2FuIGJlIGZhaXJseQo+ID4+IGFyYml0cmFyeSwg
d2hlcmUgdGhlIGRlZmF1bHQgd3hJbWFnZSBjb25zdHJ1Y3RvciBtYWtlcyBhIGNvcHk/Cj4gPj4g
d3hFbXB0eUltYWdlPyB3eERlZmF1bHRJbWFnZT8gVGhlIGRlZmF1bHQgZm9yIHd4Qml0bWFwIHRh
a2VzIHRoZQo+ID4+IGJpdG1hcCBkYXRhIGl0c2VsZiwgYnV0IG9ubHkgZm9yIE1TVywgaG93IHVz
ZWZ1bCBpcyB0aGF0Pwo+ID4+Cj4gPj4gSSB3b3VsZCBsaWtlIHRvIG5vcm1hbGl6ZSBhbGwgb2Yg
dGhlc2UsIG9idmlvdXNseSBicmVha2luZwo+ID4+IGNvbXBhdGliaWxpdHksIGJ1dCBiZXR0ZXIg
c29vbmVyIHRoYW4gbGF0ZXIuIDopIFRoZXJlJ3MgcHJvYmFibHkgYWJvdXQKPiA+PiAyIGRvemVu
IG9mIHRoZW0gdG8gY2hhbmdlLgo+ID4gSSBhZ3JlZSB0aGF0IHRoaXMgc2hvdWxkIGJlIGRvbmUg
YXMgc29vbiBhcyBwb3NzaWJsZS4KCk5leHQgd2VlaywgSSdtIG9mZiBmb3IgdGhlIHdlZWtlbmQu
Cgo+IEkgd2FzIG5hbWluZyBteSBweXRob24gYmluZGluZ3MgKHdpdGggc3dpZykgbGlrZSB3eFB5
dGhvbi4gQnV0Cj4gZm9yIGx1YSBJJ20gbm90IGR1cGxpY2F0aW5nIGZ1bmN0aW9ucyBmb3IgZXZl
cnkgZGlmZmVyZW50IHBhcmFtczsKPiBJJ20gY2hlY2tpbmcgdGhlbSBpbiB3cmFwcGluZyBmdW5j
dGlvbnMuIEknbSB1c2luZyBsdW5hLiBTbyBhbGwKPiB3cmFwcGluZyBpcyBoYW5kIG1hZGUgOikK
Pgo+IEV4OiBpbiBDKysgOiBTZW5kKGludCksIFNlbmQod3hTdHJpbmcpLCBTZW5kKGludCwgaW50
KSwuLi4KPiBiZWNvbWVzIGluIEx1YTogU2VuZCguLi4pCj4KPiBCdXQgSSBkb24ndCBrbm93IGhv
dyBzb21ldGhpbmcgbGlrZSB0aGF0IGNhbiBiZSBnZW5lcmF0ZWQgYXV0b21hdGljYWxseS4KPiBE
b2VzIHRvTHVhIGhhbmRsZSBvdmVybG9hZGVkIGZ1bmN0aW9ucz8KCkR1bm5vLCB3eEx1YSB1c2Vz
IGl0J3Mgb3duIHdyYXBwaW5nIG1lY2hhbmlzbSBmb3IgYmV0dGVyIG9yIHdvcnNlLgpQcm9iYWJs
eSBmb3IgdGhlIGJldHRlciBzaW5jZSB3ZSBoYXZlIGNvbnRyb2wgb3ZlciBpdCBhbmQgdGhlcmUn
cyBhCmZldyB0aGluZyBpbiB3eFdpZGdldHMgdGhhdCB3ZSBoYXZlIHRvIGhhbmRsZSBzcGVjaWFs
bHksIGxpa2Ugd3hXaW5kb3cKZGVyaXZlZCBjbGFzc2VzLgoKaHR0cDovL3d4bHVhLnNvdXJjZWZv
cmdlLm5ldC9kb2NzL2JpbmRpbmcuaHRtbApodHRwOi8vd3hsdWEuc291cmNlZm9yZ2UubmV0L2Rv
Y3Mvd3hsdWFyZWYuaHRtbAoKUmVnYXJkcywKICAgIEpvaG4gTGFiZW5za2kK

Hi,

Francesco Montorsi yazmış:
> John Labenski ha scritto:
>> In going through the the interface files I've noticed that there are a
>> few naming inconsistencies for C++ overloaded functions and
>> constructors. Typically they have the names that wxPython uses (where
>> noted in the docs) and for the most part are fine, but...
>>
>> Since we can overloaded function in wxLua directly (usually) we don't
>> actually need to give them unique names, however they need some sort
>> of name for the C function and might as well be accessible in wxLua
>> using that name as well as the overloaded way.
> however I'm not sure that having two possible names (e.g. InsertItem and 
> InsertItemString) for the same functions (in lua scripts) is a good 
> thing: it probably means there will be scripts with a messy mix of the 
> two...
> 
>> Suggested rules for renaming:
>> 1) Most "commonly used" or default function gets actual name
>> 2) Function names use the original name + [With][Data type]
>> ex. Append(int n), Append(wxString s) -> AppendString(s)
>> ex. Append(int n), Append(int n, Stuff s) -> AppendWithStuff(n, s)
>> 3) Class constructors start with the ClassName + From[Data type]
>> Default constructors are always wxClassNameDefault()
>> Copy constructors are always wxClassNameCopy(const wxClassName& c)
>>
>> Obviously there will be exceptions or cases where the name may sound
>> awkward, but the number of these will be small.
> I agree: better follow a unique rational rule. This will reduce the 
> number of times the user is forced to look in the manual to find the 
> right name of a function.
> 
> 
>> Hopefully you can see that the naming right now can be fairly
>> arbitrary, where the default wxImage constructor makes a copy?
>> wxEmptyImage? wxDefaultImage? The default for wxBitmap takes the
>> bitmap data itself, but only for MSW, how useful is that?
>>
>> I would like to normalize all of these, obviously breaking
>> compatibility, but better sooner than later. :) There's probably about
>> 2 dozen of them to change.
> I agree that this should be done as soon as possible.
> 
> Francesco
> 
> 

I was naming my python bindings (with swig) like wxPython. But
for lua I'm not duplicating functions for every different params;
I'm checking them in wrapping functions. I'm using luna. So all
wrapping is hand made :)

Ex: in C++ : Send(int), Send(wxString), Send(int, int),...
becomes in Lua: Send(...)


But I don't know how something like that can be generated automatically.
Does toLua handle overloaded functions?



--
Regards,
Hakki Dogusan

John Labenski ha scritto:
> In going through the the interface files I've noticed that there are a
> few naming inconsistencies for C++ overloaded functions and
> constructors. Typically they have the names that wxPython uses (where
> noted in the docs) and for the most part are fine, but...
> 
> Since we can overloaded function in wxLua directly (usually) we don't
> actually need to give them unique names, however they need some sort
> of name for the C function and might as well be accessible in wxLua
> using that name as well as the overloaded way.
however I'm not sure that having two possible names (e.g. InsertItem and 
InsertItemString) for the same functions (in lua scripts) is a good 
thing: it probably means there will be scripts with a messy mix of the 
two...

> Suggested rules for renaming:
> 1) Most "commonly used" or default function gets actual name
> 2) Function names use the original name + [With][Data type]
> ex. Append(int n), Append(wxString s) -> AppendString(s)
> ex. Append(int n), Append(int n, Stuff s) -> AppendWithStuff(n, s)
> 3) Class constructors start with the ClassName + From[Data type]
> Default constructors are always wxClassNameDefault()
> Copy constructors are always wxClassNameCopy(const wxClassName& c)
> 
> Obviously there will be exceptions or cases where the name may sound
> awkward, but the number of these will be small.
I agree: better follow a unique rational rule. This will reduce the 
number of times the user is forced to look in the manual to find the 
right name of a function.


> Hopefully you can see that the naming right now can be fairly
> arbitrary, where the default wxImage constructor makes a copy?
> wxEmptyImage? wxDefaultImage? The default for wxBitmap takes the
> bitmap data itself, but only for MSW, how useful is that?
> 
> I would like to normalize all of these, obviously breaking
> compatibility, but better sooner than later. :) There's probably about
> 2 dozen of them to change.
I agree that this should be done as soon as possible.

Francesco

John Labenski ha scritto:
> On 5/18/06, Francesco Montorsi 
> <f18...@ya...> wrote:
>> Hi,
>>    today my SSH client says that the RSA key fingerprint for the CVS
>> server is
>>
>>     13:f1:65:c3:6c:b7:7e:a5:f0:f3:f5:19:f4:42:9c:4a
>>
>> I had to delete the "offending" line from my
>> /home/frm/.ssh/known_hosts... does anyone got the same message ?
>>
>> Or I've really been subject to a "man-in-the-middle attack" as SSH 
>> says ? ;)
> 
> The key changed for wxcode as well, so I guess SF changed machines and
> didn't copy the old key?
seems so... (that sounded a bit strange for me given how much SF cares 
about security - I couldn't even find a news on SF website about this 
change)

Francesco

On 5/18/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>    today my SSH client says that the RSA key fingerprint for the CVS
> server is
>
>     13:f1:65:c3:6c:b7:7e:a5:f0:f3:f5:19:f4:42:9c:4a
>
> I had to delete the "offending" line from my
> /home/frm/.ssh/known_hosts... does anyone got the same message ?
>
> Or I've really been subject to a "man-in-the-middle attack" as SSH says ? ;)

The key changed for wxcode as well, so I guess SF changed machines and
didn't copy the old key?

-John Labenski

John Labenski ha scritto:
> On 5/17/06, Francesco Montorsi 
> <f18...@ya...> wrote:
>> Hi,
>>     I'm experimenting with wx module and I've got a few proposals for it:
>>
>> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
>> isn't it ? Shouldn't then go in wxLua/samples ?
>> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
> 
> Eh... I think these are pretty specialized. But, you're probably
> right, once things work they should be moved. I just put them into the
> dir where I generated the shared lib since I was having trouble with
> the paths for require.
Ok, another thing which now comes to my mind: "luamodule" directory 
should probably be moved too, in wxLua/modules. In fact, it does not 
build any application at all, just a .so/.dll

BTW: I'd organize the thing as:
-> wx.so/dll is always placed in wxLua/lib (even if, in Unix, you're 
building from a different build folder, e.g. wxLua/mybuild)

-> luamodule.wx.lua sample uses
package.cpath = ";;../lib/?.so;..\lib\?.dll"
before the call to require("wx")

-> on Unix, wx.so is installed in  $prefix/lib/lua/5.1

Now, developers using wxLua which want to ship an application entirely 
written in wxLua, which uses the require("wx") notation, will just need 
to ship:

-> all DLLs/.so of wxLua/lib if they built wxLua as a shared library 
(SHARED=1)
-> wx.so/.dll if they built wxLua as a static library (SHARED=0).
    In fact, wx.so/.dll should be built regardless of the SHARED option 
value: when SHARED==1, it will just be a super-small file which tells 
the OS to load the other .so/.dll libraries; when SHARED==0, it will be 
a bigger lib (on my Unix, it is about 9,4 MB) which is self-contained.

What do you think ?

Francesco

Ray Gilbert ha scritto:
> Being able to set LUA_PATH from within lua script is does not work with 5.1
> 
> I hacked code to look for LUA_PATH in our version of loadlib.c - but it only uses it for pname of "path" i.e. .lua files.
> 
> You could change loadlib.c code to
> 
>   /* Make 5.0 compatible to allow global LUA_PATH to be set from LUA */
>   if (strcmp(pname, "path") == 0 || strcmp(pname, "cpath") == 0) {
> 						^^^^^^^^^^^^^^^^^^^^^^^^^^^
>       lua_getfield(L, LUA_GLOBALSINDEX, LUA_PATH);
> 
> 
> so that it will pick up "cpath" libraries 
thanks for the tip but I'd prefer not to modify the loadlib.c code - 
specially because I've solved this problem with package.cpath ;)

BTW, why was this LUA_PATH change added ?
It would be great if we could use the verbatim lua 5.1 distribution in 
modules/lua...

Thanks!
Francesco

Hakki Dogusan ha scritto:
> I'm using paths like this (on winxp):
> 
> DSASPATH = "c:/a_C/dsas/server/"
> 
> package.path  = 
> DSASPATH.."?;"..DSASPATH.."?.lua;"..DSASPATH.."/apps/?;"..DSASPATH.."/apps/?.lua" 
> 
> package.cpath = 
> DSASPATH.."?;"..DSASPATH.."?.dll;"..DSASPATH.."/apps/?;"..DSASPATH.."/apps/?.dll" 
> 
> 
> require("testapp")         -- API testing
> ...
> 
Exactly what I was looking for: package.cpath.
Works nicely here, thanks!

Francesco

Damien Fagnou ha scritto:
> 
>  I have being using LUA_CPATH
> setenv LUA_CPATH "...../lua/5.1/linux.fedora1/gcc3.3.4/?.so"
> and  doing require "wx" in the scripts 
>  and it works fine 
> 
>  I can`t remember when I found the documentation about it though :)
it works but I was searching a way to set the path from the lua script 
itself...

Thanks anyway,
Francesco

Hi,
   today my SSH client says that the RSA key fingerprint for the CVS 
server is

    13:f1:65:c3:6c:b7:7e:a5:f0:f3:f5:19:f4:42:9c:4a

I had to delete the "offending" line from my 
/home/frm/.ssh/known_hosts... does anyone got the same message ?

Or I've really been subject to a "man-in-the-middle attack" as SSH says ? ;)

Francesco

Hi,

John Labenski yazmış:
> On 5/17/06, Francesco Montorsi <f18...@ya...> wrote:
>> Hi,
>>     I'm experimenting with wx module and I've got a few proposals for it:
>>
>> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
>> isn't it ? Shouldn't then go in wxLua/samples ?
>> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
> 
> Eh... I think these are pretty specialized. But, you're probably
> right, once things work they should be moved. I just put them into the
> dir where I generated the shared lib since I was having trouble with
> the paths for require.
> 
>> 2) I'm getting a weird behaviour of lua's require: I'd like to make the
>> "luamodule" app installable in $prefix/lib/lua/5.1; however, while
>> everything works as expected if I put the compiled wx.so in
>> /usr/local/lib/lua/5.1, it doesn't work if I put it in /usr/lib/lua/5.1:
> 
> This is the path stuff I was talking about, it's a nightmare.
> 
>> wxlua-lua: luamodule.wx.lua:17: module 'wx' not found:
>>          no field package.preload['wx']
>>          no file './wx.so'
>>          no file '/usr/local/lib/lua/5.1/wx.so'
>>          no file '/usr/local/lib/lua/5.1/loadall.so'
>> stack traceback:
>>          [C]: in function 'require'
>>          luamodule.wx.lua:17: in main chunk
>>          [C]: ?
>>
>> I tried to set LUA_PATH in luamodule.wx.lua to:
>> LUA_PATH="/usr/lib/lua/5.1/?.so;"
>> *before* the require() call but then I get:
>>
>> wxlua-lua: error loading module 'wx' from file '/usr/lib/lua/5.1/wx.so':
>>          /usr/lib/lua/5.1/wx.so:1: unexpected symbol near 'char(127)'
>> stack traceback:
>>          [C]: ?
>>          [C]: in function 'require'
>>          luamodule.wx.lua:17: in main chunk
>>          [C]: ?
>>
>> that "unexpected symbol near 'char(127)'" is not clear to me !
>>
>> This strange behaviour (lua bug?) is easy to reproduce also putting the
>> wx.so file in /usr/local/lib/lua/5.1 and then setting:
>>
>> LUA_PATH="/usr/local/lib/lua/5.1/?.so"
>>
>> So, it looks that the global variable LUA_PATH, described at
>> http://www.lua.org/pil/8.1.html, does not work... is anyone able to
>> reproduce this "bug" ?
> 
> LUA_PATH, I think, is a 5.0 thing, but recently Ray added some code in
> our version of lua to handle it. Hopefully he (or anyone else)
> understands what this is all about? I've spent far too much time
> trying to understand the PATH thing and got nowhere.
> 
> I was hoping that the people who requested that require work w/ wxLua
> would step forward and finish things. :)
> 
> Regards,
>    John Labenski
> 
[snip]

I'm using paths like this (on winxp):

DSASPATH = "c:/a_C/dsas/server/"

package.path  = 
DSASPATH.."?;"..DSASPATH.."?.lua;"..DSASPATH.."/apps/?;"..DSASPATH.."/apps/?.lua"
package.cpath = 
DSASPATH.."?;"..DSASPATH.."?.dll;"..DSASPATH.."/apps/?;"..DSASPATH.."/apps/?.dll"

require("testapp")         -- API testing
...



--
Regards,
Hakki Dogusan

Being able to set LUA_PATH from within lua script is does not work with =
5.1

I hacked code to look for LUA_PATH in our version of loadlib.c - but it =
only uses it for pname of "path" i.e. .lua files.

You could change loadlib.c code to

  /* Make 5.0 compatible to allow global LUA_PATH to be set from LUA */
  if (strcmp(pname, "path") =3D=3D 0 || strcmp(pname, "cpath") =3D=3D 0) =
{
						^^^^^^^^^^^^^^^^^^^^^^^^^^^
      lua_getfield(L, LUA_GLOBALSINDEX, LUA_PATH);


so that it will pick up "cpath" libraries=20

Ray


-----Original Message-----
From: wxl...@li... =
[mailto:wxl...@li...] On Behalf Of John =
Labenski
Sent: Thursday, 18 May 2006 03:05
To: wxl...@li...
Subject: LUA_PATH (Ray) Re: [Wxlua-users] require("wx") and build stuff

On 5/17/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>     I'm experimenting with wx module and I've got a few proposals for =
it:
>
> 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an =
example,
> isn't it ? Shouldn't then go in wxLua/samples ?
> wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?

Eh... I think these are pretty specialized. But, you're probably
right, once things work they should be moved. I just put them into the
dir where I generated the shared lib since I was having trouble with
the paths for require.

> 2) I'm getting a weird behaviour of lua's require: I'd like to make =
the
> "luamodule" app installable in $prefix/lib/lua/5.1; however, while
> everything works as expected if I put the compiled wx.so in
> /usr/local/lib/lua/5.1, it doesn't work if I put it in =
/usr/lib/lua/5.1:

This is the path stuff I was talking about, it's a nightmare.

> wxlua-lua: luamodule.wx.lua:17: module 'wx' not found:
>          no field package.preload['wx']
>          no file './wx.so'
>          no file '/usr/local/lib/lua/5.1/wx.so'
>          no file '/usr/local/lib/lua/5.1/loadall.so'
> stack traceback:
>          [C]: in function 'require'
>          luamodule.wx.lua:17: in main chunk
>          [C]: ?
>
> I tried to set LUA_PATH in luamodule.wx.lua to:
> LUA_PATH=3D"/usr/lib/lua/5.1/?.so;"
> *before* the require() call but then I get:
>
> wxlua-lua: error loading module 'wx' from file =
'/usr/lib/lua/5.1/wx.so':
>          /usr/lib/lua/5.1/wx.so:1: unexpected symbol near 'char(127)'
> stack traceback:
>          [C]: ?
>          [C]: in function 'require'
>          luamodule.wx.lua:17: in main chunk
>          [C]: ?
>
> that "unexpected symbol near 'char(127)'" is not clear to me !
>
> This strange behaviour (lua bug?) is easy to reproduce also putting =
the
> wx.so file in /usr/local/lib/lua/5.1 and then setting:
>
> LUA_PATH=3D"/usr/local/lib/lua/5.1/?.so"
>
> So, it looks that the global variable LUA_PATH, described at
> http://www.lua.org/pil/8.1.html, does not work... is anyone able to
> reproduce this "bug" ?

LUA_PATH, I think, is a 5.0 thing, but recently Ray added some code in
our version of lua to handle it. Hopefully he (or anyone else)
understands what this is all about? I've spent far too much time
trying to understand the PATH thing and got nowhere.

I was hoping that the people who requested that require work w/ wxLua
would step forward and finish things. :)

Regards,
    John Labenski

ps. This was a reply I got on the lua-l about dlls and require, it
looks like for gcc in MSW you just link the dlls as you do the .so
files in linux. No news about MSVC.

On 5/13/06, J=E9r=F4me VUARAND <jer...@gm...> wrote:
> With mingw you can do exactly the same to build a wx.dll Lua module :
> wx.dll: luamodule.cpp $(OBJECTS) $(LUA_LIBS) wxLuaLib wxLuaDebugLib
> wxLuaSocketLib wxLuaBindings
>         $(CXX) $(CXXFLAGS) $(APPEXTRADEFS) -g -O -shared -o wx.dll =
-fpic \
>         $(LDLIBS) $(APPEXTRALIBS) \
>         luamodule.cpp
>
> The only extra thing you have to do is to check that all your
> -l$(XXXLIB) point to existing libraries. These libraries can either be
> static libs, or dll import libraries. Static libs are exactly like on
> unix (-lfoo need libfoo.a). Dll import libraries are necessary if you
> want to link dynamically to a dll. You can generate libfoo.a from
> foo.dll with the following commands :
>         impdef foo.dll > foo.def
>         libtool --kill-at --dllname foo.dll --input-def foo.def =
--output-lib libfoo.a
>         rm foo.def
> These import libraries may already exist in the wxWidget build tree if
> you built it with mingw.
>
> Feel free to ask if I'm not clear. I had a hard time finding docs on
> the subject since everything on mingw site is outdated, but now I
> think I know the subject well.


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, =
security?
Get stuff done quickly with pre-integrated technology to make your job =
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users

In going through the the interface files I've noticed that there are a
few naming inconsistencies for C++ overloaded functions and
constructors. Typically they have the names that wxPython uses (where
noted in the docs) and for the most part are fine, but...

Since we can overloaded function in wxLua directly (usually) we don't
actually need to give them unique names, however they need some sort
of name for the C function and might as well be accessible in wxLua
using that name as well as the overloaded way.

Suggested rules for renaming:
1) Most "commonly used" or default function gets actual name
2) Function names use the original name + [With][Data type]
ex. Append(int n), Append(wxString s) -> AppendString(s)
ex. Append(int n), Append(int n, Stuff s) -> AppendWithStuff(n, s)
3) Class constructors start with the ClassName + From[Data type]
Default constructors are always wxClassNameDefault()
Copy constructors are always wxClassNameCopy(const wxClassName& c)

Obviously there will be exceptions or cases where the name may sound
awkward, but the number of these will be small.

Some examples of the inconsistencies I'm talking about:

--------------------------
These member functions will be out of alphabetical order and may be
difficult to directly associate with the original function without
looking through the docs. It is true that the wxPython ones may be
more syntactically "correct", but I think that directly associating
them with the original function is more compelling.

wxListCtrl
wxPython naming (currently wxLua uses this)
  InsertItem(item)   Inserts an item using a wxListItem.
  InsertStringItem(index, label)   Inserts a string item.
  InsertImageItem(index, imageIndex)   Inserts an image item.
  InsertImageStringItem(index, label, imageIndex)   Insert an image/string =
item.

I would prefer
  InsertItem(item)   Inserts an item using a wxListItem.
  InsertItemString(index, label)   Inserts a string item.
  InsertItemImage(index, imageIndex)   Inserts an image item.
  InsertItemImageString(index, label, imageIndex)   Insert an image/string =
item.

---------------------------

Some constructor examples, currently it's this way
  wxColour(const unsigned char red, const unsigned char green, const
unsigned char blue)
  wxNamedColour(const wxString& colourNname) // python compatibility
  wxColourCopy(const wxColour& colour)

I would prefer
  wxColour(const unsigned char red, const unsigned char green, const
unsigned char blue)
  wxColourFromString(const wxString& colourNname) // python compatibility
  wxColourCopy(const wxColour& colour)

other examples
    %constructor wxDefaultBitmap()
    %win wxBitmap(void * data, int type, int width, int height, int depth =
=3D -1)
    %constructor wxBitmapCopy(const wxBitmap& bitmap)
    %constructor wxEmptyBitmap( int width, int height, int depth =3D -1)
    %constructor wxBitmapFromFile( const wxString& name, long type)
    %constructor wxBitmapFromXPMData(const char **data)
    %wxchkver23 %constructor wxBitmapFromImage(const wxImage &image,
int depth =3D -1)
and
    wxImage(const wxImage& image)
    %constructor wxDefaultImage()
    %wxchkver23 %constructor wxImageFromBitmap(const wxBitmap& bitmap)
    %constructor wxEmptyImage(int width, int height, bool clear=3Dtrue)
    %constructor wxImageFromData(int width, int height, unsigned char*
data, bool static_data =3D false)
    %constructor wxImageFromFile(const wxString& name, long type =3D
wxBITMAP_TYPE_ANY)

Hopefully you can see that the naming right now can be fairly
arbitrary, where the default wxImage constructor makes a copy?
wxEmptyImage? wxDefaultImage? The default for wxBitmap takes the
bitmap data itself, but only for MSW, how useful is that?

I would like to normalize all of these, obviously breaking
compatibility, but better sooner than later. :) There's probably about
2 dozen of them to change.

Regards,
    John Labenski

 I have being using LUA_CPATH
setenv LUA_CPATH "...../lua/5.1/linux.fedora1/gcc3.3.4/?.so"
and  doing require "wx" in the scripts=20
 and it works fine=20

 I can`t remember when I found the documentation about it though :)

damien


> On 5/17/06, Francesco Montorsi <f18...@ya...> wrote:
> > Hi,
> >     I'm experimenting with wx module and I've got a few proposals for i=
t:
> >
> > 1) the luamodule.wx.lua files in wxLua/apps/luamodule/src is an example,
> > isn't it ? Shouldn't then go in wxLua/samples ?
> > wrapmodule.wx.lua is an utility so shouldn't it got in wxLua/utils ?
>=20
> Eh... I think these are pretty specialized. But, you're probably
> right, once things work they should be moved. I just put them into the
> dir where I generated the shared lib since I was having trouble with
> the paths for require.
>=20
> > 2) I'm getting a weird behaviour of lua's require: I'd like to make the
> > "luamodule" app installable in $prefix/lib/lua/5.1; however, while
> > everything works as expected if I put the compiled wx.so in
> > /usr/local/lib/lua/5.1, it doesn't work if I put it in /usr/lib/lua/5.1:
>=20
> This is the path stuff I was talking about, it's a nightmare.
>=20
> > wxlua-lua: luamodule.wx.lua:17: module 'wx' not found:
> >          no field package.preload['wx']
> >          no file './wx.so'
> >          no file '/usr/local/lib/lua/5.1/wx.so'
> >          no file '/usr/local/lib/lua/5.1/loadall.so'
> > stack traceback:
> >          [C]: in function 'require'
> >          luamodule.wx.lua:17: in main chunk
> >          [C]: ?
> >
> > I tried to set LUA_PATH in luamodule.wx.lua to:
> > LUA_PATH=3D"/usr/lib/lua/5.1/?.so;"
> > *before* the require() call but then I get:
> >
> > wxlua-lua: error loading module 'wx' from file '/usr/lib/lua/5.1/wx.so':
> >          /usr/lib/lua/5.1/wx.so:1: unexpected symbol near 'char(127)'
> > stack traceback:
> >          [C]: ?
> >          [C]: in function 'require'
> >          luamodule.wx.lua:17: in main chunk
> >          [C]: ?
> >
> > that "unexpected symbol near 'char(127)'" is not clear to me !
> >
> > This strange behaviour (lua bug?) is easy to reproduce also putting the
> > wx.so file in /usr/local/lib/lua/5.1 and then setting:
> >
> > LUA_PATH=3D"/usr/local/lib/lua/5.1/?.so"
> >
> > So, it looks that the global variable LUA_PATH, described at
> > http://www.lua.org/pil/8.1.html, does not work... is anyone able to
> > reproduce this "bug" ?
>=20
> LUA_PATH, I think, is a 5.0 thing, but recently Ray added some code in
> our version of lua to handle it. Hopefully he (or anyone else)
> understands what this is all about? I've spent far too much time
> trying to understand the PATH thing and got nowhere.
>=20
> I was hoping that the people who requested that require work w/ wxLua
> would step forward and finish things. :)
>=20
> Regards,
>     John Labenski
>=20
> ps. This was a reply I got on the lua-l about dlls and require, it
> looks like for gcc in MSW you just link the dlls as you do the .so
> files in linux. No news about MSVC.
>=20
> On 5/13/06, J=E9r=F4me VUARAND <jer...@gm...> wrote:
> > With mingw you can do exactly the same to build a wx.dll Lua module :
> > wx.dll: luamodule.cpp $(OBJECTS) $(LUA_LIBS) wxLuaLib wxLuaDebugLib
> > wxLuaSocketLib wxLuaBindings
> >         $(CXX) $(CXXFLAGS) $(APPEXTRADEFS) -g -O -shared -o wx.dll -fpi=
c \
> >         $(LDLIBS) $(APPEXTRALIBS) \
> >         luamodule.cpp
> >
> > The only extra thing you have to do is to check that all your
> > -l$(XXXLIB) point to existing libraries. These libraries can either be
> > static libs, or dll import libraries. Static libs are exactly like on
> > unix (-lfoo need libfoo.a). Dll import libraries are necessary if you
> > want to link dynamically to a dll. You can generate libfoo.a from
> > foo.dll with the following commands :
> >         impdef foo.dll > foo.def
> >         libtool --kill-at --dllname foo.dll --input-def foo.def --outpu=
t-lib libfoo.a
> >         rm foo.def
> > These import libraries may already exist in the wxWidget build tree if
> > you built it with mingw.
> >
> > Feel free to ask if I'm not clear. I had a hard time finding docs on
> > the subject since everything on mingw site is outdated, but now I
> > think I know the subject well.
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users