Lua 5.1 (final,rc) now available

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

Lua 5.1 (final,rc) now available

Luiz Henrique de Figueiredo
Lua 5.1 (final,rc) is now available for testing at
       http://www.lua.org/work/lua-5.1-rc.tar.gz

This is a pre-release. Unless major problems appear, it will be frozen
in 10 days or so. The tarball will then be renamed and moved to the
official download area.

In addition to many little details and fixes, the tarball contains a
revised and updated reference manual and revamped Makefiles following
suggestions by Mike Pall and others.

Please take a look and send us your comments or post them here.

Enjoy.
--lhf

Reply | Threaded
Open this post in threaded view
|

lua-5.1-rc "arg"

Dolan, Ryanne Thomas (UMR-Student)

I think I mentioned this earlier but it is not fixed in the new release.  In the reference manual, the pseudocode under the Metatables section uses the "arg" parameter, but this is not mentioned anywhere in the manual and is of course deprecated.
Reply | Threaded
Open this post in threaded view
|

Re: lua-5.1-rc "arg"

Roberto Ierusalimschy
> In the reference manual, the pseudocode under the Metatables section
> uses the "arg" parameter, but this is not mentioned anywhere in the
> manual and is of course deprecated.

Thanks.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

varol kaptan
In reply to this post by Luiz Henrique de Figueiredo
There seems to be an inconsistance with table_getn/table_setn
semantics when LUA_COMPAT_GETN is defined. In Lua 5.0.2, table size
was stored in either a table field 'n' or an inaccessible array in the
registry (checked in that order). Seems like this was changed in lua
5.1-rc in such a way that the internal array is used always in
table_setn, and internal array or 'n' used in table_getn (in that
order). This results in an inconsistent behavior for a feature whose
sole purpose is to provide backward compatibility (unless I
misunderstood).

Here is an example:

Lua 5.0.2  Copyright (C) 1994-2004 Tecgraf, PUC-Rio
> a = { n = 0 }
> table.insert(a, 'one')
> table.insert(a, 'two')
> =a.n, table.getn(a)
2	2
> table.setn(a, 3)
> =a.n, table.getn(a)
3	3

 Lua 5.1  Copyright (C) 1994-2006 Lua.org, PUC-Rio
> a = { n = 0 }
> table.insert(a, 'one')
> table.insert(a, 'two')
> =a.n, table.getn(a)
0	2
> table.setn(a, 3)
> =a.n, table.getn(a)
0	3

Is the change intentional or a bug?

Thanks,
Varol Kaptan

On 1/12/06, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> Lua 5.1 (final,rc) is now available for testing at
>        http://www.lua.org/work/lua-5.1-rc.tar.gz
>
> This is a pre-release. Unless major problems appear, it will be frozen
> in 10 days or so. The tarball will then be renamed and moved to the
> official download area.
>
> In addition to many little details and fixes, the tarball contains a
> revised and updated reference manual and revamped Makefiles following
> suggestions by Mike Pall and others.
>
> Please take a look and send us your comments or post them here.
>
> Enjoy.
> --lhf
>


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Roberto Ierusalimschy
> Is the change intentional or a bug?

It was intentional, but I guess it became a bug :) During the
development of 5.1 we planned to change the semantics of getn/setn (so
the changes in the implementation). With the new #, that change lost its
meaning. As you said, there is no point to change the behavior for a
feature whose sole purpose is to provide backward compatibility.

We will correct that.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

D Burgess-4
lua_gc now takes the LUA_COUNTB value.
for completeness, should collectgarbage() also have this same
parameter?

DB

On 1/13/06, Roberto Ierusalimschy <[hidden email]> wrote:
> > Is the change intentional or a bug?
>
> It was intentional, but I guess it became a bug :) During the
> development of 5.1 we planned to change the semantics of getn/setn (so
> the changes in the implementation). With the new #, that change lost its
> meaning. As you said, there is no point to change the behavior for a
> feature whose sole purpose is to provide backward compatibility.
>
> We will correct that.
>
> -- Roberto
>


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Mike Pall-41
Hi,

D Burgess wrote:
> lua_gc now takes the LUA_COUNTB value.
> for completeness, should collectgarbage() also have this same
> parameter?

collectgarbage("count") now calls LUA_COUNT and LUA_COUNTB.
If your lua_Number happens to be a floating point type then
you even get to see the result of this change:

$ lua51rc1 -e 'print(gcinfo(), collectgarbage("count"))'
17      17.4833984375
$ lua51rc1 -e 'print(gcinfo()*1024, collectgarbage("count")*1024)'
17408   18043

Bye,
     Mike

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

D Burgess-4
Thanks MIke.

On 1/13/06, Mike Pall <[hidden email]> wrote:
> Hi,
>
> D Burgess wrote:
> > lua_gc now takes the LUA_COUNTB value.
> > for completeness, should collectgarbage() also have this same
> > parameter?
>
> collectgarbage("count") now calls LUA_COUNT and LUA_COUNTB.
> If your lua_Number happens to be a floating point type then
> you even get to see the result of this change:
>
> $ lua51rc1 -e 'print(gcinfo(), collectgarbage("count"))'
> 17      17.4833984375
> $ lua51rc1 -e 'print(gcinfo()*1024, collectgarbage("count")*1024)'
> 17408   18043
>
> Bye,
>      Mike
>


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

D Burgess-4
line 705 luaconf.h

@* in 'string.fomat'.

should read

@* in 'string.format'.

DB


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Roberto Ierusalimschy
> line 705 luaconf.h
> [...]

Thanks.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Mike Pall-41
In reply to this post by Luiz Henrique de Figueiredo
Hi,

Luiz Henrique de Figueiredo wrote:
> Please take a look and send us your comments or post them here.

Ok, I've tested it on a dozen OS, compiler and CPU flavours and
so far everything looks good. It compiles without warnings on all
systems. The TKey related changes have silenced GCC 4.1 beta, too.

I've noticed some configuration issues though:

- Solaris works fine with the "posix" target. But if you want
  to enable dynamic loading: it needs "-ldl", but not "-Wl,-E".
  In case you want to support it officially:

solaris:
	$(MAKE) all MYCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN" MYLIBS="-ldl"

- Much to my surprise some SLES9 systems (Novell/SuSE Linux)
  didn't have readline installed (uh?). But many (but not all)
  BSD systems I tested did have the readline compatibility
  installed. See the discussion about Mac OS X 10.4, too.
  So, do we need (want?) two targets for each OS?

[I've reported some more Makefile issues to lhf by mail (make
install complains, problem with non-"all" targets and mingw).]

Some other noteworthy things:

- lvm.c:luaV_execute() case OP_FORLOOP:
  'step > 0' should be 'luai_numlt(0, step)'.

- Maybe we need to be able to redefine the casts to (and from!)
  lua_Number in luaconf.h, too? It could be a struct ...

- luaconf.h should have a
    #define LUA_NUMBER_DOUBLE
  near the LUA_NUMBER define to allow checking for the number
  type with CPP. Some modules really need to know this. Patches
  to change the number type should change this one, too.

- I guess the call to buffreplace() in read_numeral should get an
    if (ls->decpoint != '.')
  to avoid copying every number twice in the standard case.
  I'm not sure how happy everyone will be with the new dependency
  on localeconv() (from <locale.h>) in llex.c. Maybe add an
  option in luaconf.h?

- doc/lua.html and luac.html start with a comment line. Better
  move this line inside (e.g. /usr/bin/file detects it as SGML).

Digging in my archives, I've been looking for previously reported
but unfixed issues. There are a few:

- IMHO the problematic syntax "a=1b=2" should be explicitly
  disallowed. This avoids problems with foreign parsers and
  allows for more extensibility (e.g. adding hex numbers in a
  future release would make "y=0x=1" unparseable).

  Add this at the end of llex.c:read_numeral():
    if (isalpha(ls->current) || ls->current == '_')
      luaX_syntaxerror(ls, "ambiguous syntax");

- The new calling convention for luaopen_* functions should be
  listed under "Incompatibilities", too. Every embedder needs to
  know this (it's only mentioned briefly in chapter 5).

- A warning about the side-effects of DirectX/Direct3D is needed
  in the manual (and maybe in INSTALL, too):

    A warning for users of DirectX/Direct3D: You MUST set the
    D3DCREATE_FPU_PRESERVE flag upon initialization when you
    use Lua in the same thread. Otherwise you'll encounter
    strange behaviour -- complain to Microsoft, not to us.

- table.maxn(t) should be documented as 'expensive' and only to
  be used if #t does not work (for arrays with holes or tables
  with non-integer keys).

- The docs still don't pass the HTML validation suites.

- 'make install' still does not create the module directories.
  It's the duty of the core package to create the module
  directories and the duty of the add-on (module) packages to put
  modules into them:

INSTALL_LMOD= $(INSTALL_TOP)/share/lua/5.1
INSTALL_CMOD= $(INSTALL_TOP)/lib/lua/5.1

install: all
	... mkdir -p ... $(INSTALL_LMOD) $(INSTALL_CMOD)

- etc/strict.lua should be installed, too.

- etc/lua.pc should include variables for the standard/preferred
  module directories to install modules.

Bye,
     Mike

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Asko Kauppi

Good list, Mike! :)

Some comments/questions, not necessarily for you, but in general..

1. Is #t NOT expected to work, if a table has both integer (1..N) and other (string, etc) keys? If so, it's really too easy to mess it up, I hope #t would always find the 'N', no matter which other keys there are (note: hole issue is different).


2. Extension packages will still need to make sure all directories they're placing stuff to (including the share/lua/5.1) exist. In fact, they normally must do this in order for packaging to work, since the packaging is made to a dummy, clean, directory structure, and then wrapped together into .deb or something.

Anyways, having Lua do this as well would not hurt, and it'd emphasize the standard places, at least.

-asko


Mike Pall kirjoitti 18.1.2006 kello 17.30:

- table.maxn(t) should be documented as 'expensive' and only to
  be used if #t does not work (for arrays with holes or tables
  with non-integer keys).

...

- 'make install' still does not create the module directories.
  It's the duty of the core package to create the module
  directories and the duty of the add-on (module) packages to put
  modules into them:

INSTALL_LMOD= $(INSTALL_TOP)/share/lua/5.1
INSTALL_CMOD= $(INSTALL_TOP)/lib/lua/5.1

install: all
	... mkdir -p ... $(INSTALL_LMOD) $(INSTALL_CMOD)


Reply | Threaded
Open this post in threaded view
|

maxn considered pointless. Was: Re: Lua 5.1 (final,rc) now available

Rici Lake-2

On 18-Jan-06, at 10:48 AM, Asko Kauppi wrote:


Good list, Mike! :)

Some comments/questions, not necessarily for you, but in general..

1. Is #t NOT expected to work, if a table has both integer (1..N) and other (string, etc) keys? If so, it's really too easy to mess it up, I hope #t would always find the 'N', no matter which other keys there are (note: hole issue is different).

I would have thought so, too.

On the other hand, maxn works with sparse arrays only if they're not "sparse at the end", as it were. I personally think this is simply a bug waiting to get a user of maxn, and that people who actually use sparse arrays should come up with their own protocol to record the "size" of the array. I've gone back to using a 'n' field, myself:

  function sparse(...)
    return {n = select('#', ...), ...}
  end

  function sparseadd(t, ...)
    local count = select('#', ...)
    local n = t.n
    for i = 1, count do t[n+i] = select(i, ...) end
    t.n = n + count
    return t
  end

  function sparsenext(t, i)
    for j = i + 1, t.n do
      if t[j] ~= nil then return j, t[j] end
    end
  end

  function sparsepairs(t)
    return sparsenext, t, 0
  end

  t = sparse(2, nil, nil, 4, nil)
  sparseadd(t, nil, 3, 7)
  for i, val in sparsepairs(t) do
    print(i, val)
  end

prints:
  1       2
  4       4
  7       3
  8       7

Q: What would happen if sparse* were implemented with maxn?


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Mike Pall-41
In reply to this post by Asko Kauppi
Hi,

Asko Kauppi wrote:
> 1. Is #t NOT expected to work, if a table has both integer (1..N) and  
> other (string, etc) keys?

Sorry, my wording was too ambiguous.

Of course #t always 'works' in the sense that it finds the
maximum positive integral key for arrays without holes. It
doesn't matter if there are other keys, too:

 print(#{ 0, [1.5]=0, 0, [2.5]=0, foo=0 }) --> 2

My point was that newbies could easily be lead to the wrong
conclusion that table.maxn is the standard way to get the length
of a table. But it's only a fallback for exceptional cases.

Bye,
     Mike

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Roberto Ierusalimschy
In reply to this post by Mike Pall-41
> - I guess the call to buffreplace() in read_numeral should get an
>     if (ls->decpoint != '.')
>   to avoid copying every number twice in the standard case.

I profiled that and found no detectable difference.


>   I'm not sure how happy everyone will be with the new dependency
>   on localeconv() (from <locale.h>) in llex.c. Maybe add an
>   option in luaconf.h?

I guess you can simply define your own localconv macro, if needed.


-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Asko Kauppi
In reply to this post by Mike Pall-41

Yeah, also it is wise not to have too known-to-be-slow features around, unless they're named like maxn_crawl() ;) which.. please don't use! :D

I agree with you, that maxn() wouldn't be missed.

-asko


Mike Pall kirjoitti 18.1.2006 kello 18.52:

Hi,

Asko Kauppi wrote:
1. Is #t NOT expected to work, if a table has both integer (1..N) and
other (string, etc) keys?

Sorry, my wording was too ambiguous.

Of course #t always 'works' in the sense that it finds the
maximum positive integral key for arrays without holes. It
doesn't matter if there are other keys, too:

 print(#{ 0, [1.5]=0, 0, [2.5]=0, foo=0 }) --> 2

My point was that newbies could easily be lead to the wrong
conclusion that table.maxn is the standard way to get the length
of a table. But it's only a fallback for exceptional cases.

Bye,
     Mike


Reply | Threaded
Open this post in threaded view
|

Re: maxn considered pointless. Was: Re: Lua 5.1 (final,rc) now available

Paul Chiusano
In reply to this post by Rici Lake-2
> On the other hand, maxn works with sparse arrays only if they're not
> "sparse at the end", as it were. I personally think this is simply a
> bug waiting to get a user of maxn, and that people who actually use
> sparse arrays should come up with their own protocol to record the
> "size" of the array. I've gone back to using a 'n' field, myself...

Another approach is to use mask and unmask nil functions for accessing
the array. Then it's possible to just use the # operator without
modification:

untested:
Nil = {} -- notice captial 'Nil', not nil
function maskNil(v)
  return v~=nil and v or Nil
end
function unmaskNil(v)
  return v ~= Nil and v or nil
end
function add(t, v)
  t[#t+1] = maskNil(v)
end
function get(t, ind)
  return unmaskNil(t[ind])
end

etc...

-Paul


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Luiz Henrique de Figueiredo
In reply to this post by Mike Pall-41
> - Solaris works fine with the "posix" target. But if you want
>   to enable dynamic loading: it needs "-ldl", but not "-Wl,-E".
>   In case you want to support it officially:

I feel uneasy at adding more "official" targets to the Makefile; it seems
to imply that we have tested them all, but we only have convenient access
to Linux and Mac OS X (convenient in the sense that we can readily test
any changes).

It seems to me that community effort is needed for supplying the correct
incantations for each platform -- the community is being great with
that. But, as Mike says, do we really want to have two targets for each
platform, one with say readline or dynamic loading, and one without?

I'm not sure what to do. We can just include those incantations suggested
by the community and hope that they work; but we cannot test them all.
What is worse, "solaris" or "bsd" or "macosx" may not mean the same thing
to different persons...

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Luiz Henrique de Figueiredo
In reply to this post by Mike Pall-41
> - 'make install' still does not create the module directories.
>   It's the duty of the core package to create the module
>   directories and the duty of the add-on (module) packages to put
>   modules into them:
> 
> INSTALL_LMOD= $(INSTALL_TOP)/share/lua/5.1
> INSTALL_CMOD= $(INSTALL_TOP)/lib/lua/5.1

I've heard you the first time, but I still don't know how to do this
consistently with what is in luaconf.h. I could run "gcc -E" on a fake
program to extract the final values of LUA_LDIR and LUA_CDIR, but how
portable would that be?
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.1 (final,rc) now available

Ben Sunshine-Hill
On 1/18/06, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> > - 'make install' still does not create the module directories.
> >   It's the duty of the core package to create the module
> >   directories and the duty of the add-on (module) packages to put
> >   modules into them:
> >
> > INSTALL_LMOD= $(INSTALL_TOP)/share/lua/5.1
> > INSTALL_CMOD= $(INSTALL_TOP)/lib/lua/5.1
>
> I've heard you the first time, but I still don't know how to do this
> consistently with what is in luaconf.h. I could run "gcc -E" on a fake
> program to extract the final values of LUA_LDIR and LUA_CDIR, but how
> portable would that be?

Well... after compilation, Lua knows them. How about a simple script
to make the directories?

Ben


123