wxlua-users — wxLua list for users and developers

Re: [wxlua-users] wxLuaIDE

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

Francesco Montorsi wrote:
> I agree.
>
> I also think that having a stock dialog for running wxLua scripts and 
> maybe debug them would be very nice.
Yep, i think it will make things much easier for new users which want to 
integrate wxLua in there app.
Especially if the wxluacan shows them how to do it. With debug the 
scripts and stepping through your own scripts, what more does one want.
>  Unfortunately I don't really know 
> much about wxLua internals and wxStEdit, so here it is my dumb question:
> do such things need wxStEdit? wouldn't it be possible to add such things 
> to "wxlua" module _without_ making it depending on wxStEdit?
>   
A simplified version i think.
> If it's really required, maybe we could still add it to wxlua module and 
> then use wxDynamicLibrary stuff to open wxstedit.dll at runtime, if present.
>   
Better if its available use it, and else fall back on a simpled text 
control.
But i don't know is this is possible at all.
>>
> I'm now get used to KATE. It's great I think.
>   
My other favorite ;-)
And the same editor component is used in krusader.

Klaas

Re: [wxlua-users] wxLua announcement text

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

Hakki Dogusan ha scritto:
> Hi,
> 
> Francesco Montorsi wrote:
>> Hi all,
>>    i've added a file under distrib\announce.txt which lists the places where to 
>> post the info about the new wxLua release and also the announcement text for it.
>>
>> Any comments/suggestions gladly accepted,
>> Francesco
>>
> 
> Info at LuaAddons would be changed?
> 
> #  [wxLua] (5.0) - a blend of Lua and wxWidgets. has its own IDE with a 
> debugger. The IDE is written in wxLua.
> 
> (5.0) -> (5.1)
> +Has a binding generator written in Lua
> +Usable as module
sure, good idea. I've done it now. Thanks for the tip.


> Don't know but, if luaforge allows projects hosted elsewhere,
> it would be good to have a project there?
wxLua is already subscribed at LuaForge:

  http://luaforge.net/projects/wxlua/

;)

Thanks,
Francesco

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

[Hakki D. <dog...@tr...>]

Hi,

Francesco Montorsi wrote:
> Hakki Dogusan ha scritto:
[snip]
> 
>> ps. I was reported this before but..
>> DependencyWalker shows following for wx.dll:
>>
>> WX.DLL
>> - LUA5.1.DLL (lua_getfield)
>> - WXLUA_MSW28_WXBIND.DLL
>> --- WXLUA_MSW28_LUA.DLL
>> --- WXLUA_MSW28_WXLUA.DLL
>> --- WXMSW28_GCC_DS.DLL
>> - WXLUA_MSW28_WXLUA.DLL
>> --- WXLUA_MSW28_LUA.DLL
>> --- WXMSW28_GCC_DS.DLL
>> - WXMSW28_GCC_DS.DLL
>>
>> Could it be possible to have only lua5.1.dll dependency
>> for wx.dll module configuration? Something like:
>>
>> WX.DLL
>> - LUA5.1.DLL
>> - WXLUA_MSW28_WXBIND.DLL
>> --- LUA5.1.DLL
>> --- WXLUA_MSW28_WXLUA.DLL
>> --- WXMSW28_GCC_DS.DLL
>> - WXLUA_MSW28_WXLUA.DLL
>> --- LUA5.1.DLL
>> --- WXMSW28_GCC_DS.DLL
>> - WXMSW28_GCC_DS.DLL
> Absolutely: if we want to have wx.dll as a good Lua module we need to 
> build instead of WXLUA_MSW28_WXLUA.DLL a LUA5.1.DLL. That's exactly what 
> I say in "wxLua module" thread.
> 

Yes. You did. Sorry.

> This has the side effect of replacing any user's lua5.1 library when 
> doing "make install" but I think this is really not worth the extra the 
> dependency which wx.dll currently has.
> 
> Francesco
> 


It may be a radical change but, what about making
lua as -weak- requirement?

- if user already has lua installed use it, install only wxLua
- otherwise build and install lua and wxLua

ps. I never use "make install" on windows.


--
Regards,
Hakki Dogusan

Re: [wxlua-users] wxLua announcement text

[Hakki D. <dog...@tr...>]

Hi,

Francesco Montorsi wrote:
> Hi all,
>    i've added a file under distrib\announce.txt which lists the places where to 
> post the info about the new wxLua release and also the announcement text for it.
> 
> Any comments/suggestions gladly accepted,
> Francesco
> 

Info at LuaAddons would be changed?

#  [wxLua] (5.0) - a blend of Lua and wxWidgets. has its own IDE with a 
debugger. The IDE is written in wxLua.

(5.0) -> (5.1)
+Has a binding generator written in Lua
+Usable as module

Don't know but, if luaforge allows projects hosted elsewhere,
it would be good to have a project there?


--
Regards,
Hakki Dogusan

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

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

Hakki Dogusan ha scritto:
>> 2) do a make clean in wxLua and then retry.
>>
> 
> - did a make clean
> - compiled with
> F:\a_C\wxLua\build\msw>mingw32-make -fmakefile.gcc SHARED=1 
> WX_MONOLITHIC=1 WX_SHARED=1 BUILD=release
> 
> - build stopped with ld error; couldn't find liblua5.1.a
yes, that's related to my other thread "wxLua module"...

> - copied it manually to wxLua\lib\gcc_dll
> - build finished OK.
good


> ps. I was reported this before but..
> DependencyWalker shows following for wx.dll:
> 
> WX.DLL
> - LUA5.1.DLL (lua_getfield)
> - WXLUA_MSW28_WXBIND.DLL
> --- WXLUA_MSW28_LUA.DLL
> --- WXLUA_MSW28_WXLUA.DLL
> --- WXMSW28_GCC_DS.DLL
> - WXLUA_MSW28_WXLUA.DLL
> --- WXLUA_MSW28_LUA.DLL
> --- WXMSW28_GCC_DS.DLL
> - WXMSW28_GCC_DS.DLL
> 
> Could it be possible to have only lua5.1.dll dependency
> for wx.dll module configuration? Something like:
> 
> WX.DLL
> - LUA5.1.DLL
> - WXLUA_MSW28_WXBIND.DLL
> --- LUA5.1.DLL
> --- WXLUA_MSW28_WXLUA.DLL
> --- WXMSW28_GCC_DS.DLL
> - WXLUA_MSW28_WXLUA.DLL
> --- LUA5.1.DLL
> --- WXMSW28_GCC_DS.DLL
> - WXMSW28_GCC_DS.DLL
Absolutely: if we want to have wx.dll as a good Lua module we need to 
build instead of WXLUA_MSW28_WXLUA.DLL a LUA5.1.DLL. That's exactly what 
I say in "wxLua module" thread.

This has the side effect of replacing any user's lua5.1 library when 
doing "make install" but I think this is really not worth the extra the 
dependency which wx.dll currently has.

Francesco

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

[Hakki D. <dog...@tr...>]

Hi,

Francesco Montorsi wrote:
> Hakki Dogusan ha scritto:
>> Hi,
[snip]
>> Funny...
>>
>> I did a cvs update, then continue to compile..
>> Then send the above message.
>>
>> Meanwhile, Francesco were committing his changes :)
> right ;)
> 
> 
>> Now building ends with:
>>
>> (mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1 
>> WX_SHARED=1 BUILD=release)
>>
>>
>> g++ -c -o gccdll\wxbind_dll_config.o
>> -I..\..\..\modules\wxbind\setup
>> -DHAVE_W32API_H
>> -D__WXMSW__
>> -IF:\WX\lib\gcc_dll\msw
>> -IF:\WX\include -DWXUSINGDLL
>> -O2  -I..\..\..\modules
>> -I.\..\..\..
>> -IF:\WX\contrib\include
>> -DWXMAKINGDLL_WXBIND
>> -MT
>> gccdll\wxbind_dll_config.o
>> -MFgccdll\wxbind_dll_config.o.d
>> -MD
>> .../../wxbind/src/config.cpp
>> In file included from F:/WX/include/wx/wx.h:55,
>>                   from ../../wxbind/src/config.cpp:15:
>> F:/WX/include/wx/menu.h: In member function `#`qual_union_type' not 
>> supported by dump_decl#<declaration error>':
>> F:/WX/include/wx/menu.h:36: internal compiler error: in 
>> aggregate_value_p, at function.c:4264
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://www.mingw.org/bugs.shtml> for instructions.
>> mingw32-make[1]: *** [gccdll\wxbind_dll_config.o] Error 1
>> mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
>> mingw32-make: *** [modules] Error 2
> hmmm, I'm going to test mingw ASAP; in the meanwhile I suggest you to:
> 
> 1) verify that you can compile&link a wx sample using that config

F:\wx\samples\minimal>mingw32-make -fmakefile.gcc BUILD=release SHARED=1 
MONOLITHIC=1

Builds OK.

> 2) do a make clean in wxLua and then retry.
> 

- did a make clean
- compiled with
F:\a_C\wxLua\build\msw>mingw32-make -fmakefile.gcc SHARED=1 
WX_MONOLITHIC=1 WX_SHARED=1 BUILD=release

- build stopped with ld error; couldn't find liblua5.1.a
- copied it manually to wxLua\lib\gcc_dll
- build finished OK.


Thanks.

> 
> Francesco
> 
> 

ps. I was reported this before but..
DependencyWalker shows following for wx.dll:

WX.DLL
- LUA5.1.DLL (lua_getfield)
- WXLUA_MSW28_WXBIND.DLL
--- WXLUA_MSW28_LUA.DLL
--- WXLUA_MSW28_WXLUA.DLL
--- WXMSW28_GCC_DS.DLL
- WXLUA_MSW28_WXLUA.DLL
--- WXLUA_MSW28_LUA.DLL
--- WXMSW28_GCC_DS.DLL
- WXMSW28_GCC_DS.DLL

Could it be possible to have only lua5.1.dll dependency
for wx.dll module configuration? Something like:

WX.DLL
- LUA5.1.DLL
- WXLUA_MSW28_WXBIND.DLL
--- LUA5.1.DLL
--- WXLUA_MSW28_WXLUA.DLL
--- WXMSW28_GCC_DS.DLL
- WXLUA_MSW28_WXLUA.DLL
--- LUA5.1.DLL
--- WXMSW28_GCC_DS.DLL
- WXMSW28_GCC_DS.DLL


--
Regards,
Hakki Dogusan

[wxlua-users] wxLua announcement text

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

Hi all,
   i've added a file under distrib\announce.txt which lists the places where to 
post the info about the new wxLua release and also the announcement text for it.

Any comments/suggestions gladly accepted,
Francesco

[wxlua-users] wxLua module (was Re: build system update)

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

Francesco Montorsi ha scritto:
>   2) renamed lua5.1 library built by wxLua to libwxlua_gtk2d_lua-2.8.a; 
> that is, to a lib which follows wxLua naming conventions. This is more 
> coherent with the way we call the (vanilla) lua intepreter which we 
> build: wxlua-lua. That is, if we care about not replacing the 
> system-wide "lua" executable, we should care also about not replacing 
> the system-wide "lua5.1" library.
> 
> I don't remember why we decided to call our verbatim lua library 
> "lua5.1"... do you see anything wrong with calling it using our naming 
> convention?
Ok, I now remember why we decided to call it lua5.1; the wx.dll module we build 
from modules\luamodule is coinceived to be used as any other Lua module.  I.e. 
it must be linked against a DLL/DSO named "lua5.1" not "wxlua_msw28_lua".

So, I think we have no other choice that making our "lua" module build a library 
named lua5.1 and then install it in standard paths, eventually overwriting the 
preexisting one.

This should not be a big problem since the name is versioned and we're using 
vanilla lua now. It may just be a problem if someone modified lua and thus has 
in system paths a custom version (but this is a bad practice anyway; that user 
should consider to name its custom library in some other way).

Do you agree with this change?

Once we get this up and running I think we should also

   1) add our "wx" module to this list:

       http://lua-users.org/wiki/LuaBinaryModules (look at the end)

   2) publish in the next release a single .ZIP download which contains only the 
wxLua+wxWidgets DLLs + wx.dll module; so that users could just unzip them and 
start using wx.dll module as for any other lua module.


Francesco

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

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

Hakki Dogusan ha scritto:
> Hi,
> 
> Hakki Dogusan wrote:
>> Hi,
>>
>> John Labenski wrote:
>>> Everything else seems great, I'm using VC 2003 and nmake.exe and both
>>> release and debug work even with the wxStEditor lib!
>>>
>>> But, for SHARED=1 the paths for the dlls are
>>> ..\..\lib\wxmsw_msw26_wxlua.dll
>>> but should be
>>> ..\..\..\lib\[vc_dll]\wxmsw_msw26_wxlua.dll
>>>
>> [snip]
>>
>> FYI,
>>
>> (cvs 2006-12-17, wx2.8, winxp)
>>
>> I tried with mingw:
>> mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1
>>
>> It gives:
>> F:\mingw\BIN\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: 
>> cannot open output file ..\..\lib\wxlua_msw28d_lua.dll: No such file or 
>> directory collect2: ld returned 1 exit status
>> mingw32-make[1]: *** [..\..\lib\wxlua_msw28d_lua.dll] Error 1
>> mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
>> mingw32-make: *** [modules] Error 2
>>
>>
>> Since, I had similar results with modified (as your's but with gcc_dll)
>> makefile.gcc with a recent cvs, I didn't try it again.
>>
>> There is no problem in SHARED=0 configuration.
>>
>>
> 
> Funny...
> 
> I did a cvs update, then continue to compile..
> Then send the above message.
> 
> Meanwhile, Francesco were committing his changes :)
right ;)


> Now building ends with:
> 
> (mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1 
> WX_SHARED=1 BUILD=release)
> 
> 
> g++ -c -o gccdll\wxbind_dll_config.o
> -I..\..\..\modules\wxbind\setup
> -DHAVE_W32API_H
> -D__WXMSW__
> -IF:\WX\lib\gcc_dll\msw
> -IF:\WX\include -DWXUSINGDLL
> -O2  -I..\..\..\modules
> -I.\..\..\..
> -IF:\WX\contrib\include
> -DWXMAKINGDLL_WXBIND
> -MT
> gccdll\wxbind_dll_config.o
> -MFgccdll\wxbind_dll_config.o.d
> -MD
> .../../wxbind/src/config.cpp
> In file included from F:/WX/include/wx/wx.h:55,
>                   from ../../wxbind/src/config.cpp:15:
> F:/WX/include/wx/menu.h: In member function `#`qual_union_type' not 
> supported by dump_decl#<declaration error>':
> F:/WX/include/wx/menu.h:36: internal compiler error: in 
> aggregate_value_p, at function.c:4264
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.mingw.org/bugs.shtml> for instructions.
> mingw32-make[1]: *** [gccdll\wxbind_dll_config.o] Error 1
> mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
> mingw32-make: *** [modules] Error 2
hmmm, I'm going to test mingw ASAP; in the meanwhile I suggest you to:

1) verify that you can compile&link a wx sample using that config
2) do a make clean in wxLua and then retry.


Francesco

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

[Hakki D. <dog...@tr...>]

Hi,

Hakki Dogusan wrote:
> Hi,
> 
> John Labenski wrote:
>> Everything else seems great, I'm using VC 2003 and nmake.exe and both
>> release and debug work even with the wxStEditor lib!
>>
>> But, for SHARED=1 the paths for the dlls are
>> ..\..\lib\wxmsw_msw26_wxlua.dll
>> but should be
>> ..\..\..\lib\[vc_dll]\wxmsw_msw26_wxlua.dll
>>
> [snip]
> 
> FYI,
> 
> (cvs 2006-12-17, wx2.8, winxp)
> 
> I tried with mingw:
> mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1
> 
> It gives:
> F:\mingw\BIN\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: 
> cannot open output file ..\..\lib\wxlua_msw28d_lua.dll: No such file or 
> directory collect2: ld returned 1 exit status
> mingw32-make[1]: *** [..\..\lib\wxlua_msw28d_lua.dll] Error 1
> mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
> mingw32-make: *** [modules] Error 2
> 
> 
> Since, I had similar results with modified (as your's but with gcc_dll)
> makefile.gcc with a recent cvs, I didn't try it again.
> 
> There is no problem in SHARED=0 configuration.
> 
> 

Funny...

I did a cvs update, then continue to compile..
Then send the above message.

Meanwhile, Francesco were committing his changes :)


Now building ends with:

(mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1 
WX_SHARED=1 BUILD=release)


g++ -c -o gccdll\wxbind_dll_config.o
-I..\..\..\modules\wxbind\setup
-DHAVE_W32API_H
-D__WXMSW__
-IF:\WX\lib\gcc_dll\msw
-IF:\WX\include -DWXUSINGDLL
-O2  -I..\..\..\modules
-I.\..\..\..
-IF:\WX\contrib\include
-DWXMAKINGDLL_WXBIND
-MT
gccdll\wxbind_dll_config.o
-MFgccdll\wxbind_dll_config.o.d
-MD
../../wxbind/src/config.cpp
In file included from F:/WX/include/wx/wx.h:55,
                  from ../../wxbind/src/config.cpp:15:
F:/WX/include/wx/menu.h: In member function `#`qual_union_type' not 
supported by dump_decl#<declaration error>':
F:/WX/include/wx/menu.h:36: internal compiler error: in 
aggregate_value_p, at function.c:4264
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
mingw32-make[1]: *** [gccdll\wxbind_dll_config.o] Error 1
mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
mingw32-make: *** [modules] Error 2




--
Regards,
Hakki Dogusan

Re: [wxlua-users] wxLuaIDE

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

klaas.holwerda ha scritto:
>> What about just adding the path $(WXLUA) to your include path and then
>> include this in the header
>> #include "apps/wxluaedit/src/wxledit.h"
>> and this in the cpp file
>> #include "apps/wxluaedit/src/wxledit.cpp"
>>   
> In that case better copy, since how will users understand such things.
> Currently i do already set WXLUA (after installing), just to get to the 
> script for generating the bindings.
> This is part of the Cmake files. But not needed, if using a released 
> distribution, so acceptable.
> But asking users to have wxLua installed, and the wxLua source to get to 
> the two wxledit files, is a bit to much.
I agree.

I also think that having a stock dialog for running wxLua scripts and 
maybe debug them would be very nice. Unfortunately I don't really know 
much about wxLua internals and wxStEdit, so here it is my dumb question:
do such things need wxStEdit? wouldn't it be possible to add such things 
to "wxlua" module _without_ making it depending on wxStEdit?

If it's really required, maybe we could still add it to wxlua module and 
then use wxDynamicLibrary stuff to open wxstedit.dll at runtime, if present.

>> It's a little unconventional, but will easily work. The only thing is
>> that it won't work if you install wxlua to a system directory? Do you
>> do that?
>>   
> Yes, that i always do. 
I always do that, too ;)


>> On the code editor standpoint, I haven't found  good one for Linux. I
>> just use my editor in the modules directory to load all the files.
>> $wxStEdit -r *.h *.cpp &
>>   
> You should have a look at krusader, almost the same as windows commander 
> on windows.
> I use it for almost anything (edit, search, pack, browse dirs.).
I'm now get used to KATE. It's great I think.

Just my 2 cents,
Francesco

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

[Hakki D. <dog...@tr...>]

Hi,

John Labenski wrote:
> Everything else seems great, I'm using VC 2003 and nmake.exe and both
> release and debug work even with the wxStEditor lib!
> 
> But, for SHARED=1 the paths for the dlls are
> ..\..\lib\wxmsw_msw26_wxlua.dll
> but should be
> ..\..\..\lib\[vc_dll]\wxmsw_msw26_wxlua.dll
> 
[snip]

FYI,

(cvs 2006-12-17, wx2.8, winxp)

I tried with mingw:
mingw32-make -fmakefile.gcc WX_VERSION=28 WX_MONOLITHIC=1 SHARED=1

It gives:
F:\mingw\BIN\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: 
cannot open output file ..\..\lib\wxlua_msw28d_lua.dll: No such file or 
directory collect2: ld returned 1 exit status
mingw32-make[1]: *** [..\..\lib\wxlua_msw28d_lua.dll] Error 1
mingw32-make[1]: Leaving directory `F:/a_C/wxLua/modules/build/msw'
mingw32-make: *** [modules] Error 2


Since, I had similar results with modified (as your's but with gcc_dll)
makefile.gcc with a recent cvs, I didn't try it again.

There is no problem in SHARED=0 configuration.


--
Regards,
Hakki Dogusan

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

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

klaas.holwerda ha scritto:
> John Labenski wrote:
>> Everything else seems great, 
> It does, every day its better :-)
>> I'm using VC 2003 and nmake.exe and both
>> release and debug work even with the wxStEditor lib!
>>   
> Yep. just setting WXSTEDIT as env., where would we be without Francesco :-)
Thanks ;)

> 
> Should we change the default to 2.8 now? In the makefiles i mean.
right, I've done it and committed.


>> Grrrr :/
>>   
> WX_PRESETS i think Francesco has nightmares around this word :-)
I just hope that all my work won't be rejected with a "it doesn't make 
sense" short sentence as it was 2-3 years ago (but I admit that at that 
time my patch was a bit messy).

Francesco

[wxlua-users] wxLua on wxMac

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

Hi all|Anders Björklund,

    is anyone out there using wxLua on a mac?

We would be glad to publish new wxLua screenshots for wxMac, and to fix 
any problem with mac-bundling, if there's any, before 2.8.0.0

Thanks!
Francesco

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

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

John Labenski ha scritto:
> Everything else seems great, I'm using VC 2003 and nmake.exe and both
> release and debug work even with the wxStEditor lib!
great!


> But, for SHARED=1 the paths for the dlls are
> ..\..\lib\wxmsw_msw26_wxlua.dll
> but should be
> ..\..\..\lib\[vc_dll]\wxmsw_msw26_wxlua.dll
> 
> Also, I see in the changelog that lib\vc_dll is now only \lib, see
> line 305 here.
> http://wxlua.cvs.sourceforge.net/wxlua/wxLua/modules/build/msw/makefile.vc?r1=1.53&r2=1.54
> 
> I can't find the change to common.bkl? that caused this.
I did a dummy change which removed vc_dll; fixed now, sorry.


> wxWidgets seems to build it's libs in only
> lib/vc_lib  for all lib builds release, debug, unicode
> lib/vc_dll  for all dll builds release, debug, unicode
> 
> Can we change it to this? Is this something else that should be in the
> WX_PRESETS? In addition to wxWidgets style lib names, also wxWidgets
> style lib paths?
good idea, maybe I should add a <set-wxlike-builddir/> tag and a 
<wxlike-dirname/> tag. I'll surely look at this!


> I think the only reason to separate lib builds is that if you build a
> lib you get *.lib, but if you buid a dll with the same release, debug,
> unicode settings you get *.lib + *.dll and the *.libs have the same
> names, but conflict due to the DLLIMPEXP symbols.
sure, but currently vc_lib and vc_dll subdirs are already used.

> Finally, (and this is only if it's easy) can we output the *.obj files
> to just "vc_msw[u][d][dll]" like wxWidgets does? Again maybe this
> belongs in WX_PRESETS so that a uniform *.obj file directory structure
> is used. (I know this is not important, but if the code could be in
> the WXPRESETS once it doesn't have to be duplicated.)
right, I've done that for wxLua bakefiles and rebaked. I'll look about a 
<set-wxlike-builddir/> tag for wxpresets.


> Sigh... all this would be so much easier if we could just the
> wxWidgets bakefiles in user projects (as I showed how it could be done
> years ago).
sorry but I don't completely agree. wx bakefiles are a huge set of 
bakefiles and debugging them is a nightmare; they're also completely 
oriented to wx itself, not for wx-based programs. I think wxpresets are 
the way to go.
If only my patches were accepted I would be much happier. But it looks 
like there's a solid wall of indifference toward bakefile+wxpresets issue.

Francesco

Re: [wxlua-users] wxLuaIDE

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

John Labenski wrote:
>> http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/
>> in the files luawrap.cpp and luawrap.h
>>     
>
> I don't see that you really do anything special to get it working? The
> class "a2dLuaConsole" as used in this dialog "a2dLuaExecDlg" right?
>   
Right. I normally just call things like Fit(), what special think should 
i try?
I must admit that i am not so good in sizers and how and why what to call.
>
> What about just adding the path $(WXLUA) to your include path and then
> include this in the header
> #include "apps/wxluaedit/src/wxledit.h"
> and this in the cpp file
> #include "apps/wxluaedit/src/wxledit.cpp"
>   
In that case better copy, since how will users understand such things.
Currently i do already set WXLUA (after installing), just to get to the 
script for generating the bindings.
This is part of the Cmake files. But not needed, if using a released 
distribution, so acceptable.
But asking users to have wxLua installed, and the wxLua source to get to 
the two wxledit files, is a bit to much.
> It's a little unconventional, but will easily work. The only thing is
> that it won't work if you install wxlua to a system directory? Do you
> do that?
>   
Yes, that i always do. Do you use  it with --prefix?
> Its ok I guess. I hate to have a whole separate module for just
> wxledit.h/cpp, seems like overkill. Let me know what you think about
> the #include hack above.
>   
You have seen the problem with it already. Also the bitmaps in the art 
directory is a problem, they would need to be installed too, if it were 
a library. So if it not will be a module, i stick to copying for the 
moment. Still wxluacan would be oke to include/use the files like you 
propose.  Maybe a nice add once it starts working.

BTW is  a step mode in scripts possible from the wxLuaIDE class?

> On the code editor standpoint, I haven't found  good one for Linux. I
> just use my editor in the modules directory to load all the files.
> $wxStEdit -r *.h *.cpp &
>   
You should have a look at krusader, almost the same as windows commander 
on windows.
I use it for almost anything (edit, search, pack, browse dirs.).

Klaas

Re: [wxlua-users] wxLuaIDE

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

On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
> John Labenski wrote:
> > On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
> >> It works more or less. E.g. it comes up but i need to resize it a little
> >> to show it properly.
> >
> It stays gray at first, so the wxLuaIDE does not adjust itself to the
> wxDialog that is around it somehow.
> And i don't know  what to call to make it size properly.

I think I should use a sizer to arrange things, maybe it's not getting
a final wxSizeEvent so that the code in wxLuaIDE::OnSize isn't run.

> http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/
> in the files luawrap.cpp and luawrap.h

I don't see that you really do anything special to get it working? The
class "a2dLuaConsole" as used in this dialog "a2dLuaExecDlg" right?

> >> Any way, i would like very much to have this  wxLuaIDE  inside one of
> >> the libaries instead of having it as  part of  a wxLua application.
> >> Then i would not need to copy wxledit.* anymore into wxArt2D.
> >
> > Umm, we alreay have a lot of module libs, it's a little anoying to for
> > me to work on all the little bits, plus since the wxLuaEdit app
> > depends on wxStEdit I think it'd be best to keep it off to the side.
> > Maybe we could build libs for the wxledit.h/cpp files in the wxluaedit
> > app and not make another module directory?
> >
> That would mean more include paths. Is there not an existing module
> where this fits in? Aah wxstedit needed right!
> It would also exclude it from use in wxluacan, which would  be a nice
> demo on how to integrate wxlua scripting  in any app.
> I think a module would be best, although i understand that you are not
> happy with that.

What about just adding the path $(WXLUA) to your include path and then
include this in the header
#include "apps/wxluaedit/src/wxledit.h"
and this in the cpp file
#include "apps/wxluaedit/src/wxledit.cpp"

It's a little unconventional, but will easily work. The only thing is
that it won't work if you install wxlua to a system directory? Do you
do that?

> Maybe we just need a "misc" module, in which we can put all the smaller
> things, which are too small for a new module.

Nah, again it needs wxstedit and I don't think anything else ever will.

> Just curious, why do you find it annoying?, i work with VC IDE and there
> it does not bother me that i have 16 modules?
> Without and IDE, it might be cd'ing a lot, but for that we have krusader
> is't it :-)

Its ok I guess. I hate to have a whole separate module for just
wxledit.h/cpp, seems like overkill. Let me know what you think about
the #include hack above.

On the code editor standpoint, I haven't found  good one for Linux. I
just use my editor in the modules directory to load all the files.
$wxStEdit -r *.h *.cpp &

The problem I have is that all the IDEs I've tried want to generate
build files or other files for me, but all my projects are complete
and I can't find how to not make them be so "helpful". The last I
tried kdevelop was the least intrusive, but I forget why I stopped
using it.

Regards,
    John Labenski

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

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

On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
> John Labenski wrote:

> > wxWidgets seems to build it's libs in only
> > lib/vc_lib  for all lib builds release, debug, unicode
> > lib/vc_dll  for all dll builds release, debug, unicode
> >
> > Can we change it to this?
> I think that was the idea already,  there is already the vc_dll created.
> Or am i miss understanding something?

Oops, you're right. I was looking at the bin/ directory where, yes, we
do have to give them all unique names. Nevermind.

> > Grrrr :/
> >
> WX_PRESETS i think Francesco has nightmares around this word :-)

Heh. :(

-John Labenski

Re: [wxlua-users] makefile.vc has wrong path to lib for DLLs

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

John Labenski wrote:
> Everything else seems great, 
It does, every day its better :-)
> I'm using VC 2003 and nmake.exe and both
> release and debug work even with the wxStEditor lib!
>   
Yep. just setting WXSTEDIT as env., where would we be without Francesco :-)

Should we change the default to 2.8 now? In the makefiles i mean.
> But, for SHARED=1 the paths for the dlls are
> ..\..\lib\wxmsw_msw26_wxlua.dll
> but should be
> ..\..\..\lib\[vc_dll]\wxmsw_msw26_wxlua.dll
>   
Right.
>
> wxWidgets seems to build it's libs in only
> lib/vc_lib  for all lib builds release, debug, unicode
> lib/vc_dll  for all dll builds release, debug, unicode
>
> Can we change it to this? 
I think that was the idea already,  there is already the vc_dll created. 
Or am i miss understanding something?

> Grrrr :/
>   
WX_PRESETS i think Francesco has nightmares around this word :-)

Klaas

Re: [wxlua-users] wxLuaIDE

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

John Labenski wrote:
> On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
>   
>> Hi John,
>>
>> I am rather often now ;-) copying wxledit.cpp and wxledit.h to wxArt2D,
>> to keep up o date.
>>     
>
> Sorry about the rename, the wxLua app had a class called wxLuaConsole already.
>
>   
>> I use wxLuaIDE to have a console to run script from my Application
>> written with wxArt2D.
>> In there wxLuaIDE becomes a subwindow in a wxDialog derived class, just
>> to make it a modeless dialog to run scripts.
>> It works more or less. E.g. it comes up but i need to resize it a little
>> to show it properly.
>>     
>
> What doesn't work right? I'm guessing the splitter position?
>   
It stays gray at first, so the wxLuaIDE does not adjust itself to the 
wxDialog that is around it somehow.
And i don't know  what to call to make it size properly.

http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/

in the files luawrap.cpp and luawrap.h
http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/include/luawrap.h?revision=1.27&view=markup
http://wxart2d.cvs.sourceforge.net/wxart2d/wxArt2D/modules/luawraps/src/luawrap.cpp?revision=1.35&view=markup

>   
>> Any way, i would like very much to have this  wxLuaIDE  inside one of
>> the libaries instead of having it as  part of  a wxLua application.
>> Then i would not need to copy wxledit.* anymore into wxArt2D.
>>     
>
> Umm, we alreay have a lot of module libs, it's a little anoying to for
> me to work on all the little bits, plus since the wxLuaEdit app
> depends on wxStEdit I think it'd be best to keep it off to the side.
> Maybe we could build libs for the wxledit.h/cpp files in the wxluaedit
> app and not make another module directory?
>   
That would mean more include paths. Is there not an existing module 
where this fits in? Aah wxstedit needed right!
It would also exclude it from use in wxluacan, which would  be a nice 
demo on how to integrate wxlua scripting  in any app.
I think a module would be best, although i understand that you are not 
happy with that.
Maybe we just need a "misc" module, in which we can put all the smaller 
things, which are too small for a new module.

Just curious, why do you find it annoying?, i work with VC IDE and there 
it does not bother me that i have 16 modules?
Without and IDE, it might be cd'ing a lot, but for that we have krusader 
is't it :-)
>   
>> Also  i think it would be  good to have  inside the library some
>> standard dialogs to work with wxLua script inside an application. WxLua
>> being meant to integrate with application, to extend it with scripting,
>> currently does need some work to get a nice dialog to run those scripts.
>> The best way would be to have some ready made IDE dialog (modeless or
>> modal), to run and maybe debug application scripts.
>> Like step through a script line by line. I think it is all there
>> already, but because it not inside a library, it is a bit copy/paste to
>> use it.
>>     
>
> I'm not sure exactly what you mean. I think you're saying that you
> would like a wxDialog with a child wxLuaIDE to run scripts in. Maybe
> you can point me to the code using web cvs to see what you actually
> need to do to make this work? 
See above, it is exactly what you say that i have.
> I also use the wxLuaIDE, but I don't
> think I need to do all that much to it, it's just a window in a
> notebook page.
>   
Right, and copy wxledit.* plus the art/*.bmp etc.  ;-)
>   
>> If we had such a dialog, we could use wxluacan to test it, currently it
>> just has this menu to choose a script to run.
>>     
>
> Sure, but again, this adds the wxStEdit dependency which makes things
> harder for people to compile it.
>   
wxLua already detects if wxstedit is available, if its not, it is not 
included. I think Francesco does not find it much of a problem to arrange.
At least on Unix.

Thanks,

Klaas

[wxlua-users] makefile.vc has wrong path to lib for DLLs

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

Everything else seems great, I'm using VC 2003 and nmake.exe and both
release and debug work even with the wxStEditor lib!

But, for SHARED=1 the paths for the dlls are
..\..\lib\wxmsw_msw26_wxlua.dll
but should be
..\..\..\lib\[vc_dll]\wxmsw_msw26_wxlua.dll

Also, I see in the changelog that lib\vc_dll is now only \lib, see
line 305 here.
http://wxlua.cvs.sourceforge.net/wxlua/wxLua/modules/build/msw/makefile.vc?r1=1.53&r2=1.54

I can't find the change to common.bkl? that caused this.

wxWidgets seems to build it's libs in only
lib/vc_lib  for all lib builds release, debug, unicode
lib/vc_dll  for all dll builds release, debug, unicode

Can we change it to this? Is this something else that should be in the
WX_PRESETS? In addition to wxWidgets style lib names, also wxWidgets
style lib paths?

I think the only reason to separate lib builds is that if you build a
lib you get *.lib, but if you buid a dll with the same release, debug,
unicode settings you get *.lib + *.dll and the *.libs have the same
names, but conflict due to the DLLIMPEXP symbols.

Finally, (and this is only if it's easy) can we output the *.obj files
to just "vc_msw[u][d][dll]" like wxWidgets does? Again maybe this
belongs in WX_PRESETS so that a uniform *.obj file directory structure
is used. (I know this is not important, but if the code could be in
the WXPRESETS once it doesn't have to be duplicated.)

Sigh... all this would be so much easier if we could just the
wxWidgets bakefiles in user projects (as I showed how it could be done
years ago). That way wxWidgets users use the same bakefile code as the
library itself and guarantee that everything is the same and any
updates to wxWidgets don't have to be duplicated in the wxpresets!
Grrrr :/

Thanks,
     John Labenski

Re: [wxlua-users] wxLuaIDE

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

On 12/15/06, klaas.holwerda <kho...@xs...> wrote:
> Hi John,
>
> I am rather often now ;-) copying wxledit.cpp and wxledit.h to wxArt2D,
> to keep up o date.

Sorry about the rename, the wxLua app had a class called wxLuaConsole already.

> I use wxLuaIDE to have a console to run script from my Application
> written with wxArt2D.
> In there wxLuaIDE becomes a subwindow in a wxDialog derived class, just
> to make it a modeless dialog to run scripts.
> It works more or less. E.g. it comes up but i need to resize it a little
> to show it properly.

What doesn't work right? I'm guessing the splitter position?

> Any way, i would like very much to have this  wxLuaIDE  inside one of
> the libaries instead of having it as  part of  a wxLua application.
> Then i would not need to copy wxledit.* anymore into wxArt2D.

Umm, we alreay have a lot of module libs, it's a little anoying to for
me to work on all the little bits, plus since the wxLuaEdit app
depends on wxStEdit I think it'd be best to keep it off to the side.
Maybe we could build libs for the wxledit.h/cpp files in the wxluaedit
app and not make another module directory?

> Also  i think it would be  good to have  inside the library some
> standard dialogs to work with wxLua script inside an application. WxLua
> being meant to integrate with application, to extend it with scripting,
> currently does need some work to get a nice dialog to run those scripts.
> The best way would be to have some ready made IDE dialog (modeless or
> modal), to run and maybe debug application scripts.
> Like step through a script line by line. I think it is all there
> already, but because it not inside a library, it is a bit copy/paste to
> use it.

I'm not sure exactly what you mean. I think you're saying that you
would like a wxDialog with a child wxLuaIDE to run scripts in. Maybe
you can point me to the code using web cvs to see what you actually
need to do to make this work? I also use the wxLuaIDE, but I don't
think I need to do all that much to it, it's just a window in a
notebook page.

> If we had such a dialog, we could use wxluacan to test it, currently it
> just has this menu to choose a script to run.

Sure, but again, this adds the wxStEdit dependency which makes things
harder for people to compile it.

Regards,
    John Labenski

[wxlua-users] wxLuaIDE

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

Hi John,

I am rather often now ;-) copying wxledit.cpp and wxledit.h to wxArt2D, 
to keep up o date.

I use wxLuaIDE to have a console to run script from my Application 
written with wxArt2D.
In there wxLuaIDE becomes a subwindow in a wxDialog derived class, just 
to make it a modeless dialog to run scripts.
It works more or less. E.g. it comes up but i need to resize it a little 
to show it properly.

Any way, i would like very much to have this  wxLuaIDE  inside one of 
the libaries instead of having it as  part of  a wxLua application.
Then i would not need to copy wxledit.* anymore into wxArt2D.
Also  i think it would be  good to have  inside the library some 
standard dialogs to work with wxLua script inside an application. WxLua 
being meant to integrate with application, to extend it with scripting, 
currently does need some work to get a nice dialog to run those scripts.
The best way would be to have some ready made IDE dialog (modeless or 
modal), to run and maybe debug application scripts.
Like step through a script line by line. I think it is all there 
already, but because it not inside a library, it is a bit copy/paste to 
use it.

If we had such a dialog, we could use wxluacan to test it, currently it 
just has this menu to choose a script to run.

Do you think this is possible?

Klaas

Re: [wxlua-users] wxLua users please comment : Do we want stricter type checking?

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

Ok well, based on everyones agreement I'll make things a little
stricter to provide a little better error checking. You'll get a
message along the lines of "expected XXX but got YYY".

Regards,
    John Labenski

On 12/13/06, Eero Pajarre <epa...@ko...> wrote:
> Francesco Montorsi wrote:
>
> > BASIC (I started programming with it ;)) had an "Option Explicit"
> > statement which allowed to turn on & off at run-time the creation of the
> > variables on the fly:
>
> I have been using the "strict.lua" code piece with my wxLua applications,
> and it seems to catch my "mistyped a variable name" errors quite well.
>
>
>         Eero
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Re: [wxlua-users] about web activity

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

On 12/13/06, Hakki Dogusan <dog...@tr...> wrote:
> Hi,
>
> You could see in lua list, there is a common saying like:
>
>  > I think this could be good for the community to have at least one GUI
>  > maintained consistently and extensively across time.
>
> I replied that message -with my excellent english! -
>
> Just FYI, wxLua is maintained actively :)
> We just don't see it in http://wxlua.sf.net web site...
>
> I'm posting here for:
> "Please put/distribute some news about your wonderfull workings"
>
> Please...

Yes, yes. You're very right and it does look bad that from the website
you'd never know that anything was happening.

I will try to post news about the site when things are updated.

Thanks,
    John Labenski