Params::Classify provides various type-testing functions. These are
intended for functions that, unlike most Perl code, care what type of
data they are operating on. For example, some functions wish to behave
differently depending on the type of their arguments (like overloaded
functions in C++).
MooseX::NonMoose allows for easily subclassing non-Moose classes with
Moose, taking care of the annoying details connected with doing this,
such as setting up proper inheritance from Moose::Object and installing
(and inlining, at make_immutable time) a constructor that makes sure
things like BUILD methods are called.
MooseX::MarkAsMethods allows one to easily mark certain functions as
Moose methods. This will allow other packages such as
namespace::autoclean to operate without blowing away your overloads.
After using MooseX::MarkAsMethods your overloads will be recognized by
Class::MOP as being methods, and class extension as well as composition
from roles with overloads will "just work".
Often you want to write a persistant daemon that has a pid file, and
responds appropriately to Signals. MooseX::Daemonize provides a set of
basic roles as an infrastructure to do that.
"require EXPR" only accepts "Class/Name.pm" style module names, not
"Class::Name". How frustrating! For that, we provide "load_class
'Class::Name'".
It's often useful to test whether a module can be loaded, instead of
throwing an error when it's not available. For that, we provide
"try_load_class 'Class::Name'".
Finally, sometimes we need to know whether a particular class has been
loaded. Asking %INC is an option, but that will miss inner packages and
any class for which the filename does not correspond to the package
name. For that, we provide "is_class_loaded 'Class::Name'".
Updated from 1.04 port in Andreas Voegele's repository.
''Currently, several ports that could be built with
"CONFIGURE_STYLE=modinst" are built with "CONFIGURE_ARGS += --skipdeps"
as they require a more recent version of Module::Install.''
WWW::Mechanize 1.70. Required by the recent www/p5-WWW-Mechanize update
as well as the Catalyst update.
More recent versions of Test::WWW::Mechanize depend on LWP 6.02, which
hasn't hit OpenBSD's ports tree yet.
From Andreas Voegele's repo.
- built from the official upstream release
- needed for upcoming gnome/js update
- this is not an update to lang/spidermonkey, as that new version was
built upon Ffx 4 js engine and probably only works on amd64/i386/ppc.
It builds on sparc64 but is broken at runtime. Not marking BROKEN-* to
allow depending ports to build. Other archs untested.
- special care was taken to ensure it doesnt conflict with
lang/spidermonkey (install versionned binaries/headers..)
- ports wanting to use it should use devel/spidermonkey>=1.8,<1.9 to
ensure the correct version is picked up
Tested in an amd64 bulk build.
ok/prodding ajacoutot@
- rename libxul{,-embedding}.pc files to libxul19{,-embedding}.pc to
cope with an eventual xulrunner built from latest mozilla
- move some WANTLIB-devel from Makefile.inc to 1.9/Makefile
- use BASE_PKGPATH instead of devel/xulrunner/${MOZILLA_VERSION:R:R}, as
there might be a devel/xulrunner/last someday
- sanitize the subst regexps done on the .pc files, half of them were
useless
- bump REVISIONs.
Tested in a full bulk build with all xulrunner users..
For the theory of Memoization, please see the Memoize module
documentation. This module implements an expiry policy for Memoize
that follows LRU semantics, that is, the last n results, where n
is specified as the argument to the CACHESIZE parameter, will be
cached.
This module always exports a single function, Dumper, which can be
called with an array of values to dump those values.
It exists, fundamentally, as a convenient way to reproduce a set
of Dumper options that we've found ourselves using across large
numbers of applications, primarily for debugging output.
The principle guiding theme is "all the concision you can get while
still having a useful dump and not doing anything cleverer than
setting Data::Dumper options" - it's been pointed out to us that
Data::Dump::Streamer can produce shorter output with less lines of
code. We know. This is simpler and we've never seen it segfault.
But for complex/weird structures, it generally rocks. You should
use it as well, when Concise is underkill. We do.
Why is deparsing on when the aim is concision? Because you often
want to know what subroutine refs you have when debugging and because
if you were planning to eval this back in you probably wanted to
remove subrefs first and add them back in a custom way anyway. Note
that this -does- force using the pure perl Dumper rather than the
XS one, but I've never in my life seen Data::Dumper show up in a
profile so "who cares?".
