Re: Multiple return values from __index

John McKenna wrote:
> 
> state, pressure = controller.button
> 
> These are the multiple values we want to return from __index.

Why not return them in a table:
   state, pressure = unpack(controller:button())
or
   btn = controller:button()
   -- use btn.state, btn.pressure

--

-- 
Shmuel

[ANNOUNCE] lua-users lottery drawing

See <http://lua-users.org/wiki/LuaUsersLottery> for an opportunity to
lose money (and help support lua-users.org).

The lua-users.org site, with a current pace of about 10 million page
views per year, is heading into its seventh year.  It's time to select
members of the community to pay the domain registration fee.  This time
two winners will be selected, paying $25 USD each.  That amount will
cover the domain name until 2012.  We had 18 participants in the last
lottery back in July 2004-- let's try to beat that number.  The drawing
will be held at the start of Sunday, July 8th (midnight UTC).

Re: Microsoft DLR and Lua?

There are semantic mismatches between the DLR and Lua, mostly in the varargs and multi-values department, but also on tail calls, and Lua-style coroutines. The DLR as it is now is fairly flexible on the points where the four languages below have semantic differences, but that is not the case when they agree. But considering the maturity of the platform (basically it's in the anything can change stage yet) that's to be expected. In the future, maybe (especially if Microsoft becomes more open to open source contributions; its developers can't even read the source code of those languages!).

Lua on the CLR is another matter, though, and very doable (although coroutines are still a pain, but possible). And I'm working on that right now. Oh, and about the DLR again, a Lua compiler *could* be implemented, but I believe it would perform badly. But if Silverlight/Moonlight gains traction, and there is no other way...

--

Fabio Mascarenhas

On 6/30/07, Erik Cassel < erik <at> roblox.com> wrote:

Has anybody been thinking about Microsoft's DLR?  It will be part of Silverlight. Lua sounds like an excellent language for this kind of thing. Imagine Flash on steroids with Lua in place of clunky ActionScript!

 

Apparently there are Python, JavaScript, Visual Basic and Ruby implementations already built on top of DLR.

 

Of course, this might require a complete re-implementation of the language. Also, Lua generally prides itself in being small, self-contained, pure C, etc, etc.  Still, I think it is intriguing…

 

Here are some links:

 

http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx

 

http://sessions.visitmix.com/default.asp?event=1011&session=2012&pid=DEV02&disc=&id=1511&year=2007&search=DEV02

 

http://arstechnica.com/news.ars/post/20070430-microsoft-reveals-dynamic-language-runtime-for-net.html

 

Your thoughts?

 

-Erik Cassel

 

 

 

Re: Microsoft DLR and Lua?

On Sun, 1 Jul 2007, Fabio Mascarenhas wrote:

> There are semantic mismatches between the DLR and Lua, mostly in the varargs
> and multi-values department, but also on tail calls, and Lua-style
> coroutines.

Does it support arbitrary types as table indexes?

Where is there a technical description of the DLR?

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
FITZROY SOLE: WEST OR SOUTHWEST 5 OR 6, OCCASIONALLY 7. ROUGH OR VERY ROUGH.
SQUALLY SHOWERS THEN RAIN. MODERATE OR GOOD.

Re: Microsoft DLR and Lua?

Re: Microsoft DLR and Lua?

On Sun, 1 Jul 2007, Fabio Mascarenhas wrote:
> On 7/1/07, Tony Finch <dot <at> dotat.at> wrote:
> >
> > Does it support arbitrary types as table indexes?
>
> Python dictionaries can have anything as a key, so I guess yes.

The Python reference manual says only immutable types can be used as keys,
which rules out using dictionaries and functions as keys. In Ruby, any
object with a hash function can be used as a key; typically if the
contents of the object change the hash value does as well - i.e. it's not
based on object identity like Lua, so if you change the contents of a
table used as a key then it will no longer index the same location. (Also
Ruby has mutable strings so they have to break this rule for string
indexes on tables. Yuck.)

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
SOUTH UTSIRE: SOUTHEAST 6 OR 7, OCCASIONALLY GALE 8, DECREASING 4 OR 5.
MODERATE OR ROUGH. SHOWERS. GOOD.

Re: [ANN] LuaTask 1.6.1

>The 1.6.1 release of LuaTask is ready to download

Is this intended to fix the "more than 255 tasks segfault?"

It seems to fix it when there are N tasks each just blocking indefinitely. 
(This code would reliably segfault under 1.6.0 for N>= 255.)

I have code which creates N tasks which sort M random itmes P times. As 
long as I'm careful not to set M so high that I blow out the C stack of 
the tasks, I can use almost any combination of M, N and P as long as N <= 
255. So sorting 10,000 items 50 times in 255 concurrent tasks is fine, if 
somewhat slow 

With N >= 256, the code always segfaults, even with, say, 10 items sorted 
10 times, or even 1 items sorted 1 time.

FWIW I set LUATASK_PTHREAD_STACK_SIZE to 2097152 (2m) in my makefile.

Of course if this version isn't intended to address the "255" issue then 
ignore this email -- though note that the "just blocking" case above 
always segfaulted at 256 with 1.6.0 yet doesn't now. Though this could be 
down to the fact that the binary is rebuilt and thus differently laid 
out...

Re: [ANN] LuaTask 1.6.1

Duck escribió:
> Is this intended to fix the "more than 255 tasks segfault?"
>
> It seems to fix it when there are N tasks each just blocking 
> indefinitely. (This code would reliably segfault under 1.6.0 for N>= 
> 255.)
>
> I have code which creates N tasks which sort M random itmes P times. 
> As long as I'm careful not to set M so high that I blow out the C 
> stack of the tasks, I can use almost any combination of M, N and P as 
> long as N <= 255. So sorting 10,000 items 50 times in 255 concurrent 
> tasks is fine, if somewhat slow 
>
> With N >= 256, the code always segfaults, even with, say, 10 items 
> sorted 10 times, or even 1 items sorted 1 time.
>
> FWIW I set LUATASK_PTHREAD_STACK_SIZE to 2097152 (2m) in my makefile.
>
> Of course if this version isn't intended to address the "255" issue 
> then ignore this email -- though note that the "just blocking" case 
> above always segfaulted at 256 with 1.6.0 yet doesn't now. Though this 
> could be down to the fact that the binary is rebuilt and thus 
> differently laid out...

Please: change TASK_SLOTS_STEP to 384 (ltask.c:49) and check again with 
N between 255 and 380.  Tell me if the segfault is gone.

Thanks,
Daniel

Re: [ANN] LuaTask 1.6.1

>Please: change TASK_SLOTS_STEP to 384 (ltask.c:49) and check
>again with N between 255 and 380.  Tell me if the segfault is
>gone.

The segfaults seem to start at N == TASK_SLOTS_STEP.

With TASK_SLOTS_STEP at 256, it works until N == 255, then segfaults. I 
set it to 384 and the segfaults start when N == 384. For N at 381, 382, 
383 it all work fine.

I tried setting TASK_SLOTS_STEP to 443, and the behaviour was what you 
might expect: it worked up to 442 tasks and segfaulted from 443 and up.

Hope this helps.

Re: [ANN] LuaTask 1.6.1

Duck escribió:
>
> The segfaults seem to start at N == TASK_SLOTS_STEP.
>
> With TASK_SLOTS_STEP at 256, it works until N == 255, then segfaults. 
> I set it to 384 and the segfaults start when N == 384. For N at 381, 
> 382, 383 it all work fine.
>
> I tried setting TASK_SLOTS_STEP to 443, and the behaviour was what you 
> might expect: it worked up to 442 tasks and segfaulted from 443 and up.
>
> Hope this helps.
>

Thanks,

Yes... this helps.

LuaTask allocates TASK_ENTRY memory in TASK_SLOTS_STEP * 
sizeof(TASK_ENTRY) chunks.
Problem arises when it reallocates memory to grow one step more.

The size of TASK_ENTRY structure is 52 bytes on Linux.
As a workaround, you can set TASK_SLOTS_STEP larger enough in order to 
avoid reallocation.

It's time to work on 1.6.2 ... 

Regards,
Daniel