lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Thanks everyone, that has been very educational particularly Dirk's Glossary.

However:

I still maintain it is confusing to have NaN first introduced in the context of being a disallowed table key. If it is necessary to refer to it later in the manual it would be better to introduce it with number type. It is NOT obvious that it is a value of the number-float subtype - indeed I initially assumed it must be another one value type like Nil.

The (odd) requirement of the IEEE standard that NaN not test equal to itself means that there is no (robust) way to test for NaN from Lua, which is surely a significant omission? In the implementation I have to hand, tostring(0/0) == "-1.#IND", so I could test it that way, but could I be confident such code would be portable or even if NaN always converts this way on the same implementation and nothing else does?

If Egor's comment about Lua not requiring the IEEE standard but working with any underlying float implementation is right, then Dirk's Glossary is misleading in that the behaviour of zero and infinity would not necessarily be as defined, even if Lua forces conformity with respect to NaN (although a non-IEEE float implementation might not support NaN at all).

Should 0 // 0 result in NaN? (It results in an Error "attempt to divide by zero" in the implementation I have to hand). Here is where it is important to know that NaN is a value of number-float subtype rather than number type. Might it be better (or at least more consistent) if Lua trapped NaN after resolving an expression and raised the same error?

------ Original Message ------
From: lua-l-request@lists.lua.org
To: lua-l@lists.lua.org
Sent: 01/01/0001 00:00:00
Subject: lua-l Digest, Vol 83, Issue 47

Send lua-l mailing list submissions to
	lua-l@lists.lua.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lua-l-lists.lua.org

or, via email, send a message with subject or body 'help' to
	lua-l-request@lists.lua.org

You can reach the person managing the list at
	lua-l-owner@lists.lua.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lua-l digest..."


Today's Topics:

  1. Re: NaN in Lua 5.3 Reference Manual (Dirk Laurie)
  2. Re: NaN in Lua 5.3 Reference Manual (Egor Skriptunoff)
  3. Re[2]: NaN in Lua 5.3 Reference Manual (John Hind)
  4. Re: Re[2]: NaN in Lua 5.3 Reference Manual (Coda Highland)
  5. Re: NaN in Lua 5.3 Reference Manual (nobody)
  6. Re: NaN in Lua 5.3 Reference Manual (Martin)
  7. Yet another user confused by the *program* exporting symbols
     (was Re: Symbol not found error using embedded Lua interpreter in
     Rust) (Jay Carlson)


----------------------------------------------------------------------

Message: 1
Date: Fri, 23 Jun 2017 16:39:22 +0200
From: Dirk Laurie <dirk.laurie@gmail.com>
Subject: Re: NaN in Lua 5.3 Reference Manual
To: Lua mailing list <lua-l@lists.lua.org>
Message-ID:
	<CABcj=tkuPBhm3JcDwdJnqOgWRHhjJEt2=6RarNti4EN0g3gKjg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

2017-06-23 12:41 GMT+02:00 John Hind <john.hind@zen.co.uk>:

I notice that Lua 5.3 Reference Manual has been extensively edited over the
last few point releases, but one aspect that is still not very well
described is NaN. There are three references to it, all tangential. Two
state that it is not a valid table key while the third describes its
treatment by comparison operators. The thing itself is never properly
introduced.

NaN is an IEEE-754 subtlety and no more worthy of elaboration in
the Lua manual than a discussion of why n*(1/n)==1 might for some
values of n be false. The properties mentioned in the manual are
precisely the ways in which it impinges on essential Lua issues.

It does fall within the scope of an auxiliary glossary [1] for careful readers,
and there I wrote the following:

NaN
---

Acronym for "Not A Number". An exceptional value of type [number] (also
written 'NAN' and 'nan'), which arises as the result of an undefinable
arithmetic [operation]. NaN is not a Lua keyword, but appears in
output (in some implementations, even the nonsensical '-nan' may
be printed). If you need the notation NaN, assign such
a value to the name.

NaN is not a legal [key] in a table, but counts as [true](truth).

   NaN = 0/0
   NaN + 1        -- NaN. All arithmetic operations involving NaN have
                  -- result NaN.
NaN <= NaN -- false. All comparison operations involving NaN have
                  -- result false except the following.
   NaN ~= NaN     -- true. The only Lua value with this property.

[1] https://rawgit.com/dlaurie/lua-notes/master/glossary.html



------------------------------

Message: 2
Date: Fri, 23 Jun 2017 18:15:26 +0300
From: Egor Skriptunoff <egor.skriptunoff@gmail.com>
Subject: Re: NaN in Lua 5.3 Reference Manual
To: John Hind <john.hind@zen.co.uk>, Lua mailing list
	<lua-l@lists.lua.org>
Message-ID:
	<CAPweGw6V=d4DYZzTLEx-G6iuP0BXMUCrKQgE95axpjRSv+pKwg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

T24gRnJpLCBKdW4gMjMsIDIwMTcgYXQgMTo0MSBQTSwgSm9obiBIaW5kIHdyb3RlOgoKPiBvbmUg
YXNwZWN0IHRoYXQgaXMgc3RpbGwgbm90IHZlcnkgd2VsbCBkZXNjcmliZWQgaXMgTmFOLiBUaGVy
ZSBhcmUgdGhyZWUKPiByZWZlcmVuY2VzIHRvIGl0LCBhbGwgdGFuZ2VudGlhbC4gVHdvIHN0YXRl
IHRoYXQgaXQgaXMgbm90IGEgdmFsaWQgdGFibGUKPiBrZXkgd2hpbGUgdGhlIHRoaXJkIGRlc2Ny
aWJlcyBpdHMgdHJlYXRtZW50IGJ5IGNvbXBhcmlzb24gb3BlcmF0b3JzLiBUaGUKPiB0aGluZyBp
dHNlbGYgaXMgbmV2ZXIgcHJvcGVybHkgaW50cm9kdWNlZC4KPgo+Ckx1YSBkb2VzIG5vdCBpbnRy
b2R1Y2UgTmFOIGJ5IGl0c2VsZiAoYW5kIHRoZXJlZm9yZSBzaG91bGQgbm90IGRlc2NyaWJlIGl0
CmluIGRldGFpbHMpLgpJRUVFLTc1NCBjbGVhcmx5IGRlZmluZXMgdGhlIHZhbHVlICJOYU4iLCBh
bmQgTHVhIG1hbnVhbCBqdXN0IHJlZmVycwooaW1wbGljaXRseSkgdG8gdGhhdCBkZWZpbml0aW9u
LgpTaG91bGQgTHVhIG1hbnVhbCBhbHNvIGRlZmluZSB3aGF0ICJmbG9hdGluZyBwb2ludCBudW1i
ZXIiIGlzPyAgV2hhdAoiaW50ZWdlciBudW1iZXIiIGlzPyAgV2hhdCAic3RyaW5nIiBpcz8gIFdo
YXQgImNoYXJhY3RlciIgaXM/ICBXaGF0ICJtb3JlIiwKImxlc3MiIGFuZCAiZXF1YWwiIG1lYW4/
CgoKCj4gIk5vdCBhIE51bWJlciBpcyBhIHNwZWNpYWwgdmFsdWUgdXNlZCB0byByZXByZXNlbnQg
dW5kZWZpbmVkIG9yCj4gdW5yZXByZXNlbnRhYmxlIG51bWVyaWNhbCByZXN1bHRzLCBzdWNoIGFz
IDAvMC4iCj4KY2FuIG9uZSByZXByZXNlbnQgdGhlIHVucmVwcmVzZW50YWJsZT8KPgoKVGhlIHZh
bHVlIE5hTiAoTm90IGEgTnVtYmVyKSBpcyB1c2VkIHRvIHJlcHJlc2VudCBhIHZhbHVlIHRoYXQg
ZG9lcyBub3QKcmVwcmVzZW50IGEgcmVhbCBudW1iZXIuClNvIHllcywgb25lIGNhbiAicmVwcmVz
ZW50IHVucmVwcmVzZW50YWJsZSIgaW4gbW9yZSB3aWRlIHN1cGVyc2V0LgpJbiBhIHNpbWlsYXIg
d2F5LCBtYXRoZW1hdGljaWFucyAiY291bnQgdW5jb3VudGFibGUiLgoKCgo+IEluZGVlZCB0aGUg
aW50cm9kdWN0aW9uIG9mIHR3byBudW1iZXIgc3VidHlwZXMgJ2ludGVnZXInIGFuZCAnZmxvYXQn
IG9wZW5zCj4gdXAgYW4gb3Bwb3J0dW5pdHkgZm9yIGNvbmNlcHR1YWwgY2xhcmlmaWNhdGlvbi4g
J05hTicgY291bGQgYmUgcHJlc2VudGVkIGFzCj4gYSB0aGlyZCBzdWJ0eXBlLgo+CgpOYU4gc2hh
cmVzIHNlbWFudGljcyBvZiBhcml0aG1ldGljIG9wZXJhdGlvbnMgd2l0aCBhbGwgZmxvYXRpbmcg
cG9pbnQKbnVtYmVycywgc28gdGhlcmUgaXMgbm8gbmVlZCBmb3Igc3BsaXR0aW5nICdmbG9hdCcg
aW50byAncmVhbCcsICdOYU4nIGFuZAonaW5maW5pdHknLgotLS0tLS0tLS0tLS0tLSBuZXh0IHBh
cnQgLS0tLS0tLS0tLS0tLS0KQW4gSFRNTCBhdHRhY2htZW50IHdhcyBzY3J1YmJlZC4uLgpVUkw6
IGh0dHA6Ly9saXN0bWFzdGVyLnBlcHBlcmZpc2gubmV0L2NnaS1iaW4vbWFpbG1hbi9wcml2YXRl
L2x1YS1sLWxpc3RzLmx1YS5vcmcvYXR0YWNobWVudHMvMjAxNzA2MjMvYjNmZTAwZDAvYXR0YWNo
bWVudC0wMDAxLmh0bWwK

------------------------------

Message: 3
Date: Fri, 23 Jun 2017 17:04:07 +0000
From: "John Hind" <john.hind@zen.co.uk>
Subject: Re[2]: NaN in Lua 5.3 Reference Manual
To: "Egor Skriptunoff" <egor.skriptunoff@gmail.com>, "Lua mailing
	list" <lua-l@lists.lua.org>
Message-ID: <em89f516ee-d98d-4b1a-988b-bade02519329@cruncher>
Content-Type: text/plain; charset="utf-8"

SW4gdGhpcyBjYXNlLCBJIHdvdWxkIHJlZmVyZW5jZSBJRUVFIDc1NCB3aGVuICdmbG9hdCBudW1i
ZXInIHR5cGUgaXMgCmZpcnN0IGludHJvZHVjZWQgaW4gc2VjdGlvbiAyLjEuIEkgd291bGQgdGhl
biByZW1vdmUgdGhlIHJlZmVyZW5jZSB0byAKTmFOIGZyb20gc2VjdGlvbiAzLjQuNC4gVGhhdCBs
ZWF2ZXMgdGhlIGlzc3VlIG9mIE5hTiBub3QgYmVpbmcgYSB2YWxpZCAKdGFibGUga2V5LiBXaHkg
bm90IGdpdmVuIGl0IGlzIGEgdW5pcXVlIGJpdCBwYXR0ZXJuIGluIHRoZSBJRUVFIDc1NCBjb2Rl
IApzcGFjZT8gQnV0IGlmIGl0IGlzIG5lY2Vzc2FyeSB0byBzcGVjaWZpY2FsbHkgZXhjbHVkZSBp
dCwgSSB3b3VsZCByZWZlciAKdG8gaXQgYXMgInRoZSBmbG9hdCBudW1iZXIgdmFsdWUgTmFOIiwg
b3IgInRoZSBJRUVFIDc1NCB2YWx1ZSBOYU4iLgoKUHJlc3VtYWJseSBJRUVFIDc1NCBwb3NpdGl2
ZSBhbmQgbmVnYXRpdmUgaW5maW5pdHkgQVJFIHZhbGlkIHRhYmxlIGtleXMsIApzaW5jZSB0aGV5
IGFyZSBub3Qgc3BlY2lmaWNhbGx5IGV4Y2x1ZGVkPyBXaGF0IGFib3V0IHBvc2l0aXZlIGFuZCAK
bmVnYXRpdmUgemVybz8gV291bGQgdGhlc2UgYmUgZGlzdGluZ3Vpc2hlZCB0YWJsZSBrZXlzPwoK
VGhlIHByb2JsZW0gSSBoYWQgcmVhZGluZyBzZWN0aW9uIDIuMSBpcyB0aGF0IGl0IGltcGxpZXMg
J05hTicgaXMgCnNvbWV0aGluZyBsaWtlICduaWwnICh3aGljaCBhcyBhbHJlYWR5IGJlZW4gaW50
cm9kdWNlZCkgYW5kIG5ldmVyIApleHBsYWlucyB0aGF0IGl0IGlzIGFjdHVhbGx5IGEgc3BlY2lm
aWMgdmFsdWUgb2YgdGhlIGZsb2F0IHN1YnR5cGUgb2YgCnRoZSBudW1iZXIgdHlwZS4KCi0tLS0t
LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLQpGcm9tOiAiRWdvciBTa3JpcHR1bm9mZiIgPGVnb3Iu
c2tyaXB0dW5vZmZAZ21haWwuY29tPgpUbzogIkpvaG4gSGluZCIgPGpvaG4uaGluZEB6ZW4uY28u
dWs+OyAiTHVhIG1haWxpbmcgbGlzdCIgCjxsdWEtbEBsaXN0cy5sdWEub3JnPgpTZW50OiAyMy8w
Ni8yMDE3IDE2OjE1OjI2ClN1YmplY3Q6IFJlOiBOYU4gaW4gTHVhIDUuMyBSZWZlcmVuY2UgTWFu
dWFsCgo+T24gRnJpLCBKdW4gMjMsIDIwMTcgYXQgMTo0MSBQTSwgSm9obiBIaW5kIHdyb3RlOgo+
Pm9uZSBhc3BlY3QgdGhhdCBpcyBzdGlsbCBub3QgdmVyeSB3ZWxsIGRlc2NyaWJlZCBpcyBOYU4u
IFRoZXJlIGFyZSAKPj50aHJlZSByZWZlcmVuY2VzIHRvIGl0LCBhbGwgdGFuZ2VudGlhbC4gVHdv
IHN0YXRlIHRoYXQgaXQgaXMgbm90IGEgCj4+dmFsaWQgdGFibGUga2V5IHdoaWxlIHRoZSB0aGly
ZCBkZXNjcmliZXMgaXRzIHRyZWF0bWVudCBieSBjb21wYXJpc29uIAo+Pm9wZXJhdG9ycy4gVGhl
IHRoaW5nIGl0c2VsZiBpcyBuZXZlciBwcm9wZXJseSBpbnRyb2R1Y2VkLgo+Pgo+Cj5MdWEgZG9l
cyBub3QgaW50cm9kdWNlIE5hTiBieSBpdHNlbGYgKGFuZCB0aGVyZWZvcmUgc2hvdWxkIG5vdCBk
ZXNjcmliZSAKPml0IGluIGRldGFpbHMpLgo+SUVFRS03NTQgY2xlYXJseSBkZWZpbmVzIHRoZSB2
YWx1ZSAiTmFOIiwgYW5kIEx1YSBtYW51YWwganVzdCByZWZlcnMgCj4oaW1wbGljaXRseSkgdG8g
dGhhdCBkZWZpbml0aW9uLgo+U2hvdWxkIEx1YSBtYW51YWwgYWxzbyBkZWZpbmUgd2hhdCAiZmxv
YXRpbmcgcG9pbnQgbnVtYmVyIiBpcz8gIFdoYXQgCj4iaW50ZWdlciBudW1iZXIiIGlzPyAgV2hh
dCAic3RyaW5nIiBpcz8gIFdoYXQgImNoYXJhY3RlciIgaXM/ICBXaGF0IAo+Im1vcmUiLCAibGVz
cyIgYW5kICJlcXVhbCIgbWVhbj8KPgo+Cj4+Ik5vdCBhIE51bWJlciBpcyBhIHNwZWNpYWwgdmFs
dWUgdXNlZCB0byByZXByZXNlbnQgdW5kZWZpbmVkIG9yIAo+PnVucmVwcmVzZW50YWJsZSBudW1l
cmljYWwgcmVzdWx0cywgc3VjaCBhcyAwLzAuIgo+PmNhbiBvbmUgcmVwcmVzZW50IHRoZSB1bnJl
cHJlc2VudGFibGU/Cj4KPlRoZSB2YWx1ZSBOYU4gKE5vdCBhIE51bWJlcikgaXMgdXNlZCB0byBy
ZXByZXNlbnQgYSB2YWx1ZSB0aGF0IGRvZXMgbm90IAo+cmVwcmVzZW50IGEgcmVhbCBudW1iZXIu
Cj5TbyB5ZXMsIG9uZSBjYW4gInJlcHJlc2VudCB1bnJlcHJlc2VudGFibGUiIGluIG1vcmUgd2lk
ZSBzdXBlcnNldC4KPkluIGEgc2ltaWxhciB3YXksIG1hdGhlbWF0aWNpYW5zICJjb3VudCB1bmNv
dW50YWJsZSIuCj4KPgo+PkluZGVlZCB0aGUgaW50cm9kdWN0aW9uIG9mIHR3byBudW1iZXIgc3Vi
dHlwZXMgJ2ludGVnZXInIGFuZCAnZmxvYXQnIAo+Pm9wZW5zIHVwIGFuIG9wcG9ydHVuaXR5IGZv
ciBjb25jZXB0dWFsIGNsYXJpZmljYXRpb24uICdOYU4nIGNvdWxkIGJlIAo+PnByZXNlbnRlZCBh
cyBhIHRoaXJkIHN1YnR5cGUuCj4KPk5hTiBzaGFyZXMgc2VtYW50aWNzIG9mIGFyaXRobWV0aWMg
b3BlcmF0aW9ucyB3aXRoIGFsbCBmbG9hdGluZyBwb2ludCAKPm51bWJlcnMsIHNvIHRoZXJlIGlz
IG5vIG5lZWQgZm9yIHNwbGl0dGluZyAnZmxvYXQnIGludG8gJ3JlYWwnLCAnTmFOJyAKPmFuZCAn
aW5maW5pdHknLgo+Ci0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQpBbiBI
VE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uClVSTDogaHR0cDovL2xpc3RtYXN0ZXIucGVw
cGVyZmlzaC5uZXQvY2dpLWJpbi9tYWlsbWFuL3ByaXZhdGUvbHVhLWwtbGlzdHMubHVhLm9yZy9h
dHRhY2htZW50cy8yMDE3MDYyMy8wMjllZmE0Yi9hdHRhY2htZW50LTAwMDEuaHRtbAo=

------------------------------

Message: 4
Date: Fri, 23 Jun 2017 12:28:27 -0500
From: Coda Highland <chighland@gmail.com>
Subject: Re: Re[2]: NaN in Lua 5.3 Reference Manual
To: John Hind <john.hind@zen.co.uk>, Lua mailing list
	<lua-l@lists.lua.org>
Message-ID:
	<CAFE_sBFLOr-QDE4Do_PKrOYC4A2urgv8KAU8PJfpwOPhBhLRZg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 23, 2017 at 12:04 PM, John Hind <john.hind@zen.co.uk> wrote:
In this case, I would reference IEEE 754 when 'float number' type is first introduced in section 2.1. I would then remove the reference to NaN from section 3.4.4. That leaves the issue of NaN not being a valid table key. Why not given it is a unique bit pattern in the IEEE 754 code space? But if it is necessary to specifically exclude it, I would refer to it as "the float
number value NaN", or "the IEEE 754 value NaN".

Presumably IEEE 754 positive and negative infinity ARE valid table keys, since they are not specifically excluded? What about positive and negative
zero? Would these be distinguished table keys?

The problem I had reading section 2.1 is that it implies 'NaN' is something like 'nil' (which as already been introduced) and never explains that it is
actually a specific value of the float subtype of the number type.

It actually DOESN'T have a unique bit pattern in IEEE-754. All
IEEE-754 numbers with an exponent of all 1's is a NaN, and in fact
some VMs (including LuaJIT) exploit this fact to pack 52 bits of
useful information into the mantissa instead of storing it externally.

The reason section 2.1 doesn't mention IEEE-754 is because the Lua
reference interpreter doesn't rely strictly on IEEE-754 semantics
(notwithstanding the expected behavior of NaN) and it will compile and
run just fine on platforms that use other floating-point
representations (this is mentioned in 3.4.1).

I'm pretty sure you're right that positive and negative infinities are
distinct table keys. I don't think positive and negative zeroes are
because they compare equal to each other in all contexts.

As for referring to it as "the float number value NaN" in section 2.1
-- it already does. The parenthetical note right there calls out that
it is a special value used as a numerical result.

As for removing it from 3.4.4... Why? This definition is actually
required BECAUSE Lua doesn't require that the underlying platform
supports IEEE-754 semantics, but the language guarantees these
semantics anyway. (Also, there are other languages that use IEEE-754
floating point math that give NaN a well-defined comparison value in
order to provide a well-ordering property over the set of all possible
values.)

/s/ Adam



------------------------------

Message: 5
Date: Fri, 23 Jun 2017 19:31:32 +0200
From: nobody <nobody+lua-list@afra-berlin.de>
Subject: Re: NaN in Lua 5.3 Reference Manual
To: lua-l@lists.lua.org
Message-ID: <a254dc17-900c-1495-3634-c834ca5f80ae@afra-berlin.de>
Content-Type: text/plain; charset=utf-8; format=flowed

On 2017-06-23 19:04, John Hind wrote:
Why not given it is a unique bit pattern in the IEEE 754 code space?

It's not, it's **tons** of different patterns.

Which is precisely why it's a problem:  As float, NaN ~= NaN by
definition.  While reinterpreting the bits as int _usually_ (for NaNs
generated by the FPU) gives the same integers, it's not guaranteed to.
Which means no matter how you compare, it may be that NaN ~= NaN, which
makes recalling things from a hash table kinda awkward.

-- nobody



------------------------------

Message: 6
Date: Fri, 23 Jun 2017 21:17:29 -0700
From: Martin <eden_martin_fuhrspam@gmx.de>
Subject: Re: NaN in Lua 5.3 Reference Manual
To: John Hind <john.hind@zen.co.uk>, Lua mailing list
	<lua-l@lists.lua.org>
Message-ID: <6bb67377-a921-2db2-fb5a-2082f45277d3@gmx.de>
Content-Type: text/plain; charset=utf-8

On 06/23/2017 10:04 AM, John Hind wrote:
[...] What about positive and
negative zero? Would these be distinguished table keys?

With positive and negative float zeros is funny thing: you can't (I
don't know how) distinguish negative float zero (-0.0) from positive
float zero (0.0). Usually we detect negative number by comparing it with
0, which is not applicable here.

But in tables both three zeros as key maps to integer zero:

 Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
 > t = {[0] = '0', [0.0] = '0.0', [-0.0] = '-0.0'}
 > for k, v in pairs(t) do print(math.type(k), k, v) end
 integer	0	-0.0

-- Martin



------------------------------

Message: 7
Date: Fri, 23 Jun 2017 18:46:23 +0000
From: Jay Carlson <nop@nop.com>
Subject: Yet another user confused by the *program* exporting symbols
	(was Re: Symbol not found error using embedded Lua interpreter in
	Rust)
To: Lua mailing list <lua-l@lists.lua.org>
Message-ID:
	<CAJgdgDcq=7xCc+cqLOtxx_DonUwLpUU9N3ddzG6OZsDnst1-2w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Tm90ZSB0aGF0IHRoZSBiZWxvdyBpcyBub3QgcmVsZXZhbnQgdG8gYW55IHN5c3RlbXMgbW9yZSBl
bWJlZGRlZCB0aGFuIGEKcm91dGVyOyB0aGV5IHdvbid0IGNhcmUgYmVjYXVzZSB0aGV5IHdvbid0
IHVzZSBFTEYgU1ZSNC1zdHlsZSBzaGFyZWQKbGlicmFyaWVzLgoKSU1PLCB0aGUgbW9zdCBjb21w
ZWxsaW5nIGFyZ3VtZW50IGZvciB0aGUgb2RkIHdheSB1cHN0cmVhbSBwcmVmZXJzIHRvIGJ1aWxk
Cm1vZHVsZXMgaXMgdGhhdCB0aGUgbWFpbiBwcm9ncmFtIGRvZXMgbm90IGhhdmUgdG8gYmUgcG9z
aXRpb24taW5kZXBlbmRlbnQuCk9uIHNvbWUgYXJjaGl0ZWN0dXJlcywgdGhlcmUgaXMgYSBsYXJn
ZSBwZW5hbHR5IGZvciBQSUMsIGVzcGVjaWFsbHkgb24gaTM4NgppbXBsZW1lbnRhdGlvbnMuIChG
b3Igc3RhcnRlcnMsIHlvdSBsb3NlIGEgdmVyeSBzY2FyY2UgcmVnaXN0ZXIuKSBVc2luZwovdXNy
L2Jpbi9sdWEgYXMgbGlibHVhLnNvIGFzIHdlbGwgaGVscGVkIGdldCBMdWEgdG8gdGhlIHRvcCBv
ZiB0aGUKcHJvZ3JhbW1pbmcgbGFuZ3VhZ2Ugc2hvb3RvdXQuCgpXZSdyZSBqdXN0IGFib3V0IGF0
IHRoZSBlbmQgb2YgdGhlIGkzODYgYXJjaGl0ZWN0dXJlLiBBbGwgdGhlIG90aGVyCnBsYXRmb3Jt
cyB3aGljaCBjb3VsZCB1c2Ugc2hhcmVkIGxpYnJhcmllcyBhcmUgbm90IHNvIHJlZ2lzdGVyLXN0
YXJ2ZWQuIEluCnRoZSAiUEMiIHNwYWNlLCBhbG1vc3QgZXZlcnl0aGluZyBpcyBhbWQ2NCwgYW5k
IGFtZDY0IGlzIG11Y2ggYmV0dGVyIGZvcgpwb3NpdGlvbi1pbmRlcGVuZGVudCBjb2RlLgoKSW4g
YWRkaXRpb24sIHRoZSBwcmVmZXJyZWQgd2F5IHRvIGJ1aWxkIGxpYmx1YS5zbyB0aGVzZSBkYXlz
IGlzIHRvIG9ubHkKZXhwb3J0IHRoZSBwdWJsaWMgTHVhIEFQSS4gVGhpcyBhbGxvd3MgdGhlIGxp
bmtlciB0byBvcHRpbWl6ZSBpbnRlcm5hbApyZWZlcmVuY2VzIHRvIHByaXZhdGUgc3ltYm9scy4K
Ckkgd291bGQgcnVuIGJlbmNobWFya3MgZm9yIHlvdSBpbiBteSBtdXNldW0sIGJ1dCBJIHdvdWxk
IG5lZWQgc29tZQpiZW5jaG1hcmtzIHRvIHJ1bi4gQW55IHBvaW50ZXJzIG9yIHZvbHVudGVlcnM/
CgpKYXkKCihPdmVyaGVhZCBjb3VsZCBiZSByZWR1Y2VkIG1vcmUgaWYgZXh0ZXJuYWwgc3ltYm9s
cyBkaWQgbm90IGFmZmVjdCBob3cKbGlibHVhLnNvIHJlZmVycyB0byB0aGUgbGlibHVhLnNvIHN5
bWJvbHMuIFRoaXMgYnJlYWtzIExEX1BSRUxPQUQgYW1vbmcKb3RoZXIgdGhpbmdzLCBidXQgaXQn
cyBhYm91dCBtb3JhbGx5IGVxdWl2YWxlbnQgdG8gZXhwb3J0aW5nIHN5bWJvbHMgZnJvbQp0aGUg
bWFpbiBwcm9ncmFtLikKCk9uIFRodSwgSnVuIDIyLCAyMDE3LCAwMDozMiBEZWVwYWsgSm9pcyA8
ZGVlcGFrLmpvaXNAZ21haWwuY29tPiB3cm90ZToKCj4gVGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlv
bnMuCj4KPiBPbiBXZWQsIEp1biAyMSwgMjAxNyBhdCAxOjI2IFBNLCBEZWVwYWsgSm9pcyA8ZGVl
cGFrLmpvaXNAZ21haWwuY29tPgo+IHdyb3RlOgo+ID4gSXMgdGhlcmUgYSBzcGVjaWZpYyB3YXkg
dG8gbGluayB0aGUgTHVhIGNvZGUgaW5zaWRlIG9mIFJ1c3QKPiA+IHNvIHRoYXQgdGhlIHN5bWJv
bHMgYXJlIGF2YWlsYWJsZSB0byB0aGUgQyBtb2R1bGU/Cj4KPiBGV0lXLCBJIG1hbmFnZWQgdG8g
c29sdmUgdGhpcyBieSBsaW5raW5nIHRoZSBSdXN0IHByb2dyYW0gd2l0aCB0aGUKPiByaWdodCBm
bGFncy4gSSBoYWQgdG8gcGFzcyBhIGZsYWcgLXJkeW5hbWljLgo+Cj4gSSBqdXN0IGZvdW5kIHRo
ZSBhbnN3ZXIgYnkgZG9pbmcgYSBsb3Qgb2YgdHJpYWwgYW5kIGVycm9yLCBhbmQKPiByZXNlYXJj
aC4gSSBjYW7igJl0IGNsYWltIEkgdW5kZXJzdGFuZCBhbGwgdGhlIG15c3RlcmllcyBvZiBsaW5r
aW5nLiBJCj4gd29uZGVyIGlmIHRoaXMgc29ydCBvZiBpbmZvIGlzIGFscmVhZHkgdGhlcmUgb24g
c29tZSBMdWEgd2lraS4gSWYgbm90LAo+IEkgd291bGQgYWRkIGl0IHRvIGFuIGFwcHJvcHJpYXRl
IHBsYWNlIGlmIHNvbWVib2R5IGNhbiBwb2ludCBpdCBvdXQgdG8KPiBtZS4KPgo+IFNvbWUgaGVs
cGZ1bCBsaW5rcyBmb3IgYW55Ym9keSB3aG8gbWlnaHQgZW5kIHVwIGluIHRoZSBhcmNoaXZlcwo+
IHNlYXJjaGluZyBmb3IgdGhlIGV4YWN0IHNhbWUgcHJvYmxlbToKPgo+ICoKPiBodHRwczovL3N0
YWNrb3ZlcmZsb3cuY29tL3F1ZXN0aW9ucy8yMTI3OTAzNi93aGF0LWlzLWNsYW5ncy1lcXVpdmFs
ZW50LXRvLXJkeW5hbWljLWdjYy1mbGFnCj4KPiAqIGh0dHA6Ly9rZWl0YWl0by5jb20vYmxvZy8y
MDE3LzAxLzAyL2V4cGxvcmluZy1jb21waWxlci1vcHRpb25zLmh0bWwKPgo+Ci0tLS0tLS0tLS0t
LS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQpBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnVi
YmVkLi4uClVSTDogaHR0cDovL2xpc3RtYXN0ZXIucGVwcGVyZmlzaC5uZXQvY2dpLWJpbi9tYWls
bWFuL3ByaXZhdGUvbHVhLWwtbGlzdHMubHVhLm9yZy9hdHRhY2htZW50cy8yMDE3MDYyMy83NGMx
YzEwYy9hdHRhY2htZW50Lmh0bWwK

------------------------------

_______________________________________________
lua-l mailing list
lua-l@lists.lua.org
http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lua-l-lists.lua.org


End of lua-l Digest, Vol 83, Issue 47
*************************************