wxlua-users — wxLua list for users and developers

[wxlua-users] about web activity

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

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


--
Regards,
Hakki Dogusan

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

[Eero P. <epa...@ko...>]

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

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

[Klaas H. <db...@nl...>]

John Labenski wrote:
> First off, I'm going to rename some rather unfortunately named
> functions. These are mostly internal to wxLua, but you may have to
> rebuild your bindings using genwxbind.lua.
> 
> More importantly, do we want stricter function parameter type
> checking. 

I like that. The more the better, i never understood what is so good about this automatic conversion, in general it does 
not save me time in the end, just more confusion :-)

Klaas


-- 
Unclassified

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:
>>> I think we should also remove these blocks:
>>>
>>> #if defined(__GNUG__) && !defined(NO_GCC_PRAGMA)
>>>      #pragma implementation "wxlstate.h"
>>> #endif
>>>
>>> GCC does not use it anymore since a long time and they can only give problems...
>>>
>> Very right, i still needed to that.
> 
> Ok, I can do this. I'm going through all the code and hopefully once
> and for all give things good names now that I have a much better
> understanding of everything.
great !

Before 2.8.0.0 release I hope to be able to put the PCH compilation in a 
better shape (i.e. have faster builds) by adding a wxluaprec.h file and 
a "wxlua.h" which include all wxLua headers so that ours PCH files will 
have also wxLua code precompiled (currently precompilation affects only 
wx headers).

Francesco

Re: [wxlua-users] MSW problems

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

Francesco Montorsi ha scritto:
> klaas.holwerda ha scritto:
>> Klaas Holwerda wrote:
>>> Will test your fix this evening.
>>>   
>> After getting 2.8.0rc3 from york site, and the latest CVS of wxLua and 
>> wxstedit,
>> i do get some warning here and there ( deprecated and such) but nothing 
>> serious.
>>
>> Only think not working for me is:
>>
>> nmake -f makefile.vc BUILD=release
>>
>> That is after a normal debug build.
> Ouch - this is really a big problem. It looks like the WX_DEBUG option has not 
> been completely replaced by the BUILD option. I need to look better into this - 
> probably this has been caused by moving some option declarations in wxhacks.bkl 
> but it may also be a wider problem in the "option-renaming" patch which I use in 
> bakefile.
> 
> I'll look at this tomorrow.
I've found it was caused by a dummy problem with my patch. I've fixed it 
in my local copy. I still need to test wxMSW. I'll do that this evening.
In the meanwhile I've checked in the regenerated makefiles.

_maybe_ this could also be the cause of the linker warnings...

Francesco

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

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

Hi,

John Labenski ha scritto:
> First off, I'm going to rename some rather unfortunately named
> functions. These are mostly internal to wxLua, but you may have to
> rebuild your bindings using genwxbind.lua.
> 
> More importantly, do we want stricter function parameter type
> checking. Lua itself is very generous and will convert numbers to
> strings, nil to number, etc... BUT, this means that without some
> checking you can spend a lot of time debugging a small typo since vars
> can be created on the fly with the value nil.
   even if honestly I still haven't found enough time to start using 
wxLua myself :(, just a dummy advice: I'd keep the auto conversion code 
(it's an important part of modern interpreted languages I think) but I 
understand what you mean - so maybe we could add a work mode to wxLua 
interpreter so that it logs the creation of each new variable (to help 
debugging). This sort of logging has the disadvantage however that the 
log may become extremely long and thus unusable for big programs.

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:

http://msdn2.microsoft.com/en-us/library/y9341s4f(vs.80).aspx

maybe something like that could be the solution...

Francesco

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

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

Hi,

John Labenski wrote:
> First off, I'm going to rename some rather unfortunately named
> functions. These are mostly internal to wxLua, but you may have to
> rebuild your bindings using genwxbind.lua.
> 
> More importantly, do we want stricter function parameter type
> checking. Lua itself is very generous and will convert numbers to
> strings, nil to number, etc... BUT, this means that without some
> checking you can spend a lot of time debugging a small typo since vars
> can be created on the fly with the value nil.
> 
> Lua has nice functions, tostring(X), tonumber(X), and nil can be
> avoided using "nil or value".
> 
> Below is what we currently accept for different variable types and
> what I propose I marked with a *
> 
> See here
> http://wxlua.cvs.sourceforge.net/wxlua/wxLua/modules/wxlua/src/wxlstate.cpp?view=markup
> 
> wxLua_lua_isstringtype
>         case LUA_TNIL:          * MAKE INVALID can use [str or ""]

Ok.

>         case LUA_TSTRING:
>         case LUA_TNUMBER: // can convert easily
> 
> wxLua_lua_isbooleantype
>        case LUA_TNIL:
>        case LUA_TNUMBER:
>        case LUA_TBOOLEAN:
> 
> wxLua_lua_isenumerationtype
>       case LUA_TNUMBER  * check to see if it's an INT? probably not

If you can't check that it is really an enum value, why bother?
wx itself accepts int for enum? ex:
// Bitmap flags
enum wxBitmapType
{
     wxBITMAP_TYPE_INVALID,          // should be == 0 for compatibility!
     wxBITMAP_TYPE_BMP,
     wxBITMAP_TYPE_BMP_RESOURCE,
...
     wxBITMAP_TYPE_ANY = 50
};

wxImage(const wxString& name, long type = wxBITMAP_TYPE_ANY, int index = -1)

> 
> wxLua_lua_isnumbertype
>         case LUA_TNIL:          * MAKE INVALID can use [num or 0]

Ok.

>         //case LUA_TSTRING: // will be 0 unless really a number "2"
>         case LUA_TNUMBER:
>         case LUA_TBOOLEAN:
> 
> Thoughts?
>      John Labenski
> 


--
Regards,
Hakki Dogusan

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

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

First off, I'm going to rename some rather unfortunately named
functions. These are mostly internal to wxLua, but you may have to
rebuild your bindings using genwxbind.lua.

More importantly, do we want stricter function parameter type
checking. Lua itself is very generous and will convert numbers to
strings, nil to number, etc... BUT, this means that without some
checking you can spend a lot of time debugging a small typo since vars
can be created on the fly with the value nil.

Lua has nice functions, tostring(X), tonumber(X), and nil can be
avoided using "nil or value".

Below is what we currently accept for different variable types and
what I propose I marked with a *

See here
http://wxlua.cvs.sourceforge.net/wxlua/wxLua/modules/wxlua/src/wxlstate.cpp?view=markup

wxLua_lua_isstringtype
        case LUA_TNIL:          * MAKE INVALID can use [str or ""]
        case LUA_TSTRING:
        case LUA_TNUMBER: // can convert easily

wxLua_lua_isbooleantype
       case LUA_TNIL:
       case LUA_TNUMBER:
       case LUA_TBOOLEAN:

wxLua_lua_isenumerationtype
      case LUA_TNUMBER  * check to see if it's an INT? probably not

wxLua_lua_isnumbertype
        case LUA_TNIL:          * MAKE INVALID can use [num or 0]
        //case LUA_TSTRING: // will be 0 unless really a number "2"
        case LUA_TNUMBER:
        case LUA_TBOOLEAN:

Thoughts?
     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/11/06, klaas.holwerda <kho...@xs...> wrote:
> Francesco Montorsi wrote:
> > Klaas Holwerda ha scritto:
> > I agree, I like to see "wxlua" as a prefix instead of having it in the middle.

Ok, about the suggestions I made, I forgot to remove the wxlua_
prefix, I meant wxgtk2ud_wxlua_XXX.lib, but anyway, just ignore all
that. having wxlua_wxgtk2ud_XXX.lib is just fine by me.

> > I think we should also remove these blocks:
> >
> > #if defined(__GNUG__) && !defined(NO_GCC_PRAGMA)
> >      #pragma implementation "wxlstate.h"
> > #endif
> >
> > GCC does not use it anymore since a long time and they can only give problems...
> >
> Very right, i still needed to that.

Ok, I can do this. I'm going through all the code and hopefully once
and for all give things good names now that I have a much better
understanding of everything.

-John Labenski

Re: [wxlua-users] MSW problems

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

klaas.holwerda ha scritto:
> Klaas Holwerda wrote:
>> Will test your fix this evening.
>>   
> 
> After getting 2.8.0rc3 from york site, and the latest CVS of wxLua and 
> wxstedit,
> i do get some warning here and there ( deprecated and such) but nothing 
> serious.
> 
> Only think not working for me is:
> 
> nmake -f makefile.vc BUILD=release
> 
> That is after a normal debug build.
Ouch - this is really a big problem. It looks like the WX_DEBUG option has not 
been completely replaced by the BUILD option. I need to look better into this - 
probably this has been caused by moving some option declarations in wxhacks.bkl 
but it may also be a wider problem in the "option-renaming" patch which I use in 
bakefile.

I'll look at this tomorrow.
Francesco

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

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

Francesco Montorsi wrote:
> Hi,
>
> John Labenski ha scritto:
>   
>> These warnings are back, I'm pretty sure I didn't get them a week ago
>> and I don't understand what the problem could be. I'm using wxWidgets
>> 2.6 from CVS and MS Visual Studio 6.
>>     
> I get them also with MS VisualStudio 7.1 with wxMSW 2.8...
>   
7.10.3077

I did a complete new wxLua checkout first. And i thought i did not see 
those warning.
But removed all object files and lib files and build again, no such 
warnings!
This is using nmake not IDE.
>> wxlua_msw26d_wxlua_wxluadebug.lib
>> wxlua_msw26d_wxlua_wxluasocket.lib
>>     
> sorry but I don't understand why should we repeat "wxlua" twice in the name of 
> the libraries: if there's 1 "wxlua" prefix it seems quite clear to me that the 
> debug/sockets libs are not "generic" but wxlua-only.
>   
Same here, to me its fine as is.
>   
>> In any case, do whatever you think is best Francesco.
>>     
> sorry but I don't see what's wrong with current naming - I'd just keep it as in 
> current way...
>   
Agreed.
>   
>> ps. The precompiled headers are GREAT! I can't really tell much of a
>> difference in MSVC6, but I was thinking about how we could do it and
>> wanted to ask if you knew how, but thought it might be too much work.
>>     
> glad to know they were appreciated - however to speedup even more the 
> compilation of wxLua our headers should include a wxLua PCH, just as Klaas 
> suggests (see other mail).
>   
If help is need, let me know. But first i need to get wxArt2D going with 
the new bin dir, lib names etc.


regards,

Klaas

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

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

Francesco Montorsi wrote:
> Klaas Holwerda ha scritto:
>   
>> All in all i think i still like this a little more:
>>
>> wxlua_msw28d_debug.lib
>>
>> compared to:
>>
>> wxmsw28d_wxlua_debug.lib
>>
>> The namespace in the beginning is easier when it comes to sorting (ls or dir will show them grouped ).
>>     
> I agree, I like to see "wxlua" as a prefix instead of having it in the middle.
>
>
>   
>>>> ps. The precompiled headers are GREAT! I can't really tell much of a
>>>>         
>>> difference in MSVC6, but I was thinking about how we could do it and
>>> wanted to ask if you knew how, but thought it might be too much work.
>>>       
>> Well in wxArt2D we have it working. The idea is this:
>>
>> // our own pre compiled header file.
>> #include "general/include/a2dprec.h"
>>
>> #ifdef __GNUG__
>>      #pragma implementation "artglob.h"
>> #endif
>>
>> #ifdef __BORLANDC__
>>      #pragma hdrstop
>> #endif
>>
>> #ifndef WX_PRECOMP
>>      #include "wx/wx.h"
>> #endif
>>
>>     
> well, I'd say that we should infact have a wxluaprec.h file
sure. I think you mean that in my case

#include "wxart2d.h" is not really needed inside the #include "general/include/a2dprec.h"?

But i use it for other cases when no PCH is in question.

>  and then put all 
> possible headers there and all other unnecessary #include directives into the 
> WX_PRECOMP block.
>
> I think we should also remove these blocks:
>
> #if defined(__GNUG__) && !defined(NO_GCC_PRAGMA)
>      #pragma implementation "wxlstate.h"
> #endif
>
> GCC does not use it anymore since a long time and they can only give problems...
>   
Very right, i still needed to that.

Klaas

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

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

Klaas Holwerda ha scritto:
> All in all i think i still like this a little more:
> 
> wxlua_msw28d_debug.lib
> 
> compared to:
> 
> wxmsw28d_wxlua_debug.lib
> 
> The namespace in the beginning is easier when it comes to sorting (ls or dir will show them grouped ).
I agree, I like to see "wxlua" as a prefix instead of having it in the middle.


>>> ps. The precompiled headers are GREAT! I can't really tell much of a
>> difference in MSVC6, but I was thinking about how we could do it and
>> wanted to ask if you knew how, but thought it might be too much work.
> 
> Well in wxArt2D we have it working. The idea is this:
> 
> // our own pre compiled header file.
> #include "general/include/a2dprec.h"
> 
> #ifdef __GNUG__
>      #pragma implementation "artglob.h"
> #endif
> 
> #ifdef __BORLANDC__
>      #pragma hdrstop
> #endif
> 
> #ifndef WX_PRECOMP
>      #include "wx/wx.h"
> #endif
> 
well, I'd say that we should infact have a wxluaprec.h file and then put all 
possible headers there and all other unnecessary #include directives into the 
WX_PRECOMP block.

I think we should also remove these blocks:

#if defined(__GNUG__) && !defined(NO_GCC_PRAGMA)
     #pragma implementation "wxlstate.h"
#endif

GCC does not use it anymore since a long time and they can only give problems...


Francesco

Re: [wxlua-users] MSW problems

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

Klaas Holwerda wrote:
> Will test your fix this evening.
>   

After getting 2.8.0rc3 from york site, and the latest CVS of wxLua and 
wxstedit,
i do get some warning here and there ( deprecated and such) but nothing 
serious.

Only think not working for me is:

nmake -f makefile.vc BUILD=release

That is after a normal debug build.

But we most update e.g. genwxbind.bat (both) to take wxlua-lua.exe from 
$WLUA\vcd_lib\wxlua-lua.exe.
At least that is where the executables end up now.
Don't what it should be for genwxbind.sh.

Thanks.

Klaas

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

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

Hi,

John Labenski ha scritto:
> These warnings are back, I'm pretty sure I didn't get them a week ago
> and I don't understand what the problem could be. I'm using wxWidgets
> 2.6 from CVS and MS Visual Studio 6.
I get them also with MS VisualStudio 7.1 with wxMSW 2.8...


> wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _lua_ident already
> defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition ignored
...
> 
> and so on for the other libs. Any ideas why this is happening again?
I've searched the wxlua-users mailing list but I couldn't find any reference 
(except in the very latest mails) to LNK4006 warnings - did we ever get them before?

> I
> can't understand why the const char lua_ident[] = {...} inside of
> lapi.c only (not in header at all) could possibly have a problem since
> mod_wxbind Debug Multilib doesn't link to anything!
I can't understand that too. I've checked and unless my eyes are lying to me, 
all the DSP are using the same build settings.
I've searched the net but I couldn't find any good hint. It's strange: the 
linker shouldn't run at all when creating a static 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.
>> it's not a preference - just a "bug". Definitively the <wxlike-lib> tag
>> should take in account a prefix as other wxlike-* tags do.
> 
> Maybe an additional <wxlike-prefix-lib> that has the prefix could be
> added. The <wxlike-lib> code is pretty small so it might not be too
> much bloat. See below, that idea sounds pretty good and very simple.
sure, adding a new tag like <wxlike-prefix-lib> would be feasible but I hope 
that it won't even be needed - as soon as wx2.8.0 will be released I hope to get 
the wxpresets patch applied (and it contains a working wxlike-lib tag with 
prefix support).

> 
>>> 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.
>> hmmm, I don't see any great advantage over current naming, except that
>> this is backward-incompatible for all ours wxLua users which should
>> probably need to update their makefiles/project files without any real
>> need (wxlike-lib tag must be fixed, not our naming rules).
> 
> I don't think we have to worry about backwards compatibility too much.
> We have a small user base and hopefully things will be settled once
> and for all after this.
> 
> I DO like this idea and think it's just as well. I'd keep the wx in
> the second name though to be clear about what the lib is really for
> since wxluadebug/socket are not generic debug/socket libs, but only
> work with wxlua.
> 
> wxlua_msw26d_wxlua_lua.lib
> wxlua_msw26d_wxlua_wxbind.lib
> wxlua_msw26d_wxlua_wxbindstc.lib
> wxlua_msw26d_wxlua_wxlua.lib
> wxlua_msw26d_wxlua_wxluadebug.lib
> wxlua_msw26d_wxlua_wxluasocket.lib
sorry but I don't understand why should we repeat "wxlua" twice in the name of 
the libraries: if there's 1 "wxlua" prefix it seems quite clear to me that the 
debug/sockets libs are not "generic" but wxlua-only.

> 
> In any case, do whatever you think is best Francesco.
sorry but I don't see what's wrong with current naming - I'd just keep it as in 
current way...

> ps. The precompiled headers are GREAT! I can't really tell much of a
> difference in MSVC6, but I was thinking about how we could do it and
> wanted to ask if you knew how, but thought it might be too much work.
glad to know they were appreciated - however to speedup even more the 
compilation of wxLua our headers should include a wxLua PCH, just as Klaas 
suggests (see other mail).


Francesco

Re: [wxlua-users] debug

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

John Labenski <jlabenski@...> writes:


> But then you have zombie debugee processes if something fails. I
> worked on this last night a little bit and hope it's better now. The
> problem is that you want to Kill debuggee process, but when you do the
> main thread is run and if you're in the destructor of the
> wxLuaDebuggerBase things get out of sync and you get an exception. It
> seems as though what you want to do is
> 
> 1) kill debugee process in the debugger server
> 2) send some made up event back to myself so that the wxWidgets event
> handler is run at least once
> 3) in the event handler actually delete the debugger server
> 
> I have to debug it more, but you may want to look at the current cvs
> to see what I've done. See ~wxLuaDebuggerBase and the OnTerminate you
> mention. Another idea is to create a static class to actually delete
> the process so that when the Kill function returns the class will
> still be there.
> 
> This crashes because KillDebuggee returns, but the process is still in
> a thread trying to kill it when you delete the debugger server.
> debuggerServer:KillDebuggee()
> debuggerServer:Delete()
> 
> Does this make sense? The backtrace that MS Visual Studio gives is
> pretty bad, but a breakpoint set in the debugger server shows that the
> problem seems to be with that.

Now I am really confused, nothing new :)

The problem I had was a zombie process left on failure. But by removing these
lines then the zombie process was removed. Also debugging a program which
terminates properly works, not a surprise since it does not used this code.

I will look at it again. 

I think I am using the moste recent code.

Andre

Re: [wxlua-users] debug

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

On 12/11/06, Andre <ar...@ki...> wrote:
> When this code is invoke on an error
>
> the call m_debugger->OnEndDebugeeProcess(event);
>  seems to destroy both m_debugger and the running wxLuaDebuggerProcess
>
>
> void wxLuaDebuggerProcess::OnTerminate(int pid, int status)
> {
>     // If this is being deleted from the destructor of wxLuaDebuggerBase
>     //   it has already been NULLed so don't send event or delete this.
>     if (m_debugger->m_debuggeeProcess)
>     {
>         // we don't use the event handler, but this is good enough.
>         wxProcessEvent event(m_id, pid, status);
>         m_debugger->OnEndDebugeeProcess(event);
>
>         m_debugger->m_debuggeeProcess = NULL;
>         m_debugger->m_debuggeeProcessID = -1;
>         delete this;
>     }
> }
>
> it seem to work fine if the last 3 lines are removed:
>
>         m_debugger->m_debuggeeProcess = NULL;
>         m_debugger->m_debuggeeProcessID = -1;
>         delete this;

But then you have zombie debugee processes if something fails. I
worked on this last night a little bit and hope it's better now. The
problem is that you want to Kill debuggee process, but when you do the
main thread is run and if you're in the destructor of the
wxLuaDebuggerBase things get out of sync and you get an exception. It
seems as though what you want to do is

1) kill debugee process in the debugger server
2) send some made up event back to myself so that the wxWidgets event
handler is run at least once
3) in the event handler actually delete the debugger server

I have to debug it more, but you may want to look at the current cvs
to see what I've done. See ~wxLuaDebuggerBase and the OnTerminate you
mention. Another idea is to create a static class to actually delete
the process so that when the Kill function returns the class will
still be there.

This crashes because KillDebuggee returns, but the process is still in
a thread trying to kill it when you delete the debugger server.
debuggerServer:KillDebuggee()
debuggerServer:Delete()

Does this make sense? The backtrace that MS Visual Studio gives is
pretty bad, but a breakpoint set in the debugger server shows that the
problem seems to be with that.
    John Labenski

[wxlua-users] debug

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

When this code is invoke on an error 

the call m_debugger->OnEndDebugeeProcess(event);
 seems to destroy both m_debugger and the running wxLuaDebuggerProcess


void wxLuaDebuggerProcess::OnTerminate(int pid, int status)
{
    // If this is being deleted from the destructor of wxLuaDebuggerBase
    //   it has already been NULLed so don't send event or delete this.
    if (m_debugger->m_debuggeeProcess)
    {
        // we don't use the event handler, but this is good enough.
        wxProcessEvent event(m_id, pid, status);
        m_debugger->OnEndDebugeeProcess(event);

        m_debugger->m_debuggeeProcess = NULL;
        m_debugger->m_debuggeeProcessID = -1;
        delete this;
    }
}

it seem to work fine if the last 3 lines are removed:

        m_debugger->m_debuggeeProcess = NULL;
        m_debugger->m_debuggeeProcessID = -1;
        delete this;

Andre

Re: [wxlua-users] MSW problems

[Klaas H. <db...@nl...>]

John Labenski wrote:

> wxWidgets CVS HEAD has GetCaretLineBackground
> http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/contrib/include/wx/stc/stc.h?rev=HEAD&content-type=text/vnd.viewcvs-markup
> 

Oke we will soon know (today) :-)
All i have here on 2.8.0rcX download has it different.

> 
> Oops, struct WXDLLEXPORT wxVideoMode in current CVS HEAD.
> gcc 4.1.1 and MSVC 6 and 8 (2005) don't complain and I guess they're
> treating the struct as a class.
> 
> wxLUA_DECLARE_ENCAPSULATION(WXDLLIMPEXP_WXBIND, wxVideoMode, wxVideoMode)

Strange i am using VC6 at work, and get the same warning. Service packs maybe??
Will test your fix this evening.

Thanks,

Klaas

-- 
Unclassified

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

[Klaas H. <db...@nl...>]

John Labenski wrote:

> 
>>>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.
>>
>>hmmm, I don't see any great advantage over current naming, except that
>>this is backward-incompatible for all ours wxLua users which should
>>probably need to update their makefiles/project files without any real
>>need (wxlike-lib tag must be fixed, not our naming rules).

Agreed and for me the current wxlua way is just fine. I just got confused by wxCode and its naming of libs.
But as you say it should be changed.

All in all i think i still like this a little more:

wxlua_msw28d_debug.lib

compared to:

wxmsw28d_wxlua_debug.lib

The namespace in the beginning is easier when it comes to sorting (ls or dir will show them grouped ).

> I DO like this idea and think it's just as well. I'd keep the wx in
> the second name though to be clear about what the lib is really for
> since wxluadebug/socket are not generic debug/socket libs, but only
> work with wxlua.
> 
> wxlua_msw26d_wxlua_lua.lib
> wxlua_msw26d_wxlua_wxbind.lib
> wxlua_msw26d_wxlua_wxbindstc.lib
> wxlua_msw26d_wxlua_wxlua.lib
> wxlua_msw26d_wxlua_wxluadebug.lib
> wxlua_msw26d_wxlua_wxluasocket.lib

But this seconds wxlua has the same goal as the first is it not?
So why add it twice?
I looks like the current situation in wxLua is not a problem ;-)

> 
> In any case, do whatever you think is best Francesco.

Yep.

>> ps. The precompiled headers are GREAT! I can't really tell much of a
> difference in MSVC6, but I was thinking about how we could do it and
> wanted to ask if you knew how, but thought it might be too much work.

Well in wxArt2D we have it working. The idea is this:

// our own pre compiled header file.
#include "general/include/a2dprec.h"

#ifdef __GNUG__
     #pragma implementation "artglob.h"
#endif

#ifdef __BORLANDC__
     #pragma hdrstop
#endif

#ifndef WX_PRECOMP
     #include "wx/wx.h"
#endif

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

/*! \file general/include/a2dprec.h

     Licence: wxWidgets License

     RCS-ID: $Id: a2dprec.h,v 1.2 2005/08/10 21:10:48 titato Exp $
*/

#include "wx/wxprec.h"

#ifdef WX_PRECOMP

#include <wx/mstream.h>
#include <wx/tokenzr.h>
#include "wxart2d.h"

#endif // WX_PRECOMP


And at last have the precompiled header flags for the compiler.
And the central dummy.cpp file used in each module.

Not that complicated.

Klaas

-- 
Unclassified

Re: [wxlua-users] MSW problems

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

On 12/10/06, klaas.holwerda <kho...@xs...> wrote:
> > 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.

wxWidgets CVS HEAD has GetCaretLineBackground
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/contrib/include/wx/stc/stc.h?rev=HEAD&content-type=text/vnd.viewcvs-markup

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

Oops, struct WXDLLEXPORT wxVideoMode in current CVS HEAD.
gcc 4.1.1 and MSVC 6 and 8 (2005) don't complain and I guess they're
treating the struct as a class.

wxLUA_DECLARE_ENCAPSULATION(WXDLLIMPEXP_WXBIND, wxVideoMode, wxVideoMode)

I think I fixed it in wxLUA_DECLARE_ENCAPSULATION by not forward
declaring the input "class".

Try the new cvs again.

Regards,
    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...>]

These warnings are back, I'm pretty sure I didn't get them a week ago
and I don't understand what the problem could be. I'm using wxWidgets
2.6 from CVS and MS Visual Studio 6.

--------------------Configuration: mod_verbatimlua - Win32 Debug
Multilib--------------------
Compiling...
lapi.c
...
lzio.c
Generating Code...
Creating library...
--------------------Configuration: mod_wxlua - Win32 Debug
Multilib--------------------
Compiling...
dummy.cpp
Compiling...
wxlbind.cpp
wxlcallb.cpp
wxlstate.cpp
Generating Code...
Creating library...
--------------------Configuration: mod_wxbind - Win32 Debug
Multilib--------------------
Compiling...
dummy.cpp
Compiling...
appframe.cpp
...
xml.cpp
Generating Code...
Creating library...
wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _lua_ident already
defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition ignored
wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _luaA_pushobject
already defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition
ignored
wxlua_msw26d_lua.lib(lzio.obj) : warning LNK4006: _luaZ_openspace
already defined in wxlua_msw26d_wxlua.lib(lzio.obj); second definition
ignored
...
--------------------Configuration: mod_wxbindstc - Win32 Debug
Multilib--------------------
Compiling...
dummy.cpp
Compiling...
stc.cpp
wxstc_bind.cpp
Generating Code...
Creating library...
wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _lua_ident already
defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition ignored
wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _luaA_pushobject
already defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition
ignored

and so on for the other libs. Any ideas why this is happening again? I
can't understand why the const char lua_ident[] = {...} inside of
lapi.c only (not in header at all) could possibly have a problem since
mod_wxbind Debug Multilib doesn't link to anything!

On 12/10/06, Francesco Montorsi <f18...@ya...> wrote:
> klaas.holwerda ha scritto:
> > 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.

Yes, but I like wxmsw28d_wxlua_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.
> it's not a preference - just a "bug". Definitively the <wxlike-lib> tag
> should take in account a prefix as other wxlike-* tags do.

Maybe an additional <wxlike-prefix-lib> that has the prefix could be
added. The <wxlike-lib> code is pretty small so it might not be too
much bloat. See below, that idea sounds pretty good and very simple.

> > 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.
> hmmm, I don't see any great advantage over current naming, except that
> this is backward-incompatible for all ours wxLua users which should
> probably need to update their makefiles/project files without any real
> need (wxlike-lib tag must be fixed, not our naming rules).

I don't think we have to worry about backwards compatibility too much.
We have a small user base and hopefully things will be settled once
and for all after this.

I DO like this idea and think it's just as well. I'd keep the wx in
the second name though to be clear about what the lib is really for
since wxluadebug/socket are not generic debug/socket libs, but only
work with wxlua.

wxlua_msw26d_wxlua_lua.lib
wxlua_msw26d_wxlua_wxbind.lib
wxlua_msw26d_wxlua_wxbindstc.lib
wxlua_msw26d_wxlua_wxlua.lib
wxlua_msw26d_wxlua_wxluadebug.lib
wxlua_msw26d_wxlua_wxluasocket.lib

In any case, do whatever you think is best Francesco.

Was there anything else I've missed?

Thanks,
    John Labenski

ps. The precompiled headers are GREAT! I can't really tell much of a
difference in MSVC6, but I was thinking about how we could do it and
wanted to ask if you knew how, but thought it might be too much work.

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

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

klaas.holwerda ha scritto:
> 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. 
it's not a preference - just a "bug". Definitively the <wxlike-lib> tag 
should take in account a prefix as other wxlike-* tags do.

I've updated the wxpresets patch which I've submitted to wxWidgets with 
a wxlike-lib tag which supports the prefix so that hopefully it won't be 
a problem anymore soon.

>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.
I agree

> Looking at  the wxWidgets naming , i also see  wxbase28.lib, next to 
> wxmsw28_core and wxmsw28_stc, i don't see the logic.
there's a logic, really ;)

> I only see "wx" as common namespace, why did they not use wxmsw in front 
> of all??
because some of wx libraries are not port-dependent. E.g. the wxBase 
library does not uses different sources when compiled as wxMSW and 
others when compiled as wxGTK.

> 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.
hmmm, I don't see any great advantage over current naming, except that 
this is backward-incompatible for all ours wxLua users which should 
probably need to update their makefiles/project files without any real 
need (wxlike-lib tag must be fixed, not our naming rules).

Francesco

Re: [wxlua-users] MSW problems

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

klaas.holwerda ha scritto:
>>   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??
installing is required when you want to have all lua binaries in your 
PATH...

>> 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.
right. Current name is unversioned so that we've fixed this too ;)

Francesco

Re: [wxlua-users] MSW problems

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

John Labenski ha scritto:
> I think things are really shaping up for a very nice 2.8 release.
I agree. I've added a few notes about the latest build system changes to 
changelog.txt and also changed the version for next release to 2.8.0.0


Francesco