develooper Front page | perl.perl5.porters | Postings from December 2019

Re: updating POSIX module for newer functions

Thread Previous | Thread Next
Sawyer X
December 28, 2019 19:48
Re: updating POSIX module for newer functions
Message ID:

On 12/17/19 9:18 AM, Eric Wong wrote:
>> On Mon, Dec 16, 2019 at 2:51 PM Eric Wong <> wrote:
>>> Hello all, I noticed POSIX.pod states it's for IEEE Std 1003.1,
>>> but I figure it'll be useful to support new functionality...
> Hi Mark, Dan; thanks for the responses so far.
> Some background here: most users of my software get Perl from
> their GNU/Linux distros or BSD ports.  And a big reason why I
> choose Perl is that it's widely available out-of-the-box and
> users typically don't need to install extra dependencies.
> CPAN modules which aren't packaged by the distro are extra
> overhead for them to learn, download and install; and they
> already complain about dependencies.  Most of them are not Perl
> hackers.  Even getting them to consider using software written
> in Perl these days is a challenge :<
> Mark Overmeer <> wrote:
>> There are about 1800 functions in the 2008 release.
>> and CORE together support about 100 (but also not really strict) 
>> There are some modules on CPAN which implement some additional
>> functions.  A few dozen.
> Right, some are abandoned and most of those are not available
> from distros.
>> I started POSIX::1003 which tries to provide all functions... as
>> pure as feasible.  But... I need to rework it into a more flexible
>> installation structure using Config::AutoConf.  Help welcome ;-)
>> When I get help, I will increase its priority.
> Any reason you choose to work on a new module rather than
> improving the existing POSIX one?  I certainly don't see the
> need for all functions in POSIX, especially the ones which
> are made redundant by CORE functions.
> Dan Book <> wrote:
>> If it's at all helpful, it's trivial to write a FFI::Platypus wrapper of
>> POSIX functions available on the system, such as I did in Unix::Groups::FFI.
> Yup.  I favor Inline(::C) since it's more widely-packaged
> (for example, perl-Inline is in CentOS/RHEL 7.x and AFAIK
> Platypus is not).
> I may even favor syscall() for popular platforms since there's
> no extra .so loading and no need to have a compiler installed.
> But I consider those dependencies interim solutions because of
> the extra installation burden it places on users (and distro
> maintainers).  And this probably a big reason why AOT-compiled
> languages like Go with giant binaries are gaining favor
> nowadays.

Is it not possible to go the path that Mark suggests by compiling a big
Perl binary with the additional modules?

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About