headers
Eero Pajarre | 1 Nov 2002 09:27
Picon

lua_dofile and _ALERT, 5.0a compatibility

I just changed my application from Lua 4.? to Lua 5.0a
(I am planning to add Lua related stuff which would
depend on the new features)

I noticed following difference between the 4 and 5-versions:

In previous version lua_dofile returned an error code if
it could not parse the file. In 5.0a it exits my program.
The reason for the exit seems to be in lauxlib.c callalert,
which attempts to lua_call "_ALERT", which is not defined and
Lua ends panicking. The 4.0 version seems to ignore _ALERT if
it does not exist.

I think I have a good idea how to avoid this in my case,
but maybe version compatibility should/could be improved here.

		Eero

(I tried to check the mailing list archives, and did not
find this mentioned there)
Permalink | Reply | 1 comment |
headers
Roberto Ierusalimschy | 1 Nov 2002 14:39
Picon
Picon

Re: lua_dofile and _ALERT, 5.0a compatibility

> In previous version lua_dofile returned an error code if
> it could not parse the file. In 5.0a it exits my program.
> The reason for the exit seems to be in lauxlib.c callalert,
> which attempts to lua_call "_ALERT", which is not defined and
> Lua ends panicking.

Yes, this is a bug in 5.0a. It will be corrected for 5.0 beta. Sorry
about that.

-- Roberto
Permalink | Reply | 0 comments |
headers
Luiz Henrique de Figueiredo | 1 Nov 2002 15:59
Picon

Re: lua_dofile and _ALERT, 5.0a compatibility

>Yes, this is a bug in 5.0a. It will be corrected for 5.0 beta.

Here is the correct code:

static void callalert (lua_State *L, int status) {
  if (status != 0) {
    lua_getglobal(L, "_ALERT");
    if (lua_isfunction(L, -1)) {
      lua_insert(L, -2);
      lua_call(L, 1, 0);
    }
    else {  /* no _ALERT function; print it on stderr */
      fprintf(stderr, "%s\n", lua_tostring(L, -2));
      lua_pop(L, 2);  /* remove error message and _ALERT */
    }
  }
}

--lhf
Permalink | Reply | 0 comments |
headers
James McCartney | 1 Nov 2002 21:21
Picon

Re: Garbage collection


On Thursday, October 31, 2002, at 03:59  PM, Steve Dekorte wrote:

> so only the freed objects are touched on a sweep.

Just to press the point, with Baker's treadmill you don't even have to 
do that.

--

-- 
--- james mccartney   james <at> audiosynth.com   <http://www.audiosynth.com>
SuperCollider - a real time synthesis programming language for the 
PowerMac.
Permalink | Reply | 6 comments |
headers
Steve Dekorte | 1 Nov 2002 21:32
Gravatar

Re: Garbage collection


On Friday, November 1, 2002, at 12:21 PM, James McCartney wrote:
> On Thursday, October 31, 2002, at 03:59  PM, Steve Dekorte wrote:
>> so only the freed objects are touched on a sweep.
>
> Just to press the point, with Baker's treadmill you don't even have to 
> do that.

I just made a small change to make the definitions of black and white 
dynamic that avoids it. Maybe this is equivalent to "Baker's 
treadmill"? The descriptions I've read of it weren't very clear to me.

Cheers,
Steve
OSX freeware and shareware: http://www.dekorte.com/downloads.html
Permalink | Reply | 5 comments |
headers
Pyrogon Public | 1 Nov 2002 21:43

LUA_API

I notice that Lua (and many other open source projects) prefix their
function prototypes with an "extern" -- is this absolutely necessary?
What compilers/platforms won't link properly if this is missing?

Thanks,

Brian
Permalink | Reply | 1 comment |
headers
Sean Middleditch | 1 Nov 2002 21:52

Re: LUA_API

On Fri, 2002-11-01 at 15:43, Pyrogon Public wrote:
> I notice that Lua (and many other open source projects) prefix their
> function prototypes with an "extern" -- is this absolutely necessary?
> What compilers/platforms won't link properly if this is missing?

It's ANSI C.  Many many compilers won't handle it right without the
extern, including GCC with certain options enabled.

> 
> Thanks,
> 
> Brian
>
Permalink | Reply | 0 comments |
headers
Mattias Karlgren | 1 Nov 2002 21:47

for infinite loop bug

Hi!

I think I have found a bug. I am using Lua 4.0.1.
The code below produces an infinite loop.

for _, x in {1} do
   _ = nil
end

Sure, the code does not make sense, but it is a stripped down version
of code that was useful to me.

It seems to have something todo with (mixing?) the _ dummy identifiers.
If I change either of them it works. Changing the first _ to a variable name
is the way I worked around the problem.
If I change nil to 2 I get the following message:

error: invalid key for `next'

It is not a showstopper and the new for code in lua 5 might not have
this problem but I just wanted to let you know anyway.

Thanks for an excellent language!

Mattias
Permalink | Reply | 0 comments |
headers
Curt Carpenter | 1 Nov 2002 22:09
Picon
Favicon

RE: for infinite loop bug

>From the docs:
The behavior is undefined if you assign to index inside the block. 

Curt
Permalink | Reply | 0 comments |
headers
Mattias Karlgren | 1 Nov 2002 22:25

RE: for infinite loop bug

Ok, I understand now.
Somehow I thought that the _ identifier was special
and meant not caring about the value.
But I realise now that it is just an ordinary variable name.
Maybe a warning while compiling could be useful.

Thanks!

Mattias

At 13:09 2002-11-01 -0800, you wrote:
> >From the docs:
>The behavior is undefined if you assign to index inside the block.
>
>Curt
Permalink | Reply | 0 comments |

Gmane