Breakthrough dream

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

Breakthrough dream

Rodrigo Azevedo
Based on the thread 'Selenophobia', and your major experience, choose 5 characteristics you think indispensable to keep Lua advancing as a "general-purpose script language";

1) an expanded basic library (some batteries), well organized, maintained and documented. "Pure Lua" libraries at least.
2) easy installation on major operating systems (with shared libraries)
3) threads (pthreads!? not Lua's coroutine)
4) optional type annotations (performance, error check etc)
5) easy, transparent, way to port libraries to new versions of Lua.

Is this possible to start, organize and support for a long period ( a 'larger' community)?

Or Lua's community is so specialized, and happy, like the 'webdevs' of stackoverflow, that this is not possible in a foreseen future?

and consequently the 'general-purpose script language' is an utopic, romantic, dream.


--
Rodrigo Azevedo Moreira da Silva
Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Peter Aronoff
Rodrigo Azevedo <[hidden email]> wrote:
> 1) an expanded basic library (some batteries), well organized, maintained
>    and documented. "Pure Lua" libraries at least.

Just curious: why must (or should) they be “pure Lua”? Don’t many
mainstream programming languages (e.g. Perl, Python, Ruby) write at least
some of their batteries (i.e., built-in stdlib components) in the language
of the language interpreter itself (i.e., usually C)? Why does it matter to
the scripter whether, say, a map function is written in Lua or C?

P
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Rodrigo Azevedo
This is not an exclusion, but C libraries are harder to maintain than "Pure Lua". Then, "Pure Lua" is *better than nothing*, but C library is OK also, obviously.


2017-03-25 10:42 GMT-03:00 Peter Aronoff <[hidden email]>:
Rodrigo Azevedo <[hidden email]> wrote:
> 1) an expanded basic library (some batteries), well organized, maintained
>    and documented. "Pure Lua" libraries at least.

Just curious: why must (or should) they be “pure Lua”? Don’t many
mainstream programming languages (e.g. Perl, Python, Ruby) write at least
some of their batteries (i.e., built-in stdlib components) in the language
of the language interpreter itself (i.e., usually C)? Why does it matter to
the scripter whether, say, a map function is written in Lua or C?

P
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System




--
Rodrigo Azevedo Moreira da Silva
Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Peter Aronoff
Rodrigo Azevedo <[hidden email]> wrote:
> This is not an exclusion, but C libraries are harder to maintain than "Pure
> Lua".

I’m going to sound like a broken record, but really? Why? I’ve never
thought of it as being the case—again from experience with other languages.

What I have seen is that *any* library in a language’s stdlib often ends up
being maintained more slowly, and less well, than non-stdlib equivalents.
In fact, in both Perl and Ruby, people often joke that stdlib is where good
libraries go to die. I’m not sure entirely why that is, but I suspect it
has to do with the politics and complexities of being part of the official
package of a language. I’ve read similar things re Python, but that’s not
a language I know as well personally.

P
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Rodrigo Azevedo
>> This is not an exclusion, but C libraries are harder to maintain than "Pure
>> Lua".
>
> I’m going to sound like a broken record, but really? Why? I’ve never
> thought of it as being the case—again from experience with other languages.
>
> What I have seen is that *any* library in a language’s stdlib often ends up
> being maintained more slowly, and less well, than non-stdlib equivalents.
> In fact, in both Perl and Ruby, people often joke that stdlib is where good
> libraries go to die. I’m not sure entirely why that is, but I suspect it

Lua does not have even a well organized necropolis;

## JOKE ##
Ex: if you try to find the bones of Mr. JSON you will be completely lost.
## JOKE ##

Namely, one where we can quickly find a reference implementation of a
given set of useful functions, not necessarily the 'best' or the
'fast'  but the one that simple solve the problem for a while.

> has to do with the politics and complexities of being part of the official
> package of a language. I’ve read similar things re Python, but that’s not
> a language I know as well personally.

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Marc Balmer
In reply to this post by Rodrigo Azevedo

I am (very) happt with Lua as it is.


Am 25.03.17 um 14:04 schrieb Rodrigo Azevedo:
Based on the thread 'Selenophobia', and your major experience, choose 5 characteristics you think indispensable to keep Lua advancing as a "general-purpose script language";

1) an expanded basic library (some batteries), well organized, maintained and documented. "Pure Lua" libraries at least.
2) easy installation on major operating systems (with shared libraries)
3) threads (pthreads!? not Lua's coroutine)
4) optional type annotations (performance, error check etc)
5) easy, transparent, way to port libraries to new versions of Lua.
Please, no.

Is this possible to start, organize and support for a long period ( a 'larger' community)?

Or Lua's community is so specialized, and happy, like the 'webdevs' of stackoverflow, that this is not possible in a foreseen future?

and consequently the 'general-purpose script language' is an utopic, romantic, dream.


--
Rodrigo Azevedo Moreira da Silva

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Dirk Laurie-2
In reply to this post by Rodrigo Azevedo
2017-03-25 15:04 GMT+02:00 Rodrigo Azevedo <[hidden email]>:

> Based on the thread 'Selenophobia', and your major experience, choose 5
> characteristics you think indispensable to keep Lua advancing as a
> "general-purpose script language";
>
> 1) an expanded basic library (some batteries), well organized, maintained
> and documented. "Pure Lua" libraries at least.
> 2) easy installation on major operating systems (with shared libraries)
> 3) threads (pthreads!? not Lua's coroutine)
> 4) optional type annotations (performance, error check etc)
> 5) easy, transparent, way to port libraries to new versions of Lua.
>
> Is this possible to start, organize and support for a long period ( a
> 'larger' community)?

This does sound a bit like someone who wishes to enlarge the listening
public of a radio station that broadcasts classical music, and comes
with suggestions like:

* breezy disc jockeys
* short, snappy pieces instead of those interminable symphonies
* phone-in discussion programmes
* jazz is fine music too, isn't it?

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Egor Skriptunoff-2
On Sat, Mar 25, 2017 at 10:26 PM, Dirk Laurie wrote:
2017-03-25 15:04 GMT+02:00 Rodrigo Azevedo:

> Based on the thread 'Selenophobia', and your major experience, choose 5
> characteristics you think indispensable to keep Lua advancing as a
> "general-purpose script language";
>
> 1) an expanded basic library (some batteries), well organized, maintained
> and documented. "Pure Lua" libraries at least.
> 2) easy installation on major operating systems (with shared libraries)
> 3) threads (pthreads!? not Lua's coroutine)
> 4) optional type annotations (performance, error check etc)
> 5) easy, transparent, way to port libraries to new versions of Lua.
>
> Is this possible to start, organize and support for a long period ( a
> 'larger' community)?

This does sound a bit like someone who wishes to enlarge the listening
public of a radio station that broadcasts classical music, and comes
with suggestions like:

* breezy disc jockeys
* short, snappy pieces instead of those interminable symphonies
* phone-in discussion programmes
* jazz is fine music too, isn't it?


The analogy with classical music is very incorrect.
All 5 characteristics being discussed here would be useful for all Lua users.
They are not contradictory to set of features we already have in the language.
Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Florian Weimer
* Egor Skriptunoff:

>> > 1) an expanded basic library (some batteries), well organized,
>> > maintained
>> > and documented. "Pure Lua" libraries at least.
>> > 2) easy installation on major operating systems (with shared libraries)
>> > 3) threads (pthreads!? not Lua's coroutine)
>> > 4) optional type annotations (performance, error check etc)
>> > 5) easy, transparent, way to port libraries to new versions of Lua.
>> >

> All 5 characteristics being discussed here would be useful for all Lua
> users.

(1) and (3) would make it more difficult to embed and ship Lua
implementations.  For example, RPM itself is not thread-safe, so why
should it expose threads to Lua scripts?

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Martin
In reply to this post by Egor Skriptunoff-2


On 03/25/2017 12:54 PM, Egor Skriptunoff wrote:

> On Sat, Mar 25, 2017 at 10:26 PM, Dirk Laurie wrote:
>
>     2017-03-25 15:04 GMT+02:00 Rodrigo Azevedo:
>
>     > Based on the thread 'Selenophobia', and your major experience, choose 5
>     > characteristics you think indispensable to keep Lua advancing as a
>     > "general-purpose script language";
>     >
>     > 1) an expanded basic library (some batteries), well organized, maintained
>     > and documented. "Pure Lua" libraries at least.
>     > 2) easy installation on major operating systems (with shared libraries)
>     > 3) threads (pthreads!? not Lua's coroutine)
>     > 4) optional type annotations (performance, error check etc)
>     > 5) easy, transparent, way to port libraries to new versions of Lua.
>     >
>     > Is this possible to start, organize and support for a long period ( a
>     > 'larger' community)?
>
>     This does sound a bit like someone who wishes to enlarge the listening
>     public of a radio station that broadcasts classical music, and comes
>     with suggestions like:
>
>     * breezy disc jockeys
>     * short, snappy pieces instead of those interminable symphonies
>     * phone-in discussion programmes
>     * jazz is fine music too, isn't it?
>
>
> The analogy with classical music is very incorrect.
> All 5 characteristics being discussed here wouldbe useful for all Lua users.
> They are not contradictory to set of features we already have in the
> language.

Anyway I enjoyed by Dirk's messages. Great style and humour (imo). And
rare perk of feeling unobvious analogies.

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Tim Hill
In reply to this post by Dirk Laurie-2

> On Mar 25, 2017, at 12:26 PM, Dirk Laurie <[hidden email]> wrote:
>
> 2017-03-25 15:04 GMT+02:00 Rodrigo Azevedo <[hidden email]>:
>
>> Based on the thread 'Selenophobia', and your major experience, choose 5
>> characteristics you think indispensable to keep Lua advancing as a
>> "general-purpose script language";
>>
>> 1) an expanded basic library (some batteries), well organized, maintained
>> and documented. "Pure Lua" libraries at least.
>> 2) easy installation on major operating systems (with shared libraries)
>> 3) threads (pthreads!? not Lua's coroutine)
>> 4) optional type annotations (performance, error check etc)
>> 5) easy, transparent, way to port libraries to new versions of Lua.
>>
>> Is this possible to start, organize and support for a long period ( a
>> 'larger' community)?
>
> This does sound a bit like someone who wishes to enlarge the listening
> public of a radio station that broadcasts classical music, and comes
> with suggestions like:
>
> * breezy disc jockeys
> * short, snappy pieces instead of those interminable symphonies
> * phone-in discussion programmes
> * jazz is fine music too, isn't it?
>

That’s not really a fair analogy .. it would apply if people where suggesting drastic changes to the language itself. They are not. They are doing something much more akin to suggesting adding another aisle to the grocery store for ready-to-eat meals for those people who don’t want to cook from scratch every day. (Though btw I also despise the dilution of classical music stations in the manner you note.)

Their point is a practical and valid one. Using Lua in any large production programming project is a complex business (I speak from experience). Getting Lua compiled and integrated is trivial. Extending it with the necessary support libraries is VERY non-trivial. More so, i think, than the maintainers of Lua realize. We devoted a full 5+ man-years building out the necessary libraries and support to get to the point where we could deploy Lua in our systems.

—Tim






Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Duane Leslie
In reply to this post by Rodrigo Azevedo
On 26 Mar 2017, at 06:54, Egor Skriptunoff <[hidden email]> wrote:

On Sat, Mar 25, 2017 at 10:26 PM, Dirk Laurie wrote:
2017-03-25 15:04 GMT+02:00 Rodrigo Azevedo:

> Based on the thread 'Selenophobia', and your major experience, choose 5
> characteristics you think indispensable to keep Lua advancing as a
> "general-purpose script language";
>
> 1) an expanded basic library (some batteries), well organized, maintained
> and documented. "Pure Lua" libraries at least.
> 2) easy installation on major operating systems (with shared libraries)
> 3) threads (pthreads!? not Lua's coroutine)
> 4) optional type annotations (performance, error check etc)
> 5) easy, transparent, way to port libraries to new versions of Lua.
>
> Is this possible to start, organize and support for a long period ( a
> 'larger' community)?

This does sound a bit like someone who wishes to enlarge the listening
public of a radio station that broadcasts classical music, and comes
with suggestions like:

* breezy disc jockeys
* short, snappy pieces instead of those interminable symphonies
* phone-in discussion programmes
* jazz is fine music too, isn't it?


The analogy with classical music is very incorrect.
All 5 characteristics being discussed here would be useful for all Lua users.
They are not contradictory to set of features we already have in the language.

All of these extra things have costs that I am not willing to pay, especially (1) and (3).  I think it would help to make the distinction between the language runtime and a distribution.  I think the runtime should stay as it is because it is small and easy to embed in other programs.

Distributions are another matter, and should come Batteries-Included.  I enjoy playing around with Codea on my iPad, and Löve on my laptop, and I'm all in favour of people making more of these or supporting the existing ones.  I think the distinction here is between the Linux kernel and the distributions like Ubuntu, RedHat, etc.  This would solve (1) and (2) without any change to Lua.

Under no circumstances should threads ever be added to the Lua runtime.  It would essentially make the runtime un-embeddable.  The only real use I can think of for threads is Workers, and this should be a library.  This addresses (3).

Type annotations and optimisations would make the embedded compiler too large.  I think there is certainly merit in having an optimising compiler as a separate project, and it would be nice if it was supported by the core Lua team, but obviously they have their own priorities.  Essentially, we need a llvm compiler that takes Lua Source and outputs Lua ByteCode.  The only cooperation required from the core Lua team would be an agreement on some syntax that can be used for annotations which would be ignored by the embedded compiler.  This could be a marked up comment, but it would be nicer to have something separate.  I have some small annotations I use with a modified compiler and I use '<anno>'.  This could then integrate with LuaCheck and some DBC mechanism as well.  This solves (4).

I've got nothing for (5).  The looseness of version compatibility and the prevalence of undefined behaviour makes this almost impossible to solve at this stage in any strict way.

So, apart from agreed syntax for annotations, I think everything else should be solved by the community and not involve changes to the core language.

Regards,

Duane.
Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Sean Conner
In reply to this post by Rodrigo Azevedo
It was thus said that the Great Rodrigo Azevedo once stated:
> Based on the thread 'Selenophobia', and your major experience, choose 5
> characteristics you think indispensable to keep Lua advancing as a
> "general-purpose script language";

  0) Port LuaJIT to Lua 5.3.  That alone would probably solve most of the
     issues.  I think Mike Pall did a too good of a job with LuaJIT and it's
     probably the biggest reason for the continued use of Lua 5.1

> 1) an expanded basic library (some batteries), well organized, maintained
> and documented. "Pure Lua" libraries at least.

  Aren't there a few projects out there doing this already?

> 2) easy installation on major operating systems (with shared libraries)

  Easy installation on Windows.  FTFY.

> 3) threads (pthreads!? not Lua's coroutine)

  No.  Lua can support threads (you just need to implement lua_lock() and
lua_unlock()) but if you do that, you'll end up with a Lua that's about as
fast as Python or Ruby.  

> 4) optional type annotations (performance, error check etc)

  I know of at least one variation on Lua that does this, Ravi.

> 5) easy, transparent, way to port libraries to new versions of Lua.

  Given the slow release rate of Lua, I don't think this is as much of a
concern.  But it might be nice if LuaRocks (CLI tool and website) had an
easy way to restrict searches to modules of a particular version of Lua
(5.1, LuaJIT, 5.2, 5.3)

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Sean Conner
In reply to this post by Duane Leslie
It was thus said that the Great Duane Leslie once stated:

>
> Type annotations and optimisations would make the embedded compiler too
> large.  I think there is certainly merit in having an optimising compiler
> as a separate project, and it would be nice if it was supported by the
> core Lua team, but obviously they have their own priorities.  Essentially,
> we need a llvm compiler that takes Lua Source and outputs Lua ByteCode.
> The only cooperation required from the core Lua team would be an agreement
> on some syntax that can be used for annotations which would be ignored by
> the embedded compiler.  This could be a marked up comment, but it would be
> nicer to have something separate.  I have some small annotations I use
> with a modified compiler and I use '<anno>'.  This could then integrate
> with LuaCheck and some DBC mechanism as well.  This solves (4).

  Okay.  I'll assume that Lua supports annotations, but ignores them.  Any
text between (and including) '@' is ignored.  Other tools could make use
such text.  Code might look like (pulling from some code I'm currently
working on):

        local function dis_fault(
                @type: userdata@ @luacheck: ignore 212@ dis,
                @type: integer@  @luacheck: ignore 212@ fault
        )
          -- XXX to be done
        end

  It could be done now:

        local function dis_fault(
                --[[ type: userdata ]] --[[ luacheck: ignore 212 ]] dis,
                --[[ type: integer ]]  --[[ luacheck: ignore 212 ]] fault
        )
          -- XXX to be done
        end

  I'm ambivalent.  I mean, this just means that '@...@' is another form of
comment and given that Lua will ignore it, I'm not sure if it serves the
proper role.  I'm thinking that the inline block comments is good enough.
But I'm ambivalent enough to give this a +0.5.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Frank Kastenholz-2
In reply to this post by Egor Skriptunoff-2
On 3/25/17 3:54 PM, Egor Skriptunoff wrote:

> On Sat, Mar 25, 2017 at 10:26 PM, Dirk Laurie wrote:
>
>     2017-03-25 15:04 GMT+02:00 Rodrigo Azevedo:
>
>     > Based on the thread 'Selenophobia', and your major experience, choose 5
>     > characteristics you think indispensable to keep Lua advancing as a
>     > "general-purpose script language";
>     >
>     > 1) an expanded basic library (some batteries), well organized, maintained
>     > and documented. "Pure Lua" libraries at least.
>     > 2) easy installation on major operating systems (with shared libraries)
>     > 3) threads (pthreads!? not Lua's coroutine)
>     > 4) optional type annotations (performance, error check etc)
>     > 5) easy, transparent, way to port libraries to new versions of Lua.
>     >
>     > Is this possible to start, organize and support for a long period ( a
>     > 'larger' community)?
>
>     This does sound a bit like someone who wishes to enlarge the listening
>     public of a radio station that broadcasts classical music, and comes
>     with suggestions like:
>
>     * breezy disc jockeys
>     * short, snappy pieces instead of those interminable symphonies
>     * phone-in discussion programmes
>     * jazz is fine music too, isn't it?
>
>
> The analogy with classical music is very incorrect.
> All 5 characteristics being discussed here wouldbe useful for all Lua users.
> They are not contradictory to set of features we already have in the
> language.


These particular changes _could_ be problematic.  The project I was on
developed an application environment, with apps coded in Lua, that runs
on a variety of platforms -- different processors and operating systems
and varying levels of resources.  On some systems we had 250MHz
cpu speeds, <10MB RAM for our part of the system, and the OS was not
Windows or a flavor of Unix.  Anything that would expand the footprint
of the core PUC-Rio Lua (larger libraries, type checking in the
compiler, etc) would be a problem. Similarly, anything that ties Lua
to a specific OS (or family) would be very bad.

That said,

1) What would be reasonable would be to make these sorts of
    features truly optional, selectable by #defines in something
    like "lua_features.h".  I would not want to have to go through
    all the source code unwinding things to pull out some features.

2) Despite what this list would like, Lua will never replace, or even
    come close to equating, Python or sh or ... as scripting languages.
    The others are too embedded in the world's mindset.  Lua's
    real strength is that it can easily be installed in some other
    program, giving that program scripting/config/etc-ability. That is
    its market niche. I would _strongly_ urge that the PUC-Rio folks
    never risk losing that niche as the consider new functions/features
    to add.

Frank Kastenholz








Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Luiz Henrique de Figueiredo
In reply to this post by Sean Conner
>
>   0) Port LuaJIT to Lua 5.3.  That alone would probably solve most of the
>      issues.

I'd love to see this or at least a fork of LuaJIT that tries to keep up
with current Lua. I don't know how hard that would be.

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Vadim A. Misbakh-Soloviov
> I'd love to see this or at least a fork of LuaJIT that tries to keep up
> with current Lua. I don't know how hard that would be.

Actually, even existing one have flags to enable some things from 5.2 and 5.3.
But AFAIRC, argumention for keeping 5.1 api was "most production software
still using 5.1, so moving A{P,B}I can brake it all", ot something like that.

Although, last time I saw that question in their ML was long time ago.
So, if somebody from this list will create there a thread about this issue, we
can look about current LJ team mood about that.

// Although, I guess, answer would be something like "Default A{B,P}I will
still be 5.1, but we're working on porting features from 5.2/5.3".

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Pierre Chapuis
In reply to this post by Luiz Henrique de Figueiredo
March 26, 2017 5:26 PM, "Luiz Henrique de Figueiredo" <[hidden email]> wrote:

>> 0) Port LuaJIT to Lua 5.3. That alone would probably solve most of the
>> issues.
>
> I'd love to see this or at least a fork of LuaJIT that tries to keep up
> with current Lua. I don't know how hard that would be.


+1. It would not even need the JIT. Even a port of the JIT *interpreter*
would be awesome.

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Pierre Chapuis
In reply to this post by Rodrigo Azevedo
March 25, 2017 2:05 PM, "Rodrigo Azevedo" <[hidden email]> wrote:

> 1) an expanded basic library (some batteries), well organized, maintained and documented. "Pure
> Lua" libraries at least.

I agree that we need an organized and well-maintained collection
of pure Lua libraries. I don't think that collection should be
part of the Lua project.

Pure Lua libraries cannot do everything on their own though,
since Lua does not have the required I/O facilities. We need
ways to do two things: network I/O and filesystem manipulation.
Almost anything else can be built on top of that in pure Lua.

There are two approaches to that: low-level libraries such
as luaposix and winapi, or cross-platform libraries like
LuaFilesystem and LuaSocket. I am slightly more in favor of
the second approach.

Slightly related: I wish the standard I/O library would
support Unicode filenames on Windows. I have to patch it
in basically all my professional projects using Lua.

> 2) easy installation on major operating systems (with shared libraries)

Lua is already pretty easy to install everywhere except on
Windows. Because I/O is not standard today, a lot of modules
have C parts so I don't think a Lua development setup without
a C compiler is realistic. There are plenty of solutions that
are not so complicated (MinGW + luawinmulti, the Linux
subsystem, msys2...) but maybe we need something that installs
a local mingw + Lua + LuaRocks with a graphical installer to
satisfy some category of users.

> 3) threads (pthreads!? not Lua's coroutine)

Threads is also something that cannot be done in pure Lua.
I would not be against a standard library for threads,
now the API is not easy to define. I like something like
LuaProc personally. At work we have a pretty good library
to run and manage concurrent Lua processes, sadly we are
not able to open source it as of now.

In any case it should be a library, not a part of the
core language, and remain optional.

> 4) optional type annotations (performance, error check etc)

I know a lot of people in the community like that approach.
Personally, I don't. I like Lua as a simple dynamic language.
Maybe type annotations for functions, especially functions
exported by modules, but I feel this belongs more in something
like LuaCheck than Lua per se.

> 5) easy, transparent, way to port libraries to new versions of Lua.

Something like the lua-compat-* modules?

https://github.com/keplerproject/lua-compat-5.3

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Enrico Colombini
On 27-Mar-17 10:46, Pierre Chapuis wrote:

>> 2) easy installation on major operating systems (with shared libraries)
>
> Lua is already pretty easy to install everywhere except on
> Windows. Because I/O is not standard today, a lot of modules
> have C parts so I don't think a Lua development setup without
> a C compiler is realistic. There are plenty of solutions that
> are not so complicated (MinGW + luawinmulti, the Linux
> subsystem, msys2...) but maybe we need something that installs
> a local mingw + Lua + LuaRocks with a graphical installer to
> satisfy some category of users.

Or simply precompiled DLLs, assuming this is still possible on current
Windows systems.

--
   Enrico

12