​Dead Batteries

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

Re: Dead Batteries

Dibyendu Majumdar
On Sun, 5 Jan 2020 at 13:38, Lorenzo Donati <[hidden email]> wrote:
> > 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!

Or not. I used to think as above, but I now see that if you need
language with batteries, you should go for Python or Javascript. Lua's
strength is lack of any baggage, which makes it better for embedded
use.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Lorenzo Donati-3
On 05/01/2020 22:23, Dibyendu Majumdar wrote:

> On Sun, 5 Jan 2020 at 13:38, Lorenzo Donati <[hidden email]> wrote:
>>> 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!
>
> Or not. I used to think as above, but I now see that if you need
> language with batteries, you should go for Python or Javascript. Lua's
> strength is lack of any baggage, which makes it better for embedded
> use.
>
> Regards
>
>
Sorry, but I don't see how the availability of a "complete standard
battery pack" would hamper "embeddabilty".

Even Lua standard libraries can be excluded from compilation, if they
are not needed.

A more complete standard library could be well an optional download with
a series of Lua files/DLLs (e.g. Windows) that would be required on demand.

They don't need to be statically linked into the core Lua engine, if
this is what you are worried about.

OTOH the lack of such batteries greatly hamper the diffusion of Lua as a
general purpose language.

Cheers!




Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Dibyendu Majumdar
On Sun, 5 Jan 2020 at 21:51, Lorenzo Donati <[hidden email]> wrote:

> OTOH the lack of such batteries greatly hamper the diffusion of Lua as a
> general purpose language.
>

Well Python is arguably a better general purpose language and has a
very powerful set of libraries. Why does the world need another one?

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Russell Haley
In reply to this post by Dibyendu Majumdar


On Sun, Jan 5, 2020 at 1:24 PM Dibyendu Majumdar <[hidden email]> wrote:
On Sun, 5 Jan 2020 at 13:38, Lorenzo Donati <[hidden email]> wrote:
> > 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!

Or not. I used to think as above, but I now see that if you need
language with batteries, you should go for Python or Javascript. Lua's
strength is lack of any baggage, which makes it better for embedded
use.
I recently found Lua it in The Steingberg Halion Virtual Instrument software.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Coda Highland


On Sun, Jan 5, 2020 at 11:16 PM Russell Haley <[hidden email]> wrote:


On Sun, Jan 5, 2020 at 1:24 PM Dibyendu Majumdar <[hidden email]> wrote:
On Sun, 5 Jan 2020 at 13:38, Lorenzo Donati <[hidden email]> wrote:
> > 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!

Or not. I used to think as above, but I now see that if you need
language with batteries, you should go for Python or Javascript. Lua's
strength is lack of any baggage, which makes it better for embedded
use.
I recently found Lua it in The Steingberg Halion Virtual Instrument software.

Regards


I used it in EastWest's PLAY library, too. (That is, in fact, the reason I joined the list in the first place.) Though unless things have changed since I left it's only available for instrument creators, not end users.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Lorenzo Donati-3
In reply to this post by Dibyendu Majumdar
On 05/01/2020 23:00, Dibyendu Majumdar wrote:

> On Sun, 5 Jan 2020 at 21:51, Lorenzo Donati
> <[hidden email]> wrote:
>
>> OTOH the lack of such batteries greatly hamper the diffusion of Lua
>> as a general purpose language.
>>
>
> Well Python is arguably a better general purpose language and has a
> very powerful set of libraries.
>

Sorry, but I agree to a point:

Python /is/ a better GPL, but /because of its libraries/.

Strip it of its library and what remains is slow, bloated and the
language itself is far less readable and elegant than Lua (at least that
was the state of it, IMO, some years ago when I learned it).

But I admit I haven't stayed up to date and I haven't used it for years,
so maybe it has improved as a language in latest years.

> Why does the world need another one?

Well you seem to imply that Python is the ultimate best GPL and there is
no space for innovation.

Moreover you also imply Lua is /not/ a GPL, but this is not what Lua
authors think (at least that was my impression from what they've been
saying for years. If they changed their mind recently, I cannot tell,
since I don't follow this list /so/ closely nowadays).

FWIW, I argue that if Lua had the same libraries of Python, with their
same standardization and continuous care, Lua would be a FAR better GPL.

IMO, (non-extreme) minimalism in the core language is good for a GPL. It
is not good in the libraries, though.

Moreover, but this is a knee-jerk reflex of mine, I hate semantically
meaningful spaces in a language. I /do/ like explicit code blocks (pun
intended :-)


> Regards
>
>

Cheers!

Reply | Threaded
Open this post in threaded view
|

New Batteries? (Was: Dead Batteries)

Stefan-2
In reply to this post by Dibyendu Majumdar
Am 05.01.2020 um 23:00 schrieb Dibyendu Majumdar:
>
> Well Python is arguably a better general purpose language and has a
> very powerful set of libraries. Why does the world need another one?
>
> Regards
>

[Warning: wall of text - jump to "What about Lua?" or "Conclusion" for a
shortcut]

Python's insufficient thread support is a *big* disadvantage.
The GIL (Global Interpreter Lock) basically combines the
unpredictability of preemptive multithreading with the low performance
of cooperative multithreading and is only useful for some I/O tasks[1].

Making Python and all of its libraries ready for "real" multithreading
is a lot of work and the Python community hasn't done this yet.

But soon this will become very important!

Fast CPUs are a "solved problem" nowadays and we will probably only get
more of them, more efficient and cheaper ones and specialized hardware
but no longer faster cores[2].
This trend has already started - AMD produces mobile CPUs with 8 cores
at 15W[3] and Intel will certainly not sit still.
Maybe 8 cores for laptops and 16 cores for PCs will be the default in
less than five years...

OTOH data production/transport/storage technology is *still* improving
at an unbelievable pace[4][5] (excerpt: new technology will help 500
million Indians to join the internet).
With most users possessing only dual-core machines (today), not having
actual multicore support wasn't that bad. But with 8/16/32/special
cores? And a lot more data to process?

Even the CPU architects are concerned about this[6, page 35/36].

Unfortunately weak typing and multithreading doesn't mix well and
multithreading in general has many pitfalls.
Jython/JRuby use the JVM to take advantage of its sophisticated runtime.
But a threaded garbage collector and per-object locking seem to be
anything but trivial and the JVM is a memory-hogging behemoth.
JavaScript doesn't allow shared context at all and WebWorkers basically
provide processes with bolted-on message passing.
PHP seems to allow threading without actually being thread-safe...
solves the problem by ignoring it ;)
About others I'm not sure.

What about Lua?

Making the language itself multithreaded is obviously not going to
happen. But creating many independent Lua states that are executed by
multiple threads is easy!

While starting hundreds or thousands of threads is not a good idea,
having more independent program contexts than cores is very useful:
- map one network connection to one Lua state, i.e. application servers
- one state per user for multiuser applications
- one state per view for GUI programs
- process a directory recursively and have a state per directory
- for divide-and-conquer strategies in general
- partitioning of complex programs

Compared to various other scripting languanges Lua has by far the
fastest startup time by at least an order of magnitude. Btw check out
`strace ruby -e "puts 'hello world'" 2>&1 | wc -l`, Ruby 2.5 needs
1790 syscalls for "hello world" (yes I know this example is unfair :))

For Lua, one of my i5230M cores can create 100K states + load a
precompiled script in *one second*. On x86_64 they use up ~700MB RAM
afterwards.

Unfortunately the reason why this is so fast is that the lua_States are
basically empty. Loading just the standard library slows it down by a
factor of 10.

So, a theoretical future feature-rich standard library should support:
- lazy binding/loading so that adding more functions doesn't impede
state creation
- thread safety or awareness of its functions (one C function could be
called by multiple Lua states in parallel)
- communication/synchronization between states
- offloading of blocking calls into separate threads
- some kind of compatibility header/subset of the C API so that minor
changes in the language don't break existing library sources

Conclusion:
- It's 2020, a useful standard library must support real threading
- And Lua states are handy since they provide separate contexts without
giving up the user-friendly cooperative model

It has always bummed me out that there is no agreed-on bigger standard
library for Lua that is not directly meant for embedding. I mean it is
also the perfect glue language, why isn't there anything ready to glue
together?

There are probably many "invisible" Lua users that are some kiddos that
mod their favourite game and sooner or later want to create "real"
applications outside of the host game.

But they aren't full-blown programmers with an elaborate toolchain and a
stack of reference books on their desks (yet ^^).
So they download some things from the internet, fiddle around a bit and
then give up on Lua...

Providing them with a powerful and extensible, pre-compiled library
would go a long way!

I think due to its simple and divisible nature Lua *could* be a general
purpose scripting language of the future!

Best regards and a happy new year :)

[1] "Inside the Python GIL"
https://www.dabeaz.com/python/GIL.pdf
[2] "Trends in Processor Architecture"
https://arxiv.org/ftp/arxiv/papers/1801/1801.05215.pdf
[3] "Ryzen 7 4700U: AMD's First Ever 8-Core APU"
https://www.tomshardware.com/news/ryzen-7-4700u-amds-first-ever-8-core-apu
[4] "Ericsson Mobility Report November 2019"
https://www.ericsson.com/4acd7e/assets/local/mobility-report/documents/2019/emr-november-2019.pdf
[5] "Cisco Visual Networking Index: Forecast and Trends, 2017–2022"
https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/white-paper-c11-741490.pdf
[6] "A New Golden Age for Computer Architecture"
https://californiaconsultants.org/wp-content/uploads/2018/04/CNSV-1806-Patterson.pdf

Reply | Threaded
Open this post in threaded view
|

Re: New Batteries? (Was: Dead Batteries)

Dael Muñiz
> There are probably many "invisible" Lua users that are some kiddos that
> mod their favourite game and sooner or later want to create "real"
> applications outside of the host game.
> But they aren't full-blown programmers with an elaborate toolchain and a
> stack of reference books on their desks (yet ^^).
> So they download some things from the internet, fiddle around a bit and
> then give up on Lua...

[Another wall of text, I will try to sum stuff up by the end of it]

This was probably one of the most relatable parts of the previous
response for me.

I personally started getting into programming by wondering how
Minecraft worked. Quite the intro, I know. I somehow started with Java
and modding, and descarted it as a feasible idea and moved on to other
languages to do my usual script kiddie stuff thati uploaded onto
Microsoft CodePlex. It was all quite weird and sketchy. I went through
Python, Batch, C#, and almost Ruby, until I found Lua.

By the time I found Lua it wasn't so far from my original intentions
when I started programming. I learned it from the hand of a Minecraft
mod that implements fantasy computers that run Lua, since it is an
easily embeddable language. (There are actually two different mods
that allow doing this). I started fading off from the mod, moving onto
making practical stuff, leaving all of that phase behind. I don't know
exactly what made me stay, but I think it was the simplicity of the
language, not necessarily in syntax, but I just didn't like what
Python did, and I still suffered from some "Not Invented Here
Syndrome". It's true that I found myself working on libraries most of
the time because while there are many availiable, I felt like many of
them wouldn't work for me.

Now I know that many of these I looked at could have actually worked,
however, I'm still working on libraries, why?
While the community has made really important contributions and useful
libraries, I still feels like there are many holes to fill, many
libraries that Lua is lacking. That isn't necessarily a bad thing and
I understand the nature of the Lua language. Lua *could* be a good
GPL, but I feel like a parallel project to Lua should fill that hole
instead of Lua. I will expand more on that later.

I still find myself around the community of that Minecraft Lua mod,
and I see new people coming in every month with the same excitement I
had. The problems they ask about are usually about opening a door or
solving some logic problem, but the experience is not much different
from what a kid could do with Scratch and moving blocks. Truth is,
many of these people, as you said, move on from Lua onto other
languages. That is, of course, only if they do end up falling in love
with programming as I did.

You can see Lua in many ways, and depending on the way you see it,
your answer to "Lua needs a standard library" will vary. If someone
thinks of Lua as a mostly embedded language, they probably are not
going to be very fond of a standard library, because excluding it or
including it at compilation would not be as easy for the unexperienced
end user, say. In the end, you could end up not knowing the
implementation you got if you are working anywhere that uses embedded
Lua. Or, in the case of the Minecraft mods, they may end up being
completely irrelevant, as for example it implements its own "API" for
"filesystem" handling like creating folders, listing files and the
such. If you think of it as a General Purpose Language, of course you
are going to want a standard library, it will certainly make many
people stay and increase the "market share" that Lua currently has by
making it a far more powerful language out of the box. If you think of
it as a passing language, one that you use merely to learn to later
move on to a better language, chances are that it doesn't matter too
much.

Now, regardless of your view of Lua, I think it's undeniable that if
it did get a standard library, included batteries, whatever; it would
change the way people see and use Lua. It is not a solution that works
for everyone, however.

Now, expanding on the previous idea of the parallel project. I don't
feel like Lua as a project, with its maintainers and current purpose,
is ready to take on the responsibility of maintaining a standard
library and turning into a GPL. Besides, many people will not like
that solution. These are not necessarily bad things, merely opinions.
This is why I don't think that Lua should try to go for a "majority
vote" and find the solution that works for *most*, but rather keep the
Lua project as it currently is, and have a certain group of volunteers
maintain a parallel project to Lua, forked from it and fairly
up-to-date, that does implement these standard libraries and has the
focus on becoming a GPL rather than being embedded.

I personally believe that it would only work if everything is open
standard, and publicly hosted. By open standard I mean all decisions
being discussed and agreed for the most part, and while Lua is
publicly hosted, people usually check out the GitHub repository. It
would rather be helpful to have it hosted on a platform where it can
get a lot of attention.

(Now, I know there's many parts about the last e-mail I am missing,
I'm not well-versed on thread and don't really have a stance on it)

[Conclusion]
I think a good conclusion would be:
- Many people use Lua as a passing language that they use to learn.
- Many more people would stay on Lua given the right included batteries.
- There is disagreement as to what people think of Lua and whether it
should have a stdlib or not.
- I believe that a project with included batteries would have to work
parallel to Lua and more open than it currently is.


On Mon, 6 Jan 2020 at 19:02, Stefan <[hidden email]> wrote:

>
> Am 05.01.2020 um 23:00 schrieb Dibyendu Majumdar:
> >
> > Well Python is arguably a better general purpose language and has a
> > very powerful set of libraries. Why does the world need another one?
> >
> > Regards
> >
>
> [Warning: wall of text - jump to "What about Lua?" or "Conclusion" for a
> shortcut]
>
> Python's insufficient thread support is a *big* disadvantage.
> The GIL (Global Interpreter Lock) basically combines the
> unpredictability of preemptive multithreading with the low performance
> of cooperative multithreading and is only useful for some I/O tasks[1].
>
> Making Python and all of its libraries ready for "real" multithreading
> is a lot of work and the Python community hasn't done this yet.
>
> But soon this will become very important!
>
> Fast CPUs are a "solved problem" nowadays and we will probably only get
> more of them, more efficient and cheaper ones and specialized hardware
> but no longer faster cores[2].
> This trend has already started - AMD produces mobile CPUs with 8 cores
> at 15W[3] and Intel will certainly not sit still.
> Maybe 8 cores for laptops and 16 cores for PCs will be the default in
> less than five years...
>
> OTOH data production/transport/storage technology is *still* improving
> at an unbelievable pace[4][5] (excerpt: new technology will help 500
> million Indians to join the internet).
> With most users possessing only dual-core machines (today), not having
> actual multicore support wasn't that bad. But with 8/16/32/special
> cores? And a lot more data to process?
>
> Even the CPU architects are concerned about this[6, page 35/36].
>
> Unfortunately weak typing and multithreading doesn't mix well and
> multithreading in general has many pitfalls.
> Jython/JRuby use the JVM to take advantage of its sophisticated runtime.
> But a threaded garbage collector and per-object locking seem to be
> anything but trivial and the JVM is a memory-hogging behemoth.
> JavaScript doesn't allow shared context at all and WebWorkers basically
> provide processes with bolted-on message passing.
> PHP seems to allow threading without actually being thread-safe...
> solves the problem by ignoring it ;)
> About others I'm not sure.
>
> What about Lua?
>
> Making the language itself multithreaded is obviously not going to
> happen. But creating many independent Lua states that are executed by
> multiple threads is easy!
>
> While starting hundreds or thousands of threads is not a good idea,
> having more independent program contexts than cores is very useful:
> - map one network connection to one Lua state, i.e. application servers
> - one state per user for multiuser applications
> - one state per view for GUI programs
> - process a directory recursively and have a state per directory
> - for divide-and-conquer strategies in general
> - partitioning of complex programs
>
> Compared to various other scripting languanges Lua has by far the
> fastest startup time by at least an order of magnitude. Btw check out
> `strace ruby -e "puts 'hello world'" 2>&1 | wc -l`, Ruby 2.5 needs
> 1790 syscalls for "hello world" (yes I know this example is unfair :))
>
> For Lua, one of my i5230M cores can create 100K states + load a
> precompiled script in *one second*. On x86_64 they use up ~700MB RAM
> afterwards.
>
> Unfortunately the reason why this is so fast is that the lua_States are
> basically empty. Loading just the standard library slows it down by a
> factor of 10.
>
> So, a theoretical future feature-rich standard library should support:
> - lazy binding/loading so that adding more functions doesn't impede
> state creation
> - thread safety or awareness of its functions (one C function could be
> called by multiple Lua states in parallel)
> - communication/synchronization between states
> - offloading of blocking calls into separate threads
> - some kind of compatibility header/subset of the C API so that minor
> changes in the language don't break existing library sources
>
> Conclusion:
> - It's 2020, a useful standard library must support real threading
> - And Lua states are handy since they provide separate contexts without
> giving up the user-friendly cooperative model
>
> It has always bummed me out that there is no agreed-on bigger standard
> library for Lua that is not directly meant for embedding. I mean it is
> also the perfect glue language, why isn't there anything ready to glue
> together?
>
> There are probably many "invisible" Lua users that are some kiddos that
> mod their favourite game and sooner or later want to create "real"
> applications outside of the host game.
>
> But they aren't full-blown programmers with an elaborate toolchain and a
> stack of reference books on their desks (yet ^^).
> So they download some things from the internet, fiddle around a bit and
> then give up on Lua...
>
> Providing them with a powerful and extensible, pre-compiled library
> would go a long way!
>
> I think due to its simple and divisible nature Lua *could* be a general
> purpose scripting language of the future!
>
> Best regards and a happy new year :)
>
> [1] "Inside the Python GIL"
> https://www.dabeaz.com/python/GIL.pdf
> [2] "Trends in Processor Architecture"
> https://arxiv.org/ftp/arxiv/papers/1801/1801.05215.pdf
> [3] "Ryzen 7 4700U: AMD's First Ever 8-Core APU"
> https://www.tomshardware.com/news/ryzen-7-4700u-amds-first-ever-8-core-apu
> [4] "Ericsson Mobility Report November 2019"
> https://www.ericsson.com/4acd7e/assets/local/mobility-report/documents/2019/emr-november-2019.pdf
> [5] "Cisco Visual Networking Index: Forecast and Trends, 2017–2022"
> https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/white-paper-c11-741490.pdf
> [6] "A New Golden Age for Computer Architecture"
> https://californiaconsultants.org/wp-content/uploads/2018/04/CNSV-1806-Patterson.pdf
>

Reply | Threaded
Open this post in threaded view
|

Re: Multi-Threading (Was: New Batteries? (Was: Dead Batteries))

Oliver Schmidt
In reply to this post by Stefan-2
Hi,

On 07.01.20 04:02, Stefan wrote:
> Python's insufficient thread support is a *big* disadvantage.
> But soon this will become very important!
> What about Lua?
> Making the language itself multithreaded is obviously not going to happen. But
> creating many independent Lua states that are executed by multiple threads is easy!
> - It's 2020, a useful standard library must support real threading
> - And Lua states are handy since they provide separate contexts without giving
> up the user-friendly cooperative model

you might want to have a look at my lua multi-threading modules, especially
"mtstates" for using lua states accross threads, see
http://lua.2524044.n2.nabble.com/ANN-multi-threading-tools-mtmsg-mtstates-amp-mtint-td7684427.html

Best regards,
Oliver


Reply | Threaded
Open this post in threaded view
|

Is Kepler Project dead?

Stefan-2
Hello,

the Kepler Project website ( http://www.keplerproject.org ) seems
to be hijacked - in 2017 it has gained an ominous "Blog" section
with topics like "How to Get Your Dog to Smell Nicer" and various
links to Singaporean web sites.
https://web.archive.org/web/20170925220702/http://www.keplerproject.org/

Downloading anything here is likely a really bad idea, yet
LuaBinaries links to it; and lua.org links to LuaBinaries.
The github repositories ( https://github.com/keplerproject ) seem
to be still updated, however.

Is anybody here responsible for this web page? It only has an
anonymous contact form and a dead mailing list.

Greetings

Reply | Threaded
Open this post in threaded view
|

Re: Is Kepler Project dead?

Fabio Mascarenhas
Hey Stefan,

The domain name lapsed out of my control a few years ago and it seems to have been taken over by a spammer, for which I am very sorry.

I have contacted the owner of LuaBinaries to remove the link.

This is the first time I have seen an expired domain name takeover using a mixture of the original content of the site and spam, something new learned today!

The page itself was deactivated for a while, that's why the domain ended up lapsing.

--
Fabio Mascarenhas

On Wed., Jan. 8, 2020, 11:51 a.m. Stefan, <[hidden email]> wrote:
Hello,

the Kepler Project website ( http://www.keplerproject.org ) seems
to be hijacked - in 2017 it has gained an ominous "Blog" section
with topics like "How to Get Your Dog to Smell Nicer" and various
links to Singaporean web sites.
https://web.archive.org/web/20170925220702/http://www.keplerproject.org/

Downloading anything here is likely a really bad idea, yet
LuaBinaries links to it; and lua.org links to LuaBinaries.
The github repositories ( https://github.com/keplerproject ) seem
to be still updated, however.

Is anybody here responsible for this web page? It only has an
anonymous contact form and a dead mailing list.

Greetings

Reply | Threaded
Open this post in threaded view
|

Re: Is Kepler Project dead?

pocomane

On Thu 9 Jan 2020, 03:06 Fabio Mascarenhas, <[hidden email]> wrote:
I have contacted the owner of LuaBinaries to remove the link.

What about the links in the GitHub repos? E.g. keplerproject/kepler stills mentions www.keplerproject.org in the description.

Reply | Threaded
Open this post in threaded view
|

Re: Is Kepler Project dead?

Stefan-2
In reply to this post by Fabio Mascarenhas
Am 09.01.2020 um 03:05 schrieb Fabio Mascarenhas:

> Hey Stefan,
>
> The domain name lapsed out of my control a few years ago and it seems to
> have been taken over by a spammer, for which I am very sorry.
>
> I have contacted the owner of LuaBinaries to remove the link.
>
> This is the first time I have seen an expired domain name takeover using
> a mixture of the original content of the site and spam, something new
> learned today!
>
> The page itself was deactivated for a while, that's why the domain ended
> up lapsing.
>
> --
> Fabio Mascarenhas
>
Hey Fabio,

I too haven't seen such a scavenging yet. Glad you reacted so fast.
Flagging the site on Google/Bing would also be an option.

Greetings

Reply | Threaded
Open this post in threaded view
|

Re: Is Kepler Project dead?

Fabio Mascarenhas
Hey Stefan,

Antonio Scuri, the LuaBinaries maintainer, has already fixed the link in the LuaBinaries home page.

Technically the rogue site is engaging in copyright violation by using the original text of the Kepler wiki as part of it, I am looking how I can request a DNS takedown with that basis...

--
Fabio Mascarenhas

On Thu., Jan. 9, 2020, 9:31 a.m. Stefan, <[hidden email]> wrote:
Am 09.01.2020 um 03:05 schrieb Fabio Mascarenhas:
> Hey Stefan,
>
> The domain name lapsed out of my control a few years ago and it seems to
> have been taken over by a spammer, for which I am very sorry.
>
> I have contacted the owner of LuaBinaries to remove the link.
>
> This is the first time I have seen an expired domain name takeover using
> a mixture of the original content of the site and spam, something new
> learned today!
>
> The page itself was deactivated for a while, that's why the domain ended
> up lapsing.
>
> --
> Fabio Mascarenhas
>
Hey Fabio,

I too haven't seen such a scavenging yet. Glad you reacted so fast.
Flagging the site on Google/Bing would also be an option.

Greetings

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Steve Litt
In reply to this post by Dibyendu Majumdar
On Sun, 5 Jan 2020 22:00:15 +0000
Dibyendu Majumdar <[hidden email]> wrote:

> On Sun, 5 Jan 2020 at 21:51, Lorenzo Donati
> <[hidden email]> wrote:
>
> > OTOH the lack of such batteries greatly hamper the diffusion of Lua
> > as a general purpose language.
> >  
>
> Well Python is arguably a better general purpose language

Only because batteries.


> and has a
> very powerful set of libraries. Why does the world need another one?

Personally speaking, so I can have a batteries included language whose
only complex datatypes are table and metatable.

As far as the question "why does the world need another one?", one
could have asked that about C, because you can do *anything* with C. It
might take ten times more code, it might tremendously increase the
likelihood of errant pointers and buffer overruns, but C is the
ultimate general purpose language: Why do we need another one?

Just as a point of information, I recommended a curated group of
add-ons be in a separate package, not in the Lua package. That way
embedded programmers can use just Lua.
 
SteveT

Steve Litt
January 2020 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Dibyendu Majumdar
On Thu, 9 Jan 2020 at 20:44, Steve Litt <[hidden email]> wrote:

>
> On Sun, 5 Jan 2020 22:00:15 +0000
> Dibyendu Majumdar <[hidden email]> wrote:
>
> > On Sun, 5 Jan 2020 at 21:51, Lorenzo Donati
> > <[hidden email]> wrote:
> >
> > > OTOH the lack of such batteries greatly hamper the diffusion of Lua
> > > as a general purpose language.
> > >
> >
> > Well Python is arguably a better general purpose language
>
> Only because batteries.
>

Not only because of. In my experience Python is a more user friendly
language. Lua is more geek friendly.

>
> > and has a
> > very powerful set of libraries. Why does the world need another one?
>
> Personally speaking, so I can have a batteries included language whose
> only complex datatypes are table and metatable.
>
> As far as the question "why does the world need another one?", one
> could have asked that about C, because you can do *anything* with C. It
> might take ten times more code, it might tremendously increase the
> likelihood of errant pointers and buffer overruns, but C is the
> ultimate general purpose language: Why do we need another one?
>

Of course a new language is always possible, but in general, languages
fit into specific niches. Lua is successful because it fits into its
own niche. It cannot and should not be a Python replacement.

> Just as a point of information, I recommended a curated group of
> add-ons be in a separate package, not in the Lua package. That way
> embedded programmers can use just Lua.
>

I think Lua team have endorsed LuaRocks - that is as far as it will
ever go probably.
To do anything better is significantly more difficult and requires a
huge amount of effort. I know this because I am trying to create a
small let of libraries in Suravi.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Steve Litt
On Sat, 11 Jan 2020 01:42:57 +0000
Dibyendu Majumdar <[hidden email]> wrote:

> On Thu, 9 Jan 2020 at 20:44, Steve Litt <[hidden email]>
> wrote:
> >
> > On Sun, 5 Jan 2020 22:00:15 +0000
> > Dibyendu Majumdar <[hidden email]> wrote:

> > > Well Python is arguably a better general purpose language  
> >
> > Only because batteries.
> >  
>
> Not only because of. In my experience Python is a more user friendly
> language. Lua is more geek friendly.

The "Python is more user friendly" might have some merit, but the
question is which is a "better general purpose language". Any user
friendliness criteria are dwarfed by the fact that Lua's syntax is
simple and it has only two types of complex data: Table and Metatable.
IMHO Lua, *as a language*, is both more powerful and easier to
understand.

>
> >  
> > > and has a
> > > very powerful set of libraries. Why does the world need another
> > > one?  
> >
> > Personally speaking, so I can have a batteries included language
> > whose only complex datatypes are table and metatable.
> >
> > As far as the question "why does the world need another one?", one
> > could have asked that about C, because you can do *anything* with
> > C. It might take ten times more code, it might tremendously
> > increase the likelihood of errant pointers and buffer overruns, but
> > C is the ultimate general purpose language: Why do we need another
> > one?
>
> Of course a new language is always possible, but in general, languages
> fit into specific niches. Lua is successful because it fits into its
> own niche. It cannot and should not be a Python replacement.

You can repeat your assertion a hundred times, but it's still just your
opinion. If Python and Lua had equally capable and reliable "batteries",
I'm pretty sure that Lua would be more productive not only in the
embedded arena, but in office automation, data processing, conversions,
and web apps.

>
> > Just as a point of information, I recommended a curated group of
> > add-ons be in a separate package, not in the Lua package. That way
> > embedded programmers can use just Lua.
> >  
>
> I think Lua team have endorsed LuaRocks - that is as far as it will
> ever go probably.

Luarocks is a package manager, not a group of applications.

> To do anything better is significantly more difficult

Yes it is.

> and requires a
> huge amount of effort.

Yes it does.

But given the fact that Lua, as it has existed for the past five years,
is a pretty much perfect language, curating a group of approved add-ons
would be the best way to improve Lua.

SteveT

Steve Litt
January 2020 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Dibyendu Majumdar
On Wed, 15 Jan 2020 at 16:59, Steve Litt <[hidden email]> wrote:

>
> But given the fact that Lua, as it has existed for the past five years,
> is a pretty much perfect language, curating a group of approved add-ons
> would be the best way to improve Lua.
>

http://lua-users.org/lists/lua-l/2018-01/msg00392.html
http://lua-users.org/lists/lua-l/2018-01/msg00513.html
http://lua-users.org/lists/lua-l/2018-03/msg00096.html

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Dibyendu Majumdar
In reply to this post by Steve Litt
On Wed, 15 Jan 2020 at 16:59, Steve Litt <[hidden email]> wrote:

> > Not only because of. In my experience Python is a more user friendly
> > language. Lua is more geek friendly.
>
> The "Python is more user friendly" might have some merit, but the
> question is which is a "better general purpose language". Any user
> friendliness criteria are dwarfed by the fact that Lua's syntax is
> simple and it has only two types of complex data: Table and Metatable.
> IMHO Lua, *as a language*, is both more powerful and easier to
> understand.
>

Well looks like I have diametrically opposite opinion. Mixing arrays
and maps in a single data structure was a big mistake in my view!
Ditto for exposing metatables. Both of these are 'clever' things but
leak implementation details out which always causes grief in the long
run. These and a few other features are why I called Lua a geek
friendly language.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Dead Batteries

Sean Conner
It was thus said that the Great Dibyendu Majumdar once stated:

> On Wed, 15 Jan 2020 at 16:59, Steve Litt <[hidden email]> wrote:
> > > Not only because of. In my experience Python is a more user friendly
> > > language. Lua is more geek friendly.
> >
> > The "Python is more user friendly" might have some merit, but the
> > question is which is a "better general purpose language". Any user
> > friendliness criteria are dwarfed by the fact that Lua's syntax is
> > simple and it has only two types of complex data: Table and Metatable.
> > IMHO Lua, *as a language*, is both more powerful and easier to
> > understand.
> >
>
> Well looks like I have diametrically opposite opinion. Mixing arrays
> and maps in a single data structure was a big mistake in my view!

  I can see that.  I also think that Roberto & Co. could have more clearly
stated the reasons for adding boolean types to the language (so you could
mark a missing array element with 'false' instead of 'nil').

> Ditto for exposing metatables.

  So what's the issue with exposing metatables?  Python has its own form of
operator overloading.

  -spc


123