wxlua-users Mailing List for wxLua

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 :)

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

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

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

Francesco

Hi,

k. holwerda ha scritto:
> 
> 
> Francesco Montorsi wrote:
> 
>> Hi,
>>
>>
>>      libwxlua_[gtk2|x11|msw|...][u][d]_lua-[wxversion].so.0
>>      libwxlua_[gtk2|x11|msw|...][u][d]_lualib-[wxversion].so.0
>>      libwxlua_[gtk2|x11|msw|...][u][d]_wxbind-[wxversion].so.0
>>      libwxlua_[gtk2|x11|msw|...][u][d]_wxlua-[wxversion].so.0
>>      libwxlua_[gtk2|x11|msw|...][u][d]_wxluadebug-[wxversion].so.0
>>      libwxlua_[gtk2|x11|msw|...][u][d]_wxluasocket-[wxversion].so.0
Just a few things which came up to my mind while updating bakefiles:
1) on win32 it's best not to use a version in the libname with dots 
(instead of 2.6, we should use 26); furthermore, we can even choose to 
use the same wx library convention:

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

  So, what do you propose? I think that while on linux we can adopt a 
more complex library naming (like 
libwxlua_[gtk2|x11|msw|...][u][d]_lua-[wxversion].so.0) since the user 
will probably use `pkg-config wxlua --libs` to get libname, on win32 we 
should keep the library name shorter as wxWidgets does.
Thus I suggest to stick with wx rules for both linux and win32 libnames.



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 ?

AFAIK the only files containing wxLua version numbers should be:
1) build/bakefiles/wxluabase.bkl
2) build/autoconf/configure.ac

If we decide to use a wxPython-like versioning, then we can store a 
single version number in these files (the fourth number).

In any case we would still use only wx major and minor version digits in 
libnames, unless someone has other ideas....


Francesco

Hi,

WxLua is now on sourceforge,

cvs.sourceforge.net:/cvsroot/wxlua

Forget about the old site.
We just recently started to get it to work on linux, almost finished.

The makefiles are much improved and VC project files are available.
All generated via bakefile, used in wxWidgets too.

You compile and install wxWidgets 2.6.2 and after that wxLua.
In case of problems, the mailing list  of wxLua is at:

wxl...@li...

regards,

Klaas

ro...@co... wrote:

> Has anyone got a copy of the wxLua binary for Linux tarball? I'm about 
> to go completely bald pulling my hair out over the stupid broken link 
> on the wxlua website. It seems only the Windows .zip files are 
> available - the .tar.gz have vanished. I can't even find them in 
> archive.org!!!
>
> Tried to  compile the windows source (I'm assuming it's the same as 
> the tared source) but I've run into several weird compiler errors. I 
> just want the dratted binary for crying out loud!
>
> So... Um... Help! Please... :-(
>
>  Thanx! :-D
>
>  
>
> - Rodney 
>
>

-- 
Unclassified

k. holwerda wrote:

>
>
> Francesco Montorsi wrote:
>
>
>> -> fixed wxLua.dsw
>
app_wxlua complains in batch build that it can not find wxluasocket.lib, 
but the second time it is oke,
I think this is a dependency problem.

--------------------Configuration: app_wxlua - Win32 
Debug--------------------
Compiling resources...
Compiling...
lconsole.cpp
wxlua.cpp
Generating Code...
Linking...
LINK : fatal error LNK1104: cannot open file "wxluasocket.lib"
Error executing link.exe.


Can the default configuration be set to debug? Or is this not best?



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 ?

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.

Coming closer to perfect ;-)

regards,

Klaas




-- 
Unclassified

Francesco Montorsi wrote:

> Hi,
>
>
>      libwxlua_[gtk2|x11|msw|...][u][d]_lua-[wxversion].so.0
>      libwxlua_[gtk2|x11|msw|...][u][d]_lualib-[wxversion].so.0
>      libwxlua_[gtk2|x11|msw|...][u][d]_wxbind-[wxversion].so.0
>      libwxlua_[gtk2|x11|msw|...][u][d]_wxlua-[wxversion].so.0
>      libwxlua_[gtk2|x11|msw|...][u][d]_wxluadebug-[wxversion].so.0
>      libwxlua_[gtk2|x11|msw|...][u][d]_wxluasocket-[wxversion].so.0
>
> Do you agree ?
>
I do agree!

Klaas

-- 
Unclassified