Batteries

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

Batteries

Dirk Laurie-2
2018-03-11 3:42 GMT+02:00 Dibyendu Majumdar <[hidden email]>:

> On the other hand, I think this model is harmful for the 'batteries'
> part - which could easily be improved by allowing external
> contributors.

I use Roberto's LPeg and several of Luiz's modules: complex numbers,
C99 math, XML parsing etc. They are of comparable quality to Lua
itself and stay abreast of new releases, but they give a glimpse of
what Lua might have been like if developed by only that person ­— and
I wonder if Waldemar's unheralded role might not be to mediate between
two extremes.

The key is: "of comparable quality to Lua itself ".

We have two main battery providers: stdlib and penlight, and one
battery compiler: luarocks. Will lovers of the first two please stand
up to be counted? I use a dozen or so offerings from the third, but
with caution: there are often several different offerings for the same
task, and they come without quality certificates.

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Dibyendu Majumdar
On 11 March 2018 at 08:25, Dirk Laurie <[hidden email]> wrote:

> 2018-03-11 3:42 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>
>> On the other hand, I think this model is harmful for the 'batteries'
>> part - which could easily be improved by allowing external
>> contributors.
>
> I use Roberto's LPeg and several of Luiz's modules: complex numbers,
> C99 math, XML parsing etc. They are of comparable quality to Lua
> itself and stay abreast of new releases, but they give a glimpse of
> what Lua might have been like if developed by only that person ­— and
> I wonder if Waldemar's unheralded role might not be to mediate between
> two extremes.
>
> The key is: "of comparable quality to Lua itself ".
>
> We have two main battery providers: stdlib and penlight, and one
> battery compiler: luarocks. Will lovers of the first two please stand
> up to be counted? I use a dozen or so offerings from the third, but
> with caution: there are often several different offerings for the same
> task, and they come without quality certificates.
>

Sorry I don't think I explained clearly what I meant.

The Lua core libraries are constrained by the need to be small,
portable anywhere there is a C99 compiler, hence most libraries cannot
be included in Lua standard library.

However, the community needs and would benefit from an extended
standard library that is supervised / blessed by the Lua team. All the
Lua team have to do is:

a) Create an official repository - perhaps in Github
b) Appoint trusted leads who can manage the library - I am sure many
people here who maintain distros or major libraries would be willing
to help - I can think of a few names including yours.
c) Take part in regular reviews and decision making - maybe spend 1
hour per fortnight in an online meeting to approve / disapprove
decisions taken by the leads.
d) The leads should create a shortlist of the libraries that need to
be include - and set criteria on quality, documentation, portability
etc., again possibly reviewed/approved by Lua team.

All this can be done with very little effort from the Lua team.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Dirk Laurie-2
2018-03-11 13:10 GMT+02:00 Dibyendu Majumdar <[hidden email]>:

> On 11 March 2018 at 08:25, Dirk Laurie <[hidden email]> wrote:
>> 2018-03-11 3:42 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>>
>>> On the other hand, I think this model is harmful for the 'batteries'
>>> part - which could easily be improved by allowing external
>>> contributors.
>>
>> I use Roberto's LPeg and several of Luiz's modules: complex numbers,
>> C99 math, XML parsing etc. They are of comparable quality to Lua
>> itself and stay abreast of new releases, but they give a glimpse of
>> what Lua might have been like if developed by only that person ­— and
>> I wonder if Waldemar's unheralded role might not be to mediate between
>> two extremes.
>>
>> The key is: "of comparable quality to Lua itself ".
>>
>> We have two main battery providers: stdlib and penlight, and one
>> battery compiler: luarocks. Will lovers of the first two please stand
>> up to be counted? I use a dozen or so offerings from the third, but
>> with caution: there are often several different offerings for the same
>> task, and they come without quality certificates.
>>
>
> Sorry I don't think I explained clearly what I meant.
>
> The Lua core libraries are constrained by the need to be small,
> portable anywhere there is a C99 compiler, hence most libraries cannot
> be included in Lua standard library.
>
> However, the community needs and would benefit from an extended
> standard library that is supervised / blessed by the Lua team. All the
> Lua team have to do is:
>
> a) Create an official repository - perhaps in Github
> b) Appoint trusted leads who can manage the library - I am sure many
> people here who maintain distros or major libraries would be willing
> to help - I can think of a few names including yours.
I am allergic to anything that smacks of administration.

> c) Take part in regular reviews and decision making - maybe spend 1
> hour per fortnight in an online meeting to approve / disapprove
> decisions taken by the leads.
> d) The leads should create a shortlist of the libraries that need to
> be include - and set criteria on quality, documentation, portability
> etc., again possibly reviewed/approved by Lua team.
>
> All this can be done with very little effort from the Lua team.

In 24 years they have never been willing to canonize. Why suddenly now?

The only way to achieve am extended standard library would be for one
or two dedicated persons to say "these are the modules we personally
use regularly and we take the responsibilty for keeping them
compatible with the current Lua release from PUC-Rio". Such as you
seem to be doing with your latest effort to make libraries that you
support for Ravi available for Lua 5.3 too.

All that the Lua team need help us with is some infrastructure.

1. Agreement that a `contrib` directory in the standard distribution
is reserved for modules for an extended standard library.
2. (Optional) Seed that directory with LPeg and some of LHF's
libraries. No need to go outside the Lua team here.
3. Modifying the standard Makefile so that `make SYSTEM contrib`
builds modules in `contrib` and `make install` installs them.

Then anybody who has a module that they think is a candidate of the
extended standard library must supply it a zip, tgz etc archive, to be
extracted when in the root library of the Lua distribution, that will
build out of the box that way.

The only administration needed will be to draw up a jealously guarded
list of names of approved modules. I say "only", but this will be the
crunch.

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Marc Balmer


> Am 11.03.2018 um 15:53 schrieb Dirk Laurie <[hidden email]>:
>
> 2018-03-11 13:10 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>> On 11 March 2018 at 08:25, Dirk Laurie <[hidden email]> wrote:
>>> 2018-03-11 3:42 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>>>
>>>> On the other hand, I think this model is harmful for the 'batteries'
>>>> part - which could easily be improved by allowing external
>>>> contributors.
>>>
>>> I use Roberto's LPeg and several of Luiz's modules: complex numbers,
>>> C99 math, XML parsing etc. They are of comparable quality to Lua
>>> itself and stay abreast of new releases, but they give a glimpse of
>>> what Lua might have been like if developed by only that person ­— and
>>> I wonder if Waldemar's unheralded role might not be to mediate between
>>> two extremes.
>>>
>>> The key is: "of comparable quality to Lua itself ".
>>>
>>> We have two main battery providers: stdlib and penlight, and one
>>> battery compiler: luarocks. Will lovers of the first two please stand
>>> up to be counted? I use a dozen or so offerings from the third, but
>>> with caution: there are often several different offerings for the same
>>> task, and they come without quality certificates.
>>>
>>
>> Sorry I don't think I explained clearly what I meant.
>>
>> The Lua core libraries are constrained by the need to be small,
>> portable anywhere there is a C99 compiler, hence most libraries cannot
>> be included in Lua standard library.
>>
>> However, the community needs and would benefit from an extended
>> standard library that is supervised / blessed by the Lua team. All the
>> Lua team have to do is:
>>
>> a) Create an official repository - perhaps in Github
>> b) Appoint trusted leads who can manage the library - I am sure many
>> people here who maintain distros or major libraries would be willing
>> to help - I can think of a few names including yours.
> I am allergic to anything that smacks of administration.
>
>> c) Take part in regular reviews and decision making - maybe spend 1
>> hour per fortnight in an online meeting to approve / disapprove
>> decisions taken by the leads.
>> d) The leads should create a shortlist of the libraries that need to
>> be include - and set criteria on quality, documentation, portability
>> etc., again possibly reviewed/approved by Lua team.
>>
>> All this can be done with very little effort from the Lua team.
>
> In 24 years they have never been willing to canonize. Why suddenly now?
>
> The only way to achieve am extended standard library would be for one
> or two dedicated persons to say "these are the modules we personally
> use regularly and we take the responsibilty for keeping them
> compatible with the current Lua release from PUC-Rio". Such as you
> seem to be doing with your latest effort to make libraries that you
> support for Ravi available for Lua 5.3 too.
>
> All that the Lua team need help us with is some infrastructure.
>
> 1. Agreement that a `contrib` directory in the standard distribution
> is reserved for modules for an extended standard library.
> 2. (Optional) Seed that directory with LPeg and some of LHF's
> libraries. No need to go outside the Lua team here.
> 3. Modifying the standard Makefile so that `make SYSTEM contrib`
> builds modules in `contrib` and `make install` installs them.
>
> Then anybody who has a module that they think is a candidate of the
> extended standard library must supply it a zip, tgz etc archive, to be
> extracted when in the root library of the Lua distribution, that will
> build out of the box that way.
>
> The only administration needed will be to draw up a jealously guarded
> list of names of approved modules. I say "only", but this will be the
> crunch.

I truly love Lua the way it is.


Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Dibyendu Majumdar
In reply to this post by Dirk Laurie-2
On 11 March 2018 at 14:53, Dirk Laurie <[hidden email]> wrote:

> 2018-03-11 13:10 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>> On 11 March 2018 at 08:25, Dirk Laurie <[hidden email]> wrote:
>>> 2018-03-11 3:42 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>>>
>>>> On the other hand, I think this model is harmful for the 'batteries'
>>>> part - which could easily be improved by allowing external
>>>> contributors.
>>>
>>> I use Roberto's LPeg and several of Luiz's modules: complex numbers,
>>> C99 math, XML parsing etc. They are of comparable quality to Lua
>>> itself and stay abreast of new releases, but they give a glimpse of
>>> what Lua might have been like if developed by only that person ­— and
>>> I wonder if Waldemar's unheralded role might not be to mediate between
>>> two extremes.
>>>
>>> The key is: "of comparable quality to Lua itself ".
>>>
>>> We have two main battery providers: stdlib and penlight, and one
>>> battery compiler: luarocks. Will lovers of the first two please stand
>>> up to be counted? I use a dozen or so offerings from the third, but
>>> with caution: there are often several different offerings for the same
>>> task, and they come without quality certificates.
>>>
>>
>> Sorry I don't think I explained clearly what I meant.
>>
>> The Lua core libraries are constrained by the need to be small,
>> portable anywhere there is a C99 compiler, hence most libraries cannot
>> be included in Lua standard library.
>>
>> However, the community needs and would benefit from an extended
>> standard library that is supervised / blessed by the Lua team. All the
>> Lua team have to do is:
>>
>> a) Create an official repository - perhaps in Github
>> b) Appoint trusted leads who can manage the library - I am sure many
>> people here who maintain distros or major libraries would be willing
>> to help - I can think of a few names including yours.
> I am allergic to anything that smacks of administration.
>

If you think deciding which libraries to include, setting standards
for inclusion, testing that the libraries work, is administration then
this whole discussion is a non-starter and idle talk, as existing
distros already do the rest. My suggestion above was to avoid
burdening the Lua team but put the onus on the community leaders (who
are these?).

>> c) Take part in regular reviews and decision making - maybe spend 1
>> hour per fortnight in an online meeting to approve / disapprove
>> decisions taken by the leads.
>> d) The leads should create a shortlist of the libraries that need to
>> be include - and set criteria on quality, documentation, portability
>> etc., again possibly reviewed/approved by Lua team.
>>
>> All this can be done with very little effort from the Lua team.
>
> In 24 years they have never been willing to canonize. Why suddenly now?
>

Sure and possibly nothing will come of it as from past discussions.
But times are changing .... Lua's trajectory is flat line whereas
other languages are growing in importance. Here is a thought
experiment: what if Mike Pall had decided to not drop LuaJIT and had
decided to actually enhance the language in a different direction and
created a larger set of libraries for it. What do you think would have
happened?

> The only way to achieve am extended standard library would be for one
> or two dedicated persons to say "these are the modules we personally
> use regularly and we take the responsibilty for keeping them
> compatible with the current Lua release from PUC-Rio". Such as you
> seem to be doing with your latest effort to make libraries that you
> support for Ravi available for Lua 5.3 too.
>

I am spending a lot of time testing and fixing issues ... you need to
have this if you want a quality / reliable set of libraries.

> All that the Lua team need help us with is some infrastructure.
>
> 1. Agreement that a `contrib` directory in the standard distribution
> is reserved for modules for an extended standard library.
> 2. (Optional) Seed that directory with LPeg and some of LHF's
> libraries. No need to go outside the Lua team here.
> 3. Modifying the standard Makefile so that `make SYSTEM contrib`
> builds modules in `contrib` and `make install` installs them.
>
> Then anybody who has a module that they think is a candidate of the
> extended standard library must supply it a zip, tgz etc archive, to be
> extracted when in the root library of the Lua distribution, that will
> build out of the box that way.
>
> The only administration needed will be to draw up a jealously guarded
> list of names of approved modules. I say "only", but this will be the
> crunch.
>

I do think it needs more effort if it is to be any success.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Marc Balmer


> Am 11.03.2018 um 16:13 schrieb Dibyendu Majumdar <[hidden email]>:
>
> On 11 March 2018 at 14:53, Dirk Laurie <[hidden email]> wrote:
>> 2018-03-11 13:10 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>>> On 11 March 2018 at 08:25, Dirk Laurie <[hidden email]> wrote:
>>>> 2018-03-11 3:42 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>>>>
>>>>> On the other hand, I think this model is harmful for the 'batteries'
>>>>> part - which could easily be improved by allowing external
>>>>> contributors.
>>>>
>>>> I use Roberto's LPeg and several of Luiz's modules: complex numbers,
>>>> C99 math, XML parsing etc. They are of comparable quality to Lua
>>>> itself and stay abreast of new releases, but they give a glimpse of
>>>> what Lua might have been like if developed by only that person ­— and
>>>> I wonder if Waldemar's unheralded role might not be to mediate between
>>>> two extremes.
>>>>
>>>> The key is: "of comparable quality to Lua itself ".
>>>>
>>>> We have two main battery providers: stdlib and penlight, and one
>>>> battery compiler: luarocks. Will lovers of the first two please stand
>>>> up to be counted? I use a dozen or so offerings from the third, but
>>>> with caution: there are often several different offerings for the same
>>>> task, and they come without quality certificates.
>>>>
>>>
>>> Sorry I don't think I explained clearly what I meant.
>>>
>>> The Lua core libraries are constrained by the need to be small,
>>> portable anywhere there is a C99 compiler, hence most libraries cannot
>>> be included in Lua standard library.
>>>
>>> However, the community needs and would benefit from an extended
>>> standard library that is supervised / blessed by the Lua team. All the
>>> Lua team have to do is:
>>>
>>> a) Create an official repository - perhaps in Github
>>> b) Appoint trusted leads who can manage the library - I am sure many
>>> people here who maintain distros or major libraries would be willing
>>> to help - I can think of a few names including yours.
>> I am allergic to anything that smacks of administration.
>>
>
> If you think deciding which libraries to include, setting standards
> for inclusion, testing that the libraries work, is administration then
> this whole discussion is a non-starter and idle talk, as existing
> distros already do the rest. My suggestion above was to avoid
> burdening the Lua team but put the onus on the community leaders (who
> are these?).
>
>>> c) Take part in regular reviews and decision making - maybe spend 1
>>> hour per fortnight in an online meeting to approve / disapprove
>>> decisions taken by the leads.
>>> d) The leads should create a shortlist of the libraries that need to
>>> be include - and set criteria on quality, documentation, portability
>>> etc., again possibly reviewed/approved by Lua team.
>>>
>>> All this can be done with very little effort from the Lua team.
>>
>> In 24 years they have never been willing to canonize. Why suddenly now?
>>
>
> Sure and possibly nothing will come of it as from past discussions.
> But times are changing .... Lua's trajectory is flat line whereas
> other languages are growing in importance. Here is a thought

That is your opinion only. FUD.

> experiment: what if Mike Pall had decided to not drop LuaJIT and had
> decided to actually enhance the language in a different direction and
> created a larger set of libraries for it. What do you think would have
> happened?

What do you think would have happened if god the almighty (does he even exist?) created three sexes instead of only two?  What do you think would have happened?

>
>> The only way to achieve am extended standard library would be for one
>> or two dedicated persons to say "these are the modules we personally
>> use regularly and we take the responsibilty for keeping them
>> compatible with the current Lua release from PUC-Rio". Such as you
>> seem to be doing with your latest effort to make libraries that you
>> support for Ravi available for Lua 5.3 too.
>>
>
> I am spending a lot of time testing and fixing issues ... you need to
> have this if you want a quality / reliable set of libraries.
>
>> All that the Lua team need help us with is some infrastructure.
>>
>> 1. Agreement that a `contrib` directory in the standard distribution
>> is reserved for modules for an extended standard library.
>> 2. (Optional) Seed that directory with LPeg and some of LHF's
>> libraries. No need to go outside the Lua team here.
>> 3. Modifying the standard Makefile so that `make SYSTEM contrib`
>> builds modules in `contrib` and `make install` installs them.
>>
>> Then anybody who has a module that they think is a candidate of the
>> extended standard library must supply it a zip, tgz etc archive, to be
>> extracted when in the root library of the Lua distribution, that will
>> build out of the box that way.
>>
>> The only administration needed will be to draw up a jealously guarded
>> list of names of approved modules. I say "only", but this will be the
>> crunch.
>>
>
> I do think it needs more effort if it is to be any success.
>
> Regards
> Dibyendu


Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Russell Haley
In reply to this post by Dirk Laurie-2


On Sun, Mar 11, 2018 at 7:53 AM, Dirk Laurie <[hidden email]> wrote:
2018-03-11 13:10 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
> On 11 March 2018 at 08:25, Dirk Laurie <[hidden email]> wrote:
>> 2018-03-11 3:42 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>>
>>> On the other hand, I think this model is harmful for the 'batteries'
>>> part - which could easily be improved by allowing external
>>> contributors.
>>
>> I use Roberto's LPeg and several of Luiz's modules: complex numbers,
>> C99 math, XML parsing etc. They are of comparable quality to Lua
>> itself and stay abreast of new releases, but they give a glimpse of
>> what Lua might have been like if developed by only that person ­— and
>> I wonder if Waldemar's unheralded role might not be to mediate between
>> two extremes.
>>
>> The key is: "of comparable quality to Lua itself ".
>>
>> We have two main battery providers: stdlib and penlight, and one
>> battery compiler: luarocks. Will lovers of the first two please stand
>> up to be counted? I use a dozen or so offerings from the third, but
>> with caution: there are often several different offerings for the same
>> task, and they come without quality certificates.
>>
>
> Sorry I don't think I explained clearly what I meant.
>
> The Lua core libraries are constrained by the need to be small,
> portable anywhere there is a C99 compiler, hence most libraries cannot
> be included in Lua standard library.
>
> However, the community needs and would benefit from an extended
> standard library that is supervised / blessed by the Lua team. All the
> Lua team have to do is:
>
> a) Create an official repository - perhaps in Github
> b) Appoint trusted leads who can manage the library - I am sure many
> people here who maintain distros or major libraries would be willing
> to help - I can think of a few names including yours.
I am allergic to anything that smacks of administration.

> c) Take part in regular reviews and decision making - maybe spend 1
> hour per fortnight in an online meeting to approve / disapprove
> decisions taken by the leads.
> d) The leads should create a shortlist of the libraries that need to
> be include - and set criteria on quality, documentation, portability
> etc., again possibly reviewed/approved by Lua team.
>
> All this can be done with very little effort from the Lua team.

In 24 years they have never been willing to canonize. Why suddenly now?

The only way to achieve am extended standard library would be for one
or two dedicated persons to say "these are the modules we personally
use regularly and we take the responsibilty for keeping them
compatible with the current Lua release from PUC-Rio". Such as you
seem to be doing with your latest effort to make libraries that you
support for Ravi available for Lua 5.3 too.

All that the Lua team need help us with is some infrastructure.

1. Agreement that a `contrib` directory in the standard distribution
is reserved for modules for an extended standard library.
2. (Optional) Seed that directory with LPeg and some of LHF's
libraries. No need to go outside the Lua team here.
3. Modifying the standard Makefile so that `make SYSTEM contrib`
builds modules in `contrib` and `make install` installs them.

Then anybody who has a module that they think is a candidate of the
extended standard library must supply it a zip, tgz etc archive, to be
extracted when in the root library of the Lua distribution, that will
build out of the box that way.

The only administration needed will be to draw up a jealously guarded
list of names of approved modules. I say "only", but this will be the
crunch.


Josh Jensen has already created a very complete "batteries included" distribution called LuaPlus. I think suggesting we all help maintain that project will collapse as quickly as any other suggestion for one reason: we all want a say but we don't want to do the work. 

I think no matter what solution is provided by the community, the nature of Lua means there will never be a standard. However, a foundation that maintains documentation and infrastructure and a means for duty rotation could keep fresh blood in the maintainer queue and provide consistency for projects chosen by said foundation. 99% of what is needed already exists in the Lua wiki users and various projects like LuaBuild, LuaDist, LuaRocks and LuaPlus. I wonder out loud if the Kepler project could be re-tooled as such a project?

I think recipes lists are better than hard fast rules and standard distributions[1]. New users can then review a project description and the tools the author used to create said project. Build instructions could be provided and projects that fall out of line with Lua revisions can be removed. Successful patterns can then be easily deduced by new users.

I'd be willing to help on the setup and documentation of such a foundation-type organization if there is actual interest. 

Russ

[1] That said, I am attempting to make tooling a little easier on Windows via WinLua and MSI installers. The roadmap is here: https://github.com/WinLua/bin/wiki/Project-Roadmap and includes a binary distribution of Lua, LuaPlus and .Net integration components. 
Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Dirk Laurie-2
2018-03-11 18:23 GMT+02:00 Russell Haley <[hidden email]>:

> Josh Jensen has already created a very complete "batteries included"
> distribution called LuaPlus.

Does it work for Lua 5.3 under Linux?

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Russell Haley
Sorry for the top post,

LuaPlus uses a build system called JamPlus to generate the buildable files, but I've thus far only been interested in generating the VS solution. 

I'm hoping Josh will pipe up shortly.
‎Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Dirk Laurie
Sent: Sunday, March 11, 2018 10:25 AM
To: Lua mailing list
Reply To: Lua mailing list
Subject: Re: Batteries

2018-03-11 18:23 GMT+02:00 Russell Haley <[hidden email]>:

> Josh Jensen has already created a very complete "batteries included"
> distribution called LuaPlus.

Does it work for Lua 5.3 under Linux?


Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Gregg Reynolds-2
In reply to this post by Marc Balmer


On Mar 11, 2018 10:08 AM, "Marc Balmer" <[hidden email]> wrote:
...
I truly love Lua the way it is.

+2

Someday the main perpetrators will no longer be with us. But Lua will live on, no matter what the inheritors do, so long as it answers to a need, which it does.  If you doubt that just look at cobol: "COBOL still accounts for more than 70 percent of the business transactions that take place in the world today."

.
World domination is not an appropriate goal for a programming language. Where Lua ranks in this or that list of most "important" languages is totally irrelevant, IMHO. Lua offers stuff no other language ecosystem offers, for many use-cases. You use it because it solves your problem, not because it has a fancy lib ecosystem.  Having such a system might help Lua become more mainstream, but who cares? That's not the point of Lua, IMHO.

Otoh, we have languages like Rexx. NetRexx was the first non-java language to target the jvm, but today nobody has even heard of it, mostly. It's a shame, because it's a gorgeous language. Like Lua. Why is it moribund while Lua is vigorous? I think it's about more than the language. Lua's easy integration with c etc. is the real killer app.
Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Dibyendu Majumdar
On 11 March 2018 at 20:21, Gregg Reynolds <[hidden email]> wrote:

>
>
> On Mar 11, 2018 10:08 AM, "Marc Balmer" <[hidden email]> wrote:
> ...
>
> I truly love Lua the way it is.
>
>
> +2
>

Problem is you misunderstand the proposal. Nobody is taking anything
away. The proposal is to have an extended library outside of Lua that
is 'blessed' by the Lua team, and managed by community leaders. Are
you still objecting to this?

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Gregg Reynolds-2


On Sun, Mar 11, 2018 at 4:03 PM, Dibyendu Majumdar <[hidden email]> wrote:
On 11 March 2018 at 20:21, Gregg Reynolds <[hidden email]> wrote:
>
>
> On Mar 11, 2018 10:08 AM, "Marc Balmer" <[hidden email]> wrote:
> ...
>
> I truly love Lua the way it is.
>
>
> +2
>

Problem is you misunderstand the proposal. Nobody is taking anything
away. The proposal is to have an extended library outside of Lua that
is 'blessed' by the Lua team, and managed by community leaders. Are
you still objecting to this?

No. Make it happen, good luck. But it need not be "blessed" by anybody. 

Regards


Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Sean Conner
In reply to this post by Dirk Laurie-2
It was thus said that the Great Dirk Laurie once stated:
> 2018-03-11 18:23 GMT+02:00 Russell Haley <[hidden email]>:
>
> > Josh Jensen has already created a very complete "batteries included"
> > distribution called LuaPlus.
>
> Does it work for Lua 5.3 under Linux?

  This seems to be the repository: https://github.com/jjensen/luaplus51-all
and I don't see mention of Lua 5.2 or higher.  Also, there isn't much
description about what LuaPlus actually offers.  The code seems to be 50% C
and 50% C++ with a seemingly scary amount of IDE specific files.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Russell Haley
https://github.com/jjensen/luaplus51-all/tree/master/Src/LuaPlus/lua53/src

The ide stuff is generated. The readme discusses setting up Linux and Mac environments. ‎It's the list of modules that excites me. He's got a really good cross section of components (IMHO). 

Regardless of shortcomings that may exist, it's a batteries included Lua that many of us could probably settle on. ‎I intend to find out asap. 

Cheers,
Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Sean Conner
Sent: Sunday, March 11, 2018 5:54 PM
To: Lua mailing list
Reply To: Lua mailing list
Subject: Re: Batteries

It was thus said that the Great Dirk Laurie once stated:
> 2018-03-11 18:23 GMT+02:00 Russell Haley <[hidden email]>:
>
> > Josh Jensen has already created a very complete "batteries included"
> > distribution called LuaPlus.
>
> Does it work for Lua 5.3 under Linux?

This seems to be the repository: https://github.com/jjensen/luaplus51-all
and I don't see mention of Lua 5.2 or higher. Also, there isn't much
description about what LuaPlus actually offers. The code seems to be 50% C
and 50% C++ with a seemingly scary amount of IDE specific files.

-spc



Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Dirk Laurie-2
In reply to this post by Dibyendu Majumdar
2018-03-11 23:03 GMT+02:00 Dibyendu Majumdar <[hidden email]>:

> On 11 March 2018 at 20:21, Gregg Reynolds <[hidden email]> wrote:
>>
>>
>> On Mar 11, 2018 10:08 AM, "Marc Balmer" <[hidden email]> wrote:
>> ...
>>
>> I truly love Lua the way it is.
>>
>>
>> +2
>>
>
> Problem is you misunderstand the proposal. Nobody is taking anything
> away. The proposal is to have an extended library outside of Lua that
> is 'blessed' by the Lua team, and managed by community leaders. Are
> you still objecting to this?

And who are those community leaders? You may find "able", you may find
"willing", but you are not going to find "able and willing".

The "blessed by the Lua team" bit is not going to fly, any more than
Donald Knuth blessed LaTeX or ConTeXt. [1] They provide a lean and
lithe Lua that runs on any platform, and that last bit is more than
you can say about almost any other language of comparable power. It's
quite enough for one three-man team doing a labour of love. [2]

That extended library will also have to run on any platform. That's
why I suggested an acid test: it has to build not with its own snazzy
Makefile while perched on its own rock, but in the same environment
that the minimal standard library builds in.

One other thing: we do NOT want C libraries disguised as Lua code.
Bindings that refer you to the docs of Debian package libbullshit etc.
That's my problem with many of these so-called batteries on LuaRocks.
Even lcurl, which I use a lot. How on earth can you expect people who
design Lua not to be disgusted by a bloated interface like that?

[1] He said kind words about LaTeX but himself never used it.
Actually, LuaTeX is a good example of a "batteries included" Lua.
[2] Speaking of Love, that too is quite a nice little
batteries-included Lua. Like LuaTex, no interactive interpreter
supplied. Makes one think …

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Sean Conner
It was thus said that the Great Dirk Laurie once stated:
>
> One other thing: we do NOT want C libraries disguised as Lua code.
> Bindings that refer you to the docs of Debian package libbullshit etc.

  That's not a popular opinion (thread starts here):

        http://lua-users.org/lists/lua-l/2015-03/msg00001.html

  It seems quite a few people do the "thin layer that mimics C" but never
get around to the "Luaish API that makes it easy to use".

  -spc (We both agree, however ... )


Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Dirk Laurie-2
2018-03-12 10:06 GMT+02:00 Sean Conner <[hidden email]>:

> It was thus said that the Great Dirk Laurie once stated:
>>
>> One other thing: we do NOT want C libraries disguised as Lua code.
>> Bindings that refer you to the docs of Debian package libbullshit etc.
>
>   That's not a popular opinion (thread starts here):
>
>         http://lua-users.org/lists/lua-l/2015-03/msg00001.html
>
>   It seems quite a few people do the "thin layer that mimics C" but never
> get around to the "Luaish API that makes it easy to use".
>
>   -spc (We both agree, however ... )

Not popular? The thread ends with Roberto's saying:

I am all in favor of "Luarizing" APIs. (PiL has an example where first
it builds an API for opendir/readdir/closedir, then it repacks them in
a single iterator function to traverse directories.)

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

pocomane
In reply to this post by Dibyendu Majumdar
On Sun, Mar 11, 2018 at 12:10 PM, Dibyendu Majumdar
<[hidden email]> wrote:
> However, the community needs and would benefit from an extended
> standard library that is supervised / blessed by the Lua team. All the
> Lua team have to do is:

Also for me the best way to go is the "Blessing" one. I am aware that
probably it will never happen, however, here there is my motivation.

Lua as extension language is perfect as it is, but as extendible
language it needs a bigger standard library. It is a popularity issue
also, but not to "Dominate the world". I want to be able to use lua in
more and more projects. I just want be able to propose lua to my
collegues, but:
1) For small tools people do not want to "Manage their own modules
distribution" (MTOMD).
2) For bigger application people accept to MTOMD but they want a
library for everything.
3) "Lua? What is it?"

The "Blessing" way is the only one I see to handle the point 1 while
keeping the features I love about lua (mainly resumable with the term
"Simplicity"). For the point 2 I thing no solution there will be till
lua (re)-gains popularity.

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Joshua Jensen-2
In reply to this post by Sean Conner
Sean Conner wrote on 3/11/2018 6:54 PM:

> It was thus said that the Great Dirk Laurie once stated:
>> 2018-03-11 18:23 GMT+02:00 Russell Haley <[hidden email]>:
>>
>>> Josh Jensen has already created a very complete "batteries included"
>>> distribution called LuaPlus.
>> Does it work for Lua 5.3 under Linux?
>    This seems to be the repository: https://github.com/jjensen/luaplus51-all
> and I don't see mention of Lua 5.2 or higher.  Also, there isn't much
> description about what LuaPlus actually offers.  The code seems to be 50% C
> and 50% C++ with a seemingly scary amount of IDE specific files.
Yes, LuaPlus has Lua 5.3 working under Linux. Or, at least, it is
working fine under Ubuntu 16.04 and Ubuntu 17.10, the last two versions
I tested against, Ubuntu 17.10 being just last night.

I do not know what you are referring to as a scary amount of IDE
specific files. Would you care to elaborate? I also don't know what 50%
C and 50% C++ has to do with anything.

Thanks.

Josh

Reply | Threaded
Open this post in threaded view
|

Re: Batteries

Russell Haley
In reply to this post by Dirk Laurie-2


On Sun, Mar 11, 2018 at 10:30 PM, Dirk Laurie <[hidden email]> wrote:
2018-03-11 23:03 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
> On 11 March 2018 at 20:21, Gregg Reynolds <[hidden email]> wrote:
>>
>>
>> On Mar 11, 2018 10:08 AM, "Marc Balmer" <[hidden email]> wrote:
>> ...
>>
>> I truly love Lua the way it is.
>>
>>
>> +2
>>
>
> Problem is you misunderstand the proposal. Nobody is taking anything
> away. The proposal is to have an extended library outside of Lua that
> is 'blessed' by the Lua team, and managed by community leaders. Are
> you still objecting to this?

And who are those community leaders? You may find "able", you may find
"willing", but you are not going to find "able and willing".

The "blessed by the Lua team" bit is not going to fly, any more than
Donald Knuth blessed LaTeX or ConTeXt. [1] They provide a lean and
lithe Lua that runs on any platform, and that last bit is more than
you can say about almost any other language of comparable power. It's
quite enough for one three-man team doing a labour of love. [2]

That extended library will also have to run on any platform. That's
why I suggested an acid test: it has to build not with its own snazzy
Makefile while perched on its own rock, but in the same environment
that the minimal standard library builds in.

One other thing: we do NOT want C libraries disguised as Lua code.
Bindings that refer you to the docs of Debian package libbullshit etc.
That's my problem with many of these so-called batteries on LuaRocks.
Even lcurl, which I use a lot. How on earth can you expect people who
design Lua not to be disgusted by a bloated interface like that?

[1] He said kind words about LaTeX but himself never used it.
Actually, LuaTeX is a good example of a "batteries included" Lua.
[2] Speaking of Love, that too is quite a nice little
batteries-included Lua. Like LuaTex, no interactive interpreter
supplied. Makes one think …

(This is meant in fun)

Good news everyone![1] Dirk and Sean have identified themselves as "able" to provide concrete design criticism for a standard library! I have created a StdLuaLib github organization and invited them to join. Now, if they would be kind enough to provide requirements and use cases, those of us that are "willing" can start contributing. I would conjecture that every single new-ish Lua user would be very eager to provide code to such a library if sound direction were provided. The core Lua Team may even have few lines of code they'd be willing to contribute.

If I see no activity in the next 30 days, I'll re-direct the main repository to Penlight. :P

(Ouch, ouch! Stop throwing things at me! tee hee)

Cheers,
Russ

123