wxlua-users — wxLua list for users and developers

[Wxlua-users] Re: wxLua updated to lua 5.1, please test, NOTES for programmers

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

Hi,

John Labenski ha scritto:
> I came across what seemed to be a bug in the garbage collector in
> 5.0.2. In the printing sample  "virtual" functions are set for the
> wxLuaPrintout which get called instead of the c++ functions. However
> in the print preview if you changed the size of the preview a few
> times the functions you set (even if global, not local) would get
> garbage collected.
weird...

> Anyway, this prompted to me try 5.1 and so far the results are very
> good, this bug was fixed and it's MUCH FASTER! (yes using capitals is
> appropriate, it's pretty impressive)
very good news !


> It compiles and runs using the "Makefiles" in the src dir of the
> apps/XXX dirs. All the samples have been updated, but not thoroughly
> tested.
I've updated bakefiles but now, when I try to run wxluaedit I get a 
segmentation fault... (this with wx2.6.3 and with an up2date 
wxStedit...); other apps and samples I've tried work fine.


> -------------------------
> 
> Some notes on the changes for 5.1 that I've come across, there's more...
> 
> 1) lua 5.1 does not have an "include" dir so I faked it by copying the
> pertinent headers that we use into it.
if you want to keep the header files in lua/src/ folder it's fine for me 
as it's not a problem for bakefiles ;)


> 2) All the sources are in lua/src, even the lua and luac programs.
> Please see modules/luaINSTALL for the list of files for each.
> (Francesco, could you update the bakefiles? I don't think your *.c
> trick will work anymore)
I've updated the bakefiles using the list of source files provided in 
lua/INSTALL...

Francesco


> 3) DO NOT CALL luaopen_XXX (eg luaopen_io for the io.XXX table). IT
> WILL CRASH after some invalid reads. You have to open the libs a
> little differently, I'm just using the function "luaL_openlibs" in
> lua/src/linit.c which loads them all, but shows you how to do it
> individually.
> 
> 4) "for k, v in sometable do" is now "for k, v in pairs(sometable) do"
> 
> 5) table.getn and table.setn are gone, use the #sometable to get the
> count of the consecutive integer indexes in a table.
> 
> 6) math.mod -> math.fmod and string.gfind -> string.gmatch
> 
> etc, see bottom of
> http://www.lua.org/manual/5.1/manual.html
> 
> Regards,
>     John Labenski
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642

[Wxlua-users] wxLua updated to lua 5.1, please test, NOTES for programmers

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

I came across what seemed to be a bug in the garbage collector in
5.0.2. In the printing sample  "virtual" functions are set for the
wxLuaPrintout which get called instead of the c++ functions. However
in the print preview if you changed the size of the preview a few
times the functions you set (even if global, not local) would get
garbage collected.

Anyway, this prompted to me try 5.1 and so far the results are very
good, this bug was fixed and it's MUCH FASTER! (yes using capitals is
appropriate, it's pretty impressive)

It compiles and runs using the "Makefiles" in the src dir of the
apps/XXX dirs. All the samples have been updated, but not thoroughly
tested.

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

Some notes on the changes for 5.1 that I've come across, there's more...

1) lua 5.1 does not have an "include" dir so I faked it by copying the
pertinent headers that we use into it.

2) All the sources are in lua/src, even the lua and luac programs.
Please see modules/luaINSTALL for the list of files for each.
(Francesco, could you update the bakefiles? I don't think your *.c
trick will work anymore)

3) DO NOT CALL luaopen_XXX (eg luaopen_io for the io.XXX table). IT
WILL CRASH after some invalid reads. You have to open the libs a
little differently, I'm just using the function "luaL_openlibs" in
lua/src/linit.c which loads them all, but shows you how to do it
individually.

4) "for k, v in sometable do" is now "for k, v in pairs(sometable) do"

5) table.getn and table.setn are gone, use the #sometable to get the
count of the consecutive integer indexes in a table.

6) math.mod -> math.fmod and string.gfind -> string.gmatch

etc, see bottom of
http://www.lua.org/manual/5.1/manual.html

Regards,
    John Labenski

Re: [Wxlua-users] Re: Do we want a wxluaminimal to create standalone executables?

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

On 3/23/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
>
> John Labenski ha scritto:
> > This would be a minimal program with a wxApp:OnInit that creates a
> > wxLuaState and runs the string that you provide in minimallua.cpp
> > which you generate using bin2c.lua. The file that gets #included and
> > the name of the c-string would be hard coded, but bin2c.lua can
> > generate files and the c-string they contain with any name, so this is
> > easy enough for people.
> >
> > Big downside - I think that it can only handle a single lua file,
> > maybe people can concatenate their files together before running
> > bin2c.lua on it?
> or we could extend bin2.c to support multiple files writing multiple
>
> const size_t inputfile_len;
> const unsigned char inputfile[] =3D { 123, 232, ... , 0 };
> pieces...

Unfortunately won't work if people use dofile(...) or require() since
it'll still look for them on disk.


> > Out of the box the program would fail to compile since you have to
> > provide the lua program c-string in minimallua.cpp. In order to not
> > have cvs try to update things I think this would be the best route we
> > can take. Alternatively, we put in the minimal.wx.lua and just be
> > careful about not overwriting it if any of the developers use it with
> > their own programs.
> we can also add minimal.wx.lua to CVS and then also to .cvsignore so
> that our local copies won't be committed by error...

Good idea.

> > Any thoughts on this or does someone know how to append data to an exe
> > that can be accesed as const char* so
> > that a compiler wouldn't be needed?
> more or less like Klaas suggest, I think that this can be done simply
> copying the original EXE to a new file containing the verbatim EXE + lua
>   script(s) + payload header concatenated at the end. Then the program
> opens 'itself' (i.e. the EXE file on harddisk),  using wxFile::Seek it
> reads the last bytes of the EXE which are the payload header. This is of
> a fixed size and contains just some basic info like the size of the lua
> scripts, their name and their order in the EXE.
> With these info it's easy for the EXE to do a seek at (filesize -
> payload header size - lua script size) and read (lua script size) bytes
> in a char[] array....
>
> Something like this is done in autopackage using bash and it works very
> good ;)

Klaas sent me some things about that. I'll try it out this weekend. I
think I can write a simple little lua program to automate it. If I can
get this to work then back to the original plan.

-John

[Wxlua-users] Re: Do we want a wxluaminimal to create standalone executables?

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

Hi,

John Labenski ha scritto:
> This would be a minimal program with a wxApp:OnInit that creates a
> wxLuaState and runs the string that you provide in minimallua.cpp
> which you generate using bin2c.lua. The file that gets #included and
> the name of the c-string would be hard coded, but bin2c.lua can
> generate files and the c-string they contain with any name, so this is
> easy enough for people.
> 
> Big downside - I think that it can only handle a single lua file,
> maybe people can concatenate their files together before running
> bin2c.lua on it?
or we could extend bin2.c to support multiple files writing multiple

const size_t inputfile_len;
const unsigned char inputfile[] = { 123, 232, ... , 0 };

pieces...



> It would reside in
> apps/wxluaminimal/src
>     minimal.cpp - contains subclassed wxApp that runs
>     minimallua.cpp - user provides this file from bin2c.lua
>                            contains const char* minimallua = {lua program};
sure...


> Out of the box the program would fail to compile since you have to
> provide the lua program c-string in minimallua.cpp. In order to not
> have cvs try to update things I think this would be the best route we
> can take. Alternatively, we put in the minimal.wx.lua and just be
> careful about not overwriting it if any of the developers use it with
> their own programs.
we can also add minimal.wx.lua to CVS and then also to .cvsignore so 
that our local copies won't be committed by error...


> This is the best I think I can do to make it easy to create your own
> standalone wxLua executables. It's the closest to pythons freeze that
> I can do right now.
Very nice work!

> When I briefly looked at freeze I thought that it
> was a little beyond the scope of what I want to get involved in.
> Unfortunately the creator of their standalone wxLua programs would
> need a C++ compiler
Quickly looking at python freeze (http://wiki.python.org/moin/Freeze) I 
see that also python devs, need a C++ compiler to create a standalone ELF...

> and would have to compile wxLua as well, but
> thanks to Francesco that's pretty easy.
;)


> Any thoughts on this or does someone know how to append data to an exe
> that can be accesed as const char* so
> that a compiler wouldn't be needed?
more or less like Klaas suggest, I think that this can be done simply 
copying the original EXE to a new file containing the verbatim EXE + lua 
  script(s) + payload header concatenated at the end. Then the program 
opens 'itself' (i.e. the EXE file on harddisk),  using wxFile::Seek it 
reads the last bytes of the EXE which are the payload header. This is of 
a fixed size and contains just some basic info like the size of the lua 
scripts, their name and their order in the EXE.
With these info it's easy for the EXE to do a seek at (filesize - 
payload header size - lua script size) and read (lua script size) bytes 
in a char[] array....

Something like this is done in autopackage using bash and it works very 
good ;)


Francesco

Re: [Wxlua-users] Do we want a wxluaminimal to create standalone executables?

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

Hi,

I think it is good to have such an application.

John Labenski wrote:

>
>Any thoughts on this or does someone know how to append data to an exe
>that can be accesed                                                   
>                                                  as const char* so
>that a compiler wouldn't be needed?
>  
>
What i could find quickly, i did sent to you.
They idea is to add copy the executable + uniquestring + data  to a new 
exeplusdata.exe.
The new executable reads itself until the uniquestring, and from there 
read the data into the string wanted.
I think this brings the executable in memory +  a copy of the data part. 
This is not ideal, but if the data is not huge, i would not care.
So may it is possible to do it with an initialized string being the size 
of the data. In such a case the new executable generated, could directly 
access it.

regards,

Klaas

-- 
Unclassified

[Wxlua-users] Do we want a wxluaminimal to create standalone executables?

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

This would be a minimal program with a wxApp:OnInit that creates a
wxLuaState and runs the string that you provide in minimallua.cpp
which you generate using bin2c.lua. The file that gets #included and
the name of the c-string would be hard coded, but bin2c.lua can
generate files and the c-string they contain with any name, so this is
easy enough for people.

Big downside - I think that it can only handle a single lua file,
maybe people can concatenate their files together before running
bin2c.lua on it?

It would reside in
apps/wxluaminimal/src
    minimal.cpp - contains subclassed wxApp that runs
    minimallua.cpp - user provides this file from bin2c.lua
                           contains const char* minimallua =3D {lua program=
};

Out of the box the program would fail to compile since you have to
provide the lua program c-string in minimallua.cpp. In order to not
have cvs try to update things I think this would be the best route we
can take. Alternatively, we put in the minimal.wx.lua and just be
careful about not overwriting it if any of the developers use it with
their own programs.

This is the best I think I can do to make it easy to create your own
standalone wxLua executables. It's the closest to pythons freeze that
I can do right now. When I briefly looked at freeze I thought that it
was a little beyond the scope of what I want to get involved in.
Unfortunately the creator of their standalone wxLua programs would
need a C++ compiler and would have to compile wxLua as well, but
thanks to Francesco that's pretty easy.

Any thoughts on this or does someone know how to append data to an exe
that can be accesed                                                  =20
                                                                     =20
                                                                     =20
                                                                     =20
                                                                     =20
                                                                     =20
                                                                     =20
                                                   as const char* so
that a compiler wouldn't be needed?

Regards,
    John Labenski

Re: [Wxlua-users] Re: RPM spec for wxLua

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

>> Will try, once SourceForge's CVS feels happier...
> Did you manage to get CVS updated ?

No, and haven't contacted John yet either.
But I unpacked your snapshot to test with.

Busy week, so haven't been able to debug it.

--anders

[Wxlua-users] Re: RPM spec for wxLua

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

> Will try, once SourceForge's CVS feels happier...
Did you manage to get CVS updated ?

Francesco

[Wxlua-users] Re: wxLua as a 5.1 binary module

[thegeek <ok...@on...>]

> 
> On 3/13/06, thegeek <okrog@...> wrote:
> > So far I've been able to upgrade wxLua to lua 5.1, works great except for 
some
> > of the wxlua lua-code, which does ofcourse use table.getn and other 
deprecated
> > functions/syntaxes, but i tested with some of the samples(modified for lua 
5.1)
> > and it worked with no problem.
> > So I have all the wxlua libs compiled with lua 5.1 and just need to 
integrate
> > this into the lslua litestep plugin. This could prove to be a little beyond 
me,
> 
> There were no changes in the C code? That's good to know.

I did ofcourse have to add the newthread coroutine code back in, and a few 
functions changed name; load* and a few others. The garbage collection has also 
changed, and the dobuffer function too. However, the changes were all in all 
very minor.


> 
> > so I'll probably be looking forward to your next release.
> > Good luck:)
> 
> I've already updated some of the lua code to work with 5.1, it was
> suprisingly easy with this little function. :)
> 
> if table.getn == nil then
>     function table.getn(atable)
>         local count = 0
>         while atable[count+1] do
>             count = count + 1
>         end
>         return count
>     end
> end
> 

You'll also have to update all for statements, since they now need pair() or 
ipairs().

> I'll have to wait 'till next week to try the C code update.
> 
> Regards,
>     John Labenski
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> 

Re: [Wxlua-users] Re: wxLua as a 5.1 binary module

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

On 3/13/06, thegeek <ok...@on...> wrote:
> So far I've been able to upgrade wxLua to lua 5.1, works great except for=
 some
> of the wxlua lua-code, which does ofcourse use table.getn and other depre=
cated
> functions/syntaxes, but i tested with some of the samples(modified for lu=
a 5.1)
> and it worked with no problem.
> So I have all the wxlua libs compiled with lua 5.1 and just need to integ=
rate
> this into the lslua litestep plugin. This could prove to be a little beyo=
nd me,

There were no changes in the C code? That's good to know.

> so I'll probably be looking forward to your next release.
> Good luck:)

I've already updated some of the lua code to work with 5.1, it was
suprisingly easy with this little function. :)

if table.getn =3D=3D nil then
    function table.getn(atable)
        local count =3D 0
        while atable[count+1] do
            count =3D count + 1
        end
        return count
    end
end

I'll have to wait 'till next week to try the C code update.

Regards,
    John Labenski

[Wxlua-users] Re: wxLua as a 5.1 binary module

[thegeek <ok...@on...>]

So far I've been able to upgrade wxLua to lua 5.1, works great except for some 
of the wxlua lua-code, which does ofcourse use table.getn and other deprecated 
functions/syntaxes, but i tested with some of the samples(modified for lua 5.1) 
and it worked with no problem. 
So I have all the wxlua libs compiled with lua 5.1 and just need to integrate 
this into the lslua litestep plugin. This could prove to be a little beyond me, 
so I'll probably be looking forward to your next release.
Good luck:)

Re: [Wxlua-users] Re: RPM spec for wxLua

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

Francesco Montorsi wrote:

>> Should be straight-forward to convert
>> Version: into a "configurable" value,
>> and put it into build/rpm/wxlua.spec.in ?
> yes, sure; I'll do it.

And once it works, we can lose the "Mac-patch" part
that is currently included in the spec in 2 places:
	Patch: wxlua-2.6.2.0-wxmac.patch
	%patch -p0

>> Then you can build a SRPM, for the site.
> I don't know how useful an SRPM is: those wanting to compile wxLua 
> will probably use .tar.gz or .zip; does an SRPM gives some advantage 
> over them ?

Well, the .src.rpm file only contains just that:
1) the specfile (wxlua.spec)
2) the distfiles / tarball (wxlua-2.6.2.0.tar.gz)
3) any extra sources and patches (just one, here)
One can also do .nosrc.rpm, without the distfiles...

If the specfile and patches are already included
in the tarball, then you don't need a .src.rpm -
it would be more like a "different source format",
like providing both of TGZ and ZIP for instance ?

The main advantage (i.e. in theory) is that you can go:
"rpmbuild --rebuild *.src.rpm"
without having to configure and package it up yourself.
But it's not different from packaging for other systems ?

(like Portage or Ports or DarwinPorts or Fink, to name a few)

> right - that's weird; can you test if it's still necessary with latest 
> CVS: I did a small change and regenerated the bindings...

Will try, once SourceForge's CVS feels happier...

--anders

[Wxlua-users] Re: wxLua as a 5.1 binary module

[thegeek <ok...@on...>]

John Labenski <jlabenski@...> writes:

> 
> On 3/11/06, thegeek <okrog@...> wrote:
> > Hi, I've been using lua in combination with litestep ( an alternative
> > shell for litestep ), litestep has a lslua module that allows themers to
> > use lua for scripting themes. Lslua uses lua 5.1 and has full support
> > for the new binary module spec.
> 
> I'm not sure what litestep is, an xterm replacement? litestep.net?
> Their web page is broken for mozilla (in linux) and you cannot
> navigate to any of the tabs.
> 
> > Is it currently possible to load wxlua as a lua "module"?
> 
> No, see #3 below.
> 
> > If not, how hard would it be to make it possible, what problems are there?
> > I'm not much of a programmer, but I've been looking at the latest
> > release, and it seems very nice, it would however be great if users
> > could use the normal lua 5.1 release to load wxlua, without having to
> > recompile the parent application.
> 
> I agree that 5.1 "modules" should be something that wxLua should
> support. There are some issues however.
> 
> 1) wxLua currently uses 5.0.2 so we'd have to upgrade to 5.1.
> Unfortunately this means that we have to rewrite some of our lua code
> since table.getn has disappeared.
> 
> 2) In order to track coroutines we had to modify the lua source code.
> What has been added is a function that gets called when a coroutine
> creates a new lua_State. wxLua must be able to find the wxLua
> variables associated with the lua_State, these are the windows,
> events, data, etc. I'm not sure if there is another way to do this?
> Using a vanilla lua executable means that you cannot run coroutines,
> which may or may not be a problem for people.
> 
> 3) Additionally for the "module" support we'd have to make it so that
> the wxWidgets event loop gets initialized. This should be possible and
> I believe that it was done before, but again figuring it all out will
> take some effort. I have not looked into what it takes to setup a
> module so I cannot make any promises.
> 
> Hopefully for the next release we'll get to both of these things, but
> I cannot give any definite timelines for it.
> 
> You can always run wxLua itself on the command line and it should work
> fine. For example
> $wxLua myluaprogram.lua
> merely runs your program if it contains wxlua code or just straight
> lua code. You can even run compat5.1.lua to load modules as was
> previous discussed in the luasocket thread.
> 
> Regards,
>     John Labenski
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> 

First of all thank you for your quick and very informative reply.
I doubt I could help much with the development, but if you do implement module 
functionality it would be great:)

Regarding litestep:
Sorry, I meant to say "(litestep is a shell replacement for windows)", it's a 
quite old shell, but because of it's modular design it has survived(and is 
still beeing developed) There are lots of plugins that let you do almost 
anything conceiveable.
There are a few websites you can visit for more information; lsdev.org , ls-
universe.info and litestep.com
Keeping with the modular design it would be a shame if wxLua would have to be 
compiled into/with lslua.
The primary reason I would like wxlua in litestep is to give themers a better 
interface for any gui needs they have beyond the theme itself, such as "control 
panels" or even widgets such as a color picker.
wxLua in combination with litestep and xlabel(a plugin for litestep) would give 
a _lot_ of freedom in designing your very own ui.

:)

[Wxlua-users] Re: Why does wxLua install lua too ?

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

John Labenski ha scritto:
> We've also patched our lua so it should be installed if people want to
> compile their programs using the wxlua libs. Can we put the includes
> into
> 
> /usr/loca/include/wxlua/...
> 
> maybe it's non standard, but I definitely don't want to overwrite
> other people's things. (Thats why I never install tgz sources I
> compile into the system path).
currently the headers are installed into an 'include' subfolders of:

drwxr-xr-x  3 root root  72 2006-02-27 21:49 lua/
drwxr-xr-x  6 root root 144 2006-02-27 21:49 wxbind/
drwxr-xr-x  3 root root  72 2006-02-27 21:49 wxbindstc/
drwxr-xr-x  3 root root  72 2006-02-27 21:49 wxlua/
drwxr-xr-x  3 root root  72 2006-02-27 21:49 wxluadebug/
drwxr-xr-x  3 root root  72 2006-02-27 21:49 wxluasocket/

in $PREFIX so no header should be ever overwritten. Do you mean that's 
better to install all of them in folders like:

$PREFIX/include/wxlua/lua/include/*.h
$PREFIX/include/wxlua/wxbind/include/*.h
$PREFIX/include/wxlua/wxbindstc/include/*.h
$PREFIX/include/wxlua/wxlua/include/*.h
$PREFIX/include/wxlua/wxluadebug/include/*.h
etc...
?


> 
> About the lua executable, maybe it's best to rename it to wxlua-lua as
> Francesco suggested.
ok, done the change in bakefiles.

Francesco

[Wxlua-users] Re: RPM spec for wxLua

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

> Should be straight-forward to convert
> Version: into a "configurable" value,
> and put it into build/rpm/wxlua.spec.in ?
yes, sure; I'll do it.

> 
> Then you can build a SRPM, for the site.
I don't know how useful an SRPM is: those wanting to compile wxLua will 
probably use .tar.gz or .zip; does an SRPM gives some advantage over them ?


> Took quite some "trickery" to get it to
> package up the Mac resource forks properly,
> (in the "darwin" sections) but it works...
> 
> Tested on Fedora Core 4 and Mac OS X 10.3
> 
> Here is what it looks like on Mac OS X,
> after you've converted the RPM into a
> PKG/DMG image, with the "rpm2pkg" tool:
> 
> http://www.algonet.se/~afb/wx/wxlua-rpm2pkg.jpg
> (My "RPM for Darwin", installs under /usr/local
> See http://rpm4darwin.sourceforge.net for info)
nice


> PS. I had to patch the wxMac for it to compile, still...
> http://www.algonet.se/~afb/wx/wxlua-2.6.2.0-wxmac.patch
> (thought we did some kind of Mac workaround there ? Hmm)
right - that's weird; can you test if it's still necessary with latest 
CVS: I did a small change and regenerated the bindings...

Francesco

[Wxlua-users] Re: wxMac - packaging details

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

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>>> I don't actually think we'll even need an Installer PKG...
>> this gives me some other conceptual problem: Installer PKG was not 
>> mentioned in point 1) or 2)... I thought we were going to release a 
>> .dmg...
> 
> Normally you wrap a PKG inside a DMG, if you need to
> get permission or install in "invisible" directories
> (the Finder hides /usr/local and the rest from the user)
> 
> For wxLua, we're not really going to distribute the
> bin and lib and so on to the "end user", so we can
> let users wanting those use source or DarwinPorts/Fink ?
> 
> Thus, we won't require PKG in this project. Right you are.
ok

> 
> Making a DMG is pretty simple, just proprietary to Apple:
> hdiutil create -srcfolder wxLua -fs HFS+ -format UDZO -ov wxLua.dmg
> hdiutil internet-enable -yes -quiet wxLua.dmg
maybe these cmds should go into a script in build\macbundle ?


> 
>>> (better to do an RPM spec file in that case, and use RPM ?)
>> RPM is evil as it is distro- and version-distro- specific.
>> That's why I'm using autopackage for Linux binary package.
>> So I'd prefer to avoid it...
> 
> huh ?
> I was just talking about a .spec file, for building RPMS yourself ?
> You don't even have to distribute SRPMS, as one can use the tarball.
> 
> Nothing evil about that, I like RPM.
ah, ok; I strongly associate RPM with the idea of binaries, maybe 
because I've never used SRPM... ;)


> Binary RPMS, however: Oh dear... :-)
:)

Francesco

Re: [Wxlua-users] wxLua as a 5.1 binary module

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

On 3/11/06, thegeek <ok...@on...> wrote:
> Hi, I've been using lua in combination with litestep ( an alternative
> shell for litestep ), litestep has a lslua module that allows themers to
> use lua for scripting themes. Lslua uses lua 5.1 and has full support
> for the new binary module spec.

I'm not sure what litestep is, an xterm replacement? litestep.net?
Their web page is broken for mozilla (in linux) and you cannot
navigate to any of the tabs.

> Is it currently possible to load wxlua as a lua "module"?

No, see #3 below.

> If not, how hard would it be to make it possible, what problems are there=
?
> I'm not much of a programmer, but I've been looking at the latest
> release, and it seems very nice, it would however be great if users
> could use the normal lua 5.1 release to load wxlua, without having to
> recompile the parent application.

I agree that 5.1 "modules" should be something that wxLua should
support. There are some issues however.

1) wxLua currently uses 5.0.2 so we'd have to upgrade to 5.1.
Unfortunately this means that we have to rewrite some of our lua code
since table.getn has disappeared.

2) In order to track coroutines we had to modify the lua source code.
What has been added is a function that gets called when a coroutine
creates a new lua_State. wxLua must be able to find the wxLua
variables associated with the lua_State, these are the windows,
events, data, etc. I'm not sure if there is another way to do this?
Using a vanilla lua executable means that you cannot run coroutines,
which may or may not be a problem for people.

3) Additionally for the "module" support we'd have to make it so that
the wxWidgets event loop gets initialized. This should be possible and
I believe that it was done before, but again figuring it all out will
take some effort. I have not looked into what it takes to setup a
module so I cannot make any promises.

Hopefully for the next release we'll get to both of these things, but
I cannot give any definite timelines for it.

You can always run wxLua itself on the command line and it should work
fine. For example
$wxLua myluaprogram.lua
merely runs your program if it contains wxlua code or just straight
lua code. You can even run compat5.1.lua to load modules as was
previous discussed in the luasocket thread.

Regards,
    John Labenski

[Wxlua-users] wxLua as a 5.1 binary module

[thegeek <ok...@on...>]

Hi, I've been using lua in combination with litestep ( an alternative 
shell for litestep ), litestep has a lslua module that allows themers to 
use lua for scripting themes. Lslua uses lua 5.1 and has full support 
for the new binary module spec.
Is it currently possible to load wxlua as a lua "module"?
If not, how hard would it be to make it possible, what problems are there?
I'm not much of a programmer, but I've been looking at the latest 
release, and it seems very nice, it would however be great if users 
could use the normal lua 5.1 release to load wxlua, without having to 
recompile the parent application.

Thanks:)

[Wxlua-users] RPM spec for wxLua

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

As mentioned earlier, all that needs to be
done to support RPM building is to put a
spec file into a "build/rpm" directory...

Here is such a file, that I just wrote:
http://www.algonet.se/~afb/wx/wxlua.spec
(builds with: "rpmbuild -ba wxlua.spec")

Should be straight-forward to convert
Version: into a "configurable" value,
and put it into build/rpm/wxlua.spec.in ?

Then you can build a SRPM, for the site.


Took quite some "trickery" to get it to
package up the Mac resource forks properly,
(in the "darwin" sections) but it works...

Tested on Fedora Core 4 and Mac OS X 10.3

Here is what it looks like on Mac OS X,
after you've converted the RPM into a
PKG/DMG image, with the "rpm2pkg" tool:

http://www.algonet.se/~afb/wx/wxlua-rpm2pkg.jpg
(My "RPM for Darwin", installs under /usr/local
See http://rpm4darwin.sourceforge.net for info)

Note: this is *not* the usual wxLua installer!

--anders


PS. I had to patch the wxMac for it to compile, still...
http://www.algonet.se/~afb/wx/wxlua-2.6.2.0-wxmac.patch
(thought we did some kind of Mac workaround there ? Hmm)

Re: [Wxlua-users] Re: 2.6.2.0 packaged but...

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

  Francesco Montorsi:

> I've tried to link statically also expat but in the final ELF ldd 
> still shows expat.so.1 is needed.
> Probably because wxWidgets was not compiled using autopackage's gcc 
> wrapper, apgcc, which cuts down dependencies... I'm going to create an 
> autopackage for wxWidgets but it's going to take some days at least, 2 
> weeks at worst.

Doesn't that assume that wxWidgets was installed from an autopackage 
too ?
(I already had wxWidgets 2.6.3rc1, which was installed from a local 
RPM...)

--anders

Re: [Wxlua-users] Re: wxLua for wxMac

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

On 3/10/06, Anders F Bj=F6rklund <af...@al...> wrote:
> John Labenski wrote:
>
> >> Will recompile wxLua with full debugging symbols enabled tomorrow, I
> >> think.
> >
> > That would be great, sorry but I can't help without some more
> > information. I can't imagine what could fail in
> > wxLuaEditorApp::OnInit, but a line number would help!
>
> Here you go then:
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> 0x0000809c in wxLuaEditorApp::OnInit() (this=3D0x13210c0) at
> ../apps/wxluaedit/src/wxluaedit.cpp:195
> 195                 frame->GetEditor()->LoadFile( fileNames[0] );

That's weird? We check for there at least being one fileName.

line 190: if (fileNames.GetCount() > 0u)

could you print out (are you using gdb?) the value of  "fileNames.GetCount(=
)"?

Regards,
    John Labenski

[Wxlua-users] Re: 2.6.2.0 packaged but...

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

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>>    finally I've tagged the wxLua tree and created all binary and 
>> source packages, updated download page and created a news entry.
> 
> Just for fun, I tried downloading the .package file and installing it.
> (following the instructions linked to from the download package...)
> 
> The install went OK, it fetched the rest of autopackage OK and so on.
> A little scared of binary installers,this was just for experimenting.
thanks for testing!


> But when I ran the wxLuaEditor application from the menu, it just died.
> Running it again, from the shell, showed that libexpat.so.1 not found ?
> 
> I only have libexpat.so.0 on my Linux machine, running Fedora Core 4.
> libtiff.so.4 also seemed to be missing, when checking it with "ldd"...
> 
> 
> Can this be fixed, by linking those two libraries statically or so ?
libtiff should always be linked statically looking better in autopackage 
docs. I've fixed this.

I've tried to link statically also expat but in the final ELF ldd still 
shows expat.so.1 is needed.
Probably because wxWidgets was not compiled using autopackage's gcc 
wrapper, apgcc, which cuts down dependencies... I'm going to create an 
autopackage for wxWidgets but it's going to take some days at least, 2 
weeks at worst.

Francesco

Re: [Wxlua-users] Re: Why does wxLua install lua too ?

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

On 3/10/06, Anders F Bj=F6rklund <af...@al...> wrote:
> Francesco Montorsi wrote:
>
> >> You might want to do the same thing for the include dir, too... ?
> > the headers should not cause any conflict since they go in
> > $PREFIX/include/lua/include
> >
> > (note the double include string in path - required for wxLua moduling
> > system). IIRC correctly lua puts its headers in $PREFIX/include/lua,
> > right ?
>
> Almost, an example:
> /usr/local/include/lua.h
> /usr/local/include/luaconf.h
> /usr/local/include/lualib.h
> /usr/local/include/lauxlib.h
> /usr/local/include/lua.hpp
>
> > Ok, it's not that clear which headers belong to lua and which ones to
> > the lua shipped with wxLua... maybe we should change also these ?
>
> Just a thought...
>
> It's fine with me to not install the "vanilla" lua, but just the wxlua ?
> I've patched my Lua to support loading of Mac shared libraries,
> anyway...
>
> See http://www.algonet.se/~afb/lua/, using it to load "luaglut" for
> OpenGL

We've also patched our lua so it should be installed if people want to
compile their programs using the wxlua libs. Can we put the includes
into

/usr/loca/include/wxlua/...

maybe it's non standard, but I definitely don't want to overwrite
other people's things. (Thats why I never install tgz sources I
compile into the system path).

About the lua executable, maybe it's best to rename it to wxlua-lua as
Francesco suggested. You may not be able to use the system lua if it's
the wrong version. For example, we use 5.0.2 and 5.1 will really break
a lot of things for us (table.getn has been removed) so the binding
generator has to use "our" version of lua.

Regards,
    John Labenski

Re: [Wxlua-users] Re: Why does wxLua install lua too ?

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

Francesco Montorsi wrote:

>> You might want to do the same thing for the include dir, too... ?
> the headers should not cause any conflict since they go in 
> $PREFIX/include/lua/include
>
> (note the double include string in path - required for wxLua moduling 
> system). IIRC correctly lua puts its headers in $PREFIX/include/lua, 
> right ?

Almost, an example:
/usr/local/include/lua.h
/usr/local/include/luaconf.h
/usr/local/include/lualib.h
/usr/local/include/lauxlib.h
/usr/local/include/lua.hpp

> Ok, it's not that clear which headers belong to lua and which ones to 
> the lua shipped with wxLua... maybe we should change also these ?

Just a thought...

It's fine with me to not install the "vanilla" lua, but just the wxlua ?
I've patched my Lua to support loading of Mac shared libraries, 
anyway...

See http://www.algonet.se/~afb/lua/, using it to load "luaglut" for 
OpenGL

--anders

[Wxlua-users] Re: Why does wxLua install lua too ?

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

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>> well, wxLua embeds lua so I thought it was natural to install it.
> 
> It should probably be installed under another name, though ?
> 
> Otherwise it *will* cause conflicts.
> 
>> The lua library installed won't create any conflict since it's named 
>> something like:
>> libwxlua_gtk2_lua-2.6.a
>>
>> maybe we should adopt a custom name also for the lua exec ?
>> Maybe wxlua-lua ?
> 
> You might want to do the same thing for the include dir, too... ?
the headers should not cause any conflict since they go in 
$PREFIX/include/lua/include

(note the double include string in path - required for wxLua moduling 
system). IIRC correctly lua puts its headers in $PREFIX/include/lua, right ?

Ok, it's not that clear which headers belong to lua and which ones to 
the lua shipped with wxLua... maybe we should change also these ?

Francesco