rt.cpan.org is going away
rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules [1], is going to be shut down on 1st March this year [2]; 39 days from when I write this email. I am rather concerned about this, as there doesn't appear to be any sort of co-ordinated bailout plan or migration of the *huge amount* of CPAN modules this is about to affect. I am furthermore concerned at the total lack of discussion or response that has so far been generated; aside from Karen Etheridge I haven't seen any noise of upset being generated at all. Nor am I aware of any sort of effort to handle what will become a huge outage of a major component of the CPAN ecosystem. I personally have 189 modules in need of migration - somehow. As yet I have no clue what I am going to do about it. Existing bugs need to be moved somewhere else (and I have no clue how I'm going to fix up URLs that currently point to those, in code comments, documentation, blog posts, ... anywhere else), and a new for users to report new bugs needs to exist. Of special note are the numerous "in progress" tickets I have across my distributions, containing ongoing discussions about design issues and the like. To say that I am "concerned" is an understatement; I am fairly close to panicing about this. I am quite sure I am but the smallest tip of the iceberg here. Every time I mention it on Freenode's #perl or irc.perl.org's #p5p there are always new folks who were totally unaware of this fact. This is going to hit lots of people in a very hard surprise. I am therefore interested to know if anyone has any sort of thoughts or plan on what to do about this; either a) Attempts to take over maintenance of the system as it stands, or b) Find an alternative location and implement some sort of mass-bailout in that direction. To emphasise again: in 39 days time the bug tracker used by nearly 80% of all of CPAN is going to be shut down and become unavailable for either historic or newly-reported bugs. We *need* to find a solution in that time. It would be great if we all went the same way, thus making the lives of users (and metacpan.org) a lot simpler, rather than all scattering in 50 different ways, which will cause a huge splintering of what has been a very coherent service so far. 1: Add the "known to be RT" and "unknown" categories of https://cpan.rocks/; because metacpan.org defaults to RT in the latter case. 2: https://log.perl.org/2020/12/rtcpanorg-sunset.html -- Paul "LeoNerd" Evans leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ pgpuxteHPdQtI.pgp Description: OpenPGP digital signature
Re: Extending Proc::ProcessTable::Process with number of file opened and Naming a new package
On Thu, 20 Aug 2020 16:08:43 -0400 "Sven F." wrote: > Dear readers, > > I recently find myself using Prometheus database, > I found about the perl `binding` Net::Prometheus > > Net::Prometheus provides a way to export metrics to > the databases. > > The Any::Metrics generalize the concept to make perl code > not 'glued' to Prometheus. ITYM Metrics::Any > Net::Prometheus provides a few metrics which are linux dependant, > in Net::Prometheus::ProcessCollector::linux > For example , the Package is using the `/proc/$pid/fd` info . > > Perl posses an abstract for processes with Proc::ProcessTable::Process > but this , just like the 'ps' command, lacks the amount of file > opened by a process (which could be quite helpful, this resource > is limited). > > Personally I will -unless strongly advised against- > write a XS package to get that metric in OpenBSD > with kvm_getfiles. > > The only way i currently know to get this info is using `fstat $pid | > wc -l`, fstat , being a lsof in bsds. > > BSD::Process does not have this either but is using the 'kvm' system. > > Linking all of this may create too many dependencies, > nevertheless I know some perl code could be quite smart to > opt in certains sub routines if the right module is available . > So this could be done through 'soft' dependencies. - I do not know > what you call those packages that are optional but work together. If it's an optional dependency that opportunistically loads and works if available, that should be fine. > Of course i will have to name the package, i saw OpenBSD::Checkpass > so it could be OpenBSD::Kvm_getfiles > But it also is a specific implementation so if > Proc::ProcessTable::Process::Files ( which would be the number of > file open and maybe some limits info like the one found in the class > limits/login.conf ) It would look like > Proc::ProcessTable::Process::OpenBSD which seems way too long. > > So i guess OpenBSD::Kvm_getfiles is completely enough > Especially since BSD::Process is not OpenBSD compatible > and freebsd use procstat_getfiles while openbsd use kvm_getfiles. > > Thank you for reading that far, stay safe and > have a good one. I don't have any specific suggestions about OpenBSD, but overall having some process metrics exported from OpenBSD would be good. Whatever's available - don't feel you *have* to support every single one as an exact copy of the Linux ones. Just do whatever makes sense there - different OSes can differ slightly in shape and that's fine. Maybe have a look around some other Prometheus client libs for other langauges, and see if they have any OpenBSD support. Try to copy what they do - different language clients on the same OS should act the same. Maybe also try asking in #prometheus on Freenode. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ pgpWxN47d_z9i.pgp Description: OpenPGP digital signature
Re: Module heirarchy naming for SPI/I²C device drivers
On Thu, 22 Oct 2015 13:45:18 +0200 Aldo Calpini <d...@perl.it> wrote: > I would personally keep Device, most of the hardware-related stuff on > CPAN (not much, but still) is already in that namespace. Agree. > Bus, by itself, is far from unambiguous to me > (https://en.wikipedia.org/wiki/Bus). On the other hand, I think I2C > and SPI are familiar enough to people working - or playing - with > electronics. Ditto. > So I would go for: > > Device::I2C > Device::SPI > > Which are hardware-abstract, and subclassed if/when needed > (Device::I2C::FT232H, etc.). Hmm. I'm not sure I like putting "SPI" or "I²C" or whatever (UART? 1Wire?) in the module name. There are genuinely some chips that are available with a variety of interface types, or some even support a selection of them by different hardware configurations or whatever. So I think that the interface type should be an implementation detail, and not really part of the name. What do you think to simply Device::Chip::* as the namespace for individual chips. E.g Device::Chip::INA219 Device::Chip::MAX7221 I'm not sure if driver adapters (Bus Pirate, FT232H, Raspberry Pi GPIO, etc...) would necessarily warrant a dedicated space too; they become the consumers of these chips, much like my existing Device::BusPirate currently consumes chips within its space. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS pgpoGjIpZZYyr.pgp Description: OpenPGP digital signature
Re: Module heirarchy naming for SPI/I²C device drivers
On Thu, 22 Oct 2015 11:39:00 +0100
Matthew Astley <m...@sanger.ac.uk> wrote:
> The Bus::I2C:: namespace seems safe. Short, unambiguous, unlikely to
> have a legitimate claim from software.
>
> Under that you could put chip names like Bus::I2C::DS1307 [1] but I
> suspect software will fit better by function like Bus::I2C::EEPROM [2]
> since families of chips will naturally share code.
Hmm. I'm not sure I like "Bus" - the driver talks to just one device,
one chip. If it sits on a bus like I2C that's a different concern.
I wonder if simply
Device::Chip::*
> The CPAN search for just I2C shows a few things,
>
> https://metacpan.org/release/i2c (i2c_{ser,lpt})
> https://metacpan.org/pod/HiPi (various under HiPi::*)
> https://metacpan.org/pod/Device::LPS331AP
> https://metacpan.org/pod/Device::Gyroscope::L3GD20
> https://metacpan.org/pod/Device::SMBus
> https://metacpan.org/pod/Device::WebIO::Device::I2CUser
>
> so it's probably too late to converge on one perfect naming scheme
> anyway.
Well there's at least some precedent for putting it under Device::, so
that's a start :)
> I don't see a way to avoid the usual problem with someone releasing
> Bus::I2C::EEPROM::Lite and Bus::I2C::EEPROM::Tiny after the first come
> module gets bloated out with obsolete parts.
Eh... That's a standard problem across the whole of CPAN. We usually
cope fairly well... :)
--
Paul "LeoNerd" Evans
leon...@leonerd.org.uk
http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
pgpNytw7D0Z3W.pgp
Description: OpenPGP digital signature
Module heirarchy naming for SPI/I²C device drivers
[[Background ~~ I've been writing a bunch of modules to talk to specific kinds of hardware chips (sensors, motor controllers, radio interfaces, etc...) that are electrically SPI or I²C. There's likely hundreds or thousands of possibles here. Currently, they all live under the namespace Device::BusPirate::Chip::* because they're written to talk to the hardware device via a particular piece of USB-attached hardware, called a Bus Pirate. However, there's nothing specific about the operation of these SPI or I²C devices, that relates to the Bus Pirate. In particular, there are other computer <-> SPI or I²C adapters available, such as the GPIO port built into a Raspberry Pi, or the FTDI FT232H chip. ]] I'm considering how to name device drivers for talking to these hardware chips in a way that's independent of how that chip is ultimately connected to the computer, and provide an abstracted API that the driver can use to communicate with the chip, regardless of this mechanism. Ultimately, it'd be cool to end up with lots of hardware chip drivers on CPAN that can talk to all kinds of hardware, via whatever mechanism people use to physically attach it. But lets start with the name... -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS pgpszjNsQ2giD.pgp Description: OpenPGP digital signature
Seeking a suitable forum to discuss Scalar/List::Util
Hi all, Sorry for the crosspost, but I'm hoping sufficient numbers of people will be interested in this discussion. I'm finding more lately that I keep thinking up interesting ideas for new features to add to Scalar::Util or List::Util. Given the very core-ish nature of these modules, both literally in the core sense and also in that most of CPAN either directly or indirectly uses them, I feel it best not to just go adding things that might or mightnot be a good idea, but instead to first discuss them some more. Rather than get into the specifics of what my ideas are at this stage, I'd like first to open a meta-discussion on where interested parties might be, and what suggestions we'd have for the best place to actually discuss those ideas? I'm loathe to suggest make a new mailing list or somesuch, mostly because that likely misses most of the people who'd be interested in it. Partly I might just suggest these two lists, unless people on either list object to the traffic. I dunno... thoughts anyone? -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS pgpmgleRIaLV4.pgp Description: OpenPGP digital signature
Re: Seeking a suitable forum to discuss Scalar/List::Util
On Thu, 14 May 2015 13:36:27 -0700 David Christensen dpchr...@holgerdanske.com wrote: Have you tried contacting the module author (Graham Barr in both cases) and/or maintainer (Paul Evans for List::Util)? http://search.cpan.org/~pevans/Scalar-List-Utils-1.42/lib/Scalar/Util.pm http://search.cpan.org/~pevans/Scalar-List-Utils-1.42/lib/List/Util.pm Ummm... Have I tried contacting... myself? ;) -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS pgp4uRjukei5V.pgp Description: OpenPGP digital signature
=head1 SEEN ALSO BY
Random musings from #perl on Freenode: If I write a base module that's intended for expansion/extension (such as Tickit), and then write lots and lots of extensions (see: the entire Tickit::Widget:: namespace), it would be nice as an end-user feature browsing module documentation, to be able to see a list of all those widgets when looking at the base. Sometimes module developers use a =head1 SEE ALSO However, for developers that's a terrible solution. It means the author of the base has to list all the extensions, which will naturally grow over time. As the base becomes more stable, it increasingly means the base does documentation-only releases that just add to that list. Also it's hard for third-parties to add it there. I wonder if therefore, metacpan needs some sort of back-reference ability? That if an extension module could somehow list =head1 SEEN ALSO BY LTickit then such a module declaring that would *automatically* get listed somehow in some automatically-generated and (near)-realtime updated part of the Tickit documentation when viewed via metacpan. Does this sound like something that might gain traction? -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS pgpNfE5DPPYdc.pgp Description: OpenPGP digital signature
Module for making bitfields
[[ background ]]
I've been doing a lot of hardware IO work lately, which involves lots
of talking to hardware devices, where there are byte-wide registers
that store little bitfields, sometimes of individual and unrelated bits
packed together. To make this easier I tend to write myself lots of
pairs of functions to pack/unpack the fields in one of these bytes; for
instance:
use constant {
MASK_RX_RD = 16,
MASK_TX_DS = 15,
MASK_MAX_RT = 14,
EN_CRC = 13,
CRCO= 12,
PWR_UP = 11,
PRIM_RX = 10,
};
sub unpack_CONFIG
{
my ( $config ) = @_;
return
MASK_RX_RD = !!( $config MASK_RX_RD ),
MASK_TX_DS = !!( $config MASK_TX_DS ),
MASK_MAX_RT = !!( $config MASK_MAX_RT ),
EN_CRC = !!( $config EN_CRC ),
CRCO= $CRCOs[!!( $config CRCO )],
PWR_UP = !!( $config PWR_UP ),
PRIM_RX = !!( $config PRIM_RX );
}
sub pack_CONFIG
{
my %config = @_;
return
( $config{MASK_RX_RD} ? MASK_RX_RD : 0 ) |
( $config{MASK_TX_DS} ? MASK_TX_DS : 0 ) |
( $config{MASK_MAX_RT} ? MASK_MAX_RT : 0 ) |
( $config{EN_CRC} ? EN_CRC : 0 ) |
( ( _idx_of $config{CRCO}, @CRCOs )
// croak Unsupported 'CRCO' ) * CRCO |
( $config{PWR_UP} ? PWR_UP : 0 ) |
( $config{PRIM_RX} ? PRIM_RX : 0 ) );
}
This convenient pair of functions bidirectionally converts bytes into
key/value lists. As well as containing 6 simple boolean values, there's
also an enumerated field, represented by the values in the array
@CRCOs. These functions convert those too.
I'm getting tired of writing these pairs of functions. Hey, this is
Perl write? :) I should get Perl to write them for me.
[[ TL;DR - I propose the following ]]
I'd like instead to write something like:
use bitfield;
bitfield CONFIG =
MASK_RX_DS = boolfield(6),
MASK_TX_DS = boolfield(5),
MASK_MAX_RT = boolfield(4),
EN_CRC = boolfield(3),
CRCO= enumfield(2, qw( values here )),
PWR_UP = boolfield(1),
PRIM_RX = boolfield(0);
The operation here is that 'bitfield' is automatically exporting a
function called 'bitfield', along with the various *field() functions
that create field definitions. boolfield() declares a single true/false
boolean bit position, enumfield() declares a range of bits that give
an enumeration. I guess also would be required intfield() to use a
range of bits as an integer, and finally most likely customfield()
taking a pair of conversion CODE refs or somesuch.
What does anyone think to that?
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
signature.asc
Description: PGP signature
Re: Module for making bitfields
On Wed, 24 Sep 2014 15:31:36 +0300 Shmuel Fomberg shmuelfomb...@gmail.com wrote: Hi Paul. Check out Data::ParseBinary. I developed it for similar tasks. That looks to be quite a large system for doing structs and similar; and doesn't appear to support the enum conversion case of fields, like I have here. E.g. see the 'CRCO' field. Additionally though, I do like the Data:: namespace - I should probably name mine Data::Bitfield, rather than the lowercase 'bitfield'. -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
Re: Aliens depending on Aliens
On Mon, 6 Jan 2014 20:02:31 -0500 Chris Marshall devel.chm...@gmail.com wrote: pkg-config has a standard format. I see no reason why the Alien::unibilium could not make a valid .pc file that could be used by the standard autoconf enabled builds. So, it seems my solution is to have Alien::unibilium's build process write a .pc file. Simple, right? :) Only, not quite so, because unibilium's make install will already write one. So additionally I'll have to hunt that one down and rewrite its contents. While understanding it all. Including all those variable expansions and anything else the format might generate. This is starting to sound worse... -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Re: Aliens depending on Aliens
On Tue, 7 Jan 2014 01:22:30 +0100 Aristotle Pagaltzis pagalt...@gmx.de wrote: You need to configure_requires Alien::unibilium and the module must provide API to query its install location such that the Makefile.PL or Build.PL from Alien::libtermkey can set things up as necessary. (Or maybe Alien::unibilium would provide API to tweak the environment to taste. Not sure which one would be the less leaky abstraction.) I'm not following. Alien::libtermkey does indeed configure_require Alien::unibilium. When the perl-level Alien::libtermkey's Build.PL runs, it is of course free to make queries of Alien::unibilium. But what good does this do? Alien::libtermkey's next action is to unpack the bundled libtermkey.tar.gz and run make install on it. A:l cannot communicate anything it has learned from A:u into this Makefile, because libtermkey's Makefile tries to enquire directly of pkg-config itself. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Aliens depending on Aliens
So, another Alien question. I have two C libraries. One depends on the other. (Actually, it's more of a one-of-many dependencies, but this way it easiest). How is best to arrange for this to happen then? Outside of perl/Alien wrappings, this is a purely manual process. Install first library (as root) so its pkg-config file is created, then the Makefile in the second library finds this, adds cflags/ldflags, all well and good. But Aliens complicate this, because of the requirement that non-root users can install and use them. This requires the first library to get installed somewhere in perl's @INC where the user can write. pkg-config won't automatically look there. This is OK for the Alien layer because the Alien/Foo.pm can know where to find the pkg-config file. But the second C library's Makefile can't. So how is it going to find the first one? I am beginning to think that this requirement that non-root users be able to install C libraries into non-system standard places is getting problematic. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Aliens depending on Aliens
On Mon, 6 Jan 2014 11:12:49 -0800 Ryan Voots simcop2...@simcop2387.info wrote: You can probably have Module::Build and such play with the PKG_CONFIG_PATH env variable to fill out where it should be. Hah, if only it were so simple... The trouble with non-standard install locations is that in general the paths needs to be fixed. Right now I have no better way of doing that than the hideous hack that is: https://metacpan.org/source/PEVANS/Alien-unibilium-0.11/lib/Alien/unibilium.pm#L78 and https://metacpan.org/source/PEVANS/Alien-unibilium-0.11/lib/Alien/unibilium.pm#L92 Without those two things, it won't be sufficient to simply set the PKG_CONFIG_PATH. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Re: Aliens depending on Aliens
On Mon, 6 Jan 2014 16:49:54 -0500 David Mertens dcmertens.p...@gmail.com wrote: Why use pkg_config when you can simply use include_dirs and extra_linker_flags (or their equivalent in EU::MM)? This is how I do things with Alien::TinyCC. See the Synopsishttps://metacpan.org/pod/Alien::TinyCC. Or is this approach insufficient for unibilium? Huh? Two issues: 1) It's possible the lower-level module (unibilium) is already installed, so we should just ask its pkg-config. 2) The higher-level module is also a C library, it's not going to be controlled by M::B's include_dirs/etc... I don't follow how this helps. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Re: Aliens depending on Aliens
On Mon, 6 Jan 2014 17:21:04 -0500 Chris Marshall devel.chm...@gmail.com wrote: Hi Paul- I'm a bit confused by the discussion so far. Alien modules are to provide external dependencies wrapped up for perl modules to use and not, in general, as a way to resolve C library dependencies. Once installed, an Alien module should provide all the information needed to use the library from/with perl without any other tools being involved. The only issue with the non-standard library location is that you need to have the right location for the various compile and link parts of install and execution for the perl module depending on the provided Alien library. In general, different platforms all have different default and not-so-default locations for system package installs. Even in the case of a root user install, the specific paths may need to be adjusted for the given platform type and/or local configuration. Here is a scenario that I think represents the case of interest below and how it might be implemented. I have a perl module MyXS that depends on library A and library B (through the fact that library A uses library B). In that case, the MyXS install would have a dependency on Alien::A, which, when satisfied, allows the MyXS configuration to determine everything about what is needed to use the library A bindings for its work. Since library A depends on library B, it might make sense to have an Alien::B module whose job it is to install/detect library B and to provide the needed information to Alien::A. NOTE: Alien::A will be providing whatever is needed on the library B configuration side to MyXS. This is all determined by what and how the libraries are to be used. It should also be possible to have OtherXS need library B and to have it as a direct dependency in CPAN which would configure or install with the needed information to support perl development or bindings using library B. So, ignore Alien and perl and everything for a moment. uniblium exists. libtermkey depends on unibilium. uses pkg-config to find it. This works fine when root is installing it in a real place. This works fine when non-root is installing it somewhere they made up (e.g. $HOME/lib and $HOME/include), and sets PKG_CONFIG_PATH appropriately. Now consider Alien. Alien::unibilium installs unibilium into the only place it knows how - namely, somewhere in Perl's @INC dir. At this point, how does the C library libtermkey's Makefile, manage to find unibilium, to link against it? The pkg-config that libtermkey's Makefile invokes cannot itself find the unibilium.pc file because it's hidden in Perl's @INC dir. I currently can't see how Alien::libtermkey /can/ provide a totally hassle-free self-contained just do it installation of libtermkey and its own C-level dependencies, because of this fact. This surely limits Alien wrappings to only being useful for C libraries that don't themselves have other C-level dependencies. Unless I have missed something - how does anyone else do this? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Re: Aliens depending on Aliens
On Mon, 6 Jan 2014 17:54:56 -0500
Chris Marshall devel.chm...@gmail.com wrote:
Again, Alien modules are for *perl* to access external dependencies
and not for other external dependencies to access eachother---you've
already given a bunch of examples of the standard pkg-config use
in builds.
But now I don't understand how any e.g. smoketest machine can ever pass
this. How can a smoker install Alien::libtermkey? libtermkey's Makefile
has to know how to find unibilium, and only Alien::unibilium knows
where that is. The C-level agnostic-of-Perl Makefile only asks
pkg-config, and pkg-config has no clue.
The only possible way is if Alien::libtermkey tells it, but there is no
general mechanism for this to work.
...
Perhaps I need to see a concrete real example here.
Right now, libtermkey's Makefile looks like this:
ifeq ($(shell pkg-config --atleast-version=0.1.0 unibilium echo 1),1)
CFLAGS +=$(shell pkg-config --cflags unibilium) -DHAVE_UNIBILIUM
LDFLAGS+=$(shell pkg-config --libs unibilium)
else ...
I cannot see how that can /ever/ find what Alien::unibilium has
installed. At absolute best, PKG_CONFIG_PATH could be set to point at a
directory containing unibilium.pc, but the problem is no such file
exists in a useable form, because one wasn't written. The install
process for unibilium did install /a/ .pc file but that is NOT USEABLE
at present, because it needs altering to make it work for the odd
directory locations that Alien::unibilium was forced to install it
into, as it wasn't root at the time. Namely:
local $ENV{PKG_CONFIG_PATH} = $libdir/pkgconfig/ if $use_bundled;
unshift @args, --define-variable=libdir=$libdir if $use_bundled;
open my $eupc, -|, pkg-config, @args, $module or
die Cannot popen pkg-config - $!;
my $ret = do { local $/; $eupc }; chomp $ret;
close $eupc;
and furthermore
sub libs
{
# Append RPATH so that runtime linking actually works
return _get_pkgconfig( libs = @_ ) .
( $use_bundled ? -Wl,-R$libdir : );
}
Because of this, I cannot see how Alien::libtermkey can /ever/ be
installed automated on a brand-new clean slate machine, without user
intervention specific to these libraries.
You suggest it is possible though, so perhaps you can explain to me
what code I can write in either Alien::unbilium to better export the
information so that libtermkey's Makefile can find it via pkg-config
alone, or else what code I can write in Alien::libtermkey to help drive
the build process to provide the extra information.
The current versions of both modules are visible on CPAN, so you can
refer there...
...
Once again, a summary of the facts:
1) Alien::unibilium has to install the unibilium C library into Perl's
@INC dir, and thus make up path names that /ONLY IT CAN KNOW/ for
where to put the include and .pc files
2) Alien::unibilium has to install unibilium.pc into lib/pkg-config
knowing full well that the contents of the file as supplied by the
unibilium C library /CANNOT BE USED/ as they stand, as certain
options are missing (namely, the true $libdir and the adjustment of
the RPATH linker option).
3) libtermkey, the C library, invokes pkg-config in order to find
unibilium, and does not involve Perl in the process at all.
Right now, about the only idea that I can see is that Alien::unibilium
has to invent a new unibilium.pc file that is useable as it stands, so
it can force the Makefile to find it by only setting PKG_CONFIG_PATH to
include the directory it can be found in. But this then involves an
Alien wrapping writing a new .pc file when it installs, other than the
one the original library actually supplied. That feels wrong to me.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
Re: RFC: Time::mkgmtime
On Thu, Jun 14, 2012 at 02:05:54PM +0100, Paul LeoNerd Evans wrote: I am hesitant to upload this to CPAN, because -srely- something like it already exists. I can't seem to find it though. ... I specifically make note of two facts: 1) This module specifically handles denormalised values like POSIX::mktime does; things like 31st Jan == 1st Feb BY DESIGN. 2) This module uses the system's own datetime functions of mktime(3) and gmtime(3); it does not attempt to reinvent them with possibly incompatible semantics; mkgmtime is always the inverse of gmtime(3). If someone can point me at an existing implementation of this, I'll use that instead of uploading this one. But so far I can't find one, yet it confuses me that such should still not exist yet. So, I still haven't got a satisfactory answer to at least part 1 here. The only thing I can find close to it on CPAN is Time::Local, which specifically says that denormalised values give unspecified behaviour. That will be no good to me. I'm also thinking I should rename the module to Time::timegm, providing a single timegm() function, partly because some OSes (notably GNU libc and BSD) already provide a timegm(3) function, so a later version of this module could just provide XS wrapping of that if required. Any further comment? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: RFC: Time::mkgmtime
On Mon, Jul 09, 2012 at 11:13:13AM -0500, Dave Rolsky wrote: I don't think this is a very good way to do datetime math, which is why the docs discourage it. That said, I'm not sure having yet another module to do essentially the same thing is a great idea. Well, notably this one can just wrap timegm(3) in the common case that it exists. GNU libc, BSD and Windows all provide the functionality, either under this name, or renamed (on Windows it is called _mkgmtime). So in most cases it should just wrap the C function. You can make Time::Local do what you want by calling timegm_nocheck. Yes, I'm aware that currently it appears to work, but the documentation does state it specifically is undefined what happens when you do that. So I don't want to rely on things the documentation says I shouldn't rely on, even if the current implementation makes it OK. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Win32 event loop and threading framework
On Sun, Jun 10, 2012 at 08:14:18PM -0400, bulk 88 wrote: I am planning to release a event loop integration/async I/O/multi OS threading framework module for Perl on Windows. It supports delivering events into a dozen different event loops, around half of which are existing perl modules (GTK, Wx, Perl/TK, Tkx/Tcl, Win32::Gui, Win32::IPC, maybe more). It has nothing to do with ithreads. It gets events from Win32 Thread Sync Objects, async kernel I/O or non-perl multi threaded C libraries/random OS threads. It obviously has to go in Win32::* namespace. Does anyone object to name Win32::Async? Other words that I didn't like or rejected were AsyncToolkit, AsyncTK, AnyEvent, UniIO, Threads, ThreadFusion. I have a weak objection, simply because I tend to stick ::Async as a suffix on module names to indicate IO::Async integration (Term::TermKey::Async, IPC::PerlSSH::Async, Tickit::Async, ...). If you could consider instead Win32::Events perhaps? Failing that I'm sure I can live with it ;) .oO( Though that would then raise the question of what -would- the Win32 + IO::Async module be called. That does sound like a fun and interesting thing to write based on this... ) -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
RFC: Time::mkgmtime
I am hesitant to upload this to CPAN, because -srely- something like it already exists. I can't seem to find it though. - Time::mkgmtime(3) User Contributed Perl DocumentationTime::mkgmtime(3) NAME Time::mkgmtime - a UTC version of mktime() SYNOPSIS use Time::mkgmtime qw( mkgmtime ); my $epoch = mkgmtime 0, 0, 0, 14, 6-1, 2012-1900; print 2012-06-14 00:00:00 UTC happened at , scalar localtime($epoch), localtime\n; DESCRIPTION The POSIX standard provides three functions for converting between integer epoch values and 6-component broken-down time representations. localtime and gmtime convert an epoch into the 6 components of seconds, minutes, hours, day of month, month and year, in either local timezone or UTC. The mktime function converts a local broken-down time into an epoch value. However, POSIX does not provide a UTC version of this. This module provides a function mkgmtime which has this ability. Unlike some other CPAN implementations of this behaviour, this version does not re-implement the time handling logic internally. It reuses the mktime and gmtime functions provided by the system to ensure its results are always consistent with the other functions. FUNCTIONS $epoch = mkgmtime( $sec, $min, $hour, $mday, $mon, $year ) Returns the epoch integer value representing the time given by the 6 broken-down components. As with POSIX::mktime it is not required that these values be within their valid ranges. This function will normalise values out of range. For example, the 25th hour of a day is normalised to the 1st hour of the following day; or the 0th month is normalised to the 12th month of the preceeding year. AUTHOR Paul Evans leon...@leonerd.org.uk perl v5.14.2 2012-06-14 Time::mkgmtime(3) - I specifically make note of two facts: 1) This module specifically handles denormalised values like POSIX::mktime does; things like 31st Jan == 1st Feb BY DESIGN. 2) This module uses the system's own datetime functions of mktime(3) and gmtime(3); it does not attempt to reinvent them with possibly incompatible semantics; mkgmtime is always the inverse of gmtime(3). If someone can point me at an existing implementation of this, I'll use that instead of uploading this one. But so far I can't find one, yet it confuses me that such should still not exist yet. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: RFC: Time::mkgmtime
On Thu, Jun 14, 2012 at 04:21:14PM +0200, Philippe Bruhat (BooK) wrote: On Thu, Jun 14, 2012 at 02:05:54PM +0100, Paul LeoNerd Evans wrote: I am hesitant to upload this to CPAN, because -srely- something like it already exists. I can't seem to find it though. - Time::mkgmtime(3) User Contributed Perl Documentation Time::mkgmtime(3) NAME Time::mkgmtime - a UTC version of mktime() SYNOPSIS use Time::mkgmtime qw( mkgmtime ); my $epoch = mkgmtime 0, 0, 0, 14, 6-1, 2012-1900; print 2012-06-14 00:00:00 UTC happened at , scalar localtime($epoch), localtime\n; Isn't it exactly what Time::Local's timegm and timelocal do? Which is exactly why I further explained the differences. Time::Local complains about out-of-range values. It cannot do 25th hour or -3rd day or whatever. Time::mkgmtime specifically allows these, the same way POSIX::mktime() does. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: RFC: Time::mkgmtime
On Thu, Jun 14, 2012 at 05:13:04PM +0100, Paul LeoNerd Evans wrote:
Time::Local complains about out-of-range values. It cannot do 25th hour
or -3rd day or whatever. Time::mkgmtime specifically allows these, the
same way POSIX::mktime() does.
To wit, the -3rd hour of the 12th June 2012:
$ perl -MTime::mkgmtime=mkgmtime -E 'say scalar gmtime mkgmtime
0,0,-3,12,6-1,2012-1900'
Mon Jun 11 21:00:00 2012
$ perl -MTime::Local=timegm -E 'say scalar gmtime timegm
0,0,-3,12,6-1,2012-1900'
Hour '-3' out of range 0..23 at -e line 1
This behaviour is very much required. It allows one to perform all kinds
of simple date/time arithmetic; e.g:
sub midnight_four_days_ago {
my @t = gmtime;
$t[3] -= 4; $t[0]=$t[1]=$t[2] = 0;
return mkgmtime @t;
}
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: Proposal: IO::Termios
On Mon, May 23, 2011 at 08:05:18PM +0100, Paul LeoNerd Evans wrote: I've been getting annoyed lately at the awkward and insane steps required to go through just to get a serial device On Wed, May 25, 2011 at 11:21:50PM +0200, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote: I've missed something totally nonobvious on CPAN Device::SerialPort? Device::SerialPort is exactly what I was talking about when I mentioned awkward and insane steps :) Contrast IO::Socket; you make a $sock object, then call methods _on the very IO handle_ to configure it (bind, connect, sockopt, etc...). This is the way of using IO::Termios too; that the very IO handle gains new methods that inspect or control its nature as a serial or TTY device. If you know it, then write a piece of contrasting documentation so that a potential user can make an informed decision to employ your module over D::S or vice-versa. If that's too abstract, put yourself in my shoes when writing this program: https://github.com/Metalab/hsc2011/blob/a799dc1ea19261e4d64290222541a5d46de4fb06/software/serial- filter Why would I use one module or the other? To be honest, in your use-case I'd suggest socat, instead of writing some Perl code :) (Also not wanting to be too much a code review critic, but your code has a serious bug in that it is using some select-alike polling mechanism on STDIN, but then using STDIN to read a line. I suggsest not doing that ;) ) -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Proposal: IO::Termios
On Tue, May 24, 2011 at 12:57:20PM -0700, Austin Schutz wrote: IO::Tty. IO::Stty. IO::Tty is useful and contains constants and so on, but it isn't an IO::Handle subclass. Can be quite cute. IO::Stty is also not an IO::Handle subclass, and has a somewhat odd interface. I don't see what this really adds above and beyond the core POSIX module and those two, but if you really like your combined syntax I guess that's something. It's a small subclass around IO::Handle, that adds useful methods to handle objects themselves. It's similar to what IO::Socket and friends adds to IO::Handle from Socket. I'm doing the same for TTYs... use IO::Termios -upgrade; STDIN-setflag_echo( 0 ); my $password = STDIN; STDIN-setflag_echo( 1 ); Such as this. Sure you -can- do that with the other modules, but this makes it much more convenient. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Proposal: IO::Termios
I've been getting annoyed lately at the awkward and insane steps
required to go through just to get a serial device, or hack around at
the termios flags of STDIN/etc... To this end, I've written the
following module, called IO::Termios.
Some future plans involve:
* Adding more getflag_*/setflag_* convenience wrappers
* Automatically upgrading STDIN/STDOUT/STDERR if appropriate, given a
flag. Would allow such convenience as:
use IO::Termios -upgrade;
STDOUT-autoflush( 1 );
print Password: ;
STDIN-setflag_echo( 0 );
my $password = STDIN;
STDIN-setflag_echo( 1 );
* Some sort of combined baud/csize/parity/stop getting/setting method
$term-setline( 38400,8,n,1 );
I'd appreciate comments on the general approach; if anyone thinks it
might be useful, or if I've missed something totally nonobvious on
CPAN/etc... before I upload it.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
--
IO::Termios(3pm) User Contributed Perl Documentation IO::Termios(3pm)
NAME
IO::Termios - supply termios(3) methods to IO::Handle objects
SYNOPSIS
use IO::Termios;
my $term = IO::Termios-open( /dev/ttyS0 )
or die Cannot open ttyS0 - $!;
$term-setbaud( 9600 );
$term-setcsize( 8 );
$term-setparity( 'n' );
$term-setstop( 1 );
$term-print( Hello world\n ); # Still an IO::Handle
while( $term ) {
print A line from ttyS0: $_;
}
DESCRIPTION
This class extends the generic IO::Handle object class by providing
methods which access the system's terminal control termios(3)
operations.
CONSTRUCTOR
$term = IO::Termios-new()
Construct a new IO::Termios object around the terminal for the
program. This is found by checking if any of STDIN, STDOUT or
STDERR are a terminal. The first one that's found is used. An error
occurs if no terminal can be found by this method.
$term = IO::Termios-new( $handle )
Construct a new IO::Termios object around the given filehandle.
$term = IO::Termios-open( $path )
Open the given path, and return a new IO::Termios object around the
filehandle. If the open call fails, undef is returned.
METHODS
$attrs = $term-getattr
Makes a tcgetattr() call on the underlying filehandle, and returns a
IO::Termios::Attrs object.
If the tcgetattr() call fails, undef is returned.
$term-setattr( $attrs )
Makes a tcsetattr() call on the underlying file handle, setting
attributes from the given IO::Termios::Attrs object.
If the tcsetattr() call fails, undef is returned. Otherwise, a true
value is returned.
FLAG-ACCESSOR METHODS
Theses methods are implemented in terms of the lower level methods, but
provide an interface which is more abstract, and easier to re-implement
on other non-POSIX systems. These should be used in preference to the
lower ones.
For efficiency, when getting or setting a large number of flags, it may
be more efficient to call getattr, then operate on the returned
object, before possibly passing it to setattr. The returned
IO::Termios::Attrs object supports the same methods as documented
here.
The following two sections of code are therefore equivalent, though the
latter is more efficient as it only calls setattr once.
$term-setbaud( 38400 );
$term-setcsize( 8 );
$term-setparity( 'n' );
$term-setstop( 1 );
my $attrs = $term-getattr;
$attrs-setbaud( 38400 );
$attrs-setcsize( 8 );
$attrs-setparity( 'n' );
$attrs-setstop( 1 );
$term-setattr( $attrs );
$baud = $term-getibaud
$baud = $term-getobaud
$term-setibaud( $baud )
$term-setobaud( $baud )
$term-setbaud( $baud )
Convenience accessors for the ispeed and ospeed. $baud is an
integer directly giving the line rate, instead of one of the Bddd
constants.
$bits = $term-getcsize
$term-setcsize( $bits )
Convenience accessor for the CSIZE bits of c_cflag. $bits is an
integer 5 to 8.
$parity = $term-getparity
$term-setparity( $parity )
Convenience accessor for the PARENB and PARODD bits of c_cflag.
$parity is n, o or e.
$stop = $term-getstop
$term-setstop( $stop )
Convenience accessor for the CSTOPB bit of c_cflag. $stop is 1 or
2.
$mode = $term-getflag_icanon
$term-setflag_icanon( $mode )
Accessor for the ICANON bit of c_lflag. This is called canonical
mode and controls whether the terminal's line-editing feature will be
used to return a whole line (if false), or if individual bytes from
keystrokes will be returned as they are available (if true).
$mode = $term-getflag_echo
$term-setflag_echo( $mode
Module Naming Suggestion - Carp from somewhere else
(To copypaste
http://leonerds-code.blogspot.com/2011/03/carp-from-somewhere-else.html ):
Carp provides two main functions, carp and croak, as replacements for
core Perl's warn and die. The functions from Carp report the file and
line number slightly differently from core Perl; walking up the
callstack looking for a different package name. The idea being these are
used to report errors in values passed in to the function, typically bad
arguments from the caller.
These functions use the dynamic callstack (as provided by caller()) at
the time the message is warned (or thrown) to create their context. One
scenario where this does not lead to sensible results is when the called
function is internally implemented using a closure via some other
package again.
Having thought about this one a bit, it seems what's required is to
split collecting the callstack information, from creating the message.
Collect the information in one function call, and pass it into the
other.
This would be useful in CPS for example. Because the closures used in
CPS::kseq or kpar aren't necessarily invoked during the dynamic scope of
the function that lexically contains the code, a call to croak may not
be able to infer the calling context. Even if they are, the presence of
stack frames in the CPS package would confuse croak's scanning of the
callstack. Instead, it would be better to capture the calling context
using whence, and pass it into whoops if required for generating a
message.
For example, this from IO::Async::Connector:
sub connect
{
my ( %params ) = @_;
...
my $where = whence;
kpar(
sub {
my ( $k ) = @_;
if( exists $params{host} and exists $params{service} ) {
my $on_resolve_error = $params{on_resolve_error} or whoops $where,
Expected 'on_resolve_error' callback;
...
}
These functions would be a fairly simple replacement of carp and croak;
capture the callsite information at entry to a function, and pass it to
the message warning function.
It does occur to me though, the code will be small and self-contained,
and not specific to CPS. I think it ought to live in its own module
somewhere - any ideas on a name?
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: What hurts you the most in Perl?
On Thu, Dec 02, 2010 at 08:19:32AM +0100, Matija Grabnar wrote:
Right now? I need support for IPv6, actually support for dual-stack
in standard library
calls and in the major CPAN modules. Preferably transparent one, not
one involving loading
a special library, and patching third party modules to call Socket6
instead of Socket, or whatever.
Does
IO::Socket::IP
look like it'll help you?
I am at this very moment working on getting proper IPv6 handling into
core perl - bleadperl's Socket.xs already has
{pack,unpack}_sockaddr_in6, and I am working on getaddrinfo /
getnameinfo now. I hope to be able to have IO::Socket::IP in core by
5.14.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: Discussion question: what is the best syntax for documenting a coderef parameter?
On Thu, Dec 09, 2010 at 06:16:45AM -0600, David Nicol wrote: On Wed, Dec 8, 2010 at 7:59 PM, Eric Wilhelm enoba...@gmail.com wrote: If you can, avoid the need to document I will pass a callback to your callback. --Eric Continuation-style programming requires that all the time. Which is why CPS.pm documents them thus: =head2 kforeach( \...@items, \body, $k ) CPS version of perl's foreach loop. Calls the body code once for each element in @items, until either the items are exhausted or the body invokes its $klast continuation, then invoke $k. $body-( $item, $knext, $klast ) $knext-() $klast-() $k-() =cut (see http://search.cpan.org/~pevans/CPS-0.10/lib/CPS.pm#kforeach(_...@items,_\body,_$k_) -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: What hurts you the most in Perl?
On Wed, Nov 24, 2010 at 04:54:31PM +0100, Sébastien Aperghis-Tramoni wrote: In terms of Perl itself, apart from the reference syntax, the thing that really annoyed me recently was the lack of advanced debug tools, for example to find memory leaks. None of the tools I found or was pointed to worked in my case. Have you tried either Test::Refcount Test::MemoryGrowth ? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Which Build Module?
On Tue, Jul 13, 2010 at 09:25:26AM -0700, Eric Wilhelm wrote: Agreed. In research I did on CPAN modules that contain XS, ExtUtils::MakeMaker was still used 10 times as often as Module::Build. It seems like authors lean toward EU::MM for XS because they've got so many examples like that. Also, M::B's documentation about xs_files handling was not always clear (and keeping them in lib/ must somehow seem non-obvious since that difference has caught a lot of people.) Speaking of XS-based modules and Module::Build, it should perhaps be observed that my ExtUtils::CChecker (a sortof ./configure-alike helper for build time) natively supports Module::Build, but so far no real thoughts on EU::MM or M::I. http://search.cpan.org/perldoc?ExtUtils::CChecker Suggestions/improvements/patches welcome. ;) -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: 2 Qs about Module::Build
On Sun, 7 Feb 2010 23:25:56 -0800
cr...@animalhead.com wrote:
Q2: What's the easiest way to communicate something from
the Build.PL code to test code?
I'm not sure about test, but I have an ExtUtils:: module that needs to
invoke the C compiler again. If Module::Build is in effect, I use its.
The first step here is to obtain the existing M::B configuration:
if( my $mb = eval { require Module::Build and Module::Build-current } ) {
... use $mb here...
}
The principle would be the same for test code, but I'd be given to wonder
in your case what you're doing with it...
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: avoid running CPAN as root
On Tue, 12 Jan 2010 17:14:03 + Andy Armstrong a...@hexten.net wrote: On 12 Jan 2010, at 16:59, dhu...@hudes.org wrote: While the idea of using sudo only at install time is nice, there are two problems: 1. Some modules require extra privileges at test time Do they? I've got 1213 distributions installed on this laptop. All using cpan and none of them required elevated privileges during testing. Which modules do this? I have two module tests that might require root; knowing that 99% of test cases won't have it, I skip them: http://cpansearch.perl.org/src/PEVANS/IO-Async-0.27/t/35loop-child-root.t http://cpansearch.perl.org/src/PEVANS/Socket-Packet-0.03/t/20io-socket-packet.t -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Module naming suggestions : Test::DNS
Usually the Test:: heirarchy is for unit test modules; mostly things built on Test::Builder, et.al. Such a module would be used to assert on the behaviour of code under test. I would expect, given the name, that Test::DNS would check the behaviour of some module, perhaps by asserting it performs DNS queries, or mocking the results of such. Your module doesn't seem to be doing this - perhaps something like Check::DNS may be a more suitable name for yours? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
ExtUtils::H2PM - generate pure-perl system extension modules
I've spent some time lately writing modules that just present a perl
level mapping into some kernel-level concept. Initially I wrote
http://search.cpan.org/~pevans/Socket-Packet-0.03/lib/Socket/Packet.pm
This really just contains exports of a bunch of constants, and some
pack/unpack functions for structure types. It's somewhat tedious to have
to go to all the effort of writing an XS module just for that.
So I've come up with a new approach, a way to generate a pureperl module
from pureperl source, without the module developer having to go anywhere
near C.
A little example rewriting most of the Socket::Packet module using this:
-
$ cat Packet_const.pm.PL
#!/usr/bin/perl
use strict;
use warnings;
use ExtUtils::H2PM;
module Socket::Packet;
include sys/socket.h;
include netpacket/packet.h;
include net/ethernet.h;
constant PF_PACKET;
constant AF_PACKET;
constant PACKET_$_ for qw( HOST BROADCAST MULTICAST OTHERHOST OUTGOING );
constant ETH_P_ALL;
constant SIOCGSTAMP;
constant SIOCGSTAMPNS;
structure struct timeval,
members = [
tv_sec = numeric,
tv_usec = numeric,
];
structure struct timespec,
members = [
tv_sec = numeric,
tv_nsec = numeric,
];
$ perl Packet_const.pm.PL
package Socket::Packet;
# This module was generated automatically by ExtUtils::H2PM from
Packet_const.pm.PL
push @EXPORT_OK, 'PF_PACKET', 'AF_PACKET', 'PACKET_HOST', 'PACKET_BROADCAST',
'PACKET_MULTICAST', 'PACKET_OTHERHOST', 'PACKET_OUTGOING', 'ETH_P_ALL',
'SIOCGSTAMP', 'SIOCGSTAMPNS', 'pack_timeval', 'unpack_timeval',
'pack_timespec', 'unpack_timespec';
use constant PF_PACKET = 17;
use constant AF_PACKET = 17;
use constant PACKET_HOST = 0;
use constant PACKET_BROADCAST = 1;
use constant PACKET_MULTICAST = 2;
use constant PACKET_OTHERHOST = 3;
use constant PACKET_OUTGOING = 4;
use constant ETH_P_ALL = 3;
use constant SIOCGSTAMP = 35078;
use constant SIOCGSTAMPNS = 35079;
use Carp;
sub pack_timeval
{
@_ == 2 or croak usage: pack_struct timeval(tv_sec, tv_usec);
pack l l , @_;
}
sub unpack_timeval
{
length $_[0] == 8 or croak unpack_struct timeval: expected 8 bytes;
unpack l l , $_[0];
}
sub pack_timespec
{
@_ == 2 or croak usage: pack_struct timespec(tv_sec, tv_nsec);
pack l l , @_;
}
sub unpack_timespec
{
length $_[0] == 8 or croak unpack_struct timespec: expected 8 bytes;
unpack l l , $_[0];
}
1;
-
This has now generated me a platform-specific Packet_const.pm which I
can use Socket::Packet_const; in my actual code.
It is platform-specific, but it was created at the time I installed the
module. It's no less portable than the compiled Packet.so which would
have been created by going the traditional XS route.
Finally, find attached the full text of the module's documentation.
I'd be interested to hear any thoughts, etc...
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
NAME
ExtUtils::H2PM - automatically generate perl modules to wrap C header
files
DESCRIPTION
This module assists in generating wrappers around system functionallity,
such as socket() types or ioctl() calls, where the only interesting
features required are the values of some constants or layouts of
structures normally only known to the C header files. Rather than
writing an entire XS module just to contain some constants and
pack/unpack functions, this module allows the author to generate, at
module build time, a pure perl module containing constant declarations
and structure utility functions. The module then requires no XS module
to be loaded at run time.
In comparison to h2ph, C::Scan::Constants, and so on, this module
works by generating a small C program containing printf() lines to
output the values of the constants, compiling it, and running it. This
allows it to operate without needing tricky syntax parsing or guessing
of the contents of C header files.
It can also automatically build pack/unpack functions for simple
structure layouts, whose members are all simple integer fields. It is
not intended as a full replacement of arbitrary code written in XS
modules. If structures should contain pointers, or require special
custom handling, then likely an XS module will need to be written.
FUNCTIONS
module $name
Sets the name of the perl module to generate. This will apply a
package header.
include $file
Adds a file to the list of headers which will be included by the C
program, to obtain the constants or structures from
constant $name
Adds a numerical constant.
structure $name, %args
Adds a structure definition. This requires a named argument, members.
This should be an ARRAY ref containing an even number of name-definition
pairs. The first of each pair should be a member name. The second should
be one of the following structure member definitions
Re: Test-only code
On Tue, 22 Dec 2009 22:05:40 + Ben Morrow b...@morrow.me.uk wrote: Personally I like to put such modules in the t:: namespace, since tests are always run from the module build directory, so I might call it t::Hooks or some such. +1 I often do similar; usually I'll have a t::TestFoo or t::MockBar in there. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: MANIFEST (Makefile.pl) ignore Mercurial files
On Thu, 17 Dec 2009 11:03:41 +0100 Rene Schickbauer rene.schickba...@gmail.com wrote: Hi! What is the standard way of ignoring files or sub-directories in the module build directory. I just switched to mercurial, which uses a .hg directory for its Metafiles. I have a standard MANIFEST.SKIP which contains: .*\.~\d~ .*\.bak .*\.swp .*\.tar(\.gz)? \.bzr \.bzrignore blib .*\.deb Makefile$ Makefile\.old MANIFEST\.SKIP Build$ _build .*\.c .*\.o It should be quite easy to extend this with \.(?:svn|bzr|hg|git|arch) or something... -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: MANIFEST (Makefile.pl) ignore Mercurial files
On Thu, Dec 17, 2009 at 01:42:24PM +0200, Burak Gürsoy wrote: I have a standard MANIFEST.SKIP which contains: Another choice could be to not auto-generate MANIFEST. Anything not in MANIFEST will not enter into the distro unless you're building it in an esoteric way :) That's another choice, but I find too easily I'll forget to add something to the list, such as a new test script. Whereas, it's usually easier to spot things in the MANIFEST that ought not be there, and remove them. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: bug in Net::Cmd/how to do pop3s for gmail
On Mon, 30 Nov 2009 04:06:36 +0100
Aristotle Pagaltzis pagalt...@gmx.de wrote:
Seems to me that it is the job of IO::Foo classes to respond to
a `select` as being ready to read from, if they have buffered
data, even if the underlying handle is not.
I don’t know if that response is overridable in Perl classes.
Even if IO::Select might be overrideable, I'd doubt that select() is, or
poll(), or ppoll(), or epoll_pwait(), or... any of the other O(1)
OS-specific blocking prims.
Instead I suggest some sort of pure-perl toplevel method.
The way I usually write easy sync-or-async IO classes is to give the
filehandle-like object its own internal buffer, and have two APIs into it:
get_foo - just read buffer or return undef
wait_foo - try to read buffer, or synchronously block on IO
A supplimentary method, advise_readable, informs the object that a
sysread() operation may be performed; when called it does a sysread()
into its own internal buffer.
Then the get_foo can be written simply as
sub wait_foo
{
my $self = shift;
while(1) {
my $foo = $self-get_foo;
return $foo if defined $foo;
$self-advise_readable; # will block on blocking sockets
}
}
Synchronous programs can just call the wait_foo method to block and get
new foos; asynchronous programs can call advise_readable every time the
underlying blocking prim says it's a good idea, then repeatedly call
get_foo to drain the buffer.
For example, see the split APIs provided by
http://search.cpan.org/~pevans/Term-TermKey-0.04/ (at the perl level)
http://home.leonerd.org.uk/code/libtermkey/(at the C level)
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: Quick style question
On Thu, 19 Nov 2009 02:16:37 -0700 Philip Prindeville phil...@redfish-solutions.com wrote: Hi. I'm working on releasing an update to Net-Patricia, and I needed to make AF_INET6 from the Socket6 space appear as an exported symbol when Net::Patricia loads. I currently do this as: I could be given to wondering why you need to manually import AF_INET6 or know anything about INET6 in the first place... What is it you're doing that can't be done with the normal getaddrinfo() / getnameinfo() sequences? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Repository links in META/Pod should be http://
On Sat, 31 Oct 2009 18:38:32 -0400 Ricardo Signes perl.moda...@rjbs.manxome.org wrote: I'm strongly opposed. There might not be any HTTP URL to my repositor, even though a CVS or Git URL may exist. +1 -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Reliability of timing in smoke tests
On Mon, 19 Oct 2009 14:16:18 +0200 sawyer x xsawy...@gmail.com wrote: On Mon, Oct 19, 2009 at 11:45 AM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: Before I think about this though; does anyone have any better suggestions? Are there other modules around with timing-sensitive tests? How do they cope with variable load on the test boxes? I like Test::Timer. Is that the kind of thing you're looking for? Sortof, but not exactly. Test::Timer has exact inequallity comparisons. I'd like more of a: It's going to take about this long, but I can't be exact because of CPU load. Give it some (perhaps dynamically discovered) range _around_ this time. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Reliability of timing in smoke tests
On Mon, 19 Oct 2009 12:05:33 -0700 Eric Wilhelm enoba...@gmail.com wrote: # from Paul LeoNerd Evans # on Monday 19 October 2009 02:45: Before I think about this though; does anyone have any better suggestions? Are there other modules around with timing-sensitive tests? How do they cope with variable load on the test boxes? You might be able to do something with Time::Mock. E.g. slow down the clock or adjust it at critical points. If your timings are related to sleep(), alarm(), or such that might work. Ah; I'm afraid not. In the distribution itself it'll be the timeouts given to select() or poll(). The tests are also part of a shipped module, IO::Async::LoopTests, that are applied to externally-written modules; such as might use epoll_pwait(), ppoll(), or GLib's GMainLoop. These would be quite beyond Perl's control... -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Reliability of timing in smoke tests
I'm having a few test FAILs lately on IO::Async, all due to boundary
cases of timing, for example
http://www.nntp.perl.org/group/perl.cpan.testers/2009/10/msg5585418.html
I suspect this is simply due to heavier-than-normal machine load on the
testing box, causing the program to be somewhat delayed in its
normally-precise timing.
I'm planning just to add an testing primitive to the internal testing
library, something like
test_time_about sub { ... }, 2.5;
to check that the code takes about 2.5 seconds. This would probably
assert it's at least half that, no more than double + 1 second, or
something of that nature.
Before I think about this though; does anyone have any better
suggestions? Are there other modules around with timing-sensitive tests?
How do they cope with variable load on the test boxes?
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: module name for test data?
On Mon, Sep 28, 2009 at 05:37:17PM +0100, Smylers wrote: Jerome Quelin writes: - audio::mpd::common? (even if i don't think that's the best) - audio::mpd::test? this one is already used by a module in audio::mpd, but that's not a problem (i plan to move audio::mpd::test somewhere in t/lib/, so namespace would be free) - audio::mpd::testdata? - audio::mpd::common::test? - data::audio::mpd? - data::audio::mpd::test? - test::audio::mpd? I'd go for the latter (well, with some capital letters!) cos people are used to the idea that Test:: modules are used for testing rather than being part of the 'main function' of your program. But none of those names sound bad -- they're all pretty self- explanatory, so any of them would do. If the module is for use purely during testing, and serves no other useful purpose, I'd make sure to include the word Test (capitalised) somewhere in its distribution name. The variations on common without test would imply it's some sort of shared useful code to use in production use. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Term::Info - takeover
I notice that Term::Info was released in 1999, has no documentation, no testing, only wraps Tput, and is generally not all that useful. I'm planning to write a proper terminfo wrapping module anyway, and this seems an ideal name to give it. CPANTS claims nothing is using it: http://cpants.perl.org/dist/used_by/Term-Info If I were to create another one which is more useful, providing more access to terminfo information, how might I go about creating a release of it? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
API design musings - CPS + IO::Async (or others)
Hi all,
I'm more-or-less thinking out loud for a bit here. I'd appreciate any
thoughts or comments people might want to make.
So, I have the CPS module:
http://search.cpan.org/~pevans/CPS-0.04/lib/CPS.pm
On its own it doesn't create an awful lot of real interest yet; nothing
much that can't easily be done with normal perl. But this wasn't yet
the point.
I'm thinking of ways to combine it nicely with IO::Async (or other event
frameworks, but I'll take this as a useful example).
My primary thought is how to combine things like kwhile() with other
events; ideally it'd be nice to interleave kwhile() loops with other
event processing. ((I pick on kwhile here specifically, because all the
other k*() control-flow structures are built on kwhile(), so getting that
right gives the others for free)).
Imagine the normal while loop with some event handling:
while( cond ) {
do_something();
process_pending_events();
}
What if instead we had an IO::Async-aware version of CPS. Lets say, for
the sake of argument, we had some sort of object, which knows of the
IO::Async loop.. lets call it, for reasons that'll become clear soon, a
Governor:
my $governor = CPS::Governor::IOAsync-new( $loop );
$governor-kwhile( sub {
my ( $knext, $kdone ) = @_;
return $kdone-() if !cond;
do_something( on_done = $knext );
}, sub { say Finished } );
Aside from the slightly messy syntax, this is a fairly short and
convenient way to mix CPS with IO::Async. The Governor object can mix
iterations of the while loop with other event processing in a neat simple
way.
In fact, given as it can store state, we can configure it more powerfully
than just this. Suppose we're processing a big list of, maybe, hundreds
of thousands of little items. Each item is tiny, but processing the whole
list is going to take several seconds of CPU time, during which it would
be polite if we handled IO events (such as GUI interactions). No problem..
my @items = (foo) x 1_000_000;
my $governor = CPS::Governor::IOAsync-new( $loop, iterations = 100 );
$governor-kforeach( \...@items, sub {
my ( $item, $knext ) = @_;
process( $item );
goto $knext;
}, sub { say Finished } );
The Governor object here takes care of the iteration counting. Every 100
iterations it'll pause a moment and check IO::Async pending events.
The way this would be implemented would be that the Governor's kwhile()
method would use the $loop's idle event handling to call the next
iteration, rather than invoke it immediately. This also lets us do such
interesting things as:
my @numbers = ( 1 .. 10 );
my $governor = CPS::Governor::IOAsync-new( $loop, iterations = 2 );
$governor-kforeach( \...@numbers, sub {
print A$_[0] ; goto $_[1]
}, sub {} );
$governor-kforeach( \...@numbers, sub {
print B$_[0] ; goto $_[1]
}, sub {} );
This would print
A1 A2 B1 B2 A3 A4 B3 B4 A5 A6 B5 B6 A7 A8 B7 B8 A9 A10 B9 B10
The only real point of hesitation in my mind, though, is that of
implementing control flow structures as methods on an object. This feels
somehow unclean.
Perhaps instead they can use the new lexical pragmas in 5.10; allowing a
somewhat cleaner style of:
use CPS qw( kforeach );
# kforeach here would use the default flat Governor
{
use CPS::Governor::IOAsync $loop, iterations = 10;
kforeach( [ 1 .. 100 ], sub {
my ( $item, $knext ) = @_;
do_item( $item, on_done = $knext );
}, sub { say Finished } );
}
Or perhaps being a pragma it ought to be all lowercase? What are the
rules here?
And finally there's nothing IO::Async'y about the whole thing. Simply
implementing another kwhile() method would allow Governors such as
use CPS::Governor::POE $kernel;
use CPS::Governor::AnyEvent $loop;
use CPS::Governor::GLib $maincontext;
...
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: What Would you like to see in a CPAN Distro Manager?
On Fri, 4 Sep 2009 15:15:32 -0400 Jonathan Yu jonathan.i...@gmail.com wrote: I think the problem with doing that, for me, is that I'd forget to update stuff and then my docs would become even more out of sync with my code, which is a pretty bad thing. It's bad enough people don't update comments that are right next to the code in question; when it comes to docs... I imagine it'd get even worse. Redoing stuff for the purposes of making things easier for a computer seems backwards to me. After all, computers are supposed to do work for /us/ -- they're faster, more consistent, etc. So leave programmers to do what programmers do, and let the computers worry about extracting inline POD. :-) +1 -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Renaming a perl module/dist
I have a one-module dist that I'd like to rename. How problematic will this be? I know I could just upload new dist with new module, and get things to use that instead, and just abandon the old one. Seems a bit harsh. I could upload one last copy of the old module (which, being an object class) can simply use base the new name. Should these go in their own dists, or would it be OK both in just the new one? And what for deleting the old name? And finally, is it all worth it, just for the neatness of a name? Or should I just live with it? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Renaming a perl module/dist
On Tue, Aug 11, 2009 at 07:09:04AM -0400, Shawn H. Corey wrote: How many people are using it? Would they be upset if you changed the name? Don't forget, when you place a module in CPAN, it is no longer entirely yours. People have invested time to use your module and consider it as much theirs as yours. Well, the module in question is http://search.cpan.org/dist/IO-Async-Loop-IO_Ppoll/ I dislike the IO_ part of the prefix; when I did the Epoll one based on IO::Epoll, I finally decided to remove the IO_ part. I'd like to rename this and some others to match. The thing about it, is that most people shouldn't be using it directly. There's a magic constructor on IO::Async::Loop itself, which selects a good (concrete) subclass from those installed. Also there's http://search.cpan.org/perldoc?IO::Async::Loop::linux which knows of it, to automatically select it. This can easily be changed and updated. Given these, I suspect there'll be little impact because most people won't be using the name directly; it will come indirectly via one of these routes. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Module::Build + automatic README / LICENSE
On Wed, 10 Jun 2009 22:04:55 -0500 Ken Williams kena...@gmail.com wrote: On Tue, May 12, 2009 at 9:06 AM, Eric Wilhelmenoba...@gmail.com wrote: Isn't that what Ken did some time ago? Ah... 0.31 added the create_license = 1 option, but I guess it didn't get documented. Oopsie. Yeah. create_license = 1, create_readme = 1, and Bob's your uncle. Lovely. I've now got that set on my latest two module uploads, and it's doing just the right thing. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Module::Build + automatic README / LICENSE
On Mon, 11 May 2009 15:11:13 -0400 Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: * Take the module given by module_name (or some other named one), run it through pod2txt README You forgot to specify create_readme = 1. Ah yes; I see that works fine. Somehow I must have missed that in the docs... * Look up the named license from a standard set of default ones and print it to LICENSE use Software::License. Hmm.. I don't see how this interacts with Module::Build. Do you suggest I'd just have it as a separate part of the build process? I was hoping for some integration with Module::Build to do it automatically from the data it already has to hand (i.e. the licence name itself) -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Module::Build + automatic README / LICENSE
I was recently pointed in the direction of my kwalitee tests:
http://cpants.perl.org/author/PEVANS
They all fail for not having a README file or a LICENSE.
I was wondering, since I have e.g. the following Build.PL:
my $build = Module::Build-new
(
module_name = 'IO::Async',
...
license = 'perl',
);
surely Module::Build ought to be able to automatically satisfy both
these conditions?
* Take the module given by module_name (or some other named one), run it
through pod2txt README
* Look up the named license from a standard set of default ones and
print it to LICENSE
Are either of those doable automatically?
--
Paul LeoNerd Evans
leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)
signature.asc
Description: Digital signature
Re: Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
On Tue, 5 May 2009 19:09:30 -0700 Bill Ward b...@wards.net wrote: The way I've interpreted that in my own auto-build scripting is that if Build.PL exists, the module author is probably a Module::Build user who is only providing a Makefile.PL grudgingly for the sake of those who haven't installed Module::Build, and thus I figure that if there's any difference between the two .PL files, probably Build.PL is the one the author is more invested in. That's the logic I work to, yes. All my Makefile.PLs are built from the original Build.PLs. On Tue, May 5, 2009 at 7:06 PM, Jonathan Yu jonathan.i...@gmail.com wrote: The real question at hand here is: for modules that provide both a Makefile.PL and Build.PL, which should be preferred? More than that, from the perspective of CPAN authors, is it even useful to provide both? Now that Module::Build is a core module, maybe only a Build.PL should be included. But only core in 5.10. I've decided semi-officially that I don't care about 5.6 any more, in that I'll happily use Scalar::Util::weaken(), or other 5.8-and-above things, unless someone can demonstrate me a simple workaround for them that would work on 5.6. I don't yet apply the same for 5.10, as 5.8 is still the default in lots of places. Perhaps in a year or two I might rethink that, but for now I have to keep 5.8 in mind. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: On 'unpack()' - How much did I eat?
On Wed, Apr 22, 2009 at 02:10:03AM +0100, Ben Morrow wrote:
What am I missing here? It appears to me unpacking . gives the current
byte position in the string, which is what is needed.
~% perl -E'my $bin = pack NN, 10, 12; say for unpack .N.N., $bin'
0
10
4
12
8
Ah, youknow, that is exactly what I wanted :)
I had in fact looked up and down the docs for a format which would do
something like that, and didn't find it. Is that documented anywhere?
I've just sat and reread perldoc -f pack and perldoc -f unpack _again_
and still haven't spotted it.
So it would appear no changes to perl code are needed, though perhaps
the docs could be improved somewhat to draw more attention to this, as
relatively few people are aware of it. Certainly nobody in Freenode's
#perl was when I asked...
--
Paul LeoNerd Evans
leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)
signature.asc
Description: Digital signature
Re: On 'unpack()' - How much did I eat?
On Tue, Apr 21, 2009 at 10:24:10AM +0100, Paul LeoNerd Evans wrote:
sub pull_int
{
my $self = shift;
my $i = unpack( N, $self-{buffer} );
substr( $i, 0, 4 ) = ;
return $i;
}
Uh.. obviously, that's meant to be
substr( $self-{buffer}, 0, 4 ) = ;
/me unpacks more coffee into self...
--
Paul LeoNerd Evans
leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)
signature.asc
Description: Digital signature
On 'unpack()' - How much did I eat?
I find lately I've been doing a lot of binary protocol work, taking
messages that live in TCP streams or files or similar, and doing lots of
pack()/unpack() on them.
I find what works best is to wrap up a message into an object, so I can
do things like:
my $field = $message-pull_int();
where
sub pull_int
{
my $self = shift;
my $i = unpack( N, $self-{buffer} );
substr( $i, 0, 4 ) = ;
return $i;
}
this strikes me as more than a little inelegant. That 4 floating about
there is a magic constant. Things like this get worse
sub pull_strz
{
my $self = shift;
my $s = unpack( Z*, $self-{buffer} );
substr( $i, 0, len($s) + 1 ) = ;
return $s;
}
Is there some neater way to do this? Can I either:
a: Get unpack() to consume bytes from the LVALUE
b: Ask unpack() how much it ate in a generic fashion?
One suggestion I've seen would be to
sub unpack_and_eat
{
my ( $format, $str ) = @_;
my @values = unpack( $format . A*, $str );
$_[1] = pop @values;
return @values;
}
but that seems a bit messy, all that O(n^2) copying about the place if
we're going to, say, pull lots of small ints out of a really big buffer.
There surely has to be a better way...
--
Paul LeoNerd Evans
leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)
signature.asc
Description: Digital signature
Re: a lot of silliness about Module::Build
On Thu, 9 Apr 2009 04:47:59 -0700 (PDT) Ovid publiustemp-moduleautho...@yahoo.com wrote: Me? I use M::B for most of my modules. Generally don't need to, but I provide a Makefile.PL for those who don't like MB. However, if I have complicated build needs, EU::MM is very, very hard to work with. I find this too. Of all my modules, any of them that don't have XS code in them simply provide a dual Build.PL / Makefile.PL as written by M::B's create_makefile_pl = 'traditional' setting. It only becomes even vaguely complicated on a few of my XS ones, where M::B expects to find lib/Foo/Bar.xs whereas EU::MM wants only Bar.xs This random inconsistency annoys me - IMHO M::B's behaviour here is much more preferable, for reasons of being able to find the code, of making the file unique in case I want more than one,... Furthermore I just find M::B to be nicer from an ideological perspective. EU::MM writes a Makefile, so we can use GNU make or BSD make or MSVC make or... why, exactly? M::B is written in perl. It works in perl. I -generally- dislike build tools to rely on other languages, but when it's a build system _for perl_, I suspect one could make a reasonable case for it :) -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Module name suggestions? - automatic per-OS subclass
On Wed, Mar 25, 2009 at 04:09:12PM +, David Cantrell wrote:
On Wed, Mar 25, 2009 at 11:25:15AM -0400, Jonathan Yu wrote:
So, I guess this is just my long-winded way of saying that you should
include a method of mapping operating systems to class names, but in a
portable manner
Devel::CheckOS is your friend. It knows that, for example, Solaris,
Irix and AIX are all Unix.
Having looked at it, it's not sufficient. When run on, say, Solaris, I
want to try in order:
Foo::Bar::Solaris
Foo::Bar::Unix
Foo::Bar
Devel::CheckOS can't apply this ordering. I could get a list of all
possible supported names, then filter that by what this machine is.
I'm sure I recall in some code somewhere, the use of a list of possible
OS family names, from most to least specific, keyed by $^O. I'm thinking
something more like that would be best.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)
signature.asc
Description: Digital signature
Re: RFC: Yet Another Excel Writer..
On Mon, 30 Mar 2009 16:21:10 -0500
Brad Lhotsky b...@divisionbyzero.net wrote:
# Add a new format
$report-addFormat('credit', { color='green', bold = 1 } );
# Use that:
$report-custom_row( 'credit', 1, '2009-04-01', 2000.00, 0, 'Bank Error');
A small note on API - you seem inconsistent here between camelCase and
under_scores. Pick one. I suggest the latter - it seems more the way perl
is done by convention.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: Module name suggestions? - automatic per-OS subclass
On Wed, Mar 25, 2009 at 05:57:45PM -0700, Bill Ward wrote: I'm not really liking any of the names that have been proposed so I'm going back to the original message to give my thoughts. The English name of $^O is $OSNAME, so there's precedent for OS. I think it should use OS and not something like System. That doesn't really narrow it down ;) ByOS PerOS ForOS OSSpecific OSMagic MagicOS ... As for where to put it, the way this would be useful to me would not be as any sort of object (which rules out Class::) but as a sort of assertion or query about the operating system. You wouldn't need to instantiate any objects of this class, it would just be for asking what OS am I running on? so OO is really not needed except maybe for some @ISA magic. This isn't about yes/no assertions. This is about always providing _an_ implementation of some code, but possibly providing a better one on some OS if it can be done. An actual example: Linux has pselect() and ppoll(), which allow safe mixed IO-and-signal handling. Portably these don't exist. A Linux implementation of IO::Async::Loop could use these to mix file IO and signals safely; a portable base can't, so would have to make do with something less. use OS has_symlinks; # would fail under Windows use OS::linux; # would fail under any non-Linux OS That's not at all where I'm aiming here... What specific OS-related questions do you want this for? Obviously not filesystem naming rules... IT's the magic used to allow another class to provide per-OS customisations. E.g. see my IO::Async example above :) -- Paul LeoNerd Evans leon...@leonerd.org.uk |CPAN ID: PEVANS signature.asc Description: Digital signature
unicode.pm - a replacement of perl -C
Since #!/usr/bin/perl -C no longer works, I've been pondering on what is a good replacement. How do people feel about: #!/usr/bin/perl use unicode; With tags to control it; things like use unicode qw( :stdio :env :argv :defaultio :locale ); -- Paul LeoNerd Evans leon...@leonerd.org.uk |CPAN ID: PEVANS signature.asc Description: Digital signature
Re: RFC: String::Tagged
On Thu, 29 Jan 2009 21:45:18 -0500 Ryan Voots simcop2...@yahoo.com wrote: I don't know how you would feel about this but what about also overloading the stringification of the object so that one could use the built in Csubstr also? Ohyes, that sounds useful. I didn't have anything else in mind for stringification, so I guess if that helps debugging etc.. I could do that. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: RFC: String::Tagged
On Fri, 30 Jan 2009 09:50:21 +0100 Elizabeth Mattijsen l...@dijkmat.nl wrote: Without having looked at implementation, Ah; I purposely didn't include that because it isn't finished in some parts - I wanted an idea of what people thought of the interface first, I can hack up those ideas behind the method names later ;) this sounds like it could benefit from my out-of-band data module OOB: http://search.cpan.org/perldoc?OOB Hmm.. That does look interesting, though a few questions come to mind. If it was done as outofband data behind a plain string - how would the methods get called? How would a method get called after a substr() modify operation, to go and fix up the tags afterwards. That said, maybe some tags would want to imply a locking effect, banning the disturbance of the character positions beneath them. This would have to veto the substr() before it's even called. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: RFC: String::Tagged
On Fri, Jan 30, 2009 at 09:15:35AM -0600, Jonathan Rockway wrote:
* On Fri, Jan 30 2009, Bill Ward wrote:
I agree here. There is prior art for calling these overlays:
http://www.gnu.org/software/emacs/elisp/html_node/Overlays.html
Ah; would this suggest something like these?
String::Overlay
String::Overlaid
String::Overlays
--
Paul LeoNerd Evans
leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)
signature.asc
Description: Digital signature
Re: RFC: String::Tagged
On Fri, Jan 30, 2009 at 10:11:33AM -0800, Bill Ward wrote:
String::Overlay
String::Overlaid
String::Overlays
I think Overlain may be more grammatical than Overlaid
Overlaid, Overlain... One of those annoying centuries-old legacies of
languages. Seems Perl isn't the only language to suffer those ;)
but I think I prefer MarkUp personally.
Hrm. Well, MarkUp would tend to suggest issues of formatting or
rendering attributes. That was mostly the use-case I had in mind, but
only indirectly. Nothing in the implementation directly requires that to
be the case.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)
signature.asc
Description: Digital signature
Re: RFC: String::Tagged
On Fri, Jan 30, 2009 at 02:00:13PM -0600, David Nicol wrote:
there is also intersection with the concept of ropes rather than
strings as I understand the term,
A rope is a data structure designed to make string concat an O(1)
operation, where you store a tree, or a linked list of substrings.
That isn't the case here - in fact, the string data itself is just
stored in here as a single perl string. The tags are stored in as a list
of [start, length, name, value] objects beside it.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)
signature.asc
Description: Digital signature
Re: RFC: String::Tagged
On Fri, Jan 30, 2009 at 02:08:24PM -0800, Bill Ward wrote:
Or String::Substrate? The meaning of substrate doesn't really fit
here but it's so close to SubStrAttr that I bet you could get away
with it, with a suitable comment explaining the name :)
I can't help thinking we're getting a bit side-tracked by the name here.
There's a lot of interesting API in the code, I feel the name is
somewhat overshadowing any other discussion on the API design or other
details...
--
Paul LeoNerd Evans
leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)
signature.asc
Description: Digital signature
RFC: String::Tagged
position. A shortcut around set_substr(). $st-append( $newstr ) Append to the underlying plain string. Because no tags will yet apply here, this method is not subject to note given in set_substr(). $st-append_tagged( $newstr, %tags ) Append to the underlying plain string, and apply the given tags. TODO · Implement (possibly multiple) ways to modify substrings, while keeping some level of sanity on the tags. Likely sensible behaviour would probably be: Tags entirely before the replaced region would remain unchanged. Tags entirely within the replaced region would be deleted. Tags entirely after the replaced region would get shifted up/down the appropriate amount to ensure they still apply to the right characters. Tags that start before and end after the range would remain, and have their lengths suitably adjusted. Tags that span just the start or end of the range, but not both, would be truncated shorter, so as to remove the part of the tag applied on the modified section but preserving that applied outside. There are likely variations on these rules that could equally apply to some uses of tagged strings. Consider whether the behaviour of modification is chosen per-method, per-tag, or per-string. AUTHOR Paul Evans leon...@leonerd.org.uk perl v5.10.0 2009-01-30 String::Tagged(3pm) - -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: FAILs with undefined symbol: setup_constants
On Wed, 29 Oct 2008 05:16:57 +0100 [EMAIL PROTECTED] (Andreas J. Koenig) wrote: All your fail reports are written by bingos with CPANPLUS, version 0.84. This is not only true for the three above but for all reports. CPANPLUS 0.84 *never* wrote a PASS for Devel-Refcount up to now. ... These are written by CPANPLUS::Dist::YACSmoke 0.02 and 0.04 by the same tester, this time known as chris. Like a cheetah who's just won Best Coat Award in the annual Serengeti Miss Africa contest; well spotted. Maybe chris knows something? Righto. I'll ask him. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
FAILs with undefined symbol: setup_constants
I'm finding that one of my XS-based dists, Devel-Refcount, is failing
lately on most platforms ({Open,Free,Net}BSD, Darwin, Linux), on a symbol
lookup error:
t/01refs.../home/cpan/pit/rel/perl-5.10.0/bin/perl: symbol lookup error:
/home/cpan/pit/rel/conf/perl-5.10.0/.cpanplus/5.10.0/build/Devel-Refcount-0.03/blib/arch/auto/Devel/Refcount/Refcount.so:
undefined symbol: setup_constants
I don't have such a symbol in my code; the XS is absolutely tiny. It
seems like it may be related to perl itself then?
For reference, some FAILs:
http://nntp.x.perl.org/group/perl.cpan.testers/2470288 (5.10 / linux)
http://nntp.x.perl.org/group/perl.cpan.testers/2449662 (5.10 / netbsd)
http://nntp.x.perl.org/group/perl.cpan.testers/2447543 (5.10 / darwin)
Some PASSes on the same perl version / platform:
http://nntp.x.perl.org/group/perl.cpan.testers/2069693 (5.10 / linux)
http://nntp.x.perl.org/group/perl.cpan.testers/2028293 (5.10 / netbsd)
http://nntp.x.perl.org/group/perl.cpan.testers/2149637 (5.10 / darwin)
Before I go looking too deeply into it; is anyone aware of the reason
behind this? Anything I can do about it?
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: Integrating license related things of CPAN
On Wed, Oct 22, 2008 at 01:09:16PM +0200, Gabor Szabo wrote: 1) META.yml license field is required. http://module-build.sourceforge.net/META-spec.html#license says the license field is required but FAIK when calling make dist or ./Build dist both EUMM and MB will happily create META.yml files without a license field. If there is an agreement on the field being required then I think the tools should not create a distribution without a valid license key. Obviously they should keep installing modules without a license in META.yml. I think an outright failure for what is ultimately a non-technical reason, is not a good behaviour. It could warn loudly, but I don't think it should completely fail to build. That would get annoying in sitautions when you want to Just Do It. 2) The list of valid values should be in http://module-build.sourceforge.net/META-spec.html#license instead of its current place, which is http://search.cpan.org/dist/Module-Build/lib/Module/Build/API.pod Specs are good. 3) Software::License http://search.cpan.org/dist/Software-License/ has a growing list of licenses with full text in it. The list of licenses is not the same as the values in META.yml and even in the cases where the license seem to be the same their short name is not identical. IMHO these lists should be unified. If we can accept http://www.opensource.org/licenses as the official list of open source licenses the short names should be coordinated with them. Unified agreement with the wider community is good. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Integrating license related things of CPAN
On Wed, Oct 22, 2008 at 11:52:27AM -0700, Eric Wilhelm wrote: While that might be annoying (once -- for the author), the tool can't get around that if it is a required field -- because any other behavior wouldn't comply with the META.yml spec. I suppose that's a fair point. I'm just thinking of the case where someone will just put anything in the field to shut up the tool because they just want to get on with it. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: RFC: Attribute::Storage
On Mon, Oct 20, 2008 at 11:49:58PM +0100, Paul LeoNerd Evans wrote: Thoughts, anyone? On the name, the implementation, the idea,.. anything else that comes to mind? Nothing; anybody? In that case perhaps I'll shove it up on CPAN then. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Proposal: Test::Refcount
On Tue, 15 Jul 2008 19:16:08 -0700 Joshua ben Jore [EMAIL PROTECTED] wrote: *Devel::RefCount::refcount = \Devel::Peek::SvREFCNT; No it isn't. Devel::Peek::SvREFCNT counts the refcount of the SV itself that is passed to it. Mine counts the refcount of the RV contained in a reference value. As is even printed in the docs: This differs from Devel::Peek::SvREFCNT in that SvREFCNT() gives the reference count of the SV object itself that it is passed, whereas refcount() gives the count of the object being pointed to. This allows it to give the count of any referent (i.e. ARRAY, HASH, CODE, GLOB and Regex types) as well. Consider: my $array = []; my $otherref = $array; Devel::Peek::SvREFCNT($array) = 1 Devel::Refcount::refcount($array) = 2 -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Proposal: Test::Refcount
On Tue, 15 Jul 2008 00:44:12 +0100 Paul LeoNerd Evans [EMAIL PROTECTED] wrote: GLOB = \*SomeNewName, Also, this one isn't a fair test. Any real object code in a module would probably just pass out a new IO handle (as from socket(), socketpair(), pipe(), etc...) or else generate one using Symbol::gensym(). If I use gensym() in this test, that becomes happy too. Still no idea on the CODE though. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Proposal: Test::Refcount
On Tue, 15 Jul 2008 00:11:10 -0700 (PDT) Ovid [EMAIL PROTECTED] wrote: The B modules are incredibly powerful, poorly documented pieces of crap. They may be great, but without documentation on how to use that speedboat, it's so much scrap metal. So... is this a vote in favour of better docs, or a wrapper module to hide the magicness? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Proposal: Test::Refcount
I've been hunting through my code, eventually coming to a bug where I had
a closure that referred to itself, as well as an object of mine. This
prevented my object's DESTROY handler from working, causing bugs.
I've been playing with Test::Memory::Cycle, but unfortunately that won't
solve this particular problem.
my $hash = {};
$hash-{object} = $some_object;
$hash-{cycle} = $hash;
No amount of cycle checking in $some_object is going to find this cycle.
If the cycled object is one like this; containing the only reference to
itself, then almost by definition there's nothing that could be walked
for memory cycles.
This is where I consider a refcount-assertion module instead; something I
could do this with:
use Test::Refcount;
my $object = Some::Class-new( ... );
has_onlyref( $object, '$object has only 1 reference' );
# Synonym for
has_refcount( $object, 1, '$object has only 1 reference' );
There's a very simple implementation for this I can think of; using:
use B qw( svref_2object );
sub refcount {
my $sv = svref_2object( $_[0] );
return $sv-REFCNT - 1; # Because @_ refers to it too
}
Does this sound good?
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: Proposal: Test::Refcount
On Tue, 15 Jul 2008 05:01:14 +1000
Ivan Wills [EMAIL PROTECTED] wrote:
I would suggest a two modules though say Devel::Refcount
Is this Devel::Refcount really necessary, given how easy it is to build
using B::SV-REFCNT ?
Plus, the more levels of code, the more difficult it is to ensure the
count is correct. Consider
sub is_1ref
{
my ( $object, $name ) = @_;
my $count = refcount($object);
...
}
vs
sub is_1ref
{
my ( undef, $name ) = @_;
my $count = refcount($_[0]);
...
}
The $object in the first code creates a second reference, so you have to
subtract 1, whereas the @_ array seems special and doesn't have that
side-effect.
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: Proposal: Test::Refcount
On Mon, 14 Jul 2008 13:46:42 -0500 Andy Lester [EMAIL PROTECTED] wrote: Yes, and if it sounds like it would actually supercede Test::Memory::Cycle, I would be glad to abandon T:M:C in favor of yours. OK; see what you think to the attached initial attempt. Not CPANned it yet; will wait and see some comments on it first. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ Test-Refcount-0.01.tar.gz Description: GNU Zip compressed data signature.asc Description: PGP signature
Re: Proposal: Test::Refcount
On Mon, 14 Jul 2008 20:59:34 +0100 David Cantrell [EMAIL PROTECTED] wrote: Can't you use Devel::Peek to get the refcount? I use B: use B qw( svref_2object ); my $SV = svref_2object($ref); my $refcount = $SV-REFCNT; -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Proposal: Test::Refcount
On Mon, 14 Jul 2008 20:59:20 +0100 Nicholas Clark [EMAIL PROTECTED] wrote: It would be dangerous to rely on this reference counting behaviour remaining the same. Ah. Then perhaps it may be safer to use the normal my ( $object, $count, $name ) = @_; list assign idiom, then use -REFCNT - 1 -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Proposal: Test::Refcount
On Tue, 15 Jul 2008 06:11:25 +1000
Ivan Wills [EMAIL PROTECTED] wrote:
If Paul LeoNerd Evens doesn't want to create the module Devel::Refcount
along with Test::Refcount I would be happy to do it my self.
Well, it's not that I don't want to as such.. I'm just not sure it's
really justified.
It's kindof a personal thing, but I have a disliking for the mass
accumulation of really small one-liner modules around the place. Would
anyone consider
package String::CaseInsensitive;
sub casecmp { lc $_[0] cmp lc $_[1] }
1;
as a module, for example?
When the module starts to get this small, I begin to wonder if it's more
of a documentation issue. Perhaps somewhere in the documentation about
objects and reference counts:
The reference count of an object can be obtained by
use B qw( svref_2object );
my $count = svref_2object($ref)-REFCNT;
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: Proposal: Test::Refcount
On Tue, 15 Jul 2008 06:33:26 +1000 Ivan Wills [EMAIL PROTECTED] wrote: I just tried it and the tests fail on anonymous references in t/01count.t and t/02one.t, I'm using perl 5.8.8 on linux if that is of any help. Ahh.. 5.10 here. OK; I've changed it to use a normal lexical $object, then subtract 1 from the refcount, rather than rely on @_ not incrementing the count. Perhaps that'll be more portable. Try again attached... -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ Test-Refcount-0.01.tar.gz Description: GNU Zip compressed data signature.asc Description: PGP signature
Re: Proposal: Test::Refcount
On Mon, 14 Jul 2008 21:42:23 +0100 Paul LeoNerd Evans [EMAIL PROTECTED] wrote: OK; I've changed it to use a normal lexical $object, then subtract 1 from the refcount, rather than rely on @_ not incrementing the count. Perhaps that'll be more portable. Actually it occurs to me this may not help, because the reference will still be in @_ as well. If it still fails, perhaps try my $object = shift; my $count = shift; my $name = shift; that way it'll remove the ref. from @_ as it goes. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Proposal: Test::Refcount
On Mon, 14 Jul 2008 18:28:57 -0500
Jonathan Rockway [EMAIL PROTECTED] wrote:
Considering B is core, there is probably no need for a module to do
this. But, does this always return correct results? Does the
svref_2object call affect the REFCNT? I am too lazy to check, but these
are nice questions for the documentation to answer. If svref_2object
affects its argument, then it's probably best to write a module that
compensates for this behavior.
Actually, now I look at it there seems to be more complicated things
going on.
Originally I tried testing it with just the HASH or ARRAY based object
types people tend to use. I thought I'd try out all the reference types,
and here's the behaviour I get:
A new SCALAR ref has REFCNT 2
A new ARRAY ref has REFCNT 1
A new HASH ref has REFCNT 1
A new CODE ref has REFCNT 2
A new GLOB ref has REFCNT 3
A new Regex ref has REFCNT 1
[see attached program]
It seems interesting that a new SCALAR or CODE ref has 2 references
already, and a GLOB has 3. I guess the CODE one -might- be explained by
its PAD or something, and maybe the GLOB one has more references in the
Perl symbol table, but these are pure guesses. I also cannot explain the
SCALAR one.
This behaviour seems to complicate the idea of simply asserting
REFCNT == 1.
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
#!/usr/bin/perl -w
use strict;
use B qw( svref_2object );
my %refs = (
SCALAR = do { \my $var },
ARRAY = [],
HASH = +{},
CODE = sub {},
GLOB = \*SomeNewName,
Regex = qr/foo/,
);
foreach my $type (qw( SCALAR ARRAY HASH CODE GLOB Regex )) {
my $REFCNT = svref_2object($refs{$type})-REFCNT;
printf A new %6s ref has REFCNT %d\n, $type, $REFCNT;
}
signature.asc
Description: PGP signature
Re: Proposal: Test::Refcount
On Tue, 15 Jul 2008 00:44:12 +0100
Paul LeoNerd Evans [EMAIL PROTECTED] wrote:
SCALAR = do { \my $var },
It seems I can make the SCALAR ref have refcount 1 by changing this to
SCALAR = do { my $var; \$var },
Various initialisations {e.g my $var = 1} also keep it happy.
Just the CODE and GLOB to go then...
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Module proposal: event hook lists
,
on_done = sub {
my ( $total ) = @_;
print Total: $total\n;
}
);
sub my_handler
{
return 20;
}
sub my_async_handler
{
my %params = @_;
later( sub {
$params{next}-( $count );
} );
}
If we now give the aggregation function the ability to control the loop, we
find that the next/last behaviour above falls out as a natural consequence of
how it works:
my $hooklist = Hooklist-new(
aggregate = sub { last HOOK if $b },
);
One Big Question still remains. Ordering. Do we just take priority numbers, or
can we find something better?
Perhaps anyone who cares about ordering has a name, and others can ask to be
somewhere before/after those named points?
$hooklist-register_sync(
name= mangle,
handler = \my_mangle_function,
);
$hooklist-register_sync(
name= eat,
handler = \my_eat_function,
after = [ mangle ],
);
Then sometime later, some wants to look at this event after it's been mangled
but before it's been eaten:
$hooklist-register_sync(
name= observe,
handler = \my_observe_function,
after = [ mangle ],
before = [ eat ],
);
This has the ability to throw an exception if the ordering conditions cannot be
met.
This solution has now changed the problem from one of managing absolute
numbers, into one of managing names. Hopefully less chance of collisions and
mistaken behaviour, but it's more complex to implement and handle. Also harder
for the end user to picture the behaviour. But maybe it's worth it?
Another interesting question - if two async. handlers are installed at the same
priority, would it be best for us to take advantage of that, and run them both
in parallel? If we do, we can maximise IO performance of whatever they do, but
we run the interesting risk that one of them asks to stop; we can't stop the
other one. But maybe that's hard luck, and just what you get from taking the
same number twice..?
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Re: Module proposal: event hook lists
On Tue, Jun 03, 2008 at 12:49:57PM +0100, Paul LeoNerd Evans wrote:
Of course, now we have the simplest of hooklist aggregations - the
repeat while false one. What if we wanted something else? Suppose we
wanted to sum some quantity?
my $hooklist = Hooklist-new(
aggregate = sub { $a + $b }, # accumulate in $a using the per-hook
value $b
);
Actually, I've thought about it some more. We don't strictly need these,
if we're prepared to do just a little bit more work in the handler or
invokation time:
my $hooklist = Hooklist-new();
$hooklist-register_sync( sub {
my %params = @_;
$params{args}-( $count );
} );
my $total = 0;
$hooklist-fire_sync( sub { $total += shift } );
Or maybe even simpler
$hooklist-register_sync( sub {
my %params = @_;
$params{args}[0] += $count;
} );
my @args = ( 0 );
$hooklist-fire_sync( [EMAIL PROTECTED] );
my $total = $args[0];
We can also do looping control in sync. handlers by just doing the
last HOOK trick there.
It does mean putting more intelligence in the specific handlers and
callsites of the hook list, rather than in the Hooklist object itself,
which is where I originally wanted it. The advantage of being in the
list itself is to keep good modularity - the hooked functions don't need
to consider it so much any more.
Opinions either way?
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Finding the best concrete subclass for an abstract base class
I have a base class which is abstract, and various concrete
implementations of it that might be chosen in different circumstances
(different OSes, different modules installed). I'd like a magic
constructor that attempts to find the best subclass... Problem is,
there's no easy way to answer what is best...
My current best ideas are either:
a: Each module just gives a ranking number, and we find the one with
the highest ranking.
b: Each module declares a list of other modules it knows it's better
than...
Both of these have problems.
Idea a would be implemented by something like:
my @modules = [some magic with Module::Pluggable];
my %rankings = map { $_ = $_-get_ranking } @modules;
# get_ranking is a method, so it can make a runtime choice on how
# good it is in the current situation
return ( sort { $ranking{$b} = $ranking{$a} } @modules )[0]
This works, provided every module author plays the same way with regard
to rankings. But how to choose these? Because my module declares 30,
does that mean it's better than yours which is 20, or is it just that we
happened to pick different numbers? Perhaps some guidelines by what is
meant by various numbers - e.g. 10 for the basic default one, 50 for a
per-OS one, 100 for a per-installed-library one, etc...
Idea b would involve taking each module in turn, and removing from the
set of candidates all other modules that it declares itself to be better
than. We will then end up with a (possibly-empty) subset of what we
started with. If we have one, great, use it. If we have multiple, how
can we choose? More's the problem, what if we end up with none? What if
Foo claims to be better than Bar, but Bar claims to be better than Foo?
I suspect approach a may end up being better in practice, even if it
involves a bit more coordination between the authors.
How's anyone else go about this problem?
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: How to challenge a cpan-testers test result?
On Mon, 26 May 2008 15:10:00 -0700 Eric Wilhelm [EMAIL PROTECTED] wrote: There is a long-standing discussion over whether or not Module::Build is a viable installation technique, due to the bootstrapping problem of requiring Module::Build to be installed in the first place before installing your own module. It's no different than requiring Extutils::MakeMaker to be installed, so it's not really a bootstrapping problem as much as one of outdated assumptions, but in either case it seems to be the norm to test with an outdated (they call it stock toolchain), so the signal/noise ratio is roughly zero. This should largely become a non-issue now. 5.10 is the current stable perl, and comes with Module::Build. It's only the older testers on 5.8.8 or below that matter with this now. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: How to challenge a cpan-testers test result?
On Mon, 26 May 2008 23:22:47 +0200 David Landgren [EMAIL PROTECTED] wrote: I have a couple of FreeBSD-specific modules. Automated smokers running on Linux and what ever keep trying to test them and fail. I don't think these failures will stop someone who uses FreeBSD from considering them for their own use. die OS unsupported unless $^O eq freebsd; in Build.PL should fix that. It'll turn your FAILs into NAs when run on non-FreeBSD boxen. I have two dists (IO-Ppoll and Solaris-SysInfo) which need that trick. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: RFC: URI::cpan
On Wed, Mar 26, 2008 at 01:19:28PM -0400, Hans Dieter Pearcey wrote: I prefer cpan://ID/file, but I can see a case for cpan://author/ID/file, and I don't have strong feelings on the matter. Does anyone else? Well, if your author ID happens to be dist or module or whatever, you might get a bit upset... ;) Having a small fixed toplevel space with freeform text below, is much easier on automatic tools that might read this. cpan://dist/Foo-Bar cpan://module/Foo::Bar cpan://author/FRED Otherwise, we have to specialcase out all sorts of odd things, and whatever is left must be IDs. cpan://dist/Foo-Bar cpan://module/Foo::Bar cpan://FRED I'd easily go for the former. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: cpantesters.org stalled?
On Thu, 7 Feb 2008 14:04:29 + Paul LeoNerd Evans [EMAIL PROTECTED] wrote: This page was generated by CPAN::WWW::Testers 0.33 at 2008-01-29 15:38:43 Ah; it's now been updated. Either false alarm, or someone's managed to fix it. In any case, all is happy now. :) -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Any contact with BRUCEK?
I have some changes I'd like to make to IO::Epoll. I'm trying to get hold of BRUCEK, its author: http://search.cpan.org/~brucek/ I tried mailing the address given, just got a bounce: - [EMAIL PROTECTED]: host mail.drangle.com[198.145.186.2] said: 550 5.1.1 [EMAIL PROTECTED]... User unknown (in reply to RCPT TO command) - I've now tried his email address given in the code itself, which appears to be different. No reply yet, but I've only given it two days so far... What's the procedure now..? At some point do we declare him uncontactable, and invoke some sort of missing-in-action procedure? Is it possible I might be able to take ownership of it, if contact cannot be made? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
XS wrapper around system - how to test the wrapper but not the system?
I'm finding it difficult to come up with a good testing strategy for an XS module that's just a thin wrapper around an OS call, without effectively also testing that function itself. Since its behaviour has minor variations from system to system, writing a test script that can cope is getting hard. The code is the 0.08 developer releases of Socket::GetAddrInfo; see http://search.cpan.org/~pevans/Socket-GetAddrInfo-0.08_5/ for latest. The code itself seems to be behaving on most platforms; most of the test failures come from such things as different OSes behaving differently if asked to resolve a host called something.invalid, or quite whether any system knows the ftp service, or what happens if it wants to reverse resolve unnamed 1918 addresses (e.g. 192.168.2.2). The smoke testers page is showing a number of FAILs on most platforms not Linux (where I develop), probably because of assumptions the tests make that don't hold there any more. E.g. one problem I had was BSD4.4-based systems, whose struct sockaddr_in includes the sin_len field. http://cpantesters.perl.org/show/Socket-GetAddrInfo.html Does anyone have any strategy suggestions for this? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Naming convention for thin wrappers around C libfoo.so ?
On Tue, 11 Dec 2007 00:05:19 + Smylers [EMAIL PROTECTED] wrote: Or if you want Lib::, then Lib::memcached makes the most sense. Compare also to the C case: use Lib::memcached gcc ... -lmemcached The library's name is memcached; the fact it lives in a file called libmemcached.so is purely a convention of the environment; namely, dynamically linked ELF libraries. Similarly here, the fact it lives in the Lib:: namespace is a convention of the perl environment. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Naming convention for thin wrappers around C libfoo.so ?
On Tue, 11 Dec 2007 08:04:04 -0500 Guy Hulbert [EMAIL PROTECTED] wrote: Lib::Memcached Follows perl conventions more closely ... iirc, all lower case is for pragmas and such ... but there seem to be precedents both ways. Ah yes, fair point. I was simply trying to argue against Lib::libmemcached, on the grounds of the 'lib' not really being part of the name. Yes; CamelCased names do seem the convention around here, except the pragmata, so I guess that's the way forward. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
autoconf-like work in Build.PL - detecting OS features
I'm writing a Perl wrapper around Linux's ppoll() system call. The
requirements here are
OS = Linux
Kernel version = 2.6.16
GNU libc = 2.4
The first two are quite easy to detect in Build.PL, the third is very
difficult. Having failed to think up a nice way to do that, my next
approach is
OS = Linux
Kernel version = 2.6.16
GNU libc supports compiling/linking/executing a program that calls
ppoll()
The only real way I can think of that last requirement, is to try
acutally doing it. So now my Build.PL is starting to look like an
autoconf script. [see attached].
Is this really the only way to check this sort of thing..? Is there a
better way?
I sortof like the idea of testing the ability to run ppoll(), rather
than inferring that from version numbers. Maybe the test is actually
sufficient, so I can not care about being Linux; so it any other OS ever
picks up the call, it will JustWork there...?
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
use strict;
use warnings;
use Module::Build;
use Config;
print ppoll() only works on Linux = 2.6.16, with a supporting libc.\n;
print These requirements will now be detected...\n;
# ppoll() is specific to Linux
$^O eq linux or die OS unsupported\n;
print Detected OS as Linux\n;
# ppoll() was added in 2.6.16
my $uname_r = `uname -r`; chomp $uname_r;
print Detected uname -r as $uname_r\n;
my ( $major, $minor, $release ) = $uname_r =~ m/^(\d+)\.(\d+)\.(\d+)/ or die
OS unsupported;
print Detected kernel version $major.$minor.$release\n;
die OS unsupported if $major 2;
die OS unsupported if $major == 2 and $minor 6;
die OS unsupported if $major == 2 and $minor == 6 and $release 16;
# The ppoll() syscall was added to GNU libc 2.4. Rather than go through all
# the tricky hoops to work out what version of libc is being used, we'll try
# instead to actually compile and run a program that calls ppoll()
print Detecting if libc supports ppoll()...\n;
my $test_c = test-ppoll.c;
my $test_exe = test-ppoll;
END {
-f $test_c and unlink $test_c;
-f $test_exe and unlink $test_exe;
}
my $cc = $Config{cc};
open( my $test_c_fh, , $test_c ) or die Cannot write test.c - $!;
print $test_c_fh EOF;
#include poll.h
#include stdlib.h
#include unistd.h
int main(int argc, char *argv[]) {
struct timespec timeout = { 0, 0 };
if(ppoll(NULL, 0, timeout, NULL) != 0)
exit(1);
exit(0);
}
EOF
close $test_c_fh;
system( $cc, -o, $test_exe, $test_c ) == 0 or die OS unsupported;
print Compiled $test_exe\n;
system( ./$test_exe ) == 0 or die OS unsupported;
print Successfully ran $test_exe - looks like the libc supports ppoll()\n;
print \n;
my $build = Module::Build-new
(
module_name = 'IO::Ppoll',
dist_version_from = 'lib/IO/Ppoll.pm',
requires = {
},
build_requires = {
'Module::Build' = 0,
'Test::More' = 0,
},
license = 'perl',
create_makefile_pl = 'small',
);
$build-create_build_script;
signature.asc
Description: Digital signature
Testers required for less-common platforms [was: RFC: Socket::GetAddrInfo]
No loud objections from the public gallery, so I've uploaded it, with some behavioural changes and documentation: http://search.cpan.org/perldoc?Socket::GetAddrInfo One thing I found while testing it, was that various platforms differ a lot in their own behaviour of getaddrinfo(). The emulated version in the perl module emulates GNU's libc as best as I can. I compared it against Solaris 10 and with the help of some people on #perl/Freenode, comparisons were also made with some BSDs. What I found was differences in how getaddrinfo( localhost, ) or similar requests that lack a service name all behave. * GNU libc on Linux will return three possible answers: AF_INET / SOCK_STREAM / IPPROTO_TCP AF_INET / SOCK_DGRAM / IPPROTO_UDP AF_INET / SOCK_RAW/ 0 * Solaris will only return one answer: AF_INET / 0 / 0 I also found that Solaris will never fill in the protocol number even for specifically-named service entries; it always leaves 0. * BSD will return two answers: AF_INET / SOCK_DGRAM / IPPROTO_UDP AF_INET / SOCK_STREAM / IPPROTO_TCP These differences meant I couldn't employ a testing strategy of simply comparing the emulated function with the platform's real one. I don't think any of these approaches is more correct than any other; at least, nothing I can find in documentation suggests any are wrong. I'd be interested to hear any other reports from other operating systems; the helper script t/10compare-getaddrinfo.pm will generate some useful output to compare the real and emulated versions. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
