[ANN] Lua 5.3.0 (rc0) now available

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

RE: [ANN] Lua 5.3.0 (rc0) now available

ForthCAD

I have compiled on VC10 with success, but have to append two file to compile
LUAC.EXE :

In http://www.lua.org/work/doc/#changes,
"Building Lua on other systems".
--------------------------------
To compile LUAC.EXE, I think the file list is incomplete: it is necessary to
have : library, luac.c + LDUMP.C + LOPCODE.C

Thanks for the nice work !

-----Message d'origine-----
De : [hidden email] [mailto:[hidden email]] De la
part de Luiz Henrique de Figueiredo
Envoyé : jeudi 11 décembre 2014 17:46
À : [hidden email]
Objet : [ANN] Lua 5.3.0 (rc0) now available

Lua 5.3.0 (rc0) is now available for testing at
        http://www.lua.org/work/lua-5.3.0-rc0.tar.gz

MD5 4692ad494c1d597888c03c5d6f278c40  -
SHA1 5da073fe552a9f2e2da57be3cec32378a4c902e0  -

This is the first release candidate for the final release of Lua 5.3.0.

A few things have changed since beta that we'd like to test in the wild,
hence rc0 instead of rc1. In particular, we made some changes in luaconf.h
and in the Makefile that we'd like to test. Please try compiling the
current code in as many platforms as possible. We expect the compilation to
go smoothly as usual but please report any warnings or other glitches.

The main change in Lua 5.3.0 is the introduction of integers. See also
        http://www.lua.org/work/doc/#changes

The complete diffs are available at
        http://www.lua.org/work/diffs-lua-5.3.0-beta-rc0.txt

An updated test suite is available at
        http://www.lua.org/work/lua-5.3.0-tests.tar.gz

All feedback welcome. Thanks.
--lhf



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Ulrich Schmidt
In reply to this post by François Perrad

Am 11.12.2014 um 22:50 schrieb François Perrad:

> 2014-12-11 21:35 GMT+01:00 Ulrich Schmidt <[hidden email]>:
>> Thank you.
>>
>> defining..
>> ----8X----------------------------------
>> #define LUA_COMPAT_5_1
>> #define LUA_COMPAT_5_2
>> ----8X----------------------------------
>> ... in luaconf.h seems to be a good idea. and solves most of the problems
>> for lfs, lanes, lsqlite, ...
>>
>> lua_dump need some changes in the sources and also lua_getfenv, you
>> mentioned.
>>
>> lpeg seems to need a update.
> This small patch
> https://github.com/fperrad/br/blob/lua/package/lpeg/lpeg-01-fix-compat-lua-5.3.patch
> does the job.
>
> François
>
This was too easy for me to find ;) Thanks a lot.

Ulrich.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Luiz Henrique de Figueiredo
In reply to this post by ForthCAD
> I have compiled on VC10 with success, but have to append two file to compile
> LUAC.EXE :
>
> In http://www.lua.org/work/doc/#changes,
> "Building Lua on other systems".
> --------------------------------
> To compile LUAC.EXE, I think the file list is incomplete: it is necessary to
> have : library, luac.c + LDUMP.C + LOPCODE.C

The library contains LDUMP.C + LOPCODE.C. What errors do you get?

Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Lua 5.3.0 (rc0) now available

ForthCAD
In reply to this post by ForthCAD

When compiling LUAC : (library+luac.c)

2>------ Rebuild All started: Project: Luac, Configuration: Debug
2>Win32 ----
2>ClCompile:
2>  luac.c
2>luac.obj : error LNK2019: unresolved external symbol _luaU_dump
2>referenced in function _pmain
2>luac.obj : error LNK2001: unresolved external symbol _luaP_opmodes
2>luac.obj : error LNK2001: unresolved external symbol _luaP_opnames
2>C:\7\lua53\Lua\Debug\Luac.exe : fatal error LNK1120: 3 unresolved
externals
2>
2>Build FAILED.

I have to append LDUMP.C and LOPCODE.C to build LUAC.exe



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Luiz Henrique de Figueiredo
> luac.obj : error LNK2019: unresolved external symbol _luaU_dump
> luac.obj : error LNK2001: unresolved external symbol _luaP_opmodes
> luac.obj : error LNK2001: unresolved external symbol _luaP_opnames
> C:\7\lua53\Lua\Debug\Luac.exe : fatal error LNK1120: 3 unresolved externals
> Build FAILED.

I don't understand this. Linking lua.obj with lua.lib (or whatever name
it is) should resolve these symbols. Anyone else has this problem?

This hasn't changed at all from 5.2 to 5.3...

Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Lua 5.3.0 (rc0) now available

ForthCAD
I compile LUAC.exe linked LUA.DLL _dynamic library_.
Probably, there would be no error when linking with the a LUA.lib static
library.

I think the problem is that 'luaU_dump', 'luaP_opmodes', 'luaP_opnames' are
not exported from DLL.

For instance, the 'luaU_dump' look like :

  int luaU_dump(lua_State *L, const Proto *f, lua_Writer w, void *data,
              int strip) {
  ...
  }

But, to link with DLL, should be:

  LUA_API int luaU_dump(lua_State *L, const Proto *f, lua_Writer w, void
*data,
              int strip) {
  ...
  }

Charles

-----Message d'origine-----
De : [hidden email] [mailto:[hidden email]] De la
part de Luiz Henrique de Figueiredo
Envoyé : vendredi 12 décembre 2014 11:43
À : Lua mailing list
Objet : Re: [ANN] Lua 5.3.0 (rc0) now available

> luac.obj : error LNK2019: unresolved external symbol _luaU_dump
> luac.obj : error LNK2001: unresolved external symbol _luaP_opmodes
> luac.obj : error LNK2001: unresolved external symbol _luaP_opnames
> C:\7\lua53\Lua\Debug\Luac.exe : fatal error LNK1120: 3 unresolved
externals
> Build FAILED.

I don't understand this. Linking lua.obj with lua.lib (or whatever name
it is) should resolve these symbols. Anyone else has this problem?

This hasn't changed at all from 5.2 to 5.3...


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Luiz Henrique de Figueiredo
> I compile LUAC.exe linked LUA.DLL _dynamic library_.

Ah, luac.exe is meant to be linked statically.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Alek Paunov
In reply to this post by ForthCAD
Hi Charles,

On 12.12.2014 13:01, ForthCAD wrote:

> I compile LUAC.exe linked LUA.DLL _dynamic library_.
> Probably, there would be no error when linking with the a LUA.lib static
> library.
>
> I think the problem is that 'luaU_dump', 'luaP_opmodes', 'luaP_opnames' are
> not exported from DLL.
>
> For instance, the 'luaU_dump' look like :
>
>    int luaU_dump(lua_State *L, const Proto *f, lua_Writer w, void *data,
>                int strip) {
>    ...
>    }
>
> But, to link with DLL, should be:
>
>    LUA_API int luaU_dump(lua_State *L, const Proto *f, lua_Writer w, void
> *data,
>                int strip) {
>    ...
>    }
>

The same patch could be seen in current Fedora packaging of Lua:

http://pkgs.fedoraproject.org/cgit/lua.git/tree/lua-5.2.2-luac-shared-link-fix.patch

Kind regards,
Alek


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Peter Melnichenko-2
Hello! Is it intended that in stacktraces standard C functions are
sometimes reported as `_G.function` and sometimes simply as
`function`? E.g. trying lua -e 'error("msg")' on the command line
sometimes gives

lua: (command line):1: msg
stack traceback:
    [C]: in function 'error'
    (command line):1: in main chunk
    [C]: in ?

and sometimes

lua: (command line):1: msg
stack traceback:
    [C]: in function '_G.error'
    (command line):1: in main chunk
    [C]: in ?

Peter


On Fri, Dec 12, 2014 at 3:10 PM, Alek Paunov <[hidden email]> wrote:

> Hi Charles,
>
> On 12.12.2014 13:01, ForthCAD wrote:
>>
>> I compile LUAC.exe linked LUA.DLL _dynamic library_.
>> Probably, there would be no error when linking with the a LUA.lib static
>> library.
>>
>> I think the problem is that 'luaU_dump', 'luaP_opmodes', 'luaP_opnames'
>> are
>> not exported from DLL.
>>
>> For instance, the 'luaU_dump' look like :
>>
>>    int luaU_dump(lua_State *L, const Proto *f, lua_Writer w, void *data,
>>                int strip) {
>>    ...
>>    }
>>
>> But, to link with DLL, should be:
>>
>>    LUA_API int luaU_dump(lua_State *L, const Proto *f, lua_Writer w, void
>> *data,
>>                int strip) {
>>    ...
>>    }
>>
>
> The same patch could be seen in current Fedora packaging of Lua:
>
> http://pkgs.fedoraproject.org/cgit/lua.git/tree/lua-5.2.2-luac-shared-link-fix.patch
>
> Kind regards,
> Alek
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Roberto Ierusalimschy
> Hello! Is it intended that in stacktraces standard C functions are
> sometimes reported as `_G.function` and sometimes simply as
> `function`?

It is not *intended*, but it is known. The algorithm that searches for
a name is depth-first, and due to the random order of table traversals
sometimes it finds 'function' first, sometimes it finds '_G' (and then
'function' inside it) first. Is this a problem? It seems easy to fix...
(As performance is not a problem here, we can first search with a level
limit of 1, and then search again with a level limit of 2.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Soni "They/Them" L.

On 13/12/14 09:56 AM, Roberto Ierusalimschy wrote:

>> Hello! Is it intended that in stacktraces standard C functions are
>> sometimes reported as `_G.function` and sometimes simply as
>> `function`?
> It is not *intended*, but it is known. The algorithm that searches for
> a name is depth-first, and due to the random order of table traversals
> sometimes it finds 'function' first, sometimes it finds '_G' (and then
> 'function' inside it) first. Is this a problem? It seems easy to fix...
> (As performance is not a problem here, we can first search with a level
> limit of 1, and then search again with a level limit of 2.)
>
> -- Roberto
>
Can you get it to report as `package.loaded._G.function`?

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Lua 5.3.0 (rc0) now available

Thijs Schreijer
In reply to this post by Luiz Henrique de Figueiredo

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Luiz Henrique de Figueiredo
> Sent: donderdag 11 december 2014 17:46
> To: [hidden email]
> Subject: [ANN] Lua 5.3.0 (rc0) now available
>
> Lua 5.3.0 (rc0) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-rc0.tar.gz
>
> MD5 4692ad494c1d597888c03c5d6f278c40  -
> SHA1 5da073fe552a9f2e2da57be3cec32378a4c902e0  -
>
> This is the first release candidate for the final release of Lua 5.3.0.
>
> A few things have changed since beta that we'd like to test in the wild,
> hence rc0 instead of rc1. In particular, we made some changes in luaconf.h
> and in the Makefile that we'd like to test. Please try compiling the
> current code in as many platforms as possible. We expect the compilation to
> go smoothly as usual but please report any warnings or other glitches.
>

I tested building it on Windows using my Windows build script/batchfile [1].

MinGW32 - Ok
MS Win7SDK 32 - Ok
MS Win7SDK 64 - Ok
TDM32 - Ok
TDM64 - Several warnings see below for details

These warnings are new to RC0, both Work3 and Alpha versions did not generate those warnings.

Note: I only build them and ran the interpreter once. Didn't run any tests.

Thijs

[1] https://github.com/Tieske/luawinmake


Full build log TDM 64;


Setting up environment for using MinGW with GCC from C:\TDM-GCC-64\.

C:\TDM-GCC-64>cd\temp\lua-5.3.0-rc0

C:\Temp\lua-5.3.0-rc0>etc\winmake clean
Cleaning...
Done.

C:\Temp\lua-5.3.0-rc0>etc\winmake

Checking source code to extract Lua version...
Lua version found: 5.3

Testing for MS...
cl wordt niet herkend als een interne
of externe opdracht, programma of batchbestand.
Testing for GCC...
gcc (tdm64-2) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Using GCC toolchain...

Now compiling CORE file set...
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lapi.o lapi.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lcode.o lcode.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lctype.o lctype.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o ldebug.o ldebug.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o ldo.o ldo.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o ldump.o ldump.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lfunc.o lfunc.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lgc.o lgc.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o llex.o llex.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lmem.o lmem.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lobject.o lobject.c
lobject.c: In function 'luaO_tostring':
lobject.c:327:5: warning: format '%d' expects argument of type 'int', but argume
nt 3 has type 'lua_Integer' [-Wformat=]
     len = lua_integer2str(buff, ivalue(obj));
     ^
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lopcodes.o lopcodes.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lparser.o lparser.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lstate.o lstate.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lstring.o lstring.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o ltable.o ltable.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o ltm.o ltm.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lundump.o lundump.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lvm.o lvm.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lzio.o lzio.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lauxlib.o lauxlib.c
Now compiling LIB file set...
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lbaselib.o lbaselib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lbitlib.o lbitlib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lcorolib.o lcorolib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o ldblib.o ldblib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o liolib.o liolib.c
liolib.c: In function 'g_write':
liolib.c:612:17: warning: format '%d' expects argument of type 'int', but argume
nt 3 has type 'lua_Integer' [-Wformat=]
                 ? fprintf(f, LUA_INTEGER_FMT, lua_tointeger(L, arg))
                 ^
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lmathlib.o lmathlib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o loslib.o loslib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lstrlib.o lstrlib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o ltablib.o ltablib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lutf8lib.o lutf8lib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o loadlib.o loadlib.c
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o linit.o linit.c
Now compiling DLL file set...
gcc -O2 -Wall -DLUA_BUILD_AS_DLL -DLUA_COMPAT_ALL -c -o lua.o lua.c
Now compiling OTH file set...
gcc -O2 -Wall  -DLUA_COMPAT_ALL -c -o luac.o luac.c
luac.c: In function 'PrintConstant':
luac.c:269:2: warning: format '%d' expects argument of type 'int', but argument
2 has type 'lua_Integer' [-Wformat=]
  printf(LUA_INTEGER_FMT,ivalue(o));
  ^
gcc -shared -o lua53.dll  lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o
 lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o
ltm.o lundump.o lvm.o lzio.o lauxlib.o  lbaselib.o lbitlib.o lcorolib.o ldblib.o
 liolib.o lmathlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o loadlib.o linit.o
strip --strip-unneeded lua53.dll
gcc -o lua.exe -s lua.o lua53.dll -lm
ar rcu liblua53.a  lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o
llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o l
undump.o lvm.o lzio.o lauxlib.o  lbaselib.o lbitlib.o lcorolib.o ldblib.o liolib
.o lmathlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o loadlib.o linit.o
ranlib liblua53.a
gcc -o luac.exe   luac.o liblua53.a -lm

Build completed.

C:\Temp\lua-5.3.0-rc0>


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Roberto Ierusalimschy
> lobject.c:327:5: warning: format '%d' expects argument of type 'int', but argume
> nt 3 has type 'lua_Integer' [-Wformat=]
>      len = lua_integer2str(buff, ivalue(obj));
>      ^
> [...]
> liolib.c:612:17: warning: format '%d' expects argument of type 'int', but argume
> nt 3 has type 'lua_Integer' [-Wformat=]
>                  ? fprintf(f, LUA_INTEGER_FMT, lua_tointeger(L, arg))
>                  ^
> [...]
> luac.c:269:2: warning: format '%d' expects argument of type 'int', but argument
> 2 has type 'lua_Integer' [-Wformat=]
>   printf(LUA_INTEGER_FMT,ivalue(o));
>   ^
> [...]

All three warnings are about the same issue. Can you make your code
print the value of LUA_INTEGER_FMT (a string)? It should be "%I64d", not
"%d".  (Just in case, print also the value of macro LUA_INTEGER_FRMLEN,
another string.)

This whole thing is weird, because this code should give a warning
in all other platforms, too...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Roberto Ierusalimschy
> > lobject.c:327:5: warning: format '%d' expects argument of type 'int', but argume
> > nt 3 has type 'lua_Integer' [-Wformat=]
> >      len = lua_integer2str(buff, ivalue(obj));
> >      ^
> > [...]
> > liolib.c:612:17: warning: format '%d' expects argument of type 'int', but argume
> > nt 3 has type 'lua_Integer' [-Wformat=]
> >                  ? fprintf(f, LUA_INTEGER_FMT, lua_tointeger(L, arg))
> >                  ^
> > [...]
> > luac.c:269:2: warning: format '%d' expects argument of type 'int', but argument
> > 2 has type 'lua_Integer' [-Wformat=]
> >   printf(LUA_INTEGER_FMT,ivalue(o));
> >   ^
> > [...]
>
> All three warnings are about the same issue. Can you make your code
> print the value of LUA_INTEGER_FMT (a string)? It should be "%I64d", not
> "%d".  (Just in case, print also the value of macro LUA_INTEGER_FRMLEN,
> another string.)
>
> This whole thing is weird, because this code should give a warning
> in all other platforms, too...

Does that compiler define _WIN32? If not, try defining LUA_USE_WINDOWS...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Documentation now Open , can LUA OpenCV ?

Achromat
Hello together

on some wiches we have Open the Documentation for using LUA with an
VisionServer. (in German an translator we need)

http://drive.google.com/viewerng/viewer?url=www.flexxvision.de/Handbuch+PatControl.pdf

The integrated Editor and Debugger is usefull to test LUA Stuff easy with
our WebCam.

For this documentation i will inform the reader about what can LUA external
Librarys do.

Question : Give it an OpenCV Support that would be funny ?

Greetings
Karsten Schulz
www.flexxvision.de






-----Ursprüngliche Nachricht-----
From: Roberto Ierusalimschy
Sent: Monday, December 15, 2014 4:44 PM
To: Lua mailing list
Subject: Re: [ANN] Lua 5.3.0 (rc0) now available

> > lobject.c:327:5: warning: format '%d' expects argument of type 'int',
> > but argume
> > nt 3 has type 'lua_Integer' [-Wformat=]
> >      len = lua_integer2str(buff, ivalue(obj));
> >      ^
> > [...]
> > liolib.c:612:17: warning: format '%d' expects argument of type 'int',
> > but argume
> > nt 3 has type 'lua_Integer' [-Wformat=]
> >                  ? fprintf(f, LUA_INTEGER_FMT, lua_tointeger(L, arg))
> >                  ^
> > [...]
> > luac.c:269:2: warning: format '%d' expects argument of type 'int', but
> > argument
> > 2 has type 'lua_Integer' [-Wformat=]
> >   printf(LUA_INTEGER_FMT,ivalue(o));
> >   ^
> > [...]
>
> All three warnings are about the same issue. Can you make your code
> print the value of LUA_INTEGER_FMT (a string)? It should be "%I64d", not
> "%d".  (Just in case, print also the value of macro LUA_INTEGER_FRMLEN,
> another string.)
>
> This whole thing is weird, because this code should give a warning
> in all other platforms, too...

Does that compiler define _WIN32? If not, try defining LUA_USE_WINDOWS...

-- Roberto


Reply | Threaded
Open this post in threaded view
|

[PATCH] HPUX dynamic library loading support for 5.3.0 (rc0) [Was Re: [ANN] Lua 5.3.0 (rc0) now available]

Gary V. Vaughan
In reply to this post by Luiz Henrique de Figueiredo
On Dec 11, 2014, at 4:46 PM, Luiz Henrique de Figueiredo <[hidden email]> wrote:

>
> Lua 5.3.0 (rc0) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-rc0.tar.gz
>
> MD5 4692ad494c1d597888c03c5d6f278c40  -
> SHA1 5da073fe552a9f2e2da57be3cec32378a4c902e0  -
>
> This is the first release candidate for the final release of Lua 5.3.0.
>
> A few things have changed since beta that we'd like to test in the wild,
> hence rc0 instead of rc1. In particular, we made some changes in luaconf.h
> and in the Makefile that we'd like to test. Please try compiling the
> current code in as many platforms as possible. We expect the compilation to
> go smoothly as usual but please report any warnings or other glitches.
>
> The main change in Lua 5.3.0 is the introduction of integers. See also
> http://www.lua.org/work/doc/#changes
>
> The complete diffs are available at
> http://www.lua.org/work/diffs-lua-5.3.0-beta-rc0.txt
>
> An updated test suite is available at
> http://www.lua.org/work/lua-5.3.0-tests.tar.gz
>
> All feedback welcome. Thanks.
> --lhf
I've been meaning to post this patch for consideration for several years.  It is
non-intrusive, with no impact on other architectures, simply adding support for
loading of dynamic libraries on IA64 and HPPA HPUX 11.00 and newer.

While HPUX 11.31 has finally introduced dlopen() support, those calls are not
available to production machines with older releases of the OS installed, and in
any case, the official APIs are still the usual way to open library objects even
on 11.31 where the dlopen() compatibility wrappers are provided.

In case the patch does not make it in to the official release, at least this post
makes it available in the list archives for other HPUX users to discover.

Cheers,
--
Gary V. Vaughan (gary AT vaughan DOT pe)





lua-5.3.0-shl_load.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPUX dynamic library loading support for 5.3.0 (rc0) [Was Re: [ANN] Lua 5.3.0 (rc0) now available]

Luiz Henrique de Figueiredo

> I've been meaning to post this patch for consideration for several years.

Talk about the speed of Lua releases... :-)

> adding support for loading of dynamic libraries on IA64 and HPPA HPUX 11.00 and newer.

My loadlib library for Lua 4.0 released in 2002 already contained a port of
dlopen and friends which seems similar to yours:
        http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#loadlib
However, I doubt it has been widely tested, so thanks for this.
People searching for this in the lua-l archives will be glad to find your post.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] HPUX dynamic library loading support for 5.3.0 (rc0) [Was Re: [ANN] Lua 5.3.0 (rc0) now available]

Gary V. Vaughan
Hi Luiz,

On Dec 15, 2014, at 6:17 PM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
>> I've been meaning to post this patch for consideration for several years.
>
> Talk about the speed of Lua releases... :-)

I've been selfishly keeping it to myself all the while, sorry!  But, who uses
HPUX 11.00 these days, anyway? ;-)

>> adding support for loading of dynamic libraries on IA64 and HPPA HPUX 11.00 and newer.
>
> My loadlib library for Lua 4.0 released in 2002 already contained a port of
> dlopen and friends which seems similar to yours:
> http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#loadlib
> However, I doubt it has been widely tested, so thanks for this.
> People searching for this in the lua-l archives will be glad to find your post.

Indeed.  Maybe even me, since I already lost it once and had to rewrite it.

(Hello, future self!)

Cheers,
--
Gary V. Vaughan (gary AT vaughan DOT pe)


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (rc0) now available

Roberto Ierusalimschy
In reply to this post by Roberto Ierusalimschy
> > > lobject.c:327:5: warning: format '%d' expects argument of type 'int', but argume
> > > nt 3 has type 'lua_Integer' [-Wformat=]
> > >      len = lua_integer2str(buff, ivalue(obj));
> > >      ^
> > > [...]
> > > liolib.c:612:17: warning: format '%d' expects argument of type 'int', but argume
> > > nt 3 has type 'lua_Integer' [-Wformat=]
> > >                  ? fprintf(f, LUA_INTEGER_FMT, lua_tointeger(L, arg))
> > >                  ^
> > > [...]
> > > luac.c:269:2: warning: format '%d' expects argument of type 'int', but argument
> > > 2 has type 'lua_Integer' [-Wformat=]
> > >   printf(LUA_INTEGER_FMT,ivalue(o));
> > >   ^
> > > [...]

Thijs and I figured out the problem. TDM64 (and maybe other gcc
compilers for Windows) does not recognize Windows-specific options in
formats (such as '%I64d') and handles them incorrectly. Despite the
warnings, the compiler generates correct code.

One solution would be to use ISO standard stuff to handle 64-bit
integers (long long, %lld, LLONG_MAX), instead of Windows-specific
stuff (__int64, %I64d, _I64_MAX). At least in my test box (VS 2010), that
works, but I am not sure about other Windows. (In particular, I could
not find anything about LLONG_MAX in Microsoft documentation.) For now,
we will leave at it is.

-- Roberto

12