[mildly OT] Some info about Python

classic Classic list List threaded Threaded
121 messages Options
1 ... 34567
Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Enrico Colombini
On 04-Feb-20 13:47, Fernando Jefferson wrote:

> Enrico:
>
> I miss using RPN (Reverse Polish Notation) on my HP29C, (please see
> photo) with 32 memories (16 of them continuous, 16 volatile), 100
> programming steps ...
>
> All this in the past millennium ...
>
> If you think you are a dinosaur for this, what would I be, starting to
> program on the Intel 8008 in 1973?

This list seems to have its fair share of dinos... er, people from the
computer revolution era ;-)

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Enrico Colombini
It was thus said that the Great Enrico Colombini once stated:
> On 04-Feb-20 00:46, Sean Conner wrote:
> >
> >   -spc (Thining of bowing out of the whole batteries thang for Lua---it's
> > just not worth the effort because of laziness on the part of
> > everybody else ... )
>
> Uh... your honor, I plead guilty here.
> That's one of the reasons I think a small-steps policy would be easier
> to pursue.

  Hey, I'm guilty as well.  We all are.  We all want someone else (or a
bunch of someone elses) to start the ball rolling, and keep it rolling for
some time and then maybe join in.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Pierre Chapuis
In reply to this post by Peter Drahoš
On Tue, Feb 4, 2020, at 13:07, Peter Drahoš wrote:
If there is still any interest in LuaDist[1] I do have an unpublished development version with the following feature set:

The feature list sounds awesome, except for "unpublished" :)

What are the LuaRocks build types supported automatically? builtin and cmake?

-- 
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Roberto Ierusalimschy
In reply to this post by Enrico Colombini
> Anyway, I still think 'a step at a time' would be the best policy. First
> step a stable, 'blessed' library.

I would break the steps even further: first step is a stable library.
Nobody can bless anything unstable.


> Then there is the matter of stability: Lua getting better is a great thing
> but, on the other hand, it is hard to build a large user base on shifting
> foundations. An industrial client of mine still develops in Python 2.7
> because splitting the codebase would be a huge headache for re-testing and
> maintenance of machinery installed around the world.
>
> But supporting multiple Lua versions for each module could be hard work (and
> no, I don't see a simple solution to this dilemma).

I may be wrong, but I think the main problem is that several libraries
are just not being maintained. Usually, it is not that hard to adapt
a library to different Lua versions. I agree that sometimes is not
easy, but I don't think that is the main issue. Just in case, I
volunteer to help any maintainer who are having technical problems
in updating a library to a new Lua version.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Dibyendu Majumdar
> I may be wrong, but I think the main problem is that several libraries
> are just not being maintained. Usually, it is not that hard to adapt
> a library to different Lua versions. I agree that sometimes is not
> easy, but I don't think that is the main issue. Just in case, I
> volunteer to help any maintainer who are having technical problems
> in updating a library to a new Lua version.
>

In my efforts I found the effort goes into following areas:

a) Library may have been written with LuaJIT in mind, hence dependency
on LuaJIT's ffi. The Torch libraries are an example of this. I have
been removing the ffi dependency gradually.
b) Library is not portable - assumes Posix or Linux environment. Again
with Torch libraries this was an issue - I had to fix the libraries to
work on Windows.
c) Library may be relying on LuaJIT's bit library - e.g. dynasm.
d) Diversity of build systems - in my view having something like CMake
makes it easier to maintain the library across common platforms.
e) Unmaintained with regards to Lua versions - i.e. library was never
updated to work with 5.3. The question is whether the library is
useful enough to put the effort in upgrading it.

The harder problems are duplication in functionality and overlap.
The worst example of this are the testing libraries - everyone seems
to use their own favourite. So then you have a dependency on a
multitude of testing frameworks, some of which are quite large and
complex.

Anyway, one of the fundamental questions is what platforms should be
supported. I have taken the view that at least 64-bit Windows, Linux
and Mac OSX must be supported.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Luiz Henrique de Figueiredo
> e) Unmaintained with regards to Lua versions - i.e. library was never
> updated to work with 5.3. The question is whether the library is
> useful enough to put the effort in upgrading it.

Is this very frequent? I mean, what in 5.3 prevents a 5.2 or 5.1
library to run in Lua 5.3?

At the other extreme, in 2018 I reworked my libraries to use a single
source that targets 5.3 but includes with a simple compat header that
can handle 5.2 and 5.1 (and even 5.0, if the need for that ever
arose). I'm very happy with the libraries now.

My libraries also build out of the box in Linux and macOS, if Lua is
installed in the standard places. I also wrote a Makefile that was
supposed to be LuaRocks friendly but I never could get a confirmation
that the simple rock I wrote was the right thing. And so unfortunately
I haven't uploaded rocks for my libraries. (Some kind people have done
but I'm not sure they are for my current libraries.)

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Dibyendu Majumdar
> > e) Unmaintained with regards to Lua versions - i.e. library was never
> > updated to work with 5.3. The question is whether the library is
> > useful enough to put the effort in upgrading it.
>
> Is this very frequent? I mean, what in 5.3 prevents a 5.2 or 5.1
> library to run in Lua 5.3?
>

Maybe not. I have two examples I was interested in:

https://github.com/carvalho/numlua
http://metalua.luaforge.net/

In the end regarding the first use case I chose Torch.
Porting any library is an effort for someone ... and you don't know
how much effort until you start.

> At the other extreme, in 2018 I reworked my libraries to use a single
> source that targets 5.3 but includes with a simple compat header that
> can handle 5.2 and 5.1 (and even 5.0, if the need for that ever
> arose). I'm very happy with the libraries now.
>
> My libraries also build out of the box in Linux and macOS, if Lua is
> installed in the standard places. I also wrote a Makefile that was
> supposed to be LuaRocks friendly but I never could get a confirmation
> that the simple rock I wrote was the right thing. And so unfortunately
> I haven't uploaded rocks for my libraries. (Some kind people have done
> but I'm not sure they are for my current libraries.)
>

I am interested in your maths libraries and would be happy to include
in Suravi, but some of them appear to have external dependencies (and
on Windows these dependencies can be a problem), and I do not know if
you have documentation for any - documentation is essential for people
to use a library. I would recommend putting them all the libraries in
github.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Luiz Henrique de Figueiredo
It was thus said that the Great Luiz Henrique de Figueiredo once stated:
> > e) Unmaintained with regards to Lua versions - i.e. library was never
> > updated to work with 5.3. The question is whether the library is
> > useful enough to put the effort in upgrading it.
>
> Is this very frequent? I mean, what in 5.3 prevents a 5.2 or 5.1
> library to run in Lua 5.3?

  First off, module() is no longer in Lua 5.2+, so there's that.  Then there
are some C API changes (not many) that require some work arounds.

  For Lua based modules, I did the following:

        local _VERSION = _VERSION
        if _VERSION == "Lua 5.1" then
          module(...)
        else
          _ENV = {}
        end

        -- rest of module

        if _VERSION >= "Lua 5.2" then
          return _ENV
        end

  And that pretty much did the work.  For the C-based modules, I've found
these work:

#if LUA_VERSION_NUM == 501
#  define lua_rawlen(L,idx)       lua_objlen((L),(idx))
#  define luaL_setfuncs(L,reg,up) luaL_register((L),NULL,(reg)) // [1]
#  define lua_getuservalue(L,idx) lua_getfenv((L),(idx))
#  define lua_setuservalue(L,idx) lua_setfenv((L),(idx))
#endif

and this (per module):

#if LUA_VERSION_NUM == 501
  luaL_register(L,"org.conman.clock",m_clock_reg);
#else
  luaL_newlib(L,m_clock_reg);
#endif

  The changes were quite minimal for my stuff.  For others---eh.  One module
I use, LuaXML is a mess.  First, the project is LuaXML. What you use in
require() is "LuaXml", and it pollutes the global namespace (because it's
for Lua 5.1) with "xml" (and expects that to be in the global space or it
won't work).  That one took a bit of effort to get working on Lua 5.2 and
above.

  -spc

[1] Or

#if LUA_VERSION_NUM == 501
#  define luaL_setfuncs(L,reg,up) luaI_openlib((L),NULL,(reg),(up))
#endif

        if I have upvalues I need to set.  It may be hacky, but it works.

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Enrico Colombini
It was thus said that the Great Enrico Colombini once stated:
>
> But supporting multiple Lua versions for each module could be hard work
> (and no, I don't see a simple solution to this dilemma).

  I've found it to be rather easy.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Petite Abeille
In reply to this post by Sean Conner


> On Feb 4, 2020, at 23:00, Sean Conner <[hidden email]> wrote:
>
>  First off, module() is no longer in Lua 5.2+, so there's that.

Perhaps we should all (re)read the epic discussions we had nearly 10 years ago on the subject:

http://lua-users.org/lists/lua-l/2011-10/msg00532.html

Good luck.




Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Luiz Henrique de Figueiredo
In reply to this post by Dibyendu Majumdar
> I am interested in your maths libraries and would be happy to include
> in Suravi, but some of them appear to have external dependencies

My libraries now are all self-contained: the package contains
third-party code. The exception is lgdbm, which downloads and build
gdbm.

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Peter Drahoš
In reply to this post by Pierre Chapuis


On Feb 4, 2020, at 7:20 PM, Pierre Chapuis <[hidden email]> wrote:
The feature list sounds awesome, except for "unpublished" :)
Yeah, sorry for that. I rarely get time to work on any of it, hence LuaDist has not been updated in a long time ...

What are the LuaRocks build types supported automatically? builtin and cmake?

Exactly, builtin usually works fine as long as I can find external libraries, I convert these to CMake builds internally. CMake modules work fine but command and make modules are unusable ..

pd
Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Pierre Chapuis
In reply to this post by Sean Conner
On Tue, Feb 4, 2020, at 23:00, Sean Conner wrote:

>   First off, module() is no longer in Lua 5.2+, so there's that.

module() is annoying but relatively easy to change, and the new way works with 5.1.

When I port from 5.1 while keeping 5.1 support, environments are more annoying for me, because the new way is not backward-compatible. It is possible to implement something that works like setfenv / getfenv [1] but there are gotchas.

[1] https://leafo.net/guides/setfenv-in-lua52-and-above.html

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Luiz Henrique de Figueiredo
In reply to this post by Fernando Jefferson-2
On Wed, Feb 5, 2020 at 8:44 AM Fernando Jefferson
<[hidden email]> wrote:
>
> If you think you are a dinosaur for this, what would I be, starting to program on the Intel 8008 in 1973?

It makes you the the oldest dinosaur around. :-)

I started programming in assembly under the supervision of Fernando
Jefferson in the early 1980's. I think it was a Z80 by then, running
CP/M. I vaguely remember a paper tape, and perhaps also 8" floppies.
It was an informal internship: no paperwork, no pay, no hours.
Fernando just let me hang around the lab and do stuff. I'm very
thankful for having had this opportunity. It was a quiet place with
cool machines and lots to learn. A good change from Fortran in an IBM
mainframe, which I had been doing before.

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Thorkil Naur
Hello List,

On Wed, Feb 05, 2020 at 08:58:38AM -0300, Luiz Henrique de Figueiredo wrote:
> ...
> It makes you the the oldest dinosaur around. :-)

Well, age is not actually mentioned. But how about Olivetti Programma
P101 and Regnecentralen GIER in 1972 which is how my programming
activities started?

(Specimens of both these machines are actually in working order at
datamuseum.dk, magnetic cards, paper tape, and all. So we are having
great fun.)

> ...

Best
Thorkil

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Doug Currie
Yes, Thorkil! I also used an Olivetti Programma 101 at Yale University and in industry in 1971/1972.

e


On Wed, Feb 5, 2020 at 12:05 PM Thorkil Naur <[hidden email]> wrote:
Hello List,

On Wed, Feb 05, 2020 at 08:58:38AM -0300, Luiz Henrique de Figueiredo wrote:
> ...
> It makes you the the oldest dinosaur around. :-)

Well, age is not actually mentioned. But how about Olivetti Programma
P101 and Regnecentralen GIER in 1972 which is how my programming
activities started?

(Specimens of both these machines are actually in working order at
datamuseum.dk, magnetic cards, paper tape, and all. So we are having
great fun.)

> ...

Best
Thorkil

Reply | Threaded
Open this post in threaded view
|

A great honor for me ...

Fernando Jefferson-2
In reply to this post by Luiz Henrique de Figueiredo

It is a great honor for me this testimony from one of the creators of Lua.

It really was another time.

Better times? I do not know ...

But certainly a lot of fun!

Fernando Jefferson
CCE-PUC-Rio - Professor
Projeto UpLua - Coordinator
Cel: +5521-99763-2135

 

Em 2020-02-05 08:58, Luiz Henrique de Figueiredo escreveu:

On Wed, Feb 5, 2020 at 8:44 AM Fernando Jefferson
<[hidden email]> wrote:

If you think you are a dinosaur for this, what would I be, starting to program on the Intel 8008 in 1973?

It makes you the the oldest dinosaur around. :-)

I started programming in assembly under the supervision of Fernando
Jefferson in the early 1980's. I think it was a Z80 by then, running
CP/M. I vaguely remember a paper tape, and perhaps also 8" floppies.
It was an informal internship: no paperwork, no pay, no hours.
Fernando just let me hang around the lab and do stuff. I'm very
thankful for having had this opportunity. It was a quiet place with
cool machines and lots to learn. A good change from Fortran in an IBM
mainframe, which I had been doing before.

 

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

Re: [mildly OT] Some info about Python

Lorenzo Donati-3
In reply to this post by Andrew Starks-2
On 03/02/2020 03:02, Andrew Starks wrote:

>
>> On Feb 2, 2020, at 04:43, Lorenzo Donati
>> <[hidden email]> wrote:
>>
>> The "we have no standard library" issue is not a technical problem
>> in the first place, but a management and (partly) a social one,
>> IMO.
>
> What if an organization, such as the Linux Foundation, would agree to
> host such an organization? Perhaps they would agree to help With
> marketing, trade shows, other exposure, provide a governance
> framework, etc.?
>
> Assuming they would do it with the blessings of PUC/Rio, do you think
> something like that would help?
>
> -Andrew
>

It's not a bad idea, in principle. I see just some practical obstacles:

1. As you point out, would Lua team endorse such an effort? I strongly
believe that with no such endorsement any initiative is doomed to fail.
That's a big prerequisite.

2. It should take care also of the Windows "part" of the job, which is
not obvious it would happen. And I think Lua shouldn't become a
"*NIX"-only thing, also because most non professional devs are probably
Windows users (and that's a big market share).
Would the Linux foundation care to support Windows in a neutral and
on-par way, without trying to win users for Linux or biasing its efforts
toward Linux Lua distros?


3. Still we would need guidance and policies to define guidelines for
the whole library. Just start coding and trying to come up with an API
wouldn't work, IMO. We already have some libraries. We should strive for
a consensus about:

A. What common problems the /standard/ library should tackle.

B. What the structure of "The Library" should be (modules naming
conventions, namespacing, disk layout, how to cope with new modules,
etc.). How a single module should be organized to support
backward/forward compatibility?

C. What "look and feel" should "The Libray" have? what style the APIs
(plural!) should have (having a uniform API style across modules helps a
lot in usability and documentation)? What error reporting style would it
use? Are debugging facility for the library be consistent across
modules? Should we have a "framework" for error reporting/unit testing/
debugging (also usable by client code), or do we need to use a simpler
set of very basic facilities (small modules, no framework-like) that
every module writer should use to integrate it in the library.

D. How would a module be accepted in the library; how to accomodate
developers with few time to spend on maintenance (copyright should be
transferred to the "foundation"? The "foundation" should allocate dev
resources?). Maybe some devs wants to contribute with few hours a month,
are there modules where many devs can work only for limited time? Maybe
use their time to build unit tests?
Someone has to decide all this.

I repeat "LOT of policy" if we want to avoid past mistakes and really
want to build a solid, stable, backward/forward compatible and
future-proof code base, to which big and small contributions can be
integrated in a harmonic way. More so, if we want the library to be more
Lua-like than Python-like.

A good "Standard Library" is not (should not?) be just an enormous
collection of sticked together code.

I'm not saying it's easy, on the contrary, we failed many times because
it is not easy at all. Good management is all but easy (and few
developers, in my experience, are also good managers)!

Disclaimer: I'm not at all a manager type (/defintely/ not), but I can
recognize a good manager when I get to know one.

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Dibyendu Majumdar
In reply to this post by Luiz Henrique de Figueiredo
On Tue, 4 Feb 2020 at 23:41, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>
> > I am interested in your maths libraries and would be happy to include
> > in Suravi, but some of them appear to have external dependencies
>
> My libraries now are all self-contained: the package contains
> third-party code. The exception is lgdbm, which downloads and build
> gdbm.
>

Okay that's great. I had a quick look at some of them. I think the one
on complex numbers and the qd wrapper are the two I might look at.
The QD license is a concern.

I have a version of cephes now with all dependency on LuaJIt ffi
removed. https://github.com/dibyendumajumdar/ravi-torch-cephes
However work is need for complex functions and also functions that
accept arrays - as the binding generator I used (Torch cwrap) doesn't
support these out of the box.
I might look at adapting your complex library to work with cephes.

The Torch wrapper for cephes allows applying cephes functions on
tensors. Seems to work after my attempt to remove ffi - but not very
well tested.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Lorenzo Donati-3
It was thus said that the Great Lorenzo Donati once stated:

> On 03/02/2020 03:02, Andrew Starks wrote:
> >
> >>On Feb 2, 2020, at 04:43, Lorenzo Donati
> >>
> >>The "we have no standard library" issue is not a technical problem
> >>in the first place, but a management and (partly) a social one,
> >>IMO.
> >
> >What if an organization, such as the Linux Foundation, would agree to
> >host such an organization? Perhaps they would agree to help With
> >marketing, trade shows, other exposure, provide a governance
> >framework, etc.?
> >
> >Assuming they would do it with the blessings of PUC/Rio, do you think
> >something like that would help?
>
> It's not a bad idea, in principle. I see just some practical obstacles:
>
> 1. As you point out, would Lua team endorse such an effort? I strongly
> believe that with no such endorsement any initiative is doomed to fail.
> That's a big prerequisite.
>
> 2. It should take care also of the Windows "part" of the job, which is
> not obvious it would happen. And I think Lua shouldn't become a
> "*NIX"-only thing, also because most non professional devs are probably
> Windows users (and that's a big market share).
> Would the Linux foundation care to support Windows in a neutral and
> on-par way, without trying to win users for Linux or biasing its efforts
> toward Linux Lua distros?

  And that's a problem because Windows doesn't come with a development
system by default.  And from what I understand listening to complaints about
Windows on this list over the years, if you use one tool chain, you often
can't mix artifacts from another tool chain.

  I mean, if it were up to me, I'd say "screw Windows!" but I know that is a
very unpopluar opinion 8-)

> 3. Still we would need guidance and policies to define guidelines for
> the whole library. Just start coding and trying to come up with an API
> wouldn't work, IMO. We already have some libraries. We should strive for
> a consensus about:
>
> A. What common problems the /standard/ library should tackle.

  There was a list Dibyendu gave a two years ago [1]:

        - lpeg
        - luafilesystem
        - luasocket
        - libuv (Luvit)
        - libcurl (wrapper tbc)
        - lua-cjson
        - torch7
        - luaossl
        - cephes (wrapper tbc)
        - luaffifb (port of LuaJIT FFI interface)

  Some, I agree with, some I don't.  But that list is a start.

  But the bigger issue is the overlap and difficult composability (or
interoperability) of modules.  This stems from two issues---a module covers
too much territory, and the non-Luaish nature of most modules.  I've
commented before on non-Luaish modules [2].  I have always contended that
C-based modules should be more Luaish, but most people are lazy, do the the
simplist thing (wrap a C-API in a Lua API that mimics the C-API) and never
bother to make a higher level Lua API (if that makes any sense).

> B. What the structure of "The Library" should be (modules naming
> conventions, namespacing, disk layout, how to cope with new modules,
> etc.). How a single module should be organized to support
> backward/forward compatibility?

  Again, that's hard and my own solutions isn't popular (nor well understood
by some people).  And even with my own solution, I have made some blunders.
Naming is one of the three most difficult things in computer science (the
other being cache invalidation and off-by-one errors).

> C. What "look and feel" should "The Libray" have? what style the APIs
> (plural!) should have (having a uniform API style across modules helps a
> lot in usability and documentation)? What error reporting style would it
> use?

  I've been working on a standard library, and for error reporting, I've
been using the method used by the io library:

        thing[,errs,erri] = functioncall()

where 'thing' is either the object, or nil, and when it's nil, the other two
values are an error string and error number.  I'm not happy with the
returning of the error string, but I can see why Roberto went with that
approach.  I personally prefer the error number, but ANSI C only defines
three values:

        EDOM
        ERANGE
        EILSEQ -- C99

  I'm not a fan of error() in general (or exceptions) but I will agree that
they can be useful in some cases.  

> Are debugging facility for the library be consistent across
> modules? Should we have a "framework" for error reporting/unit testing/
> debugging (also usable by client code), or do we need to use a simpler
> set of very basic facilities (small modules, no framework-like) that
> every module writer should use to integrate it in the library.

  I'm more in favor of library approaches over frameworks, but it's becoming
clear to me that *some* framework for network (or advanced file I/O) is
probably required.  I prefer modules that have a definite focus on one type
of problem, say directory manipulation, rather than a "kitchen-sink"
approach.

> D. How would a module be accepted in the library; how to accomodate
> developers with few time to spend on maintenance (copyright should be
> transferred to the "foundation"? The "foundation" should allocate dev
> resources?). Maybe some devs wants to contribute with few hours a month,
> are there modules where many devs can work only for limited time? Maybe
> use their time to build unit tests?
> Someone has to decide all this.
>
> I repeat "LOT of policy" if we want to avoid past mistakes and really
> want to build a solid, stable, backward/forward compatible and
> future-proof code base, to which big and small contributions can be
> integrated in a harmonic way. More so, if we want the library to be more
> Lua-like than Python-like.
>
> A good "Standard Library" is not (should not?) be just an enormous
> collection of sticked together code.
>
> I'm not saying it's easy, on the contrary, we failed many times because
> it is not easy at all. Good management is all but easy (and few
> developers, in my experience, are also good managers)!
>
> Disclaimer: I'm not at all a manager type (/defintely/ not), but I can
> recognize a good manager when I get to know one.

  -spc (Not much to add ... )

[1] http://lua-users.org/lists/lua-l/2018-01/msg00513.html

[2] Some examples:
        http://lua-users.org/lists/lua-l/2013-11/msg00400.html
        http://lua-users.org/lists/lua-l/2015-03/msg00001.html

1 ... 34567