On Fri, Sep 7, 2012 at 6:25 AM, Vespe Savikko <[email protected]> wrote: > Hi, > > Although this is an old issue, I could explain how I finally > got it resolved: I simply moved the LuaSocket dll (core.dll) > outside of LuaRocks after the installation. From then on, > the dll no longer interfered with the LR functionality.
Thank you for bringing it back to my attention. Regarding your comment in your original message: > So it seems that LR itself is not shielded from the modules it installs?! > At least not in my system. Yes, it's not shielded, and it was intentional, so that LR would not depend on third-party command-line tools when equivalent Lua modules are available. I especially wanted to have this behavior on Windows so we could add all the necessary modules to the Lua for Windows distro and ship LuaRocks without needing any extra "Unix-simulation" .exe's such as the ones we ship in the LuaRocks win32 .zip file. Unfortunately, reality seems to get in the way of good intentions: using extra modules from within LuaRocks causes problems on Windows, since one can't remove a rock that's in use because of the particular filesystem semantics of Windows. I'm thinking of disabling the use of native Lua modules inside LuaRocks altogether on Windows, to avoid that problem. That would mean that we would stay dependent on those extra .exe's -- I'd like to know what Windows users think of this situation; if it bothers you or if its basically transparent. An alternative would be for LuaRocks to keep its own copies of some modules [*]. It wouldn't be able to internally update them (or itself), however. In the long term, a semi-automated update scheme could be made possible with some kind of kludge (a wrapper luarocks.bat that executed "scheduled operations" after luarocks (the Lua program) finished executing?). [* that would bring some extra maintenance burden, so I'm not going for that unless users see a real need for this] Now, the particular bug you had shouldn't be related to the problem I just mentioned. I just took a look at both the LuaRocks and LuaSocket sources and I managed to reproduce it: an invalid value for the "proxy" variable broke LuaSocket (function adjustrequest in socket/http.lua validates the "host" variable but does not re-validate it after it was changed by adjustproxy). You probably forgot to add "http://"; at the beginning of your proxy URL. I just pushed a commit to LuaRocks adding a test to work around this issue. -- Hisham ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
