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
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&bid1720ドル&dat1642
On 3/29/06, Francesco Montorsi <f18...@ya...> wrote: > > 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... Yeah, that's why I haven't gotten around to the minimal/freeze program. :( > > 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. Ok, I'll try to debug it, works ok in linux for me. > > 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 ;) What about installing? I guess it'd be ok too since lua doesn't use directories to nicely confine their headers anyway so it's just a matter of fully specifying the include path. #include "lua.h" instead of "lua/lua.h" > I've updated the bakefiles using the list of source files provided in > lua/INSTALL... Thanks alot! John Labenski
John Labenski ha scritto: > On 3/29/06, Francesco Montorsi <f18...@ya...> wrote: >>> 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... > > Yeah, that's why I haven't gotten around to the minimal/freeze program. :( > >>> 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. > > Ok, I'll try to debug it, works ok in linux for me. I forgot to say that 1) I'm in linux, too 2) I'm using release, unicode builds (I'm messing with autopackages once again ;)) I'll try soon with a debug build > >>> 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 ;) > > What about installing? I guess it'd be ok too since lua doesn't use > directories to nicely confine their headers anyway so it's just a > matter of fully specifying the include path. > > #include "lua.h" instead of "lua/lua.h" yes, exactly; changing the way headers are included there should be no problem at all... Francesco PS: I forgot to say that I removed the WXLUA_CODE symbol from compiler line as otherwise I get a redefinition error...
On 3/29/06, Francesco Montorsi <f18...@ya...> wrote: > >> 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. > > > > Ok, I'll try to debug it, works ok in linux for me. > I forgot to say that > 1) I'm in linux, too > 2) I'm using release, unicode builds (I'm messing with autopackages once > again ;)) > I'll try soon with a debug build If you still have problems see what gdb can say. I just retried it and gdb says it exists cleanly. I even tried valgrind and it didn't find any problems, though I can't say the same for gdk and glib, half a dozen invalid reads and hundreds of unfreed memory blocks, totaling 1Mb. :( Gdb does give me these about every 2 seconds though. I wonder who's creating the threads? I don't think lua is? Maybe it's just from the wxLuaEditor program which calls wxYield to fake running the wxLuaState as a thread (it runs in the main thread). [New Thread -1239192656 (LWP 16373)] [Thread -1239192656 (LWP 16373) exited] [New Thread -1239192656 (LWP 16376)] [Thread -1239192656 (LWP 16376) exited] > >>> 1) lua 5.1 does not have an "include" dir so I faked it by copying th= e > >>> 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 ;) > > > > What about installing? I guess it'd be ok too since lua doesn't use > > directories to nicely confine their headers anyway so it's just a > > matter of fully specifying the include path. > > > > #include "lua.h" instead of "lua/lua.h" > yes, exactly; changing the way headers are included there should be no > problem at all... Ok, then lets stick with having an "official" version of lua 5.1. Would you mind removing the modules/lua/include dir files and rebaking. I apologize about no doing it myself since I can't get a compiled version of your bakefile to generate identical build files to what you've got and until you get a chance I'd like to keep it working. :) > PS: I forgot to say that I removed the WXLUA_CODE symbol from compiler > line as otherwise I get a redefinition error... That was an mistake on my part, let's just leave it as is. This was for some code I added to lua's lstate.c file to allow you to have a function run whenever a coroutine is created and destroyed. By default nothing happens since the handler is NULL. Someone added this #ifdef and last night I was lazy and just put in #define WXLUA_CODE right in the lstate.c file. I think it's just as well to run the code since it checks for NULL so it's harmless and only gets run for coroutines. I'm not sure why they thought it was better to #ifdef it off? Thanks, John Labenski
> > >>> 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 fo= r me > > >> as it's not a problem for bakefiles ;) > > > > > > What about installing? I guess it'd be ok too since lua doesn't use > > > directories to nicely confine their headers anyway so it's just a > > > matter of fully specifying the include path. > > > > > > #include "lua.h" instead of "lua/lua.h" > > yes, exactly; changing the way headers are included there should be no > > problem at all... > > Ok, then lets stick with having an "official" version of lua 5.1. > Would you mind removing the modules/lua/include dir files and > rebaking. I apologize about no doing it myself since I can't get a > compiled version of your bakefile to generate identical build files to > what you've got and until you get a chance I'd like to keep it > working. :) Scrap that, we have this in our wxLua code so we only include "blah/wxLua/modules" #include "lua/include/lua.h" I think we should leave it like this since otherwise it'll be #include "lua/src/lua.h" This is what I was getting at about installing, but hadn't really thought it out clearly. Lets leave everything as is for the time being. -John Labenski
John Labenski ha scritto: >>>>>> 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 ;) >>>> What about installing? I guess it'd be ok too since lua doesn't use >>>> directories to nicely confine their headers anyway so it's just a >>>> matter of fully specifying the include path. >>>> >>>> #include "lua.h" instead of "lua/lua.h" >>> yes, exactly; changing the way headers are included there should be no >>> problem at all... >> Ok, then lets stick with having an "official" version of lua 5.1. >> Would you mind removing the modules/lua/include dir files and >> rebaking. I apologize about no doing it myself since I can't get a >> compiled version of your bakefile to generate identical build files to >> what you've got and until you get a chance I'd like to keep it >> working. :) sure, no problem at all to rebake: it just takes me few seconds ;) > Scrap that, we have this in our wxLua code so we only include > "blah/wxLua/modules" > #include "lua/include/lua.h" > > I think we should leave it like this since otherwise it'll be > #include "lua/src/lua.h" > > This is what I was getting at about installing, but hadn't really > thought it out clearly. Lets leave everything as is for the time > being. Ok, so then leave it as it is Francesco