# Location of a package

128 messages
1234 ... 7
Open this post in threaded view
|

## Location of a package

 Hi everyone. Is it possible for a module to know where it is placed when being required? I mean, if I have several places specified in my package.path, I'd like the module to be aware of where it was picked up from. That's because I want my module to be able to construct full pathnames pointing to files in subdirectories.  If the answer is 'no', or 'no unless you patch Lua', then do you have any suggestions on how to deal with "resource files"? If my module is at c:\foo\bar\myModule.lua, I need to load files from c:\foo\bar\resource.txt or c:\foo\bar\blah.jpg, and the only path I'd like to configure is the one I set in package.path, so I can't hard-code the paths in myModule.lua  Also, I can't rely on parsing the package.path, since I might remove the path I used to require my module.  Regards, Ignacio Burgueño 
Open this post in threaded view
|

## Re: Location of a package

  On Feb 18, 2008, at 9:21 PM, Ignacio Burgueño wrote: Is it possible for a module to know where it is placed when being required  Hmmm... well... kind of... you can try debug.getinfo( aFunction, 'S' )... 'aFunction' being a, hmmm, function in the package you are trying to locate...  
Open this post in threaded view
|

## Re: Location of a package

 In reply to this post by Ignacio Burgueño  Hi Ignacio > I'd like the module to be aware of where it was picked up from. That's > because I want my module to be able to construct full pathnames pointing > to files in subdirectories. Why don't you use relative pathnames? > If the answer is 'no', or 'no unless you patch Lua', then do you have > any suggestions on how to deal with "resource files"? > If my module is at c:\foo\bar\myModule.lua, I need to load files from > c:\foo\bar\resource.txt or c:\foo\bar\blah.jpg, and the only path I'd > like to configure is the one I set in package.path, so I can't hard-code > the paths in myModule.lua Why don't you put everything in a proper directory?: c:\foo\bar\myModule\init.lua \resource.txt \blah.jpg Regards, Tomás 
Open this post in threaded view
|

## Re: Location of a package

 In reply to this post by Petite Abeille-2-2 Petite Abeille wrote:  On Feb 18, 2008, at 9:21 PM, Ignacio Burgueño wrote: Hmmm... well... kind of... you can try debug.getinfo( aFunction, 'S' )... 'aFunction' being a, hmmm, function in the package you are trying to locate...   Thanks, I'll save that as a last resource, since it's possible that I don't have access to the debug library.  
Open this post in threaded view
|

## Re: Location of a package

  On Feb 18, 2008, at 9:39 PM, Ignacio Burgueño wrote: Thanks, I'll save that as a last resource, since it's possible that I don't have access to the debug library.  Hmmm... well... then... you can always wrap require() with your own function and perhaps set the module path there...  
Open this post in threaded view
|

## Re: Location of a package

 Yeah, this is what the WSAPI launchers do with Orbit apps (along with isolating each application in its own Lua state, but reusing the state between different requests). -- Fabio Mascarenhas On Feb 18, 2008 5:07 PM, Petite Abeille <[hidden email]> wrote: > > On Feb 18, 2008, at 9:39 PM, Ignacio Burgueño wrote: > > > Thanks, I'll save that as a last resource, since it's possible that > > I don't have access to the debug library. > > Hmmm... well... then... you can always wrap require() with your own > function and perhaps set the module path there... > > 
Open this post in threaded view
|

## Re: Location of a package

 In reply to this post by Tomás Guisasola-2 Tomas Guisasola Gorham wrote:  Hi Ignacio I'd like the module to be aware of where it was picked up from. That's because I want my module to be able to construct full pathnames pointing to files in subdirectories.  Why don't you use relative pathnames?  I can't. That's exactly what I'm trying to avoid. Maybe some info about what I'm trying to do is needed.  I'm doing some web stuff based upon Xavante, CgiLua and Orbit. From Xavante, I stripped the Copas' based server and replaced it with a multithreaded one written in C. I have a pool of luaStates, so when serving a request, I pick a state and pass control to it. From that point on, it behaves like Xavante, parsing the request, picking the right handler, etc.  I need to move away from relative paths because I can have two scripts running at the same time, each of them in different physical directories. I had to tweak CGILua to avoid changing directories and running each script with a full path.  This is working fine, I just prepend cgilua.script_pdir to the file I want to run. My problem is with Orbit. It relies on the process' current directory being the one in which the "orbit-enabled" app is located.  I'd like to avoid PA's suggestion about using debug.getinfo, since I might need to remove it, to disallow scripts fiddling with it. And I also would like to decrease the amount of 'path configuration' needed. I just want to say where a module is to be required, then I want the module itself to figure where are its resources.  Regards, Ignacio Burgueño 
Open this post in threaded view
|

## Re: Location of a package

 It's unfortunate that the package finder function isn't exposed in Lua by the native package lib. I hope it will be done in Lua 5.2.Metalua needs it, and reimplements it. Look at function package.findfile() in http://repo.or.cz/w/metalua.git?a=blob_plain;f=src/lib/package2.lua, and give it your package's name as first arg,package.cpath or package.path as a second arg, depending on whether your module is in C or in Lua. Don't forget to close the file handle if you don't use it.-- Fabien.
Open this post in threaded view
|

## Re: Location of a package

 > It's unfortunate that the package finder function isn't exposed in Lua by > the native package lib. I hope it will be done > in Lua 5.2. > > Metalua needs it, and reimplements it. Look at function package.findfile()in > http://repo.or.cz/w/metalua.git?a=blob_plain;f=src/lib/package2.lua, and > give it your package's name as first arg, > package.cpath or package.path as a second arg, depending on whether your > module is in C or in Lua. Don't > forget to close the file handle if you don't use it. Lua 5.2 will include a package.searchpath function. It is similar to this package.findfile, but it returns only the file name (not the file handler). -- Roberto 
Open this post in threaded view
|

## Re: Location of a package

 Speaking of which: is there a better way to check whether a package is available other than using require() and catching errors with pcall()? - yuri On Mon, Feb 18, 2008 at 12:19 PM, Roberto Ierusalimschy <[hidden email]> wrote: > Lua 5.2 will include a package.searchpath function. It is similar > to this package.findfile, but it returns only the file name (not the > file handler). > > -- Roberto > 
Open this post in threaded view
|

## Re: Location of a package

 In reply to this post by Roberto Ierusalimschy >>>>> "RI" == Roberto Ierusalimschy <[hidden email]> writes: >> It's unfortunate that the package finder function isn't exposed in Lua by >> the native package lib. I hope it will be done >> in Lua 5.2. >> >> Metalua needs it, and reimplements it. Look at function package.findfile()in >> http://repo.or.cz/w/metalua.git?a=blob_plain;f=src/lib/package2.lua, and >> give it your package's name as first arg, >> package.cpath or package.path as a second arg, depending on whether your >> module is in C or in Lua. Don't >> forget to close the file handle if you don't use it. RI> Lua 5.2 will include a package.searchpath function. It is similar RI> to this package.findfile, but it returns only the file name (not the RI> file handler). Roberto, is there any description of upcoming changes in Lua 5.2? -- Yours sincerely, Eugeny. Doctor Web, Ltd. http://www.drweb.com +79119997425 
Open this post in threaded view
|

## Re: Location of a package

 In reply to this post by Yuri Takhteyev  On Feb 18, 2008, at 9:37 PM, Yuri Takhteyev wrote: Speaking of which: is there a better way to check whether a package is available other than using require() and catching errors with pcall()?  E.g.: local ok, zlib = pcall( require, 'zlib' ) What's wrong with it? 
Open this post in threaded view
|

## Re: Location of a package

 In reply to this post by Fabio Mascarenhas Fabio Mascarenhas wrote: Yeah, this is what the WSAPI launchers do with Orbit apps (along with isolating each application in its own Lua state, but reusing the state between different requests).  Could you point me to some sample code? I'm looking at both wsapi and orbit's source and I can't find where you do that.  I mean, if I have two apps which serve static content, both placed in different directories, how does Orbit handle that? orbit.serve_static will fail unless given a full pathname.  Regards, Ignacio Burgueño 
Open this post in threaded view
|

## Re: Location of a package

 Start from src/launcher/wsapi.fcgi in the WSAPI CVS and follow the function calls to src/wsapi/common.lua. And orbit.serve_static has to work with relative paths (looking in the cwd, of course), what problems are you having? -- Fabio Mascarenhas On Feb 18, 2008 6:34 PM, Ignacio Burgueño <[hidden email]> wrote: > Fabio Mascarenhas wrote: > Could you point me to some sample code? I'm looking at both wsapi and > orbit's source and I can't find where you do that. > > I mean, if I have two apps which serve static content, both placed in > different directories, how does Orbit handle that? orbit.serve_static > will fail unless given a full pathname. > > Regards, > Ignacio Burgueño > > > 
Open this post in threaded view
|

## Re: Location of a package

 Fabio Mascarenhas wrote: Start from src/launcher/wsapi.fcgi in the WSAPI CVS and follow the function calls to src/wsapi/common.lua. And orbit.serve_static has to work with relative paths (looking in the cwd, of course), what problems are you having?  I've described my problem in a response to Tomás Guisasola. I'll copy+paste it here in case the message didn't get through.  Tomas Guisasola Gorham wrote: > Hi Ignacio > >> I'd like the module to be aware of where it was picked up from. That's because I want my module to be able to construct full pathnames pointing to files in subdirectories. > Why don't you use relative pathnames? I can't. That's exactly what I'm trying to avoid. Maybe some info about what I'm trying to do is needed.  I'm doing some web stuff based upon Xavante, CgiLua and Orbit. From Xavante, I stripped the Copas' based server and replaced it with a multithreaded one written in C. I have a pool of luaStates, so when serving a request, I pick a state and pass control to it. From that point on, it behaves like Xavante, parsing the request, picking the right handler, etc.  I need to move away from relative paths because I can have two scripts running at the same time, each of them in different physical directories. I had to tweak CGILua to avoid changing directories and running each script with a full path.  This is working fine, I just prepend cgilua.script_pdir to the file I want to run. My problem is with Orbit. It relies on the process' current directory being the one in which the "orbit-enabled" app is located.  I'd like to avoid PA's suggestion about using debug.getinfo, since I might need to remove it, to disallow scripts fiddling with it. And I also would like to decrease the amount of 'path configuration' needed. I just want to say where a module is to be required, then I want the module itself to figure where are its resources.  Regards, Ignacio Burgueño 
Open this post in threaded view
|

## Re: Location of a package

 In reply to this post by Roberto Ierusalimschy Roberto Ierusalimschy wrote: ...  Lua 5.2 will include a package.searchpath function. It is similar to this package.findfile, but it returns only the file name (not the file handler).  I recall a discussion about splitting the 'require' logic in two parts. I don't remember if it was on the Kepler dev's list or here. Anyway, it was about decoupling the process of finding a module from the actual loading of the module. Surely someone who took part in that discussion will be reading this.  Will issues like this be addressed in Lua 5.2 ? Regards, Ignacio Burgueño 
Open this post in threaded view
|

## Re: Location of a package

 In reply to this post by Fabien-3 Fabien wrote: It's unfortunate that the package finder function isn't exposed in Lua by the native package lib. I hope it will be done in Lua 5.2. Metalua needs it, and reimplements it. Look at function package.findfile() in http://repo.or.cz/w/metalua.git?a=blob_plain;f=src/lib/package2.lua, and  Thanks Fabien, I'll take a look at it. 
Open this post in threaded view
|

## upcoming changes in Lua 5.2 [was Re: Location of a package]

 In reply to this post by eugeny gladkih > Roberto, is there any description of upcoming changes in Lua 5.2? There is no "official" roadmap :) The following is a list of what we have been doing. We have already implemented several small changes: - emergency garbage collector (core forces a GC when allocation fails) - ephemeron tables (tables with weak keys only visit value when key is accessible) - handling of non-string error messages (somewhat along the lines of John Belmonte's suggestion) - new function package.searchpath - "metamethods" __pairs & __ipairs - tables and strings respect __len metamethod - udata with finalizers are kept in a separated list for the GC - arguments for function called through xpcall We are also considering the following changes: - string.pack/string.unpack (along the lines of struct/lpack) - Mike Pall's implementation for yield (using longjmp), allowing yields in several places not allowed currently (inside pcall, metamethods, etc.) - some form of bit operations. (We are not very happy with any known implementation. Maybe just incorporate bitlib?) - there is already a new function luaL_tolstring (along the lines of the 'tostring' function). Maybe we should define a lua_rawtostring (no coercions from numbers) and then use luaL_tolstring ("full" coercion from other types) when we want to allow coercions. The point is where to use one and where to use the other. (The current lua_tostring behavior would be deprecated in the future...) -- Roberto 
Open this post in threaded view
|

## Re: Location of a package

 In reply to this post by Ignacio Burgueño >> Lua 5.2 will include a package.searchpath function. It is similar >> to this package.findfile, but it returns only the file name (not the >> file handler). > > > I recall a discussion about splitting the 'require' logic in two parts. I > don't remember if it was on the Kepler dev's list or here. Anyway, it was > about decoupling the process of finding a module from the actual loading of > the module. Surely someone who took part in that discussion will be reading > this. > > Will issues like this be addressed in Lua 5.2 ? 'require' already decouples its process of finding a module, using loaders. This new function package.searchpath will easy the task of writing new loaders. (E.g., both the C loader and the Lua loader are just calls to searchpath.) -- Roberto 
 In reply to this post by Roberto Ierusalimschy Roberto Ierusalimschy wrote: Roberto, is there any description of upcoming changes in Lua 5.2?  There is no "official" roadmap :) The following is a list of what we have been doing.  will lpeg end up in the core? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------