Re: A funny module that shortens one-liners - is it worth global namespace?
* Aristotle Pagaltzis <pagalt...@gmx.de> [2017-01-09 01:42]: > * Konstantin S. Uvarin <khe...@gmail.com> [2016-12-27 11:24]: > > perl -Mnew=x=My::Very::Long::Module,foo,42 -we "print $x->foo;" > > perl -Maliased=My::Very::Long::Module,X -we 'print X->new( foo => 42 )' Err. perl -Maliased=My::Very::Long::Module,X -we 'print X->new( foo => 42 )->foo'
Re: A funny module that shortens one-liners - is it worth global namespace?
Hi Konstantin, * Konstantin S. Uvarin <khe...@gmail.com> [2016-12-27 11:24]: > I've come up with an interface to shorten that to just > > perl -Mnew=x=My::Very::Long::Module,foo,42 -we "print $x->foo;" maybe https://metacpan.org/pod/aliased is good enough? perl -Maliased=My::Very::Long::Module,X -we 'print X->new( foo => 42 )' I don’t know if that’s enough magic for you, though. Personally I find it a lot more obvious what’s going on there compared to your proposed interface. I’m sure I would never need to look at the docs to decipher what that line was supposed to be doing. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Sanity checking for namespace and other abuses
* David Mertens <dcmertens.p...@gmail.com> [2016-10-26 18:12]: > Does anybody oppose me adding to code to top-level, lower-cased > packages "int", "num", and "str"? What about top-level packages "Int", > "UInt", "Str", or "Num"? Do other type systems use these top-level > packages? Yes. You would either be reserving them for yourself across all of CPAN, unless you no_index them, in which case you would merely be making it probably-impossible to use your module together with another one that might also want to use these packages. (Which doesn’t have to be a CPAN module, it can also be some would-be user’s already-existing code base.) It will be uglier to namespace your stuff more; bite that bullet. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Boolean As a Top Level Name
* John M. Gamble <jgam...@ripco.com> [2016-09-09 22:12]: > Technically it's math, but I suspect people would be more likely to use > the keyword 'boolean', or perhaps 'digital logic', when looking for > something like this. > > (For supporting evidence, the Wikipedia article on the Quine-McCluskey > algorithm nowhere uses 'math' in the current version of the article.) But “mathematical” is the first non-stop-word besides “truth table” in the Wikipedia entry for “truth table”. As for Boolean::Minimizer, I wouldn’t have the foggiest clue what that module might be about from the name of it. Even after your explanation, the foggiest clue is as much as I got. So I can’t really suggest better. I vaguely suspect it’ll turn to be something best put in Data::, but who knows. To backtrack a bit here though – are these supposed to be in different distributions? Sounds like Algorithm::QuineMcCluskey would be separate but the others would ship together. If so, then one should probably be a sub-namespace of the other. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Dilemma for XML::MyXML
* Alexander Karelas <ak...@zoo.gr> [2016-07-04 21:48]: > The same question applies to parsing: should the XML documents that > the module parses be byte strings or character strings? An XML document must be bytes, because it specifies its encoding in the at the top (even if only implicitly) and that makes no sense any other way. But an XML fragment must be characters because text in XML is Unicode and fragments do not have an encoding. But this gets a little metaphysical when you deal with concrete data because the XML PI is optional. You can’t distinguish XML fragments from XML documents just by looking at them. It’s like a string that sticks to ASCII: is that bytes or characters? The distinction is not in the data, it’s in programmer intent behind the code that handles the data… but you have to keep that in mind to write code that actually works correctly. (Which is to say we’re talking about types. The type is not in the data. This is where an actual type system helps – having one means you can express that concretely.) So the I-don’t-believe-in-abstractions answer is… just allow the user to get the data as both characters and bytes, and make them say which one. For that case I would argue that the default ought to be bytes. The more abstractionista answer would be if the user can ask for a node to be rendered as an XML fragment; in that case, to get characters they must ask for the document element rendered to a string, and if they ask for the whole document they always get bytes. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: A question of permissions
* Matt S Trout <m...@shadowcat.co.uk> [2016-05-11 20:23]: > Were I you, I'd simply take the evidence as available: > > - At least four people thought your comment was phrased unkindly > - At least one person thought your comment was phrased fine I cringed at the comment, but I also realised this was because I know that Neil is in a position to know what he is talking about. I guessed that Buddy simply did not, and I assumed the comment would have passed by unnoticed if it had been directed at some random subscriber helping out, so I thought it best not to make a fuss of it myself on behalf of Neil without asking him, and to leave it to Neil whether he wanted the point addressed. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Perl Modules in GitHub
Hi Jerry, * Jerry D. Hedden <jdhed...@cpan.org> [2016-03-29 05:25]: > Is there preferred organization, account, methodology for doing this? not really. > I would think there is a better way than just putting them under my > own GitHub account, The current situation is the same as with all other parts of the Perl ecosystem: whatever worked for whoever showed up to do the work. With the vast majority of CPAN modules that live on GitHub, that means they live under their maintainer’s personal account. Some CPAN authors have set up personal GitHub Organisations to put their modules into so they can hand out admin access. You can hand out commit bits to repos in your personal account to other GitHub users, mind. AFAIUI the diffference with a GitHub Org is that you can also hand out administrative access to its repos (and the org itself) at the GitHub level. That’s why the Perl Toolchain Gang org exists, as mentioned by BooK. > particularly as this would complicate matters if the time should come > when someone else would need to take over their maintenance. The history of the project can be grabbed by anyone, that is the whole point of using a DVCS after all. The only real issue is bug tracking, because it is usually centralised. If you use GitHub Issues to manage tickets, then the bug tracker cannot be taken over by a new maintainer without action on your part. (You can move the repository from your account to another, which will carry over its issues (and wiki content, if you use that). That will require your active participation.) If you use RT.cpan, the PAUSE admins can reassign permissions, so that takeovers can happen without your involvement. You can turn off GitHub Issues in a repository if you wish issues to be reported otherwise. But note that you cannot turn off pull requests at the time of this writing. So in practice modules maintained under a personal account are not that problematic. The only serious problem is in case the maintainer got run over by a bus and nobody else can log into their GitHub account. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Is META.yml Necessary Anymore?
* Dominique Dumont <domi.dum...@free.fr> [2015-10-25 12:30]: > Debian uses the information from META to create and refresh Perl > package in Debian format. > > More specifically, the tool used to create and refresh package > (dh-make-perl [1]) needs META.yml to work. > > So, please, do not remove META. Nobody is talking about dropping META entirely. The question is whether a META.yml is necessary in addition to META.json. Does dh-make-perl need META.yml specifically or can it just as well use META.json? (I would hope it can…) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Is META.yml Necessary Anymore?
* Leon Timmermans <faw...@gmail.com> [2015-10-10 15:50]: > META was never something relevant for installation purposes except > configure_requires (and dynamic_config, theoretically), it's MYMETA > that matters more. When using EUMM often you can easily live without > META.yml, but figuring out when you need it and when not is a hassle, > and actually declaring a minimum EUMM version (even if it's an ancient > one) is generally considered good practice. Also I think some > packagers may be using it. So what does that mean for John’s original question? -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Is META.yml Necessary Anymore?
Hi John, * John M Gamble <jgam...@ripco.com> [2015-10-06 20:25]: > What with META.json being generated (and presumably used) in our CPAN > uploads, is it necessary to include META.yml anymore? A brief search > didn't really tell me anything. > > If it makes a difference, the minimum version of Perl that I require > for my modules is currently 5.10.1. if I’m looking at this right, Perl 5.13.10 is the earliest Perl version where the toolchain supports META.json out of the box. Specifically, 5.13.9 was the first perl to ship JSON::PP in core, but its CPAN.pm and Parse::CPAN::Meta lack META.json support. They were added in Parse::CPAN::Meta 1.41_01 and CPAN.pm 1.94_65, both of which were included in 5.13.10 (or rather, Parse::CPAN::Meta was upgraded to 1.44). In practice that means Perl 5.14.0 is the first Perl that can install dists with a JSON-only META out of the box. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Naming help needed for evil @INC hackery
* David Cantrell <david.cantr...@uk2group.com> [2015-10-06 17:35]:
> One of my modules is Sub::WrapPackages. It has a feature where you can
> invoke it once and it will both wrap itself around code that's already
> been loaded, but will also lurk in the background and do Things to
> code that is loaded in the future. It does this by dropping sub-refs
> in @INC. It also subverts 'use lib' so that if you 'use lib' after it
> has dropped its magic into @INC, it silently moves its sub-refs to the
> front of @INC.
http://search.cpan.org/search?q=inc
https://metacpan.org/pod/Array::Sticky::INC
https://metacpan.org/pod/Devel::INC::Sorted
Huh.
> The code for this is quite simple and right at the end of Sub::WrapPackages:
> https://metacpan.org/source/DCANTRELL/Sub-WrapPackages-2.0/lib/Sub/WrapPackages.pm#L337
Those other modules both rely on tie’ing @INC, which is more bloated but
also more robust than your solution (they’ll work for code that operates
on @INC directly, unlike your solution). Hmm.
Probably you can use Variable::Magic to write a lower-overhead version.
But then you have to live with the XS requirement. Hmm.
> I now find that I need this functionality in another module, so I'm
> going to rip it out and upload it to the CPAN as a seperate
> distribution that will let you register sub-refs to do this with. But
> what to call that?
>
> Devel::INC::MySubrefsFirst?
>
> I think that sucks, but I can't think of anything better that is still
> reasonably short. Anyone got any better suggestions?
I don’t like the general abuse of Devel:: for things that have nothing
to do with perl’s -d switch (though the abuse was certainly invited by
the reservation of an overly broad TLNS for this purpose).
You’re monkeypatching lib.pm. How about lib::RespectHooks?
That would be particularly descriptive if you avoid the need for any
interface by simplifying the code to something like
my $newimport = sub {
my @hook;
push @hook, shift @INC while ref $INC[0];
&$originallibimport;
unshift @INC, @hook;
};
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Trying to come up with a name for a DTrace Consumer XS module
* Lars Thegler l...@thegler.dk [2015-07-09 20:40]: http://prepan.org/ has this exact purpose - incl discussing namespace. This list also has this exact purpose, including discussing namespace. * Gordon Marler gmar...@gmarler.com [2015-07-09 14:40]: I initially named it Devel::libdtrace, which in hindsight seems completely wrong, since it's not meant to be used to debug Perl itself. Hooray, someone else who notices the thing that bugs me about 99% of the stuff in Devel:: on CPAN! It may be unfortunate that perl’s -d switch reserves a name as broad as “Devel” for itself, but it is what it is. Yet 99% of modules in Devel:: have nothing to do with the -d switch, they just use the namespace as a generic term. There is no way to change any of this now, but it’s still irritating. DTrace::Consumer seems nice and descriptive, but may be too far up in the name hierarchy. Any other suggestions? Thanks for any feedback. The only other DTrace-related stuff on CPAN is in Devel:: which is out of the question. Personally I wouldn’t mind DTrace::Consumer… or so I thought. But if I’m honest I would mind it just a little. So I went looking for stuff like strace- and ptrace-related modules, and that did turn up another alternative: those are split between Devel:: (again) and Sys::. Oh right, d’oh. That seems like a pretty good choice. How does Sys::DTrace::Consumer sound? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: good form for discontinuing a module
* John Macdonald john.macdon...@oicr.on.ca [2015-06-08 21:05]: We rebuild our environment very night, including downloading all cpan modules anew (automatically getting the latest one if it has been updated). So, if anyone else has a similar environment and does a similar autofetch, then they would be impacted (although in such cases, they would probably already have converted to the renamed new module). Note that modules exist on forever on BackPAN. “Deleted” modules are only slightly less easy to download than non-deleted ones. The main effect of deletion is to de-index the tarball in question, making it nearly impossible to find unless you go looking for it specifically. (Though this is a little less true now with metacpan.org, which lists BackPAN releases of a distribution alongside the ones still on PAUSE. Only once every release of a distribution is deleted off PAUSE does it become unlikely to be found by undirected search.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Seeking a suitable forum to discuss Scalar/List::Util
* Paul LeoNerd Evans leon...@leonerd.org.uk [2015-05-14 18:50]: 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. I agree that hesitation is warranted, but I don’t know that discussion is the remedy to the reason for it. You indicated to me previously that before you’d only consider adding features to these modules if they had been implemented and proven in other modules on CPAN. That seems like a sensible approach even when it comes to “feature requests” from yourself: an initial implementation in a module released separately to CPAN, to vet the interface and shake the bugs out of the implementation before it is considered for SLU. For experiments that succeed, if the code emigrates to SLU verbatim, it is even trivial to provide completely transparent migration to users of the pre-SLU version. So this seems to me the obvious and sensible answer to the issue. 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? Maybe cpan-workers, as suggested at the QAH as the venue for development and governance discussion for toolchain and high-upriver modules. SLU is certainly a match for that category. I’m interested in the discussion, am subscribed to all of these lists, don’t mind mail dupes if it gets cross-posted, and if another mailing list is set up for SLU I’ll sign up for that too. So whatever is all fine with me, I don’t care. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: =head1 SEEN ALSO BY
Hi Tim, * Tim Bunce tim.bu...@pobox.com [2015-04-04 13:25]: Independently of that, I'd love to see something like a 'mentioned by' page. It would list all other distros that mention (via an LFoo link) a module in this distro. d’oh – of course. It would look like the revese dependencies page. Or more to the point, “what links here” as seen in many wikis. Bonus points for also recording and showing the header of the pod section that the L was seen in. That was the first thought that popped into my head after the d’oh, too. :-) I like! Now someone’s just gotta do it… Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Test failing on Windows but not elsewhere
* Karen Etheridge p...@froods.org [2015-03-10 05:10]: Any time you include a path in a regex, you should surround it with \Q and \E. Those backslashes are going to bite you. :) Hmm. * Karen Etheridge p...@froods.org [2015-03-10 05:10]: Any time you interpolate a variable into a regex and its value is supposed to be just a string, you should surround it with \Q and \E. FTFY. It’s not just paths. (You don’t need to quotemeta *every* time of course – but you *should* reflexively stop and consider *whether* you need it, every time.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: name for a module that parces and compiles micro assembly language (MAL) into Mic-1 microinstructions.
* Jean Pierre Ducassou jpducas...@gmail.com [2015-01-14 23:20]: I've being using Parse::MAL as package name for some time and I wanted to check it before publishing it on CPAN. So it’s really an assembler? There’s CPU::Z80::Assembler as precedent, the only similar module I seem to find in cursory search. Seems a decent enough name. So, CPU::Mic1::Assembler? With “MAL” mentioned in the abstract so a CPAN search will find it? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Paging Andreas König… [was: throw away module namespace]
* Chris Marshall devel.chm...@gmail.com [2014-12-12 17:35]: I thought I read somewhere that there is a way to have a non-comittal CPAN module in the sense that there was a namespace that *would* allow one to delete a module rather than having it in perpetuity? IIRC there was a change to PAUSE recently in which uploading a dev release will no longer lay claim to an as-yet-unclaimed namespace. Unfortunately I am not having any luck finding the relevant postings to confirm or deny exactly what changed. But if that is the case then you could just upload every release as a development release until you have settled the namespace question. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Module name advice
* Ben Deutsch b...@bendeutsch.de [2014-09-18 20:20]: Text::Template::LocalVars FWIW, that was going to be my suggestion too. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: naming a new module
* Greg Lindahl lind...@pbm.com [2014-05-13 02:10]: We're open-sourcing our module that generates the basedomain of a hostname, i.e. ic.ac.uk or blekko.com. We need a name. These existing modules do the same thing, only slower, less completely, and less correctly: Mozilla::PublicSuffix Domain::PublicSuffix ParseUtil::Domain IO::Socket::SSL::PublicSuffix Net::Domain::Match Net::Domain::Regex Net::Domain::TldMozilla Here are some ideas for a new name: Domain::BaseDomain (possibly confusing with Domain::PublicSuffix) Net::BaseDomain Net::PublicSuffix Host::BaseDomain Host::PublicSuffix Net::Domain::PublicSuffix What say you, oh naming consultants? The functionality does not lend itself to an obvious keyword, but if you *do* know a keyword then it’s “public suffix”, so if you ask me the name should be some form of ::PublicSuffix. As for the choice of TLNS, Domain::PublicSuffix appears to be the sole thing under Domain::, and it doesn’t look like there is *anything* yet under Host::, so I’d be disinclined to go with either. And Net:: seems a bit too generic for this module, plus in general it *tends* to be for protocol implementations, when people aren’t randomly using it for all sorts of junk they consider net-related. But Net::Domain:: looks just fine. It’s specific enough, and going by the choices of the other authors of public suffix modules, it also seems like a namespace where other people will expect it. Furthermore all the *other* modules in that namespace are internet domain-related also, so the evidence says that Net::Domain:: universally communicates exactly the concept you want to refer to. And hey, it’s your lucky day: though several authors put their public suffix list modules in Net::Domain::, none of them have squatted on the preferable term, so it’s still yours for the grabbing. So, congratulations on your shiny new Net::Domain::PublicSuffix module. :-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Aliens depending on Aliens
* Paul LeoNerd Evans leon...@leonerd.org.uk [2014-01-09 20:30]:
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?
Well, so you have a pkg-config (et al) question, not an Aliens question.
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.
What he said:
* David Mertens dcmertens.p...@gmail.com [2014-01-09 22:20]:
Your build system can set environment variables that pkg-config
listens to, and then when Module::Build calls system('make'), those
changes to environment variables will carry through. […]
Furthermore, you can pass flags to the Makefile or any other of the
commands you `system`, depending on what they accept.
Furthermore, there is no reason you can't patch the build files after
unpacking them. Is this brittle? Absolutely!
If you do have to resort to this, it doesn’t even have to be brittle: if
you are shipping a tarball of the alien or downloading a particular of
it version during *.PL, you know exactly what’s in the tarball, so you
know exactly what your patch code will do.
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Aliens depending on Aliens
* Paul LeoNerd Evans leon...@leonerd.org.uk [2014-01-06 23:35]: 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. 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.) -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Best way to communicate changing the output of a module
* Yanick Champoux yan...@babyl.dyndns.org [2013-12-22 20:35]: Perhaps a saner middle-ground could be of introducing a new environment variable CPAN_NO_MAJOR_JUMP. Or just warn instead of dying. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: COMAINT on https://metacpan.org/release/String-Random
* David Cantrell da...@cantrell.org.uk [2013-12-12 20:40]: On Sat, Dec 07, 2013 at 02:38:46AM +0100, Aristotle Pagaltzis wrote: * Shlomi Fish shlo...@shlomifish.org [2013-12-04 15:30]: Well, git rebase did not work properly (too many silly merge commits for stuff that predates my contributions) but a semi-manual git cherry-pick appears to have worked well. git rebase --onto silug/master d601c5b shlomi/master Then a few `git rm -f META.yml git rebase --continue` later you???d???ve gotten what I think is just what???s in your pull request. Or simpler, turn your commits into a sequence of patches, clone the author's repo, apply your patches to the clone, issue pull request. Better IMO than playing git --russian roulette with its powerful but underdocumented tools for doing unusual stuff. … while turning the crank on your computer to keep the power going, sure, exactly. Unusual? Russian roulette? I do this sort of thing for breakfast, lunch and supper, never got seriously surprised, and I can get out of whatever botch might come out if I *do* try something out of the ordinary. Maybe precisely because I do this stuff constantly. Just to be sure that I wasn’t about to embarrass myself, I tried what I wrote up there before I sent the mail, using clones of the mentioned repos. Well whaddayaknow, Git did in fact do exactly what I expected it was going to. I really don’t get the fear. Be afraid of your tools and they’ll give you reason to be. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: COMAINT on https://metacpan.org/release/String-Random
* Nicholas Clark n...@ccl4.org [2013-12-13 11:20]: On Fri, Dec 13, 2013 at 10:11:09AM +, Nicholas Clark wrote: balls it up). And as long as you don't throw away the terminal output, push anything or run `git gc`, there's always about 30 days to recover from any mess* from the various internal reflogs. * Other than git reset --hard Bother, or git clean -dxf Or git checkout. There have to be a few more, basically any command that is willing to touch the working copy – while the working copy is already dirty – may potentially lose data. Anything that only operates on the object database or only accepts to touch the working copy if it’s clean, is 100% safe, since objects are immutable by design while they reside in the object database. (And you can turn GC off to ensure they stay there forever, which I do on my dev boxes (as opposed to central repo hosts).) The only thing that can happen is that the user lacks the experience to understand the state they put Git into, and how to change it (back, or in any other direction) – but not actual data loss. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: COMAINT on https://metacpan.org/release/String-Random
* Shlomi Fish shlo...@shlomifish.org [2013-12-04 15:30]: Well, git rebase did not work properly (too many silly merge commits for stuff that predates my contributions) but a semi-manual git cherry-pick appears to have worked well. git rebase --onto silug/master d601c5b shlomi/master Then a few `git rm -f META.yml git rebase --continue` later you’d’ve gotten what I think is just what’s in your pull request. -- git commit -m 'Just another Git hacker,' #Aristotle Pagaltzis // http://plasmasturm.org/
Re: Problem naming a module
Hi Philippe, there are two issues causing a problem with naming for this module: 1. very specific form of input required/expected (hash of weights) 2. tightly bound to a DSL as its API If you want to be descriptive then you simply cannot give a module like this a terribly generic name. To cover (2), you need ::Rules. To cover (1), you basically need to name all aspects: takes a hash, specifically one where the values are weights, and reduces it to a single value. So I ended up with Hash::Reduce::Weighted::Rules It’s a mouthful but seems necessary to accurately summarize the module. None of the names that omit any of these components felt satisfactory: whichever one you take out, the shorter name seems to describe a very different module. I did try to fit “Categorize” in there but it just isn’t specific enough to *replace* any component of the name, and if you just *add* it to the whole kit and caboodle, the name becomes ludicrous. So I left it out. So that’s the best I could do. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Unclear as to problem: Tried to register 'Types', but says can't due to unrelated module.
* Linda A. Walsh perl-didd...@tlinx.org [2013-11-13 16:20]: Unclear as to problem: Tried to register 'Types', but says can't due to unrelated module. And that didn’t make you stop and wonder, if you thought that this other author should not have claimed that namespace, that maybe the same could be thought of yourself by someone else? -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Unclear as to problem: Tried to register 'Types', but says can't due to unrelated module.
* Linda A. Walsh perl-didd...@tlinx.org [2013-11-14 04:25]:
Which would at least have looked better as:
elseif(SCALAR $refx || REF $refx)...
elsif (HASH $refx)...
https://metacpan.org/pod/Params::Util --- Use that.
There you go. Thread solved.
sub ARRAY (;$) {my $p = $_[0]; my $t='ARRAY';
return @_ ? ref $p eq $t : $t; }
sub HASH (;$) { my $p = $_[0]; my $t='HASH';
return @_ ? ref $p eq $t : $t; }
sub SCALAR (;$) {my $p = $_[0]; my $t='SCALAR';
return @_ ? ref $p eq $t : $t; }
Params::Util’s has better checks than those. (In terms of what it
checks. Not the level of copypaste, which doesn’t matter.)
Its name is better too.
You’ll do your other code a favour by adopting it and dropping your own
Types.pm.
So far the people who have not wanted it at the top level said that
before even knowing what it did.
And having seen what it does, that opinion stands.
If non-toplevel is good enough for Params::Util and Adam Kennedy then
it’s good enough for you.
Which – surprise – to people with experience was predictable before they
saw your code.
I don't think they'll change their minds, but who knows?
That’s OK, you won’t change your mind either.
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Jperl is bad name -;
* Jean-Damien Durand jeandamiendur...@free.fr [2013-10-29 19:00]:
I plan to write the engine itself using a internal JavaScript source
code translation into a Perl source code
Javascript::Transpiler?
--
*AUTOLOAD=*_;sub _{s/..([^:]*)$/()[print$1,(,$\/, )[defined
wantarray]]/e;$_}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: Jperl is bad name -;
* Jean-Damien Durand jeandamiendur...@free.fr [2013-10-30 01:00]: I liked - JavaScript::Transpile for its explicit namespace and play on words translate/compile (that's my interpretation, Aristotle) Not my coinage. https://en.wikipedia.org/wiki/Transpiler -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Please takeover HTML::Element::Library
Hi Terrence, * Terrence Brannon scheme...@gmail.com [2013-08-21 22:55]: I would greatly appreciate it if someone could takeover HTML::Element::Library. to reach more people than just the ones reading this list and reading it right now, you should log into PAUSE and give either either co-maint or ownership to ADOPTME. That marks the module as needing a new maintainer, so anyone looking at it can see, it will show up wherever such modules get listed (most obviously in [1]), and the CPAN admins know they can just pass it to whoever asks for it without needing to involve you. Cf. https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lancaster-consensus.md#flagging-abandoned-modules-and-modules-requesting-help [1]: https://metacpan.org/author/ADOPTME -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Please takeover HTML::Element::Library
* Aristotle Pagaltzis pagalt...@gmx.de [2013-08-22 04:23]: [1]: https://metacpan.org/author/ADOPTME Hmm, http://search.cpan.org/~adoptme/ seems better for this case… -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Proposal For A Module To Generate Regular Expressions
* Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org [2013-08-04 18:05]: There is already Regexp-Genex which portrays itself as a generator for regexes, but its functionality is different from your module, so it's a good idea to prevent confusion and avoid that overlap, generator. To generate is about as useful as the verbs do or process, anyway. How about Regexp-Methods? That seems to fit best given your description. Regexp::Methods is much more nondescript than Regex::Generator to me. From looking at that name, I would never ever come up with the right guess at the module’s actual purpose. I’d call this Regexp::Builder. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Alien::XXX needs something more
* Chris Marshall devel.chm...@gmail.com [2013-08-04 17:35]:
Maybe it would be useful to carve out OS specific packages under the
Alien:: moniker. What about Alien::Unix::libtermkey ?
Yeah, that’ll work great until the moment someone supports three OSes.
Or supports all OSes except a specific one. (Alien::NotVMS::FooBar?)
--
*AUTOLOAD=*_;sub _{s/..([^:]*)$/()[print$1,(,$\/, )[defined
wantarray]]/e;$_}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: potentially GD::Image::Filter::Simple ??
Hi Joshua, * Joshua Turcotte joshua.eric.turco...@gmail.com [2013-07-13 21:20]: […] image edge simplification algorithm […] To that end, one shot in the dark could be ..::Filter::Simple or Filter::SimpleEdge or something to that end. sounds to me like you want GD::Image::Filter::EdgeSimplify. I'm refactoring the algorithm currently to operate as a module rather than a script, and I'd like, if someone doth use GD::Image::Filter::WoopWoop; that they'd get the extended capabilities of GD::Image right along with it (rather than having to make the two play nice with each other themselves.) I don’t follow. Do you mean they should get a GD::Image that has methods for both algorithms, or something along these lines? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Naming/API for async-capable webservices modules
* Paul LeoNerd Evans leon...@leonerd.org.uk [2013-05-27 01:35]: On Sat, 25 May 2013 08:52:30 +0200 Aristotle Pagaltzis pagalt...@gmx.de wrote: That’s just what futures are for, I think? As in, they abstract the sync/async control flow out of the code. And you’re just putting that on top of one common HTTP client API pattern. It seems like discovery rather than invention to me. Oh sure - I didn't mean to suggest I'd invented the entire concept of using futures as control flow :) Simply, this particular arrangement of methods/API details, for solving this particular HTTP problem. I mean even the method and signature you chose, aside from returning a future, is already a common pattern… then again, in the traditional form that does not involve futures, its value feels more limited, more like a convenience. Involving futures somehow makes it feel more like a protocol than a pattern. In some sense what you’ve done feels trivial and other senses it feels significant, I just can’t quite put my finger on the particulars… Naming-wise I’d emphasise futures rather than IO::Async, natch. Oh indeedy. Does anything come to mind, though? Tricky, it seemed, because what are we naming and why? After sitting on this for a long time it finally occurred to me the approach that would make sense here would be to make this a role, which requires a `request` method and documents the expected interface. Your webservice wrapper module would take objects that do this role. The naming seems fairly easy then – HTTP::Client::Future perhaps? Maybe HTTP::Client::Role::Future if you want to be perfectly clear? (Actually on first read I thought you were asking about naming advice for your webservice wrapper module. On re-read now it’s not clear to me whether that was a hasty inference and you were already talking about an futures-based abstract API module… but it seems implausible that you’d be asking for naming advice for that? Though I dunno, maybe a case of programmer’s block? Anyway.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Naming/API for async-capable webservices modules
* Paul LeoNerd Evans leon...@leonerd.org.uk [2013-05-23 23:15]:
The whole module would work easily as well given any other type of
object with this API, including anything that is actually synchronous,
such as a tiny wrapper around LWP:
package LWP::FutureReturning;
use base qw( LWP::UserAgent );
use Future;
sub request {
my $self = shift;
return Future-new-done( $self-SUPER::request( @_ ) );
}
Hey presto - have I just invented a PSGI-alike API for writing
webservices / things that use web clients, that can work
synchronously, or asynchronously using IO::Async, POE, AnyEvent,
hardcoded poll(), etc...?
That’s just what futures are for, I think? As in, they abstract the
sync/async control flow out of the code. And you’re just putting that
on top of one common HTTP client API pattern. It seems like discovery
rather than invention to me.
Naming-wise I’d emphasise futures rather than IO::Async, natch.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Taking over maintenance of a module
* Matt Simerson m...@tnpi.net [2013-05-11 06:30]: I've noticed that quite a few modules have maintainers, who take over when an author goes AWOL. What is the process for for achieving that? http://www.cpan.org/misc/cpan-faq.html#How_adopt_module
Re: Make sure all the modules have the same version number in a distribution
* Dominique Dumont domi.dum...@free.fr [2013-02-16 09:45]:
As Perl module developer, I'm guilty as charged: I haven't found
a practical way to change $VERSION when a file has actually changed
:-/
Nor should you. One day I’ll write that article, one day…
--
*AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(,$\/, )[defined
wantarray]/e;chop;$_}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: Make sure all the modules have the same version number in a distribution
* Lutz Gehlen lrg...@gmx.net [2013-01-09 16:20]: On Tuesday, January 08, 2013 09:04:31 Gabor Szabo wrote: I just wanted to update a distribution and ensure that all the modules in a distribution have version number and they are all the same. Please excuse this digression, but would you be so kind to explain why you find this desirable? In my distributions, I deliberately only bump the version number of a module to the current value of the distribution when I modify the module. Like that I can easily see when I last modified a certain module. Applying the same version to all modules within a distribution is a non- obvious precondition for dependency resolution to work 100% reliably in all edge cases. I have notes for an article about it flying around here somewhere that I should really get around to writing and publishing. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: RFC: the Author:: namespace
* sawyer x xsawy...@gmail.com [2012-09-07 12:50]: On Fri, Sep 7, 2012 at 12:43 PM, Pedro Melo m...@simplicidade.org wrote: I would like to propose the Author:: namespace as a place for all of our personal modules that don't fit into any other namespace, for public experimental modules, and for author metadata. I don't understand why people upload things to CPAN that are specifically exclusively without-a-doubt on-purpose *just for them*? Neither DZPluginBundles nor Author::JRH::ContributingPolicy are “just for me”, they are necessary for everyone who might want to collaborate on the respective author’s modules. Giving these things one single home within the CPAN hierarchy would be an improvement on the current situation where they just exist anyway but are strewn all over the place and pollute the search results with no easy way for the CPAN search engines to hide them from people who aren’t looking for them (except by special-casing every single such namespace that has been established). * Alders Olaf o...@wundersolutions.com [2012-09-07 18:40]: On 2012-09-07, at 12:20, Dave Rolsky auta...@urth.org wrote: I think it's also worth noting that every extra upload has the potential to show up in search results. If the thing you're uploading isn't useful to anyone else but it shows up in a search result, you've just made the search result a little less useful. Very true. Although putting this stuff in its own namespace makes it easier to exclude from search results. I also don't find most of the author specific stuff to be useful, but if it has to be there it would be cleaner to segregate it into its own namespace. Funny, you swayed me. Coming into this thread (always playing the archæologist to other people’s parties as I am) I was thinking exactly what Dave wrote. But what you countered makes me realise that an explicit such convention would actually make search results better. The CPAN search engines would offer an “include Author:: distros” checkbox (off by default) and we would standardise on that for things like BeLike and DZPluginBundle. Then when looking e.g. for dzil plugins you would no longer get flooded with dozens and dozens of useless results. At the same time specifically looking for these things would get easier too. I like. It’s probably not gonna happen, but count me in favour if it ever does. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Text::TemplateLite syntax, was Re: Please help me name my text template module...
* Brian Katzung bri...@kappacs.com [2012-11-14 22:15]:
Here's what I would consider a typical use case for
Text::TemplateLite: nicely displaying the number of matches
returned by a query using Template and Text::TemplateLite:
# The Template Toolkit template:
my $tt_tpl = q{Your search returned [% IF m == 0 %]no matches[%
ELSIF m == 1 %]1 match[% ELSE %][% m %] matches[% END %].};
# The Text::TemplateLite template:
my $tl_tpl = q{Your search returned ??(=($m, 0), 'no matches',
=($m, 1), '1 match', $m' matches').};
# (Substitute ifel for ?? if desired)
Q.E.D.
The T:TL syntax has the benefit of being easily balance-checkable
in an editor such as vim.
“Non-programmers” “an editor such as vim”. I see. :-)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: module name for a tutorial or example or sample module
* bulk 88 bul...@hotmail.com [2012-06-08 03:20]: It only real purpose is to be copied into other XS modules and be studied from. What namespace should it go under? CopyPasta::FastHash? :-) In all seriousness, I would pick Example::XS::FasterHashes. Or maybe just Example::FasterXSHashes. XS:: seems the wrong place because the *main* thing about this module seems to me to be that it is not a library, just an educational example for XS authors. Module:: is definitely incorrect, because this has nothing to do with doing something with modules. Acme:: seems incorrect because to my mind it means “this is stupid or crazy but in any case inadvisable, yet still funny or cool, and I wanted to put it out there for people to look at”. And your code would clearly be out of place in such a category. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Continued life of my GitPan fork
* Buddy Burden barefootco...@gmail.com [2012-06-08 19:40]: Does anyone know of a possible fix for this? Do you have issues, wiki pages, or watchers that you don’t want to lose? If not it’s very simple: just delete the repo, create one with the exact same name, and do a git push. Otherwise it comes down to a GitHub question (how do I dissociate a fork from its original repository). Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: XML-LibXML's 2.* Versioning Scheme: Please Advise.
* Philippe Bruhat (BooK) philippe.bru...@free.fr [2012-06-01 01:25]: On Thu, May 31, 2012 at 08:12:37PM +0100, David Cantrell wrote: On Thu, May 31, 2012 at 10:49:36AM -0700, Jarrod Overson wrote: You lose the version's value as an actual number, but you gain more standard readability as to what the version means, which is something that I consider more valuable. You lose that the moment someone decides to rename Linux 2.6.bignum to 3.0 for no good reason. So really, no matter what the ideal, in practice it doesn't mean a damned thing. Which is why some people have moved to integer versions, based on the date, with extra digits tacked at the end to allow for multiple releases on the same day: a package released today would have the version 2012060101. (to be read as 2012-06-01 release 01). Which is why File::Slurp is now version .19 on the CPAN. If you’re going to use date-based versions I suggest V.YYmmNN as the format, with V being some arbitrary major version number. So e.g. the first release cut during May 2012 would be 2.120501. (I omit the day since a limit of 99 releases a month is reasonable but lengthening the version number by another 2 digits would not be.) Then you can change your mind about the versioning scheme without having to contend with 99.xx (or else abandoning the namespace so that you get to start over). Simply bump the major version to switch to another convention. You lose the easy intuitiveness of plain date-based versions, of course, and thus a major attraction, but you do retain the same information they provide (save for the exact age in days, which is meaninglessly precise in the grand scheme of things). Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Module naming: postifx/dovecot/MySQL configuration
Hi Avi, * Avi Greenbury li...@avi.co [2011-12-13 14:10]: To me, this obviously belongs somewhere in the Mail namespace, but I'm not really sure where it should go in that. I'm tempted to rename it to Mail::Postfixadmin, but I don't want to give the impression that it's somehow endorsed by that project. neither is Mail::vpopmail. https://metacpan.org/module/Mail::vpopmail#AUTHOR http://vpopmail.svn.sourceforge.net/viewvc/vpopmail/trunk/doc/AUTHORS?view=markup It’s the exception rather than the norm that a module on CPAN which interfaces with XYZ is written by the XYZ project/owners themselves. I’d argue for this name. It's currently called Mail::Vpostmail (since originally it was to be a postfix clone of the Vpopmail utilities and it must have seemed like a reasonable pun at the time). It made me think your module is about sending mail in some way… esp. so since you had just mentioned vpopmail. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: The CPAN Covenant
* Brandon Fosdick bfosd...@gmail.com [2011-11-21 06:30]: Escheat is a common law doctrine which transfers the property of a person who dies without heirs to the crown or state. It serves to ensure that property is not left in limbo without recognised ownership. That seems morbid, considering that death is neither the sole nor anywhere near the most common reason for maint bits to be transferred.
Re: The CPAN Covenant
* yan...@babyl.dyndns.org yan...@babyl.dyndns.org [2011-11-18 16:00]: On Fri, Nov 18, 2011 at 02:06:54PM +0100, Burak G?rsoy wrote: I think something like this must be standalone like Software::License. Attaching it to Dist::Zilla limits the audience heavily. Very good point. I'll extract the pledge wording itself to a separate distribution (CPAN::Covenant, CPAN::AuthorPledge, CPAN::Pledge?). Covenant seems much more appropriate a term than pledge since the author isn’t making a promise about action or behaviour, but is rather granting permission for such to be taken with his property. I think some extra qualification would be useful though. Only I can think of nothing that isn’t a mouthful. It’s about maintainer privileges, but how do you put that so it rolls off the tongue? “Author” is not exact. “Maint” came to mind but it sounds like it it might mean that you are making a promise to maintain the module, which is not the point. OwnershipCovenant is probably the most accurate, but ugh… Anyway, I’ll put the brush aside. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: The module authors pledge
* yan...@babyl.dyndns.org yan...@babyl.dyndns.org [2011-11-11 22:30]: On Thu, Nov 10, 2011 at 11:27:04PM +, Neil Bowers wrote: I think this would still have to be a mechanism that an author has to sign up to, rather than it automatically being applied. Considering the nature of CPAN, I tend to agree. Trying to force it everyone's throat would be the best way to quickly and utterly doom the project. And probably ensure to wake up one morning with a camel's head in our bed. :-) Or a severed one under your bed sheets…
Re: New module naming
* Trystan trysta...@gmail.com [2011-11-06 23:30]: I found this idea in Head First OOADhttp://headfirstlabs.com/books/hfooad/, chapter 5. It's somewhat like a very simple version of Key-Value Codinghttp://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1. It's also very similar to Object::Generichttp://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pmbut I didn't use AUTOLOAD and I implemented 'equals' and 'contains' methods in order to make the objects searchable within a container. Here's an example: my $a = tbd_name::Object-new(); my $b = tbd_name::Object-new(); $a-set( ID, tbd_name::String-new(1234a) ); $b-set( ID, tbd_name::String-new(1234a) ); print $a-get(ID); $a-equals($b) ? print yes; $container = tbd_name::List-new(); $container-add($a); $container-search($b); #which returns $a What do I call this thing? Uhm. So when would I ever use this over a simple hash?
Taking another swing [was: New module naming]
* sawyer x xsawy...@gmail.com [2011-11-07 12:40]: * Shlomi Fish shlo...@shlomifish.org [2011-11-07 18:45]: You shouldn't call lexical variables $a and $b: That was a completely pointless comment, Shlomi. Only in sending it to the list instead of as a private comment, and in his way of stating it – as a do-not instead of a suggestion, followed by the reason, followed by an off-topic disclaimer. In the opposite order it would have gone down easy. (OK: and if it didn’t come from Shlomi. Even if he gets better at tone now his reputation would haunt him.) This is a case where $a and $b makes absolute sense. It is also the same case as Perl's sort() function that uses $a and $b to indicate two values of the same importance. There is no real case in which `my $a` or `my $b` make sense in Perl, only a handful of cases where they don’t make no sense. I think his point was a reasonable one, if minor. * Bob Parker b...@perldevgeek.com [2011-11-07 21:30]: * Shlomi Fish shlo...@shlomifish.org [2011-11-07 09:25]: Well, I hope I didn't also make the same mistake (again). Yeah, you did. Quite frankly, I have been lurking on this list for years - first through the web then as an actual subscriber as I currently try to find time in my schedule to contribute a module that I finally believe to be worthy of adding to CPAN. I have seen a multitude of posts from you, Shlomi, and the vast majority of them have been of the them of I don¹t like the way you are doing it, because it's not the way *I* would do it, but I really don't have a better way of doing it myself to contribute. Nobody likes a know-it-all. But the perpetrators of drive-by ad hominems are popular? Particularly ones who come out of the woodworks to beat on the community punchbag after he has already apologized? Worse yet, nobody likes a know-it-all without the who doesn't have the credentials to back up their b.s. You made a mistake to bring up credentials. His have-to-fix-that attitude has driven Shlomi to pick up the upkeep chores of a whole raft of neglected high-profile CPAN modules, and there are quite a few perl patches to his name. Not all of them have been applied, bless his eager heart :-), but neither have all of them gone unappreciated. That looks like a lot more in credentials than you brought to the table. Sure, Shlomi suffers from overly rigid ideas of how to do things and is too eager to dismiss the “old” way along with all other options. But he isn’t stupid either, and he doesn’t just nitpick but contributes. Nor is he is in the habit of flaming people, much less talking about them without knowing who he is talking about. That’s a lot more than can be said about some people. In this particular case, pretty much everyone clearly understood that what was given was a GENERIC EXAMPLE, not real code. It didn't call for code review, comment or criticism on the use of variables or their naming. What was requested was feedback on the naming of the MODULE. His point was valid, clumsy though his way of stating it was. The abuse he invited with his clumsiness is out of all proportion for his sin. There is probably a reason why your suggestions are ignored, for everything from improving the perl.org site to redesigning the perl training documentation to ridiculous commentary like this. Dig deep and you can probably figure it out. A lot of them are ignored. A lot of them are not. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Politics Personalities - was Re: New module naming
* Bob Parker b...@perldevgeek.com [2011-11-07 22:15]: Perhaps you are a fan of the guy, perhaps not - I don't know you. Perhaps it doesn’t even matter. Perhaps you can be a decent person to someone you dislike. What I do know is that for the past several years, I have seen what should have been basic and common sense discussions degenerate into personality wars because of Shlomi Fish. So sue me if I have the balls to call him out on it. Note that I was not the first, I simply elaborated on someone else's comment. No. You had the no-balls to come out behind someone else and follow up on an apology by beating on him some more. Congratulations, I hope you’re proud. Frankly, I am tired of so many on this list acting like children. Me, me, me instead of perl, perl, perl. People getting blacklisted because they dare to speak their minds. Others, with totally valid and valuable contributions being totally ignored because their ideas are not popular. I *thought* that we had gone beyond this petty stuff. Clearly I was was wrong. Pot, kettle. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Taking another swing [was: New module naming]
* Bob Parker b...@perldevgeek.com [2011-11-08 00:30]: Clearly you are another fanboy of Shlomi's. You found me out. I am two days short of proposing gay marriage to him. * Aristotle Pagaltzis pagalt...@gmx.de [2011-11-07 23:50]: * sawyer x xsawy...@gmail.com [2011-11-07 12:40]: This is a case where $a and $b makes absolute sense. It is also the same case as Perl's sort() function that uses $a and $b to indicate two values of the same importance. There is no real case in which `my $a` or `my $b` make sense in Perl, only a handful of cases where they don’t make no sense. I think his point was a reasonable one, if minor. Once again, you too have missed the point. The original post was AN EXAMPLE. At now point was it intended to be usable code in which any reasonable person would be expected to literally use $a or $b. Thanks for pointing it out. I would not have realised this without your helpful contribution. In the real world people learn by copy-pasting code and tweaking until it seems to do what they wanted. Every code example should be as close to real working code as possible, ideally *should* be real working code; or else so broken (by missing declarations and what have you) that it cannot be made to work accidentally. Shlomi was nitpicking for the purpose of nitpicking Hip hip hooray for projection. so as to get his 2￠in there, not for the purpose of contributing to the conversation as it his known to do on a regular basis. In other words, he was stirring up trouble for no reason. No, I believe that was you. You provided no value WHATSOEVER – your comment contained zero technical content, which Shlomi’s at least did, even if it was off-topic. But you had to get your utterly worthless 2￠ in there. If this was anyone else BUT Shlomi, we wouldn't even be having this discussion. For whatever reason, you feel the need to defend him against the newcomer who dares to speak up against the status quo. I am not defending anyone. Shlomi was too brash, but then Sawyer was too, and then finally comes here someone whose grand debut consists in lashing out. Some entry. Welcome to you too sir. But the perpetrators of drive-by ad hominems are popular? Particularly ones who come out of the woodworks to beat on the community punchbag after he has already apologized? There was an apology? Start by reading harder next time. Worse yet, nobody likes a know-it-all without the who doesn't have the credentials to back up their b.s. You made a mistake to bring up credentials. His have-to-fix-that attitude has driven Shlomi to pick up the upkeep chores of a whole raft of neglected high-profile CPAN modules, and there are quite a few perl patches to his name. Not all of them have been applied, bless his eager heart :-), but neither have all of them gone unappreciated. That looks like a lot more in credentials than you brought to the table. Honestly, you don't know me or my credentials. No. You just made a point of pointing them out. You have seen exactly 2 posts of mine on this mailing list - the grand total my contributions to the list to date. You should be proud of yourself! Your track record so far is stellar. The reason I haven't contributed so far is because of back-biting, political, personal attacks like you have demonstrated so well here. To hell with furthering the cause of the language - let's form cliques and screw with those people who disagree with us, regardless of what they think. More projection. Why does the back-biting bother you so much when your grand act of entry to this list is to turn the dial to 11 on back-biting? I have followed the career of Shlomi over the years since he first appeared on the scene. His very first appearances were full of strife and controversy. Sure, he may have taken over some projects, but not without disagreement and/or opposition. I never eulogised him. I am just not going to let you get away with justifying your ad hominem by demonising him. Sure, Shlomi suffers from overly rigid ideas of how to do things and is too eager to dismiss the “old” way along with all other options. But he isn’t stupid either, and he doesn’t just nitpick but contributes. No, not exactly. Based on this early postings that were full of criticisms and nitpicks of the various perl.org sites, Shlomi had PLENTY to say about those sites that certainly qualified as nitpicking. Yes, he has contributed to CPAN. Goodie for him. CPAN contributes are not the be all/end all of a person's worth, however. Thanks for dismantling my point and missing all essence. My point was that he puts his money where his mouth is. He wants things a certain way; he works to make that happen. If you don’t like the way he wants things to be, push back. If he’s badgering someone who should be encouraged, take the badgered’s side. Lashing out at him achieves nothing but to turn the lists into the unpleasant places you made them out to be. Nor
Re: Taking another swing [was: New module naming]
* Bob Parker b...@perldevgeek.com [2011-11-08 04:55]: Aristotle you are, by your words and deeds in this thread, what was known in my days in school as a bully. Apparently age and so-called maturity has not changed that. Hating Shlomi does not justify bullying him and painting me as the bully for not letting you get away with it does not absolve you. At this point I choose to ignore you publicly and forego further response, because we have already taken up too much of the mailing list's time. Yes please. If you have anything further to say, you can say it privately. No thanks. -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Starting a module's history from gitpan
* David Precious dav...@preshweb.co.uk [2011-10-12 11:15]: Out of interest, did you try asking the original author whether he has a repo knocking around he'd be willing to share with you, so you can maintain history? That would be ideal. I'm not entirely sure that would be worth the effort, though; there's only 4 prior releases, and the real value in having the history in version control is commit messages with explanations of decisions made and stuff, which you won't have if you just have the snapshots of releases from gitpan. It’s still useful to be able to get diffs. And with git, keeping that extra history around takes no space to speak of. I don’t really see the point of *not* doing it, considering how little effort it takes with the tools we have nowadays. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Starting a module's history from gitpan
* Buddy Burden barefootco...@gmail.com [2011-10-12 22:00]: I didn't know if somehow GitHub would consider my repo to be a fork forever-more If you use the fork button in the web interface, it will. If you really don’t want that, you can avoid it by cloning the GitPAN repo with git, creating your a new repo on Github, and then switching the `origin` URL of your clone to your own repo URL and pushing it. and that might somehow have negative side-effects. Nah. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Lyle webmas...@cosmicperl.com [2011-09-13 02:05]: I wasn't going to reply to this, but as this thread has continued... I thought Arthur's point was so relevant and clear to the greater context of this (as he has continued to outline), that such as comment as Aristotle's could only be inspired by some kind of affinity felt towards Google. Maybe it's just because I work with a guy that gets his back up when you knock Google, that I read this as similar behaviour The only Google product I ever use if I can help it is their web search, and then only because all of the competitors are next to worthless in comparison. I wish someone were able to step up to Google on that front. I don’t even like how many people I correspond with with use GMail (though if you’re going to use webmail, there really is no other competent MUA – again the same problem as above), and my Google+ profile (which I only made after a dozen people added me using my email address and the milk was already spilt – thanks, guys) only says “If you haven’t added me then please don’t”. So much for your theory, then. I’ll still rather use encrypted.google.com than www.google.com. (On a distantly related note, my feelings about Apple run along very similar lines. I admire their products and wish I could use them but I refuse to be beholden to the company. So I can merely forlornly pine for a worthy competitor, though the outlook on that front is equally bleak as in Google’s case. Sigh. (Wasn’t the unfettered free market supposed to automagically be able to solve problems of this type? – Though now I’m stepping too far afield.[^1])) [^1]: On that note, though, if you who are reading this *do* love those companies, then please consider this line of argument on how you can best help make such companies better: http://robert.ocallahan.org/2006/02/choosing-sides_27.html http://lists.canonical.org/pipermail/kragen-tol/2011-August/000938.html Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Peter Pentchev r...@ringlet.net [2011-09-11 02:50]: I also wonder why is it that nobody has so far brought up another important consequence of using SSL, at least with a trusted certificate at the other end - protection from not just eavesdropping, but also man-in-the-middle attacks. Yes, it seems kind of... weird... to think of MITM attacks against MetaCPAN, but with just a little bit of further thinking, it's not all *that* weird - and now you've all started me wondering how difficult it would be to catch an HTTP file transfer of a previously unknown Perl module out of the air, hijack it, unpack the tarball, add a couple of lines to Build.PL (or Makefile.PL or whatever), repack it and pass it on down the line :) No, of course I'm not going to seriously sit down and write code doing that. Still... I really wonder why no one brought MITM attacks up yet :) I think in this particular scenario you mentioned, SSL is the wrong layer at which to solve the problem. CPAN clients download from the CPAN mirror network, in general. Some sort of code signing should be baked into them (in fact there is, but it has a number of problems in its current form that I don’t remember off hand, so that nobody is using it in anger). But more generally your point is a good one. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Arthur Corliss corl...@digitalmages.com [2011-08-28 21:40]: My humor was perhaps too subtle, since you didn't get the relevance of my reply. Google switching to SSL by default is as pointless as metacpan. In the former case it's the protection of delivery to/from an entity that not only doesn't have your best interest at heart, but has a business built on exploiting *your* information for *its* benefit. Utterly pointless. Protecting your communication with another party from third parties needs no justification whatever. It should be the assumed default that exceptions are made from, not the exception from the rule requiring proof. If I’m having a massive argument with my personal foe #1, the fact that I distrust this person on all conceivable levels does not make you welcome to eavesdrop on the conversation. It does not matter the very least bit how trustworthy the other party is: uninvited third parties have no business knowing what you do or do not say to the other party. In the latter case you have a search engine whose use is basically the retrieval of information based on *published* open source software, and highly published at that, given the world-wide replication of CPAN itself. What exactly is metacpan protecting? Is it that embarrasing that programmer Joe can't remember what module function foo was defined in? Can someone really derive significant benefit from witnessing Harry browse the API for WWW:Retrieval::LOLCats or what have you? That’s the “I have nothing to hide” argument. It does not matter how embarrassing it is or isn’t. Irrelevant. It’s much simpler: unless they want you to know (or it affects you directly in some undue manner etc. – insert reasonable qualifiers here), you have no business knowing. How yawn-worthy that information is makes no criterion. The one criterion that does apply is whether making the channel secure against you trying to find out is too expensive relative to its sensitivity. So far, MetaCPAN seems to be less than straining under the load, so I don’t see a justification to reconsider. We used to avoid SSL unless necessary because it was expensive. I agree with the engineers who are saying that it’s time to re-examine that as a default assumption – whether they are employed by Google or not makes no difference to me as far as that statement is concerned. So, regardless of the incremental costs of implementing SSL, *why* is the mandatory use of SSL even considered intelligent, rational, or any other way beneficial? I wasn't going to get involved in this thread, but the Google bait was too spot on to ignore. You won’t see me disagreeing that the concentration of power in Google’s hands is dangerous. But that’s a different matter, even though very important in its own right. Abolishing Google would not reduce the justification to secure communications. The two issues are independent – so the question you pose is entirely beside the point to the matter at hand. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Shlomi Fish shlo...@shlomifish.org [2011-07-29 13:25]: One reason I have not converted wholesale to metacpan is because it redirects all http:// requests to https:// . Very annoying. http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy *no additional machines* and *no special hardware*. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: *SSL/TLS is not computationally expensive any more*. […] Also, don't forget that we recently deployed encrypted web search on https://encrypted.google.com. Switch your search engine!
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Arthur Corliss corl...@digitalmages.com [2011-08-28 19:55]: On Sun, 28 Aug 2011, Aristotle Pagaltzis wrote: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy *no additional machines* and *no special hardware*. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: *SSL/TLS is not computationally expensive any more*. […] Also, don't forget that we recently deployed encrypted web search on https://encrypted.google.com. Switch your search engine! These comments are pretty funny once you consider that you're making a secure connection to an independent party who has a commercial and fiduciary responsibility to exploit every bit of data you give them. With friends like Google protecting your information, who needs encryption? ;-) --Arthur Corliss Live Free or Die Right, so just let everyone in any coffee shop or any other open network you connect to sniff all your traffic. Did you have an actual point? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Module::Build::Tiny
Hi, I find this module intriguing. In my understanding, the complexity of Module::Build piled up because the same tool tries to cover both installation and authoring use cases. I believe the Dist::Zilla approach is a better way to take care of authoring: a separate toolchain that can be as complex as the author would prefer. The installer can then be trivial, as indeed it should; as well as pure Perl – as indeed, it should. So Dist::Zilla plus the *idea* of Module::Build::Tiny seem to fulfil the original concept of Module::Build better than that module itself ever has. But is the implementation up to par? Essentially: if I’m using Dist::Zilla for authoring, what regular features not explicitly mentioned in MBT’s POD would I have to avoid? Do things like optional or build-/test-only deps work? (I’d assume these do.) Or can I assume that everything will work unless otherwise pointed out? I could answer this for myself if I had *exact* understanding of how much of the work falls upon the .PL at install time, and how many of the toolchain features are implemented in the CPAN client and thus unaffected by MBT’s minimalism. So the answer to that is what I’d like. (I’d also be interested in whether any omissions mentioned in the POD are design choices or the idea is to add them in the future, and which if so.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Using a better compression than .gz for one's CPAN modules
* Shlomi Fish shlo...@iglu.org.il [2010-11-26 22:05]: In any case, regardless of its age, xz does tend to compress better than bz2 and should also be faster. I know. I heard of it quite early and switched from bzip2 to xz for my database dumps and mail archives. That’s not the point of the quote though. New things are always better in some way. Why else would anyone make them? But things always exist in a broader context and it is rarely so straight- forward to find any of them superior on that level. That put aside sticking with an older solution may be preferable due to the better adoption ratios mentioned by David and others, but to quote George Bernard Show: The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.. ( http://en.wikiquote.org/wiki/George_Bernard_Shaw ). I agree with the notion. But let me ask how much pressure changing the compression format on CPAN would exert on the world to adapt itself to it. Note too the quote is written from the perspective of the world: no mention goes to the fortunes of the unreasonable man himself… Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Using a better compression than .gz for one's CPAN modules
* David Golden xda...@gmail.com [2010-11-28 22:45]: On the other hand, if someone wants to recompress all of CPAN into XYZ compression scheme and release their own client that deals with it (or patch cpanm or whatever), then they can have the benefits (and any resulting hassles) themselves. And note that distributions which ship packages for CPAN modules are effectively already doing exactly that. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Using a better compression than .gz for one's CPAN modules
* Shlomi Fish shlo...@iglu.org.il [2010-11-24 21:05]: Welcome to 2010. There are two kinds of fool. One says, “This is old, and therefore good.” And one says, “This is new, and therefore better.” —John Brunner Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Using a better compression than .gz for one's CPAN modules
* Andreas J. Koenig andreas.koenig.7os6v...@franz.ak.mind.de [2010-11-22 09:20]: Agreed, but since bzip2 support is already done we can welcome it when people actually use it. I am unwilling to encourage it but I won’t argue if someone wants to use it. And it can be a win for distributions with very large bundled data files so one might as well use it for them since the support exists. I just don’t want to see a campaign against gzip. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Using a better compression than .gz for one's CPAN modules
* Shlomi Fish shlo...@gmail.com [2010-11-19 19:55]:
here is a report on compressing Graph-Easy-0.70.tar with various
compression methods:
{{{
shlomif:~/progs/perl/cpan/Graph/Easy/trunk/Graph-Easy/TEMP$ ls -l
total 3420
-rw-r--r-- 1 shlomif shlomif 2160640 Nov 14 22:20 Graph-Easy-0.70.tar
-rw-r--r-- 1 shlomif shlomif 329197 Nov 5 12:24 Graph-Easy-0.70.tar.bz2
-rw-r--r-- 1 shlomif shlomif 416916 Nov 14 22:23 Graph-Easy-0.70.tar.gz
-rw-r--r-- 1 shlomif shlomif 270796 Nov 14 22:21 Graph-Easy-0.70.tar.lrz
-rw-r--r-- 1 shlomif shlomif 312844 Nov 5 12:24 Graph-Easy-0.70.tar.xz
}}}
As one can see, there are significant savings in size (and
bandwidth) by switching to .bz2 and .xz.
Where does one see that? I see some savings, but not significant
ones. You drop from 2 MB to 400 kb by using gzip, then a further
100 to 150 kb by using more unusual compression programs. Just
going to http://search.cpan.org/dist/Graph-Easy/ will pull down
more data than you just saved.
The initial savings is worthwhile, but the additional gains?
The era of 28.8 modems is long past. (And even in areas where
internet connectivity is bad, bandwidth is not the limiting
factor. You go from cell phone with data plan to satellite
internet to CD-ROMs delivered by truck: the scarce resource
becomes latency, not the bandwidth at any one instant.)
Gzip has 100% installed base. Even bzip2 does way worse; it has
100% installed base if you are looking at Linux and the 386BSD
family, but is way less commonplace elsewhere, esp. Windows. And
the other tools are only just making inroads on Linux. How long
until they’re as widespread as bzip2? How long until bzip2 is as
widespread as gzip?
How large is the total CPAN archive – 10 GB? Re-compressing all
of it now would yield a benefit of what, 3 GB? 4? Even 5 maybe?
As Dave said, it fits on a thumb drive already. And we’re not
even talking about re-compressing here, just about future support
for new distributions.
It’s gonna be a lot of work to iron out the entire tool chain to
support the newer formats; then it will take a lot of time until
the work trickles out far enough that people could start relying
on it.
For quite piddly gains, in absolute numbers.
I really don’t see the point. Gzip is Good Enough.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Looking for a name(-space)
Hi David, * David Morel dmo...@amakuru.net [2010-10-24 22:05]: Thanks for taking the time to have a look (if you have some time :) and for any useful suggestions (not even limited to naming, since I never had a chance to release anything yet). some prior art on the CPAN: http://search.cpan.org/dist/Schedule-RateLimiter/RateLimiter.pm http://search.cpan.org/dist/Data-Throttler/Throttler.pm http://search.cpan.org/dist/Data-Throttler-Memcached/lib/Data/Throttler/Memcached.pm The last one targets essentially the same problem space as your module, although it seems less powerful overall (with a somewhat simpler interface in exchange). I would say this does indeed belong in the Schedule:: TLNS. (Data:: is the “I have no idea where to file this” namespace in many cases.) BorderPatrol is a clever name, but unless you plan to expand it significantly to become more of a platform/framework, I still advise in favour of purely descriptive names over cutesy/brand/ marketing names. Those have become more common on CPAN in recent years, when once upon a time it was *all* about the descriptive names. They can work well for modules with a large scope, but I believe they are a hindrance for modules with narrower focus. So I would pick some name in Schedule:: that captures the mission statement for your module, especially as distinct from the other modules that already exist. Eg. something like AdaptiveThrottler (if I skimmed your POD right). Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: my $self = shift
* Johan Vromans jvrom...@squirrel.nl [2010-09-13 08:05]: Aristotle Pagaltzis pagalt...@gmx.de writes: You don’t want to reach inside an object just because it happens to be hash-based. Interesting. For Getopt::Long (that can take an optional hashref as its first argument) I got explicit requests from users to allow hash based objects as well. Don’t miss the crucial “just” in there. You may very well want to reach inside a hash-based object. Just by looking at the reftype you can’t know whether you’re supposed to, though. * David Cantrell da...@cantrell.org.uk [2010-09-13 15:40]: To say that you shouldn't if you're passed a hash-based object smacks of stupid parroting of religious dogma. It smacks of separation of concerns. What if you can take either a hashref or a path as a string, and someone happens to pass you a Path::Class object? You detect that it’s a reference, and it’s a hash. So you reach inside and end up doing something completely different from what the caller meant you to. Whoops. Or you try to code explicit checks for all the relevant permutations of tie, string overloads, hash deref overload, and a dozen other things. And/or maybe you add magic support for some popular modules like Path::Class. Or you just say `'HASH' eq ref $foo` and defer the problem to the object behind `$foo`, which can use UNIVERSAL::ref to declare its intent. And then things do exactly what you mean them to, in many more situations than before. However, the best way to see if what you've been passed is a hashref is to try de-referencing it, not to use isa()). That is OKish. Unfortunately it also breaks any caller who is `each`ing through any hash you are passed. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: my $self = shift
* Shawn H Corey shawnhco...@gmail.com [2010-09-10 14:30]:
On 10-09-10 03:02 AM, Eric Wilhelm wrote:
sub foo {
my $self = shift;
my $self = shift @_;
Always put the array in the shift.
Why?
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: my $self = shift
* Darren Chamberlain d...@sevenroot.org [2010-09-11 10:05]:
Template Toolkit (and several other modules) use this idiom:
sub new {
my $class = shift;
# allow hash ref as first argument, otherwise fold args into hash
my $config = defined $_[0] UNIVERSAL::isa($_[0], 'HASH') ? shift : {
@_ };
^
..
}
That’s incredibly horrible. It should at least be using `reftype`
instead of abusing `UNIVERSAL::isa`. But in fact it should be
using just `ref`. You don’t want to reach inside an object just
because it happens to be hash-based. Miyagawa and I struggled
with this in writing Hash::MultiValue and eventually he settled
for this: http://p3rl.org/Hash::MultiValue#NOTES_ON_ref.
Perl( 5) just doesn’t really provide semantics for distinguishing
interface from implementation there.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: my $self = shift
* Shawn H Corey shawnhco...@gmail.com [2010-09-12 23:15]: So you will never have experienced Perl programmers come up to you and ask, What does this shift do? It doesn't do anything; @_ is not set yet. Good Advice, #11905: “Now is the time in our program where you look at the manual.” Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Please advise before I submit to CPAN
* Ovid publiustemp-moduleautho...@yahoo.com [2010-09-10 08:20]:
From: Aristotle Pagaltzis pagalt...@gmx.de
I would write that
my $self = shift;
my ( $name ) = @_;
:-)
(To my way of thinking, the invocant is not a positional
argument, so I always pull it out of @_ with a `shift`,
whereas I unpack arguments using list assignment.)
Why does this matter? Aside from being able to do this a touch
cleaner:
sub foo {
my $self = shift;
my ($name) = @_;
$self-SUPER::foo($name); # if you're still using SUPER::
...
}
Yes, that’s actually specifically one of the reasons. But the
primary one is the same as any other convention, really, though:
it communicates to skimming reader that this is a method rather
than a function, at a glance. The `my $self = shift;` line is
much more distinct than tucking a $self away on the @_ line
(especially in the rare cases when it is with good reason not
even called $self).
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Storable Stream - Module namespace help
* Joshua ben Jore twi...@gmail.com [2010-08-10 01:55]: Further, I would highly discourage you from naming anything using Storable with Archive because absolutely no one should ever consider actually *storing* a Storable blob. If you keep one around then you'll be tempted to read it in a client version that didn't match what you created it with. That way lies madness. Good point. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Storable Stream - Module namespace help
* Joshua ben Jore twi...@gmail.com [2010-08-09 06:15]: I'd feel much better suggesting you consider streaming with YAML or JSON or something hand-rolled but anything but Storable. I would strike YAML from that list as well. Whereas JSON is great. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: The CPAN Definitive Tags Spec
* Shlomi Fish shlo...@iglu.org.il [2010-08-07 15:15]: There's an easy solution to this problem - have this tag retire after there hasn't been a new release in, say, 6 months. Or maybe we can call it something else. (By retire I mean that search engines, indexers, raters, etc. will ignore it, not that it will be physically removed from the META.yml). * Ovid publiustemp-moduleautho...@yahoo.com [2010-08-07 15:01]: On a related note, I've not made a new release of Sub::Override in 5 years because it's complete and apparently correct. Is it actively developed or not? Maybe I wasn't clear enough in the SPEC, but it wouldn't be def/active_dev because it's not constantly enhanced. What I meant by active_dev is that the module is constantly enhanced / expanded / etc. Oh ho. Shlomi, meet Mark Jason. Mark, meet Shlomi. http://perl.plover.com/yak/12views/samples/notes.html#sl-9 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Storable Stream - Module namespace help
* Marco Neves [ModAuthors] perl-module-auth...@knowhunter.cjb.net [2010-08-08
12:00]:
So, which name should I use for this small module?
First thing that popped into my head was Archive::Storable.
Now I can’t decide whether it’s perfect or silly.
--
*AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(,$\/, )[defined
wantarray]/e;chop;$_}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: The CPAN Definitive Tags Spec
* Ovid publiustemp-moduleautho...@yahoo.com [2010-08-06 23:50]:
I can't say I've really been paying attention here, but while
some tags (requires C compiler) seem like they might be
reasonable, other tags such as black_magic seem highly
subjective. And the source_filter tag seems to belong in the
black_magic category.
The ${OS}_only tags only seem haphazard and like a bad place to
put that information… why is there no `vms_only` or such? What if
something works on FreeBSD and Linux but not MacOS? Is MacOS
a true Unix?
It seems like a rather random collection.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Roles on the CPAN
* Ovid publiustemp-moduleautho...@yahoo.com [2010-07-26 21:35]: I'm thinking about writing a module which is merely a role (Moose::Role) which one must consume. While there doesn't appear to be a standard for this, I was thinking about trying to set a precedent and use the Does:: namespace. For example, if you want a upload a role which serializes things to YAML, you might call it Does::Serialize::YAML to make it clear it's a role to be consumed and not a stand-alone package. Verbs as namespaces usually read weird, and the objection regarding `with` is especially salient. I second TraitFor, or else just appending Role. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CPAN Testers, and {build,test}_requires.
* David Golden xda...@gmail.com [2010-05-11 15:40]: On Tue, May 11, 2010 at 9:04 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote: * Daniel Pittman dan...@rimspace.net [2010-05-11 05:00]: Also, the approach Dist::Zilla takes with the 'configure_requires' and 'build_requires' keys is to remove them when running on an older version of EU:MM. Is a better approach to add them to 'requires', but only on older versions of EU::MM, so that the generated code has those extra details on platforms that don't support the newer fields? By the time Makefile.PL runs, it is already too late to satisfy an unmet `configure_requires` dependency. There is simply nothing you can do on such old installations. That's correct but misleading. Newer EU::MM supports BUILD_REQUIRES and CONFIGURE_REQUIRES as arguments. Dist::Zilla generates a Makefile.PL that deletes those on older EU::MM to keep EU::MM from complaining about unknown arguments. That is still incomplete if you really want to be explicit about the conditions to which the deletion of these keys is relevant, owing to the fact that Makefile.PL was designed to do double duty for both end users and distribution authors. Dist::Zilla splits the distribution author parts from the end user parts of the toolchain, and confines Makefile.PL to the latter role. And to end users, only the `configure_requires` key in the dzil-generated META file is relevant, which cannot be emulated from within Makefile.PL. Dist::Zilla does correctly add configure_requires to META and the generated Makefile.PL has: use ExtUtils::MakeMaker 6.31; Yes, Dist::Zilla takes over the distribution author part of the toolchain responsibilities, and ticks all the boxes there. None of that is really relevant to the situation at hand, which is about a build requirement for Test::More not being met. Naturally, since it was a tangential inquiry that Daniel included in his post and Apocalypse didn’t address. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: When and how to throw exceptions?
* Ovid publiustemp-moduleautho...@yahoo.com [2010-04-09 08:55]: Buut ... that's why you want those exceptions in classes instead of as hash keys. Of course. Just saying that if you *do* consider too many exception classes a problem in need of a solution, then using a field as a message selection key would at least preclude the need parse. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: When and how to throw exceptions?
* Ovid publiustemp-moduleautho...@yahoo.com [2010-04-07 09:05]:
Presumably the format should try to determine the number of
conversions in the format and perhaps the alias could generate
a sub with a corresponding prototype like 'sub
throw_io_read($$)'. That might give you a touch of compile-time
safety. Haven't really thought too carefully about this,
though.
I think the best approach would be to tie String::Formatter into
Exception::Class, specifically its `require_named_input` and
`named_replace` options. To produce its message, an exception
class would pass its declared fields as format inputs. Then
resulting interface would look like this:
use Exception::Class (
'MyException',
'IOOpenRead' = {
isa= 'MyException',
alias = 'throw_io_open',
fields = [ qw( file mode errno ) ],
format = 'Cannot open %{file} for %{mode}ing: %{errno}',
},
);
You’d use that like so:
open my $fh, '', $filename
or throw_io_open file = $filename, mode = 'read', errno = $!;
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: When and how to throw exceptions?
* Lutz Gehlen lrg...@gmx.net [2010-04-09 01:55]: I think that an own class for each message might be a bit of an overkill. Why? I guess that could be addressed by allowing a hash of formats and then offering the throwing site to pick one of them by setting a special field. The key here is that you want to avoid a situation where catching code has to parse the error message. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Trimming the CPAN - Automatic Purging
* Graham Barr gb...@pobox.com [2010-03-26 10:20]: On Mar 25, 2010, at 8:42 AM, Barbie wrote: Lastly I would also personnally be annoyed if only the latest versions were available, as I often make great use of the diff tool on search.cpan.org. Having only the latest version renders that great tool redundant :( I use that too :-) and it is very annoying that some authors automatically delete previous releases when they upload a new one. Why does that have to be constrained by the current availability of modules? Couldn’t search.cpan.org simply not honour deletions? Would there be any serious reason against this? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Trimming the CPAN - Automatic Purging
* Nicholas Clark n...@ccl4.org [2010-03-28 18:20]: I'm missing something here, I suspect. Yes, you are. How can HTTP be more efficient than rsync? The only obvious method to me of mirroring a CPAN site by HTTP is to instruct a client (such as wget) to get it all. As Arthur has repeatedly pointed this out: by first fetching a transaction log from the remote end, then playing it forward from the last synch point. (This is essentially what CPAN::Mini already does.) It’s not very efficient protocol-wise, but it sure is rather cheap in terms of server I/O. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Trimming the CPAN - Automatic Purging
* Dana Hudes dhu...@hudes.org [2010-03-29 04:30]: Using http for this is inefficient It makes for slower file transfer because you keep rerunning path mtu probes and tcp slow start It makes extra socket handles opening and closing Errm, you missed the last decade. (HTTP/1.1 has keep-alive and pipelining and it’s 10 years old now.) In the case of CPAN you don't have to go the log route. If the mirror knows it last synch time it can use rsync to get the modlist et al and import to SQLITE then query by date to come up with the list of files to fetch -- via ftp. Say what? Stat via rsync to feed an SQLite database that drives an FTP transfer? Could you even possibly come up with a more Rube-Goldbergian construction? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Q about prerequisites
* cr...@animalhead.com cr...@animalhead.com [2010-03-25 18:00]: 1. Change 'LWP' to 'LWP::UserAgent' in BUILD_REQUIRES This won’t fix this problem, but you should do that anyway. Do not mention distributions. The CPAN client will figure out which distributions the user needs. Your job is to list the *modules* you require – every single one of them, regardless of what the distribution is called or whether several of them are part of the same distribution. Distributions can and do get split or combined. If you list modules, you will be unaffected by that: the CPAN client will simply figure out the right set of distributions to install regardless of how they’ve evolved since the time when your own code was released. It seems we have 3 categories: config_requires, build_requires, and requires, and it's not clear which of the last 2 applies to something required by a test. None of these, really. There should really be a `test_requires`. However, in absence of that option, what remains to be said is that both `configure_requires` and `requires` are more wrong than `build_requires`, so that’s what you should pick for now. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Prerequistie for Marpa::HTML
* Jeffrey jeffreykeg...@jeffreykegler.com [2010-03-22 00:50]: @Aristotle: Your two one-syllable answers were very useful. I realised afterwards that the mail reads somewhat gruff rather than (as intended) amused. Sorry. An obstacle for me was that Module::Build's actual behavior seems to contradict the documentation in Module::Build::API, which says of 'build_requires' that Modules listed in this section are necessary to build and install the given module, but are not necessary for regular usage of it. Read literally, that says that any module necessary for regular usage should never be listed under 'build_requires'. As far as I can tell the actual behavior of Module::Build would be more in accord with the following: Modules listed in this section are necessary to build and install the given module. If a listed module is necessary for regular usage as well as the build and install, the listed module also needs to be specified using the 'requires' argument. Right, it’s simply that one of these is for code that runs in normal operation and the other is for the code that runs during installation. If a module is needed at both times, it should be listed in both sections. It’s odd that adding to `build_requires` fixes any problem though. Older CPAN toolchains only understand `requires`, and many modules list all their dependencies there and do not even have a distinct `build_requires` list. To my knowledge those modules work fine. So your problem is a bit of a mystery. Hmm. (Nevertheless, your solution is the correct thing to do, so don’t go reverting it.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Prerequistie for Marpa::HTML
* Jeffrey jeffreykeg...@jeffreykegler.com [2010-03-18 13:00]: 1.) Is this to be expected when a new module (first non-developer release) is a prerequisite? No. 2.) Is my set-up still at fault? META.yml, which is created by Module::build has a Marpa: 0.100 line, which I hoped would suffice. Neither your Makefile.PL nor your Build.PL list Marpa as a requirement at all. It’s kinda funny that you go to extra effect to get Module::Build to hack it into the META.yml, by way of `meta_add`, when just listing the prereqs properly would make it do that automatically for you. What made you do that? In any case the result reported by the Testers is entirely to be expected, and is just what users will experience if they try to install your module with any CPAN installer: they’ll be forced to resolve the dependency manually before it will install. 3.) Is this a problem with some of the cpantesters setups. No. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: When and how to throw exceptions?
Hi Lutz, * Lutz Gehlen lrg...@gmx.net [2010-02-21 01:40]: 1) The first question deals with how to throw exceptions properly. In projects which ask for a more sophisticated way than just carping or croaking I use Exception::Class. However, in both cases the error message has to be assembled when the error is thrown. given that Exception::Class already provides a central place to define your exception hierarchy along with messages,… I don’t follow what it is that you need another central place for? 2) My second question is how thorough I should be about throwing exceptions. You don’t want to check each and every possibility. As you said, if nothing else, it might needlessly prevent clever uses of your code, and most of the time you don’t gain much anyway. My question is if there are any general guidelines how to decide what to check and what not (depending on my general security requirements) or do I have to perform some gut-feeling appraisal of efficiency vs. security? There are basically two ways for errors to propagate: downward and sideways. • Downward propagation means you got something from the user, and you just passed it down through to something else without checking it. This is easy to debug: that’s what stack traces are for. Maybe the user passed something bad into your code and your code blew up. Then the error won’t be reported in their code, but a stack trace will tell them which call of theirs it was where they passed something nonsensical that caused your code to crash. • Sideways propagation means you processed a value in some way, and then used or returned the result without checking if it’s good. Eg. first (try to) you turn a filename into a filehandle, then you blindly pass the filehandle to a function. This is hard to debug. The value that caused the problem is not a value passed down directly, it is the result of some computation whose intermediate states do not show up in the stack trace. The trace doesn’t tell you why that bad value got to be bad in the first place. You have to step through the code in a debugger or add print statements to track what happened. I’m sure you can already imagine where this is going: basically, you should check your own intermediate computed values, to ensure you don’t propagate error conditions sideways between parts of your own code. But if you operate on user input directly, and the operation can blow up, you can leave that input unchecked for the purposes of error reporting. (You might of course still want to check it for other reasons, eg. security. That’s a different matter.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Spam to CPAN Developers? (Fwd: Betonmarkets CTO position)
* Jonathan Yu jonathan.i...@gmail.com [2010-02-13 21:25]: Strange, I guess I haven't seen most of them due to Gmail's spam filtering. Sorry all for the noise. There haven’t been *that* many incidents, but it’s definitely nothing new. I’d say it’s roughly one big wave of specifically CPAN-targetted spam every… 1.5 years or so? I guess we’re doing OK, all things considered. But as I said, it’s a familiar scene nonetheless. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Can't cpan WWW::Mechanize
* Shawn H Corey shawnhco...@gmail.com [2010-01-13 13:35]: Rene Schickbauer wrote: Do you have a current version of the CPAN modules installed? Try install Bundle::CPAN And restart your shell. No, thanks. Last time I did that cpan never work again. I had to re-install the old version to get it back. And no, I'm not going to try again. How many times have you tried it? Just the once? I’ve done that dozens of times and never had a problem. It’s *supposed* to work. If it reproducibly breaks your setup, there’s a bug somewhere that needs to be fixed. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: satiating cpantesters
* Eric Wilhelm enoba...@gmail.com [2010-01-06 18:15]: But you didn't succeed because something's wrong The Makefile is not missing because the program crashed before it managed to generate one. It is missing because the program successfully determined that installation cannot proceed. The program succeeded. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
SQLite concurrency [was: Writing tests]
* Rene Schickbauer rene.schickba...@gmail.com [2009-12-13 19:25]: Also, there is the matter that - to my understanding - parallel access to SQLite with multiple programs may corrupt the database. Your understanding needs correction. In fact, it is an explicit design feature of SQLite to allow multiple processes to operate on the same database file concurrently. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: bug in Net::Cmd/how to do pop3s for gmail
* Rob Janes janes@gmail.com [2009-11-28 11:45]: The fix is a hack to Net::Cmd, my $select_ret = UNIVERSAL::can($cmd, 'pending') $cmd-pending ? 1 : select($rout = $rin, undef, undef, $timeout); Please do not write `UNIVERSAL::can($foo, $some_method)` for any other value of $some_method than `can`. It breaks polymorphism. Write `$foo-can($some_method)` instead. (And if the value is `can`, you probably want `Scalar::Util::blessed` instead.) Seems to me the IO::xxx api needs to handle this, but I'm not sure who to put this to. Any ideas what to do with this? Is there a better way to do this? 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. If it’s not, then a `pending` as in IO::Socket::SSL would have to be adopted ecosystem-wide. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
* O. STeffen BEYer ost...@gmail.com [2009-11-18 13:10]: One can see from these results that the XS version quite consistently runs approximately about 15 times faster than the PP version. This is flame bait? Why is this flame bait? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
* David Golden xda...@gmail.com [2009-11-18 16:05]: So creating/destroying Perl objects -- even just for things like argument passing on the stack -- is part of the cost of the flexibility of Perl. When that becomes a bottleneck in a tight loop, that's when XS becomes a potential option. That's not a knock on Perl -- that's just part of the design. It isn’t inherent in the language design. A tracing JIT runtime *could* make Perl go faster than compiled code. (Unfortunately the Perl 5 spec is perl, so there can be no other runtime, and the one we have cannot be retrofitted with a JIT any time soon. Bah.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: naming advice required
* Ryan Voots simcop2...@yahoo.com [2009-11-09 15:20]: I Thought the typical convention was to try to find some other root namespace to put things in rather than making yet another one? No one browses CPAN by namespace any more, so it hardly matters. Whereas I find the trend toward cutesy names problematic. Because ultimately what matters is that things be findable by sticking the obvious keywords into search.cpan.org. Github::Fork::Parent is quite acceptable by that criterion. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Repository links in META/Pod should be http://
* Burak Gürsoy burakgur...@gmx.net [2009-11-02 19:10]: (IMHO) I only care to download the repository only if I am interested in patching/developing the code. If I just want to take a peek I don't bother installing a VCS client and/or cloning the repo. You don’t, therefore no one else should? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
