I'm wondering if Devel::NYTProf can be used as a library in another library. I'd like to do something like the following
around 'somesub' => sub {
my $orig = shift;
my $self = shift;
start-timing;
$self->$orig(#_);
end-timing;
print '$time';
}
but from it's documentation I'm unable to determine if it can be used like this. Is it possible? could someone tell me the API calls that i'd do?
The simplest, most reliable thing to do is:
Add DB::enable_profile and DB::disable_profile calls in your library (you might want to check whether the subs are defined first, to avoid breakage when NYTProf isn't loaded).
Start perl with -d:NYTProf and NYTPROF=start=no in the environment.
All of this is pretty clearly explained in the Devel::NYTProf docs.
You could try having your library conditionally load NYTProf, but the deal here is that only stuff compiled after NYTProf is loaded gets any tracepoints. That might sound perfectly okay, since you only want to profile your library, but it's not clear what will happen if your library calls out (or calls back) to any other code, and I didn't test it. It's probably a lot easier to make the simple version make do :)
I don't think it can be used that way. But you might take a look at Aspect::Library::Profiler or Aspect::Library::Timer
Related
I really like the fact that with Mojolicious::Lite I have an overview of routes in one file like this.
get '/foo/#bar' => sub {
my $c = shift;
...;
};
get '/baz/#foo' => sub {
my $c = shift;
...;
};
However in some cases the subs in the file grow too long and complex, and I'd like to split them off, while still keeping the Lite approach.
What's the best way to do that? Is it by creating controllers like in a full Mojolicious app, or should I create helpers in separate modules, and use them?
I can't find pointers to this in the docs.
Having hit something similar, and assuming you're wanting to keep Mojolicious::Lite - the easy solution is to 'outsource' subroutines into packages/modules, that you then use.
You don't need to do anything particularly special though - with Mojolicious::Lite you need 'helpers' which are basically a way of designating subroutines.
You can skip that, and create a separate module that just has subroutines defined that you import.
E.g.
#!/usr/bin/env perl
use strict;
use warnings;
package ExtraStuff;
sub generate_a_value {
return 4; # generated by random dice roll, so guaranteed to be fair and random
}
1;
Then just use that in your Mojolicious app.
Works quite nicely for 'config' type stuff too, especially if you're reusing it.
I wouldn't suggest doing it for direct HTML generation - Mojolicious already handles that for you, and probably better - but rather just 'outsourcing' stuff that you might be doing via helpers instead anyway.
When you unpack a lite app, you end up with your routes defined in YourApp.pm, in the startup sub... like in the guide. Since you can still dispatch to code-refs by passing the to via $r->get... and friends, you don't lose anything of that by moving away from light.
The full layout does encourage use of controllers, but you really don't have to do that.
I often work on a huge, not-very-well-documented, object-oriented Perl repo at my place of employment. While maintaining the code, I frequently need to trace things that are inherited from other classes so that I can understand what they're doing. For example, I need to figure out what $self->mystery is and what it's doing:
package Foo::Bar;
use Moose;
use Method::Signatures;
use Foo::Bar::Element;
use Foo::Bar::Function;
use base qw (Baz::Foo::Bar);
method do_stuff ($some_arg) {
# mystery is not defined in Foo::Bar
my $mystery = $self->mystery;
$mystery->another_mystery($some_arg);
}
I usually find myself spending way too much time tracing through parent classes. So my question is, is there an easy way for me to figure out where $self->mystery comes from? Or in other words, I need to find where mystery is declared.
And by "easy way", I don't mean using ack or grep to string search through files. I'm hoping there's some sort of debugging module I can install and use which could help give me some insight.
Thank you.
Thanks to Standard Perl . . . the comes_from Method!
You don’t need to download any special tool or module this, let alone some giant IDE because your undocumented class structure has gotten too complicated for mere humans ever to understand without a hulking IDE.
Why not? Simple: Standard Perl contains everything you need to get the answer you’re looking for. The easy way to find out where something comes from is to use the very useful comes_from method:
$origin = $self->comes_from("mystery");
$secret_origin = $self->comes_from("another_mystery");
$birthplace = Some::Class->comes_from("method_name");
That will return the original name of the subroutine which that method would resolve to. As you see, comes_from works as both an object method and a class method, just like can and isa.
Note that when I say the name of the subroutine it resolves to, I mean where that subroutine was originally created, back before any importing or inheritance. For example, this code:
use v5.10.1;
use Path::Router;
my($what, $method) = qw(Path::Router dump);
say "$what->$method is really ", $what->comes_from($method);
prints out:
Path::Router->dump is really Moose::Object::dump
Similar calls would also reveal things like:
Net::SMTP->mail is really Net::SMTP::mail
Net::SMTP->status is really Net::Cmd::status
Net::SMTP->error is really IO::Handle::error
It works just fine on plain ole subroutines, too:
SQL::Translator::Parser::Storable->normalize_name
is really SQL::Translator::Utils::normalize_name
The lovely comes_from method isn’t quite built in though it requires nothing outside of Standard Perl. To make it accessible to you and all your classes and objects and more, just add this bit of code somewhere — anywhere you please really :)
sub UNIVERSAL::comes_from($$) {
require B;
my($invocant, $invoke) = #_;
my $coderef = $invocant->can($invoke) || return;
my $cv = B::svref_2object($coderef);
return unless $cv->isa("B::CV");
my $gv = $cv->GV;
return if $gv->isa("B::SPECIAL");
my $subname = $gv->NAME;
my $packname = $gv->STASH->NAME;
return $packname . "::" . $subname;
}
By declaring that as a UNIVERSAL sub, now everybody who’s anybody gets to play with it, just like they do with can and isa. Enjoy!
Are you sure you don't want an IDE? It seems to be what you are asking about. Padre, Eclipse EPIC, Emacs , and vim and many other editors offer some variation on the features you mention - probably simpler than you seem to want. If you have big project to navigate ctags can help - it's usually easy to integrate into an editor and you are allowed to hack on your configuration file (with regexes BTW) to get it to recognize bits of a complicated set of source files.
There is a related PERL FAQ entry about IDEs and a SO question: What's a good development environment for Perl?. There are also a host of CPAN modules you will want to use when developing that let you look into your code programmatically:
Devel::Kit
Devel::Peek
SUPER
Devel::Trepan
MooseX::amine / mex
...
You can see an example of a script that looks for methods in classes in the SO node: Get all methods and/or properties in a given Perl class or module.
You might be able to get tools like these to help you hop around in your source in a way you find useful from a shell or from inside the debugger. Trepan has a good short summary of debugging tools as part of its documentation. Generally though you can be very productive combining Data::Dumper the B:: modules (B::Xref , B::Deparse, etc., etc.) with the debugger and ack.
I find a module, that I want to change.
My problem have some features like this:
I want to add functionality and flexibility to this module.
Now this module solves tasks, but web-service, for what it was written, change API
And also, I want to use code of this module.
It is not my module
Fix some bugs
How i should be in this situation?
Inheriting from this module and add functionality and upload to CPAN?
Ask author about my modifications (and reload module)?
Something else?
There are various ways to modify a module as you use it, and I cover most of them in Mastering Perl.
As Dave Cross mentions, send fixes upstream or become part of that project. It sounds like you have the ambition to be a significant contributor. :)
Create a subclass to replace methods
Override or overload subroutines or methods
Wrap subroutines to modify or adapt either inputs or outputs (e.g. Hook::LexWrap)
Create a locally patched version, and store it separately from the main code so it doesn't disappear in an upgrade
For example, this is something I often do directly in program code while I wait for an upstream fix:
use Some::Module; # load the original first
BEGIN {
package Some::Module;
no warnings 'redefine';
if( $VERSION > 1.23 and $VERSION < 1.45 ) {
*broken = sub { ... fixed version ... };
}
}
This way, I have the fix even if the target module is upgraded.
I think that your a and b options are pretty much the best approach - although I'd probably do them the other way round.
Approach the module author with your suggestions. Read the module
documentation to find out how the author likes to be contacted. Some
like email, some like RT, other have more specific methods.
Authors tend to like suggestions better if they come with tests for
the new/changed code and patches that can be applied freely. Perhaps
the code is on Github. Can you fork it, make your changes and send
the author a pull request?
If the author is unresponsive, then consider either forking or
subclassing their code. In this case, naming is important as you
want people to be able to find your module as well as the original
one. You'll also want to carefully document the differences between
your version and the original one so that people can choose which
one they want.
I'm working on a fairly complex application written in Perl. I'm fairly experienced with the language, but I'm just stumped on this.
I'm using a module, Foo, which uses sysread and syswrite for various operations on a file-handle (a bi-directional socket, in this case) that I pass to its constructor.
I want to do the following: From another module I am writing, (let's call it Bar), I want to change the way that sysread/write behave only when called from within methods that belong to Foo
Sysread et al need to work as normal everywhere else. It can be safely assumed that the use of sysread will not change in Foo.
The reason I want to do this is that I need to track the number of bytes being read from/written to the afore-mentioned file handle. At this point, this seems like the only way I can get this information - basically saving the return value from sysread/write.
I have no problems using anything from the CPAN, as long as it's of good quality.
Update: I found a better solution to my specific problem, and have posted the code here:
https://github.com/Hercynium/Tie-Handle-CountChars
It seems to be working very well in my application, but I won't be posting it to the CPAN until I've more thoroughly tested it, plus written some actual unit tests :)
You could do this by creating your own Foo::sysread function, which wraps the core function by logging the return value. The wrapping can be done automatically (preventing you from having to mess about with the symbol table yourself) with Class::Method::Modifiers:
package Foo;
use strict;
use warnings;
# ... other code...
use Class::Method::Modifiers;
around sysread => sub {
my $orig = shift;
my $return = CORE::sysread(#_);
# do something with $return
return $return;
};
I'm currently refactoring a test suite built up by a colleague and would like to use Test::Class[::Most] while doing so. As I started I figured out I could really use a couple of Moose roles to decouple code a little bit. However, it seems it's not quite possible -- I'm getting error messages like this one:
Prototype mismatch: sub My::Test::Class::Base::blessed: none vs ($) at
/usr/lib/perl5/vendor_perl/5.8.8/Sub/Exporter.pm line 896
So the question is: can I use Moose together with Test::Class and if so, how?
PS: The code goes like this:
package My::Test::Class::Base;
use Moose;
use Test::Class::Most;
with 'My::Cool::Role';
has attr => ( ... );
Test::Deep (loaded via Test::Most via Test::Class::Most) is exporting its own blessed along with a lot of other stuff it probably shouldn't be. Its not documented. Moose is also exporting the more common Scalar::Util::blessed. Since Scalar::Util::blessed is fairly common, Test::Deep should not be exporting its own different blessed.
Unfortunately, there's no good way to stop it. I'd suggest in My::Test::Class::Base doing the following hack:
package My::Test::Class::Base;
# Test::Class::Most exports Test::Most exports Test::Deep which exports
# an undocumented blessed() which clashes with Moose's blessed().
BEGIN {
require Test::Deep;
#Test::Deep::EXPORT = grep { $_ ne 'blessed' } #Test::Deep::EXPORT;
}
use Moose;
use Test::Class::Most;
and reporting the problem to Test::Deep and Test::Most.
You can squelch particular exports via (for example):
use Test::Deep '!blessed';
I've just released an updated version of Test::Most. If you install 0.30, this issue goes away.
Folks finding this page might also be interested to know about the various Test::Class-Moose mashup modules:
Test::Able
Test::Sweet
Test::Class::Moose (not yet on CPAN)
With any of these some amount of refactoring would required-- the syntax varies. HOwever, with some amount of find-and-replace you may be able to make a fairly quick transition.