[ANN] Lua 5.2.0 (beta-rc2) now available

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

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Roberto Ierusalimschy
> I think there's no easy way. On posix systems you can use newlocale /
> uselocale / freelocale to change it per-thread [1]
> On Windows you have SetThreadLocale [2]. So, changing locale in a thread
> safe way is not portable. Some #ifdefs will be needed.

On Posix, it seems that the following does the trick:

  /* get current locale */
  oldloc = uselocale((locale_t)0);

  /* set new locale */
  loc = newlocale(LC_ALL_MASK, "C", NULL);
 uselocale(loc);
 freelocale(loc);

  /* restore previous locale */
  uselocale(oldloc);


For Windows, I could not figure out how to set a "C" locale with its
"SetThreadLocale"...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Fabio Mascarenhas
You can still use setlocale on Windows, as long as you do
_configurethreadlocale(_ENABLE_PER_THREAD_LOCALE) first:

http://msdn.microsoft.com/en-us/library/26c0tb7x(v=vs.80).aspx

--
Fabio


On Wed, Jun 22, 2011 at 2:52 PM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> I think there's no easy way. On posix systems you can use newlocale /
>> uselocale / freelocale to change it per-thread [1]
>> On Windows you have SetThreadLocale [2]. So, changing locale in a thread
>> safe way is not portable. Some #ifdefs will be needed.
>
> On Posix, it seems that the following does the trick:
>
>  /* get current locale */
>  oldloc = uselocale((locale_t)0);
>
>  /* set new locale */
>  loc = newlocale(LC_ALL_MASK, "C", NULL);
>  uselocale(loc);
>  freelocale(loc);
>
>  /* restore previous locale */
>  uselocale(oldloc);
>
>
> For Windows, I could not figure out how to set a "C" locale with its
> "SetThreadLocale"...
>
> -- Roberto
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Roberto Ierusalimschy
In reply to this post by Lorenzo Donati-2
> BTW, what about the limit per-block as opposed to the current limit
> per-function?

There are several alternatives:

1) one label per file
2) one label per function (as it is in rc2)
3) one label per scope (at any point in the code at most one label is
visible)
4) one label per block (as it was in rc1)
5) no restrictions

It is a compromise: avoiding messy code versus too much restriction. (1)
is the most restrictive (too much), (5) the most permissive (too much).
In my view, alternatives 2, 3, and 4 are all reasonable.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Lorenzo Donati-2
On 22/06/2011 20.42, Roberto Ierusalimschy wrote:

>> BTW, what about the limit per-block as opposed to the current limit
>> per-function?
>
> There are several alternatives:
>
> 1) one label per file
> 2) one label per function (as it is in rc2)
> 3) one label per scope (at any point in the code at most one label is
> visible)
> 4) one label per block (as it was in rc1)
> 5) no restrictions
>
> It is a compromise: avoiding messy code versus too much restriction. (1)
> is the most restrictive (too much), (5) the most permissive (too much).
> In my view, alternatives 2, 3, and 4 are all reasonable.
>
> -- Roberto
>
>
>
Thank you very much for the insight!

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) locale

Edgar Toernig
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:
> >
> > Do the new setlocale calls in ldo.c change thread safety assumptions
> > Lua?  http://stackoverflow.com/questions/4057319/is-setlocale-thread-safe-function
>
> It seems so :(
>
> Suggestions?

If I got it right, setlocale was added mainly to support EBCDIC systems.

Some suggestions:

 a) Declare the character set/encoding for Lua to be ASCII.
    Let the EBCDIC users deal with the conversion.

 b) Create the ctype table on the fly when building Lua.
    Maybe become difficult when cross-compiling (HOST_CC needed
    which uses the same encoding as the TARGET_CC).

 c) Provide a dedicated EBCDIC ctype table selected via some
    "#ifdef EBCDIC".

 d) You could provide hooks to let EBCDIC/strange-encoding users
    provide conversion routines.  Maybe a simple LOCAL_TO_ASCII(c)
    macro suffices.  Whether that macro should be used for ranges
    in Lua patterns (i.e. [k-p]) I don't know.
    Afaik, newer gcc uses iconv-lib and "-finput/exec-charset"
    to convert the charset on the fly...


Btw, setlocale is not really cheap.  For example:

|# time src/lua -e 'os.setlocale"de_DE" for i=1,100000 do loadstring"a=1" end'
|real 0m9.738s
|user 0m9.630s
|sys 0m0.090s
|
|# time src/lua-no-setlocale -e 'os.setlocale"de_DE" for i=1,100000 do loadstring"a=1" end'
|real 0m3.984s
|user 0m3.980s
|sys 0m0.010s

The lua-no-setlocale has only the two setlocale("C"/savedlocale) calls
in ldo.c disabled.

I think I even saw some trivial implementations that loaded the tables
from disk each time setlocale was called.


And the newlocale stuff is rather new (introduced in POSIX 2008) and probably
not available on EBCDIC systems (not even on one of my older Linux systems).

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) locale

Roberto Ierusalimschy
>  c) Provide a dedicated EBCDIC ctype table selected via some
>     "#ifdef EBCDIC".

Maybe this?

  #if 'A' == 193

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) locale

Roberto Ierusalimschy
In reply to this post by Edgar Toernig
>  b) Create the ctype table on the fly when building Lua.
>     Maybe become difficult when cross-compiling (HOST_CC needed
>     which uses the same encoding as the TARGET_CC).

Another option is to create it on the fly when opening the Lua state.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) locale

Edgar Toernig
Roberto Ierusalimschy wrote:
> >  b) Create the ctype table on the fly when building Lua.
> >     May become difficult when cross-compiling (HOST_CC needed
> >     which uses the same encoding as the TARGET_CC).
>
> Another option is to create it on the fly when opening the Lua state.

Yes.  But please, if you go that route, pre-initialize the table
for ASCII and wrap the initialization with something like
"if ('A' != 65)" or "#ifdef USE_NONASCII_CHARSET" else most of the
Lua users would suffer only because of the EBCDIC guys.

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) locale

Edgar Toernig
I wrote:

> Roberto Ierusalimschy wrote:
> > >  b) Create the ctype table on the fly when building Lua.
> > >     May become difficult when cross-compiling (HOST_CC needed
> > >     which uses the same encoding as the TARGET_CC).
> >
> > Another option is to create it on the fly when opening the Lua state.
>
> Yes.  But please, if you go that route, pre-initialize the table
> for ASCII and wrap the initialization with something like
> "if ('A' != 65)" or "#ifdef USE_NONASCII_CHARSET" else most of the
> Lua users would suffer only because of the EBCDIC guys.

Hmm... to make that multi-threading save the ctype table has to be in
the Lua-state :-/

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) locale

Roberto Ierusalimschy
> Hmm... to make that multi-threading save the ctype table has to be in
> the Lua-state :-/

Of course. Lua has no writable static C data at all.

But the best course seems to be something like #if 'A' == 193. (We will
ignore the possibility of cross-compilation between IBM mainframes
and other systems...)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Gé Weijers
In reply to this post by Roberto Ierusalimschy


On Wed, 22 Jun 2011, Roberto Ierusalimschy wrote:

>  -- example 2
>  do
>    ::label::   -- 1
>    goto label
>  end
>  ::label::   -- 2
>
> So, your second option should also disallow example 2. The first
> label is not visible when the second is declared, but the second
> label is visible when the first one is declared!  (Nevertheless,
> this seems a nice compromise between one-per-function and one-per-
> block.)

I realize that.

The visibility of labels should probably follow the scope rules you'd find
in languages like Algol 68, with extra restrictions. The rules there make
this a correct program:

BEGIN
         PROC foo = (INT i)VOID: (var := i);
         INT var := 0;
         foo(4);
         print((var,newline))
END

The assignment to 'var' inside procedure 'foo' textually precedes the
declaration of 'var', which is legal. I'm not suggesting to do this for
variables in Lua, BTW, or

local print = print

would not be a valid idiom.


Ge'

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

David Manura
In reply to this post by Gé Weijers
On Wed, Jun 22, 2011 at 9:46 AM, Gé Weijers <[hidden email]> wrote:
> - disallow a definition of a label if that label is already visible in the scope.

When might we ever want to allow two labels of the same name to be
visible from a goto?  I don't see a good use case.  Here's one
possible case I came up with:

  for _,tt in ipairs(t) do
    if f(tt) then goto continue end
    for _,v in ipairs(tt) do
      if g(v) then goto continue end
      gg()
      ::continue::
    end
    ff()
    ::continue::
  end

Personally, I would prefer to differentiate the outer label (e.g.
`::continue2::`) for clarity, and I may need to do that anyway if the
inner loop had to continue the outer loop.  (Note: I also
differentiate locals t and tt for similar reasons, but I don't do so
for `_` since I don't care about `_`.)

On the other hand, from the perspective of code generators, if a macro
expands to that inner loop, the macro doesn't need to worry about name
conflicts with surrounding labels (see
<http://en.wikipedia.org/wiki/Hygienic_macro>).  However, code
generators can handle that without too much trouble and may need to do
that type of thing anyway for local variables.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Tom N Harris
In reply to this post by Roberto Ierusalimschy
On 06/22/2011 09:52 AM, Roberto Ierusalimschy wrote:
>
> The advantage of exporting the structure is that the user may add her
> own extra fields, if needed. (Are there real cases for this need?)
>

In that case the library likely also provides its own functions that use
the extra data. And since the purpose of customizing FILE* is to be able
to use the built-in functions, it seems superfluous. However, the
exported FILE* factory could offer to add extra size to the structure
that can be written to. Any internal Lua fields would be in front of the
public fields, then extended data after. It also allows the userdata to
be created prior to opening the handle. Something like:

lua_file* F = luaL_createfilehandle(L, extrasize);
F->fclose = myclose;
F->fptr = fopen(...);
((MyFile*)F)->extra = whatever;

--
- tom
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Dirk Laurie
In reply to this post by Roberto Ierusalimschy
On Wed, Jun 22, 2011 at 08:42:57PM +0200, Roberto Ierusalimschy wrote:

>
> There are several alternatives:
>
> 1) one label per file
> 2) one label per function (as it is in rc2)
> 3) one label per scope (at any point in the code at most one label is
> visible)
> 4) one label per block (as it was in rc1)
> 5) no restrictions
>
> It is a compromise: avoiding messy code versus too much restriction. (1)
> is the most restrictive (too much), (5) the most permissive (too much).
> In my view, alternatives 2, 3, and 4 are all reasonable.
>
Simplest would be: rules for label visibility are exactly the same as
for local variables.  An existing way of thinking is reused, fewer
mistakes, easier to explain.  Consider:

~~~~ file /tmp/xxx
do  -- block A
  goto l1
  do  -- block B
    ::l1:: print 'inside'
    end
end
::l1:: print 'outside'
~~~~

~~~~
$ lua /tmp/xxx
lua: /tmp/xxx:7: label 'l1' already defined on line 4
~~~

but if you omit the last line

~~~~
$ lua /tmp/xxx
lua: /tmp/xxx:7: no visible label 'l1' for <goto> at line 2
~~~~

That is to say: one can jump from inside block A to outside it, if
and only if block B (into which one cannot jump) contains no label
of the same name.   Not a very intuitive or useful restriction.

Dirk


Reply | Threaded
Open this post in threaded view
|

SV: [ANN] Lua 5.2.0 (beta-rc2) now available

Fredrik Widlund
In reply to this post by Roberto Ierusalimschy
The difference would be that the behaviour of continue is well defined where as use of goto tends to lead to spaghetti code and it's not really clear how it's supposed to work. Which is the reason why languages like Java etc avoid it. If you have a complex problem that benefits from solving it in a "spaghetti" way then I guess you could like this addition but I'm not sure what the use cases motivating this addition are?

I do use break, and occasionally continue where it makes sense, but personally I last used a goto statement, literally, in the 80's on a c64. There is no way I will start using it as a replacement for continue, I'll just continue to write around the problem instead.

You say "we did not see why to include this one without including the others", does this mean you are adding continue as well?

Kind regards,
Fredrik Widlund








________________________________________
Från: [hidden email] [[hidden email]] f&#246;r Roberto Ierusalimschy [[hidden email]]
Skickat: den 22 juni 2011 19:02
Till: Lua mailing list
Ämne: Re: [ANN] Lua 5.2.0 (beta-rc2) now available

> As I said, I think I read in an old message by Roberto or Luiz (in
> an old of those endless threads about the beauty of continue) that
> Lua team wasn't in principle contrary to the introduction of
> continue as a counterpart of break, but the problem was that it was
> too tricky to get it right with the current (5.1.4) semantics of
> repeat-until because of the possibility of bypassing the scope of a
> local declared after the continue (*IIRC* - please feel free to
> correct me if I'm wrong).

You are :) The problem with repeat-until was only a detail. The main
problem with continue was (and still is) that, for us, it is just one of
many different forms of "domesticated goto" and we did not see why to
include this one without including the others. (We could argue the
same about 'break', BTW.)

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: SV: [ANN] Lua 5.2.0 (beta-rc2) now available

Philippe Lhoste
On 23/06/2011 11:24, Fredrik Widlund wrote:
> You say "we did not see why to include this one without including the others", does
> this mean you are adding continue as well?

No, this means that goto was a flexible way to include the others, ie. it embraces break,
continue and any creative usage you can think of.

Java has no goto, but it has labeled break/continue [1], which is a "polite"
(disciplined?) way of doing gotos. I code in Java for living for quite some time now, but
I rarely used (and saw) this feature. But I did, occasionally.

These can be also useful for finite state machines, particularly when we don't have
switch, although lot of people shown that coroutines can be useful in this field.

The fact that Lua introduces goto doesn't mean (I hope) that we will see 8bit-Basic-like
code in Lua (so called spaghetti code), just that we will have an additional tool in the
tool box, that we can use when the need arises (ie. sparingly!).

Just recently, I found back an old Lua code where I was complaining in a comment of the
lack of continue, so, yes, I find this addition useful. :-)

[1] http://stackoverflow.com/questions/46496/should-i-avoid-using-java-label-statements

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --


Reply | Threaded
Open this post in threaded view
|

Re: SV: [ANN] Lua 5.2.0 (beta-rc2) now available

Alex Queiroz
Hallo,

On Thu, Jun 23, 2011 at 1:26 PM, Philippe Lhoste <[hidden email]> wrote:
>
> These can be also useful for finite state machines, particularly when we
> don't have switch, although lot of people shown that coroutines can be
> useful in this field.
>

     You only need tail calls for state machines.

--
-alex
http://www.artisancoder.com/

Reply | Threaded
Open this post in threaded view
|

Re: SV: [ANN] Lua 5.2.0 (beta-rc2) now available

Xavier Wang


2011/6/23 Alex Queiroz <[hidden email]>
Hallo,

On Thu, Jun 23, 2011 at 1:26 PM, Philippe Lhoste <[hidden email]> wrote:
>
> These can be also useful for finite state machines, particularly when we
> don't have switch, although lot of people shown that coroutines can be
> useful in this field.
>

    You only need tail calls for state machines.

--
-alex
http://www.artisancoder.com/

may be he want machine generated state machines. 

Reply | Threaded
Open this post in threaded view
|

Re: SV: [ANN] Lua 5.2.0 (beta-rc2) now available

David Given
In reply to this post by Alex Queiroz
Alex Queiroz wrote:
[...]
>      You only need tail calls for state machines.

Depends on your requirements --- tail calls are, for example, absolutely
not an option for any of my stuff because they're too expensive.

The expense is not the tail call itself, mind, but the upvalues needed
to share data between states:

For example:

local function statemachine()
        local i = 1
        local j = 2

        local state1
        local state2

        state1 = function() i = i + 1 return state2() end
        state2 = function() j = j + 1 end

        return state1()
end

...allocates at least four heap cells *every time* statemachine() is
called; don't forget, the state functions themselves are upvalues...

The only other option is to pass your shared data in and out of every
state. But that's incredibly messy and hard to write and it's *still*
slower than an honest goto.

--
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup


signature.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SV: [ANN] Lua 5.2.0 (beta-rc2) now available

Daurnimator
On 23 June 2011 22:46, David Given <[hidden email]> wrote:

> local function statemachine()
>        local i = 1
>        local j = 2
>
>        local state1
>        local state2
>
>        state1 = function() i = i + 1 return state2() end
>        state2 = function() j = j + 1 end
>
>        return state1()
> end
>
> ...allocates at least four heap cells *every time* statemachine() is
> called; don't forget, the state functions themselves are upvalues...
>
> The only other option is to pass your shared data in and out of every
> state. But that's incredibly messy and hard to write and it's *still*
> slower than an honest goto.


how is it messy/hard?

--[[
local done = function(...) return ... end
local state1,state2

state1 = function(i,...)
    i=i+1
    return state2(i,...)
end
state2 = function(i,j,...)
   j = j + 1
   return done(i,j,...)
end

print(state1(1,2))
]]

Sure you have to manage your parameter lists; but its not too bad; you
only have to copy+paste; and you only need to do up to what you need
(cause you just follow it with a vararg)
the alternative is to use a table call:

--[[
local s = {}
function s:state1()
    self.i=self.i+1
    return self:state2()
end
function s:state2()
   self.j = self.j + 1
   return self
end

local statemachine = setmetatable({},{__index=s})
local res = statemachine:state1{i=1,j=2}
print(res.i,res.j)
]]

You do have to use 'self' a bit; and it might not be as fast
(benchmarks anyone; include luajit...) but its adequate.

Daurn.

1234