On 1/2/11 5:12 PM, steve donovan wrote:
On Sun, Jan 2, 2011 at 5:55 PM, Henning Diedrich <firstname.lastname@example.org> wrote:# pcall/pathes * I almost abandoned LuaRocks in the first place for failing to grasp the ease of the require pcall tweak.You mean the require 'luarocks.require'? Otherwise I don't understand the need for pcall.
Yes, `pcall(require, "luarocks.require")`
The blame falls to the wrong people in any case, even when on those who
contribute modules but don't have opportunity to test exceedingly.
I thought LuaRocks could be a very pragmatic spot to centralize deploy tests for
many modules included. Can one contribute, by triggering some "test all" option
that makes it try to pull and install anything it can and registers and reports back
If there was, adding a line displayed at the end of every `luarocks install ...`
saying "Contribute now by doing luarocks test-all and send results to ..." could
be the right thing to garner support from users = beneficiaries.
whatever reasons (NOT for me not trying) I could not find it, could not even find the Rocks file itself, as it kept being pasted in tmp and then deleted.That used to irritate me, then I learned that the thing to do is 'luarocks unpack MOD' , which expands the rock locally, and then go to the directory and do 'luarocks make' to explicitly build it.
Which lay beyond my efforts of finding out obviously. I'd opt for a brief
hint to that option to be displayed if things fail. Failure, even for LuaRocks,
will just always happen so "less black box" would be a virtue, even if one
hopes it's never needed. Especially this compile flag problem is of course in
no way LuaRocks specific, it happens all the time with package/module
managers. I'd be grateful for a one-liner in the error message to start me
out, specifically on fixing flags any time. There will always be the next
chaos after shared and 32/64 bit have been settled.