(c) loading and using shared libraries like LuaSocket This will come almost automatically via the new module mechanism. However, if we want it to work with precompiled modules from LuaBinaries then there is more work to do. Basically, for compatibility with LuaBinaries, the Lua runtime needs to be available through a shared library named "lua5.1.dll".
Neil, I know you preferred not to have another external dependency. Is it worth moving the Lua core out to a DLL? We can keep it as an "internal dependency" by compiling it from the SciTE source tree and distributing it with the product, like we do with SciLexer.dll. Regards, Bruce "Kein-Hong Man" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi all, > > Bruce Dodson wrote: >> I did a bit of work last night on updating SciTE to use >> Lua 5.1.1. I will be looking for testers for this, >> pretty soon. > > I am interested. Some of the Lua exporter scripts I ported > from C/C++ can do with the % operator... > >> [snip] >> While I'm at it does anyone have feedback or preferred >> behavior with regard to how packages / modules are >> handled when you switch buffers? And more generally, how >> do people feel about the way global variables are managed >> currently? Are there any issues that you have had to >> work around? If so, this might be a good time to bring >> those forward so we can tighten up the interface. > > I don't have any problems with globals currently. I have > been tending to do the following: > (a) large scripts are always in their own files > (b) only functions called by hotkey etc. are exposed as > globals > (c) configuration to use the property system > (d) everything else, all non-initialization code, are > locals > (e) buffer object is fine for per-buffer state and data > (f) use extman to manage event functions > (extman's userlist code should be updated to support > multiple userlists, though) > > So global namespace pollution doesn't seem to be a problem > right now, at least for me. If I use only standard or > popular packages, I don't think I have a real need for > multiple package namespaces. Of course, this is only one > data point, so I too am interested in what others are > facing. > > The inclusion of MenuCommand was lovely. Haven't used it > yet, though. So, still in my wishlist are roughly: > (a) a way to operate on all buffers for operations that > need it > (b) a general pipe system for executing external progs > (c) loading and using shared libraries like LuaSocket > > -- > Cheers, > Kein-Hong Man (esq.) > Kuala Lumpur, Malaysia _______________________________________________ Scite-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scite-interest
