Triumvirates

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

Triumvirates

Dirk Laurie-2
Postings involving the following circle of ideas often appear on the list.

- Lua has no officially blessed library with hundreds of add-ons like
Python does.
- The initial exposure to Lua includes no WOW! graphics and/or sound
applications.
- The Lua interactive shell is very primitive compared to {ipython,…} — no GUI
  for program development.

There are at least three big projects in the direction of standard
module libraries:
Kepler, stdlib and Penlight.  There is at least one project in the direction of
synchronized module management: Luarocks.  There is the LfW collection for
Windows.  But none of them is 'official'.

What the community needs (maybe) is a sort of overall design and quaiity control
of module libraries.  Near-universal acknowledgment that a particular set of
modules, as painless to install on all platforms as is Lua itself, is canonical.

It is quite clear that we must not expect the Lua team to deal with
these issues.
Luiz and Roberto have both put substantial Lua add-ons on their sites with no
attempt to make them part of the 'official' Lua distribution.  Their task is to
keep the Lua core lean and healthy, and very well they do it too.

There have been suggestions of appointing a BDFL for overseeing a Lua module
library, all candidates however turning down the honour.

Now we have seen a development management model that works well: the one
in action for Lua itself.  A triumvirate of individuals with different
but compatible
talents.  A conservative policy of requiring unanimity before a
feature is added.

By contrast, most [ANN] items on lua-l are one-man efforts.  Sometimes, as in
the case of LuaJIT, that one man is a superman, but many others are pet projects
that die within a year.

Suppose there were similar triumvirates for module libraries, with a similar
conservative policy.  Maybe the reluctant BDFL's would be willing to shoulder
this shared responsibilty.  Then we might, we just might, see some consensus
emerging on which libraries are the one every Lua programmer should turn
to first.

Dirk
(who had a spare half-hour between knocking off work and supper)

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Wim Couwenberg
> ...  Then we might, we just might, see some consensus
> emerging on which libraries are the one every Lua programmer should turn
> to first.

Fabien Fleutot explained in his workshop talk why this is futile.
(You had to be there though, his slides are not on the workshop site
it appears.)  Personal interpretation:  My "professional" Lua bindings
would not be suitable at all for a general audience, being very
specialized to a certain context.  That this is so easy to do is
exactly what makes Lua my language of choice.  (I think that sharing
ideas, not code, could be more interesting.)

Bye,
Wim

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Ralph Eastwood
In reply to this post by Dirk Laurie-2
I have to agree with what Dirk has said,

"What the community needs (maybe) is a sort of overall design and quaiity control
of module libraries" and "many others are pet projects
that die within a year", I think highlights this particular problem; 
who maintains all those old libraries with new lua versions across each platform in this theoretical
centralised(e.g. luarocks) module repository?

There's lots of flavours of linux, and each flavour has their own set of maintainers, varying from less than 10 to more than a hundred.  However, it goes to show that there's a lot of folk out there, and I suspect if the framework was in place, lua could be maintained similarly.
For ensuring cross-platform-ness, should automatic build systems be considered? I know the distribution of binaries would not be useful, but to ensure things can build, and give the option for pre-built libraries (on certain platforms - probably useless on linux, but fine on win+mac).

The role of the maintainer would probably be to just make sure things always compile. Should the module writer be encouraged to be the module's maintainer?

Ralph

On 26 October 2011 17:01, Dirk Laurie <[hidden email]> wrote:
Postings involving the following circle of ideas often appear on the list.

- Lua has no officially blessed library with hundreds of add-ons like
Python does.
- The initial exposure to Lua includes no WOW! graphics and/or sound
applications.
- The Lua interactive shell is very primitive compared to {ipython,…} — no GUI
 for program development.

There are at least three big projects in the direction of standard
module libraries:
Kepler, stdlib and Penlight.  There is at least one project in the direction of
synchronized module management: Luarocks.  There is the LfW collection for
Windows.  But none of them is 'official'.

What the community needs (maybe) is a sort of overall design and quaiity control
of module libraries.  Near-universal acknowledgment that a particular set of
modules, as painless to install on all platforms as is Lua itself, is canonical.

It is quite clear that we must not expect the Lua team to deal with
these issues.
Luiz and Roberto have both put substantial Lua add-ons on their sites with no
attempt to make them part of the 'official' Lua distribution.  Their task is to
keep the Lua core lean and healthy, and very well they do it too.

There have been suggestions of appointing a BDFL for overseeing a Lua module
library, all candidates however turning down the honour.

Now we have seen a development management model that works well: the one
in action for Lua itself.  A triumvirate of individuals with different
but compatible
talents.  A conservative policy of requiring unanimity before a
feature is added.

By contrast, most [ANN] items on lua-l are one-man efforts.  Sometimes, as in
the case of LuaJIT, that one man is a superman, but many others are pet projects
that die within a year.

Suppose there were similar triumvirates for module libraries, with a similar
conservative policy.  Maybe the reluctant BDFL's would be willing to shoulder
this shared responsibilty.  Then we might, we just might, see some consensus
emerging on which libraries are the one every Lua programmer should turn
to first.

Dirk
(who had a spare half-hour between knocking off work and supper)




--
Tai Chi Minh Ralph Eastwood
Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Gavin Wraith
In reply to this post by Dirk Laurie-2
In message
<CABcj=[hidden email]>
you wrote:

> Postings involving the following circle of ideas often appear on the list.

> What the community needs (maybe) is a sort of overall design and quality
> control of module libraries.  Near-universal acknowledgment that a
> particular set of modules, as painless to install on all platforms
> as is Lua itself, is canonical.

Please excuse a discreet cough from a pedantic user of a minority platform.
I do not think you meant "all", Dirk; you meant "most". My platform will
never be able to use the module libraries you mention. It does not even
support dynamic linking. One of the key reasons why people like me adore Lua
is that when http://www.lua.org/about.html says "Lua is distributed in a
small package and builds out-of-the-box in all platforms that have an
ANSI/ISO C compiler" the word "all" is being used correctly.
 
--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Peter Drahoš
In reply to this post by Ralph Eastwood

On Oct 26, 2011, at 19:01 , Ralph Eastwood wrote:

> I have to agree with what Dirk has said,
>
> "What the community needs (maybe) is a sort of overall design and quaiity control
> of module libraries" and "many others are pet projects
> that die within a year", I think highlights this particular problem;
> who maintains all those old libraries with new lua versions across each platform in this theoretical
> centralised(e.g. luarocks) module repository?
Quality control and some centralized standard is definitely needed. The situation is even worse after the collapse of LuaForge. But I don't think it is really needed unless you expect Lua to replace Python and Ruby standard installations soon. Building customized Lua environments in semi-automated manner is possible with LuaRocks[1] and LuaDist[2] even now. Only once these systems mature can we expect module authors and library standards to emerge.
>
> There's lots of flavours of linux, and each flavour has their own set of maintainers, varying from less than 10 to more than a hundred.  However, it goes to show that there's a lot of folk out there, and I suspect if the framework was in place, lua could be maintained similarly.
> For ensuring cross-platform-ness, should automatic build systems be considered? I know the distribution of binaries would not be useful, but to ensure things can build, and give the option for pre-built libraries (on certain platforms - probably useless on linux, but fine on win+mac).
LuaRocks is a great attempt to make a cross-platform Lua distribution but it has design flaws that have become apparent with the move to Lua 5.2 and with the Windows release issues. However there is also the often overlooked LuaDist which centralizes most of Lua modules in a cross-plaform Repository[3] that uses CMake to build Lua and its modules from scratch on OSX,Linux,Unix and Windows. It works good enough that we are considering releasing the next Lua4Windows[4] releases using LuaDist as base. Nothing prevents Linux maintainers from using LuaDist builds to supply the modules on their flavor of Linux. However I and the LuaDist project prefer to build a self-contained Lua environment from scratch without using the host package manager and libraries. This way any OS becomes a Lua friendly OS.
>
> The role of the maintainer would probably be to just make sure things always compile. Should the module writer be encouraged to be the module's maintainer?
Yes, module author should be the maintainer. However in case of abandoned modules it is in the responsibility of the development team of the distribution to update the module (if license allows). This is technically not a problem when you have more maintainers available. For illustration LuaDist has 3 maintainers (me, davidm, kapecp) from which 2 are inactive at the moment. LuaRocks on the other hand requires module submission over mail and the module is usually picked up by Hisham himself. It would be on a whole new level if either of us had 10 maintainers or volunteers.

pd

[1] www.luarocks.org
[2] www.luadist.org
[3] https://github.com/LuaDist/Repository
[4] http://groups.google.com/group/luaforwindows
Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Peter Drahoš
In reply to this post by Gavin Wraith

On Oct 26, 2011, at 19:30 , Gavin Wraith wrote:

> In message
> <CABcj=[hidden email]>
> you wrote:
>
>> Postings involving the following circle of ideas often appear on the list.
>
>> What the community needs (maybe) is a sort of overall design and quality
>> control of module libraries.  Near-universal acknowledgment that a
>> particular set of modules, as painless to install on all platforms
>> as is Lua itself, is canonical.
>
> Please excuse a discreet cough from a pedantic user of a minority platform.
> I do not think you meant "all", Dirk; you meant "most". My platform will
> never be able to use the module libraries you mention. It does not even
> support dynamic linking. One of the key reasons why people like me adore Lua
> is that when http://www.lua.org/about.html says "Lua is distributed in a
> small package and builds out-of-the-box in all platforms that have an
> ANSI/ISO C compiler" the word "all" is being used correctly.
But even users of embedded systems can make use of systems like CMake and collections of modules to cross-compile and build the static libraries of modules. In this regard a centralized and standardized approach could also satisfy this use case.

pd
Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Jimmie Houchin
In reply to this post by Dirk Laurie-2
On 10/26/2011 11:01 AM, Dirk Laurie wrote:

> Postings involving the following circle of ideas often appear on the list.
>
> - Lua has no officially blessed library with hundreds of add-ons like
> Python does.
> - The initial exposure to Lua includes no WOW! graphics and/or sound
> applications.
> - The Lua interactive shell is very primitive compared to {ipython,…} — no GUI
>    for program development.
>
> There are at least three big projects in the direction of standard
> module libraries:
> Kepler, stdlib and Penlight.  There is at least one project in the direction of
> synchronized module management: Luarocks.  There is the LfW collection for
> Windows.  But none of them is 'official'.
>
> What the community needs (maybe) is a sort of overall design and quaiity control
> of module libraries.  Near-universal acknowledgment that a particular set of
> modules, as painless to install on all platforms as is Lua itself, is canonical.
>
> It is quite clear that we must not expect the Lua team to deal with
> these issues.
> Luiz and Roberto have both put substantial Lua add-ons on their sites with no
> attempt to make them part of the 'official' Lua distribution.  Their task is to
> keep the Lua core lean and healthy, and very well they do it too.
>
> There have been suggestions of appointing a BDFL for overseeing a Lua module
> library, all candidates however turning down the honour.
>
> Now we have seen a development management model that works well: the one
> in action for Lua itself.  A triumvirate of individuals with different
> but compatible
> talents.  A conservative policy of requiring unanimity before a
> feature is added.
>
> By contrast, most [ANN] items on lua-l are one-man efforts.  Sometimes, as in
> the case of LuaJIT, that one man is a superman, but many others are pet projects
> that die within a year.
>
> Suppose there were similar triumvirates for module libraries, with a similar
> conservative policy.  Maybe the reluctant BDFL's would be willing to shoulder
> this shared responsibilty.  Then we might, we just might, see some consensus
> emerging on which libraries are the one every Lua programmer should turn
> to first.
>
> Dirk
> (who had a spare half-hour between knocking off work and supper)
>
I would love to see something like this.

This is open source. If somebody puts out there code with appropriate
open source license then there code is usable.
And if somebody else assembles a distribution of the disparate sources
of code, then we have a full featured option for people who are looking
for such.

People who come to Lua from Python, Ruby, Perl, ... are often going to
attempt to do things they are used to doing in their present favorite
language. The more obstacles we put between them and productivity, then
they will be less likely to use Lua. They will also be more prone to
possible complaints or another round of emails to the list.

Many of us who would like to use Lua, but are not yet of sufficient
knowledge or skills. We are not qualified to determine quality of
libraries and code to include in such a distribution. But if some who
is, started such a distribution and built a community around it. Then we
could have capable, qualified decision makers on what goes in and what
does not.

It is like Linux distributions. There were a lot of distributions
already when Ubuntu first came out. But it became a phenomenal success.
And a lot of distributions have been created after.

I don't understand communities where everybody has to do what everybody
else has already done, simply because it was easy to do. Ugh!

We have more productive things to do than to recreate, (write/build) the
wheel. Many of us don't have the skills to create certain things, but do
have the skills to use them when created.

I would love to see a Lua community get behind the building of a full
featured distribution and do some interesting things. Build upon it,
build with it.

Lets build something together, instead each building their own.

Way past my 2cents.

Jimmie Houchin


Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Jimmie Houchin
In reply to this post by Gavin Wraith
On 10/26/2011 12:30 PM, Gavin Wraith wrote:

> In message
> <CABcj=[hidden email]>
> you wrote:
>
>> Postings involving the following circle of ideas often appear on the list.
>> What the community needs (maybe) is a sort of overall design and quality
>> control of module libraries.  Near-universal acknowledgment that a
>> particular set of modules, as painless to install on all platforms
>> as is Lua itself, is canonical.
> Please excuse a discreet cough from a pedantic user of a minority platform.
> I do not think you meant "all", Dirk; you meant "most". My platform will
> never be able to use the module libraries you mention. It does not even
> support dynamic linking. One of the key reasons why people like me adore Lua
> is that when http://www.lua.org/about.html says "Lua is distributed in a
> small package and builds out-of-the-box in all platforms that have an
> ANSI/ISO C compiler" the word "all" is being used correctly.
>
Even if one could not use such a distribution as a whole. It would
potentially still be a nice resource of community maintained code which
has been deemed of sufficient quality for inclusion in said
distribution. Then you the expert, could choose what module meets your
specific need out of the distribution.

Some things you go to wherever on the web to download and you have no
idea if is still supported. Or if it is the best option to accomplish
what you want.

You go to a web page to download a module  0.4 beta dated 2009 and
wonder if it is the right choice.

This hopefully could help with such dilemmas.

Jimmie Houchin

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Enrico Colombini
In reply to this post by Gavin Wraith
On 26/10/2011 19.30, Gavin Wraith wrote:
> Please excuse a discreet cough from a pedantic user of a minority platform.
> I do not think you meant "all", Dirk; you meant "most". My platform will
> never be able to use the module libraries you mention. It does not even
> support dynamic linking. One of the key reasons why people like me adore Lua
> is that when http://www.lua.org/about.html says "Lua is distributed in a
> small package and builds out-of-the-box in all platforms that have an
> ANSI/ISO C compiler" the word "all" is being used correctly.

And I have different versions of Lua, some of those patched, each one
with its own set of modules, happily co-existing on the same Windows
machine in different project directories. They should also work on
another machine by just copying the directory (e.g. via SVN).

I have nothing against people wishing to use Lua as system-wide
language, but Lua has many other uses (and users). Requiring
installation and forcing a centralized module system (e.g. by only
releasing modules that way) could cause significant problems to some of us.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Jimmie Houchin
On 10/26/2011 1:05 PM, Enrico Colombini wrote:

> On 26/10/2011 19.30, Gavin Wraith wrote:
>> Please excuse a discreet cough from a pedantic user of a minority
>> platform.
>> I do not think you meant "all", Dirk; you meant "most". My platform will
>> never be able to use the module libraries you mention. It does not even
>> support dynamic linking. One of the key reasons why people like me
>> adore Lua
>> is that when http://www.lua.org/about.html says "Lua is distributed in a
>> small package and builds out-of-the-box in all platforms that have an
>> ANSI/ISO C compiler" the word "all" is being used correctly.
>
> And I have different versions of Lua, some of those patched, each one
> with its own set of modules, happily co-existing on the same Windows
> machine in different project directories. They should also work on
> another machine by just copying the directory (e.g. via SVN).
>
> I have nothing against people wishing to use Lua as system-wide
> language, but Lua has many other uses (and users). Requiring
> installation and forcing a centralized module system (e.g. by only
> releasing modules that way) could cause significant problems to some
> of us.
>
Understood. But how is this a problem?

 From what I understand this would be an option, an additional way to
use Lua. Not a replacement for anybodies use of Lua. Unless of course,
your use of Lua is a poor ad-hoc version of what this would try to
accomplish.

This should in no way eliminate or reduce what you are already doing.

If any conflicts arise from its design, with already existing uses or
installations, then that should be a bug and be addressed.
If necessary with renaming its executable to iLua (borrowed from Lua for
Windows) or some such. And also creating appropriate paths and
environment variables for the feature-rich version which do not conflict
with other installations or versions.

Just a couple thoughts.

Jimmie Houchin

Reply | Threaded
Open this post in threaded view
|

Fabien Fleutot's slides (was: Re: Triumvirates)

Enrico Tassi-3
In reply to this post by Wim Couwenberg
On Wed, Oct 26, 2011 at 06:25:57PM +0200, Wim Couwenberg wrote:
> > ...  Then we might, we just might, see some consensus
> > emerging on which libraries are the one every Lua programmer should turn
> > to first.
>
> Fabien Fleutot explained in his workshop talk why this is futile.
> (You had to be there though, his slides are not on the workshop site
> it appears.)  Personal interpretation:  My "professional" Lua bindings

I would be really interested to hear his arguments. Does anyone have his
slides or an audio/video recording of his talk?

regards
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Dimiter 'malkia' Stanev
In reply to this post by Dirk Laurie-2
I treat lua and luajit same way as linux kernel.

When comes to full blown GNU/Linux distribution, then it's outside the
kernel.

I understand your problem, but having lua (I'm more interrested in
luajit though) BINARY distribution, at least for Windows is tricky:

        - Which compiler should be used? Can different compilers be mixed?
        - Should both 32-bit and 64-bit be supported
        - Should we link to KERNEL32.DLL directly, or old style MSVCRT.DLL, or
new style SxS MSVCRxx.DLL, or something like Mozilla - MOZCRT?
        - Should we rely on environment variables, or side effects
(SetCurrentDirectory for example on Windows that changes the way DLLs
are found)
        - Should there be a mode for static linking?
        - For dynamic linking should we leave all .dlls one by one, or merge
them together?
       
These questions are not easy to answer.

        It depends on how you would use luajit. For some it's from the
command-line, but my goal is to use it as plugin for certain Adobe or
Autodesk products - as such I cannot rely on dependent modules to be in
specific places (/usr/bin, or c:/windows/system32, or whatever there
is), they have to be "near" the plugin one.
        Also at some point I would need special build so that all .dll/.exe are
made into one .dll/.exe and distributed this way (as long as the LICENSE
allows).

        And then OSX - Should it be based on macports, fink or homebrew? Or
should it use the system installed ones? XCode? (thank god it's free again)

        For Linux is probably easier - there are already well established
systems, and maybe reusing them is better - apt/rpm/deb/whatever there is.

        For now my goal is to treat everything locally, although I still rely
on LUA_PATH and LUA_CPATH (but I'm going to change that).

        I've found on all three major (for me) platforms ways to load DLLs
relative to the places they are located.
        -- Windows - That's by default, unless SetCurrentDirectory() is used
        -- OSX - install_name_tool magic tool with @rpath, @executable_path
        -- Linux - -rpath with $ORIGIN magic

make -C $ROOT/src -j amalg TARGET_SONAME=libluajit.so BUILDMODE=dynamic
TARGET_DYNXLDOPTS=-Wl,-rpath,'$$\ORIGIN' Q=

On 10/26/2011 9:01 AM, Dirk Laurie wrote:

> Postings involving the following circle of ideas often appear on the list.
>
> - Lua has no officially blessed library with hundreds of add-ons like
> Python does.
> - The initial exposure to Lua includes no WOW! graphics and/or sound
> applications.
> - The Lua interactive shell is very primitive compared to {ipython,…} — no GUI
>    for program development.
>
> There are at least three big projects in the direction of standard
> module libraries:
> Kepler, stdlib and Penlight.  There is at least one project in the direction of
> synchronized module management: Luarocks.  There is the LfW collection for
> Windows.  But none of them is 'official'.
>
> What the community needs (maybe) is a sort of overall design and quaiity control
> of module libraries.  Near-universal acknowledgment that a particular set of
> modules, as painless to install on all platforms as is Lua itself, is canonical.
>
> It is quite clear that we must not expect the Lua team to deal with
> these issues.
> Luiz and Roberto have both put substantial Lua add-ons on their sites with no
> attempt to make them part of the 'official' Lua distribution.  Their task is to
> keep the Lua core lean and healthy, and very well they do it too.
>
> There have been suggestions of appointing a BDFL for overseeing a Lua module
> library, all candidates however turning down the honour.
>
> Now we have seen a development management model that works well: the one
> in action for Lua itself.  A triumvirate of individuals with different
> but compatible
> talents.  A conservative policy of requiring unanimity before a
> feature is added.
>
> By contrast, most [ANN] items on lua-l are one-man efforts.  Sometimes, as in
> the case of LuaJIT, that one man is a superman, but many others are pet projects
> that die within a year.
>
> Suppose there were similar triumvirates for module libraries, with a similar
> conservative policy.  Maybe the reluctant BDFL's would be willing to shoulder
> this shared responsibilty.  Then we might, we just might, see some consensus
> emerging on which libraries are the one every Lua programmer should turn
> to first.
>
> Dirk
> (who had a spare half-hour between knocking off work and supper)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Javier Guerra Giraldez
In reply to this post by Jimmie Houchin
On Wed, Oct 26, 2011 at 1:17 PM, Jimmie Houchin <[hidden email]> wrote:
>> Requiring installation and forcing a centralized module system (e.g. by
>> only releasing modules that way) could cause significant problems to some of
>> us.
>>
> Understood. But how is this a problem?

it's not as long as it's not required.

case in point: there are some Lua packages with an INSTALL.txt file
with only "use luarocks".  great for maybe 60%-80% of users, useless
for many others.  usually, there's nothing in that package that needs
LuaRocks, but without knowing how is it supposed to be installed (or
even what are its requirements!), it becomes an obstacle.

much better would be "use LuaRocks, or be sure to have packages foobar
and bizbang available"

likewise, if some Lua packaging (distro?) becomes widely popular, and
regarded as a common standard; it becomes a platform, and some people
will create packages that need 'common' packages without specifying
(or knowing!) which ones are really required.

maybe a tracing tool that registers which packages are loaded would be
some help in documenting dependencies...

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Jimmie Houchin
On 10/26/2011 2:25 PM, Javier Guerra Giraldez wrote:

> On Wed, Oct 26, 2011 at 1:17 PM, Jimmie Houchin<[hidden email]>  wrote:
>>> Requiring installation and forcing a centralized module system (e.g. by
>>> only releasing modules that way) could cause significant problems to some of
>>> us.
>>>
>> Understood. But how is this a problem?
> it's not as long as it's not required.
>
> case in point: there are some Lua packages with an INSTALL.txt file
> with only "use luarocks".  great for maybe 60%-80% of users, useless
> for many others.  usually, there's nothing in that package that needs
> LuaRocks, but without knowing how is it supposed to be installed (or
> even what are its requirements!), it becomes an obstacle.
>
> much better would be "use LuaRocks, or be sure to have packages foobar
> and bizbang available"
>
> likewise, if some Lua packaging (distro?) becomes widely popular, and
> regarded as a common standard; it becomes a platform, and some people
> will create packages that need 'common' packages without specifying
> (or knowing!) which ones are really required.
>
> maybe a tracing tool that registers which packages are loaded would be
> some help in documenting dependencies...
I agree that this would need to be done correctly.

I may be nuts, and am ok if demonstrated as such. :)
But I naively think that such a distribution or platform should within
reason, potentially have its own repository of packages.

This way it could control packaging, require(ing), etc... without
affecting other Lua installations on a machine.
As you say it becomes its own platform.

If the author of a certain package does not wish it to be repackaged in
the distribution's repository, but is ok with it being included and is
happy to provide an appropriately packaged package. Then I don't see a
problem with packages as such.

These are only thoughts from someone who would love to replace his use
of Python with Lua. Someone who is not at this point able to contribute
much other than ideas or thoughts.

I would love to see the ability to choose Lua to be one done on merits
of Lua v. ??? language design and not on availability or support of
libraries.

Jimmie Houchin

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Peter Drahoš
In reply to this post by Dimiter 'malkia' Stanev

On Oct 26, 2011, at 21:20 , Dimiter 'malkia' Stanev wrote:

> I treat lua and luajit same way as linux kernel.
>
> When comes to full blown GNU/Linux distribution, then it's outside the kernel.
>
> I understand your problem, but having lua (I'm more interrested in luajit though) BINARY distribution, at least for Windows is tricky:
>
> - Which compiler should be used? Can different compilers be mixed?
> - Should both 32-bit and 64-bit be supported
> - Should we link to KERNEL32.DLL directly, or old style MSVCRT.DLL, or new style SxS MSVCRxx.DLL, or something like Mozilla - MOZCRT?
> - Should we rely on environment variables, or side effects (SetCurrentDirectory for example on Windows that changes the way DLLs are found)
> - Should there be a mode for static linking?
> - For dynamic linking should we leave all .dlls one by one, or merge them together?
All of this besides the last point is addressed when building with CMake, in LuaDist we can build using various compilers(MSVC, MinGW, Clang) for various targets (64bit, 32bit). Avoiding the MS provided runtimes is recommended and possible too. Environment variables do not need to be specified on Windows if the distribution carries all its dependencies. LuaDist does solve most of this and the binaries (intended to replace L4W once fully tested) are available here[1].
>
> These questions are not easy to answer.
They are actually very easy to answer when you are willing to invest time to learn tools created exactly for this purpose.
>
> It depends on how you would use luajit. For some it's from the command-line, but my goal is to use it as plugin for certain Adobe or Autodesk products - as such I cannot rely on dependent modules to be in specific places (/usr/bin, or c:/windows/system32, or whatever there is), they have to be "near" the plugin one.
> Also at some point I would need special build so that all .dll/.exe are made into one .dll/.exe and distributed this way (as long as the LICENSE allows).
In my opinion this is also no issue. For example LuaDist modules can be manually built without any other dependencies by checking out the module source and setting up few CMake variables that modify LUA_CPATH/PATH and install behavior etc.  You can tailor the build to your needs, include it in your product release process or cross-compile for you exotic platform of choice. You do not have to use the magic automated installer intended for desktop releases.
>
> And then OSX - Should it be based on macports, fink or homebrew? Or should it use the system installed ones? XCode? (thank god it's free again)
>
> For Linux is probably easier - there are already well established systems, and maybe reusing them is better - apt/rpm/deb/whatever there is.
From my point of view there is no difference, both are Unix-like system with GCC/Clang available. CMake works on both and we can generate build files for your IDE of choice. You can safely ignore the native package management if your distribution does not depend on any outside sources.
>
> For now my goal is to treat everything locally, although I still rely on LUA_PATH and LUA_CPATH (but I'm going to change that).
>
> I've found on all three major (for me) platforms ways to load DLLs relative to the places they are located.
> -- Windows - That's by default, unless SetCurrentDirectory() is used
> -- OSX - install_name_tool magic tool with @rpath, @executable_path
> -- Linux - -rpath with $ORIGIN magic
Already done in LuaDist, thanks to CMake its fully automated and portable.

pd

[1] https://github.com/LuaDist/Repository/downloads



Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Dimiter 'malkia' Stanev
Thanks for the response, Peter!

LuaDist seems like a very cool project.

On 10/26/2011 3:23 PM, Peter Drahoš wrote:

>
> On Oct 26, 2011, at 21:20 , Dimiter 'malkia' Stanev wrote:
>
>> I treat lua and luajit same way as linux kernel.
>>
>> When comes to full blown GNU/Linux distribution, then it's outside the kernel.
>>
>> I understand your problem, but having lua (I'm more interrested in luajit though) BINARY distribution, at least for Windows is tricky:
>>
>> - Which compiler should be used? Can different compilers be mixed?
>> - Should both 32-bit and 64-bit be supported
>> - Should we link to KERNEL32.DLL directly, or old style MSVCRT.DLL, or new style SxS MSVCRxx.DLL, or something like Mozilla - MOZCRT?
>> - Should we rely on environment variables, or side effects (SetCurrentDirectory for example on Windows that changes the way DLLs are found)
>> - Should there be a mode for static linking?
>> - For dynamic linking should we leave all .dlls one by one, or merge them together?
> All of this besides the last point is addressed when building with CMake, in LuaDist we can build using various compilers(MSVC, MinGW, Clang) for various targets (64bit, 32bit). Avoiding the MS provided runtimes is recommended and possible too. Environment variables do not need to be specified on Windows if the distribution carries all its dependencies. LuaDist does solve most of this and the binaries (intended to replace L4W once fully tested) are available here[1].
>>
>> These questions are not easy to answer.
> They are actually very easy to answer when you are willing to invest time to learn tools created exactly for this purpose.
>>
>> It depends on how you would use luajit. For some it's from the command-line, but my goal is to use it as plugin for certain Adobe or Autodesk products - as such I cannot rely on dependent modules to be in specific places (/usr/bin, or c:/windows/system32, or whatever there is), they have to be "near" the plugin one.
>> Also at some point I would need special build so that all ..dll/.exe are made into one .dll/.exe and distributed this way (as long as the LICENSE allows).
> In my opinion this is also no issue. For example LuaDist modules can be manually built without any other dependencies by checking out the module source and setting up few CMake variables that modify LUA_CPATH/PATH and install behavior etc.  You can tailor the build to your needs, include it in your product release process or cross-compile for you exotic platform of choice. You do not have to use the magic automated installer intended for desktop releases.
>>
>> And then OSX - Should it be based on macports, fink or homebrew? Or should it use the system installed ones? XCode? (thank god it's free again)
>>
>> For Linux is probably easier - there are already well established systems, and maybe reusing them is better - apt/rpm/deb/whatever there is.
>  From my point of view there is no difference, both are Unix-like system with GCC/Clang available. CMake works on both and we can generate build files for your IDE of choice. You can safely ignore the native package management if your distribution does not depend on any outside sources.
>>
>> For now my goal is to treat everything locally, although I still rely on LUA_PATH and LUA_CPATH (but I'm going to change that).
>>
>> I've found on all three major (for me) platforms ways to load DLLs relative to the places they are located.
>> -- Windows - That's by default, unless SetCurrentDirectory() is used
>> -- OSX - install_name_tool magic tool with @rpath, @executable_path
>> -- Linux - -rpath with $ORIGIN magic
> Already done in LuaDist, thanks to CMake its fully automated and portable.
>
> pd
>
> [1] https://github.com/LuaDist/Repository/downloads
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Fabien-3
In reply to this post by Wim Couwenberg
On Wed, Oct 26, 2011 at 6:25 PM, Wim Couwenberg <[hidden email]> wrote:
Fabien Fleutot explained in his workshop talk why this is futile.
(You had to be there though, his slides are not on the workshop site it appears)

They must have gotten lost, I sent them. Here's a Google doc upload, with speaker's notes, I'll ask to get them on the workshop's site.
 

Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Jorge Visca
On jue, 2011-10-27 at 10:47 +0200, Fabien wrote:

> They must have gotten lost, I sent them. Here's a Google doc upload,
> with speaker's notes, I'll ask to get them on the workshop's site.
>  
> https://docs.google.com/present/view?id=dc4dz2xm_52cqws8rhm
>
>

Wow. Looking at the "Coroutine-based multithreading" and "Scheduling"
diapos you have the Lua OS right there.


Jorge


Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Fabien-3
On Thu, Oct 27, 2011 at 4:13 PM, Jorge <[hidden email]> wrote:
On jue, 2011-10-27 at 10:47 +0200, Fabien wrote:
> Here are [my workshop slides, don't forget to show speaker's notes:]
> https://docs.google.com/present/view?id=dc4dz2xm_52cqws8rhm

Wow. Looking at the "Coroutine-based multithreading" and "Scheduling"
diapos you have the Lua OS right there.

I don't think it should be called an OS; but it definitely is a nice generic framework to develop complex, portable concurrent applications in Lua. 

-- Fabien.
Reply | Threaded
Open this post in threaded view
|

Re: Triumvirates

Jorge Visca
On jue, 2011-10-27 at 18:21 +0200, Fabien wrote:

> I don't think it should be called an OS; but it definitely is a nice
> generic framework to develop complex, portable concurrent applications
> in Lua.

Well, unix is a "nice framework to develop complex, portable concurrent
applications in C". :)

Jorge