Re: [ANN] LuaJIT-2.0.0-beta3

[Mike Pall <mikelu-1003@...>]

Peter Cawley wrote:
> On Sun, Mar 7, 2010 at 7:06 PM, Mike Pall <mikelu-1003@mike.de> wrote:
> > LuaJIT builds out-of-the-box on most x86 or x64 operating systems
> > (Linux, Windows, OSX etc.).
> 
> Running the msvcbuild included in beta3 from a Visual Studio 2008 x64
> command prompt on Vista x64 yields:
> lj_err.c(636) : error C2061: syntax error : identifier 'PEXCEPTION_ROUTINE'

Microsoft tells me to include "windows.h" to get its definition:
  http://msdn.microsoft.com/en-us/library/aa363082(VS.85).aspx

This works fine here. But maybe this is because I've installed
MSVC 9.0 EE _plus_ the Windows SDK (to get the x64 compiler).

The "windows.h" file provided by the WinSDK includes "WinDef.h"
which in turn includes "WinNT.h". That has all the definitions
which seem to be missing on your installation.

AFAIR newer versions of MSVC always come with some parts of the
Windows SDK. I'm not sure how complete this is, though. And short
of reinstalling everything I can't easily find out.

> The resulting DLL then worked as a drop-in replacement for a 64-bit
> compilation of the standard Lua DLL, with only one minor change to the
> application source code (which is ~30K lines of Lua, ~20K lines of
> C/C++).

Ah good, that's encouraging!

> The change was regarding the standard io.lines function - I
> read the manual as saying that io.lines returns an iterator function,
> which just happens to work in the generic for loop, which is how the
> standard implementation works. The LuaJIT implementation of io.lines
> returns an iterator function and an iterator state, which again just
> happens to work in the generic for loop, but doesn't work with code
> expecting just a single function return value.

Yes, someone else noticed this, too. My take on this is that it's
up to the implementation whether an iterator factory (such as
io.lines()) only returns an iterator function or an iterator state
and/or an initial value, too. The pseudo-code given in the Lua
manual for the iteration construct adjusts it to three results.

So, if you're dropping the iterator state, you're relying on
implementation-defined behavior. That logic would apply equally to
all iterator factories.

Maybe the Lua manual is in need of a clarification and/or it
shouldn't specify how many results individual iterator factories
(pairs, string.gmatch etc.) actually return (as this might change
in the future).

--Mike