headers
Mark Hamburg | 1 Jun 01:01

Re: Re[2]: state of the Lua nation on resource cleanup

Or look to C# and call it "using":

	using query = DB.execute "select * from blah" do
		for row in query do
			-- do something with row
			-- return statements work as intended and error location is preserved
		end
	end

[ Side note: This requires having query support a __call metamethod  
and a close method. Since we're probably going to call it a lot more  
than we're going to close it, it serves as an argument for the  
function specific metatables. ]

Now, what that probably then really argues for is a way to guarantee  
finalization in for loops so that one could write:

	for row in DB.execute "select * from blah" do
		-- do something with row
		-- return statements work as intended and error location is  
preserved		
	end

That, however, without using would lead to a tendency to construct  
iterate once constructs to get finalization.

Mark
Permalink | Reply | 0 comments |
headers
Cosmin Apreutesei | 1 Jun 01:16
Picon

Re: Re[2]: state of the Lua nation on resource cleanup

On Mon, Jun 1, 2009 at 01:50, Peter Cawley <lua <at> corsix.org> wrote:
> On Sun, May 31, 2009 at 11:22 PM, Cosmin Apreutesei
> <cosmin.apreutesei <at> gmail.com> wrote:
>> On Mon, Jun 1, 2009 at 00:58, Peter Cawley <lua <at> corsix.org> wrote:
>>> On Sun, May 31, 2009 at 10:42 PM, Cosmin Apreutesei
>>> <cosmin.apreutesei <at> gmail.com> wrote:
>>>> With immediately-collected resources, the functionality of f:close()
>>>> remains, as replaced by f = nil. I don't think any control is taken
>>>> away.
>>>>
>>>
>>> Expect "f = nil" would not provide the solid guarantee that the
>>> resource was collected, whereas "f:close()" does. Consider the example
>>> of a database API which only allows one (non-closed) cursor to exist
>>> at any one time. After running a query and using a cursor to iterate
>>> the results, you want to be absolutely sure that the cursor is
>>> collected, as otherwise no other database calls will work. If you
>>> accidently make a copy of "f" to some place, then "f = nil" would not
>>> collect the cursor, and your application would start failing all over
>>> the place. Using "f:close()" would guarantee that the cursor is
>>> closed, and any further operations on this one cursor object would
>>> result in a Lua error, which is (IMO) a much better result than having
>>> the rest of the application's future DB interactions failing.
>>
>> But that's a feature any library could provide if so designed. That
>> database API would surely have a close() method. And if it doesn't,
>> you could encapsulate the handler with a few lines of lua code and
>> provide the close() method yourself.
>>
> Consider the simple implementation of a hypothetical DB handling function:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Weimer | 1 Jun 01:24
Picon

Patch to use colored NaNs on LP64

Here's an experimental patch to shrink the size of a Lua value to 64
bit on LP64 architectures, by encoding non-double values as special
NaNs.  I think this was initially suggested by Mike Pall, but I'm not
sure if it's been implemented yet.

On my Core 2 Duo, "binarytrees 16" results in slightly less resident
memory usage (90m vs 103m).  Execution time is also about 10% less.  I
had hoped for more.  Moving values from the ALU to the FPU and back is
probably a bit expensive even today.  It might be possible to gain a
few more percent by careful tuning.

In theory, it should be possible to speed up arithmetic, by first
attempting the calculation on unchecked values and falling back to the
current logic if the result is a NaN.  But in my tests, I didn't see a
speedup.

I'm positively surprised that the patch is so small, and that the
external ABI is completely unchanged.

diff --git a/src/lgc.c b/src/lgc.c
index d9e0b78..b943c2c 100644
--- a/src/lgc.c
+++ b/src/lgc.c
@@ -663,7 +663,7 @@ void luaC_barrierf (lua_State *L, GCObject *o, GCObject *v) {
   global_State *g = G(L);
   lua_assert(isblack(o) && iswhite(v) && !isdead(g, v) && !isdead(g, o));
   lua_assert(g->gcstate != GCSfinalize && g->gcstate != GCSpause);
-  lua_assert(ttype(&o->gch) != LUA_TTABLE);
+  lua_assert(o->gch.tt != LUA_TTABLE);
   /* must keep invariant? */
(Continue reading)

Permalink | Reply | 5 comments |
headers
Cosmin Apreutesei | 1 Jun 01:37
Picon

nil semantics in Lua

I wonder why lua didn't adopted sql-like semantics for nil, i.e. nil
transcends all types, short-circuits standard operations and
functions, and nil ~= nil. It got good with tables though (although
many ppl see that differently). IMHO, it would had resulted in more
composability of standard functions and functional idioms, thus more
expressivity.
Permalink | Reply | 8 comments |
headers
Yuri Takhteyev | 1 Jun 01:58
Picon
Gravatar

The speed, size and dependability of programming languages

http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html

Lua gets mentioned as one of "a few spectacular exceptions" to a
general pattern.

  - yuri

--

-- 
http://spu.tnik.org/
Permalink | Reply | 0 comments |
headers
Mike Pall | 1 Jun 02:26
Picon

Re: Patch to use colored NaNs on LP64

Florian Weimer wrote:
> Here's an experimental patch to shrink the size of a Lua value to 64
> bit on LP64 architectures, by encoding non-double values as special
> NaNs.  I think this was initially suggested by Mike Pall, but I'm not
> sure if it's been implemented yet.

Yes, it will be in LuaJIT 2.x. But as I've mentioned in the past
it doesn't pay off for the Lua interpreter:

  http://lua-users.org/lists/lua-l/2008-02/msg00093.html

Apart from the portability problem (the popular targets are ILP32,
LP64 and LLP64) your patch is lacking the important tricks to make
it fast. I've disclosed a couple of them in a bug report for Tamarin:

  https://bugzilla.mozilla.org/show_bug.cgi?id=416398

--Mike
Permalink | Reply | 4 comments |
headers
Diego Nehab | 1 Jun 02:59
Picon

Re: LuaSocket - non-blocking connect ? (fwd)

Hi,

>> Yes, the DNS lookup can do that. What does an async DNS
>> library look like?
> 
> It's a non-blocking wrapper[1] around a fixed and hacked up version[2]
> of dns.lua[3]. A nice C replacement regularly features in our
> dreams[4] :)
> 
> The catch is that we need to look up SRV records and need a reasonable
> timeout, which the standard Linux resolver doesn't appear capable of.

So there is a Lua implementation of gethostbyname that does
not block?

>> It seems as though you should have no
>> trouble replacing the DNS lookup in LuaSocket with something
>> else, without any changes to C code.
>> 
> 
> Oh so the DNS lookup is performed from inside LuaSocket? That greatly
> simplifies things, thanks.

I don't know what you mean by the question. LuaSocket has
two DNS facilities. One is when you invoke
socket.dns.toip(). The other is when you invoke connect()
with a domain name. Both cases and up invoking
gethostbyname.

What I meant is that if you have a Lua replacement of
(Continue reading)

Permalink | Reply | 501 comments |
headers
Luiz Henrique de Figueiredo | 1 Jun 03:15
Picon

Re: ignoring BOM

> So, a system claiming it can understand UTF-8 files must be able to
> handle the BOM somehow (like ignoring it).

Lua makes no such claims.
Permalink | Reply | 0 comments |
headers
Matthew Wild | 1 Jun 03:16
Picon
Gravatar

Re: LuaSocket - non-blocking connect ? (fwd)

On Mon, Jun 1, 2009 at 1:59 AM, Diego Nehab <diego <at> tecgraf.puc-rio.br> wrote:
> Hi,
>
>>> Yes, the DNS lookup can do that. What does an async DNS
>>> library look like?
>>
>> It's a non-blocking wrapper[1] around a fixed and hacked up version[2]
>> of dns.lua[3]. A nice C replacement regularly features in our
>> dreams[4] :)
>>
>> The catch is that we need to look up SRV records and need a reasonable
>> timeout, which the standard Linux resolver doesn't appear capable of.
>
> So there is a Lua implementation of gethostbyname that does
> not block?
>

Essentially yes, though it is a lot more powerful than gethostbyname().

>>> It seems as though you should have no
>>> trouble replacing the DNS lookup in LuaSocket with something
>>> else, without any changes to C code.
>>>
>>
>> Oh so the DNS lookup is performed from inside LuaSocket? That greatly
>> simplifies things, thanks.
>
> I don't know what you mean by the question. LuaSocket has
> two DNS facilities. One is when you invoke
> socket.dns.toip(). The other is when you invoke connect()
(Continue reading)

Permalink | Reply | 501 comments |
headers
Gé Weijers | 1 Jun 04:24

Re: nil semantics in Lua

You're advocating that x ~= nil for all x (including nil). That may be
useful in an SQL environment, but silly when you want to determine the
end of a linked list.

Gé

On Mon, 2009-06-01 at 02:37 +0300, Cosmin Apreutesei wrote:
> I wonder why lua didn't adopted sql-like semantics for nil, i.e. nil
> transcends all types, short-circuits standard operations and
> functions, and nil ~= nil. It got good with tables though (although
> many ppl see that differently). IMHO, it would had resulted in more
> composability of standard functions and functional idioms, thus more
> expressivity.
Permalink | Reply | 5 comments |

Gmane