wxlua-users — wxLua list for users and developers

[Wxlua-users] bakefile version conflict

[k. h. <kla...@nl...>]

Hi Francesco,

On Linux configure tells me this.

configure: error Versions of Bakefile used to generate makefiles (0.2.2) 
and configure (0.2.0) do not match.

e basta.

 I have a CVS checkout of late last night.

What can be wrong, and why do you not have this error?

Thanks,

Klaas

-- 
Unclassified

Re: [Wxlua-users] Re: Problems with wxStEdit on Linux

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

On 2/8/06, Francesco Montorsi <f18...@ya...> wrote:
> > If you could do this easily it would be great. I just copied the
> > bakefile stuff for wxStEdit from one of your projects a long time ago
> > and haven't updated them since.
> done
>
> >> Second, I've got problems about missing wx/stedit/setup.h file; I copi=
ed
> >> setup0.h in setup.h and solved this. Should this file be generated by
> >> the configure script ?
> >
> > It's one of those things where the user should set it up the way they
> > like. I don't want to put it into CVS since it'll just get overwritten
> > and be annoying. I suppose that configure could just copy it for
> > people.
> updated configure to do it
>
> >> Last, I have problems with the usual void* -> int conversions which on
> >> 64bit machines like mine are not valid.
> >>
> >> Since I have access to wxCode CVS, I could check in the required chang=
es...
> >
> > Please do, I can't think of where this would be in wxStEdit off the
> > top of my head.
> you can see them in cvs diffs ;)

Thanks.

> I'm currently stopped by errors about include paths like:
>
> #include "../../contrib/src/stc/scintilla/include/Platform.h" // for
> PRectangle
> #include "../../contrib/src/stc/scintilla/include/PropSet.h"  // for SStr=
ing
>
> which refer to non-existent files in my wxCode tree.
> These should be really transformed into something else...
> unfortunately I checked the wxWidgets contrib section and I've found
> that on Unix scintilla headers are not installed anywhere...
>
> so my proposed fix is:
> 1) on win32, add the %WXWIN%/contrib/src/stc/scintilla/include path
> 2) on unix, add a check for these headers. If they are not available,
> tell the user to use the --with-wxdir option to indicate the full path
> of the wxWidgets source tree and use it to install scintilla headers.
> Or else, ask the wxdev to add scintilla headers to install rules.

3) I removed the dependence on them by just copying the needed class
declarations from the scintilla headers. :) (the license is ok with
that)

I started working on this before and I thought I changed some things,
but maybe I never committed them. Anyway all the #includes are gone
now. I'm trying to keep the code as similar as possible to the
original since some of the export functions are not trivial.

Thanks
    John Labenski

Re: [Wxlua-users] bakefile 0.2.2

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

Francesco Montorsi wrote:

> Hi,
>    official bakefile 0.2.0 is out but it does not integrate yet the 
> patches which are required to make it work with wxLua bakefiles.
>
> So I've updated the bakefile version number to 0.2.2 of my personal 
> 'edition' at uploaded bakefile archive at:
>
Does this include a ready to use bakefile for windows?
I am a bit scared for compiling disasters :-(

> http://www.geocities.com/f18m_cpp217828/frm-bakefile.tar.gz
>
> I also regenerated makefiles and committed them.
> The archive also adds to bakefile a working KDevelop generator...
>
No i am forced to try it ;-)

> Kdevelop requires just a small file somewhere... could we add it under 
> wxlua/build/kdevelop ?

Sure,

Klaas

[Wxlua-users] bakefile 0.2.2

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

Hi,
    official bakefile 0.2.0 is out but it does not integrate yet the 
patches which are required to make it work with wxLua bakefiles.

So I've updated the bakefile version number to 0.2.2 of my personal 
'edition' at uploaded bakefile archive at:

http://www.geocities.com/f18m_cpp217828/frm-bakefile.tar.gz

I also regenerated makefiles and committed them.
The archive also adds to bakefile a working KDevelop generator...

Kdevelop requires just a small file somewhere... could we add it under 
wxlua/build/kdevelop ?


Francesco

[Wxlua-users] Re: Problems with wxStEdit on Linux

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

John Labenski ha scritto:
> On 2/8/06, Francesco Montorsi <f18...@ya...> wrote:
>> Hi John,
>>     maybe the right place to post this would be wxCode mailing list but
>> since it also regards wxLua I'm posting it here...
>>
>> Nor the wxStEdit CVS nor the archive I've downloaded from SF contain the
>> configure script. That was easy for me to fix but probably not for the
>> generic user which has not passed the last months experimenting with
>> bakefile and autoconf :)
>> So I suggest to generate it and add it to CVS.
> 
> If you could do this easily it would be great. I just copied the
> bakefile stuff for wxStEdit from one of your projects a long time ago
> and haven't updated them since.
done




>> Second, I've got problems about missing wx/stedit/setup.h file; I copied
>> setup0.h in setup.h and solved this. Should this file be generated by
>> the configure script ?
> 
> It's one of those things where the user should set it up the way they
> like. I don't want to put it into CVS since it'll just get overwritten
> and be annoying. I suppose that configure could just copy it for
> people.
updated configure to do it



>> Last, I have problems with the usual void* -> int conversions which on
>> 64bit machines like mine are not valid.
>>
>> Since I have access to wxCode CVS, I could check in the required changes...
> 
> Please do, I can't think of where this would be in wxStEdit off the
> top of my head.
you can see them in cvs diffs ;)


I'm currently stopped by errors about include paths like:


#include "../../contrib/src/stc/scintilla/include/Platform.h" // for 
PRectangle
#include "../../contrib/src/stc/scintilla/include/PropSet.h"  // for SString


which refer to non-existent files in my wxCode tree.
These should be really transformed into something else...
unfortunately I checked the wxWidgets contrib section and I've found 
that on Unix scintilla headers are not installed anywhere...

so my proposed fix is:
1) on win32, add the %WXWIN%/contrib/src/stc/scintilla/include path
2) on unix, add a check for these headers. If they are not available, 
tell the user to use the --with-wxdir option to indicate the full path 
of the wxWidgets source tree and use it to install scintilla headers.
Or else, ask the wxdev to add scintilla headers to install rules.


Francesco

Re: [Wxlua-users] Problems with wxStEdit on Linux

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

On 2/8/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi John,
>     maybe the right place to post this would be wxCode mailing list but
> since it also regards wxLua I'm posting it here...
>
> Nor the wxStEdit CVS nor the archive I've downloaded from SF contain the
> configure script. That was easy for me to fix but probably not for the
> generic user which has not passed the last months experimenting with
> bakefile and autoconf :)
> So I suggest to generate it and add it to CVS.

If you could do this easily it would be great. I just copied the
bakefile stuff for wxStEdit from one of your projects a long time ago
and haven't updated them since.

> Second, I've got problems about missing wx/stedit/setup.h file; I copied
> setup0.h in setup.h and solved this. Should this file be generated by
> the configure script ?

It's one of those things where the user should set it up the way they
like. I don't want to put it into CVS since it'll just get overwritten
and be annoying. I suppose that configure could just copy it for
people.

> Last, I have problems with the usual void* -> int conversions which on
> 64bit machines like mine are not valid.
>
> Since I have access to wxCode CVS, I could check in the required changes.=
..

Please do, I can't think of where this would be in wxStEdit off the
top of my head.

> All of this regards wxLua because I need to compile and install wxStEdit
> in order to check if wxLua configure script successfully finds it ;)

Thanks,
    John Labenski

Re: [Wxlua-users] Re: wrong line feeds in project files

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

On 2/8/06, Francesco Montorsi <f18...@ya...> wrote:
> Francesco Montorsi ha scritto:
> > I've found that there must be some problem related to the DSW/DSP files
> > emerged when I replaced the WX_DEBUG,WX_UNICODE options with the
> > BUILD,UNICODE options, not related to EOL.
> >
> > I'm going to look into this right now.
> > Francesco
> I've found that the fact of having BUILD as an alias to WX_DEBUG and
> UNICODE as alias of WX_UNICODE gives problems to msvc6prj.
>
> I've fixed this.

Thanks alot, they load now, I'll try to work on the linking problem
for the wxbindstc lib.
     John Labenski

[Wxlua-users] Re: wrong line feeds in project files

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

Francesco Montorsi ha scritto:
> I've found that there must be some problem related to the DSW/DSP files 
> emerged when I replaced the WX_DEBUG,WX_UNICODE options with the 
> BUILD,UNICODE options, not related to EOL.
> 
> I'm going to look into this right now.
> Francesco
I've found that the fact of having BUILD as an alias to WX_DEBUG and 
UNICODE as alias of WX_UNICODE gives problems to msvc6prj.

I've fixed this.

Francesco

[Wxlua-users] Re: wrong line feeds in project files

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

I've found that there must be some problem related to the DSW/DSP files 
emerged when I replaced the WX_DEBUG,WX_UNICODE options with the 
BUILD,UNICODE options, not related to EOL.

I'm going to look into this right now.
Francesco


Francesco Montorsi ha scritto:
> Hi,
> 
> klaas.holwerda ha scritto:
>> klaas.holwerda wrote:
>> Better regenerate from scratch.
> sorry for this delay but yesterday I could not connect to SF CVS 
> servers... they always gave me connection timed out.
> 
> I've just removed all DSP/DSW files and all makefiles and re-added and 
> recommitted them all again.
> 
> Sorry for this problem...
> Francesco
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

[Wxlua-users] Problems with wxStEdit on Linux

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

Hi John,
    maybe the right place to post this would be wxCode mailing list but 
since it also regards wxLua I'm posting it here...

Nor the wxStEdit CVS nor the archive I've downloaded from SF contain the 
configure script. That was easy for me to fix but probably not for the 
generic user which has not passed the last months experimenting with 
bakefile and autoconf :)
So I suggest to generate it and add it to CVS.

Second, I've got problems about missing wx/stedit/setup.h file; I copied 
setup0.h in setup.h and solved this. Should this file be generated by 
the configure script ?

Last, I have problems with the usual void* -> int conversions which on 
64bit machines like mine are not valid.

Since I have access to wxCode CVS, I could check in the required changes...

All of this regards wxLua because I need to compile and install wxStEdit 
in order to check if wxLua configure script successfully finds it ;)

Francesco

[Wxlua-users] Re: wrong line feeds in project files

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

Hi,

klaas.holwerda ha scritto:
> klaas.holwerda wrote:
> Better regenerate from scratch.
sorry for this delay but yesterday I could not connect to SF CVS 
servers... they always gave me connection timed out.

I've just removed all DSP/DSW files and all makefiles and re-added and 
recommitted them all again.

Sorry for this problem...
Francesco

Re: [Wxlua-users] Re: wrong line feeds in project files

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

On 2/7/06, John Labenski <jla...@gm...> wrote:
> On 2/7/06, Francesco Montorsi <f18...@ya...> wrote:
> > Hi,
> >
> > klaas.holwerda ha scritto:
> > > It looks like they are wrong again.
> > > It is rather strange what i see in e.g. in all/most *.dsp files.
> > >
> > > ( CRCRLF at each line ).
> > ops; I tried to generate the win32 makefiles with CRLF line endings on
> > my Unix station and then committed them to CVS and this should have giv=
e
> > problems to CVS.
> >
> > It should be fixed now.
>
> VS Express 2005 thinks that they're all corrupt now. It just says
> that, for example, "apps_app_wxlua.dsp cannot be loaded. Do you want
> to remove the unloadable project from the solution." I checked the
> line endings and they're all CRLF so I don't know what could be the
> problem. Any ideas?

Can anyone else load the dsp files? I went through the changelog for
apps_app_wxlua.dsp, but I can't really figure out which one of the
changes caused a problem and, of course, VC Express couldn't be
bothered to tell you what line it has a problem with.

Regards,
    John Labenski

Re: [Wxlua-users] Re: wrong line feeds in project files

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

On 2/7/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>
> klaas.holwerda ha scritto:
> > It looks like they are wrong again.
> > It is rather strange what i see in e.g. in all/most *.dsp files.
> >
> > ( CRCRLF at each line ).
> ops; I tried to generate the win32 makefiles with CRLF line endings on
> my Unix station and then committed them to CVS and this should have give
> problems to CVS.
>
> It should be fixed now.

VS Express 2005 thinks that they're all corrupt now. It just says
that, for example, "apps_app_wxlua.dsp cannot be loaded. Do you want
to remove the unloadable project from the solution." I checked the
line endings and they're all CRLF so I don't know what could be the
problem. Any ideas?

Thanks
    John Labenski

Re: [Wxlua-users] Re: wrong line feeds in project files

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

klaas.holwerda wrote:

> Francesco Montorsi wrote:
>
>>
>> It should be fixed now.
>
>
> No, at least wxlua.dsw is still wrong. I can't load it

Even the ones with the right lineend are wrong now??
I copied wxlua.dsw from a previous backup, and now get problems with dsp 
files again.

Better regenerate from scratch.

Klaas

Re: [Wxlua-users] Re: wrong line feeds in project files

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

Francesco Montorsi wrote:

>
> It should be fixed now.

No, at least wxlua.dsw is still wrong. I can't load it

Klaas

[Wxlua-users] Re: wrong line feeds in project files

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

Hi,

klaas.holwerda ha scritto:
> It looks like they are wrong again.
> It is rather strange what i see in e.g. in all/most *.dsp files.
> 
> ( CRCRLF at each line ).
ops; I tried to generate the win32 makefiles with CRLF line endings on 
my Unix station and then committed them to CVS and this should have give 
problems to CVS.

It should be fixed now.

Francesco

[Wxlua-users] wrong line feeds in project files

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

It looks like they are wrong again.
It is rather strange what i see in e.g. in all/most *.dsp files.

( CRCRLF at each line ).

??

At least VC6 can not read them like this.

Klaas

Re: [Wxlua-users] wxluacan as namespace

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

John Labenski wrote:

>Humm, I don't think I understand. I haven't looked at the code for
>wxluacan yet however.
>  
>
Let me try to explain what i want to do without going into detail.

First canvasobjects are placed on a canvas and the are drawn and 
hittested by a member function of that cavasobject.
So for each derived canvasobject there is a different draw and hittest 
functions.
This how there is a rectangle and circle object already. The idea is to 
implement a special canvasobject which has its draw and hittest function 
implemented as a lua function. This lua function can be edited runtime 
if wanted, and the functions (draw and hittest ) are stored in a string 
inside the canvasobject.
So as soon as the object needs to be drawn on the canvas, it needs to 
call the function stored inside the script.
And as input parameter it will get the wxDC* that is used to draw.
The lua canvas object is created in C++ and stored in the canvas. Let's 
assume the default script string is drawing a rectangle. When drawing 
the canvas and arriving at this specific lua canvas object stored in 
that canvas,  i already have the object  pointer (  the c++ object),  
and only need to call  a (draw/hittest) function, which is stored in its 
script string. For each luacanvasobject instance added to the canvas, 
the script string  may  have its own implementation.  One draws a single 
rectangle, and another draws a whole set of whatever.

Easy to say, but i realize it is not so simple ;-)
Maybe i should begin with making all drawing and hittets functions unique.
Like:
MYOBJ_1_Draw( )
MYOBJ_1_Hittest( )
MYOBJ_2_Draw( )
MYOBJ_2_Hittest( )
 etc.
That would reduce it to loading those function at the start, and call 
the right one from C++.

First read some more about calling lua functions,

Thanks,

Klaas
 

Re: [Wxlua-users] wxluacan as namespace

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

On 2/6/06, k. holwerda <kla...@nl...> wrote:
> Hi John,
>
> John Labenski wrote:
>
> >You can have your C function just call lua code directly.
> >m_wxlState.RunString(wxString::Format(wxT("hittest(%f, %f)"), x, y)));
> >in the lua code you can then set variables back to C++ through the bindi=
ng.
> >
> >
> But i need to call a function in Lua which gets as a parameter a wxDC
> pointer from C++.
> So i think i need to push things on the lua stack, and call a function ne=
xt?

Take a look at this, it tells you how to call lua functions from C.
http://www.lua.org/pil/25.2.html

> Also the functions to call are part of the m_script string stored inside
> each luacanvas object.
> And for each such object that script would be different in general, but
> the function is called the same ( Draw and HitTest ).
> Just reporting the functions to lua (using runstring() ) is not enough,
> as i think they must be unique.

So you'll have a wxLuaState for every object? Maybe you can just
create a table in lua to store each object (as a sub table). In each
object's table you can put the functions to call.

> But on the other hand wrapping the luacanvas object to lua does not help
> too, since the instance of the object is in the C++ canvas.
> So i do not want to create the instance inside lua code.
> Eventually i think i need to push the current (to draw/hit ) luacanvas
> object as a (this) pointer on the stack, and next the parameters to the
> member function to call on that object. And when that is ready call the
> function.

Humm, I don't think I understand. I haven't looked at the code for
wxluacan yet however.

-John

Re: [Wxlua-users] Re: Remaining problems on Linux (Re: wxLua on Linux)

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

On 2/6/06, Francesco Montorsi <f18...@ya...> wrote:
> >> 2) wxluacan app works nicely but wxluaapp still crashes at startup
> >> with the same error I got from unix version...
> >>
> > Only when running a script, there is still the same problem of object
> > added in lua and destroyed in c++.
> > But this is just a wxLua bug.
> I'd like to help you and John to solve this but I still have much to
> learn with wxLua.

I can take a look at the bindings tonight. You have to be careful
about using %delete since if you use it wxLua will delete the object
for you, something you don't want for wxWindow derived classes or
objects that are managed in some other code.

-John Labenski

Re: [Wxlua-users] Re: Remaining problems on Linux (Re: wxLua on Linux)

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

On 2/6/06, Francesco Montorsi <f18...@ya...> wrote:
> > I've done some work on bakefiles:

Great.

> 1) I'm using wxCVS also on win32 and I've found that I had to put
> wxLUA_USE_wxHelpController to 0 otherwise I got an error about
> wxWinHelpController.

This was a bug in wxWidgets CVS HEAD a few weeks ago. They had
duplicate #include guards for two different files. IIRC it was
html/helpwnd.h and msw/helpwin.h, it's fixed now.

> 2) wxluacan app works nicely but wxluaapp still crashes at startup with
> the same error I got from unix version...

This error?

>frm@genius:~/work/wxLua/gtksud/bin$ ./wxlua
>[string "./wxlua"]:374: attempt to call field `wxStyledTextCtrl' (a nil
>value)wxLua: Error while running chunkwxLua: Error while running chunk

I don't get it in linux w/ gcc, but I do get it in MSW with VC Express
2005. It has to do with the linker throwing out all of the wxbindstc
lib since it's "not used" directly, but through a wxModule. I think
the cleanest way to do this is to make people run C functions to
initialize each of the binding modules they link to. Similiar to
wxWidgets' WXINIT_ALL_IMAGE_HANDLERS (or whatever it's called). I'll
change this ASAP, but probably tonight.

Regards,
    John Labenski

Re: [Wxlua-users] Re: wxluasetup.h include path

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

On 2/6/06, klaas.holwerda <kho...@xs...> wrote:
> Francesco Montorsi wrote:
>
> > I thought it was possible to build wxLua applications (in C++) which
> > do not include wxluasetup.h... is it right ?
>
> Oke i now understand all behind again.
> I was under the impression wxluasetup.h was always needed.
> But i am not sure.

I thought I removed the
#include "wxbind/setup/wxluasetup.h"
from wxLuaCan? It's not necessary unless in C++ you want to know what
parts of wxWidgets you've got.

Only modules/wxbind should ever care about wxluasetup.h.

-John Labenski

Re: [Wxlua-users] Re: wxluasetup.h include path

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

Francesco Montorsi wrote:

> I thought it was possible to build wxLua applications (in C++) which 
> do not include wxluasetup.h... is it right ? 

Oke i now understand all behind again.
I was under the impression wxluasetup.h was always needed.
But i am not sure.

Klaas

[Wxlua-users] Re: wxluasetup.h include path

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

Hi,

k. holwerda ha scritto:
> We started with only one incldue path to "$(WXLUA_BASEDIR)/modules"
right


> And use in our files this:
> 
> #include "wxlua/include/internal.h"
> 
> But now wxluasetup.h creaped in, and requires to add
> 
> $(WXLUA_BASEDIR)/modules/wxbind/setup
> 
> I wonder if this is wise?
> Is they idea to have several wxluasetup.h files, reality?
yes; if you go in wxLua/modules/wxbind/build and type

   nmake -fmakefile.vc WXLUASETUP_DIR=c:\mydir WXLUABINDLIB_DIR=c:\

then a wxbind library with your custom wxluasetup.h (which must be in 
c:\mydir) is created and put in c:\

> I am not sure i  understand why it had to be in the wxbind module in the 
> end, but if it is meant for that module, why not put it its include dir?
it's in wxbind/ and not directly in modules/ because it regards wxbind 
module only.
And it's not in wxbind/include/ because that dir _must_ always be 
included. the official wxluasetup.h must be something which we can 
decide to include or to exclude at will (e.g. when building user's 
custom wxbind we still need to include wxbind/include folder but we do 
not include the wxbind/setup one; rather than we include the folder 
specified by WXLUASETUP_DIR).

If we keep wxluasetup.h in the wxbind/include then even if we add to 
include search paths WXLUASETUP_DIR we cannot be 100% sure that compiler 
will choose the wxluasetup.h found in WXLUASETUP_DIR rather than the one 
in wxbind/include...


> And include where needed as:
> 
> #include "wxbind/include/wxluasetup.h"
> 
> or next would be oke too i think.
> 
> #include "wxbind/setup/wxluasetup.h"
using this form we force the user to keep his custom wxluasetup.h in a 
setup/ subfolder...


> Like it is now, external librarues/apps need to set two include dirs 
> again. And if there will be more wxluasetup.h files, the is the begining 
> of more include paths.
well, wxlua & wxluaedit applications do not include wxluasetup.h; only 
wxLua modules (and wxLuaCan) do.

I thought it was possible to build wxLua applications (in C++) which do 
not include wxluasetup.h... is it right ?

Francesco

[Wxlua-users] Re: Remaining problems on Linux (Re: wxLua on Linux)

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

Hi,

k. holwerda ha scritto:
>> tested on win32; I fixed some little bugs and found that now 
>> everything should work nicely except for two things:
>>
>> 1) I'm using wxCVS also on win32 and I've found that I had to put 
>> wxLUA_USE_wxHelpController to 0 otherwise I got an error about 
>> wxWinHelpController.
> 
>  From what i updated yesterday.
> 
> When i run wxLua i get the (lua script) error:
> 
> wxlua.exe:374: attempt to call field `wxStyledTextCtrl' ( a nil value)
> 
> And then exit. Is that the same problem?
this is my problem #2; the problem about wxWinHelpController is a 
compile problem in wxbind.
If you did not find it with wx2.6 it's probably because wxdev must have 
done some change in some preprocessor symbol...


>> 2) wxluacan app works nicely but wxluaapp still crashes at startup 
>> with the same error I got from unix version...
>>
> Only when running a script, there is still the same problem of object 
> added in lua and destroyed in c++.
> But this is just a wxLua bug.
I'd like to help you and John to solve this but I still have much to 
learn with wxLua.

Francesco