Re: New perl module feedback
Hi there! You can also publish it on http://prepan.org with a brief description and some example, and get some feedback there. On Mon, Apr 8, 2019 at 8:17 AM Аршак Мартиросян via module-authors < module-authors@perl.org> wrote: > Hey Perlers! > > I've come up with my own module for lookuping data structures in one > single line > without autovivification: > https://github.com/mat90x/perl-Data-Lookup > > Here, I found some alternatives: > https://metacpan.org/pod/Data::DRef > https://metacpan.org/pod/Data::Reach > https://metacpan.org/pod/Data::Diver > > But I find my module more 'lightweight' and neat. > > What do you think? Is it worth publishing? > -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
Re: [naming] To pragma or not to pragma?
Hello Dan, Ability to be lexical sounds like a terrific rule of thumb. Thank you! I changed to Module::Lazy which seems to fall in line with Module::Load and such. On Sat, Mar 2, 2019 at 11:02 AM Dan Book wrote: > On Sat, Mar 2, 2019 at 1:01 AM Konstantin S. Uvarin > wrote: > >> Hello, >> >> I'd like to release a module that lazy-loads other modules to reduce >> startup time. >> >> My initial idea was `lazy` but that was taken, so I switched to >> `on::demand`. There's also `autouse` with similar functionality. >> >> However, on second thought I'm not even sure if a lowercase name fits >> in here. It's certainly not as effectful as `namespace::clean` or `strict`. >> >> So the question is, what are the guidelines for deeming a module to be >> worth called a pragma? >> >> > Strictly speaking, a pragma is usually supposed to affect the lexical > scope it's imported to, rather than the package. "lib" has precedent of > doing neither and instead affecting global state, which is more similar to > your idea. I would say use whichever looks better to you. > > -Dan > -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
[naming] To pragma or not to pragma?
Hello, I'd like to release a module that lazy-loads other modules to reduce startup time. My initial idea was `lazy` but that was taken, so I switched to `on::demand`. There's also `autouse` with similar functionality. However, on second thought I'm not even sure if a lowercase name fits in here. It's certainly not as effectful as `namespace::clean` or `strict`. So the question is, what are the guidelines for deeming a module to be worth called a pragma? -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
Re: tools and work flows for developing collections of distributions
> > cd $bdir && perl Makefile.PL > > cd $bdir && make > > cd $bdir && make test > > cd $bdir && make dist > > 2018-11-21 13:49:07 dpchrist@tinkywinky ~/sandbox/perl > $ bash make-bundle.sh > + set -o errexit > ++ pwd > + tmp=/home/dpchrist/sandbox/perl/make-bundle.sh.tmp > + dists=DistA > + bundle=Bundle::MyBundle > + bdir=/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle > + > > bmod=/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/lib/Bundle/MyBundle.pm > + rm -rf /home/dpchrist/sandbox/perl/make-bundle.sh.tmp > + mkdir -p /home/dpchrist/sandbox/perl/make-bundle.sh.tmp > + cd /home/dpchrist/sandbox/perl/make-bundle.sh.tmp > + h2xs -XAn Bundle::MyBundle > + for d in $dists > + cd /home/dpchrist/sandbox/perl/make-bundle.sh.tmp > + h2xs -XAn DistA > + for d in $dists > + mv /home/dpchrist/sandbox/perl/make-bundle.sh.tmp/DistA > /home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/. > + perl -pi -e 's/=cut\n//' > > /home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/lib/Bundle/MyBundle.pm > + echo '=head1 CONTENTS' > + echo '' > + for d in $dists > + echo ' DistA' > + echo '' > + echo =cut > + cd /home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle > + perl Makefile.PL > Checking if your kit is complete... > Looks good > Checking if your kit is complete... > Looks good > Generating a Unix-style Makefile > Writing Makefile for DistA > Writing MYMETA.yml and MYMETA.json > Generating a Unix-style Makefile > Writing Makefile for Bundle::MyBundle > Writing MYMETA.yml and MYMETA.json > + cd /home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle > + make > cp lib/Bundle/MyBundle.pm blib/lib/Bundle/MyBundle.pm > make[1]: Entering directory > '/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/DistA' > cp lib/DistA.pm ../blib/lib/DistA.pm > Manifying 1 pod document > make[1]: Leaving directory > '/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/DistA' > Manifying 1 pod document > + cd /home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle > + make test > make[1]: Entering directory > '/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/DistA' > Manifying 1 pod document > make[1]: Leaving directory > '/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/DistA' > PERL_DL_NONLAZY=1 PERL_USE_UNSAFE_INC=1 "/usr/bin/perl" > "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef > *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > t/Bundle-MyBundle.t .. ok > All tests successful. > Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.06 cusr > 0.00 csys = 0.09 CPU) > Result: PASS > make[1]: Entering directory > '/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/DistA' > PERL_DL_NONLAZY=1 PERL_USE_UNSAFE_INC=1 "/usr/bin/perl" > "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef > *Test::Harness::Switches; test_harness(0, '../blib/lib', > '../blib/arch')" t/*.t > t/DistA.t .. ok > All tests successful. > Files=1, Tests=1, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.05 cusr > 0.02 csys = 0.11 CPU) > Result: PASS > make[1]: Leaving directory > '/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/DistA' > + cd /home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle > + make dist > rm -rf Bundle-MyBundle-0.01 > "/usr/bin/perl" "-MExtUtils::Manifest=manicopy,maniread" \ > -e "manicopy(maniread(),'Bundle-MyBundle-0.01', 'best');" > mkdir Bundle-MyBundle-0.01 > mkdir Bundle-MyBundle-0.01/lib > mkdir Bundle-MyBundle-0.01/lib/Bundle > mkdir Bundle-MyBundle-0.01/t > Generating META.yml > Generating META.json > tar cvf Bundle-MyBundle-0.01.tar Bundle-MyBundle-0.01 > Bundle-MyBundle-0.01/ > Bundle-MyBundle-0.01/Changes > Bundle-MyBundle-0.01/lib/ > Bundle-MyBundle-0.01/lib/Bundle/ > Bundle-MyBundle-0.01/lib/Bundle/MyBundle.pm > Bundle-MyBundle-0.01/t/ > Bundle-MyBundle-0.01/t/Bundle-MyBundle.t > Bundle-MyBundle-0.01/README > Bundle-MyBundle-0.01/Makefile.PL > Bundle-MyBundle-0.01/MANIFEST > Bundle-MyBundle-0.01/META.yml > Bundle-MyBundle-0.01/META.json > rm -rf Bundle-MyBundle-0.01 > gzip --best Bundle-MyBundle-0.01.tar > Created Bundle-MyBundle-0.01.tar.gz > > 2018-11-21 14:36:01 dpchrist@tinkywinky ~/sandbox/perl > $ tail -n 6 make-bundle.sh.tmp/Bundle-MyBundle/lib/Bundle/MyBundle.pm > > =head1 CONTENTS > > DistA > > =cut > -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
Re: tools and work flows for developing collections of distributions
Hello David, I recently asked a very similar question on Perlmonks: https://www.perlmonks.org/?node_id=1225608 The consensus among commenters was that I should just keep separate distributions and script whatever repetitive actions I have. But I still think that, as a side contributor, I'd rather encounter an explicit bundle rather than a standalone repo which is part of a hidden bundle at the author's laptop. I don't have a definite answer so far. So staying tuned on this thread, thanks for asking! On Wed, Nov 21, 2018 at 3:29 AM David Christensen wrote: > module-authors: > > I use h2xs, ExtUtils::MakeMaker, and make(1) on Unix-like platforms for > developing modules and collecting them together into a distribution. > > > I now have several distributions and would like to collect them together > into a unit (Bundle?), so that I can develop and test them together -- > e.g. ensure that changing one distribution does not break another > distribution. > > > Are there Perl tools and/or work flows to support this? > > > TIA, > > David > > p.s. Where can I find documentation that explains Bundles and how to > create them? > -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
Splitting a CPAN distribution in two
Hello, Sorry if this has been answered before, but I couldn't find anything... How do I split my CPAN distro in two? Say I have modules Foo::Core and Foo::Plugin in the same distribution, Foo. Over time, features accumulate and the plugin now has extra dependencies unneeded by most core users. How do I make plugin a separate distribution? Just publish it as Foo::Plugin with a version greater than that of Foo? Thank you, -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
[naminng] namespace::local - is it a good name?
Hello,
Preface. `namespace::clean` is a module that erases symbols imported prior
to its `use` line:
package Foo;
use Scalar::Util qw(blessed);
use namespace::clean;
blessed ($x); # ok
Foo->blessed; # nope, no such method
There are also namespace::autoclean and namespace::sweep (at least) in the
same `namespace` namespace.
Now after looking at namespace::clean I came up with a variation that
limits imports to its enclosing scope:
package Foo;
# no traces of blessed exist
sub uses_blessed {
use namespace::local;
use Scalar::Util qw(blessed);
blessed ($x); # ok
Foo->blessed; # nope, no such method
};
# no traces of blessed exist
See more at http://prepan.org/module/nYiS6m8kTir
However, I doubt about he name. Is it clear enough? Is it likely to clash
with something else?
Thank you.
--
Konstantin S. Uvarin
jabber: see
skype: kuvarin
http://github.com/dallaylaen
Is it ok taking the Refute::* namespace?
Hello, I would like to release a Refute or perhaps Refute::Contract module to CPAN. I used to name it Test::Refute or Test::Contract, but it's not actually a test module anymore. A refute( $reason, $comment ) is an inverted assertion: if $reason is a false value, it is assumed to pass; otherwise it fails, and the exact reason is already there! A $contract object represents a set of refutations and possibly other things (execution plan, sidenotes, subcontracts, etc). A contract is either fulfilled (refutations match plan), or failed. One can view a contract as a Test::More-based script encapsulated for being executed and queried inside production code. This setup allows for very easy building of arbitrarily complex assertions, err, refutations. For instance, is_deeply() can be recreated by simply passing a recursive diff of two structures to refute(). Now to the subject. Would it be fine to take up a whole top-level namespace, or should I stick to a humbler naming scheme like Assert::Refute? If I do take a namespace, what should I do aside from being concerned and posting here? Thank you, -- Konstantin S. Uvarin skype: kuvarin http://github.com/dallaylaen
Re: A funny module that shortens one-liners - is it worth global namespace?
Hi Aristotle, Thanks for the aliased link, looks like it covers the need, too. On Mon, Jan 9, 2017 at 2:43 AM, Aristotle Pagaltzis <pagalt...@gmx.de> wrote: > * 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' > -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
A funny module that shortens one-liners - is it worth global namespace?
Hello everyone, I've come up with idea or a module that shortens (mostly test) one-liners. E.g. we have something like perl -we 'use My::Very::Long::Module; $x = My::Very::Long::Module->new( foo => 42 ); print $x->foo;' 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;" It works well under strict, too. And it looks like it makes some sense - see this Perlmonks discussion: http://perlmonks.org/?node_id=1178455 However, I'm still unsure if the fun is worth putting into global namespace, and module name HAS to be short, otherwise it kills the idea. Maybe there's a way to get people to try it out first without polluting CPAN if it fails? Acme::n? github project w/o CPAN release?.. The module itself: https://gist.github.com/dallaylaen/206a649ea54db4c6db93e99a2e9514b0 Thank you, -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
Re: Suggestions about new perl module name
Hello Pavel and Neil, >From a quick CPAN search it looks like there's already Telegram::Bot and WWW::Telegram::(Something). So I second using one of these namespaces instead of a new one. Regards, On Mon, Nov 7, 2016 at 2:07 PM, Neil Bowers <neil.bow...@cogendo.com> wrote: > Hi Pavel, > > I made some bots for Telegram and decided to arrange common codebase into > module. > I called my project 'perlgram'. > Here it's https://github.com/pavelsr/perlgram > And this is example of bot based on module https://github.com/ > FabLab61/dt_bot > > What do you think, which package name would be better for publishing it at > CPAN ? > Is it ok to publish module under Perlgram name, like FindBin ? Or should I > add top-level hierarchy like WWW:: or Bot:: or API:: ? > > > In addition to Ron’s suggestion, the module-authors mailing list (copied > on this email) is a better place to ask for advice like this. > > And while I’m here, better then a Perlgram toplevel namespace, you could > go with a toplevel of Telegram::BotKit, or something like that, with your > distribution then being called Telegram-BotKit (note that the distribution > name needs to match the top-level module name). Then all modules in your > distribution would be inside the Telegram::BotKit::* namespace. > > Cheers, > Neil > > -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
Re: Naming stuff is hard.. Data::Topology::JSON
Hello, Does this module work on JSON-encoded data, or on a Perl structure achieved by decoding JSON? If latter is the case, then maybe the JSON part may be omitted altogether? Something like Data::Schema::Inferred? If it's JSON-encoded, I second Smylers' answer. On Mon, Oct 24, 2016 at 11:49 AM, Smylers <smyl...@stripey.com> wrote: > Aaron Trevena writes: > > > I don't have a clean-room data set I can use as an example right now, > > but essentially I'm parsing json, making a note of the names and > > hierarchy of the fields, using dot-notation (i.e. like mongo) to name > > nested fields, infer their type (i.e. ip address, mac address, epoch > > time, etc) from data, and get a sample of the data. From that I can > > then output a JSON::Schema or other documentation describing the data > > itself. > > If your module is Json-specifiec and there already exists a JSON:: > top-level namespace, then I think it's much better to put it somewhere > under JSON:: than Data::, which is so generic it tells users very little > about the module's purpose. > > How about JSON::Schema::Inferred? > > Smylers > -- > http://twitter.com/Smylers2 > -- Konstantin S. Uvarin jabber: see skype: kuvarin http://github.com/dallaylaen
Re: Top level name proposal - ComputeCluster
Hello everyone, In my opinion, ComputeCluster is way too long for a root module name. Plus, T9 in my head would type ComputerCluster instead. Maybe something like HighLoad:: or HPC:: would be better as a root name? Not sure though. On Fri, Sep 5, 2014 at 4:18 PM, John Macdonald john.macdon...@oicr.on.ca wrote: I generally think the name has to be useful for people to decide quickly whether it is useful or irrelevant to their purposes. A cryptic TLA makes it easy for the people who recognize it to decide that it is what they want, but makes it hard for people who don't know the TLA to decide that they can ignore it. HPC would be short to type and meaningful to the users, but would be a confusing noise to many others. *John Macdonald* Software Engineer *Ontario Institute for Cancer Research* MaRS Centre 661 University Avenue Suite 510 Toronto, Ontario Canada M5G 0A3 Tel: Email: john.macdon...@oicr.on.ca Toll-free: 1-866-678-6427 Twitter: @OICR_news *www.oicr.on.ca http://www.oicr.on.ca/* This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. -- *From:* Alex Muntada [alex.munt...@gmail.com] *Sent:* September 5, 2014 9:04 AM *To:* John Macdonald *Cc:* module-authors@perl.org *Subject:* Re: Top level name proposal - ComputeCluster What about HPC::? BTW, we have SGE at work too so this seems very interesting :-) Cheers! Alex
Guard objects with overall usage statisitcs
Hello, I'm willing to release another module to CPAN: Guard::Stat. It allows to create guard objects and gather overall usage statistics of those: how many are still alive, how many are gone etc. It was initially created for tracking down callback subroutines usage in an AnyEvent application but can really deal with any kind of subroutines or objects. The interface is rather simple: my $stat = Guard::Stat-new; my $guard = $stat-guard; # increase alive counter $guard-end(foo); # increase finished counter undef $guard; # increase dead counter $stat-get_stat; # alive = 0, dead = 1, total = 1, etc There are also broken() and zombie() statistics that show difference between DESTROY and end calls. running() count is for alive guards whose end() method was never called. Other features include: * If needed, time statistics can also be gathered through an external class (like Statistics::Descriptive::Sparse). * If needed, a on_level callback can be provided to do some action whenever running() counter goes above or below certain threshold. (E.g. defer incoming requests if load gets too high). The module is already used in-house and is more or less tested. My only concern is the name - is Guard::Stat a good one? Is it clear what the module does? Doesn't it occupy a sweet spot where another future module could fit much better? (Looks like stat() system call is not a resource one would build guard for). The code is available at github in case anyone is interested: https://github.com/dallaylaen/perl-Guard-Stat If no objections follow, I'll probably release it around July, 10. -- Konstantin S. Uvarin
Extending the API of Statistics::Descriptive::* (in my own module)
Hello everyone, I'm stuck with naming once again. I'm developing a module for approximate descriptive statistics. I'm trying to follow the interface of Statisitcs::Descriptive::Full as close as possible. As an exception, I've added central and standardized moments: central_moment($n); # == (x-x)**n std_moment($n); # == (x-x)**n/sigma**n -- but these seem unambiguous enough. (Or should I stick with standardized_moment() instead?) But now, I'm looking for a good name for a method that integrates arbitrary function over part of the sample. My current API looks like $stat-sum_of($coderef, $min, $max); # add up $coderef-($x) # for part of sample between $min and $max $stat-mean_of($coderef, $min, $max); # trimmed expectation # of $coderef-($x) $stat-integral_of($coderef, $min, $max); # integrate f(x)*P(x)*dx # where P is probability density (not done yet) Does sum_of(...) count as a good, descriptive name? What about others? Note: I'm NOT proposing any changes to Statistics::Descriptive itself! However, I'd like to be consistent with the rest of the pack (S::D::Full, S::D::Discrete, etc) for as long as possible in the future. -- WBR, Konstantin S. Uvarin
Re: How to name approximate descriptive statistics module
Hi Ron, Thanks for your answer! There is very rarely a perfect name for a module. The considerations you've mentioned indicate a good attempt to take past and future other module names into account. Often, that's the best we can do... The standard help for such matters is: http://pause.perl.org/pause/query?ACTION=pause_namingmodules I think your use of Bucket is not very indicative of what you module offers. I would not want it to give me buckets :-). How about Statistics::Descriptive::Approx? That makes sense to me because it indicates a close link to Statistics::Descriptive::Full while distinguishing itself by specifically stating what's different. That still leaves Statistics::Descriptive::ProbResampling. As for the length of the name, at this very moment I'm writing MarpaX::Demo::OldInterface::JSON. I've had a long think about this name, too, since there are already 2 other interfaces (BNF, Scanless), even though they as yet have no demos. The longest name in the disto will be MarpaX::Demo::OldInterface::JSON::Renderer::JSON. Such is life. It suddenly occurred to me that no more than a few modules providing exact statistics are needed. Thus the rest would some kind of space/time/precision tradeoff. So I can really use the Statistics::Descriptive:: namespace without worry. I would like to specify algorithm in the name instead of just approx, though. The Bucket part was a total mistake, it's great that I realized it. What about Statistics::Descriptive::LogScale? P.S. I'm crossposting to module-authors@ as Shlomi suggested in his reply to my initial post. -- WBR, Konstantin S. Uvarin
