Front page | perl.perl5.porters |
Postings from December 2019
> On Mon, Dec 16, 2019 at 2:51 PM Eric Wong <p5p@yhbt.net> 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 <mark@overmeer.net> wrote: > There are about 1800 functions in the 2008 release. POSIX.pm > 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 <grinnz@gmail.com> 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.Thread Previous | Thread Next