​Dead Batteries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

​Dead Batteries

LunaticCoder
Hi,

I love Lua - thank you all. This is the language I recommend to anyone wanting to learn to code - my copy of PIL has been a great tutorial. There are great development environments available in SciTE or Zerobrane, and a nice friendly community.

Lua is well suited to the "non-compiling user", as are many other interpreted languages. The popularity of these scripted languages is in part the ability to use them without learning/maintaining a compiler. However, there is a ceiling to what can be achieved with Lua alone and from that point onwards you need compiled libraries aka "Batteries" (lfs, winapi, rex_pcre, clipboard, afx, lpeg, hunspell, lsqlite, vcl, gslshell). I am very grateful to those who have made compiled libraries for windows available to download, I don't have or want a compiler!

The progress of Lua from 5.1, 5.2 to 5.3 and soon 5.4 has created a problem -  many of the previously released pre-complied libraries have not been updated and will not run under 5.3. This will stop many updating beyond Lua5.1/Luajit and for projects that do update their embedded Lua versions user like me will find addons/extensions requiring dlls will no longer work (e.g. SciTE: shell.dll, stubby.dll, gui.dll)

Attempts to find a library to allow cut and paste to the windows clipboard in textadept-curses (Lua 5.3) prompted my mail.

I know the "non-compiling" user may not be the main target audience for Lua, but as a beautiful interpreted language I feel the lack of "Live Batteries" prevents Lua becoming as popular as it should.

Q1. Anyone point me to a 32bit library that will do copy/paste to the windows clipboard and is compatible with textadept-curses (https://foicica.com/textadept/CHANGELOG.html).

Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).

Kind Regards Gavin Holt

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Ką Mykolas
On Wed, Dec 18, 2019 at 3:42 PM Gavin Holt <[hidden email]> wrote:
>
>
> Q1. Anyone point me to a 32bit library that will do copy/paste to the windows clipboard and is compatible with textadept-curses (https://foicica.com/textadept/CHANGELOG.html).
>

Hi,

I suppose whatever WinAPI bindings may be helpful for Your clipboard
needs. First one which strikes me:
https://luapower.com/winapi
https://github.com/luapower/winapi/blob/master/winapi/clipboard.lua?ts=3

Also, LuaRocks do have at least 3 packages related to WinAPI. Sadly,
can't tell for sure if those would fit Your needs for sure.

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Ką Mykolas
In reply to this post by LunaticCoder
On Wed, Dec 18, 2019 at 3:42 PM Gavin Holt <[hidden email]> wrote:
>
> Hi,
> Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).
>

For binary distribution... well, that's a tricky part. Just stumbled
on to uLua: https://ulua.io/index.html
I suppose it's worth a spin. And again, no idea how well does it work.

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

LunaticCoder
Hi,

Ką - Thanks for the ideas but both LuaPower and uLua binary distributions are Luajit/ffi based and I can't extract a usable dll to call from Lua 5.3.

winapi.dll from Steve Donovan would be very helpful and Steve did kindly release compiled binaries - back in Jan 2012 (http://lua-users.org/lists/lua-l/2012-01/msg00263.html). No sign of Lua 5.3 binaries at this time.

Kind Regards Gavin Holt

On Wed, 18 Dec 2019 at 14:16, Ką Mykolas <[hidden email]> wrote:
On Wed, Dec 18, 2019 at 3:42 PM Gavin Holt <[hidden email]> wrote:
>
> Hi,
> Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).
>

For binary distribution... well, that's a tricky part. Just stumbled
on to uLua: https://ulua.io/index.html
I suppose it's worth a spin. And again, no idea how well does it work.

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Italo Maia
LuaJIT is pretty much the holy grail for lua. A lot of big libraries rely heavily on it, like openresty, moonscript, love. Likely because it is super fast and light on resources. 

The best way to make sure all our big tooling follow lua syntax updates is literally to make lua the fastest interpreted language, so it can became a solid enterprise choice, which means support from big companies. 

Or you can hunt down yo uh r necessities specifically. 


On Wed, Dec 18, 2019, 16:45 Gavin Holt <[hidden email]> wrote:
Hi,

Ką - Thanks for the ideas but both LuaPower and uLua binary distributions are Luajit/ffi based and I can't extract a usable dll to call from Lua 5.3.

winapi.dll from Steve Donovan would be very helpful and Steve did kindly release compiled binaries - back in Jan 2012 (http://lua-users.org/lists/lua-l/2012-01/msg00263.html). No sign of Lua 5.3 binaries at this time.

Kind Regards Gavin Holt

On Wed, 18 Dec 2019 at 14:16, Ką Mykolas <[hidden email]> wrote:
On Wed, Dec 18, 2019 at 3:42 PM Gavin Holt <[hidden email]> wrote:
>
> Hi,
> Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).
>

For binary distribution... well, that's a tricky part. Just stumbled
on to uLua: https://ulua.io/index.html
I suppose it's worth a spin. And again, no idea how well does it work.

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Javier Guerra Giraldez
On Wed, 18 Dec 2019 at 12:21, Italo Maia <[hidden email]> wrote:
> make lua the fastest interpreted language,

it is


--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Dael Muñiz
In reply to this post by LunaticCoder

 

While it would be very nice to have the “Batteries Included” libraries that say, Python has, I can understand the motivation behind not having them. Lua is pretty much meant to be embedded, fast (and it is, not to mention LuaJIT), cooperative with C. This is a completely different focus from Python, Ruby, etc. Lua is very nice to use, and I personally write MoonScript and compile to Lua, so I get some (personal) “benefits” while still having the simplicity of Lua. But it still feels like it isn’t enough.

 

I wouldn’t discard the idea of an alternative Lua distribution/fork that includes these “batteries” from the language itself and not from 3rd party libraries. Have them be standardized and supported. This would require a lot more of maintenance, for source code, documentation, support, etc. This is something that I don’t think Lua has, we’re not big enough of an userbase, so at the same time it is paradoxical. I would be up for it myself, but I really haven’t got the confidence to touch any C.

 

As for Q1 I have no idea, but for Q2 I am fairly sure that there’s no *active* distribution of precompiled libraries, not that I heard of at the very least. Many libraries might become obsolete or non-working fairly soon if development goes on like this. We already got a lot of stuff running on 5.1 semantics because things are not updated for 5.3, it would be unfair to think that they are going to catch up fast, so I can’t really predict what is going to happen to those in the near future.

 

I doubt we will come up with a solution anytime soon, and I’m sure this has been talked trillion times, but I think it’s worth to keep talking about it.

 

~ Dael

 

 

From: [hidden email]
Sent: December 18, 2019 5:42 AM
To: [hidden email]
Subject: ​Dead Batteries

 

Hi,

 

I love Lua - thank you all. This is the language I recommend to anyone wanting to learn to code - my copy of PIL has been a great tutorial. There are great development environments available in SciTE or Zerobrane, and a nice friendly community.

 

Lua is well suited to the "non-compiling user", as are many other interpreted languages. The popularity of these scripted languages is in part the ability to use them without learning/maintaining a compiler. However, there is a ceiling to what can be achieved with Lua alone and from that point onwards you need compiled libraries aka "Batteries" (lfs, winapi, rex_pcre, clipboard, afx, lpeg, hunspell, lsqlite, vcl, gslshell). I am very grateful to those who have made compiled libraries for windows available to download, I don't have or want a compiler!

 

The progress of Lua from 5.1, 5.2 to 5.3 and soon 5.4 has created a problem -  many of the previously released pre-complied libraries have not been updated and will not run under 5.3. This will stop many updating beyond Lua5.1/Luajit and for projects that do update their embedded Lua versions user like me will find addons/extensions requiring dlls will no longer work (e.g. SciTE: shell.dll, stubby.dll, gui.dll)

 

Attempts to find a library to allow cut and paste to the windows clipboard in textadept-curses (Lua 5.3) prompted my mail.

 

I know the "non-compiling" user may not be the main target audience for Lua, but as a beautiful interpreted language I feel the lack of "Live Batteries" prevents Lua becoming as popular as it should.

 

Q1. Anyone point me to a 32bit library that will do copy/paste to the windows clipboard and is compatible with textadept-curses (https://foicica.com/textadept/CHANGELOG.html).

 

Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).

 

Kind Regards Gavin Holt

 

 

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Coda Highland
> not big enough of a userbase

On the contrary. Lua is used in some well-known, massive projects. Its nature as an embedded language means it never gets the flashy focus, so you'd never KNOW just how big it is just by looking, but its success is entirely BECAUSE it doesn't prescribe or standardize how any given host must use it. It doesn't bring batteries because the host application should already have everything it needs, and it would be a pretty lousy experience if a host had to hack around the "standards" in order to make it work.

I suspect this is also the reason that no standardized "batteries" package has ever caught on. Everyone has different needs so the places where serious money is getting poured into using Lua don't really have much of an incentive to standardize -- it wouldn't give them any benefit.

/s/ Adam

On Wed, Dec 18, 2019 at 7:02 PM Dael Vnaja <[hidden email]> wrote:

 

While it would be very nice to have the “Batteries Included” libraries that say, Python has, I can understand the motivation behind not having them. Lua is pretty much meant to be embedded, fast (and it is, not to mention LuaJIT), cooperative with C. This is a completely different focus from Python, Ruby, etc. Lua is very nice to use, and I personally write MoonScript and compile to Lua, so I get some (personal) “benefits” while still having the simplicity of Lua. But it still feels like it isn’t enough.

 

I wouldn’t discard the idea of an alternative Lua distribution/fork that includes these “batteries” from the language itself and not from 3rd party libraries. Have them be standardized and supported. This would require a lot more of maintenance, for source code, documentation, support, etc. This is something that I don’t think Lua has, we’re not big enough of an userbase, so at the same time it is paradoxical. I would be up for it myself, but I really haven’t got the confidence to touch any C.

 

As for Q1 I have no idea, but for Q2 I am fairly sure that there’s no *active* distribution of precompiled libraries, not that I heard of at the very least. Many libraries might become obsolete or non-working fairly soon if development goes on like this. We already got a lot of stuff running on 5.1 semantics because things are not updated for 5.3, it would be unfair to think that they are going to catch up fast, so I can’t really predict what is going to happen to those in the near future.

 

I doubt we will come up with a solution anytime soon, and I’m sure this has been talked trillion times, but I think it’s worth to keep talking about it.

 

~ Dael

 

 

From: [hidden email]
Sent: December 18, 2019 5:42 AM
To: [hidden email]
Subject: ​Dead Batteries

 

Hi,

 

I love Lua - thank you all. This is the language I recommend to anyone wanting to learn to code - my copy of PIL has been a great tutorial. There are great development environments available in SciTE or Zerobrane, and a nice friendly community.

 

Lua is well suited to the "non-compiling user", as are many other interpreted languages. The popularity of these scripted languages is in part the ability to use them without learning/maintaining a compiler. However, there is a ceiling to what can be achieved with Lua alone and from that point onwards you need compiled libraries aka "Batteries" (lfs, winapi, rex_pcre, clipboard, afx, lpeg, hunspell, lsqlite, vcl, gslshell). I am very grateful to those who have made compiled libraries for windows available to download, I don't have or want a compiler!

 

The progress of Lua from 5.1, 5.2 to 5.3 and soon 5.4 has created a problem -  many of the previously released pre-complied libraries have not been updated and will not run under 5.3. This will stop many updating beyond Lua5.1/Luajit and for projects that do update their embedded Lua versions user like me will find addons/extensions requiring dlls will no longer work (e.g. SciTE: shell.dll, stubby.dll, gui.dll)

 

Attempts to find a library to allow cut and paste to the windows clipboard in textadept-curses (Lua 5.3) prompted my mail.

 

I know the "non-compiling" user may not be the main target audience for Lua, but as a beautiful interpreted language I feel the lack of "Live Batteries" prevents Lua becoming as popular as it should.

 

Q1. Anyone point me to a 32bit library that will do copy/paste to the windows clipboard and is compatible with textadept-curses (https://foicica.com/textadept/CHANGELOG.html).

 

Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).

 

Kind Regards Gavin Holt

 

 

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Luiz Henrique de Figueiredo
In reply to this post by LunaticCoder
> The progress of Lua from 5.1, 5.2 to 5.3 and soon 5.4 has created a problem -  many of the previously released pre-complied libraries have not been updated and will not run under 5.3.

I used to have different versions of my libraries [1], one for each
version of Lua. It took some work but not too much to maintain
separate versions. In July 2018 [2] I moved to a single source code
for 5.3 with an #include for compatibility across Lua versions. I
expect that updating my libraries to 54 will be a breeze with this
approach. Overall, I'm very happy with this approach, especially
because my libraries are now self-contained and include third-party
libraries when needed, and also because they build out of the box in
Linux and macOS. (Unfortunately, I never got them into LuaRocks,
probably because I misunderstood Hisham's instructions about how to
write a LuaRocks-friendly Makefile. I'd love if someone could help me
there [3].)

I've also released a binary distribution of Lua with my libraries
pre-compiled [4]. Apparently, it attracted no interest at all. Perhaps
because it was for macOS only. I expect that multi-platform binary
distributions are indeed a LOT of work.

[1] http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/
[2] http://lua-users.org/lists/lua-l/2018-07/msg00671.html
[3] http://lua-users.org/lists/lua-l/2019-04/msg00119.html
[4] http://lua-users.org/lists/lua-l/2013-07/msg00499.html

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Italo Maia
Javis: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lua-python3.html Other benchmarks have similar results. Memory consumption might also be an issue.

Personally, the batteries are not very important if the common libraries one might need are easy to find/pick. 

Standard lua feels very niche. A lot of people feel that restriction and it hurts.

Anyhow, if looking for something with batteries included, ravi much have something for you.

On Thu, Dec 19, 2019, 05:46 Luiz Henrique de Figueiredo <[hidden email]> wrote:
> The progress of Lua from 5.1, 5.2 to 5.3 and soon 5.4 has created a problem -  many of the previously released pre-complied libraries have not been updated and will not run under 5.3.

I used to have different versions of my libraries [1], one for each
version of Lua. It took some work but not too much to maintain
separate versions. In July 2018 [2] I moved to a single source code
for 5.3 with an #include for compatibility across Lua versions. I
expect that updating my libraries to 54 will be a breeze with this
approach. Overall, I'm very happy with this approach, especially
because my libraries are now self-contained and include third-party
libraries when needed, and also because they build out of the box in
Linux and macOS. (Unfortunately, I never got them into LuaRocks,
probably because I misunderstood Hisham's instructions about how to
write a LuaRocks-friendly Makefile. I'd love if someone could help me
there [3].)

I've also released a binary distribution of Lua with my libraries
pre-compiled [4]. Apparently, it attracted no interest at all. Perhaps
because it was for macOS only. I expect that multi-platform binary
distributions are indeed a LOT of work.

[1] http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/
[2] http://lua-users.org/lists/lua-l/2018-07/msg00671.html
[3] http://lua-users.org/lists/lua-l/2019-04/msg00119.html
[4] http://lua-users.org/lists/lua-l/2013-07/msg00499.html

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Thijs Schreijer
In reply to this post by LunaticCoder


On 18 Dec 2019, at 14:42, Gavin Holt <[hidden email]> wrote:

Hi,

I love Lua - thank you all. This is the language I recommend to anyone wanting to learn to code - my copy of PIL has been a great tutorial. There are great development environments available in SciTE or Zerobrane, and a nice friendly community.

Lua is well suited to the "non-compiling user", as are many other interpreted languages. The popularity of these scripted languages is in part the ability to use them without learning/maintaining a compiler. However, there is a ceiling to what can be achieved with Lua alone and from that point onwards you need compiled libraries aka "Batteries" (lfs, winapi, rex_pcre, clipboard, afx, lpeg, hunspell, lsqlite, vcl, gslshell). I am very grateful to those who have made compiled libraries for windows available to download, I don't have or want a compiler!

Unfortunately Windows makes this very hard. Depending on the versions of the toolchains used to compile the libraries (and hence the dependencies on the underlying MSVCRT type runtime libraries) libs will be compatible or not. In case of incompatibilities, the user get’s no clear messages, just a weird failure.

Thijs
Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Ulrich Schmidt
Am 20.12.2019 um 09:42 schrieb Thijs Schreijer:

>
>
>> On 18 Dec 2019, at 14:42, Gavin Holt <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi,
>>
>> I love Lua - thank you all. This is the language I recommend to
>> anyone wanting to learn to code - my copy of PIL has been a great
>> tutorial. There are great development environments available in SciTE
>> or Zerobrane, and a nice friendly community.
>>
>> Lua is well suited to the "non-compiling user", as are many other
>> interpreted languages. The popularity of these scripted languages is
>> in part the ability to use them without learning/maintaining a
>> compiler. However, there is a ceiling to what can be achieved with
>> Lua alone and from that point onwards you need compiled libraries aka
>> "Batteries" (lfs, winapi, rex_pcre, clipboard, afx, lpeg, hunspell,
>> lsqlite, vcl, gslshell). I am very grateful to those who have made
>> compiled libraries for windows available to download, I don't have or
>> want a compiler!
>
> Unfortunately Windows makes this very hard. Depending on the versions
> of the toolchains used to compile the libraries (and hence the
> dependencies on the underlying MSVCRT type runtime libraries) libs
> will be compatible or not. In case of incompatibilities, the user
> get’s no clear messages, just a weird failure.
>
> Thijs

As a Windows user i fully agree with Thijs. Sooner or later you will
figure out no windows port fully fit your needs and you have to compile
your own lua. Maybe you want to have more than one lua version ready.
Where to store the c modules? Where to store the Lua modules? and so
on... I use TDMgcc on windows as compiler and it works great also with
luarocks.

If you want to avoid all this and you use Win10, you have the option to
use WSL (windows subsystem for Linux) and run your lua scripts in a
linux environment.

Anyway, sooner or later you need to get familiar with a c compiler :)

Ulrich.


Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Jerome Vuarand
In reply to this post by LunaticCoder
On Wed, 18 Dec 2019 at 13:42, Gavin Holt <[hidden email]> wrote:
> Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).

Depending on your definition of "movement", I maintain my own Windows
binaries of Lua and a bunch of third party libraries, mostly for
myself and the rare occasion when I need a colleague to run some of my
scripts:

http://piratery.net/lua/

There's a 32-bit build of 5.3, as that seems to be what you need. It
is however patched a bit, so I can't vouch for the compatibility of
the binary modules with another separately built Lua DLL.

Feel free to pilfer it however you see fit. And I'm open to requests
for additions, in particular features in my own libraries.

Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Russell Haley
In reply to this post by LunaticCoder


On Wed, Dec 18, 2019 at 5:42 AM Gavin Holt <[hidden email]> wrote:
Hi,

I love Lua - thank you all. This is the language I recommend to anyone wanting to learn to code - my copy of PIL has been a great tutorial. There are great development environments available in SciTE or Zerobrane, and a nice friendly community.

Lua is well suited to the "non-compiling user", as are many other interpreted languages. The popularity of these scripted languages is in part the ability to use them without learning/maintaining a compiler. However, there is a ceiling to what can be achieved with Lua alone and from that point onwards you need compiled libraries aka "Batteries" (lfs, winapi, rex_pcre, clipboard, afx, lpeg, hunspell, lsqlite, vcl, gslshell). I am very grateful to those who have made compiled libraries for windows available to download, I don't have or want a compiler!

The progress of Lua from 5.1, 5.2 to 5.3 and soon 5.4 has created a problem -  many of the previously released pre-complied libraries have not been updated and will not run under 5.3. This will stop many updating beyond Lua5.1/Luajit and for projects that do update their embedded Lua versions user like me will find addons/extensions requiring dlls will no longer work (e.g. SciTE: shell.dll, stubby.dll, gui.dll)

Attempts to find a library to allow cut and paste to the windows clipboard in textadept-curses (Lua 5.3) prompted my mail.

I know the "non-compiling" user may not be the main target audience for Lua, but as a beautiful interpreted language I feel the lack of "Live Batteries" prevents Lua becoming as popular as it should.

Q1. Anyone point me to a 32bit library that will do copy/paste to the windows clipboard and is compatible with textadept-curses (https://foicica.com/textadept/CHANGELOG.html).

Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).

Kind Regards Gavin Holt

A1. This looks like it should do the trick, but you'll need a compiler:  https://github.com/zetamatta/nyole. The Microsoft documentation on OLE should inform you how to use the library: https://docs.microsoft.com/en-us/cpp/mfc/clipboard-using-the-ole-clipboard-mechanism?view=vs-2019

A2. Binary distributions really need build infrastructure to keep up with changes in the packages and that doesn't fit well with Lua and the Lua community; there is no organization that has taken on the responsibility for the wider Lua ecosystem. 

I personally think that the package manager paradigm is the right one for Lua (e.g. download and build). LuaRocks is maturing quite nicely and has everything you need. LuaRocks does a pretty good job of hiding the complexity of building software. Installing a compiler is easy but time consuming. You can grab the free Microsoft VS community package, but the they also offer their C++ toolchain without the IDE and it's installation size is a more reasonable 4 GB. The download is well hidden, but I know how to find it here: https://visualstudio.microsoft.com/downloads/ -> Tools For Visual Studio XXXX -> "Build Tools For Visual Studio" (The direct download link is this:  https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=BuildTools&rel=16.)
 
There is an option for binary distribution with LuaRocks that I'd love to exploit for Windows but haven't got the time. LuaForWindows was probably the most well known binary package but it's no longer maintained. I wanted to try to pick that up too but fell short.

Instead I settled for creating a Windows installer for Lua called WinLua: https://github.com/winlua. Release 1 in the bin project is your best best. It installs Lua and adds the environment variables so lua is usable from the command line. I am trying to add LuaRocks to the installer and I should have something ready for when 5.4 is released. The WinLua 5.3 installer works great with the LuaRocks Legacy installation. 


If you're willing to build it, there is a really good Lua distribution called LuaPlus: https://github.com/jjensen/luaplus51-all. (The repo is named 51 but supports 5.3). It's got a ton of good packages and likely has OLE support (I know he had/has COM support). I'd love to see a binary distribution of it and thought about putting together an installer but like the other 4 things I mentioned above, I ran out of time.

As you can see, I've thought a fair bit about this subject. I actually bought an old 32 core server to create some build infrastructure for supporting Lua on Windows but haven't followed through. My thought was to automate the build of select LuaRocks packages and provide win-<packagename> binary rocks. If I could get that going, I was going to resurrect LuaForWindows as a binary LuaRocks install. The idea was this: 1) install WinLua with an installer for basic Lua and LuaRocks 2a) user can install compiler and do whatever they want or 2b) Use luarocks to download binary packages for windows or 2c) Use Luarocks to Download LuaForWindows. Surprising to nobody at this point, I ran out of steam and didn't follow through! That, and I'm a lousy sys-admin and keeping my server up has been harder than expected.

Alright, I'll stop the rambling here. If someone is interested in working on a binary distribution as I mentioned above, let me know. 

Good luck.   
Russ
Reply | Threaded
Open this post in threaded view
|

Re: ​Dead Batteries

Paul K-2
In reply to this post by LunaticCoder
Hi Gavin,

> Q1. Anyone point me to a 32bit library that will do copy/paste to the windows clipboard and is compatible with textadept-curses (https://foicica.com/textadept/CHANGELOG.html).

winapi provides set_clipboard/get_clipoard methods
(http://stevedonovan.github.io/winapi/api.html#set_clipboard). I
didn't test it with textadept, but don't see why it wouldn't work
there.

> Attempts to find a library to allow cut and paste to the windows clipboard in textadept-curses (Lua 5.3) prompted my mail.

I confirmed that winapi compiles with Lua 5.3

> Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).

I do this to some degree in ZeroBrane Studio distribution, but only
for a small set of libraries (lpeg, lfs, luasec, and luasocket). These
libraries are compiled for Lua 5.1-5.3 on Windows/macOS/Linux. I also
package wx/winapi for Lua 5.1, but these can be compiled for Lua 5.2
and 5.3 as well using the included scripts.

> The progress of Lua from 5.1, 5.2 to 5.3 and soon 5.4 has created a problem -  many of the previously released pre-complied libraries have not been updated and will not run under 5.3. This will stop many updating beyond Lua5.1/Luajit and for projects that do update their embedded Lua versions user like me will find addons/extensions requiring dlls will no longer work (e.g. SciTE: shell.dll, stubby.dll, gui.dll)

Ideally modules need to be updated to support new(er) versions of Lua,
but if there is no easy way to update them, I wonder if something like
twoface (http://corsix.github.io/twoface/) can be helpful if extended
to cover Lua 5.3+. I used it with Lua 5.2 on a quite complex libraries
(wx/wxlua) without any noticeable issues.

Paul.

On Wed, Dec 18, 2019 at 5:42 AM Gavin Holt <[hidden email]> wrote:

>
> Hi,
>
> I love Lua - thank you all. This is the language I recommend to anyone wanting to learn to code - my copy of PIL has been a great tutorial. There are great development environments available in SciTE or Zerobrane, and a nice friendly community.
>
> Lua is well suited to the "non-compiling user", as are many other interpreted languages. The popularity of these scripted languages is in part the ability to use them without learning/maintaining a compiler. However, there is a ceiling to what can be achieved with Lua alone and from that point onwards you need compiled libraries aka "Batteries" (lfs, winapi, rex_pcre, clipboard, afx, lpeg, hunspell, lsqlite, vcl, gslshell). I am very grateful to those who have made compiled libraries for windows available to download, I don't have or want a compiler!
>
> The progress of Lua from 5.1, 5.2 to 5.3 and soon 5.4 has created a problem -  many of the previously released pre-complied libraries have not been updated and will not run under 5.3. This will stop many updating beyond Lua5.1/Luajit and for projects that do update their embedded Lua versions user like me will find addons/extensions requiring dlls will no longer work (e.g. SciTE: shell.dll, stubby.dll, gui.dll)
>
> Attempts to find a library to allow cut and paste to the windows clipboard in textadept-curses (Lua 5.3) prompted my mail.
>
> I know the "non-compiling" user may not be the main target audience for Lua, but as a beautiful interpreted language I feel the lack of "Live Batteries" prevents Lua becoming as popular as it should.
>
> Q1. Anyone point me to a 32bit library that will do copy/paste to the windows clipboard and is compatible with textadept-curses (https://foicica.com/textadept/CHANGELOG.html).
>
> Q2. Is there any movement to maintain a distribution of pre-compiled libraries? Perhaps like LuaPower (https://luapower.com/) or better the comprehensive IUP distribution maintained by Antonio Scuri (https://sourceforge.net/projects/iup/files/3.28/).
>
> Kind Regards Gavin Holt
>

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Steve Litt
In reply to this post by Italo Maia
On Thu, 19 Dec 2019 12:14:12 +0100
Italo Maia <[hidden email]> wrote:

> Javis:
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lua-python3.html
> Other benchmarks have similar results. Memory consumption might also
> be an issue.
>
> Personally, the batteries are not very important if the common
> libraries one might need are easy to find/pick.

I think you put your finger on the issue, Italo. One needs to:

1) Find the library
2) Pick the library
3) Install the library

#2 involves, for each candidate library for a given task:
        a) install the library
        b) learn the library
        c) experiment with the library
        d) unless the library turns out to be the best:
                Discard all that effort

#3 requires either my distro package the library, or I use luarocks,
which I don't normally like to do (no more than I like Ruby gems,
Python pip or Perl CPAN). Worse yet, #3 requires me to explain, to
prospective users of my programs using the library, how to install the
dependency on *their* computer, and a lot of times because dependencies
have dependencies, that doesn't work.

Contrast this to Python, which has a curated set of complete, tested
and documented standard libraries, effectively meaning that almost any
project you start in Python can be finished in Python using just the
standard library.

Of course, in the case of Lua the standard library must be in a
different package to Lua itself, to facilitate tiny embedded programs.
This doesn't mean Lua can't have a curated standard library, separately
installed, and hopefully packaged by the distros.

Lua is by far the best *language* I've ever used. However, due to lack
of a curated and up-to-date standard library, it's not the most likely
to produce a successful result in a computer application as opposed to
an embedded program.

A good starting point would be an official list of approved Lua
libraries, with a search function, that tells the strengths of each
library. That would be a great improvement over having to ask online
and getting lots of opinions.

Thanks,

SteveT

Steve Litt
December 2019 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Lorenzo Donati-3
On 31/12/2019 20:29, Steve Litt wrote:

> On Thu, 19 Dec 2019 12:14:12 +0100
> Italo Maia <[hidden email]> wrote:
>
>> Javis:
>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lua-python3.html
>> Other benchmarks have similar results. Memory consumption might also
>> be an issue.
>>
>> Personally, the batteries are not very important if the common
>> libraries one might need are easy to find/pick.
>
> I think you put your finger on the issue, Italo. One needs to:
>
> 1) Find the library
> 2) Pick the library
> 3) Install the library
>
> #2 involves, for each candidate library for a given task:
> a) install the library
> b) learn the library
> c) experiment with the library
> d) unless the library turns out to be the best:
> Discard all that effort
>
> #3 requires either my distro package the library, or I use luarocks,
> which I don't normally like to do (no more than I like Ruby gems,
> Python pip or Perl CPAN). Worse yet, #3 requires me to explain, to
> prospective users of my programs using the library, how to install the
> dependency on *their* computer, and a lot of times because dependencies
> have dependencies, that doesn't work.
>
> Contrast this to Python, which has a curated set of complete, tested
> and documented standard libraries, effectively meaning that almost any
> project you start in Python can be finished in Python using just the
> standard library.
>
> Of course, in the case of Lua the standard library must be in a
> different package to Lua itself, to facilitate tiny embedded programs.
> This doesn't mean Lua can't have a curated standard library, separately
> installed, and hopefully packaged by the distros.
>
> Lua is by far the best *language* I've ever used. However, due to lack
> of a curated and up-to-date standard library, it's not the most likely
> to produce a successful result in a computer application as opposed to
> an embedded program.
>
> A good starting point would be an official list of approved Lua
> libraries, with a search function, that tells the strengths of each
> library. That would be a great improvement over having to ask online
> and getting lots of opinions.
>

You really hit the spot!


> Thanks,
>
> SteveT
>
> Steve Litt
> December 2019 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
>
>


On a related note, many years ago I read something about the success of
C (I can't recall exactly where or who wrote it, but it wasn't a
uninfluential author, IIRC).

That author stated that the success of C, despite being an inferior
language than Pascal, from an elegance and many other POVs, was that it
had a well defined machine model with a practical vision.

In particular: the core language modeled an abstract machine which was
sufficiently adaptable to any known architecture (Von Neumann based,
especially). But this was not the whole point: the core language would
have sucked without the presence of a well defined, and /separated/
/standard/ library that modeled what a high level user would expect from
a real system.

Pascal, OTOH, had integrated basic I/O in the core language (which
hampered adaptation) and left libraries to implementors (e.g. Turbo
Pascal was great, but it was Borland's vision).

The fact that the C library was standard and practical, made people
invest more effort in using C even for non-bare metal applications,
where it had no real edge over Pascal.

I think that the whole thing can be applied to Lua vs. Python. Lua as an
embeddable language is no match for Python, but sadly Python is often
chosen as an embedded language because:

- (a) It has a huge and stable standard library.
- (b) It has a huge user base which has gained because of (a).
- (c) It appeals to non-programmers which need to program something
wasting no time, especially because of (a) and also due to hype because
of (b).
- (d) Lua is not as widely known as Python nowadays, which depends on
(a), (b) and (c).

Note the "recursive/self sustaining" pattern in those reasons!

About (c) above: I've never been asked what is Lua by non-programmer
colleagues and students, unless I cited it first. OTOH I've been
frequently asked about Python!

We developers can appreciate elegance and minimalism and use Lua just
for that, but sometimes you have to solve problems and you don't have
time to roll your own solution.

A personal example of about a year ago: I had to write a script to
control an electronic instrument with a Windows PC via virtual USART
(serial port) over USB. The first problem was that every Lua library I
downloaded didn't work out of the box. Some were not maintained, others
were too difficult to install or didn't compile with my tools. I had no
time and I just wanted a small application with few files and no
dependency and no installation procedure.

So I got my hand dirty, learned the intricacies of USART API in Windows
(the difficult part) and then rolled my own C library using Lua C-API.
It was dirty and not a very elegant solution, but it worked fine. OK,
kudos to Lua being so easy to extend but:

1. I had to be a barely decent C programmer (not easy).
2. I had to know Lua C API (easy).
3. I had to delve into the intricacies of Win32 C USART API (very
difficult).

All this took time I barely had, but I bit the bullet because:

1. I have a solution that works in Lua (even if brittle) written by me
so I know where to put my hands when something goes wrong, instead of
relying on someone on the Internet solving a bug on their barely
maintained library in a timely fashion for me.
2. I don't have another dependency which then I would have to maintain.
3. It is lightweight.

But, really, if I just had more expertise in Python, in that
circumstances probably I would have just used a Python script and be
done with it.

And if I didn't already know Lua, I will probably learn Python just
because of the hype (not good, but that's the crude reality) and because
it has every kind of battery included (very good!).

And if I were a non-programmer, no way I'd even think to use Lua (even
if I knew it existed). Just learn Python at the bare level needed to use
one of its /standard/ libraries.

Even if Lua is gaining users (I don't know, is someone aware of some
current numbers and trends) it is gaining much less users than Python,
of that I'm sure.

And Lua is actively scaring away non-programmers, IMO. Unless one wants
to buy the excellent books by Roberto, the only direct and free resource
to learn Lua is the reference manual (besides the ancient online PiL
that covers Lua 5.0). Which by itself is a bit hard on non-programmers
(Lua 5.1 one was a bit more easy reading, IMO).

The non-programmer is scared away just when it comes down to read some
of the standard library documentation. An example? Just out of the
os.date refman entry:

"If format is not "*t", then date returns the date as a string,
formatted according to the same rules as the ISO C function strftime."

Imagine a non-programmer professional (a physicist, a chemist, a
teacher?) reading that. "Just to format a date I must know C ?!?"

Yes, if you are a programmer you could understand that you only need the
strftime docs. And if you are also a C programmer you could understand
it is not so scary/difficult to retrieve that docs (cppreference.com
anyone?). But those are two BIG ifs.

And references to C are scattered throughout the entire refman, even in
non C-API parts!

But, as usual, I'm beating a dead horse. Until Lua Team decide they want
really to appeal to the wider non-professional "programmer" community,
there is no way to improve the situation, IMO. Lua will remain a
wonderful language with a fairly restrict niche user base, with everyone
reinventing their own wheels.

Yes, lua-l is friendly, but that's no substitute for a real free
comprehensive /standard/ library with good documentation.

Individual initiatives are usually doomed from the start without
endorsement from the "official" source (and whoever has been following
this list for some years, has seen many attempts to create
distros/standard libraries/active wiki sites go sour). Some are still
alive, but not kicking. Some are abandonware/completely dead.

Cheers!

-- Lorenzo













Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Luiz Henrique de Figueiredo
> On a related note, many years ago I read something about the success of
> C (I can't recall exactly where or who wrote it, but it wasn't a
> uninfluential author, IIRC).

Perhaps this?

Why Pascal is Not My Favorite Programming Language
by Brian W. Kernighan
https://www.lysator.liu.se/c/bwk-on-pascal.html

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Russell Haley
In reply to this post by Lorenzo Donati-3


On Sun, Jan 5, 2020 at 5:38 AM Lorenzo Donati <[hidden email]> wrote:
On 31/12/2019 20:29, Steve Litt wrote:
> On Thu, 19 Dec 2019 12:14:12 +0100
> Italo Maia <[hidden email]> wrote:
>
>> Javis:
>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lua-python3.html
>> Other benchmarks have similar results. Memory consumption might also
>> be an issue.
>>
>> Personally, the batteries are not very important if the common
>> libraries one might need are easy to find/pick.
>
> I think you put your finger on the issue, Italo. One needs to:
>
> 1) Find the library
> 2) Pick the library
> 3) Install the library
>
> #2 involves, for each candidate library for a given task:
>       a) install the library
>       b) learn the library
>       c) experiment with the library
>       d) unless the library turns out to be the best:
>               Discard all that effort
>
> #3 requires either my distro package the library, or I use luarocks,
> which I don't normally like to do (no more than I like Ruby gems,
> Python pip or Perl CPAN). Worse yet, #3 requires me to explain, to
> prospective users of my programs using the library, how to install the
> dependency on *their* computer, and a lot of times because dependencies
> have dependencies, that doesn't work.
>
> Contrast this to Python, which has a curated set of complete, tested
> and documented standard libraries, effectively meaning that almost any
> project you start in Python can be finished in Python using just the
> standard library.
>
> Of course, in the case of Lua the standard library must be in a
> different package to Lua itself, to facilitate tiny embedded programs.
> This doesn't mean Lua can't have a curated standard library, separately
> installed, and hopefully packaged by the distros.
>
> Lua is by far the best *language* I've ever used. However, due to lack
> of a curated and up-to-date standard library, it's not the most likely
> to produce a successful result in a computer application as opposed to
> an embedded program.
>
> A good starting point would be an official list of approved Lua
> libraries, with a search function, that tells the strengths of each
> library. That would be a great improvement over having to ask online
> and getting lots of opinions.
>

You really hit the spot!


> Thanks,
>
> SteveT
>
> Steve Litt
> December 2019 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
>
>


On a related note, many years ago I read something about the success of
C (I can't recall exactly where or who wrote it, but it wasn't a
uninfluential author, IIRC).

That author stated that the success of C, despite being an inferior
language than Pascal, from an elegance and many other POVs, was that it
had a well defined machine model with a practical vision.

In particular: the core language modeled an abstract machine which was
sufficiently adaptable to any known architecture (Von Neumann based,
especially). But this was not the whole point: the core language would
have sucked without the presence of a well defined, and /separated/
/standard/ library that modeled what a high level user would expect from
a real system.

Pascal, OTOH, had integrated basic I/O in the core language (which
hampered adaptation) and left libraries to implementors (e.g. Turbo
Pascal was great, but it was Borland's vision).

The fact that the C library was standard and practical, made people
invest more effort in using C even for non-bare metal applications,
where it had no real edge over Pascal.

I think that the whole thing can be applied to Lua vs. Python. Lua as an
embeddable language is no match for Python, but sadly Python is often
chosen as an embedded language because:

- (a) It has a huge and stable standard library.
- (b) It has a huge user base which has gained because of (a).
- (c) It appeals to non-programmers which need to program something
wasting no time, especially because of (a) and also due to hype because
of (b).
- (d) Lua is not as widely known as Python nowadays, which depends on
(a), (b) and (c).

Note the "recursive/self sustaining" pattern in those reasons!

About (c) above: I've never been asked what is Lua by non-programmer
colleagues and students, unless I cited it first. OTOH I've been
frequently asked about Python!

We developers can appreciate elegance and minimalism and use Lua just
for that, but sometimes you have to solve problems and you don't have
time to roll your own solution.

A personal example of about a year ago: I had to write a script to
control an electronic instrument with a Windows PC via virtual USART
(serial port) over USB. The first problem was that every Lua library I
downloaded didn't work out of the box. Some were not maintained, others
were too difficult to install or didn't compile with my tools. I had no
time and I just wanted a small application with few files and no
dependency and no installation procedure.

I know your pain so I created this: https://github.com/RussellHaley/NLuaSerialConsole 

NLuaSerialConsole is a generic Serial Port tool to take advantage of Lua's powerful binary string manipulation in what I would consider the proper context: Embedded in a language with a complete library and multi threaded capabilities. The serial interface is provided via DotNet. The full DotNet library is available within Lua scripts via NLua. NLua is *very* slick and embeds a full version of Lua so all your C modules are available too.

I'm eventually planning on porting to DotNet Core for full cross platform functionality.

All contributions/comments/wtfs welcome.
Russ

So I got my hand dirty, learned the intricacies of USART API in Windows
(the difficult part) and then rolled my own C library using Lua C-API.
It was dirty and not a very elegant solution, but it worked fine. OK,
kudos to Lua being so easy to extend but:

1. I had to be a barely decent C programmer (not easy).
2. I had to know Lua C API (easy).
3. I had to delve into the intricacies of Win32 C USART API (very
difficult).

All this took time I barely had, but I bit the bullet because:

1. I have a solution that works in Lua (even if brittle) written by me
so I know where to put my hands when something goes wrong, instead of
relying on someone on the Internet solving a bug on their barely
maintained library in a timely fashion for me.
2. I don't have another dependency which then I would have to maintain.
3. It is lightweight.

But, really, if I just had more expertise in Python, in that
circumstances probably I would have just used a Python script and be
done with it.

And if I didn't already know Lua, I will probably learn Python just
because of the hype (not good, but that's the crude reality) and because
it has every kind of battery included (very good!).

And if I were a non-programmer, no way I'd even think to use Lua (even
if I knew it existed). Just learn Python at the bare level needed to use
one of its /standard/ libraries.

Even if Lua is gaining users (I don't know, is someone aware of some
current numbers and trends) it is gaining much less users than Python,
of that I'm sure.

And Lua is actively scaring away non-programmers, IMO. Unless one wants
to buy the excellent books by Roberto, the only direct and free resource
to learn Lua is the reference manual (besides the ancient online PiL
that covers Lua 5.0). Which by itself is a bit hard on non-programmers
(Lua 5.1 one was a bit more easy reading, IMO).

The non-programmer is scared away just when it comes down to read some
of the standard library documentation. An example? Just out of the
os.date refman entry:

"If format is not "*t", then date returns the date as a string,
formatted according to the same rules as the ISO C function strftime."

Imagine a non-programmer professional (a physicist, a chemist, a
teacher?) reading that. "Just to format a date I must know C ?!?"

Yes, if you are a programmer you could understand that you only need the
strftime docs. And if you are also a C programmer you could understand
it is not so scary/difficult to retrieve that docs (cppreference.com
anyone?). But those are two BIG ifs.

And references to C are scattered throughout the entire refman, even in
non C-API parts!

But, as usual, I'm beating a dead horse. Until Lua Team decide they want
really to appeal to the wider non-professional "programmer" community,
there is no way to improve the situation, IMO. Lua will remain a
wonderful language with a fairly restrict niche user base, with everyone
reinventing their own wheels.

Yes, lua-l is friendly, but that's no substitute for a real free
comprehensive /standard/ library with good documentation.

Individual initiatives are usually doomed from the start without
endorsement from the "official" source (and whoever has been following
this list for some years, has seen many attempts to create
distros/standard libraries/active wiki sites go sour). Some are still
alive, but not kicking. Some are abandonware/completely dead.

Cheers!

-- Lorenzo













Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Lorenzo Donati-3
In reply to this post by Luiz Henrique de Figueiredo
On 05/01/2020 17:15, Luiz Henrique de Figueiredo wrote:

>> On a related note, many years ago I read something about the success of
>> C (I can't recall exactly where or who wrote it, but it wasn't a
>> uninfluential author, IIRC).
>
> Perhaps this?
>
> Why Pascal is Not My Favorite Programming Language
> by Brian W. Kernighan
> https://www.lysator.liu.se/c/bwk-on-pascal.html
>
>
Thanks Luiz, very interesting reading!

Although some of the content resounded with my brain, I'm almost sure I
had never read it before.

It is quite an old article, and the one I remember vaguely was something
perhaps shorter and a bit more recent. I'm rather sure it was something
written in the 90s, when many successful implementations of Pascal were
widespread.

I suspect the author did actually read the article from Kerninghan,
since some of the ideas are in this latter's article as well (bad I/O
model of Pascal, ability of separate compilation of C).

But I also remember the author stressed that one of the key point of C
success was the availability of a standardized library that was
separated from the the core language (in particular the I/O facilities).

I might have read it around 2002/2003, when I was attending a PhD course
in SW engineering that I never completed. But I'm not sure.

Thanks anyway.

-- Lorenzo

123