[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: To all Lua rock maintainers, take 2 (now with human-friendly reporting), you help is appreciated again
- From: Sean Conner <sean@...>
- Date: Sun, 13 Sep 2015 17:42:33 -0400
It was thus said that the Great Stefano once stated:
> Hi All,
> Based on the previous feedback, I implemented friendly html reporting for
> your convenience.
This is much nicer and way eaiser to understand.
> In general, there is not much you can do for the excluded cases.
> The failed ones (pass : no) are in general fixable, but sometimes
> cooperation among more than 1 maintainer might be needed (rocks contending
> the same module).
> As explained before, I am going to fix *some* of the contended module
> issues by myself where it makes sense (for instance: metalua-*).
I still don't understand how "org.conman.errno" contends with
"org.conman.env". Okay, I understand that you assume that both are part of
a module called "org" but that's incorrect. It's *NOT*. They are two
separate modules that happen to share a common prefix. I'm guessing that
had I named them org-conman-env and org-conman-errno then there would be be
no issue, right? But why, if they contain periods, are they suddenly one
module? Even Lua treats them as individual modules:
> require "org.conman.errno"
> require "org.conman.env"
> require "org.conman.table"
> require "org.conman.net"
> require "org.conman.syslog"
> require "org.conman.math"
> require "org.conman.signal"
org.conman.signal-posix table: 0x9579178
string table: 0x955b618
org.conman.table table: 0x956eff8
package table: 0x955ba50
_G table: 0x955a450
os table: 0x955d3c8
table table: 0x955b100
math table: 0x955df90
coroutine table: 0x955b718
org.conman.syslog table: 0x956f5e0
org.conman.env table: 0x9570ec0
io table: 0x955cbc0
org.conman.errno table: 0x956cd20
debug table: 0x955e990
org.conman.signal table: 0x9579178
org.conman.math table: 0x957c260
org.conman.net table: 0x95780e0
Yes, the dots are significant in that they label both a table (within Lua)
and a path (on the system) to where the module resides. But that's (in my
opinion) an internal detail. Yes, there are some modules where loading the
top level will load all the "sub-modules" (for lack of a better term) but
not all. You cannot load "org" and get all my modules. There *IS* no
module "org" (there is no module "org.conman" either).
And your project shows *why* I went with namespacing my modules the way I
did. You have "math-evol", but not "math-rugekutta" because the former
claimed the "Math" module. And the only reason why "math-evol" didn't
conflich with "math-rugekutta" is because of the order you process the
modules. *This* is where I can see a "contending module", because "Math" ==
"Math". "org.conman.env" ~= "org.conman.errno". You need to treat the
entire module name (dots included) as the name.
You have "org.conman.env" listed as "org", which is wrong. You have
"love-ora" listed as "ora", which is wrong. You have a bunch of "lusty-*"
modules, which is correct, but you let that slide because it's a "flat"
Sorry to harp on this, but how you determine "contending modules" is
-spc (Don't worry, I have more comments ... )