wxlua-users — wxLua list for users and developers

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

John Labenski ha scritto:
> On 12/9/06, Francesco Montorsi <f18...@ya...> wrote:
>>   1) renamed "app_lua" to "app_verbatimlua" to be coherent with the
>> relative module which is called "verbatimlua_lib".
> 
> I think it might be better/simpler to just name it app_lua and
> lib_lua, since we only have one copy of lua now.
however the "verbatim" attribute suggests that those are "vanilla" 
versions of lua - so I'd rather keep it.


>>   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
> 
> Good idea, I guess the lua lib really only has two forms release and
> debug though?
yes, exactly... however it's really much easier to name it using wxLua 
rules even if e.g. libwxlua_gtk2d_lua-2.8.a is going to be (I haven't 
tested) identical to libwxlua_gtk2ud_lua-2.8.a (note the "u").

>> 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?
> 
> No problem I think it's good.
I have a feeling that if we decided to use lua5.1 as libname there was a 
reason behind it. Maybe it has something to do with DLLs and the wx.dll 
module ?


> 
>>   5) added the wxlike-lib tag to wxLua bakefiles, as well as a
>> AM_SET_WXLIKE_LIBNAME macro to properly detect and link to the wxStEdit
>> library
> 
> What about just using the wxlike-lib for wxlua too? That way the
> wxCode bakefiles will be able to use the libs it generates very
> easily. This is why I'm so interested in naming all the libs using
> wxWidgets like the wxWidgets libs since it becomes easy to mix
> everything together.
I'd say that we shouldn't remove the "wxlua" prefix from our libraries 
but rather modify wxCode's <wxlike-lib> tag to accept a "prefix" 
attribute just as <wxlike-libname> and <wxlike-dllname> currently do.

Unfortunately this is a bit backward-incompatible since if I modify 
<wxlike-lib> tag definition (in wxCode bakefiles) to use 
$(attributes['prefix']) with the current bakefile it would crash if you 
use the <wxlike-lib> tag without explicitely give a prefix attribute; i.e.

  <wxlike-lib>test</wxlike-lib>

would give a Python error when baking saying that attributes['prefix'] 
is used but it does not exist (not defined). This is a problem with 
bakefile and guess what: I've submitted a patch to fix a long time ago 
but it's still not part of bakefile.

In conclusion, I'd currently keep wxLua libs named as they are now and 
in future modify <wxlike-lib> in wxCode bakefiles to take that "prefix" 
extra attribute.


>> I'm sorry I could only test these changes on Unix right now.
>> Tomorrow I'll test them on Windows, too.
> 
> Sounds great, I have some commits on the wxLua program to finish and
> then I'll try it in VC6.
> 
> And of course one more thing...
> 
> Do we need to put the executables in different dirs as well? This is
> part of the problem that Klaas is having when he said that when he
> tries to build both debug and release you can only do one (at least in
> MSVC) since it thinks the exes are up to date and won't do the other
> build. I really like having the exes in the bin dir, but being able to
> have multiple builds compiled at once is also nice on my slow MSW
> machine.
ok, I'm committing now this change to CVS.
The output lib folders will be named e.g. "bin/vcud_dll" or 
"bin/mingwd_lib", etc.

The commit I'm doing also adds PCH support to wxLua. I was tired of the 
super-long compilation times; even if I don't have benchmarks I can say 
that it got a little better (i.e. faster) here after adding PCH...

Unfortunately once more I've only tested these changes on Unix...

Francesco

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

Hi,

klaas.holwerda wrote:
[snip]
> 
> wxmsw28d_wxlua_lua.lib
> wxmsw28d_wxlua_bind.lib
> wxmsw28d_wxlua_debug.lib
> wxmsw28d_wxlua_socket.lib
> etc.
> 

I like that.

Relatively for the shared configuration:

wxmsw28_gcc_"vendor"_wxlua_lua.dll
wxmsw28_gcc_"vendor"_wxlua_bind.dll
wxmsw28u_gcc_"vendor"_wxlua_lua.dll



--
Regards,
Hakki Dogusan

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

John Labenski wrote:
>
>
> What about just using the wxlike-lib for wxlua too? That way the
> wxCode bakefiles will be able to use the libs it generates very
> easily. This is why I'm so interested in naming all the libs using
> wxWidgets like the wxWidgets libs since it becomes easy to mix
> everything together.
>   
So i think you want

wxlua_msw28d_wxbind.lib  Renamed to wxmsw28d_wxbind.lib.

In the last  i see now wxlua, this is why we once decide to use wxlua_ 
as a sort of name space.
I am not sure why wxCode prefers it different. I understand for one lib 
project there is no confusion.
But for project with several modules, i don't like it. Like in wxArt2d i 
have 16 libraries coming from 16 modules.
If there is no name space at the start like wxart2d_mswd28d_curves.lib 
wxart2d_mswd28d_kbool.lib etc. i think it will be harder to find out 
what library comes from what after installation.
Looking at  the wxWidgets naming , i also see  wxbase28.lib, next to 
wxmsw28_core and wxmsw28_stc, i don't see the logic.
I only see "wx" as common namespace, why did they not use wxmsw in front 
of all??
Anyway it seems that all contrib stuff is in the from wxmsw28_nameofcontrib.
So looking at it like that maybe we should have:

wxmsw28d_wxlua_lua.lib
wxmsw28d_wxlua_bind.lib
wxmsw28d_wxlua_debug.lib
wxmsw28d_wxlua_socket.lib
etc.

or if oke:

wxmsw28d_lua_lua.lib
wxmsw28d_lua_bind.lib
wxmsw28d_lua_debug.lib
wxmsw28d_lua_socket.lib

In the end for wxstedit, it is not:

wxmsw28d_wxstedit.lib

but:

wxmsw28d_stedit.lib

So only one time the wx in it.
Like:

wxnamespace+platform+version_libraryset_specificModule.lib

What do we think is best?

Klaas

Re: [wxlua-users] MSW problems

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

Francesco Montorsi wrote:
> well, looking better at your post, probably my changes won't help you.
> It looks like wxStEdit and wxBindSTC are not fully 2.8-ready...
>   
Not only, its seems to be in both, i think 2.7.2 was different, and 
2.8.3 was like 2.6 again when it comes to those functions.
>>> Next i did not find lua5.1.exe anymore? Is that right? I used it to 
>>> generate my own bindings.
>>> Should i use wxLua.exe??
>>>       
> no, just wxlua-lua.exe . However I'm not still 100% sure we are settled 
> down with that name.
>
> Just as for the name of the vanilla lua library which we build in wxLua, 
> I've some doubt. We have two choices:
>
>   1) call it using "standard" lua names (lua5.1.lib and lua.exe) and 
> overwrite the user's system-wide installations of these files when doing 
> "make install"
>   
I would have no problem with this, but have the same on  MSW and Unix.
But installing is not needed i think??
>   2) call it using wxLua-way of naming so we're sure we don't override 
> anything.
>   
Fine too :-) Better i think, since it is only for us.
> Currently I've setup bakefiles to go with #2 but I have the feeling I'm 
> missing something which may go in favour of #1.... do I ?
>   
The think i need on  MSW and Unix is a lua executable, to generate my 
binding ( Cmake, so all happens on CLient side ).
So ideally, i take it from wxLua. The name is not so important, but i 
prefer no 5.1 in it, since it makes the scripts version dependent
without need in my case.

Regards

Klaas

Re: [wxlua-users] MSW problems

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

John Labenski wrote:
> On 12/9/06, Francesco Montorsi <f18...@ya...> wrote:
>   
>> well, looking better at your post, probably my changes won't help you.
>> It looks like wxStEdit and wxBindSTC are not fully 2.8-ready...
>>     
>
> They should be updated and work in GTK. Klaas, the errors you get seem
> like mixed headers? For example wxSTC had GetCaretLineBack in 2.6, but
> now has GetCaretLineBackground and it's #ifdefed for 2.7.1 (when the
> change occurred) in stc.cpp.
>   
As you see in th erros it comes from the right place. I checked stc.h in 
2.8.3rc, and it contains
SetCaretLineBack() and not as you say ,GetCaretLineBackground() i don't 
think i am doing it wrong, because that means i am doing the same wrong 
at work,where the problem is the same.
> You've got 2.6 headers in your 2.8... in 2.6 wxVideoMode is a struct
> in 2.8 it's a class. Check your $(WXWIN) var.
>   
I will check once more, but can it be something else?
>   
>>>> Next i did not manage to build in release:
>>>>
>>>> nmake -f makefile.vc BUILD=release
>>>> does nothing if debug is already build.
>>>>         
>> I'll look at this tomorrow
>>     
>
> See other message... It'd be nice to be able to build them all at
> once. Maybe separate dirs in bin?
>   
That is not even the case for wxWidgets itself :-)

Klaas

>   

Re: [wxlua-users] MSW problems

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

On 12/9/06, Francesco Montorsi <f18...@ya...> wrote:
> well, looking better at your post, probably my changes won't help you.
> It looks like wxStEdit and wxBindSTC are not fully 2.8-ready...

They should be updated and work in GTK. Klaas, the errors you get seem
like mixed headers? For example wxSTC had GetCaretLineBack in 2.6, but
now has GetCaretLineBackground and it's #ifdefed for 2.7.1 (when the
change occurred) in stc.cpp.

You've got 2.6 headers in your 2.8... in 2.6 wxVideoMode is a struct
in 2.8 it's a class. Check your $(WXWIN) var.

> >> Next i did not manage to build in release:
> >>
> >> nmake -f makefile.vc BUILD=release
> >> does nothing if debug is already build.
> I'll look at this tomorrow

See other message... It'd be nice to be able to build them all at
once. Maybe separate dirs in bin?

> >> Next i did not find lua5.1.exe anymore? Is that right? I used it to
> >> generate my own bindings.
> >> Should i use wxLua.exe??
> no, just wxlua-lua.exe . However I'm not still 100% sure we are settled
> down with that name.
>
> Just as for the name of the vanilla lua library which we build in wxLua,
> I've some doubt. We have two choices:
>
>   1) call it using "standard" lua names (lua5.1.lib and lua.exe) and
> overwrite the user's system-wide installations of these files when doing
> "make install"
>
>   2) call it using wxLua-way of naming so we're sure we don't override
> anything.
>
> Currently I've setup bakefiles to go with #2 but I have the feeling I'm
> missing something which may go in favour of #1.... do I ?

I think I'm leaning towards #2 now... #1 is probably easier and less
confusing, but there's the overwriting problem.

Thanks, I think things are really shaping up for a very nice 2.8 release.
    John Labenski

Re: [wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

On 12/9/06, Francesco Montorsi <f18...@ya...> wrote:
>   1) renamed "app_lua" to "app_verbatimlua" to be coherent with the
> relative module which is called "verbatimlua_lib".

I think it might be better/simpler to just name it app_lua and
lib_lua, since we only have one copy of lua now.

>   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

Good idea, I guess the lua lib really only has two forms release and
debug though?

> 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 know what to do about this, but I think it is bad form to
overwrite the lua executables installed by a rpm or deb package.

> 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?

No problem I think it's good.

>   5) added the wxlike-lib tag to wxLua bakefiles, as well as a
> AM_SET_WXLIKE_LIBNAME macro to properly detect and link to the wxStEdit
> library

What about just using the wxlike-lib for wxlua too? That way the
wxCode bakefiles will be able to use the libs it generates very
easily. This is why I'm so interested in naming all the libs using
wxWidgets like the wxWidgets libs since it becomes easy to mix
everything together.

> I'm sorry I could only test these changes on Unix right now.
> Tomorrow I'll test them on Windows, too.

Sounds great, I have some commits on the wxLua program to finish and
then I'll try it in VC6.

And of course one more thing...

Do we need to put the executables in different dirs as well? This is
part of the problem that Klaas is having when he said that when he
tries to build both debug and release you can only do one (at least in
MSVC) since it thinks the exes are up to date and won't do the other
build. I really like having the exes in the bin dir, but being able to
have multiple builds compiled at once is also nice on my slow MSW
machine.

Thanks,
    John Labenski

Re: [wxlua-users] MSW problems

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

well, looking better at your post, probably my changes won't help you.
It looks like wxStEdit and wxBindSTC are not fully 2.8-ready...


>> Next i did not manage to build in release:
>>
>> nmake -f makefile.vc BUILD=release
>> does nothing if debug is already build.
I'll look at this tomorrow


>> Next i did not find lua5.1.exe anymore? Is that right? I used it to 
>> generate my own bindings.
>> Should i use wxLua.exe??
no, just wxlua-lua.exe . However I'm not still 100% sure we are settled 
down with that name.

Just as for the name of the vanilla lua library which we build in wxLua, 
I've some doubt. We have two choices:

  1) call it using "standard" lua names (lua5.1.lib and lua.exe) and 
overwrite the user's system-wide installations of these files when doing 
"make install"

  2) call it using wxLua-way of naming so we're sure we don't override 
anything.

Currently I've setup bakefiles to go with #2 but I have the feeling I'm 
missing something which may go in favour of #1.... do I ?

Francesco

[wxlua-users] build system update (was Re: wxLua now uses an unmodified copy of lua 5.1.1)

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

Hi John,
    here is a list of the fixes I've checked in:

  1) renamed "app_lua" to "app_verbatimlua" to be coherent with the 
relative module which is called "verbatimlua_lib".

  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?

  3) removed those wxlhandl* files you asked

  4) removed unused DSP files and updated wxLua.dsw (which is not 
updated automatically)

  5) added the wxlike-lib tag to wxLua bakefiles, as well as a 
AM_SET_WXLIKE_LIBNAME macro to properly detect and link to the wxStEdit 
library

I'm sorry I could only test these changes on Unix right now.
Tomorrow I'll test them on Windows, too.

Francesco


BTW: thanks for remembering me about wxlike-lib tag; I forgot that in 
the "wxpresets big enhancement" patch which I submitted to wxWidgets 
project - added now.
Hopefully if/when that patch will be part of wxWidgets we will be able 
to remove a lot of stuff from wxLua CVS ;)


John Labenski ha scritto:
> Finally, is it possible to copy this in build/bakefiles/wxluabase.bkl
> <define-tag name="wxlua-lib" rules="exe,dll,module">
> for stedit? Maybe just making it a wxlike-lib as used in wxcode?
> <define-tag name="wxlike-lib" rules="exe,dll,module">
> 
> I think it's the same as the wxlua libs, just without the leading
> "wxlua_". Hopefully we'll be able to build it right out of the box.
> Currently you have to copy the wxStEdit lib to just stedit.lib.
> 
> Thanks,
>      John Labenski
> 
> 
> 
> 
> 
> On 12/8/06, John Labenski <jla...@gm...> wrote:
>> On 12/8/06, Francesco Montorsi <f18...@ya...> wrote:
>>> Francesco Montorsi ha scritto:
>>>>> It looks like the object files for VC for the mod_wxlua (for example)
>>>>> go into wxLua/modules/build/msw/msvc6prjd/mod_wxlua for all of these
>>>>> builds
>>>>>
>>>>> I think it's ok for for monolithic and multilib, but the dll ones have
>>>>> to go somewhere else since if you use batch build in VC to build both
>>>>> Debug and DLL Debug it starts getting all sorts of errors/warnings
>>>>> about wrong function signatures after the first lib is compiled since
>>>>> I assume that it's using the same object files for both, but the
>>>>> WXEXPORT is different.
>>>> Ok, I'll set BUILDDIR to something like
>>>> "compiler-name[u][d]_shared/static" so that there should be no clashes
>>>> anymore.
>>> I've tested my changes also under Windows but I've just noticed a thing: how
>>> could object files for the two types of build conflict since statically-compiled
>>> object files are named "wxbind_lib_etcetc" while shared-compiled are named
>>> "wxbind_dll_etcetc" ?
>>> They also go in different folders (e.g. vc_lib and vc_dll) so maybe my change to
>>> BUILDDIR didn't help...
>> I don't get any errors now, so I think it fixed it! I used batch build
>> and built the multilib debug and debug DLL at the same time. I do see
>> that VC creates a binary BuildLog.htm (which is not html at all) in
>> the *.obj dir and maybe that messes things up? wxWidgets also
>> separates the files so I think it's probably necessary.
>>
>> Could you remove the /D WXLUA_LUA_NEWTHREAD since we don't need it? I
>> don't see it in the bakefiles, but it's in modules_mod_lua.dsp, maybe
>> just a rebake will do it? I will edit the docs to remove the comment
>> about it.
>>
>> Also, the lua.5.1.lib and exe is linked to all the wxwidgets libs, can
>> that be turned off?
>>
>> Also as you said, maybe we should remove modules_mod_verbatimlua.dsp
>> and the verbatim build and just have modules_mod_lua.dsp since we only
>> have one lua now. Same here, apps/build/msw/apps_app_verbatimlua.dsp.
>> They look identical to me except for the name.
>>
>> Finally could you remove these two files before rebaking since we
>> don't need them anymore now that the debugger server is a
>> wxEvtHandler.
>> wxLua/modules/wxluasocket/src/wxlhandl.cpp
>> wxLua/modules/wxluasocket/include/wxlhandl.h
>>
>> Could you do this stuff? I will definitely try to build your bakefile
>> this weekend and see if I can manage the files myself in the future. I
>> would like you to rebake them so that when I try to redo it without
>> any changes no files should be modified and I'll know that things are
>> working.
>>
>> Thanks,
>>      John Labenski
>>
> 
> -------------------------------------------------------------------------
> 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

Re: [wxlua-users] MSW problems

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

Hi Klaas,
    sorry for the troubles. Try to wait until tomorrow morning. I'm 
trying to fix a little problem with autoconf's format and as soon as 
possible I'll commit a series of fixes which hopefully should fix 
compilation problems (I fear I broke the build system with the commits 
in the last few hours)...

Francesco


klaas.holwerda ha scritto:
> Hi,
> 
> Latest CVS, VC2003. wxWidgets.2.8.3rc
> 
> I have several problems.
> 
> During build i get errors, same as with the latest download of wxstedit.
> See the down here. Easy to correct, but needs some switches here and there.
> 
> Next i did not manage to build in release:
> 
> nmake -f makefile.vc BUILD=release
> does nothing if debug is already build.
> 
> Next i did not find lua5.1.exe anymore? Is that right? I used it to 
> generate my own bindings.
> Should i use wxLua.exe??
> 
> Rest of the changes i did manage :-)
> 
> Thanks,
> 
> Klaas
> 
> ..\..\..\modules\wxbind\include\wxbind.h(2679) : warning C4099: 
> 'wxVideoMode' :
> type name first seen using 'struct' now seen using 'class'
>         D:\soft\wxwin\wxMSW-2.8.3s\include\wx\vidmode.h(20) : see 
> declaration of
>  'wxVideoMode'
> ..\..\wxbindstc\src\stc.cpp(40) : error C2039: 'GetCaretLineBackground' 
> : is not
>  a member of 'wxStyledTextCtrl'
>         D:\soft\wxwin\wxMSW-2.8.3s\contrib\include\wx\stc\stc.h(1740) : 
> see decl
> aration of 'wxStyledTextCtrl'
> ..\..\wxbindstc\src\stc.cpp(58) : error C2039: 'SetCaretLineBackground' 
> : is not
>  a member of 'wxStyledTextCtrl'
>         D:\soft\wxwin\wxMSW-2.8.3s\contrib\include\wx\stc\stc.h(1740) : 
> see decl
> aration of 'wxStyledTextCtrl'
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
> .NET 2003\
> VC7\BIN\nmake.exe"' : return code '0x2'
> Stop.
> 
> 
> 
> -------------------------------------------------------------------------
> 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] MSW problems

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

Hi,

Latest CVS, VC2003. wxWidgets.2.8.3rc

I have several problems.

During build i get errors, same as with the latest download of wxstedit.
See the down here. Easy to correct, but needs some switches here and there.

Next i did not manage to build in release:

nmake -f makefile.vc BUILD=release
does nothing if debug is already build.

Next i did not find lua5.1.exe anymore? Is that right? I used it to 
generate my own bindings.
Should i use wxLua.exe??

Rest of the changes i did manage :-)

Thanks,

Klaas

..\..\..\modules\wxbind\include\wxbind.h(2679) : warning C4099: 
'wxVideoMode' :
type name first seen using 'struct' now seen using 'class'
        D:\soft\wxwin\wxMSW-2.8.3s\include\wx\vidmode.h(20) : see 
declaration of
 'wxVideoMode'
..\..\wxbindstc\src\stc.cpp(40) : error C2039: 'GetCaretLineBackground' 
: is not
 a member of 'wxStyledTextCtrl'
        D:\soft\wxwin\wxMSW-2.8.3s\contrib\include\wx\stc\stc.h(1740) : 
see decl
aration of 'wxStyledTextCtrl'
..\..\wxbindstc\src\stc.cpp(58) : error C2039: 'SetCaretLineBackground' 
: is not
 a member of 'wxStyledTextCtrl'
        D:\soft\wxwin\wxMSW-2.8.3s\contrib\include\wx\stc\stc.h(1740) : 
see decl
aration of 'wxStyledTextCtrl'
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
.NET 2003\
VC7\BIN\nmake.exe"' : return code '0x2'
Stop.

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

Finally, is it possible to copy this in build/bakefiles/wxluabase.bkl
<define-tag name="wxlua-lib" rules="exe,dll,module">
for stedit? Maybe just making it a wxlike-lib as used in wxcode?
<define-tag name="wxlike-lib" rules="exe,dll,module">

I think it's the same as the wxlua libs, just without the leading
"wxlua_". Hopefully we'll be able to build it right out of the box.
Currently you have to copy the wxStEdit lib to just stedit.lib.

Thanks,
     John Labenski





On 12/8/06, John Labenski <jla...@gm...> wrote:
> On 12/8/06, Francesco Montorsi <f18...@ya...> wrote:
> > Francesco Montorsi ha scritto:
> > >> It looks like the object files for VC for the mod_wxlua (for example)
> > >> go into wxLua/modules/build/msw/msvc6prjd/mod_wxlua for all of these
> > >> builds
> > >>
> > >> I think it's ok for for monolithic and multilib, but the dll ones have
> > >> to go somewhere else since if you use batch build in VC to build both
> > >> Debug and DLL Debug it starts getting all sorts of errors/warnings
> > >> about wrong function signatures after the first lib is compiled since
> > >> I assume that it's using the same object files for both, but the
> > >> WXEXPORT is different.
> > > Ok, I'll set BUILDDIR to something like
> > > "compiler-name[u][d]_shared/static" so that there should be no clashes
> > > anymore.
> > I've tested my changes also under Windows but I've just noticed a thing: how
> > could object files for the two types of build conflict since statically-compiled
> > object files are named "wxbind_lib_etcetc" while shared-compiled are named
> > "wxbind_dll_etcetc" ?
> > They also go in different folders (e.g. vc_lib and vc_dll) so maybe my change to
> > BUILDDIR didn't help...
>
> I don't get any errors now, so I think it fixed it! I used batch build
> and built the multilib debug and debug DLL at the same time. I do see
> that VC creates a binary BuildLog.htm (which is not html at all) in
> the *.obj dir and maybe that messes things up? wxWidgets also
> separates the files so I think it's probably necessary.
>
> Could you remove the /D WXLUA_LUA_NEWTHREAD since we don't need it? I
> don't see it in the bakefiles, but it's in modules_mod_lua.dsp, maybe
> just a rebake will do it? I will edit the docs to remove the comment
> about it.
>
> Also, the lua.5.1.lib and exe is linked to all the wxwidgets libs, can
> that be turned off?
>
> Also as you said, maybe we should remove modules_mod_verbatimlua.dsp
> and the verbatim build and just have modules_mod_lua.dsp since we only
> have one lua now. Same here, apps/build/msw/apps_app_verbatimlua.dsp.
> They look identical to me except for the name.
>
> Finally could you remove these two files before rebaking since we
> don't need them anymore now that the debugger server is a
> wxEvtHandler.
> wxLua/modules/wxluasocket/src/wxlhandl.cpp
> wxLua/modules/wxluasocket/include/wxlhandl.h
>
> Could you do this stuff? I will definitely try to build your bakefile
> this weekend and see if I can manage the files myself in the future. I
> would like you to rebake them so that when I try to redo it without
> any changes no files should be modified and I'll know that things are
> working.
>
> Thanks,
>      John Labenski
>

Re: [wxlua-users] wxlua editor current version

[Andre <ar...@ki...>]

John Labenski <jlabenski@...> writes:

> 
> Fixed in CVS, the problem was with the wxProcess of the debuggee
> sending a temination event, but the debugger doesn't exit until the
> lua program is finished running so the wxLua executable's wxApp was
> still in wxApp::OnInit and the event handlers aren't fully created
> yet. I subclassed wxProcess to avoid running the event handler.
> 
> I've tweaked up the editor as well so that it does a test compile
> before running or debugging to quickly see if there are any obvious
> errors.
> 
> Regards,
>     John Labenski
>

Thank you very much I wish I could have been able to figure it out and really
appreciate you solving it.

Andre

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

On 12/8/06, Francesco Montorsi <f18...@ya...> wrote:
> Francesco Montorsi ha scritto:
> >> It looks like the object files for VC for the mod_wxlua (for example)
> >> go into wxLua/modules/build/msw/msvc6prjd/mod_wxlua for all of these
> >> builds
> >>
> >> I think it's ok for for monolithic and multilib, but the dll ones have
> >> to go somewhere else since if you use batch build in VC to build both
> >> Debug and DLL Debug it starts getting all sorts of errors/warnings
> >> about wrong function signatures after the first lib is compiled since
> >> I assume that it's using the same object files for both, but the
> >> WXEXPORT is different.
> > Ok, I'll set BUILDDIR to something like
> > "compiler-name[u][d]_shared/static" so that there should be no clashes
> > anymore.
> I've tested my changes also under Windows but I've just noticed a thing: how
> could object files for the two types of build conflict since statically-compiled
> object files are named "wxbind_lib_etcetc" while shared-compiled are named
> "wxbind_dll_etcetc" ?
> They also go in different folders (e.g. vc_lib and vc_dll) so maybe my change to
> BUILDDIR didn't help...

I don't get any errors now, so I think it fixed it! I used batch build
and built the multilib debug and debug DLL at the same time. I do see
that VC creates a binary BuildLog.htm (which is not html at all) in
the *.obj dir and maybe that messes things up? wxWidgets also
separates the files so I think it's probably necessary.

Could you remove the /D WXLUA_LUA_NEWTHREAD since we don't need it? I
don't see it in the bakefiles, but it's in modules_mod_lua.dsp. I will
edit the docs to remove the comment about it.

Also, the lua.5.1.lib and exe is linked to all the wxwidgets libs, can
that be turned off?

Also maybe we should remove modules_mod_verbatimlua.dsp and the
verbatim build and just have modules_mod_lua.dsp since we only have
one lua now. Same here, apps/build/msw/apps_app_verbatimlua.dsp. They
look identical to me except for the name.

Finally could you remove these two files before rebaking since we
don't need them anymore now that the debugger server is a
wxEvtHandler.
wxLua/modules/wxluasocket/src/wxlhandl.cpp
wxLua/modules/wxluasocket/include/wxlhandl.h

Could you do this stuff? I will definitely try to build your bakefile
this weekend and see if I can manage the files myself in the future.
The last time (months ago) I ran bakefile_gen with no changes to
anything it rewrote all the files, but it was hard for me to tell
exactly what it did by diffing them so I gave up.

Thanks,
     John Labenski

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

On 12/8/06, Francesco Montorsi <f18...@ya...> wrote:
> Francesco Montorsi ha scritto:
> >> It looks like the object files for VC for the mod_wxlua (for example)
> >> go into wxLua/modules/build/msw/msvc6prjd/mod_wxlua for all of these
> >> builds
> >>
> >> I think it's ok for for monolithic and multilib, but the dll ones have
> >> to go somewhere else since if you use batch build in VC to build both
> >> Debug and DLL Debug it starts getting all sorts of errors/warnings
> >> about wrong function signatures after the first lib is compiled since
> >> I assume that it's using the same object files for both, but the
> >> WXEXPORT is different.
> > Ok, I'll set BUILDDIR to something like
> > "compiler-name[u][d]_shared/static" so that there should be no clashes
> > anymore.
> I've tested my changes also under Windows but I've just noticed a thing: how
> could object files for the two types of build conflict since statically-compiled
> object files are named "wxbind_lib_etcetc" while shared-compiled are named
> "wxbind_dll_etcetc" ?
> They also go in different folders (e.g. vc_lib and vc_dll) so maybe my change to
> BUILDDIR didn't help...

I don't get any errors now, so I think it fixed it! I used batch build
and built the multilib debug and debug DLL at the same time. I do see
that VC creates a binary BuildLog.htm (which is not html at all) in
the *.obj dir and maybe that messes things up? wxWidgets also
separates the files so I think it's probably necessary.

Could you remove the /D WXLUA_LUA_NEWTHREAD since we don't need it? I
don't see it in the bakefiles, but it's in modules_mod_lua.dsp, maybe
just a rebake will do it? I will edit the docs to remove the comment
about it.

Also, the lua.5.1.lib and exe is linked to all the wxwidgets libs, can
that be turned off?

Also as you said, maybe we should remove modules_mod_verbatimlua.dsp
and the verbatim build and just have modules_mod_lua.dsp since we only
have one lua now. Same here, apps/build/msw/apps_app_verbatimlua.dsp.
They look identical to me except for the name.

Finally could you remove these two files before rebaking since we
don't need them anymore now that the debugger server is a
wxEvtHandler.
wxLua/modules/wxluasocket/src/wxlhandl.cpp
wxLua/modules/wxluasocket/include/wxlhandl.h

Could you do this stuff? I will definitely try to build your bakefile
this weekend and see if I can manage the files myself in the future. I
would like you to rebake them so that when I try to redo it without
any changes no files should be modified and I'll know that things are
working.

Thanks,
     John Labenski

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

Francesco Montorsi ha scritto:
> John Labenski ha scritto:
>> ps. Yes there is something that would be nice to have in the build files.
>>
>> It looks like the object files for VC for the mod_wxlua (for example)
>> go into wxLua/modules/build/msw/msvc6prjd/mod_wxlua for all of these
>> builds
>> >From modules_mod_wxlua.dsp
>>
>> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Monolithic"
>> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Multilib"
>> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Monolithic"
>> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Multilib"
>>
>> I think it's ok for for monolithic and multilib, but the dll ones have
>> to go somewhere else since if you use batch build in VC to build both
>> Debug and DLL Debug it starts getting all sorts of errors/warnings
>> about wrong function signatures after the first lib is compiled since
>> I assume that it's using the same object files for both, but the
>> WXEXPORT is different.
> Ok, I'll set BUILDDIR to something like 
> "compiler-name[u][d]_shared/static" so that there should be no clashes 
> anymore.
I've tested my changes also under Windows but I've just noticed a thing: how 
could object files for the two types of build conflict since statically-compiled 
object files are named "wxbind_lib_etcetc" while shared-compiled are named 
"wxbind_dll_etcetc" ?
They also go in different folders (e.g. vc_lib and vc_dll) so maybe my change to 
BUILDDIR didn't help...

Francesco

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

John Labenski ha scritto:
> ps. Yes there is something that would be nice to have in the build files.
> 
> It looks like the object files for VC for the mod_wxlua (for example)
> go into wxLua/modules/build/msw/msvc6prjd/mod_wxlua for all of these
> builds
>>From modules_mod_wxlua.dsp
> 
> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Monolithic"
> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 DLL Debug Multilib"
> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Monolithic"
> !ELSEIF  "$(CFG)" == "mod_wxlua - Win32 Debug Multilib"
> 
> I think it's ok for for monolithic and multilib, but the dll ones have
> to go somewhere else since if you use batch build in VC to build both
> Debug and DLL Debug it starts getting all sorts of errors/warnings
> about wrong function signatures after the first lib is compiled since
> I assume that it's using the same object files for both, but the
> WXEXPORT is different.
Ok, I'll set BUILDDIR to something like 
"compiler-name[u][d]_shared/static" so that there should be no clashes 
anymore.

Francesco

Re: [wxlua-users] wxLua now uses an unmodified copy of lua 5.1.1

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

John Labenski ha scritto:
> On 12/6/06, Francesco Montorsi <f18...@ya...> wrote:
>> John Labenski ha scritto:
>>> I have rewritten the coroutine code so that we do not have to replace
>>> luaE_newthread and luaE_freethread by pushing the wxLuaStateRefData
>>> into the registry table.
>> good work!
>>
>>> Hopefully this will make using wxLua as a lua module using require
>>> much easier... of course the build files have to sorted out.
>> I'll reorganize the bakefiles tonight ;)
>>
>> With bakefile 0.2.1 we are very very near to have all functionalities we
>> need in the "official" bakefile. In fact, the only thing which makes us
>> depend on a patched bakefile currently is that we want to:
>>
>>   1) use wxPresets and all logic they contain
>>   2) have WX_DEBUG=0/1 and WX_UNICODE replaced by BUILD=debug/release
>> and UNICODE option names
>>
>> if we remove "feature" #2 then we can use bakefile 0.2.1
>> if we don't, hopefully Vaclav will apply my patch for bakefile 0.2.2
>> (I'm pinging him about that patch since a long time now).
> 
> Hopefully, soon. :)
hopefully ;)
So, AFAIU, we'll keep in use the patched bakefile version.
I.e. we keep BUILD and UNICODE option names, right?

> Is the bakefile on the wxLua website the same one you're using
> (htdocs/bakefile/frm-bakefile.tar.gz). I haven't tried it yet, since
> this would be the first time I'd need it. If not could you update it
> if it's not too much trouble?
sure - I've updated it just taking a vanilla bakefile repo and applying 
the "condvar" patch - that is the patch which makes it possible to 
rename WX_DEBUG=>BUILD and so on...

To work with it on wxLua I only need to replace the <srcdir> tags 
scattered in wxLua bakefiles with the mostly-equivalent <set-srcdir> tag 
which is now supported by bakefile.


>> Is there any other build problem which I should solve this evening ?
> 
> I don't think so. I dunno what you want to do about naming the lua.exe
> and lua.dll. Do we put wx in it somewhere since some linux
> distributions have lua packages and we don't want to overwrite it for
> "make install" even though it's identical?
looking into apps.bkl we have:

     <exe id="app_lua" template="luainterpreter">
         <!-- avoid clashes with the verbatim lua interpreter and call 
it 'wxlua-lua' -->
         <exename>wxlua-lua</exename>
         <wxlua-lib>lua</wxlua-lib>
     </exe>

     <!-- the verbatim LUA interpreter (compiled without 
WXLUA_LUA_NEWTHREAD define) -->
     <exe id="app_verbatimlua" template="luainterpreter">
         <exename>lua5.1</exename>
         <sys-lib>lua5.1</sys-lib>
     </exe>

that is, we actually build a vanilla LUA interpreter and we call it 
lua5.1 like it's common to do in unix distro... so that we are currently 
replacing the system's lua5.1 executable with our vanilla one which 
should be identic.

Maybe we should avoid to do that since users may have installed in the 
system a custom lua5.1 executable.

So I'd say we should remove the app_verbatimlua <exe> and keep only 
app_lua (which uses "wxlua-lua" name).

I'm doing all required changes to wxLua bakefiles right now.
I'll commit them as soon as they are complete.

Francesco

Re: [wxlua-users] wxlua editor current version

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

Fixed in CVS, the problem was with the wxProcess of the debuggee
sending a temination event, but the debugger doesn't exit until the
lua program is finished running so the wxLua executable's wxApp was
still in wxApp::OnInit and the event handlers aren't fully created
yet. I subclassed wxProcess to avoid running the event handler.

I've tweaked up the editor as well so that it does a test compile
before running or debugging to quickly see if there are any obvious
errors.

Regards,
    John Labenski

On 12/7/06, John Labenski <jla...@gm...> wrote:
> On 12/7/06, Andre <ar...@ki...> wrote:
> > I have tried to solve this problem but it seems to involve some rather depth
> > understanding of the internal.
> >
> > on window the debugger fail on run time error
> >
> > simple example, giving a file wiht th following line
> >
> > a()
> >
> > If you debug it you have the expected error in the output window and then the
> > program and the server (where the debug code is running) crash.
> >
> > There seem to be an invalid event being process for a hidden window but I am far
> > from understanding what is relly going on.
>
> I do not understand it either, somehow an event handler is
> uninitialized in the wxWidgets code to process the events. I believe
> it is with the wxProcessEvent and so I subclassed wxProcess and used
> it's virtual OnTerminate function instead, but then it crashed in a
> wxCriticalSection in the wWidgets events handler code. MSVC doesn't
> give a very useful stack, I'll try with gcc and gdb tonight.
>
> Regards,
>     John Labenski
>

Re: [wxlua-users] wxlua editor current version

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

On 12/7/06, Andre <ar...@ki...> wrote:
> I have tried to solve this problem but it seems to involve some rather depth
> understanding of the internal.
>
> on window the debugger fail on run time error
>
> simple example, giving a file wiht th following line
>
> a()
>
> If you debug it you have the expected error in the output window and then the
> program and the server (where the debug code is running) crash.
>
> There seem to be an invalid event being process for a hidden window but I am far
> from understanding what is relly going on.

I do not understand it either, somehow an event handler is
uninitialized in the wxWidgets code to process the events. I believe
it is with the wxProcessEvent and so I subclassed wxProcess and used
it's virtual OnTerminate function instead, but then it crashed in a
wxCriticalSection in the wWidgets events handler code. MSVC doesn't
give a very useful stack, I'll try with gcc and gdb tonight.

Regards,
    John Labenski

[wxlua-users] wxlua editor current version

[Andre <ar...@ki...>]

I have tried to solve this problem but it seems to involve some rather depth
understanding of the internal.

on window the debugger fail on run time error

simple example, giving a file wiht th following line

a()

If you debug it you have the expected error in the output window and then the
program and the server (where the debug code is running) crash.

There seem to be an invalid event being process for a hidden window but I am far
from understanding what is relly going on.

Any help would be appreciated.

Andre

Re: [wxlua-users] How to compile wxLua as module for -original- lua?

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

Hi,

John Labenski wrote:
> On 12/6/06, Hakki Dogusan <dog...@tr...> wrote:
>>> Great! If you have a place for me to get them I'll upload them to the
>>> wxLua site into the downloads dir.
>> http://www.dynaset.org/dogusanh/download/wxLua-CodeBlocks.zip ~5Mb
>>
>> - Includes CodeBlocks (SVN3315) project file
>> - wx.dll lua module unicode and non-unicode
>> - There are tons of exported functions, I couldn't solve it
>> - Used wx-rc3 static libs
>> - Used modified wxlstate.h (for Turkish)
>>
>> Could you inform me upon downloading it, please?
> 
> Got it, thanks.

Thanks. I'll remove them.

> What does it mean "There are tons of exported functions, I couldn't solve it"?
> 

I tried to export only luaopen_wx function.
- Using a wx.def file didn't help:
   EXPORTS
     luaopen_wx
- Playing with WXMAKINGDLL_... etc. didn't help


> When I try to run this, I get an error
> ./lua5.1.exe ../samples/luamodule.wx.lua
> d:\wxCVS\wxLua\wxLua\bin\lua5.1.exe: error loading module 'wx' from
> file '../lib/vc_dll/wx.dll':
>         Access is denied.
> 
> stack traceback:
>         [C]: ?
>         [C]: in function 'require'
>         ../samples/luamodule.wx.lua:19: in main chunk
>         [C]: ?
> 
> What the heck is "Access is denied" supposed to mean? It's definitely
> finding wx.dll since if I move it somewhere else it gives a "The
> specified module could not be found." error.
> 

I don't know :(

(Could it be your virus softare? I've upx'ed wx.dll.)

I was testing it with binaries compiled with gcc.

To make sure:
- re-checked dependencies with DependecyWalker
- downloaded lua5_1_1_Win32_bin from http://luaforge.net/frs/?group_id=110
- made a test dir
- copied wx.dll, lua5.1.exe, lua5.1.dll, luamodule.wx.lua
- modified cpath as package.cpath = ";?.dll;...

It runs here :)


>>> By the way, how do you use Code::Blocks with wxLua? I tried to use
>> I suggest to look it again..
>> It only generates a layout file. You don't mean object or dependency
>> files, don't you? For these I'm using sub directories.
> 
> Ok, I'll try again. If I remember correctly it was generating
> makefiles and maybe even autoconf and readme files and whatnot.
> 

I have a project sitting in a fat32 partition. I'm compiling it
both from xp and ubuntu via seperate project files. There is no 
"foreign" files there :) Maybe cb creates them in tmp, I don't know.

> Thanks,
>     John Labenski
> 



--
Regards,
Hakki Dogusan

Re: [wxlua-users] How to compile wxLua as module for -original- lua?

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

On 12/6/06, Hakki Dogusan <dog...@tr...> wrote:
> > Great! If you have a place for me to get them I'll upload them to the
> > wxLua site into the downloads dir.
>
> http://www.dynaset.org/dogusanh/download/wxLua-CodeBlocks.zip ~5Mb
>
> - Includes CodeBlocks (SVN3315) project file
> - wx.dll lua module unicode and non-unicode
> - There are tons of exported functions, I couldn't solve it
> - Used wx-rc3 static libs
> - Used modified wxlstate.h (for Turkish)
>
> Could you inform me upon downloading it, please?

Got it, thanks.
What does it mean "There are tons of exported functions, I couldn't solve it"?

When I try to run this, I get an error
./lua5.1.exe ../samples/luamodule.wx.lua
d:\wxCVS\wxLua\wxLua\bin\lua5.1.exe: error loading module 'wx' from
file '../lib/vc_dll/wx.dll':
        Access is denied.

stack traceback:
        [C]: ?
        [C]: in function 'require'
        ../samples/luamodule.wx.lua:19: in main chunk
        [C]: ?

What the heck is "Access is denied" supposed to mean? It's definitely
finding wx.dll since if I move it somewhere else it gives a "The
specified module could not be found." error.

> > By the way, how do you use Code::Blocks with wxLua? I tried to use
>
> I suggest to look it again..
> It only generates a layout file. You don't mean object or dependency
> files, don't you? For these I'm using sub directories.

Ok, I'll try again. If I remember correctly it was generating
makefiles and maybe even autoconf and readme files and whatnot.

Thanks,
    John Labenski

Re: [wxlua-users] How to compile wxLua as module for -original- lua?

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

Hi,

John Labenski wrote:
> On 12/6/06, Hakki Dogusan <dog...@tr...> wrote:
>> John Labenski wrote:
>>> On 12/5/06, Hakki Dogusan <dog...@tr...> wrote:
>>>> (Mingw, wxLua cvs, wx2.7.2/wx2.8 ANSI and Unicode, WinXP Turkish)
>> Indeed now LUA5.1.DLL == WXLUA_MSW28U_LUA.DLL
>>
>> I assume new makefiles won't generate WXLUA_MSW28U_LUA.DLL?
>>
>> ps. I built a wxLua module with Code::Blocks. I used wx as
>> static lib. It seems work. It is ~3Mb (upx'ed) single dll,
>> only depends to lua5.1.dll. If you interested I can put it
>> somewhere.
> 
> Great! If you have a place for me to get them I'll upload them to the
> wxLua site into the downloads dir.
> 

http://www.dynaset.org/dogusanh/download/wxLua-CodeBlocks.zip ~5Mb

- Includes CodeBlocks (SVN3315) project file
- wx.dll lua module unicode and non-unicode
- There are tons of exported functions, I couldn't solve it
- Used wx-rc3 static libs
- Used modified wxlstate.h (for Turkish)

Could you inform me upon downloading it, please?
My web space is limited.


> By the way, how do you use Code::Blocks with wxLua? I tried to use
> Code::Blocks a while back and found that it generated a bunch of build
> files for me. I asked on their forum how to get it to not do that, but
> didn't get a response. Is there a way to merely use CB as an editor
> and not have it generate or touch any files other than it's project
> file? It seemed like a very nice editor, but it made me nervous that
> it was generating things that might overwrite what I already had.
> 

I suggest to look it again..
It only generates a layout file. You don't mean object or dependency
files, don't you? For these I'm using sub directories.

> Thanks,
>     John Labenski
> 

Thank you.

--
Regards,
Hakki Dogusan

Re: [wxlua-users] wx2lua & Unicode was Re: Problem in using Turkish in wxLua scripts

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

Hi,

John Labenski wrote:
[snip]
> 
> I personally don't have any idea and would naively think that
> wxConvCurrent instead of wxConvUTF8 is the right thing to do.


Just to feed some more food :)


Code::Blocks uses this code (GPL):

// Return @c str as a proper unicode-compatible string
wxString cbC2U(const char* str)
{
#if wxUSE_UNICODE
     return wxString(str, *wxConvCurrent);
#else
     return wxString(str);
#endif
}

// Return multibyte (C string) representation of the string
wxWX2MBbuf cbU2C(const wxString& str)
{
#if wxUSE_UNICODE
     return str.mb_str(*wxConvCurrent);
#else
     return (wxChar*)str.mb_str();
#endif
}


- I didn't compare them with your summary
- FlameRobin and Code::Blocks works fine in WinXP-Turkish, Ubuntu-Dapper


--
Regards,
Hakki Dogusan