I am fairly new to Perl. I did a lot with it in the mid 90s and came back about 8 months ago. There is a lot I dont know and probably a lot of things I have forgotten.

I picked up Perl to write a couple of applications that I was hoping could run on MacOS, Linux,OpenBSD, and Windows. Perl runs on all of them and many come with Perl built in. Simple scripts I have written run pretty well. (Lets forget about Windows for now).

When I start using libraries(packages?) there is a world of hurt.

Now some libraries pretty much usually work, but many do not. Which works and which do not seems to be dependent upon the operating system and distro.

Then I have to start with what version of Perl is running everywhere. That is annoying.

I end up spending a lot of time on a new machine when I want to run my application, doing nothing else than trying to get the libraries installed.

So I decided to adopt PerlBrew (havent tried it on OpenBSD yet) That should give me a stable version across the differnt platforms.

Then I decided I wanted to write a shell script that would handle installing all of the libarires I might use once and for all so I would know they were all accounted for.

perlbrew exec -q --with perl-5.40.0 cpanm install DBI

Then libraries I have pulled from CPAN do not work.

Google here and Google there.

Ok install GCC and make (I should have known this) More problems:

I found a few of these: "Why are you using CPAN for this? Use the compiled packages that come with <OS><type>"

Hmm I would have thought that CPAN shold be the best source? How do I know what exists as pre built packages on what platform?

Using apt search "perl" or "-perl" or "perl" does not help that much.

I have XML::LibXML working on Mac but getting it working on Ubuntu 22 I have been able to do. I have even tried to start OpenBSD yet)

Is writing cross platform applications in Perl meant to be this difficult?

Should I avoid libraries at all costs and write an aweful lot of code myself?

Is there an easy way to guess what libraries will almost certainly work and what libraries will most likely never work? Some kind of warning system?

Should I look into using pp? I havent yet figured out how to make it compile for Ubuntu,MacOs,OpenBSD yet.

In GoLang its a couple of flags to set for each architecture and off it goes.

ShouldI look into Par files? (or was it Far) that are supposesd to contain the nessescary libraries within itself?

What am I doing wrong?

Libraries in my current set Given all the experimenting some of them are now wrong.

Array::Set, Array::Unique, Bundle::LWP, Data::Dump, Data::Dumper, DateTime, DBD::SQLite, DBI, Digest::file, Digest::MD5, Digest::MD5::File, File::Basename, File::Compare, File::Copy, File::Find, File::Find::Rule, File::Glob, File::Path, File::Slurp, File::Spec, Image::ExifTool, Image::Info, IO::All, List::Compare, List::Gen, List::MoreUtils, List::SomeUtils, List::Util, List::UtilsBy, Log::Minimal, LWP, LWP::Simple, Path::Tiny, Term::ANSIColor, Text::Fuzzy, Type::Tiny,Moose,MooseX::Types,WWW::Mechanize

submitted by /u/NoeticIntelligence
[link] [comments]

You may have noticed the slow pace of Corinna development. As it turns out, there's an easy way to speed up the development: tell Paul.

I had a call with Paul "LeoNerd" Evans last night and this, including his email address, is being shared with his permission.

As you might imagine, being a core Perl developer, Paul has many things on his plate. Currently has has tons of PRs against the Perl core, he's doing new work such as experimenting with data checks (don't call them "types"!), and is active on the Perl steering council and in P5P. However, he's previously mentioned that he doesn't get much feedback on his work. For adding something as important as Corinna, just blindly adding it without hearing from the community is bad. Yes, we had a multi-year design phase and Corinna is much better for it, but that doesn't mean it's perfect and we don't want to screw this up.

So here's where you come in. Email Paul at leonerd at leonerd.org.uk. Tell him your thoughts about Corinna. He's he one implementing it and working in isolation as he is, despite his work with Object::Pad, isn't good. Tell him what you like, what you don't like, what you'd like to see next, what bugs you've encountered, and so on. Without hearing from you, he has no way of judging community thoughts/support for this project, so he needs your help.

If you'd like a quick refresher on the new syntax, I've written a short introduction. Here's a dead-simple LRU cache written in the new syntax:

use feature 'class'; class Cache::LRU { use Hash::Ordered; field $cache = Hash::Ordered->new; field $max_size :param :reader = 20; method set( $key, $value ) { $cache->unshift( $key, $value ); # new values in front if ( $cache->keys > $max_size ) { $cache->pop; } } method get($key) { return unless $cache->exists($key); my $value = $cache->get($key); $cache->unshift( $key, $value ); # put it at the front return $value; } } 

Pull requests · Perl/perl5

🐪 The Perl programming language. Contribute to Perl/perl5 development by creating an account on GitHub.

^GitHub

Blogpost about setting the #openmpl environment from within #perl

https://chrisarg.github.io/Killing-It-with-PERL/2024/07/01/Rudimentary-control-of-OpenMP-from-Perl.html

Other links:

1. Brett Estrade's presentation at TPRC

https://www.youtube.com/watch?v=_pzG5DerDT0

1. my companion entry at blogs.perl for https://blogs.perl.org/users/chrisarg/2024/07/parallel-perlc-applications-without-tears-using-openmp-controlling-the-openmp-environment.html

perl #openmp #parallelprogramming

submitted by /u/ReplacementSlight413
[link] [comments]

Intermediate OpenMP for Perl Programmers - Brett Estrade - TPRC 2024

#tprc2024 #perl #raku #openmp This is a sequel to my 2021 talk in Houston, “Introduction to OpenMP for Perl Programmers”. That talk covered the essential ele...

^YouTube

My job has led me down the rabbit hole of doing some scripting work in Perl, mainly utility tools. The challenge being that these tools need to parse several thousand source files, and doing so would take quite some time.

I initially dabbled in doing very light stuff with a perl -e one-liner from within a shell script, which meant I could use xargs. However, as my parsing needs evolved on the Perl side of things, I ended up switching to an actual Perl file, which hindered my ability to do parallel processing as our VMs did not have the Perl interpreter built with threads support. In addition, installation of any non-builtin modules such as CPAN was not possible on my target system, so I had limited possibilities, some of which I would assume to be safer and/or less quirky than this.

So then I came up with a rather ugly solution which involved invoking xargs via backticks, which then called a perl one-liner (again) for doing the more computation-heavy parts, xargs splitting the array to process into argument batches for each mini-program to process. It looked like this thus far:

my $out = `echo "$str_in" | xargs -P $num_threads -n $chunk_size perl -e ' my \@args = \@ARGV; foreach my \$arg (\@args) { for my \$idx (1 .. 100000) { my \$var = \$idx; } print "\$arg\n"; } '`; 

• No editor syntax highlighting (in my case, VSCode), since the inline program is a string.
• All variables within the inline program had to be escaped so as not to be interpolated themselves, which hindered readability quite a bit.
• Every time you would want to use this technique in different parts of the code, you'd have to copy-paste the entire shell command together with the mini-program, even if that very logic was somewhere else in your code.

After some playing around, I've come to a nifty almost-metaprogramming solution, which isn't perfect still, but fits my needs decently well:

sub processing_fct { my u/args = u/ARGV; foreach my $arg (@args) { for my $idx (1 .. 100000) { my $var = $idx; } print "A very extraordinarily long string that contains $arg words and beyond\n"; } } sub parallel_invoke { use POSIX qw{ceil}; my $src_file = $0; my $fct_name = shift; my $input_arg_array = shift; my $n_threads = shift; my $str_in = join("\n", @{$input_arg_array}); my $chunk_size = ceil(@{$input_arg_array} / $n_threads); open(my $src_fh, "<", $src_file) or die("parallel_invoke(): Unable to open source file"); my $src_content = do { local $/; <$src_fh> }; my $fct_body = ($src_content =~ /sub\s+$fct_name\s*({((?:[^}{]*(?1)?)*+)})/m)[1] or die("Unable to find function $fct_name in source file"); return `echo '$str_in' | xargs -P $n_threads -n $chunk_size perl -e '$fct_body'`; } my $out = parallel_invoke("processing_fct", \@array, $num_threads); 

My limited benchmarking has found this to be as fast if not faster than the perl-with-threads equivalent, in addition to circumventing the performance penalty for the thread safety.

I'd be curious to hear of your opinion of such method, or if you've solved a similar issue differently.

submitted by /u/Wynaan
[link] [comments]