It's easy to overlook the output during the build and install process, so I'd like to know if there is a way in NEST's python module to check for successful MPI integration?
There is no dedicated Python function for it (yet), but you can get it from the SLI statusdict:
>>> print(nest.ll_api.sli_func('statusdict/have_mpi ::'))
True
Related
I know pybind11 provides a way to call Python from C++. My question is, how can I distribute the application? For example, does user still need to install Python and Python packages on their machine?
I wish that if I use pybind11 , I can just put used Python scripts under my app folder, and called from C++. User doesn't need to install Python at all on his machine. Can pybind11 achieve this goal? Or can Python/C API or Boost.Python do that?
No, you'll have to install python. All of those packages, and ones like it, are language bindings between C++ and Python. Say you'd like to use a Python script in your C++ project and so you made some bindings for the Python script using Pybind11. When you run your C++ code, it'll use parts of the Python script which will be run in Python. What Pybind11 allows you to do is translate the input to and the output from the Python script, it does not reimplement it.
I have a module I'd like to release to CPAN, and I like using dzil to do the packaging and releasing. However, the module relies on an external application, and while I know where it is installed on my machine, I'd like to ask users to input where it is installed on their machine. Having read Prompt user during unit test in Perl I see ExtUtils::MakeMaker::prompt does just what I want to do.
How would I incorporate that (or something similar) when using dzil?
The standard MakeMaker dzil plugin has no support for anything but a basic Makefile.PL. (Well, it can use File::ShareDir::Install, but that's its limit.) If you need more complex install-time behavior, you'll need to use something else.
I recommend my MakeMaker::Custom plugin. You write your own Makefile.PL, which can do anything that ExtUtils::MakeMaker is capable of, including prompt for information. You can still have dzil add things like your prerequisites at dzil build time, so you can still use AutoPrereqs. (Actually, I recommend ModuleBuild::Custom instead, but if you want to stick with MakeMaker, that's ok.)
Note: You should also allow the information you're prompting for to be supplied on the command line. This will help people who are trying to package your distribution using automated build tools. But that's a MakeMaker issue, not a Dist::Zilla one.
The user should not be installing via Dist::Zilla at all. It is an author-tool only, as its documentation explicitly says. Dist::Zilla is meant to build a distribution that is installed via EUMM or M::B.
Edit: Given your comment, I would instead say, it sounds like your build process isn't a good candidate for using Dist::Zilla, at least consistently. I would suggest using it to build it once more and then move to using the EUMM or M::B that it builds, modify it to your purposes and keep developing that.
If you're using ExtUtil::MakeMaker to install your distribution, then you can use the dzil plugin Dist::Zilla::Plugin::MakeMaker::Runner (that's a mouthful) to bundle a custom Makefile.PL with your dist instead of generating the default one.
That will allow you to use prompt to gather custom information from within the Makefile.PL if you need it.
I am currently working on a Mojolicious app using TDD on my Mac and I am getting a bit fed up of having to manually run my tests every time I change some code.
After doing some Rails development, I really started to like the automatic response I got from the autotest gem, and as wondering it there is a Perl equivalent or if there is some way to use autotest with Perl.
One possibility is the Test:: Continuous suite. It includes the autoprove command, which reruns the test suite after source file updates:
% sudo cpan Test::Continuous
% cd MyModule/
% autoprove
The Test module is your friend.
Take a look at Test::Simple too, or go take a look at all of the various Test modules at http://perldoc.perl.org/5.8.9/index-modules-T.html. If they're listed here, they're all part of the standard Perl distribution. In fact, if you write CPAN modules, you have to write a test suite using these Test modules to go with it.
I need to install a perl tool on a production server which has no compiler. I can install CPAN distributions fine via local::lib, but the lack of compiler means I have to ask the sysadmins to install further modules. Due to them having an average turnaround time of 1-2 weeks even for the most ridiculously simple tasks, the process of trying to install, asking them to install what's borked, trying to install again, etc. etc. is extremely painful.
So how can i figure out quickly which given dependencies of a dist require a c compiler, so i can just give them a list?
When you search for a module in CPAN at http://search.cpan.org, take a look at the far right side of the browser window. Over there you'll see a link called Dependencies. This is right below the link to download the module.
If you click on that link, it'll take you to http://deps.cpantesters.org which will show you the dependency tree for that module. For example, take a look at this one for File::Spec at http://deps.cpantesters.org/?module=File::Spec&perl=5.12.1&os=any+OS&pureperl=on&devperls=on.
It's not perfect, but it'll give you a good idea what modules you do need.
The best way is to use the cpan command or the ppm manager on Windows. These will automatically download the dependent modules.
Maybe you could just install all you need on a test server and then package the application along with its dependencies using PAR?
As David said, cpantesters tries to figure out if a module is "pure"..
their explanation on how they do this might be helpful ..
Or I guess you could just install the modules on a similar system and copy them over? Or is this against the "rules"? ;)
Figured out a solution:
Trace system calls with Technet ProcMon (for Windows) or strace on Linux, then run the test suite and filter the result for "/auto/". That way you'll see all dlls it tries to load and can work out the dists requiring a compiler from there.
I have an app that I pack into "binary" form using PerlApp for distribution. Since my clients want a simple install for their Win32 systems, this works very nicely.
Now a client has decided that they need to run all unit tests, like in a standard install. However, they still will not install a normal Perl.
So, I find myself in need of a way to package my unit tests for operation on my client's systems.
My first thought was that I could pack up prove in one file and pack each of my tests separately. Then ship a zip file with the appropriate structure.
A bit of research showed that Test::Harness::Straps invokes perl from the command line.
Is there an existing tool that helps with this process?
Perhaps I could use PAR::Packer's parl tool to handle invocation of my test scripts.
I'm interested in thoughts on how to apply either PAR or PerlApp, as well as any thoughts on how to approach overriding Test::Harness and friends.
Thanks.
Update: I don't have my heart set on PAR or PerlApp. Those are just the tools I am familiar with. If you have an idea or a solution that requires a different packager (such as Cava Packager), I would love to hear about it.
Update 2: tsee pointed out a great new feature in PAR that gets me close. Are there any TAP experts out there that can supply some ideas or pointers on where to look in the new Test::Harness distribution?
I'm probably not breaking big news if I tell you that PAR (and probably also perlapp) aren't meant to package the whole test suite and plethora of CPAN-module build byproducts. They're intended to package stand-alone applications or binary JAR-like module libraries.
This being said, you can add arbitrary files to a PAR archive (both to .par libraries and stand-alone .exe's) using pp's -a switch. In case of the stand-alone executable, the contents will be extracted to $ENV{PAR_TEMP}."/inc" at run-time.
That leaves you with the problem of reusing the PAR-packaged executable to run the test harness (and letting that run your executable as a "perl"). Now, I have no ready and done solution for that, but I've recently worked on making PAR-packaged executables re-useable as more-or-less general purpose perl interpreters. Two gotchas before I explain how you can use that:
Your application isn't going to magically be called "perl" and add itself to your $PATH.
The "reuse" of the application as a general purpose perl requires special options and does not currently support the normal perl options (those in perlrun). It can simply run an external perl script of your choice.
Unfortunately, the latter problem is what may kill this approach for you. Support for perl command line options is something I've been thinking about, but won't implement any time soon.
Here's the recipe how you get PAR with "reusable exe" support:
Install the newest version of PAR from CPAN.
Install the newest, developer version of PAR::Packer from CPAN (0.992_02 or 03).
Add the "--reusable" option to your pp command line.
Run your executable with the following options to run an external script "foo.pl":
./myapp --par-options --reuse foo.pl FOO-PL-OPTIONS-HERE
Unfortunately, how you're going to teach Test::Harness that "./myapp --par-options --reuse" is a perl interpreter is beyond me.
Cava Packager allows you to package test scripts with your packaged executables. This is primarily to allow you to run tests against the packaged code before distribution. However the option is there to also distribute the tests and test capability to your end users.
Note: As indicated by my name, I am affiliated with Cava Packager.