Inline::C is one of the most amazing modules out there. Not everything about its usage is simple as you'll need to have a decent grasp of the perl guts if you want to do anything beyond trivial - but it's not too bad either. I'm using it to speed up some objects, can't comment on how painful it would be to use it to bind to an external library (though that sounds like an amazing use case as well).
This is potentially an amazing module, and I would really love for this to work. However, there are currently some serious issues.
- Installation: I have managed to install this "sort of" on OSX, but it was a bit of a hassle. This module depends on a C library called sndlib, of which an old version comes packaged with the module. Because PDL::Audio is built against sndlib the compile and install procedure invokes the configure script of the packaged sndlib. I've had to hack this step a bit because for some reason it wants to use a preprocessor that it thinks is at /lib/cpp, instead of /usr/bin/cpp. Hopefully this can be made more portable and depend on a more recent version of sndlib.
- Configuration: I never managed to actually play audio, though writing to file works. Maybe this is just an OSX issue.
- Documentation: there are mistakes in the docs, and they are in any case completely impenetrable unless you know a decent amount of audio (DSP) processing theory as well as how PDL works. More, better documentation and more examples would be great.
- Interface: the interface is OK-ish. Basically, PDL objects are extended with DSP methods. It's good enough, though I'm trying my hand at wrapping this inside some friendlier packages so that I can build a modular synth. Toy examples of this appear to work (github.com/rvosa/synth)
- Ease of use: total headscratcher. Not at all easy.
- Overall: still love the potential. Please, please come with an update.
P.S. the other review seems to be a bit unhinged. In any case, it has nothing to do with the PDL::Audio module.
This is a very good module. One thing that threw me a bit is that "shape records" and "parts" use 1-based indexes. I assume there is a good (historical, maybe?) reason for this, but you must beware of this. Another thing that might be helpful if you're looking to use this is that you can query the *.dbf files that come with shape dumps using the XBase module. These are just observations from first time use - I happily recommend this module.
I'm confused. There appears to be no code here at all. Maybe some sort of super-brilliant abstraction? Dunno...
I was excited to see a Neo4j client library in my favourite programming language - and even more excited that it's written by Mark. Looking forward to playing around with it. The documentation looks very good, haven't tried the API in depth yet.
This is actually a really great module. Got it to work easily (on MacOSX 10.6.8), docs are good, and the underlying ANN is giving me pretty good results.
This is a very useful distribution: sometimes it's more memory efficient to code against the SAMtools API directly rather than running the samtools program. It helps if you are comfortable working with bioperl to get your head around this distribution, but it's not that hard to understand. Here's a blog post where I play around with it: biophylo.blogspot.nl/2013/06/assessin...
The principle of this module is very good, and it's very useful for simple XML. Having said that, round-tripping doesn't always work because:
* when encoding XML to JSON, the prolog <?xml ... ?> is encoded as @attributes that aren't bound to a valid root node (because they precede it), so that turning this JSON back to XML fails.
* xmlns declarations aren't encoded in the JSON, so that documents with multiple namespaces or unbound prefixes become invalid.
* the order of elements isn't alway retained.
I submitted a bug report about this five month ago, with no response. I note that the last upload of this module to CPAN was three years ago, so I doubt this will be addressed. Too bad as this could be a very useful module.
This module is an interesting idea in principle. It's yet more evidence to show that BioPerl is getting too big; hence alternative implementations are cropping up. On the downside, the exact differences between it and the Bio::DB::Taxonomy modules aren't entirely clear.
The documentation could be improved to clarify this, at which point the error (which is just a POD formatting error) that is showing up in the test reports could be addressed also.
It would also be handy if the interface mirrored that of BioPerl, so that it could be used as a drop-in replacement. And more tests should be added - if only to maintain the sanity of the developer/maintainer - right now, nothing of the actual API is being tested.
I am the author of Bio::Phylo. Thank you for your interest! Bio::Phylo is under active development. I hope you will find it useful for parsing, visualizing and transforming phylogenetic data.
This module would be a great asset to people on OSX, except it doesn't compile. I think I found a workaround for that though (see bug #35603). Unfortunately I doubt that the issue will be addressed as the second-to-last bug is two years old. YMMV.
One of the standard libraries in the perl tool belt, File::Spec is what you will want to use to chop up and concatenate paths portably. Don't assume forward slashes will just work everywhere and paste stuff together by hand, use File::Spec. Very useful module.
XUL::Node sounds like a wonderful idea for building server side xul applications. Xul is the xml application that is used throughout most mozilla-related projects such as firefox and thunderbird. The fact that users of the application only need to have firefox to access xul applications is very appealing.
I have some issues with XUL::Node, however. An api that is more explicitly tree-like (e.g. $parent->add_child( $widget )) would seem more consistent than the current, somewhat cluttered, interface. More serious for what I would like to use XUL::Node for is that it doesn't yet implement the xul tree widget. Finally, the install is fairly heavy, (including POE).
All in all, though, a great package. I would love to see this developed further.
Bio::NEXUS is currently the most advanced parser of (phylogenetic) nexus files on cpan.
This is a useful module that aids in bundling dlls/dylibs for distributing. It does this by calling 'pp', the PAR packer utility with modified arguments to link in the shared wx libraries. One complaint I have is that its dependence on PAR is not picked up by the cpan installer, and because it calls pp using exec you get silent failures.
Bundles are useful. A bundle is particular type of cpan distribution that doesn't, itself, contain any library code. Rather, it specifies what modules to install (and in what order). You want this in order to resolve dependency issues in modules with complicated prerequisites, such as, in this case, Tk.
(I have no experience with this particular bundle, I just vote here to average out the earlier downvote based on ignorance.)
This is a very handy module. Stable, easy to use. I use it to generate bundles from a source tree (with PAR). My only gripe would be the long namespaces, e.g. Module::Dependency::Indexer::makeIndex. Not sure if I can import makeIndex, so maybe the documentation is a bit ambiguous too. Overall a great module, though.