[ANN] Lua 5.1.2-rc3 now available

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANN] Lua 5.1.2-rc3 now available

Luiz Henrique de Figueiredo
Lua 5.1.2-rc3 is now available at
	http://www.lua.org/work/lua-5.1.2-rc3.tar.gz

MD5	6488372649283db528cf5a7ba94f3fea  -
SHA1	101d5c2e50b526d8dbd7394728658d3fb5729ca6  -

This rc fixes the glitches reported earlier.
Please take a look before we freeze it.  All feedback welcome.  Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Shmuel Zeigerman-2
Luiz Henrique de Figueiredo wrote:
Lua 5.1.2-rc3 is now available at
	http://www.lua.org/work/lua-5.1.2-rc3.tar.gz

MD5	6488372649283db528cf5a7ba94f3fea  -
SHA1	101d5c2e50b526d8dbd7394728658d3fb5729ca6  -

These hash values don't correspond to the file :(

--
Shmuel

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Luiz Henrique de Figueiredo
> These hash values don't correspond to the file :(

Sorry about that. Here are the correct values:

MD5     106c9ebc273a7459cab53e6404791f6c  -
SHA1    6a370aad916d9bb1fffb8c0bc8ef199524312b30  -

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Zachary P. Landau-4
In reply to this post by Luiz Henrique de Figueiredo
This rc fixes the glitches reported earlier.
Please take a look before we freeze it.  All feedback welcome.  Thanks.
--lhf

This isn't all too important, but I noticed that in the README under
'Installation' it says 'Under Unix, simply typing "make" should work'.
This isn't technically true anymore, as you have to specify a
platform.  It's just nitpicking, and certainly not a big deal for this
release.  Just thought I'd mention it.

--
Zachary P. Landau <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
One thing that I'd like to fix before the freeze is etc/luavs.bat,
which currently does not build luac.exe. Here is its current contents:

   cd src
   cl /O2 /W3 /c /DLUA_BUILD_AS_DLL l*.c
   del lua.obj luac.obj
   link /DLL /out:lua51.dll l*.obj
   cl /O2 /W3 /c /DLUA_BUILD_AS_DLL lua.c
   link /out:lua.exe lua.obj lua51.lib
   cd ..

Would the version below work? (Sorry, I don't have access to Visual Studio.)

   cd src
   cl /O2 /W3 /c /DLUA_BUILD_AS_DLL l*.c
   del lua.obj luac.obj
   link /DLL /out:lua51.dll l*.obj
   cl /O2 /W3 /c /DLUA_BUILD_AS_DLL lua.c
   link /out:lua.exe lua.obj lua51.lib
+  cl /O2 /W3 /c luac.c print.c
+  link /out:luac.exe luac.obj print.obj lua51.lib
   cd ..

(I have naively removed /DLUA_BUILD_AS_DLL from the luac compilation line.)
If not, is there a simple fix?
Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

D Burgess-4
No it wont work but this does


cl /MD /O2 /W3 /c /DLUA_BUILD_AS_DLL l*.c
del lua.obj luac.obj
link /DLL /out:lua51.dll l*.obj
cl /MD /O2 /W3 /c /DLUA_BUILD_AS_DLL lua.c
link /out:lua.exe lua.obj lua51.lib

cl /MT /O2 /W3 /c l*.c print.c
del lua.obj
link /out:luac.exe luac.obj print.obj l*.obj

The last link produces one warning which can be ignored.

db

On 3/27/07, Luiz Henrique de Figueiredo <[hidden email]> wrote:
One thing that I'd like to fix before the freeze is etc/luavs.bat,
which currently does not build luac.exe. Here is its current contents:

   cd src
   cl /O2 /W3 /c /DLUA_BUILD_AS_DLL l*.c
   del lua.obj luac.obj
   link /DLL /out:lua51.dll l*.obj
   cl /O2 /W3 /c /DLUA_BUILD_AS_DLL lua.c
   link /out:lua.exe lua.obj lua51.lib
   cd ..

Would the version below work? (Sorry, I don't have access to Visual Studio.)

   cd src
   cl /O2 /W3 /c /DLUA_BUILD_AS_DLL l*.c
   del lua.obj luac.obj
   link /DLL /out:lua51.dll l*.obj
   cl /O2 /W3 /c /DLUA_BUILD_AS_DLL lua.c
   link /out:lua.exe lua.obj lua51.lib
+  cl /O2 /W3 /c luac.c print.c
+  link /out:luac.exe luac.obj print.obj lua51.lib
   cd ..

(I have naively removed /DLUA_BUILD_AS_DLL from the luac compilation line.)
If not, is there a simple fix?
Thanks.
--lhf


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Chris-41
Couldn't that last link just be:

link /out:luac.exe l*.obj print.obj

Before it was specifying luac.obj twice.

CR


On 3/26/07, David Burgess <[hidden email]> wrote:
No it wont work but this does


cl /MD /O2 /W3 /c /DLUA_BUILD_AS_DLL l*.c
del lua.obj luac.obj
link /DLL /out:lua51.dll l*.obj
cl /MD /O2 /W3 /c /DLUA_BUILD_AS_DLL lua.c
link /out:lua.exe lua.obj lua51.lib

cl /MT /O2 /W3 /c l*.c print.c
del lua.obj
link /out:luac.exe luac.obj print.obj l*.obj

The last link produces one warning which can be ignored.

db

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

D Burgess-4
correct


Couldn't that last link just be:

link /out:luac.exe l*.obj print.obj


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Todor Totev
In reply to this post by Luiz Henrique de Figueiredo
This rc fixes the glitches reported earlier.
Please take a look before we freeze it.  All feedback welcome.  Thanks.
--lhf

Lua still cannot be compiled with Visual Studio 2005 projects created with
default settings. This pops in the list from time to time (I personally
know about 3 threads) so it should be fixed.
The offending lines are in loadlib.c:

(101) GetModuleFileName -> GetModuleFileNameA
(115) FormatMessage -> FormatMessageA
(128) LoadLibrary -> LoadLibraryA

The easiest fix is to use the straight ANSI functions instead of the
define'd names. If you want to make Lua distribution to not depend on
the ANSI functions there is more work to do, because the strings
returned by the OS travels to Lua side for using with scripts.

Even if you do not fix the code, at least give a warning in the INSTALL
file. Something in the lines of:

+++
By default the Lua distribution works with ANSI strings under Windows but
Visual Studio 2005 defines UNICODE when creating projects. Please adjust the project settings or the relevant code in loadlib.c. Please note that strings returned from the OS travels to Lua side so you may need to manually convert
between ANSI and UNICODE.
Also you can safely define _CRT_SECURE_NO_DEPRECATE for the Lua files to avoid
excessive warnings from VC compiler. For more details see
http://msdn2.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx
+++

And you can change the luavs.bat file to actually define it - just add
/D_CRT_SECURE_NO_DEPRECATE to the command line of the compiler

Regards,
Todor


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Mike Pall-71
Hi,

Todor Totev wrote:
> And you can change the luavs.bat file to actually define it - just add
> /D_CRT_SECURE_NO_DEPRECATE to the command line of the compiler

I've distributed LuaJIT with a modified luavs.bat file for quite
a while and received no complaints. AFAIK you need two defines to
silence all MSVC warnings:

  /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE

Bye,
     Mike

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

D Burgess-4
In reply to this post by Todor Totev

(101) GetModuleFileName -> GetModuleFileNameA
(115) FormatMessage -> FormatMessageA
(128) LoadLibrary -> LoadLibraryA

These three functions have previously undegone vigorous discussion.
(I am too lazy to loojup and refernce the msg thread).

I believe that the verdict was to leave them as they are.

db

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Mike Pall-71
Hi,

David Burgess wrote:
> >(101) GetModuleFileName -> GetModuleFileNameA
> >(115) FormatMessage -> FormatMessageA
> >(128) LoadLibrary -> LoadLibraryA
> >
> These three functions have previously undegone vigorous discussion.
> (I am too lazy to loojup and refernce the msg thread).
> 
> I believe that the verdict was to leave them as they are.

Well, here's a recap of the discussion threads:

I've proposed it, you've been in favour, Wim Couwenberg said that
these might not be the "official" API entries.
  http://lua-users.org/lists/lua-l/2006-04/msg00455.html

The subject reappeared a few months later, Roberto offered a
patch to luaconf.h. I argued that it doesn't work and did some
research to find out that the *A symbols are present in every
Windows version I could get hold of. Then you've proposed doing
conversion to/from UTF-8 and using the *W calls (which is IMHO
overdoing it a bit).
  http://lua-users.org/lists/lua-l/2006-06/msg00427.html

After that, the discussion died down and nothing happened. Alas,
the problem didn't disappear:
  http://lua-users.org/lists/lua-l/2006-08/msg00041.html
  http://lua-users.org/lists/lua-l/2006-09/msg00036.html

I've done some further research and e.g. APR, Firefox, PHP,
Info-ZIP, Boost and quite a few other open source products
happily use the *A calls (e.g. look for CreateFileA at Google
Codesearch). I mean ... even M$ mentions the *A and the *W
variants in their MSDN docs for every API entry.

IMHO it makes sense to apply the above mentioned changes in
loadlib.c. Unconditionally that is, because the *W variants
cannot ever work, given the surrounding code.

Bye,
     Mike

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Roberto Ierusalimschy
> IMHO it makes sense to apply the above mentioned changes in
> loadlib.c. Unconditionally that is, because the *W variants
> cannot ever work, given the surrounding code.

What about Win's proposal of undef UNICODE?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Lua 5.1.2-rc3 now available

Jerome Vuarand-2
Roberto Ierusalimschy wrote:
>> IMHO it makes sense to apply the above mentioned changes in
>> loadlib.c. Unconditionally that is, because the *W variants cannot
>> ever work, given the surrounding code.
> 
> What about Win's proposal of undef UNICODE?

Undefining UNICODE in luaconf.h may be problematic for applications
including Lua but that otherwise use Unicode API calls. I think using
the *A variants of the win32 API in Lua is the solution with the least
negative impact. As said before the A/W variants of the win32 api exist
for a long time (win95, maybe even before) and are very consistent
(afaik all API that deal with strings have both variants available). The
bigger drawback is that it would break Lua compilation on Windows 3.xx.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Erik Hougaard
In reply to this post by Mike Pall-71
Mike Pall wrote:
IMHO it makes sense to apply the above mentioned changes in
loadlib.c. Unconditionally that is, because the *W variants
cannot ever work, given the surrounding code.
I agree completly, keep it simple !

/Erik

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Wim Couwenberg
In reply to this post by Jerome Vuarand-2
As said before the A/W variants of the win32 api exist
for a long time (win95, maybe even before) and are very consistent
(afaik all API that deal with strings have both variants available).

In the header files maybe, but not in the actual system dll's.
Windows 9x and ME only provide the *A versions.  (A separate "unicode
layer" library must be installed to support the *W versions on those
platforms.)  Windows 3.x only supports the base names (no A or W
extension) for the 8-bit Windows code page versions.

So #undef UNICODE in loadlib.c should solve the problem on all Windows
platforms?

(Side note: Actually, MSDN states

 "In the few places where an application must work with 8-bit character data,
  it can make explicit use of the functions for Windows code pages."

(Taken from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_8zzn.asp)

This suggests to explicitly use the *A functions, but that doesn't
seem to take Win 3.x into account any more.)

--
Wim

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Roberto Ierusalimschy
In reply to this post by Jerome Vuarand-2
> Undefining UNICODE in luaconf.h may be problematic for applications
> including Lua but that otherwise use Unicode API calls. I think using
> the *A variants of the win32 API in Lua is the solution with the least
> negative impact.

OK, so we will adopt it. One question: does GetProcAddress have to be
changed to GetProcAddressA, too?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Wim Couwenberg
One question: does GetProcAddress have to be
changed to GetProcAddressA, too?

No.

--
Wim

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Todor Totev
In reply to this post by Roberto Ierusalimschy
IMHO it makes sense to apply the above mentioned changes in
loadlib.c. Unconditionally that is, because the *W variants
cannot ever work, given the surrounding code.

What about Win's proposal of undef UNICODE?

-- Roberto

This for sure breaks my code which becomes with:
#ifndef UNICODE
#  error .....
#endif

My observations are that most of the games shipped in 2006
required Windows 2000. Even the applications that run on 9x
line os Windows prefer to use UNICOWS.dll from Microsoft.
This dll converts *W functions to *A calls, adjusts for
bugs in 9x code and calls the OS. In short, the application
works as if running under NT based OS.
This is used by .Net framework code, WinAmp5 and more.
I think that undefining UNICODE in a public header is
impossible at this moment but doable in loadlib.c:

#if defined(UNICODE)
#  undef UNICODE
#endif
#if defined (_UNICODE)
#  undef _UNICODE
#endif
#include <windows.h>

This should be backwards compatible with Win 3.1 API but
I can't verify this.

The main problem with current code is that it is mis-reports
the size of the buffers - the *W functions interpret the size
as number of wide chars but it is in fact the number of bytes.
Not to mention that the returned unicode strings are not usable
by the rest of the Lua code and not suitable for displaying
to the user without further processing.
The compiler complains but only with warnings. And because most
of the multi-platform code is not warning free it can go unnoticed.

But if you can't change the code please consider documenting this
behaviour in the INSTALL file.
Kind regards,
Todor


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1.2-rc3 now available

Wim Couwenberg
In reply to this post by Wim Couwenberg
> One question: does GetProcAddress have to be
> changed to GetProcAddressA, too?

No.

OK...  So I forgot that there's also Windows CE...  It seems that CE
prior to 3.0 only has GetProcAddress but *always* takes a unicode
argument and CE 3.0 and later supports GetProcAddressA...  There's no
GetProcAddressA in non-CE versions.

:-\

--
Wim

12