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?".
These flags types were originally incorrectly handled in glib as being
enums. That bug was fixed, but they're still enums here, leading to
warnings about the mismatch.
Change them to flags.
