monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] 3rd party libraries


From: Markus Wanner
Subject: Re: [Monotone-devel] 3rd party libraries
Date: Sat, 25 Oct 2008 11:17:43 +0200
User-agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)

Hi,

Stephen Leake wrote:
> I'm confused.

Your question confuses me too ;-)

> You seem to be implying that a dynamically linked object file cannot
> be compiled with a C++ compiler. Is that correct?

An object file *is* compiled, it can only be linked against other
compiled objects.

The difference here is between compiling the lua source code with a C or
a C++ compiler. Only the later can throw exceptions, the former only
knowns longjmp/setjmp functions to provide similar behaviour.

This is the relevant part of luaconf.h:

> #if defined(__cplusplus)
> /* C++ exceptions */
> #define LUAI_THROW(L,c)       throw(c)
> #define LUAI_TRY(L,c,a)       try { a } catch(...) \
>       { if ((c)->status == 0) (c)->status = -1; }
> #define luai_jmpbuf   int  /* dummy variable */
> 
> #elif defined(LUA_USE_ULONGJMP)
> /* in Unix, try _longjmp/_setjmp (more efficient) */
> #define LUAI_THROW(L,c)       _longjmp((c)->b, 1)
> #define LUAI_TRY(L,c,a)       if (_setjmp((c)->b) == 0) { a }
> #define luai_jmpbuf   jmp_buf
> 
> #else
> /* default handling with long jumps */
> #define LUAI_THROW(L,c)       longjmp((c)->b, 1)
> #define LUAI_TRY(L,c,a)       if (setjmp((c)->b) == 0) { a }
> #define luai_jmpbuf   jmp_buf
> 
> #endif


What I don't quite understand is, how that's relevant to monotone.
That's a slightly different issue, but...

So far I thought that the exceptions from C++ compiled lua were
propagated to monotone. But that doesn't seem to be the case. No matter
if lua is compiled to use C++ exceptions internally or not, we are
calling lua functions via lua_pcall() in Lua::call(). That's a
"protected call" which returns a boolean upon failure.

Thus, the only thing that seems dubious to me is that there is only one
"failure" case. And i.e. for use_inodeprints(), that's not even
different from a function returning false:

> bool
> lua_hooks::hook_use_inodeprints()
> {
>   bool use = false, exec_ok = false;
> 
>   exec_ok = Lua(st)
>     .func("use_inodeprints")
>     .call(0, 1)
>     .extract_bool(use)
>     .ok();
>   return use && exec_ok;
> }

Which means, that the following two lua functions result in the same
behavior for monotone:

> function use_inodeprints()
>     return true
> end

> function use_inodeprints()
>     error("this error does not really show up anywhere noticeable")
> end

Only if you turn on '--debug' you'll see it in the log lines.

This is in contrast to "compilation" errors, i.e. for such a thing:

> function use_inodeprints()
>     -- lua comments normally look like this line
>     # this is not a lua comment and leads to a compilation error
> end

This raises a "lua error while loading rcfile ..." exception.

Am I missing something?

If not, I'd say this is irritating at least and vote for propagating lua
errors back to the monotone user, just like loading failures.

There are not many tests for such thing, are there? I didn't find
neither unit nor lua tests.

Regards

Markus Wanner




reply via email to

[Prev in Thread] Current Thread [Next in Thread]