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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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/
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: 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/
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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'
