Front page | perl.perl5.porters |
Postings from December 2019
Sawyer X <xsawyerx@gmail.com> wrote: > > On 12/17/19 9:18 AM, Eric Wong wrote: > >> 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. > > > Is it not possible to go the path that Mark suggests by compiling a big > Perl binary with the additional modules? I'm trying to reduce the long-term maintenance and update overhead, so I wouldn't even consider asking users to build/maintain their own Perl install if they aren't comfortable with dependencies which require going outside the distro to CPAN. Again, getting users to even consider software written in Perl is a challenge these days. The fact that Perl5 is packaged, and often installed-by-default on Linux/*BSD distros is something I want to take advantage of in promoting its use.Thread Previous | Thread Next