Archive::Probe is a generic library to search file within archive.

It allows you to test the existence of a particular file, which can be described in regular expression, and optionally to extract that file and inspect the file content in custom code. It supports common archive types such as .tar, .tgz, .bz2, .rar, .zip, .7z. One archive file can contain archive file of same or other type. And level of nesting is unlimited. This module depends on unrar, 7za and tar which should be in PATH.

This is a fairly simple role to make it easy to add tree-related properties and methods to objects - providing methods for accessing parents and children, ancestors and descendants, etc. It's been split out into a separate package from a larger project (not yet on CPAN) - and couldn't see anything similar on CPAN to do this.

Any suggestions for a suitable name or does anything similar exist?

You know from the school that nothing is more simple than 2 x 2 = 4

You know from the university that it is the simplest operation for computer as well (left shift).

This module tries outperform and speed up even simplest calculations using all the power of your server CPU cores and familiar map conception.

time perl -Ilib -MParallel::parallel_map -e'parallel_map {$*2} 1..20000_000'

real 0m6.379s user 0m9.592s sys 0m2.026s

time perl -Ilib -MParallel::parallel_map -e'map {$*2} 1..20000_000'

real 0m3.120s user 0m2.901s sys 0m0.217s

Provided more cores (I have 4) and more memory to test something like time perl -Ilib -MParallel::parallel_map -e'parallel_map {$*2} 1..100000_000'

It would definitely outperform, especially latest Perl 5.16 etc. :)

Here is how it works:

1) finds out how many cpu cores you have,

2) splits map work by the number of cores,

3) do it in parallel and

4) after job is done by each thread it merges the results into array if it was called int list context. Otherwise it only calculates values and does not collect the results. That can be used as a parallel for loop.

Sorry, slightly more then 1-2-3.

Interprocess communication is done using plain old temporary files. so it should work everywhere where fork is implemented.

Although I have a benchmark that makes Perl crazy when it tries to make garbage collection under Win32 despite some small tests work perfectly. So there is no still heaven on Windows ;) .

Although it's not required, please install Sereal and File::Slurp. That way IPC is done much faster than using Storable capabilities.

If you have some long running script processing data item by item (having on input some data and having on output some processed data i.e. aggregation, webcrawling,etc) here is good news for you:

You can speed it up 4-20 times with minimal efforts from you. Modern computer (even modern smartphones ;) ) have multiple CPU cores: 2,4,8, even 24! And huge amount of memory: memory is cheap now. So they are ready for parallel data processing. With this script there is an easy and flexible way to use that power.

Well, it is not the first method on parallelizm in Perl. You could write an efficient crawler using single core and framework like Coro::LWP or AnyEvent::HTTP::LWP. Also you can elegantly use all your cpu cores for parallel processing using Parallel::Loop. So what are the benefits of this module?

1) because it uses input_iterator it does not have to know all input data before starting parallel processing

2) because it uses merge_data processed data is ready for using in main thread immediately.

1) and 2) remove requirements for memory which is needed to store data items before and after parallel work. and allows parallelize work on collecting, processing and using processed data.

If you don't want to overload your database with multiple simultaneous queries you make queries only within input_iterator and then process_data and then flush it with merge_data. On the other hand you usually win if make queries in process_data and do a lot of data processors. This guarantees full load of your cpu capabilities. It's not surprise, that DB servers usually serves N queries simultaneously faster then N queries one by one. Make tests and you will know.

To (re)write your script for using all processing power of your server you have to find out:

1) the method to obtain source/input data. I call it input iterator. It can be either array with some identifiers/urls or reference to subroutine which returns next portion of data or undef if there is nor more data to process.

2) how to process data i.e. method which receives input item and produce output item. I call it process_data subroutine. The good news is that item which is processed and then returned can be any scalar value in perl, including references to array and hashes. It can be everything that Storable can freeze and then thaw.

3) how to use processed data. I call it merge_data. In the example above it just prints an item, but you could do buffered inserts to database, send email, etc.

Take into account that 1) and 3) is executed in main script thread. While all 2) work is done in parallel forked threads. So for 1) and 3) it's better not to do things that block execution and remains hungry dogs 2) without meat to eat. So (still) this approach will benefit if you know that bottleneck in you script is CPU on processing step. Of course it's not the case for some web crawling tasks unless you do some heavy calculations

P.S. Please help me to improve documentation for this module. I understand my English is far from perfect and so probably is clarity of explanations. Thank you!

"If you have never uploaded a module to CPAN before, you are strongly encouraged to get feedback on PrePAN"

So, I Couldn't find any good module on Cpan for creating a simple landing page ("single web page that appears in response to clicking on a search engine optimized search result or an online advertisement" - From Wikipedia). Maybe what I create, could be useful to others?

The HTML::LandingPages offers a simple way for creating Landing pages (it even comes with pre made easy to use default template), a built in A/B testing for optimization, javascript support for ajax submission, and ability to store the "user records" as flat file or into database.

any feedbacks?

I haven't written this yet, but I was going to write a Perl interface to Instacode, the Instagram-clone for your code snippets.

Is there any interest in this, even though there is no API (and according to the devs, will never be an API) for uploading and creating photos?

Thanks!

Plack application wrapper for SOAP::WSDL module providing the SOAP::WSDL::Server interface.

This is mostly based on SOAP::WSDL::Server::Mod_Perl2 implementation and adapted for Plack.

With this module SOAP::WSDL is able to run as modern Plack/PSGI application beside mod_perl2 and CGI.

nrun will run a single command or script on a multiple of target servers synchronously. ncopy will copy a file or directory to multiple target servers.

the underlying remote access mechanism is exchangeable. as of now, ssh, nsh, rsh and local execution modes are implemented.

the return code and all command output will be logged.

I'm at a difficult crossroads and am looking either for namespace insight and/or assistance passing object/data from Image::Filter->newFromPng() to GD::Image for manipulation, and passing it back again as an Image::Filter object.

Namely, if I CAN do this (i've not yet succeeded) then my filter (in it's pre-c state) could live with and obey the API offered in the Image::Filter namespace (as it is, conceptually, a filter.) If not, it needs a different namespace and it's own simple api.

Off the top of my head, Image::Simplify, extending/wrapping the extensive functionalities within GD::Image for the purpose of enacting a single (and in perl, somewhat time intensive) algorithm I developed as a batch script some years back, that neats up and simplifies the borders between distinct indexed color regions (as one often gets with cartographic images, etc.)

This would be a straightforward Perl binding to the Houdini API, which offers some interesting characteristics (namely security and performance) as outlined in this blog post from Github, and the README.md.