modules, require, magic

classic Classic list List threaded Threaded
160 messages Options
1 ... 5678
Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Luiz Henrique de Figueiredo
> I would like to discuss the plans and progress for porting the various
> libraries to Lua 5.2.

I plan to update my libraries to Lua 5.2 as soon as it is released.
I don't expect much change except a general clean-up.
If anyone has a request, now is a good time to make it.
(It's also useful to know if nobody cares, in which case I can avoid the
trouble...)

My libraries are at
        http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/

All feedback welcome.

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Mike Nelson
On 11/7/2011 6:23 PM, Luiz Henrique de Figueiredo wrote:

> I plan to update my libraries to Lua 5.2 as soon as it is released.
> I don't expect much change except a general clean-up.
> If anyone has a request, now is a good time to make it.
> (It's also useful to know if nobody cares, in which case I can avoid the
> trouble...)
>
> My libraries are at
> http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/
>
> All feedback welcome.
>
>

Thank you very much--great to hear. For myself, lrandom and the various
parsing libs are of particular interest. Though they all look good and
I'm likely to use all the 5.1 libs as they are ported to 5.2.

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Petite Abeille
In reply to this post by Luiz Henrique de Figueiredo

On Nov 8, 2011, at 3:23 AM, Luiz Henrique de Figueiredo wrote:

> (It's also useful to know if nobody cares, in which case I can avoid the
> trouble...)
> My libraries are at
> http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/
>
> All feedback welcome.

I do use the following libraries, in various functions:

lalarm
lascii85
lbase64
lgdbm
lmd5
lpack
lposix
lrandom
luuid

It would be great to see them officially ported to 5.2 in due time :)

Thank you very much :)


Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

steve donovan
On Tue, Nov 8, 2011 at 8:38 AM, Petite Abeille <[hidden email]> wrote:
> It would be great to see them officially ported to 5.2 in due time :)

Can the C preprocessor make the situation easier here, at least for
relatively simple libraries?

It's a bother looking after different versions of the source.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Pierre Chapuis
In reply to this post by Mike Nelson
On 07.11.2011 23:59, Mike Nelson wrote:

> I would like to discuss the plans and progress for porting the
> various libraries to Lua 5.2. I am particularly interested in alien,
> but no doubt the status of other libraries is quite useful info. I
> already use the 5.2 version of lfs for my Widows Vista machine and am
> looking forward to trying other stuff in 5.2.

Is alien even still maintained? If I remember well it doesn't even
work with recent revisions of LuaJIT (since it's strict on the syntax
of patterns).

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Peter Drahoš

On Nov 8, 2011, at 09:34 , Pierre Chapuis wrote:

> On 07.11.2011 23:59, Mike Nelson wrote:
>
>> I would like to discuss the plans and progress for porting the
>> various libraries to Lua 5.2. I am particularly interested in alien,
>> but no doubt the status of other libraries is quite useful info. I
>> already use the 5.2 version of lfs for my Widows Vista machine and am
>> looking forward to trying other stuff in 5.2.
>
> Is alien even still maintained? If I remember well it doesn't even
> work with recent revisions of LuaJIT (since it's strict on the syntax
> of patterns).
I don't think it is. Also alien has issues when compiled with MinGW I would consider to move to LuaFFI (modeled after luajit2 ffi api) [1].

pd

[1] https://github.com/jmckaskill/luaffi
Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Miles Bader-2
Peter Drahoš <[hidden email]> writes:
> I don't think it is. Also alien has issues when compiled with MinGW I
> would consider to move to LuaFFI (modeled after luajit2 ffi api) [1].

LuaFFI isn't portable though; is alien?

-Miles

--
On a bad day, I see brewers still talking as though all beer were
consumed in the pub, by the pint -- by insatiably thirsty Yorkshire
steelworkers who have in reality long ago sought work as striptease
artists.  [Michael Jackson]

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Luiz Henrique de Figueiredo
In reply to this post by steve donovan
> Can the C preprocessor make the situation easier here, at least for
> relatively simple libraries?
>
> It's a bother looking after different versions of the source.

Sure, that's a problem. When we moved to 5.1 I changed my libraries to
work with both 5.0 and 5.1 and distributed a single package. Since then
I've created packages for 5.1 for almost all my tools. For 5.2 I think
I'll start with the same source but keep separate packages. In any case,
the changes are fairly minor, typically this:

==> 5.1/lrandom.c <==

LUALIB_API int luaopen_random(lua_State *L)
{
 luaL_newmetatable(L,MYTYPE);
 lua_setglobal(L,MYNAME);
 luaL_register(L,MYNAME,R);
 ...
 
==> 5.2/lrandom.c <==

LUALIB_API int luaopen_random(lua_State *L)
{
 luaL_newmetatable(L,MYTYPE);
 luaL_setfuncs(L,R,0);
#ifdef EXPORT_GLOBAL
 lua_pushvalue(L,-1);
 lua_setglobal(L,MYNAME);
#endif
 ...

diff -u 5.1/test.lua 5.2/test.lua
-require"random"
+local random=require"random"

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Daurnimator
On 8 November 2011 21:54, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

> ==> 5.1/lrandom.c <==
>
> LUALIB_API int luaopen_random(lua_State *L)
> {
>  luaL_newmetatable(L,MYTYPE);
>  lua_setglobal(L,MYNAME);
>  luaL_register(L,MYNAME,R);
>  ...
>
> ==> 5.2/lrandom.c <==
>
> LUALIB_API int luaopen_random(lua_State *L)
> {
>  luaL_newmetatable(L,MYTYPE);
>  luaL_setfuncs(L,R,0);
> #ifdef EXPORT_GLOBAL
>  lua_pushvalue(L,-1);
>  lua_setglobal(L,MYNAME);
> #endif
>  ...
>
> diff -u 5.1/test.lua 5.2/test.lua
> -require"random"
> +local random=require"random"
>
>

Why not have an EXPORT_GLOBAL for both 5.1 and 5.2? (defaults on for
5.1; off for 5.2)
I'd rather my 5.1 libraries didn't make a global.

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Luiz Henrique de Figueiredo
> Why not have an EXPORT_GLOBAL for both 5.1 and 5.2? (defaults on for
> 5.1; off for 5.2)
> I'd rather my 5.1 libraries didn't make a global.

Sure, it's a good idea.

I plan to continue supporting the 5.1 libraries and so they'll also
probably get a new release when 5.2 comes out.

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Roberto Ierusalimschy
In reply to this post by Mike Nelson
> I would like to discuss the plans and progress for porting the
> various libraries to Lua 5.2. I am particularly interested in alien,
> but no doubt the status of other libraries is quite useful info. I
> already use the 5.2 version of lfs for my Widows Vista machine and
> am looking forward to trying other stuff in 5.2.

A good start for many libraries would be to update them to 5.1 ;)

As the standard Lua distribution comes with "compat on", many libraries
still use features deprecated in 5.1 (e.g., 'luaL_reg' instead of
'luaL_Reg'). It would be useful to get Lua compiled with compats off
and test the libraries there.

(That change does not even have to wait for the final release of Lua
5.2.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Mike Nelson
In reply to this post by Peter Drahoš
On 11/8/2011 12:52 AM, Peter Drahoš wrote:
> .... Also alien has issues when compiled with MinGW I would consider to move to LuaFFI (modeled after luajit2 ffi api) [1].
>
> pd
>
> [1] https://github.com/jmckaskill/luaffi
>
Thanks for the link. I'll give luaffi a try--it looks really promising.

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

James McKaskill-2
In reply to this post by Miles Bader-2

On Nov 8, 2011, at 04:12 , Miles Bader wrote:

> Peter Drahoš <[hidden email]> writes:
>> I don't think it is. Also alien has issues when compiled with MinGW I
>> would consider to move to LuaFFI (modeled after luajit2 ffi api) [1].
>
> LuaFFI isn't portable though; is alien?

What target are you trying to port to?

-- James

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Miles Bader-2
James McKaskill <[hidden email]> writes:
>>> I don't think it is. Also alien has issues when compiled with MinGW I
>>> would consider to move to LuaFFI (modeled after luajit2 ffi api) [1].
>>
>> LuaFFI isn't portable though; is alien?
>
> What target are you trying to port to?

Hmm, is that relevant to whether it's portable or not...?

-Miles

--
"... The revolution will be no re-run brothers; The revolution will be live."

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Jay Carlson
In reply to this post by Miles Bader-2


On Nov 8, 2011 4:13 AM, "Miles Bader" <[hidden email]> wrote:
>
> Peter Drahoš <[hidden email]> writes:
> > I don't think it is. Also alien has issues when compiled with MinGW I
> > would consider to move to LuaFFI (modeled after luajit2 ffi api) [1].
>
> LuaFFI isn't portable though; is alien?

What do you mean by portable? I thought it was impossible in ANSI C to write Lisp's apply--that is, call an arbitrary function with an arbitrary list of arguments. The signature must be known at compile-time.[1] Now that I think of it, ANSI C has no runtime type information anyway so it is impossible to even describe the argument list.

It might be reasonable to say "libffi is on every platform I care about portability to" but that's different.

Jay

[1]: For i386 people and those who remember when memory was faster than CPUs: many modern ABIs' function calling conventions do not look at all like "push args as if they were a struct" or even "put the first couple args in registers if they are int-sized, otherwise push." For starters, if you have floating point registers you want to keep args there. I really enjoyed reading the MIPS NUBI proposal; it talks about the history of the ABIs on the platform and what tradeoffs might be.

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Miles Bader-2
Jay Carlson <[hidden email]> writes:
>> > I don't think it is. Also alien has issues when compiled with MinGW I
>> > would consider to move to LuaFFI (modeled after luajit2 ffi api) [1].
>>
>> LuaFFI isn't portable though; is alien?
>
> What do you mean by portable?

What you (probably) think: can be compiled any system that Lua can.

> I thought it was impossible in ANSI C to write Lisp's apply--that is,
> call an arbitrary function with an arbitrary list of arguments. The
> signature must be known at compile-time.[1] Now that I think of it,
> ANSI C has no runtime type information anyway so it is impossible to
> even describe the argument list.

No doubt, but thus my question:  what does alien do?  Maybe it isn't
portable either, or maybe it is portable, but has less functionality
than LuaFFI.

This isn't necessarily a pointless question.  While it may be impossible
to completely support everything FFI does portably, maybe there are
useful subsets, or alternative interfaces, which _can_ be done portably
(or "sorta portably" -- making assumptions that aren't strictly true but
are defacto true in any existing ABI).  For instance, the sizes of C
types can be discovered by a C program.

Since many people seem to basically use FFI as an alternative to
stub-generators, maybe something halfway in between could be more
convenient, and yet still avoid machine-dependent code.

Anyway, I'm just tossing out ideas here...

-Miles

--
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

steve donovan
On Thu, Nov 10, 2011 at 12:35 PM, Miles Bader <[hidden email]> wrote:

> Jay Carlson <[hidden email]> writes:
>>> > I don't think it is. Also alien has issues when compiled with MinGW I
>>> > would consider to move to LuaFFI (modeled after luajit2 ffi api) [1].
>>>
>>> LuaFFI isn't portable though; is alien?
>>
>> What do you mean by portable?
>
> What you (probably) think: can be compiled any system that Lua can.
>
>> I thought it was impossible in ANSI C to write Lisp's apply--that is,
>> call an arbitrary function with an arbitrary list of arguments. The
>> signature must be known at compile-time.[1] Now that I think of it,
>> ANSI C has no runtime type information anyway so it is impossible to
>> even describe the argument list.
> No doubt, but thus my question:  what does alien do?  Maybe it isn't
> portable either, or maybe it is portable, but has less functionality
> than LuaFFI.

libffi (on which Alien is based) does a remarkable job of tracking all
those ABI differences for many architectures.

OK, the result isn't as fast as LuaJIT ffi, but often we don't need
particularly fast calls to system operations.

For LuaJIT ffi we of course are all waiting for callback support, but
that's apparently very tricky. Keeping track of closures and ensuring
that they are eventually freed, and so forth.

For C++, well that's a bitch beyond FFI.  When I was last doing this
kind of thing, I had to track a MS compiler and two different GCC
versions, and that was _just_ x86.  (GCC was going through a growth
spurt ;))

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Jay Carlson
In reply to this post by Miles Bader-2
On Thu, Nov 10, 2011 at 10:35 AM, Miles Bader <[hidden email]> wrote:
> Jay Carlson <[hidden email]> writes:

>>> LuaFFI isn't portable though; is alien?
>>
>> What do you mean by portable?
>
> What you (probably) think: can be compiled any system that Lua can.

Then no, since Lua aspires to compile and work on any ANSI C machine.
I think it's important to understand this limit. Many things many wish
to do cannot be accomplished within that constraint. In my opinion a
more important question is how much work a port of an extension
requires per platform/flavor, and what other costs it imposes.

>> I thought it was impossible in ANSI C to write Lisp's apply--that is,
>> call an arbitrary function with an arbitrary list of arguments. The
>> signature must be known at compile-time.[1] Now that I think of it,
>> ANSI C has no runtime type information anyway so it is impossible to
>> even describe the argument list.
>
> No doubt, but thus my question:  what does alien do?

It is a mystery.

> [...] While it may be impossible
> to completely support everything FFI does portably, maybe there are
> useful subsets, or alternative interfaces, which _can_ be done portably

You need to compile and link code, since under the portability
constraint (as we're discussing it) only the compiler understands the
ABI. Similarly, libffi cannot be portable; machine-specific code must
be written for each ABI. (As Steve points out this has already been
done well for most common and uncommon platforms.)

I can see one shortcut, although I'm not really a C language lawyer.
Any function with signature X may be called through a pointer to a
function with compatible signature X. It's not necessary to have one C
stub per function linked to; it suffices to have one per compatible
signature. If you do have additional (non-portable) knowledge about
the platform, it may be possible to merge more stubs; one case is if
you know a pointer to an int is passed in the same way as a pointer to
a struct.

> For instance, the sizes of C
> types can be discovered by a C program.

This is more complicated than it looks. When you compile
printf("%zu",sizeof(int)) it references a size_t constant, which is
printed at runtime. But at runtime there's no function
sizeof_type_name("int") to return 8. What would be quite useful is
sizeof_type_name("FILE") to return 148, or after dynamically loading
libpng12, sizeof_type_name("struct png_text_struct"). This information
is in the debugging symbols, but they are usually stripped from
binaries delivered to users; historically debug info was very
different from platform to platform. Instead of writing a C
declaration parser, browsing debug information may have some merit
though.

In a traditional self-hosted build process you can write a program
that prints the sizeof all the types you care about and then generate
C code based on that. But in cross-compilation environments, you may
not have the ability to run code you compile. At some point autoconf
gained the ability to deduce compile-time constants at by...declaring
an array of size 1-2*!(expr). If expr is false, the size of the array
is -1, and the compile fails. autoconf then does a *BINARY SEARCH* of
the integers for the value....

Jay
(why yes I did have to look up the C99 size_t qualifier for printf,
and then I still wrote "%zd", which is incorrect because size_t is
unsigned.)

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Fabio Mascarenhas
In reply to this post by Pierre Chapuis
Can you file a bug report about this on
https://github.com/mascarenhas/alien/issues? Ditto if compatibility
with Lua 5.2 is broken right now (I got it working with a previous
version of 5.2, but the API was still in flux).

--
Fabio Mascarenhas


On Tue, Nov 8, 2011 at 6:34 AM, Pierre Chapuis <[hidden email]> wrote:

> On 07.11.2011 23:59, Mike Nelson wrote:
>
>> I would like to discuss the plans and progress for porting the
>> various libraries to Lua 5.2. I am particularly interested in alien,
>> but no doubt the status of other libraries is quite useful info. I
>> already use the 5.2 version of lfs for my Widows Vista machine and am
>> looking forward to trying other stuff in 5.2.
>
> Is alien even still maintained? If I remember well it doesn't even
> work with recent revisions of LuaJIT (since it's strict on the syntax
> of patterns).
>
> --
> Pierre Chapuis
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Status of 5.2 ports

Pierre Chapuis
In reply to this post by Mike Nelson
On 21.11.2011 14:27, Fabio Mascarenhas wrote:
> Can you file a bug report about this on
> https://github.com/mascarenhas/alien/issues? Ditto if compatibility
> with Lua 5.2 is broken right now (I got it working with a previous
> version of 5.2, but the API was still in flux).

https://github.com/mascarenhas/alien/issues/4


1 ... 5678