wxlua-users — wxLua list for users and developers

Re: [wxlua-users] Fixing distrib/macbundle/wxLua.r.gz

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

Anders F Björklund ha scritto:
> A non-broken gzipped copy can be found at:
> http://www.algonet.se/~afb/wx/wxLua.r.gz
> 
> It should zmore as something like this:
> data 'icns' (-16455, "Item Icon") {
>          $"6963 6E73 0000 7747 4943 4E23 0000 0108"
>          ...
> 
> Having it in "clear text" in the distribution
> works with me, it needs to be gunzipped anyway.
>   12K    wxLua.r.gz
>   84K    wxLua.r
> 
> The Mac icon (128x128) looks like this:
> http://www.algonet.se/~afb/wx/wxLua.png
well, could you put an SVG like this:

    http://wxlua.sourceforge.net/images/wxlualogo.svg

in a .r file? We could then add it (gunzipped) to CVS.

Thanks,
Francesco

Re: [wxlua-users] wxLua on wxMac

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

Anders F Björklund ha scritto:
> Francesco Montorsi:
> 
>>> Not actually using it, but will happy to give building it a try...
>> Great! Also remember us if you need some other file to generate the
>> MacBundle which is not in CVS yet. In fact, if the generation is more
>> than 2-3 commands, we may also add a script to do it under
>> distrib\macbundle (just like I do for autopackages under
>> distrib\autopackage).
> 
> Trying to build wxLua CVS (2.8.0) on wxMac 2.8.0 UNICODE/Universal.
> 
> Here are the issues I've run into:
> 
> - Bakefile doesn't seem to support Universal Binaries, it uses the
>    -MMD flag which chokes the compilation
with which error?

> and doesn't support the
>    -isysroot flag which chokes the linking. 
hmm, are you saying that it doesn't add (by default) the -isysroot or 
that in some way you cannot specify it at all?

>So building twice it is
>    (once for PowerPC and once for Intel, and then merging with lipo)
hmmm, I see the -MMD flag is added by bk-make-pch:

# can do this because gcc is >= 3.4:
${compiler} -o ${outfile} -MMD -MF "${depsfile}" "${headerfile}"

It's used for dependency tracking. I don't understand why it chokes your 
compilation but I wonder if doing:

   LDFLAGS="-isysroot" ./configure --disable-dependency-tracking

wouldn't help you to solve these problems...



> - The generated shared libraries only have versioned names, so they
>    aren't able to find eachother later when trying to run the binaries.
>    i.e. it installs *-2.8.0.0.0.dylib but looks for *-2.8.0.dylib ?
>    Symlinking these manually after installation fixes this issue...
hmmm, strange....

I just know that bakefiles use the following:

             <version>$(WXLUA_VERSION)</version>
             <so_version>$(WXLUA_SOVERSION)</so_version>
             <mac_version>$(WXLUA_MACVERSION)</mac_version>

where WXLUA_MACVERSION should be set to 1, WXLUA_SOVERSION to 0.0.0 and 
WXLUA_VERSION to 2.8.0

Maybe I should change mac_version tag to something else? Or remove it 
completely... I think I took that <mac_version> "logic" from wxWidgets 
bakefiles but now grepping for <mac_version> in wx\build\bakefiles gives 
no result. They have replaced it with:

     <set var="WXMACVERSION_CMD">
         <if cond="PLATFORM_MACOSX=='1'">
            <!-- Version can't be 0, so add 1 to it to force it to be 
non null -->
             -compatibility_version $(int(WX_AGE)+1).0 -current_version 
$(int(WX_AGE)+1).$(WX_REVISION)
         </if>
     </set>


         <!-- FIXME: until libtool scheme is implemented in bakefile -->
         <ldflags cond="FORMAT=='autoconf'">$(WXMACVERSION_CMD)</ldflags>

Do you think adding the above would fix the problem?


> - The generated program does not use Rez to set the icons, which
>    for wxWidgets means that they won't receive any events either.
sorry, I'm not sure to get what you mean here saying "events"...

>    It needs to call upon Rez with the Carbon.r and wxLua.r files.
>    Unfortunately `wx-config --rezflags` is now gone from wx 2.8.0.
>    To complicate things more, the wxLua.r.gz is corrupted (ASCII?)
sorry, I always forgot the "-kb" flag when adding binary things to CVS.
See my other msg.

> 
> - wxStEdit seems to install the library as libstedit, but is later
>    trying to use it for linking with the libwx_macu_stedit name.
libwx_macu_stedit should be right. Are you sure are you using the latest 
CVS for wxStEdit too?


>    Again, symlinking to the rescue - but it seems there are some
>    duplicated symbols (?) between libwx and libwxlua, so I think I
>    will have to rebuild the entire thing with static libraries...
> 
> I can do a manual build / packaging for Christmas, but I would
> hardly state that it builds "out of the box" on Mac OS X :-)
right. Would be nice to solve these problems before 2.8.0.0.

Francesco

[wxlua-users] wxluafreeze apps on Mac OS X

[<af...@al...>]

It is working good, just needs a post-process step
of adding a resource fork or an application bundle:

wxLuaSudoku.app/
`-- Contents
     |-- Info.plist
     |-- MacOS
     |   `-- wxLuaSudoku
     |-- PkgInfo
     `-- Resources
         `-- wxLua.icns

The default static build might be a tad on the large
side, though. Especially with wxWidgets included too:

  11M    ppc-static/wxluasudoku
  11M    x86-static/wxluasudoku
  22M    wxLuaSudoku.app
6.3M    wxLuaSudoku.zip

No UPX for Mach-O/i386 yet, as far as I know ? Think
there is for Mach-O/ppc32 though, so there is hope...

Works good on Mac OS X 10.4, anyway. Looks good, too:
http://www.algonet.se/~afb/wx/wxlua28-wxluasudoku.png


No requirements needed, since this was a static build:
(i.e. just unzip, double-click the icon and it starts)

wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku: Mach-O fat file with 2 
architectures
wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku (for architecture ppc):      
Mach-O executable ppc
wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku (for architecture i386):     
Mach-O executable i386

wxLuaSudoku.app/Contents/MacOS/wxLuaSudoku:
         
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime 
(compatibility version 1.0.0, current version 6.0.0)
         /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
(compatibility version 1.0.0, current version 275.0.0)
         /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 128.0.0)
         /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 11.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 88.3.4)
         /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit 
(compatibility version 1.0.0, current version 1.0.0)
         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current 
version 1.2.3)
         /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current 
version 5.0.0)
         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, 
current version 7.4.0)
         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current 
version 1.0.0)

The wx.framework and wxLua.framework shared libraries
should help keep the wxLua overhead down to just once...

248K    ppc-shared/wxluasudoku
276K    x86-shared/wxluasudoku

Of course, then one might as well wrap the program with
a call to "wxlua" and not use freeze in the first place ?

--anders

[wxlua-users] Mac link error fixed / Mac resources

[<af...@al...>]

Here was the error:
ld: Undefined symbols:
__ZNK20wxTopLevelWindowBase10GetMaxSizeEv referenced from libwxlua 
expected to be defined in libwx
/usr/bin/libtool: internal link edit command failed
make[1]: *** [../lib/libwxlua_macu_wxbindstc-2.8.0.0.0.dylib] Error 1

Not sure where that came from, though, rebuilt it this morning and it 
worked ?
Must have forgotten to clean wxLua up properly or something silly like 
that...
But there's still a lot of problems with Bakefile and the Universal 
Binaries.
(but those are probably generic, and not isolated to just the wxLua 
building)

Sizes are much better now: (needs wxWidgets too, but)
  44K    bin/lua
360K    bin/wxlua
360K    bin/wxluacan
3.0M    bin/wxluaedit
  84K    bin/wxluafreeze
328K    lib/liblua5.1.0.0.0.dylib
7.4M    lib/libwxlua_macu_wxbind-2.8.0.0.0.dylib
908K    lib/libwxlua_macu_wxbindstc-2.8.0.0.0.dylib
400K    lib/libwxlua_macu_wxlua-2.8.0.0.0.dylib
392K    lib/libwxlua_macu_wxluadebug-2.8.0.0.0.dylib
536K    lib/libwxlua_macu_wxluasocket-2.8.0.0.0.dylib
====
4.2M    /tmp/wxlua.zip

Will see if I can get the Makefile/Bakefile patch for Rez/SetFile done,
and do a "macbundle" script to bundle wxLuaEdit and LuaCan up as .app...
(needs to generate a few Info.plist and such, using the 
@PACKAGE_VERSION@
and do some other XML bookkeeping like that - pretty much like 
autopackage)

It does this now:
/Developer/Tools/SetFile -t APPL ../bin/wxlua

It should do this:
/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r \
../../apps/../distrib/macbundle/wxLua.r -o ../bin/wxlua
/Developer/Tools/SetFile -a C -t APPL ../bin/wxlua

This will give a big "crossed-over" icon on Intel, but it can't be 
helped.
If you don't add a resource fork, it will not receive any events at 
all...
This procedure goes for *all* wx programs, also the ones with 
wxluafreeze.
For the non-commandline programs we can use bundles, like 
"wxLuaEdit.app".

http://www.algonet.se/~afb/wx/wxlua-resfork.png (Tiger thinks it's 
Classic)

--anders

Re: [wxlua-users] wxLua on wxMac

[<af...@al...>]

John Labenski wrote:

> Is there anything wrong with the code itself? It sounds like that part
> at least works.

I think it's only 1 symbol (in Makefiles/linking), should be fixable.
(Mac OS X is a little picky about "indirect symbols", for instance)

>> It built OK using static linking of the various libraries.
>> (using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS)
>
> I will be getting an antique mac next week to play with. I thought
> that macs could only be built staticly? There was also some issue
> about shared or multilib that didn't work with wxWidgets itself or has
> that been fixed?

No, it can be built statically and dynamically... But there are only
instructions from wxWidgets on how to be built it with static linking.

wxWidgets developers didn't want to do shared Mac libs until next year.

>> So I think I will have to get the dynamic linking working.
>> (the above sizes were with the debugging symbols stripped)
>
> Not cool. Doesn't OSX install wxWidgets already? Can we just link
> against that, even if it's not 2.8, 2.6 was pretty good and probably
> good enough for the Mac binary. What do you think about that?

Tiger shipped with 2.5.3. Leopard will supposedly ship with 2.8.0.
And I think I would rather stay clear of the Apple library versions ?

I'm using 2.6.3pl2++ for Mac OS X, and I will use 2.8.1 later on.

> Dumb question, since mac installs programs to /Applications as a
> package, does it also distribute the libs to the /Library dir for
> shared libs.

Unfortunately there are no Frameworks for wxWidgets, so it's
installed UNIX-style under /usr... (as mac-unicode-debug-2.5)

I've done some framework buids at http://www.algonet.se/~afb/wx/

--anders

Re: [wxlua-users] wxLua on wxMac

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

On 12/21/06, Anders F Bj=F6rklund <af...@al...> wrote:
> > I can do a manual build / packaging for Christmas, but I would
> > hardly state that it builds "out of the box" on Mac OS X :-)

Is there anything wrong with the code itself? It sounds like that part
at least works.

> It built OK using static linking of the various libraries.
> (using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS)

I will be getting an antique mac next week to play with. I thought
that macs could only be built staticly? There was also some issue
about shared or multilib that didn't work with wxWidgets itself or has
that been fixed?

> The good news:
> http://www.algonet.se/~afb/wx/wxlua28-wxluacan.png
> http://www.algonet.se/~afb/wx/wxlua28-wxluamisc.png
> http://www.algonet.se/~afb/wx/wxlua28-wxluahello.png

Cool.

> The bad news:
> 316K    bin/lua
>   24M    bin/wxlua
>   21M    bin/wxluacan
>   27M    bin/wxluaedit
>   21M    bin/wxluafreeze
> 512K    lib/liblua5.1.a
>   12M    lib/libwxlua_macu_wxbind-2.8.a
> 1.2M    lib/libwxlua_macu_wxbindstc-2.8.a
> 536K    lib/libwxlua_macu_wxlua-2.8.a
> 488K    lib/libwxlua_macu_wxluadebug-2.8.a
> 756K    lib/libwxlua_macu_wxluasocket-2.8.a
> =3D=3D=3D=3D
>   32M    wxlua.zip
>
> So I think I will have to get the dynamic linking working.
> (the above sizes were with the debugging symbols stripped)

Not cool. Doesn't OSX install wxWidgets already? Can we just link
against that, even if it's not 2.8, 2.6 was pretty good and probably
good enough for the Mac binary. What do you think about that?

Dumb question, since mac installs programs to /Applications as a
package, does it also distribute the libs to the /Library dir for
shared libs.

Regards,
    John Labenski

Re: [wxlua-users] wxLua on wxMac

[<af...@al...>]

> I can do a manual build / packaging for Christmas, but I would
> hardly state that it builds "out of the box" on Mac OS X :-)

It built OK using static linking of the various libraries.
(using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS)

The good news:
http://www.algonet.se/~afb/wx/wxlua28-wxluacan.png
http://www.algonet.se/~afb/wx/wxlua28-wxluamisc.png
http://www.algonet.se/~afb/wx/wxlua28-wxluahello.png

The bad news:
316K    bin/lua
  24M    bin/wxlua
  21M    bin/wxluacan
  27M    bin/wxluaedit
  21M    bin/wxluafreeze
512K    lib/liblua5.1.a
  12M    lib/libwxlua_macu_wxbind-2.8.a
1.2M    lib/libwxlua_macu_wxbindstc-2.8.a
536K    lib/libwxlua_macu_wxlua-2.8.a
488K    lib/libwxlua_macu_wxluadebug-2.8.a
756K    lib/libwxlua_macu_wxluasocket-2.8.a
====
  32M    wxlua.zip

So I think I will have to get the dynamic linking working.
(the above sizes were with the debugging symbols stripped)

--anders

PS. These were the Universal Binary builds (i.e. ppc+x86)
It requires Mac OS X 10.4 to run, can do a 10.3 build too.

[wxlua-users] Fixing distrib/macbundle/wxLua.r.gz

[<af...@al...>]

A non-broken gzipped copy can be found at:
http://www.algonet.se/~afb/wx/wxLua.r.gz

It should zmore as something like this:
data 'icns' (-16455, "Item Icon") {
         $"6963 6E73 0000 7747 4943 4E23 0000 0108"
         ...

Having it in "clear text" in the distribution
works with me, it needs to be gunzipped anyway.
  12K    wxLua.r.gz
  84K    wxLua.r

The Mac icon (128x128) looks like this:
http://www.algonet.se/~afb/wx/wxLua.png

--anders

Re: [wxlua-users] wxLua on wxMac

[<af...@al...>]

Francesco Montorsi:

>> Not actually using it, but will happy to give building it a try...
> Great! Also remember us if you need some other file to generate the
> MacBundle which is not in CVS yet. In fact, if the generation is more
> than 2-3 commands, we may also add a script to do it under
> distrib\macbundle (just like I do for autopackages under
> distrib\autopackage).

Trying to build wxLua CVS (2.8.0) on wxMac 2.8.0 UNICODE/Universal.

Here are the issues I've run into:

- Bakefile doesn't seem to support Universal Binaries, it uses the
   -MMD flag which chokes the compilation and doesn't support the
   -isysroot flag which chokes the linking. So building twice it is
   (once for PowerPC and once for Intel, and then merging with lipo)

- The generated shared libraries only have versioned names, so they
   aren't able to find eachother later when trying to run the binaries.
   i.e. it installs *-2.8.0.0.0.dylib but looks for *-2.8.0.dylib ?
   Symlinking these manually after installation fixes this issue...

- The generated program does not use Rez to set the icons, which
   for wxWidgets means that they won't receive any events either.
   It needs to call upon Rez with the Carbon.r and wxLua.r files.
   Unfortunately `wx-config --rezflags` is now gone from wx 2.8.0.
   To complicate things more, the wxLua.r.gz is corrupted (ASCII?)

- wxStEdit seems to install the library as libstedit, but is later
   trying to use it for linking with the libwx_macu_stedit name.
   Again, symlinking to the rescue - but it seems there are some
   duplicated symbols (?) between libwx and libwxlua, so I think I
   will have to rebuild the entire thing with static libraries...

I can do a manual build / packaging for Christmas, but I would
hardly state that it builds "out of the box" on Mac OS X :-)

--anders

Re: [wxlua-users] wxLua 2.8.0.0 release date

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

On 12/21/06, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:

> However mails are ok anyway ;)

Is there anything you'd like me to do? If you don't mind doing it, I
thought all that needs to be done is compiling in VC6 and getting the
inno setup working.

> > but I should be around sunday for a bit.
> ok, let's do sunday morning then. Hopefully it should be a pain-free
> process however.
>
> > I will check these in an hour.
> > VS 2005 dsw using debug lib/dll
> > VC 2003 makefile.vc release lib/dll
> good, yesterday however I tried to build with VC2003 and I've found that
> the LNK4006 problem was not solved... :(

I comes and goes or maybe I'm not paying attention sometimes? It makes
no sense to me and seems harmless, though annoying.

> > I think the C++ code is ok, there's a few things on my todo list, but
> > nothing that should get done before the release.
> good.
>
> BTW I've tried to use a bit the samples with the very latest CVS and
> I've found that some of them may need some small fixes:

I've fixed them, thanks for testing! These are a result of the
tightening up of the allowed parameters to the functions and, yes,
most of these were bugs where the variable passed to a wxLua function
was either a typo or not initialized and had a value of 'nil' which
used to translate to 0 or "". I think it's better this way since It's
very easy to forget [wx.]XXX and if you just get 0 or "" you might not
even know that there's a problem without rigorous testing.

> frm@ubuntu:~/work/wxLua/samples$ wxlua debug.wx.lua
> [Debug] 18:07:33: ./wxlua/src/wxlbind.cpp(330): assert
> "!wxlState.GetCallBaseClassFunction()" failed in
> wxLua_lua_getTableFunc(): Base class function call not reset
> Trace/breakpoint trap
>
> (choosing File->Debug)

This sample is BROKEN and I really don't have any idea what it's
supposed to do. It should be completely rewritten to more simply show
some debugging code instead of having all of the extra scribble code
which just confuses things. All it does now is popup a messagebox
telling you that it doesn't do anything. It has some interesting ideas
so I don't want to erase it and start over.

Also... and this is for later, the virtual function code needs to be
tweaked or rewritten. The error you got is a check for recursion, but
this isn't a show stopper since the error is for trying to make a
function for an object in *lua* virtual, which is quite different than
overriding a virtual function in C++ which requires you to really
sublcass it in C++. There's not much point in making virtual lua
functions since nobody but the lua code you write will ever call them.
I need to think more about this though.

Thanks
    John Labenski

Re: [wxlua-users] wxLua 2.8.0.0 release date

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

klaas.holwerda ha scritto:
> Francesco Montorsi wrote:
>> Unfortunately I'm busy with wxpresets patch now...
>>   
> It looks like  its going to be a happy new year after all!! ;-)
right ;)

The even better news is that Vaclav said that early in January he plans 
to make bakefile 0.2.2 with the option-renaming patch applied!

In this way it will be possible to cleanup all the wxLua build system 
adopting the official wxpresets (after patch gets applied) and the 
official bakefile.

> I got so annoyed that i started to merge my Cmake stuff with the 
> official  Cmake FindWxWidgets right away.
> This  Cmake  preset  will be easy :-)
great!

I'll send you privately (just because it doesn't belong to a wxlua-users 
mailing list) a mail so that I can give some advices.

Francesco

Re: [wxlua-users] wxLua 2.8.0.0 release date

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

Francesco Montorsi wrote:
>
> Unfortunately I'm busy with wxpresets patch now...
>   
It looks like  its going to be a happy new year after all!! ;-)
I got so annoyed that i started to merge my Cmake stuff with the 
official  Cmake FindWxWidgets right away.
This  Cmake  preset  will be easy :-)

Klaas

Re: [wxlua-users] wxLua 2.8.0.0 release date

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

John Labenski ha scritto:
> On 12/21/06, Francesco Montorsi <f18...@ya...> wrote:
>> is it ok then to make wxLua 2.8.0.0 release saturday morning ?
>>
>> For doing releases I think it's better IM than emails (to solve any
>> eventual problem coming out at the last moments - they never are
>> missing); so:
>>
>>   - if you want to contact me through IM you can use my email address
>> for Yahoo messenger or fr...@ho... with MSN messenger.
>>
>>   - I'll also be available through #IRC at wxWidgets chat room.
> 
> I haven't used IM in years and I hate to say it, don't even know how
> to go about using it. 
well, if you're on Unix there's the very good "X-Chat GNOME" for IRC 
chatting which is very simple to use (until yesterday I had never used 
it but found out #wxwidgets IRC channel very easily).

However mails are ok anyway ;)

>I'll also be away on saturday for the holidays,
good holidays then!

> but I should be around sunday for a bit.
ok, let's do sunday morning then. Hopefully it should be a pain-free 
process however.

> I will check these in an hour.
> VS 2005 dsw using debug lib/dll
> VC 2003 makefile.vc release lib/dll
good, yesterday however I tried to build with VC2003 and I've found that 
the LNK4006 problem was not solved... :(


> I think the C++ code is ok, there's a few things on my todo list, but
> nothing that should get done before the release.
good.

BTW I've tried to use a bit the samples with the very latest CVS and 
I've found that some of them may need some small fixes:

rm@ubuntu:~/work/wxLua/samples$ wxlua coroutine.wx.lua
lua: Error while running chunk
wxLua: Expected a string for parameter 3, but got 'nil'.
stack traceback:
         [C]: in function 'wxTextCtrl'
         coroutine.wx.lua:47: in function 'new'
         coroutine.wx.lua:139: in function <coroutine.wx.lua:128>

(when clicking the button)


frm@ubuntu:~/work/wxLua/samples$ wxlua debug.wx.lua
[Debug] 18:07:33: ./wxlua/src/wxlbind.cpp(330): assert 
"!wxlState.GetCallBaseClassFunction()" failed in 
wxLua_lua_getTableFunc(): Base class function call not reset
Trace/breakpoint trap

(choosing File->Debug)


frm@ubuntu:~/work/wxLua/samples$ wxlua wxluasudoku.wx.lua
lua: Error while running chunk
wxLua: Expected a number for parameter 2, but got 'nil'.
stack traceback:
         [C]: in function 'AppendMenu'
         wxluasudoku.wx.lua:4874: in function 'main'
         wxluasudoku.wx.lua:5036: in main chunk

lua: Error while running chunk


at start.

Unfortunately I'm busy with wxpresets patch now...

Francesco

Re: [wxlua-users] lua.h not found

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

I that an update just now, and
It/All is oke again on linux.

Thanks,

Klaas

Francesco Montorsi wrote:
> klaas.holwerda ha scritto:
>   
>> Hi,
>>
>> Can't compile on linux. The lua.h is not found, very likely missing an 
>> include path now.
>> This is from wxlstate.h
>>     

Re: [wxlua-users] wxLua 2.8.0.0 release date

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

On 12/21/06, Francesco Montorsi <f18...@ya...> wrote:
> is it ok then to make wxLua 2.8.0.0 release saturday morning ?
>
> For doing releases I think it's better IM than emails (to solve any
> eventual problem coming out at the last moments - they never are
> missing); so:
>
>   - if you want to contact me through IM you can use my email address
> for Yahoo messenger or fr...@ho... with MSN messenger.
>
>   - I'll also be available through #IRC at wxWidgets chat room.

I haven't used IM in years and I hate to say it, don't even know how
to go about using it. I'll also be away on saturday for the holidays,
but I should be around sunday for a bit.

I will check these in an hour.
VS 2005 dsw using debug lib/dll
VC 2003 makefile.vc release lib/dll

I think the C++ code is ok, there's a few things on my todo list, but
nothing that should get done before the release.

Thanks,
     John Labenski



>
> Francesco Montorsi ha scritto:
> > Hi all,
> >     is it if we try to make wxLua 2.8.0.0 release before 25 december?
> > It would be a nice Christmas gift for some of my friends which asked me
> > a nice interpreted language for GUI apps ;)
> >
> > Francesco
> >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Re: [wxlua-users] lua.h not found

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

klaas.holwerda ha scritto:
> Hi,
> 
> Can't compile on linux. The lua.h is not found, very likely missing an 
> include path now.
> This is from wxlstate.h
are you sure you reran configure script and you're using the very latest 
CVS?

When I compile with the built-in lua configure adds an include flag like:

-I/home/frm/work/wxLua/./modules/lua/include

Also, what does the configure says after this line:

checking if Lua 5.1 is installed...

It should say "not found, falling back to the built-in lua".


Francesco

Re: [wxlua-users] wxLua 2.8.0.0 release date

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

is it ok then to make wxLua 2.8.0.0 release saturday morning ?

For doing releases I think it's better IM than emails (to solve any 
eventual problem coming out at the last moments - they never are 
missing); so:

  - if you want to contact me through IM you can use my email address 
for Yahoo messenger or fr...@ho... with MSN messenger.

  - I'll also be available through #IRC at wxWidgets chat room.

Francesco


Francesco Montorsi ha scritto:
> Hi all,
>     is it if we try to make wxLua 2.8.0.0 release before 25 december?
> It would be a nice Christmas gift for some of my friends which asked me 
> a nice interpreted language for GUI apps ;)
> 
> Francesco
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [wxlua-users] stc not fond anymore

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

klaas.holwerda ha scritto:
> Hi,
> 
> stc library is not located anymore, because -llua5.1 is not on my system.
> It should not be required at this stage.
> It looks like Francesco had lua installed on his system, i don't.
right - sorry. Fixed.

Francesco

[wxlua-users] stc not fond anymore

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

Hi,

stc library is not located anymore, because -llua5.1 is not on my system.
It should not be required at this stage.
It looks like Francesco had lua installed on his system, i don't.

Klaas

configure:6931: result: no
configure:6980: checking if wxSTC contrib is available
configure:7005: g++ -o conftest  -g3 -O0 -Wall -Wundef 
-Wno-ctor-dtor-privacy  
-I/usr/local/lib/wx/include/gtk2-ansi-debug-static-2.8 
-I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES 
-D__WXDEBUG__ -D__WXGTK__  conftest.cpp  -llua5.1 -L/usr/local/lib 
-pthread   /usr/local/lib/libwx_gtk2d_stc-2.8.a 
/usr/local/lib/libwx_gtk2d_xrc-2.8.a 
/usr/local/lib/libwx_gtk2d_html-2.8.a 
/usr/local/lib/libwx_gtk2d_adv-2.8.a 
/usr/local/lib/libwx_based_net-2.8.a 
/usr/local/lib/libwx_based_xml-2.8.a 
/usr/local/lib/libwx_gtk2d_core-2.8.a /usr/local/lib/libwx_based-2.8.a 
-lexpat -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 
-lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 
-lXinerama -lXxf86vm -lSM -lpng -ljpeg -ltiff -lz -ldl -lm  >&5
/usr/bin/ld: cannot find -llua5.1
collect2: ld returned 1 exit status
configure:7011: $? = 1
configure: failed program was:

[wxlua-users] lua.h not found

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

Hi,

Can't compile on linux. The lua.h is not found, very likely missing an 
include path now.
This is from wxlstate.h

Klaas

Re: [wxlua-users] wxLua newlogo (was Re: wxLua 2.8.0.0 release date)

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

I like the logo with the "shiny" wxWidgets blocks in the center with
the blue lua circling it that's on the website now.

It could be a little cleaner, there's a little blur on the Lua circle
and dashed circle that you can only see when you blow it up pretty
big, and it uses a lot of colors so it's not suited to be converted
into an xpm, but I'm not complaining.

-John Labenski

Re: [wxlua-users] wxLua 2.8.0.0 release date

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

On 12/20/06, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:
> >
> > Ok, another problem, using VC 2005 and batch build it's puts Debug DLL
> > Multilib lua5.1.dll into lib/vc_lib not lib/vc_dll.
> I should have already solved 2-3 hours ago.... it was a typo in lua_dll
> template.

Works now, thanks.

> > ==============================
> >
> > Ahh... what about this? After a build you copy the bin/[build]/*.exe
> > to just bin/*.exe and overwrite them. The originals still would exist
> > in the build dir. Is this easy to do or even make sense or would it be
> > too confusing?
> well, I don't know... it's easy to do but maybe unexpect by the user...
>
> Why would we want it? So that the DLL can be copied to just "bin" and
> not "bin\vc*" ?

So that you can run genwxbind.lua easily. It's probably not important,
never mind.

-John Labenski

Re: [wxlua-users] wxLua 2.8.0.0 release date

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

John Labenski ha scritto:
> On 12/19/06, Francesco Montorsi <f18...@ya...> wrote:
>>> If you just copy wxlua_mswXXX_lua.lib to lua5.1.lib the luamodue works.
>> I was aware - it should be fixed now as our lua library is now named
>> lua5.1 and creates an interpreter called exactly "lua".
>>
>> This is more coherent I think from the previous situation where the lua
>> libraries are called lua5.1 (because the lua module _must_ be linked
>> against a DSO called exactly lua5.1) but then the interpreter were
>> called "wxlua-lua".
> 
> Ok, another problem, using VC 2005 and batch build it's puts Debug DLL
> Multilib lua5.1.dll into lib/vc_lib not lib/vc_dll. 
I should have already solved 2-3 hours ago.... it was a typo in lua_dll 
template.


>>> I had to copy all of the dlls from
>>> wxWidgets/lib/vc_dll/*.dll and the sample/luamodule.wx.lua into the
>>> dir that I ran $wxlua-lua.exe from.
>> I know. that's why I created copy-dlls.bat but now that we use different
>> dirs for different builds also for bin\*.exe that script is not so useful...
> 
> Heh, I added some really ugly batch file code to genwxbind.bat to get
> it to work for a few cases.
good


> ==============================
> 
> Ahh... what about this? After a build you copy the bin/[build]/*.exe
> to just bin/*.exe and overwrite them. The originals still would exist
> in the build dir. Is this easy to do or even make sense or would it be
> too confusing?
well, I don't know... it's easy to do but maybe unexpect by the user...

Why would we want it? So that the DLL can be copied to just "bin" and 
not "bin\vc*" ?

Francesco

Re: [wxlua-users] lua or wxlua-lua.exe

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

On 12/20/06, Francesco Montorsi <f18...@ya...> wrote:
> klaas.holwerda ha scritto:
> > Hi,
> >
> > I read lua5.1.lib was needed. So this exe renaming is not a mistake??
> > I keep changing pack and forth, i don't know any what is right :-(
> > Will it hopefully be  the same naming on Unix?
> very sorry about that.
>
> "lua" is now the definitive name (unless others find problems with it)
> of the lua interpreter which gets built together with wxLua.
>
> In this way, if the user does not have Lua installed and he compiles and
> installs wxLua, he end up with an "official" (i.e installed in the
> standard paths and with standard naming) lua + wxLua.
> In fact lua libraries are now called lua5.1 and are installed in
> $LIBDIR. Exactly like lua packages would do.

Sounds good to me.

John Labenski

Re: [wxlua-users] wxLua 2.8.0.0 release date

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

On 12/19/06, Francesco Montorsi <f18...@ya...> wrote:
> > If you just copy wxlua_mswXXX_lua.lib to lua5.1.lib the luamodue works.
> I was aware - it should be fixed now as our lua library is now named
> lua5.1 and creates an interpreter called exactly "lua".
>
> This is more coherent I think from the previous situation where the lua
> libraries are called lua5.1 (because the lua module _must_ be linked
> against a DSO called exactly lua5.1) but then the interpreter were
> called "wxlua-lua".

Ok, another problem, using VC 2005 and batch build it's puts Debug DLL
Multilib lua5.1.dll into lib/vc_lib not lib/vc_dll. See
modules/build/msw/modules_mod_lua.dsp

!ELSEIF  "$(CFG)" == "mod_lua - Win32 DLL Debug Multilib"
...
# ADD LINK32 /nologo /dll /machine:i386
/out:"..\..\..\lib\vc_lib\lua5.1.dll"
/implib:"..\..\..\lib\vc_lib\lua5.1.lib"

> Now installing wxLua you get installed also a vanilla lua5.1 using all
> standard names. And since it's now available a USE_SYSTEM_LUA option to
> disable the built-in lua, I think this is the best we can do.

Great.

> > By the way, is there a way to combine all of wxWidgets and wxLua into
> > the wx.dll?
> no easy ways I'm aware of. To get a single DLL with all wxWidgets and
> wxLua we'd need a giant library which contains all wx sources and wx lua
> sources.
>
> IIRC there was a system, maybe with borland, to merge different DLLs
> into a single one. I'll have a look at it.

I found a program that sounded like it might work by googling, but it
had a commercial license, I forget what it was.

> Anyway I don't think it's a problem but rather a (small) advantage:
> instead of a single huge DLL we have a smaller set of DLLs and with a
> bit of luck, when we run a wxLua app, some of them may be already loaded
> in the RAM by other processes, thus allowing for the OS to avoid to load
> all the DLLs from hard disk.

Fair enough.

> > I had to copy all of the dlls from
> > wxWidgets/lib/vc_dll/*.dll and the sample/luamodule.wx.lua into the
> > dir that I ran $wxlua-lua.exe from.
> I know. that's why I created copy-dlls.bat but now that we use different
> dirs for different builds also for bin\*.exe that script is not so useful...

Heh, I added some really ugly batch file code to genwxbind.bat to get
it to work for a few cases.

==============================

Ahh... what about this? After a build you copy the bin/[build]/*.exe
to just bin/*.exe and overwrite them. The originals still would exist
in the build dir. Is this easy to do or even make sense or would it be
too confusing?

Regards,
    John Labenski