[ANN] luaposix 5.1.28 released

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

[ANN] luaposix 5.1.28 released

Reuben Thomas-5
I am happy to announce the release of luaposix 5.1.28,
Lua bindings for POSIX (including curses).

This release fixes the previously unannounced posix.pipeline_iterator and
posix.pipeline_slurp functions, and adds a test for them. A workaround for
having LUA_INIT_5_2 set has been added to the build system.

Install it as luarock luaposix-5.1.28 (see
http://luarocks.org/repositories/rocks )

Most simply:

  luarocks install luaposix

(You may need to wait a while after this announcement lands before the
rocks are available.)

luaposix's home page is at http://github.com/luaposix/luaposix/

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

Ico Doornekamp
Hi rrt,

* On Sat Mar 23 13:43:25 +0100 2013, rrt wrote:
 
> I am happy to announce the release of luaposix 5.1.28,
> Lua bindings for POSIX (including curses).

Just a quick thank-you note for making and maintaining luaposix. I've
been able to throw away a big chunk of OS-glue code that I have been
growing and carrying with me for the last 10 years or so, and replace it
neatly with your lib - and getting ncurses as a free bonus!

Keep up the good work,

Ico

--
:wq
^X^Cy^K^X^C^C^C^C

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

Reuben Thomas-5
On 5 April 2013 09:51, Ico <[hidden email]> wrote:
Hi rrt,

* On Sat Mar 23 13:43:25 +0100 2013, rrt wrote:

> I am happy to announce the release of luaposix 5.1.28,
> Lua bindings for POSIX (including curses).

Just a quick thank-you note for making and maintaining luaposix. I've
been able to throw away a big chunk of OS-glue code that I have been
growing and carrying with me for the last 10 years or so, and replace it
neatly with your lib - and getting ncurses as a free bonus!

Thanks! I'm glad not only that you find it useful but specifically that it has saved you code, as that's precisely the aim.

You may be interested in issue #70, which if implemented would improve the functionality of luaposix on many systems.

--
http://rrt.sc3d.org
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

D Burgess-4
In reply to this post by Reuben Thomas-5
Hi,
I have a simple request. Would it be possible to provide a simple
makefile and default config.h that can be used without
configure/automake/m4/rocks etc?

My other question is about -fpic no longer required?

On Sat, Mar 23, 2013 at 11:43 PM,  <[hidden email]> wrote:

> I am happy to announce the release of luaposix 5.1.28,
> Lua bindings for POSIX (including curses).
>
> This release fixes the previously unannounced posix.pipeline_iterator and
> posix.pipeline_slurp functions, and adds a test for them. A workaround for
> having LUA_INIT_5_2 set has been added to the build system.
>
> Install it as luarock luaposix-5.1.28 (see
> http://luarocks.org/repositories/rocks )
>
> Most simply:
>
>   luarocks install luaposix
>
> (You may need to wait a while after this announcement lands before the
> rocks are available.)
>
> luaposix's home page is at http://github.com/luaposix/luaposix/
>



--
David Burgess

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

Dirk Laurie-2
2013/4/6 David Burgess <[hidden email]>:

> I have a simple request. Would it be possible to provide a simple
> makefile and default config.h that can be used without
> configure/automake/m4/rocks etc?

In general, not just for this pacakge, why can't we aim at any package
to build with exactly the same command as Lua itself uses? Surely
few of us write packages of greater complexity. So it should just be
a matter of replacing the contents of the src directory in the Lua
distribution with one's own stuff and changing some target names.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

steve donovan
In reply to this post by D Burgess-4
On Sat, Apr 6, 2013 at 8:45 AM, David Burgess <[hidden email]> wrote:
I have a simple request. Would it be possible to provide a simple
makefile and default config.h that can be used without
configure/automake/m4/rocks etc?

The configure logic needed to generate config.h is not very complicated. I've had success with this simple recipe from luabuild:

local libs
local cfg = {HAVE_CRYPT=true, HAVE_CRYPT_H=true, VERSION = "5.1.20"}
if PLAT~='Darwin' then
    libs = 'crypt '
else
    cfg.HAVE_CRYPT_H = false
end
if PLAT=='Linux' then
    libs = libs .. 'rt'
end

cfg.HAVE_SYS_STATVS_H = find.include_path 'sys/statvfs.h' ~= nil
cfg.HAVE_STATVS = cfg.HAVE_SYS_STATVS_H ~= nil

luabuild.write_config_header('config.h',cfg)

luabuild.lua 'posix'
luabuild.test 'tests-posix.lua'

return luabuild.library {'posix_c',src='lposix',libs=libs,incdir='.'}
 
I'm sure that a straightforward bash configure script would do the job.
 
My other question is about -fpic no longer required?

It will definitely be required on 64-bit Linux systems

 
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

steve donovan
In reply to this post by Dirk Laurie-2
On Sat, Apr 6, 2013 at 8:51 AM, Dirk Laurie <[hidden email]> wrote:
few of us write packages of greater complexity. So it should just be
a matter of replacing the contents of the src directory in the Lua
distribution with one's own stuff and changing some target names.

Apart from the word 'just', luabuild does something like that.

It's a fact of life that (even in the POSIX world) things are different and build scripts need to know the differences.   Even if it's just one header, that header can move all over the place and might have a different name (e.g. building against tcl).  Lua is blessedly simple in comparison to many packages.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

Ross Bencina
In reply to this post by Dirk Laurie-2
On 6/04/2013 5:51 PM, Dirk Laurie wrote:
> In general, not just for this pacakge, why can't we aim at any package
> to build with exactly the same command as Lua itself uses? Surely
> few of us write packages of greater complexity. So it should just be
> a matter of replacing the contents of the src directory in the Lua
> distribution with one's own stuff and changing some target names.

Why can't we? to play devil's advocate:

1. There may be additional system include paths that are needed for
building the package.

2. There may be additional libraries (shared or static) that need to be
linked with the package.

This raises at least the following 3 points of variation:

A) If the dependencies are assumed to be installed:

A.1 are they always in the same location?

=> then use a single path for libraries and includes.

or
A.2 are they in different locations on different machines or operating
system versions?

=> then determine the path on the current system


B) If the dependencies may not be installed:

B.1 determine whether the dependency is installed

=> then use them in A.1 or A.2 or fail.


Note here I'm not talking about Lua rocks dependencies, just system
libraries and header files that may not be installed.


Case A.1 can probably be achieved using your minimal approach (even
A.1+B.1 can work if the optional dependency is installed and only has
one possible install location). A.2 and B.1 require more logic to do
robustly.

Ross.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

D Burgess-4
In reply to this post by steve donovan
I should have explained that I would like to build luaposix natively
on a target machine that has *no* automake

BTB I prefer the Mike Paul style builds (see bitop)

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

steve donovan
In reply to this post by D Burgess-4
On Sat, Apr 6, 2013 at 8:45 AM, David Burgess <[hidden email]> wrote:
I have a simple request. Would it be possible to provide a simple
makefile and default config.h

This is particularly important for something like luarocks, since you don't need to provide a full-on build, just a means to make the software.  A rockspec could be written with per-platform overrides which would be almost as flexible and not even need (g)make!

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

steve donovan
In reply to this post by D Burgess-4
On Sat, Apr 6, 2013 at 9:32 AM, David Burgess <[hidden email]> wrote:
BTB I prefer the Mike Paul style builds (see bitop)

He really does good makefiles.  I appreciate that automake handles the 5% weirdo cases but why make minority platforms a problem for everyone else?  (Not intended to revive any 'hate autotools debate', just want throw in a 5c about rockspecs that work without build tool dependencies) 

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

D Burgess-4
In reply to this post by steve donovan
On Sat, Apr 6, 2013 at 6:32 PM, steve donovan
<[hidden email]> wrote:> > This is particularly important
for something like luarocks, since you don't
> need to provide a full-on build, just a means to make the software.  A
> rockspec could be written with per-platform overrides which would be almost
> as flexible and not even need (g)make!

I had a look a rocks many years ago and decided I did not like it,
maybe it is time to have another look. If rocks does that then good, I
just want to know what #defines, compile/link options are used on (say
linux) and I can then map this pretty quickly to my target platform.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

D Burgess-4
In reply to this post by steve donovan
*Thank you* Steve for summarizing the issue!

On Sat, Apr 6, 2013 at 6:39 PM, steve donovan <[hidden email]> wrote:

> On Sat, Apr 6, 2013 at 9:32 AM, David Burgess <[hidden email]> wrote:
>>
>> BTB I prefer the Mike Paul style builds (see bitop)
>
>
> He really does good makefiles.  I appreciate that automake handles the 5%
> weirdo cases but why make minority platforms a problem for everyone else?
> (Not intended to revive any 'hate autotools debate', just want throw in a 5c
> about rockspecs that work without build tool dependencies)
>



--
David Burgess

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

steve donovan
In reply to this post by D Burgess-4
On Sat, Apr 6, 2013 at 9:40 AM, David Burgess <[hidden email]> wrote:
just want to know what #defines, compile/link options are used on (say
linux) and I can then map this pretty quickly to my target platform.

Try this:

// config.h
#define HAVE_STATVS 1
#define HAVE_CRYPT 1
#define VERSION "5.1.20"
#define HAVE_CRYPT_H 1

gcc -c -O2 -Wall -I<lua-include> -I.  -fpic lposix.c -o lposix.o
gcc -shared lposix.o  -lcrypt -lrt  -o posix_c.so

The actual module is posix.lua which loads posix_c

This doesn't include the curses support, of course.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

D Burgess-4
Exactly what I had already derived. I just resent the time it took to
figure it out.

On Sat, Apr 6, 2013 at 6:59 PM, steve donovan <[hidden email]> wrote:

> On Sat, Apr 6, 2013 at 9:40 AM, David Burgess <[hidden email]> wrote:
>>
>> just want to know what #defines, compile/link options are used on (say
>> linux) and I can then map this pretty quickly to my target platform.
>>
> Try this:
>
> // config.h
> #define HAVE_STATVS 1
> #define HAVE_CRYPT 1
> #define VERSION "5.1.20"
> #define HAVE_CRYPT_H 1
>
> gcc -c -O2 -Wall -I<lua-include> -I.  -fpic lposix.c -o lposix.o
> gcc -shared lposix.o  -lcrypt -lrt  -o posix_c.so
>
> The actual module is posix.lua which loads posix_c
>
> This doesn't include the curses support, of course.



--
David Burgess

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] luaposix 5.1.28 released

Miles Bader-2
In reply to this post by steve donovan
steve donovan <[hidden email]> writes:
> He really does good makefiles.  I appreciate that automake handles the 5%
> weirdo cases but why make minority platforms a problem for everyone else?

Note that you're really describing autoconf, not automake.

automake is a "allow the user to write super simple makefiles that
still handle things like automatic dependencies" system, not a
configuration system.

-miles

--
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde