wxlua-users — wxLua list for users and developers

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

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

Francesco Montorsi wrote:

>>
>>>> 7) can I start to connect the options WXLUASETUP_DIR and
>>>> WXLUABINDLIB_DIR to the build system ?
>>>
>>>
>>> Before starting this work, I need to know exactly how they must work ;)
>>>
>>> If I'm right, they should be used not to *modify* the build of the
>>> wxbind module of wxLua (which should always use the
>>> modules/wxbind/src/wxluasetup.h header and should always go in the lib/
>>> folder) but rather to *create* a new library, built from same 
>>> sources of
>>> wxbind module, which would be created in the WXLUABINDLIB_DIR folder 
>>> and
>>> which would use the wxluasetup.h found in the WXLUASETUP_DIR path.
>>> Is it right ?
>>
>>
>>
>> I would be nice to be able to build the wxbind lib for different
>> wxluasetup.h files, one lib for the wxLua app and others for your
>> programs that use wxLua as a library. Sorry, I didn't follow this too
>> closely.
>
> Klaas, IIRC you would use these options... my description above 
> describe the wanted behaviour correctly, or there is something else 
> which needs to be done ?
>
I wonder first why wxluasetup.h is located in a source directory while 
it is a header file??
Why not place it in wbind/include?

For application/libraries which want to extend/subset the wxLua bindings 
( e.g. have one extra myextra.i file or disable some classes), one needs 
to have a wxluasetup.h of his own. So in such a case there must be two 
wxluasetup.h files in different locations.
Same for the path where the library will be created.
To extend wxLua in the same lua namespace, the new  wxBindings modules  
could handle that once they work correctly.
But that would always lead to an extra library in the end. For creating 
a subset of the wxLua bindings one will always need a second 
wxluasetup.h file.
 I think this should not be part of configure.
It is a feature to be able to use the *.i files from wxLua and a 
different external wxluasetup.h file, to create an extra bindinglib 
which only is oke for the application who needs that. Maybe there or two 
application like that and one wants extend/subset X and the other Y.
Also Installation of wxLua on Unix systems should not influence this 
mechanism.

Although i did not ask for this feature ( John wanted this i think ), i 
would be glad with it now, since that would make it possible to use 
wxLua as is currently. I would just extend the base binding, and forget 
of creating extra bindings using the new mechanism.
Without  this feature, that  is impossible, i would need to ask  users 
to modify wxLua internal first. That would be bad.

If all the new moduler binding features would work correctly, there is 
still a need for the above.  It would be to  create a subset of wxLua  
bindings to make the base  binding library smaller for a specific 
application. If one can Unregister things runtime, the need would be less.

All in all i think those variables would be good to have.

regards,

Klaas








 









-- 
Unclassified

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

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

Hi,

John Labenski ha scritto:
> On 2/1/06, Francesco Montorsi <f18...@ya...> wrote:
>>>>>> 1) STC (more generically CONTRIB) problem
>>> I tried to disconnect wxSTC from the wxWidgets wrappers last night. I
>>> think it will take some doing however. Since they'll share the same
>>> lua namespace, they don't have to, but I would like the generic
>>> flexibility of putting multiple wrappers into the same namespace, any
>>> additional wrappers overwrite earlier ones. I have to do some reading
>>> up on how to add more to lua in C. I hope it won't be too hard.
>> ok, let me know if I can help in some way...
> 
> I believe I got it to work. It currently generates a library that you
> link to in addition to the wxbind library.  You can now add any
> arbitrary number of libraries to any lua namespace.
very nice !


> So, I guess we need to add some more dirs, let me know what you think
> about these.
> 
> wxLua/bindings/wxstc/stc.i
>    or wxLua/bindings/wxwidgets/contrib/stc/stc.i  (maybe better)
there is the possibility that some day wx contrib stuff will be moved in 
wxCode or somewhere else... so I would use wxLua/bindings/wxstc/stc.i 
rather than wxLua/bindings/wxwidgets/contrib/stc/stc.i ...


> wxLua/modules/wxbindstc/  - same as wxbind
>    * I think this has to be in it's own dir at the same level as wxbind
ok



>>>>>> 2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should
>>>>>> be added to wxluasetup.h
>>>>> looking to wxluasetup.h I've found that there is a heading which says
>>>>> that it's generated by "utils/get_luasetup"; however I couldn't find
>>>>> that util.
>>>>> Is that true or that's an old comment?
>>> That is a simple little utility, basicly just grep wxLUA_USE* for the
>>> .i files. I will try to find it if I can.
>> it would be nice to have it in CVS...
> 
> I found it, it's an awk script that was written before we used the
> wxWidgets %if wxUSE_XXX in the bindings so it's pretty dumb and not
> very useful anymore.
> 
> #=======================
> # read in all the .i files, look for "%if" print them out
> 
> grep "%if" *.i | awk 'BEGIN {print("// Automatically generated by
> utils/get_luasetup edit as necessary."); \
>                              print(""); \
>                              print("#ifndef __WXLUA_SETUP__");
>                              print("#define __WXLUA_SETUP__");
>                              print("") } \
>                { len = length($2); printf("#define %s",$2); for
> (i=0;i<40-len;i++) { printf(" ") }; print("1") } \
>                END { print(""); print("#endif // __WXLUA_SETUP__") }'
> #=======================
No problem for me if we decide to maintain wxluasetup.h by hand.
In that case I will add wxLUA_USE_wxCriticalSectionLocker to it, ok ?



> 
>>>>> 7) can I start to connect the options WXLUASETUP_DIR and
>>>>> WXLUABINDLIB_DIR to the build system ?
>>>> Before starting this work, I need to know exactly how they must work ;)
>>>>
>>>> If I'm right, they should be used not to *modify* the build of the
>>>> wxbind module of wxLua (which should always use the
>>>> modules/wxbind/src/wxluasetup.h header and should always go in the lib/
>>>> folder) but rather to *create* a new library, built from same sources of
>>>> wxbind module, which would be created in the WXLUABINDLIB_DIR folder and
>>>> which would use the wxluasetup.h found in the WXLUASETUP_DIR path.
>>>> Is it right ?
>>>
>>> I would be nice to be able to build the wxbind lib for different
>>> wxluasetup.h files, one lib for the wxLua app and others for your
>>> programs that use wxLua as a library. Sorry, I didn't follow this too
>>> closely.
>> Klaas, IIRC you would use these options... my description above describe
>> the wanted behaviour correctly, or there is something else which needs
>> to be done ?
> 
> These are things that you can use with configure?
yes, there will be some options like --enable-custom-bindlib=path and 
--with-custom-wxluasetup=path  to enable the build of this additional lib.


> How would you make
> it so that you can build wxbind for the apps/wxlua and a different one
> for external programs. Do you have to run configure between building
> each of them?
No, that's not required. I'll just add another wxLua module which is 
enabled only when WXLUABINDLIB_DIR!='' and which includes the 
WXLUASETUP_DIR instead of the dir which contains the std wxluasetup.h.

Francesco

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

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

On 2/1/06, Francesco Montorsi <f18...@ya...> wrote:
> >>>>1) STC (more generically CONTRIB) problem
> >
> > I tried to disconnect wxSTC from the wxWidgets wrappers last night. I
> > think it will take some doing however. Since they'll share the same
> > lua namespace, they don't have to, but I would like the generic
> > flexibility of putting multiple wrappers into the same namespace, any
> > additional wrappers overwrite earlier ones. I have to do some reading
> > up on how to add more to lua in C. I hope it won't be too hard.
> ok, let me know if I can help in some way...

I believe I got it to work. It currently generates a library that you
link to in addition to the wxbind library.  You can now add any
arbitrary number of libraries to any lua namespace.

So, I guess we need to add some more dirs, let me know what you think
about these.

wxLua/bindings/wxstc/stc.i
   or wxLua/bindings/wxwidgets/contrib/stc/stc.i  (maybe better)
wxLua/modules/wxbindstc/  - same as wxbind
   * I think this has to be in it's own dir at the same level as wxbind

> >>>>2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should
> >>>>be added to wxluasetup.h
> >>>
> >>>looking to wxluasetup.h I've found that there is a heading which says
> >>>that it's generated by "utils/get_luasetup"; however I couldn't find
> >>>that util.
> >>>Is that true or that's an old comment?
> > That is a simple little utility, basicly just grep wxLUA_USE* for the
> > .i files. I will try to find it if I can.
> it would be nice to have it in CVS...

I found it, it's an awk script that was written before we used the
wxWidgets %if wxUSE_XXX in the bindings so it's pretty dumb and not
very useful anymore.

#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
# read in all the .i files, look for "%if" print them out

grep "%if" *.i | awk 'BEGIN {print("// Automatically generated by
utils/get_luasetup edit as necessary."); \
                             print(""); \
                             print("#ifndef __WXLUA_SETUP__");
                             print("#define __WXLUA_SETUP__");
                             print("") } \
               { len =3D length($2); printf("#define %s",$2); for
(i=3D0;i<40-len;i++) { printf(" ") }; print("1") } \
               END { print(""); print("#endif // __WXLUA_SETUP__") }'
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> >>>7) can I start to connect the options WXLUASETUP_DIR and
> >>>WXLUABINDLIB_DIR to the build system ?
> >>
> >>Before starting this work, I need to know exactly how they must work ;)
> >>
> >>If I'm right, they should be used not to *modify* the build of the
> >>wxbind module of wxLua (which should always use the
> >>modules/wxbind/src/wxluasetup.h header and should always go in the lib/
> >>folder) but rather to *create* a new library, built from same sources o=
f
> >>wxbind module, which would be created in the WXLUABINDLIB_DIR folder an=
d
> >>which would use the wxluasetup.h found in the WXLUASETUP_DIR path.
> >>Is it right ?
> >
> >
> > I would be nice to be able to build the wxbind lib for different
> > wxluasetup.h files, one lib for the wxLua app and others for your
> > programs that use wxLua as a library. Sorry, I didn't follow this too
> > closely.
> Klaas, IIRC you would use these options... my description above describe
> the wanted behaviour correctly, or there is something else which needs
> to be done ?

These are things that you can use with configure? How would you make
it so that you can build wxbind for the apps/wxlua and a different one
for external programs. Do you have to run configure between building
each of them?

Regards,
    John Labenski

[Wxlua-users] Re: FRM Bakefile install path problems

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

Hi,

John Labenski ha scritto:
> I did make and then make install, still no luck. I've tried setting
> PYTHONPATH, LD_LIBRARY_PATH, LD_RUN_PATH, copying _bottlenecks.[l]a to
> other directories, same exact error. Grrr... this is why I don't like
> to make installing things too complicated because it's very easy to
> make it impossible to figure out how to "just make it work."
Weird. on my (linux) system it works correctly. Maybe it is something 
cygwin-related ?

Can you please try to install bakefile 0.1.9.1 and then replace the 
$(prefix)/lib/bakefile, $(prefix)/share/bakefile/rules and 
$(prefix)/share/bakefile/output folders with respectively the files 
taken from my frm-bakefile/src, frm-bakefile/rules, frm-bakefile/output  ?

That should surely work.

Francesco

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

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

Hi,

John Labenski ha scritto:
>>Francesco Montorsi ha scritto:
>>
>>>>1) STC (more generically CONTRIB) problem
> 
> 
> I tried to disconnect wxSTC from the wxWidgets wrappers last night. I
> think it will take some doing however. Since they'll share the same
> lua namespace, they don't have to, but I would like the generic
> flexibility of putting multiple wrappers into the same namespace, any
> additional wrappers overwrite earlier ones. I have to do some reading
> up on how to add more to lua in C. I hope it won't be too hard.
ok, let me know if I can help in some way...


>>>>2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should
>>>>be added to wxluasetup.h
>>>
>>>looking to wxluasetup.h I've found that there is a heading which says
>>>that it's generated by "utils/get_luasetup"; however I couldn't find
>>>that util.
>>>Is that true or that's an old comment?
> 
> 
> That is a simple little utility, basicly just grep wxLUA_USE* for the
> .i files. I will try to find it if I can.
it would be nice to have it in CVS...


>>>>3) wxLua application needs wxStyledTextCtrl wrapper and an error
>>>>should be given when it's not available instead of just failing it at
>>>>runtime (IMO)
> 
> 
> See above about separating it.
> 
> 
>>>7) can I start to connect the options WXLUASETUP_DIR and
>>>WXLUABINDLIB_DIR to the build system ?
>>
>>Before starting this work, I need to know exactly how they must work ;)
>>
>>If I'm right, they should be used not to *modify* the build of the
>>wxbind module of wxLua (which should always use the
>>modules/wxbind/src/wxluasetup.h header and should always go in the lib/
>>folder) but rather to *create* a new library, built from same sources of
>>wxbind module, which would be created in the WXLUABINDLIB_DIR folder and
>>which would use the wxluasetup.h found in the WXLUASETUP_DIR path.
>>Is it right ?
> 
> 
> I would be nice to be able to build the wxbind lib for different
> wxluasetup.h files, one lib for the wxLua app and others for your
> programs that use wxLua as a library. Sorry, I didn't follow this too
> closely.
Klaas, IIRC you would use these options... my description above describe 
the wanted behaviour correctly, or there is something else which needs 
to be done ?

Francesco

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

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

> Francesco Montorsi ha scritto:
> >> 1) STC (more generically CONTRIB) problem

I tried to disconnect wxSTC from the wxWidgets wrappers last night. I
think it will take some doing however. Since they'll share the same
lua namespace, they don't have to, but I would like the generic
flexibility of putting multiple wrappers into the same namespace, any
additional wrappers overwrite earlier ones. I have to do some reading
up on how to add more to lua in C. I hope it won't be too hard.

> >> 2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should
> >> be added to wxluasetup.h
> >
> > looking to wxluasetup.h I've found that there is a heading which says
> > that it's generated by "utils/get_luasetup"; however I couldn't find
> > that util.
> > Is that true or that's an old comment?

That is a simple little utility, basicly just grep wxLUA_USE* for the
.i files. I will try to find it if I can.

> >> 3) wxLua application needs wxStyledTextCtrl wrapper and an error
> >> should be given when it's not available instead of just failing it at
> >> runtime (IMO)

See above about separating it.

> > 6) there are various files which have lines like:
> >         #include "../../../art/something.xpm"
> >    these needs to be changed!
> >    If noone is contrary, I'll do these changes.
> fixed and committed the changes.

ok.

> > 7) can I start to connect the options WXLUASETUP_DIR and
> > WXLUABINDLIB_DIR to the build system ?
> Before starting this work, I need to know exactly how they must work ;)
>
> If I'm right, they should be used not to *modify* the build of the
> wxbind module of wxLua (which should always use the
> modules/wxbind/src/wxluasetup.h header and should always go in the lib/
> folder) but rather to *create* a new library, built from same sources of
> wxbind module, which would be created in the WXLUABINDLIB_DIR folder and
> which would use the wxluasetup.h found in the WXLUASETUP_DIR path.
> Is it right ?

I would be nice to be able to build the wxbind lib for different
wxluasetup.h files, one lib for the wxLua app and others for your
programs that use wxLua as a library. Sorry, I didn't follow this too
closely.

Regards,
    John Labenski

Re: [Wxlua-users] Re: FRM Bakefile install path problems

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

On 1/31/06, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:
> > I'm trying to get things ironed out in Windows, but I can't get the
> > bakefile program to work. I installed it in cygwin and did
> > $configure --prefix=3D/home/jlabenski/lib/frm_bakefile/install (a clean=
 dir)
> >
> > then when I run this in the wxLua/build/bakefile dir
> >
> > $export PYTHONPATH=3D/home/jlabenski/lib/frm-bakefile/install/lib/bakef=
ile/
> > $~/lib/frm_bakefile/install/bin/bakefile_gen
> >
> > I get these errors
> >
> > [jlabenski@P608292 bakefiles]$
> > ~/lib/frm-bakefile/install/lib/bakefile/bakefile_gen.py
> > [1/23] generating watcom from ../../apps/build/bakefiles/apps.bkl
> > Traceback (most recent call last):
> >   File "/home/jlabenski/lib/frm-bakefile/install/lib/bakefile/bakefile.=
py",
> > line 198, in ?
> >     run(sys.argv[1:])
> >   File "/home/jlabenski/lib/frm-bakefile/install/lib/bakefile/bakefile.=
py",
> > line 47, in run
> >     import reader, writer
> >   File "/home/jlabenski/lib/frm-bakefile/install//lib/bakefile/reader.p=
y",
> > line 26, in ?
> >     import mk
> >   File "/home/jlabenski/lib/frm-bakefile/install//lib/bakefile/mk.py",
> > line 25, in ?
> >     import bottlenecks
> >   File "/home/jlabenski/lib/frm-bakefile/install//lib/bakefile/bottlene=
cks.py",
> > line 5, in ?
> >     import _bottlenecks
> > ImportError: No module named _bottlenecks
> > [bakefile_gen] error: bakefile exited with error
> >
> > I assume it's trying to load _bottlenecks.la, but it can't seem to
> > find it. Any ideas?
> yes: you need to do 'make' in bakefile folder. This will create the
> _bottlenecks module.
> you should also do 'make install' to actually install bakefile in
> '/home/jlabenski/lib/frm_bakefile/install'...

I did make and then make install, still no luck. I've tried setting
PYTHONPATH, LD_LIBRARY_PATH, LD_RUN_PATH, copying _bottlenecks.[l]a to
other directories, same exact error. Grrr... this is why I don't like
to make installing things too complicated because it's very easy to
make it impossible to figure out how to "just make it work."

-John

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

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

Hi,

Francesco Montorsi ha scritto:
>> 1) STC (more generically CONTRIB) problem
>>
>> 2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should 
>> be added to wxluasetup.h
> 
> looking to wxluasetup.h I've found that there is a heading which says 
> that it's generated by "utils/get_luasetup"; however I couldn't find 
> that util.
> Is that true or that's an old comment?
> 
> 
> 
>> 3) wxLua application needs wxStyledTextCtrl wrapper and an error 
>> should be given when it's not available instead of just failing it at 
>> runtime (IMO)
>>
> 
> 6) there are various files which have lines like:
>         #include "../../../art/something.xpm"
>    these needs to be changed!
>    If noone is contrary, I'll do these changes.
fixed and committed the changes.


> 
> 7) can I start to connect the options WXLUASETUP_DIR and 
> WXLUABINDLIB_DIR to the build system ?
Before starting this work, I need to know exactly how they must work ;)

If I'm right, they should be used not to *modify* the build of the 
wxbind module of wxLua (which should always use the 
modules/wxbind/src/wxluasetup.h header and should always go in the lib/ 
folder) but rather to *create* a new library, built from same sources of 
wxbind module, which would be created in the WXLUABINDLIB_DIR folder and 
which would use the wxluasetup.h found in the WXLUASETUP_DIR path.
Is it right ?


Francesco

[Wxlua-users] Re: FRM Bakefile install path problems

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

Hi,

John Labenski ha scritto:
> I'm trying to get things ironed out in Windows, but I can't get the
> bakefile program to work. I installed it in cygwin and did
> $configure --prefix=/home/jlabenski/lib/frm_bakefile/install (a clean dir)
> 
> then when I run this in the wxLua/build/bakefile dir
> 
> $export PYTHONPATH=/home/jlabenski/lib/frm-bakefile/install/lib/bakefile/
> $~/lib/frm_bakefile/install/bin/bakefile_gen
> 
> I get these errors
> 
> [jlabenski@P608292 bakefiles]$
> ~/lib/frm-bakefile/install/lib/bakefile/bakefile_gen.py
> [1/23] generating watcom from ../../apps/build/bakefiles/apps.bkl
> Traceback (most recent call last):
>   File "/home/jlabenski/lib/frm-bakefile/install/lib/bakefile/bakefile.py",
> line 198, in ?
>     run(sys.argv[1:])
>   File "/home/jlabenski/lib/frm-bakefile/install/lib/bakefile/bakefile.py",
> line 47, in run
>     import reader, writer
>   File "/home/jlabenski/lib/frm-bakefile/install//lib/bakefile/reader.py",
> line 26, in ?
>     import mk
>   File "/home/jlabenski/lib/frm-bakefile/install//lib/bakefile/mk.py",
> line 25, in ?
>     import bottlenecks
>   File "/home/jlabenski/lib/frm-bakefile/install//lib/bakefile/bottlenecks.py",
> line 5, in ?
>     import _bottlenecks
> ImportError: No module named _bottlenecks
> [bakefile_gen] error: bakefile exited with error
> 
> I assume it's trying to load _bottlenecks.la, but it can't seem to
> find it. Any ideas?
yes: you need to do 'make' in bakefile folder. This will create the 
_bottlenecks module.
you should also do 'make install' to actually install bakefile in 
'/home/jlabenski/lib/frm_bakefile/install'...

Francesco

[Wxlua-users] FRM Bakefile install path problems

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

I'm trying to get things ironed out in Windows, but I can't get the
bakefile program to work. I installed it in cygwin and did
$configure --prefix=3D/home/jlabenski/lib/frm_bakefile/install (a clean dir=
)

then when I run this in the wxLua/build/bakefile dir

$export PYTHONPATH=3D/home/jlabenski/lib/frm-bakefile/install/lib/bakefile/
$~/lib/frm_bakefile/install/bin/bakefile_gen

I get these errors

[jlabenski@P608292 bakefiles]$
~/lib/frm-bakefile/install/lib/bakefile/bakefile_gen.py
[1/23] generating watcom from ../../apps/build/bakefiles/apps.bkl
Traceback (most recent call last):
  File "/home/jlabenski/lib/frm-bakefile/install/lib/bakefile/bakefile.py",
line 198, in ?
    run(sys.argv[1:])
  File "/home/jlabenski/lib/frm-bakefile/install/lib/bakefile/bakefile.py",
line 47, in run
    import reader, writer
  File "/home/jlabenski/lib/frm-bakefile/install//lib/bakefile/reader.py",
line 26, in ?
    import mk
  File "/home/jlabenski/lib/frm-bakefile/install//lib/bakefile/mk.py",
line 25, in ?
    import bottlenecks
  File "/home/jlabenski/lib/frm-bakefile/install//lib/bakefile/bottlenecks.=
py",
line 5, in ?
    import _bottlenecks
ImportError: No module named _bottlenecks
[bakefile_gen] error: bakefile exited with error

I assume it's trying to load _bottlenecks.la, but it can't seem to
find it. Any ideas?

Regards,
    John Labenski

[Wxlua-users] Re: wxLua and wxWidgets versions (was Re: target names)

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

klaas.holwerda ha scritto:
> John Labenski wrote:
> 
>> I agree that we should use the 2.6.2.X versioning for wxLua.
>>
> Oke then lets do it like that.
Ok, updated the bakefiles.
Now the configure scripts sets the wxLua version after detecting the 
wx's one and adding the WXLUA_RELEASE var's content to it.

Francesco

[Wxlua-users] Re: win 32 libnames wrong

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

klaas.holwerda ha scritto:
> HI,
> 
> app_wxlua and app_wxluaedit are looking for old names of libs.
> e.g. wxluasocket.lib
> 
> It is now wxmsw26d_wxluasocket.lib etc.
Ach, sorry.
I'll fix this ASAP.

Francesco

[Wxlua-users] Re: wxLua on win32

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

Hi,

klaas.holwerda ha scritto:
> Francesco Montorsi wrote:
>> More generally this problem (listed as #1 in my "Remaining problems" 
>> mail) can be solved only using configure checks at run-time, IMO.
>> This is because while all other features presence can be 
>> auto-recognized using wxUSE_* symbols, contrib libs and 3rd party code 
>> cannot.
>> What do you think ?
> 
> 
> Why not just put it in install.html. wxWidgets its contrib organization 
> is no good, that is the problem.
> If one compromizes because others are unable to organize the stuff, that 
> is a bit weird.
you are referring to my proposal of making wxStyledTextCtrl as optional, 
right ?
well, I think it would be a nice thing but I do agree that's not 
strictly required once we document in install.html that one needs to:

-> on win32, open contrib/build/stc/stc.dsw and build it
    (or do the same with makefiles)
-> on linux, go to contrib/src/stc and use
     make install

Still, it would be nice to have a fallback.
And surely we need to check for it in configure script, at least on Unix.


> If this is really such an issue, there is always a thirdparty libs 
> trick, meaning copy it in CVS and use it, if not available somewhere else.
that could be a choice.
John, what do you propose ?


> There is also wxstedit which is needed.
I didn't know that.
It's from wxCode. I'm trying to build it; I'll let you know.
Anyway on Unix it would be easy to check for its presence using the 
AM_WXCODE_CHECKFOR_COMPONENT I created in wxcode.m4 macro file.



> Just stop configure if certain things are not available/installed, and 
> tell what is needed.
I prefer those configure which instead of stopping warn you that the 
feature X is not available and provide a fallback for it :)

Francesco

[Wxlua-users] win 32 libnames wrong

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

HI,

app_wxlua and app_wxluaedit are looking for old names of libs.
e.g. wxluasocket.lib

It is now wxmsw26d_wxluasocket.lib etc.

Klaas

Re: [Wxlua-users] Re: wxLua on win32

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

Francesco Montorsi wrote:

>
> More generally this problem (listed as #1 in my "Remaining problems" 
> mail) can be solved only using configure checks at run-time, IMO.
> This is because while all other features presence can be 
> auto-recognized using wxUSE_* symbols, contrib libs and 3rd party code 
> cannot.
> What do you think ?

Why not just put it in install.html. wxWidgets its contrib organization 
is no good, that is the problem.
If one compromizes because others are unable to organize the stuff, that 
is a bit weird.
If this is really such an issue, there is always a thirdparty libs 
trick, meaning copy it in CVS and use it, if not available somewhere else.
There is also wxstedit which is needed.
Just stop configure if certain things are not available/installed, and 
tell what is needed.

Klaas

[Wxlua-users] sample to CVS

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

Hi John,

Should/can i add the new  app/sample to CVS,
That way Francesco  can make it work in bakefile too.?

Or do you want to wait for some reason.

There is still the problem of not correctly working bindings, but that 
can be solved later.
The sample it self works oke, only the scripts will not until that is 
solved.
I tired to figure out how to solve it, but i get lost in all the 
references, and do not no how to register the funtions uniquely. Somehow 
the taking starts with 0 all the time, i don't how it works.

regards,

Klaas

[Wxlua-users] Re: wxLua on win32

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

Hi,

John Labenski ha scritto:
>>app_wxlua complains about wxStryledTextCtrl being nill, which is a lua
>>problem i think.
> 
> 
> Somehow linking to the wxStyledTextCtrl has been removed from the dsp
> files and that wxLUA_USE_wxStyledTextCtrl has been set to 0 in
> wxluasetup.h. 
Sorry; probably it was my fault.
I probably committed my local wxluasetup.h changes together with new 
makefiles.


 >By default these two MUST be on for the main wxLua app
> to run.
I think that wxLua should build out of the box against a properly 
installed wxWidgets. However contribs are not installed by default.
Nor there is a wxUSE_STC symbol anywhere in STC contrib which we can use 
to detect STC.

I think that:
1) we should make wxStyledTextCtrl optional, maybe replacing it with a 
less powerful editor...
2) add a check in configure script for its presence; if present 
configure should set the wxLUA_USE_wxStyledTextCtrl to 1 otherwise to 0.
This can be done only using wxluasetup.h.in -> wxluasetup.h.
I did try to move bindings/wxwidgets/wxluasetup.h.in to 
modules/wxbind/include but I've found that there is a CPP file 
(linternal.cpp IIRC) that uses wxluasetup.h.in directly. Why ?

More generally this problem (listed as #1 in my "Remaining problems" 
mail) can be solved only using configure checks at run-time, IMO.
This is because while all other features presence can be auto-recognized 
using wxUSE_* symbols, contrib libs and 3rd party code cannot.
What do you think ?


> You can turn them off in your version. This is why it so
> important that it's easy create different wxbind lib versions, one for
> the wxLua app and one for your own programs. I will try my hand with
> the new bakefile to link to stc again.
so the WXLUASETUP_DIR and WXLUABINDLIB_DIR options (point #7) must be 
made operational, right ?

I'll try this tomorrow...

Good night :)
Francesco

Re: [Wxlua-users] Re: wxLua on win32

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

On 1/26/06, k. holwerda <kla...@nl...> wrote:
> After setting WXSTEDIT correctly, i still get, and doing:
>
> // If you get an error on this line, maybe you forgot to copy
> //   include/wx/stedit/setup0.h to include/wx/stedit/setup.h ?

You have to copy this by hand, this is intentional.

> I get this:
>
> --------------------Configuration: app_wxluaedit - Win32
> Debug--------------------
> Linking...
> LINK : fatal error LNK1104: cannot open file "wxmsw26d_stedit.lib"
> Error executing link.exe.
>
> wxluaedit.exe - 1 error(s), 0 warning(s)
>
> BTW what did i see when compiling wxstedit, yecka there it is again ;-)
>
> --------------------Configuration: wxstedit - Win32
> Debug--------------------
> Compiling resources...
> Compiling...
> wxstedit.cpp
> Linking...
> LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other
> libs; use /NODEFAULTLIB:library
>
> wxstedit.exe - 0 error(s), 1 warning(s)
>
>
> My stedit produces libraries steditd.lib and stedit.lib, do i need an
> update there?
> Anyway i renamed them, but same problem,
>
> I think ( i am sure )  you need to add:
>
> /libpath:"$(WXSTEDIT)\lib"
>
>
> Oke running app_wxluaedit gives me ( this must be because of the swicth
> problem again ):
>
> NTDLL! 77f767cd()
> NTDLL! 77f6a6a0()
> KERNEL32! 77e6c7c4()
> _CrtIsValidHeapPointer(const void * 0x01222d08) line 1697
> _free_dbg_lk(void * 0x01222d08, int 1) line 1044 + 9 bytes
> _free_dbg(void * 0x01222d08, int 1) line 1001 + 13 bytes
> free(void * 0x01222d08) line 956 + 11 bytes
> wxListKey::~wxListKey() line 379 + 15 bytes
> wxListBase::Append(const char * 0x00b5089c, void * 0x00c47760 class
> wxClassInfo wxLuaShell::ms_classInfo) line 273
> wxObjectList::Append(const char * 0x00b5089c, void * 0x00c47760 class
> wxClassInfo wxLuaShell::ms_classInfo) line 1122 + 30 bytes
> wxHashTable::Put(const char * 0x00b5089c, wxObject * 0x00c47760 class
> wxClassInfo wxLuaShell::ms_classInfo) line 485
> wxClassInfo::Register() line 245
> wxClassInfo::wxClassInfo(const char * 0x00b5089c, const wxClassInfo *
> 0x00c483c0 class wxClassInfo wxSTEditorShell::ms_classInfo, const
> wxClassInfo * 0x00000000, int 472, wxObject * (void)* 0x00000000) line 77
> $E391() line 48 + 32 bytes
> $E395() + 8 bytes
> _initterm(void (void)* * 0x00b4d10c $S396, void (void)* * 0x00b4e8a8
> ___xc_z) line 525
> WinMainCRTStartup() line 274 + 15 bytes
> KERNEL32! 77e8141a()
>
>
> It looks like the problem is in wxstedit all the time ( which i am using
> in wxArt2D too ).
>
> Hope you can fix this.
>
> app_wxlua complains about wxStryledTextCtrl being nill, which is a lua
> problem i think.

Somehow linking to the wxStyledTextCtrl has been removed from the dsp
files and that wxLUA_USE_wxStyledTextCtrl has been set to 0 in
wxluasetup.h. By default these two MUST be on for the main wxLua app
to run. You can turn them off in your version. This is why it so
important that it's easy create different wxbind lib versions, one for
the wxLua app and one for your own programs. I will try my hand with
the new bakefile to link to stc again.

Regards,
    John Labenski

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

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

Hi,
    I've committed last changes to build system. These fix the point #4 
and #5 below and add the "docs" target to the makefiles.


Francesco Montorsi ha scritto:
> Still we have at least the following problems:
> 
> 1) STC (more generically CONTRIB) problem
> 
> 2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should be 
> added to wxluasetup.h
looking to wxluasetup.h I've found that there is a heading which says 
that it's generated by "utils/get_luasetup"; however I couldn't find 
that util.
Is that true or that's an old comment?



> 3) wxLua application needs wxStyledTextCtrl wrapper and an error should 
> be given when it's not available instead of just failing it at runtime 
> (IMO)
> 
> 4) currently doing a thing like:
>      mkdir mybuild && cd mybuild && ../configure && make
>    doesn't work. I'm going to fix this tomorrow.
now works nicely

> 
> 5) change the target names to avoid clashes with system installations of 
> LUA.
done.


However I think that we have some more issues:

6) there are various files which have lines like:
         #include "../../../art/something.xpm"
    these needs to be changed!
    If noone is contrary, I'll do these changes.


7) can I start to connect the options WXLUASETUP_DIR and 
WXLUABINDLIB_DIR to the build system ?


Francesco


PS: I'd like to complete the build system of wxLua ASAP because I'm 
going to have busy weeks later... :(

Re: [Wxlua-users] Re: wxLua and wxWidgets versions (was Re: target names)

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

John Labenski wrote:

>I agree that we should use the 2.6.2.X versioning for wxLua.
>
Oke then lets do it like that.

Klaas

Re: [Wxlua-users] Re: wxLua and wxWidgets versions (was Re: target names)

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

> >> 2) We are going to put wxversion numbers somewhere in library names
> >> in any case. However I'd like to discuss a couple of things about
> >> version.
> >>
> >> I see wxPython works this way: for wx2.6.2 there is wxPython2.6.2.1,
> >> wxPython2.6.1.2, etc...
> >> This is probably the best thing to do as it will be simpler for users
> >> to  understand which release of wxPython targets which release of
> >> wxWidgets but still lets wxPython developers to make other releases
> >> still targeted  to wx 2.6.2 using the fourth digit.
...
>
> AFAIK the fourth digit of wxPython indicates the version of wxPython
> wrappers while the first 3 indicate the version of wxWidgets which must
> be used with those wrappers.
>
> > Also i do not think that wxLuaversionX will be different for different
> > version of wxWidgets.
...
>
> > I would keep the versions of wxLua and wxArt2D independent from wxWidge=
ts.
> I agree for wxArt2d but not for wxLua. wxLua is a wrapper and I'd take
> inspiration for such things from the well-known wxPython package.

I agree that we should use the 2.6.2.X versioning for wxLua. The .i
files do try to maintain backwards compatibility as they move
forwards, but it's a drag trying to keep them working for 2.4 and so
by naming wxLua2.6.2.x we're suggesting to people that this is what
version wxLua is targeted for. For example the MSVC dsp files use 26
in them. People are welcome to hack away to make it work for other
versions and perhaps it will, but the numbering implies that it should
work out of the box for that version of wxWidgets.

Regards,
    John Labenski

[Wxlua-users] Re: wxLua and wxWidgets versions (was Re: target names)

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

Hi,

klaas.holwerda ha scritto:
> Francesco Montorsi wrote:
> 
>>
>> Thus I suggest to stick with wx rules for both linux and win32 libnames.
> 
> 
> Fine with me, but will the next become?
> 
> wxmsw[wxversion without dots][u][d]_[libname].lib
> 
> wxl_msw_wxluaversion without dots][u][d]_[libname].lib
> 
> As you see wxl_ is i think better then wxmsw.
> It must be clear we are taliking wxLua.
maybe you're right; but I would then use (for win32):

     wxlua_msw[wxversion without dots][u][d]_[libname].lib



>> 2) We are going to put wxversion numbers somewhere in library names  
>> in any case. However I'd like to discuss a couple of things about 
>> version.
>>
>> I see wxPython works this way: for wx2.6.2 there is wxPython2.6.2.1, 
>> wxPython2.6.1.2, etc...
>> This is probably the best thing to do as it will be simpler for users 
>> to  understand which release of wxPython targets which release of 
>> wxWidgets but still lets wxPython developers to make other releases 
>> still targeted  to wx 2.6.2 using the fourth digit.
>>
>> Do you agree to use this versioning rule ?
> 
> 
> I think this is confusing, since those numbers normally mean something 
> else.
what do they mean ?

AFAIK the fourth digit of wxPython indicates the version of wxPython 
wrappers while the first 3 indicate the version of wxWidgets which must 
be used with those wrappers.


> Also i do not think that wxLuaversionX will be different for different 
> version of wxWidgets.
 > At least that was the goal of the *.i files.
Yes but say that after releasing wxLua 2.6.2 we found that there is a 
small bug in wrapper generator which needs to be fixed.
How do we call the next release (still targeted for wx2.6.2) ?
Using 4th digit there's no such problem: the new version would be 2.6.2.2



> I would keep the versions of wxLua and wxArt2D independent from wxWidgets.
I agree for wxArt2d but not for wxLua. wxLua is a wrapper and I'd take 
inspiration for such things from the well-known wxPython package.


> Also i am thinking in the future wxWidgets might get to the level that 
> wxCode stuff will be moduler/pluggable.
I hope it, too :)


> In that case we certainly not have the situation that each module goes 
> in the same pase with wxWidgets.
> So better decide a solution that works always in al  situations, which 
> is what i think keep the version seperated.
3d party code (like contribs or wxCode components) should always be 
checked by wxLua configure script or CPP code for its version.
IMO this is an independent issue from the type of versioning we choose 
for wxLua...

Francesco

[Wxlua-users] Re: wxLua website (was Re: wxlua linux)

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

Hi,

klaas.holwerda ha scritto:
> I would not mind a wiki like homepage, if possible WYSIWYG.
> But i don't have the knowledge to realize something like that :-(
I've recently (last week) set up a MediaWiki for wyoguide at:

   http://wyoguide.sf.net/wiki

I could do the procedure again for wxLua.
However I don't know if a wiki is what we want... (just imaging to the 
spam we could start to receive!)...



>> We could ask to the owner of the A) link, to let us copy the contents 
>> of the website on B) and then setup a redirection from A) to B).
> 
> 
> Put it in CVS ?
yes, that can be a good idea. Specially if someone adds to his crontab a 
script which keeps the SF servers up2date with the CVS contents.

Francesco

Re: [Wxlua-users] wxLua website (was Re: wxlua linux)

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

Francesco Montorsi wrote:

> Hi,
>
> k. holwerda ha scritto:
>
>> Forget about the old site.
>
>
> I've found that searching for wxLua in google gives this link:
>       A) http://www.luascript.thersgb.net
> and the site at:
>       B) http://wxlua.sf.net
>
> is not as good as the A) link :)

I would not mind a wiki like homepage, if possible WYSIWYG.
But i don't have the knowledge to realize something like that :-(

>
> We could ask to the owner of the A) link, to let us copy the contents 
> of the website on B) and then setup a redirection from A) to B).

Put it in CVS ?

>
> IMHO the current situation is confusing. There should be a single 
> website for each single project (mirroring it would only generate 
> synch problems IMO).

I agree completely.

>
> This is not a primary issue, though.
> Unless until we don't have wxLua 2.6.2.1 ready :))

Close ;-)

Klaas

Re: [Wxlua-users] wxLua and wxWidgets versions (was Re: target names)

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

Francesco Montorsi wrote:

>
> Thus I suggest to stick with wx rules for both linux and win32 libnames.

Fine with me, but will the next become?

wxmsw[wxversion without dots][u][d]_[libname].lib

wxl_msw_wxluaversion without dots][u][d]_[libname].lib

As you see wxl_ is i think better then wxmsw.
It must be clear we are taliking wxLua.
Same i would say:

a2d_msw etc.

>
>
>
> 2) We are going to put wxversion numbers somewhere in library names  
> in any case. However I'd like to discuss a couple of things about 
> version.
>
> I see wxPython works this way: for wx2.6.2 there is wxPython2.6.2.1, 
> wxPython2.6.1.2, etc...
> This is probably the best thing to do as it will be simpler for users 
> to  understand which release of wxPython targets which release of 
> wxWidgets but still lets wxPython developers to make other releases 
> still targeted  to wx 2.6.2 using the fourth digit.
>
> Do you agree to use this versioning rule ?

I think this is confusing, since those numbers normally mean something else.
Also i do not think that wxLuaversionX will be different for different 
version of wxWidgets.
At least that was the goal of the *.i files.

I would keep the versions of wxLua and wxArt2D independent from wxWidgets.
It should be in the install.html and configure etc. ( there are/will be 
more dependencies, so where would one stop??)
Also i am thinking in the future wxWidgets might get to the level that 
wxCode stuff will be moduler/pluggable.
In that case we certainly not have the situation that each module goes 
in the same pase with wxWidgets.
So better decide a solution that works always in al  situations, which 
is what i think keep the version seperated.

regards,

Klaas