[ANN] luafaq.org source on GitHub

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] luafaq.org source on GitHub

Patrick Donnelly
Hello all,

As some of you may know, I host luafaq.org for Steve Donovan. The
source was previously pushed to the site through a fancy subversion
repository. Steve recently moved the source to GitHub [1] which I now
pull from. This should enable people to contribute more easily to the
website through pull requests.

[1] https://github.com/stevedonovan/luafaq

--
Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luafaq.org source on GitHub

steve donovan

On Fri, Jun 28, 2013 at 12:09 AM, Patrick Donnelly <[hidden email]> wrote:
As some of you may know, I host luafaq.org for Steve Donovan.

Thanks, Patrick!  I'm also using fixed-ish line lengths so that diffs and patches are less ugly.

Thinking of doing a new revision, around the idea of 'modern Lua' - the subset that all versions accept.

Some things are definitely verboten, like 'arg' for varargs. It's an ugly 5.0-ism that will hurt anyone wishing to swap over to LuaJIT or Lua 5.2.

module(name) is not considered evil, but module(name,package.seeall) is.  (I'm assuming that Lua 5.2 is usually built in compatibility mode)

People are advised to avoid set/getfenv, and prefer a 5.2-compatible load (which LuaJIT supports and various modules such as pl.compat provide for 5.1).

Being both the chief writer and editor, there are some conflicts of interest, since I'm trying to be fair to people who don't use my libraries ;)

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luafaq.org source on GitHub

Roberto Ierusalimschy
> module(name) is not considered evil, but module(name,package.seeall) is.
> (I'm assuming that Lua 5.2 is usually built in compatibility mode)

I tend to consider 'module(name)' evil nowadays. It is is so easy
to write a module without 'module', and the result is so less magic...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luafaq.org source on GitHub

steve donovan
On Fri, Jun 28, 2013 at 2:16 PM, Roberto Ierusalimschy <[hidden email]> wrote:
I tend to consider 'module(name)' evil nowadays. It is is so easy
to write a module without 'module', and the result is so less magic...

I tend to agree (moved all my code away from module even before 5.2 due to David M's persuasive arguments) but people do not need to rewrite existing code using module to feel 'up to date'. I'm trying to be very liberal in advice, since it isn't _very_ evil. But yes, always magical.

(In my experience porting from module to no-nonsense style is error-prone without a good static analysis tool - Egil's script helped me a lot to keep PL sane in the process.)

steve d.
Reply | Threaded
Open this post in threaded view
|

On Lua and C Modules (was Re: [ANN] luafaq.org source on GitHub)

Sean Conner
In reply to this post by Roberto Ierusalimschy
It was thus said that the Great Roberto Ierusalimschy once stated:
> > module(name) is not considered evil, but module(name,package.seeall) is.
> > (I'm assuming that Lua 5.2 is usually built in compatibility mode)
>
> I tend to consider 'module(name)' evil nowadays. It is is so easy
> to write a module without 'module', and the result is so less magic...

  On that note ...

  Yes, it's easy enough to do:

        module(...)

to pick up the name the requiring script is using (in fact, I just did it
right now 'org.conman.cc' [1][2]).  But for a module written in C, it's a
lot harder to "move" the modules, because of how the initialization function
needs to be called.  So, while I can take the module "org.conman.cc", copy
the file into "/usr/local/lib/lua/5.1/com/example/external/cc.lua" and load
it as:

                x = require "com.example.external.cc" -- [3]

  I *can't* do the same for the module it requires, "org.conman.tcc" [4],
since it's written in C and thus, it *needs* to reside in
"/usr/local/lib/5.1/org/conman/tcc.so".

  I'm surprised that Lua doesn't look for just

                luaopen()

as part of the search mechanism.  It's a dynamic library---there is no
problem what-so-ever in loading multiple shared libs with functions of the
same name [5] so as a fall-back, just calling luaopen() would seem to be
obvious [6].  I'm just curious as to why that wasn't done.  If it had, then
it would be easy to move, say, "org.conman.env" [7] to another location.

  -spc (Just curious ... )

[1] https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.lua

[2] I copied the file to another directory, renamed it 'fluffy.lua',
        modified the module() line, and was able to load it just fine.

[3] Don't question why I would do this; it's enough that I can.

[4] https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.c

[5] Years ago I wrote a program that would load modules at run time, and
        each module exports the same symbol.  

[6] Your method of actually appending the module name was actually
        surprising to me when I first started looking into it.

[7] https://github.com/spc476/lua-conmanorg/blob/master/src/env.c

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luafaq.org source on GitHub

Petite Abeille
In reply to this post by Roberto Ierusalimschy

On Jun 28, 2013, at 2:16 PM, Roberto Ierusalimschy <[hidden email]> wrote:

> I tend to consider 'module(name)' evil nowadays. It is is so easy
> to write a module without 'module', and the result is so less magic…

Utter nonsense.


Reply | Threaded
Open this post in threaded view
|

Re: On Lua and C Modules (was Re: [ANN] luafaq.org source on GitHub)

Roberto Ierusalimschy
In reply to this post by Sean Conner
>   I'm surprised that Lua doesn't look for just
>
> luaopen()
>
> as part of the search mechanism.  It's a dynamic library---there is no
> problem what-so-ever in loading multiple shared libs with functions of the
> same name [5] so as a fall-back, just calling luaopen() would seem to be
> obvious [6].  I'm just curious as to why that wasn't done.  If it had, then
> it would be easy to move, say, "org.conman.env" [7] to another location.

Modules are not always linked dynamically (see, for instance, the
standard Lua libraries). With a single name, one would not be able to
statically link a set of modules to a program.

(Moreover, I am not sure your experience number [5] is portable. IIRC,
we had problems in the past with some systems that signalled name
conflicts even with dynamic libraries.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: On Lua and C Modules (was Re: [ANN] luafaq.org source on GitHub)

Sean Conner
It was thus said that the Great Roberto Ierusalimschy once stated:

> >   I'm surprised that Lua doesn't look for just
> >
> > luaopen()
> >
> > as part of the search mechanism.  It's a dynamic library---there is no
> > problem what-so-ever in loading multiple shared libs with functions of the
> > same name [5] so as a fall-back, just calling luaopen() would seem to be
> > obvious [6].  I'm just curious as to why that wasn't done.  If it had, then
> > it would be easy to move, say, "org.conman.env" [7] to another location.
>
> Modules are not always linked dynamically (see, for instance, the
> standard Lua libraries). With a single name, one would not be able to
> statically link a set of modules to a program.

  I'm sorry if I didn't make myself clearer, but the intent was to look for,
say, "luaopen_foo" and if that wasn't found, try just "luaopen".  

> (Moreover, I am not sure your experience number [5] is portable. IIRC,
> we had problems in the past with some systems that signalled name
> conflicts even with dynamic libraries.)

  Hmm ... now that I think about it, that program was only ever used on
Linux (it was written in the late 90s by the way).  So, you got conflicts
with dlopen()?  (I can see conflicts if you are trying to link multiple
shared objects with the same name with the linker, but not with dlopen()).
Sadly, while surprising, it doesn't really surprise me all that much (if
that makes sense).

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: On Lua and C Modules (was Re: [ANN] luafaq.org source on GitHub)

Jerome Vuarand
In reply to this post by Sean Conner
2013/6/28 Sean Conner <[hidden email]>:
>   I'm surprised that Lua doesn't look for just
>
>                 luaopen()
>
> as part of the search mechanism.

Putting aside name conflict issues in dynamic libraries (that may not
apply to your platforms), it's very easy to extend the module system
to implement the behaviour you describe. I wrote an example binary
loaded on the Lua wiki a while ago (for 5.1):

    http://lua-users.org/wiki/BinaryModulesLoader

Simply replace the package.loadlib second argument with a constant
string, and voilà, you can move your DLLs around (provided you name
the entry point with that constant string).

Reply | Threaded
Open this post in threaded view
|

Re: On Lua and C Modules (was Re: [ANN] luafaq.org source on GitHub)

Sean Conner
It was thus said that the Great Jerome Vuarand once stated:

> 2013/6/28 Sean Conner <[hidden email]>:
> >   I'm surprised that Lua doesn't look for just
> >
> >                 luaopen()
> >
> > as part of the search mechanism.
>
> Putting aside name conflict issues in dynamic libraries (that may not
> apply to your platforms), it's very easy to extend the module system
> to implement the behaviour you describe. I wrote an example binary
> loaded on the Lua wiki a while ago (for 5.1):
>
>     http://lua-users.org/wiki/BinaryModulesLoader
>
> Simply replace the package.loadlib second argument with a constant
> string, and voilà, you can move your DLLs around (provided you name
> the entry point with that constant string).

  True enough, but I was just wanting the ability to rename C modules with
the same ease as you can Lua modules (just rename the file, and if the
module starts with "module(...)" It Just Works).

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luafaq.org source on GitHub

Miles Bader-2
In reply to this post by steve donovan
steve donovan <[hidden email]> writes:
> (I'm assuming that Lua 5.2 is usually built in compatibility mode)

Not a good assumption... e.g., the Debian Lua 5.2 package isn't built
with compatibility mode, and I've never done so for my own builds
either...

-miles

--
x
y
Z!

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luafaq.org source on GitHub

Miles Bader-2
In reply to this post by Petite Abeille
Petite Abeille <[hidden email]> writes:
>> I tend to consider 'module(name)' evil nowadays. It is is so easy
>> to write a module without 'module', and the result is so less magic…
>
> Utter nonsense.

Er, no.

[but you've made your opinion on the matter very, very, very, clear in
past discussions, so lets not go through that again.]

-miles

--
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luafaq.org source on GitHub

Petite Abeille

On Jul 3, 2013, at 4:12 AM, Miles Bader <[hidden email]> wrote:

> Petite Abeille <[hidden email]> writes:
>>> I tend to consider 'module(name)' evil nowadays. It is is so easy
>>> to write a module without 'module', and the result is so less magic…
>>
>> Utter nonsense.
>
> Er, no.
>
> [but you've made your opinion on the matter very, very, very, clear in
> past discussions, so lets not go through that again.]

Yeah… lets not beat that dead horse more than necessary.

And yet… the gratuitous, postmortem slander of 'module' by disparaging it as 'evil', 'magic', 'complex', etc… is ungentlemanly and borderline revisionist.




Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luafaq.org source on GitHub

Miles Bader-2
Petite Abeille <[hidden email]> writes:
> And yet… the gratuitous, postmortem slander of 'module' by
> disparaging it as 'evil', 'magic', 'complex', etc… is ungentlemanly
> and borderline revisionist.

As "module" is not actually sentient, I'm sure "module" can deal with
being called names... :]

-miles

--
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)