[NoW] Missing things from Lua

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

[NoW] Missing things from Lua

Sean Conner

  I suppose if Egor Skriptunoff can do "Nitpicking on Wednesdays", others
can as well, so here are two small nitpicks I have about Lua:

1) The constant LUA_BUFFERSIZE is not available in Lua.  There should be a
constant, io.BUFFERSIZE, defined to be this value.  There are instances
where this would be nice to have.

2) There is os.setlocale(), but not os.localeconv().  It would not be hard
to write, and it should return a table formatted (at least) like:

[spc]lucy:/tmp>lua xx.lua se_NO.UTF-8
locale =
{
  thousands_sep = ".",
  n_cs_precedes = true,
  frac_digits = 2,000000,
  current_symbol = " ru",
  int_curr_symbol = "NOK ",
  mon_thousands_sep = ".",
  mon_grouping =
  {
    [1] = 3,000000,
    _isrepeating = true,
  },
  int_frac_digits = 2,000000,
  negative_sign = "-",
  mon_decimal_point = ",",
  decimal_point = ",",
  n_sign_posn = 4,000000,
  grouping =
  {
    [1] = 3,000000,
    [2] = 3,000000,
    _isrepeating = true,
  },
  p_sign_posn = 4,000000,
  n_sep_by_space = false,
  p_sep_by_space = false,
  positive_sign = "",
  p_cs_precedes = true,
}

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

dyngeccetor8
On 16/05/2019 01.25, Sean Conner wrote:

> 2) There is os.setlocale(), but not os.localeconv().  It would not be hard
> to write, and it should return a table formatted (at least) like:
>
> [spc]lucy:/tmp>lua xx.lua se_NO.UTF-8
> locale =
> {
>   thousands_sep = ".",
>   n_cs_precedes = true,
>   frac_digits = 2,000000,
> [...]>
>   -spc

The "fun" thing is that Lua tries not to use tables to return
results. Yes, because they will occupy memory till next __gc.

So proposed os.localeconv() will probably return string with
values in fixed order, separated by newline. (String will
occupy memory too but will not have duplicates by design.)

And Lua does not use tables to get arguments too. Probably
because it's uncomfortable to prepare table argument in C.
It again uses strings and list of parameters.

For example, load() accept 4 parameters. Anyone remembers order?
debug.getinfo() get options from string. And I need reference card
to know that "S" there means "include source" and "l" means
"include current line".

At least debug.getinfo() returns result as table, rare exception.
Along with os.date() and os.time().

I wish standard Lua libraries use more Lua tables both for
arguments and results.

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Roberto Ierusalimschy
In reply to this post by Sean Conner
> 1) The constant LUA_BUFFERSIZE is not available in Lua.  There should be a
> constant, io.BUFFERSIZE, defined to be this value.  There are instances
> where this would be nice to have.

What for?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Dirk Laurie-2
In reply to this post by Sean Conner
I'm latching to the subject, not the post. Some time ago I posted:
~~~
By analogy to the function utf8.codes, it would be nice to have a
function string.bytes so that the construction

     for p, c in string.bytes(s) do body end

will iterate over all bytes in string s, with p being the position.
This is surprisingly clumsy in pure Lua, unless I am missing a trick.
~~~
in reply to which somebody was kind enough to post Lua code
illustrating my point.

-- Dirk

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Paul K-2
Hi Dirk,

>      for p, c in string.bytes(s) do body end
> will iterate over all bytes in string s, with p being the position.
> This is surprisingly clumsy in pure Lua, unless I am missing a trick.

`s:gmatch("()(.)")`? Or am I missing something?

Paul.

On Thu, May 16, 2019 at 8:52 AM Dirk Laurie <[hidden email]> wrote:

>
> I'm latching to the subject, not the post. Some time ago I posted:
> ~~~
> By analogy to the function utf8.codes, it would be nice to have a
> function string.bytes so that the construction
>
>      for p, c in string.bytes(s) do body end
>
> will iterate over all bytes in string s, with p being the position.
> This is surprisingly clumsy in pure Lua, unless I am missing a trick.
> ~~~
> in reply to which somebody was kind enough to post Lua code
> illustrating my point.
>
> -- Dirk
>

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Dirk Laurie-2
Op Do. 16 Mei 2019 om 17:58 het Paul K <[hidden email]> geskryf:

>
> Hi Dirk,
>
> >      for p, c in string.bytes(s) do body end
> > will iterate over all bytes in string s, with p being the position.
> > This is surprisingly clumsy in pure Lua, unless I am missing a trick.
>
> `s:gmatch("()(.)")`? Or am I missing something?
>
> Paul.

Perfect. I'll withdraw the "surprisingly clumsy" now.

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Jim-2
In reply to this post by Paul K-2
16.05.2019, 17:58, "Paul K" <[hidden email]>:
>> for p, c in string.bytes(s) do body end
>> will iterate over all bytes in string s, with p being the position.
>> This is surprisingly clumsy in pure Lua, unless I am missing a trick.

> `s:gmatch("()(.)")`?
> Or am I missing something?

i guess he was referring to users wanting a new feature added to Lua
which already exists (or that could be easily achieved by using already
existing means).



Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Sean Conner
In reply to this post by Roberto Ierusalimschy
It was thus said that the Great Roberto Ierusalimschy once stated:
> > 1) The constant LUA_BUFFERSIZE is not available in Lua.  There should be a
> > constant, io.BUFFERSIZE, defined to be this value.  There are instances
> > where this would be nice to have.
>
> What for?

  So I have this event driven network driver [1] where I can use Lua
coroutines to handle a TCP [2] or TLS [3] connections (both client and
server).  I also have code that turns such a connection into an object that
looks like a Lua file object [4] so that I can do things like:

        line = conn:read("l")
        raw  = conn:read(128)
        linecrlf = conn:read("L")

  I can't just wrap these up in a FILE* because that abstraction doesn't
lend itself to event driven programming.  If I could, I would have, but it
doesn't work, so I had to write this code.

  As it stands right now, it does *NO* buffering [5].  It would be nice to
support buffering [6] but it's hard to know what the default amount to
buffer is, hence the request for io.BUFFERSIZE.  Right now, all the code is
in pure Lua, I would hate to have to drop to C for just one constant.

  -spc (Does that make sense?)

[1] https://github.com/spc476/lua-conmanorg/blob/master/lua/nfl.lua

[2] https://github.com/spc476/lua-conmanorg/blob/master/lua/nfl/tcp.lua

[3] https://github.com/spc476/lua-conmanorg/blob/master/lua/nfl/tls.lua

[4] https://github.com/spc476/lua-conmanorg/blob/master/lua/net/ios.lua

[5] The default setvbuf() implementation I have is:

                local function setvbuf()
                  return true
                end
       
        Which is misleading, but it will still work, just not to the extent
        that the programmer is expecting it to.  By extension, the default
        flush() routine is:

                local function flush()
                  return true
                end

        Because ... well ... nothing is buffered so there's nothing to
        flush.

[6] Because the IO wrapper [4] is really not limited to just network
        stuff---it could be used for anything that you want to act as a
        FILE* but can't shoehorn into that, like maybe memory, or a
        compressed file or event driven network IO.

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Roberto Ierusalimschy
>   So I have this event driven network driver [1] where I can use Lua
> coroutines to handle a TCP [2] or TLS [3] connections (both client and
> server).  I also have code that turns such a connection into an object that
> looks like a Lua file object [4] so that I can do things like:
>
> line = conn:read("l")
> raw  = conn:read(128)
> linecrlf = conn:read("L")
>
>   I can't just wrap these up in a FILE* because that abstraction doesn't
> lend itself to event driven programming.  If I could, I would have, but it
> doesn't work, so I had to write this code.
>
>   As it stands right now, it does *NO* buffering [5].  It would be nice to
> support buffering [6] but it's hard to know what the default amount to
> buffer is, hence the request for io.BUFFERSIZE.  Right now, all the code is
> in pure Lua, I would hate to have to drop to C for just one constant.

I still fail to wee why you need LUA_BUFFERSIZE. Why not BUFSIZ?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Sean Conner
It was thus said that the Great Roberto Ierusalimschy once stated:

> >   So I have this event driven network driver [1] where I can use Lua
> > coroutines to handle a TCP [2] or TLS [3] connections (both client and
> > server).  I also have code that turns such a connection into an object that
> > looks like a Lua file object [4] so that I can do things like:
> >
> > line = conn:read("l")
> > raw  = conn:read(128)
> > linecrlf = conn:read("L")
> >
> >   I can't just wrap these up in a FILE* because that abstraction doesn't
> > lend itself to event driven programming.  If I could, I would have, but it
> > doesn't work, so I had to write this code.
> >
> >   As it stands right now, it does *NO* buffering [5].  It would be nice to
> > support buffering [6] but it's hard to know what the default amount to
> > buffer is, hence the request for io.BUFFERSIZE.  Right now, all the code is
> > in pure Lua, I would hate to have to drop to C for just one constant.
>
> I still fail to wee why you need LUA_BUFFERSIZE. Why not BUFSIZ?

  1) Why have LUA_BUFFERSIZE when BUFSIZ exists?

  2) I still need to use C to know what the value is.  It seems like
overkill, and Lua already wraps several standard C functions, so why not a
constant?

  -spc

Jim
Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Jim
On 5/16/19, Sean Conner <[hidden email]> wrote:
>> I still fail to wee why you need LUA_BUFFERSIZE. Why not BUFSIZ?
>  1) Why have LUA_BUFFERSIZE when BUFSIZ exists?
>  2) I still need to use C to know what the value is.  It seems like
> overkill, and Lua already wraps several standard C functions,
> so why not a constant ?

maybe he is reluctant to add it since it would not be a constant
from the Lua side ?

just add and export a C function along this lines to your package:

static int get_bufsiz ( lua_State * const L )
{
  lua_pushinteger ( L,
    // without checking the macro's value :-/
#if defined (BUFSIZ)
    BUFSIZ
#else
    0 // maybe no good idea ?
#endif
    ) ;

  return 1 ;
}

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Roberto Ierusalimschy
In reply to this post by Sean Conner
>   1) Why have LUA_BUFFERSIZE when BUFSIZ exists?

Because what is good for file buffers in the heap may not be good for
string buffers in the stack. (And there is a chance that neither one is
particularly good for your specific use.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Sean Conner
In reply to this post by Jim
It was thus said that the Great Jim once stated:
> On 5/16/19, Sean Conner <[hidden email]> wrote:
> >> I still fail to wee why you need LUA_BUFFERSIZE. Why not BUFSIZ?
> >  1) Why have LUA_BUFFERSIZE when BUFSIZ exists?
> >  2) I still need to use C to know what the value is.  It seems like
> > overkill, and Lua already wraps several standard C functions,
> > so why not a constant ?
>
> maybe he is reluctant to add it since it would not be a constant
> from the Lua side ?

  I'm not sure I follow.  BUFSIZ is defined by ANSI, and is a part of C89
(which is what Lua expects), C99, C11, etc.  LUA_BUFFERSIZE is defined by
Lua, so by definition, it exists there.  If you mean it can be changed by
the user in Lua, there's already one "constant" defined in Lua---"_VERSION",
a string representing the current Lua version.

> just add and export a C function along this lines to your package:

  I'm relunctant to add a C function *just for a constant*.  On Linux, the
minimum runtime size of a C-based module is 8K.  While machines today come
with gigabytes of RAM, it still bothers me to waste 8K for what is, at most,
an 8-byte constant.  Adding that function to another module is just pushing
the problem around.

  Given Roberto's latest reply, I'm going to just accept that this won't
happen any time soon.  Ah well ...

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Jeff Pohlmeyer
On Fri, May 17, 2019 at 3:43 PM Sean Conner <[hidden email]> wrote:

>   I'm relunctant to add a C function *just for a constant*.

The GNU libc doc for BUFSIZ says "Actually, you can get an even better
value to use for the buffer size by means of the fstat system call: it
is found in the st_blksize field of the file attributes."

And `stat --help` says:
...
Valid format sequences for file systems:
  ...
  %s   block size (for faster transfers)


So maybe:
io.popen('stat -f / -c %s')


 - Jeff

Reply | Threaded
Open this post in threaded view
|

Re: [NoW] Missing things from Lua

Russell Haley
In reply to this post by Paul K-2


On Thu, May 16, 2019 at 8:58 AM Paul K <[hidden email]> wrote:
Hi Dirk,

>      for p, c in string.bytes(s) do body end
> will iterate over all bytes in string s, with p being the position.
> This is surprisingly clumsy in pure Lua, unless I am missing a trick.

`s:gmatch("()(.)")`? Or am I missing something?
Wow. I can't count how many times I've needed that little gem. Yes, there are "better" solutions in Lua but...

Russ 

Paul.

On Thu, May 16, 2019 at 8:52 AM Dirk Laurie <[hidden email]> wrote:
>
> I'm latching to the subject, not the post. Some time ago I posted:
> ~~~
> By analogy to the function utf8.codes, it would be nice to have a
> function string.bytes so that the construction
>
>      for p, c in string.bytes(s) do body end
>
> will iterate over all bytes in string s, with p being the position.
> This is surprisingly clumsy in pure Lua, unless I am missing a trick.
> ~~~
> in reply to which somebody was kind enough to post Lua code
> illustrating my point.
>
> -- Dirk
>