headers
Alex Davies | 1 Mar 07:05
Picon
Picon
Favicon

Re: LuaJIT vs C++

Hey,

I run luajit under Delphi, which also cannot run setjmp/longjmp due to 
finalizers. My approach was to compile it as C code, but replace uses of 
LUAI_TRY with a function that calls Delphi_Try. (and define the LUAI_THROW 
macro as one that simply raises a delphi exception). I never had any 
problems with Jit, but I do not use or require coroutines. However error 
handling works fine. You could try that?

Delphi_Try:

procedure Delphi_Try(L: TLua; var Status: Integer; F: FLuaProcCall; UD: 
Pointer);
begin
  try
    func(L, UD);
  except
    if status = 0 then
      status := -1;
  end;
end;

(The function is a little bit different to that, as I have it that regular 
delphi exceptions are converted in to lua errors);

----- Original Message ----- 
From: "Alexander Gladysh"
> Hi, list!
>
> We have an application, dynamically linked with Lua. Lua is compiled
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Pall | 1 Mar 09:53
Picon

Re: LuaJIT vs C++

Alexander Gladysh wrote:
> As you know, compiling Lua as C++ basically changes longjmp() in
> LUAI_THROW to throw; and setjmp() in LUAI_TRY to try {} catch() {}.
> This change is crucial as longjmp/setjmp basically do not call any
> destructors in C++ objects.

That's only part of the problem. The other issue is that throwing
a C++ error "across" a C++ -> Lua -> C++ call chain would leave
Lua in an inconsistent state.

> Now we're considering a switch to LuaJIT. Vanilla LuaJIT does not
> compile as C++.

This is untested, because it's not a supported configuration.
Sorry, I should have ripped out the option in luaconf.h.

> However, compiled LuaJIT crushes on errors (same when embedded in our app):

GCC uses DWARF2 exception handling for C++ exceptions. This
depends on accurate stack frame information for every function
(this is the .eh_frame section in ELF objects).

But LuaJIT is a JIT compiler and generates code at runtime. The
dynamically generated functions have no unwind info. The GCC
unwinder cannot cope with this and terminates the process if a
JIT-compiled frame is on the stack between the catching and the
throwing frame.

> Unfortunately, we currently do not have any resources to debug this
> issue. We also currently have no resources on adopting our existing
(Continue reading)

Permalink | Reply | 602 comments |
headers
Alexander Gladysh | 1 Mar 12:09
Picon
Gravatar

Re: LuaJIT vs C++

>  > As you know, compiling Lua as C++ basically changes longjmp() in
>  > LUAI_THROW to throw; and setjmp() in LUAI_TRY to try {} catch() {}.
>  > This change is crucial as longjmp/setjmp basically do not call any
>  > destructors in C++ objects.
>
>  That's only part of the problem. The other issue is that throwing
>  a C++ error "across" a C++ -> Lua -> C++ call chain would leave
>  Lua in an inconsistent state.

Hmm. I naively thought that that try/catch in LUAI_TRY deals with that issue.

<...>

>  Enabling
>  GCC's exception handling causes considerable bloat in the
>  executables and catch(...) has it's own share of problems.

Well, we use exceptions in our C++ code anyway.

<...>

>  Well, this is a matter of resources for me, too. I've already
>  researched how to pass the necessary info to the GCC unwinder at
>  runtime. Unfortunately, this is quite complicated and would take
>  a lot of time to implement. I'm not sure it's worth the effort to
>  add this to the LuaJIT 1.x branch.

I see. Am I correct that the only feasible option for us at the moment
is to compile LuaJIT as plain C and to rewrite all our bindings as
follows:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mike Pall | 1 Mar 21:08
Picon

Re: LuaJIT vs C++

Alexander Gladysh wrote:
> >  > As you know, compiling Lua as C++ basically changes longjmp() in
> >  > LUAI_THROW to throw; and setjmp() in LUAI_TRY to try {} catch() {}.
> >  > This change is crucial as longjmp/setjmp basically do not call any
> >  > destructors in C++ objects.
> >
> >  That's only part of the problem. The other issue is that throwing
> >  a C++ error "across" a C++ -> Lua -> C++ call chain would leave
> >  Lua in an inconsistent state.
> 
> Hmm. I naively thought that that try/catch in LUAI_TRY deals with that issue.

Yes, it does. I just wanted to point out that there are two
issues which need to be solved:
1. Cleaning up C++ frames if a lua_error() is thrown.
2. Cleaning up the Lua state if a C++ exception is thrown.

> >  Well, this is a matter of resources for me, too. I've already
> >  researched how to pass the necessary info to the GCC unwinder at
> >  runtime. Unfortunately, this is quite complicated and would take
> >  a lot of time to implement. I'm not sure it's worth the effort to
> >  add this to the LuaJIT 1.x branch.
> 
> I see. Am I correct that the only feasible option for us at the moment
> is to compile LuaJIT as plain C and to rewrite all our bindings as
> follows:
>
> [... try/catch inside the binding ...]

Well, this solves issue 2, but not issue 1. Most Lua API
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Pall | 1 Mar 23:09
Picon

Re: another hat in the ring regarding Lua 5.2: static typing

Alex Davies wrote:
> Impressive that jit 2.x performs loop hoisting, but how is it that neither 
> assert nor type need to be checked? The only thing I can think of is that 
> it is assumed that they are both stored in upvalues, and that jit 2.x 
> checks that nothing modifies those upvalues. If so, wouldn't that cause 
> problems with debug.setupvalue =/? Intrigued. Sounds good though.

I've left out some details, but you're right -- this can get
tricky. Function identity checks can be hoisted out just like
type checks (conceptually this is the same).

I use optimistic hoisting for type checks (with a very high
success rate). If this leads to a PHI conflict at the end of the
loop (type has changed), the slots are blacklisted and the
recorder retries automatically.

Hoisting is quite easy for locals and upvalues. With one caveat:
open upvalues can alias locals in an outer frame -- which could
be part of the same trace.

Right now I don't care about interaction of the debug.* functions
with JIT-compiled code. They work fine with the interpreter and
you can just selectively disable compilation if necessary. But I
could use a trick similar to what I'm doing in lua_sethook(): if
you call it, it just aborts trace recording and drops back to the
interpreter. :-)

Hoisting of checks for functions stored in tables is a lot more
involved. This requires alias analysis, which is still on my TODO
list.
(Continue reading)

Permalink | Reply | 1 comment |
headers
John D. Ramsdell | 2 Mar 00:46
Picon
Favicon

[ANN] Lineqpp 0.5: a MetaPost-like linear equations preprocessor

Lineqpp 0.5 has been released on LuaForge.  The Linear Equations
Preprocessor solves linear equations and then substitutes the
solutions into a document at prescribed locations.  It can be used
with SVG to specify the position of graphics objects using a set of
linear equations.

http://luaforge.net/projects/lineqpp/

http://luaforge.net/docman/view.php/351/2420/lineqpp.html

Lua turns out to be a perfect match for this program.  The C code
scans and parses text, and Lua does the rest.  The Lua code is concise
and straightforward.  It's just 568 lines of code.

John
Permalink | Reply | 0 comments |
headers
Duck | 2 Mar 01:33

Re: Lua Workshop 2008 Announcements


> Unfortunately, I won't be able to come to the workshop, 
> my company is backing off since they read 
> <http://www.pcworld.com/article/id,142429/article.html 

But this isn't news. And it's no reason to avoid the USA, unless you also 
avoid entering almost any other country, e.g. UK (which has IIRC been 
notifying travellers of the possibility of a full laptop audit for about 
10 years!) and Australia. Naturally, this means avoiding leaving any of 
those countries if you live in one of them, unless your intention is never 
to return.

If your company really is that worried about US immigration, to the point 
that they won't let you go to a Lua conference on those grounds alone, 
then surely they'd never let you stay in a hotel, either, where the 
average laptop is much more likely to 'get surveilled' (probably without 
your knowledge) or simply stolen.

Why not simply get a second hard drive? Use it when travelling 
and equip it with the data you need for each specific trip, and wipe it 
between trips.

Restricting the set of data you carry around on international visits is a 
good idea _in all respects_. Indeed, you shouldn't do it just because you 
are afraid of US public servants. You should do it because you are mindful 
of the ease with which data you carry around can be {lost,stolen,peeked 
at} whilst you are on the road, and of the difficulty of taking your usual 
computer security precautions when you are 2,000 light years from home and 
living out of a suitcase.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Duck | 2 Mar 02:09

Re: LuaSocket 3.0? (was Re: A proposal for faster userdata type checking)


>We are shooting for an API that behaves like the IOCP API from Windows, 
>but simpler to use.  Using kqueue on BSD, IOCP on Windows, epoll on 
>Linux.

Sounds excellent.

I would add my voice to those who are urging that a LuaSocket 3 object 
should be able to handle (within reason, of course) any read-writeable 
object, not just IP sockets, on any supported platform.

Being able to throw files, named pipes, sockets etc. into the mix is IMO 
vital if you want to write something like a TCP server which does anything 
more than trivia. With co-operative multitasking you can't afford to have 
any point at which something which isn't using a socket might block. (Even 
uncontroversial I/O, such as writing one line to a log file, is 
potentially dangerous -- the file might be on a remote NFS server for all 
you know.) So IMO, _all_ I/O must be handleable through the same asynch 
API, or it's going to have an unconquerable weak spot.

Incidentally, it sounds as though what you are building isn't really 
LuaSocket 3, but LuaAsynCore 1, so it seems as though there is a case for 
naming it as a new library, and keeping LuaSocket 2 as an alternative, and 
more traditional, socket-specific API for those Lua users to whom it's 
sufficient, more comformatable, etc. In other words, reflect the 
difference in nomenclature as well as implementation.

When can we get at a pre-release build :-)
(Continue reading)

Permalink | Reply | 5 comments |
headers
John D. Ramsdell | 2 Mar 02:37
Picon
Favicon

Complex numbers and code vetting

I had reason to use complex numbers in Lua recently.  I tried to save
time by using someone else's complex number package.  You should
conclude from this note that public packages require careful scrutiny.

I found a post to this list that included Lua code for complex
numbers, but its definition of division has a sign error.  I
downloaded the LuaMatrix 2.0.8 package, but its complex number code is
very difficult to read and I noticed an error in the definition for
the natural logarithm.

I visited my bookcase and found:

"Introduction to Complex Variables and Applications", Ruel
V. Churchill, McGraw-Hill Book Company, Inc, 1949.

Note the year.  It's a wonderful book.  I used it to guide the writing
of a complex number package.  I don't have a good place to make it
available, so I've put it in the CVS repository for the lineqpp
project on LuaForge.

http://luaforge.net/projects/lineqpp/

Let me conclude with a very serious question.  Is there a vetting
process for Lua packages?  For example, is there a way to gain
confidence in some package because several others assert it has done
right by them?  Shouldn't there be a complex number package that is
the one the community agrees is solid?

John
(Continue reading)

Permalink | Reply | 0 comments |
headers
Javier Guerra | 2 Mar 02:58
Gravatar

Re: LuaSocket 3.0? (was Re: A proposal for faster userdata type checking)

On 3/1/08, Duck <duck <at> roaming.ath.cx> wrote:
>  Incidentally, it sounds as though what you are building isn't really
>  LuaSocket 3, but LuaAsynCore 1, so it seems as though there is a case for
>  naming it as a new library, and keeping LuaSocket 2 as an alternative, and
>  more traditional, socket-specific API for those Lua users to whom it's
>  sufficient, more comformatable, etc. In other words, reflect the
>  difference in nomenclature as well as implementation.

i'd second this idea.

as an anecdote, some time ago, i tried to develop a similar
infrastructure, to have all kinds of I/O under one single
event/queue/select/whatever.  searching for event-driven libraries,
some were quite flexible, but in the end required the I/O to signal
availability on a file or file-like object.  that clearly left out any
DB API.

the only solution i could think of was using helper threads, that is,
create a thread that blocks and signals the main one when the task was
finished.

and that's the story behind Helper Threads Toolkit.  unfortunately,
the two requirements that stem from this approach (new I/O libraries
and pthreads) has made it totally uninteresting for almost everybody.

so, if the new LuaSocket (or LuaAsynCore :-) can handle any file-like
object, it could be a great foundation for all kind of servers.

now the next challenge would be to create a split SQL library, to
isolate the blocking API in a second process, using IPC to expose a
(Continue reading)

Permalink | Reply | 3 comments |

Gmane