Skip to main content



Does anybody remember this phrase featuring in an old story about clueless admins who banned Perl? Phil Pennock on the zsh dev mailing list knew the phrase in 1999 but I can’t find any other references to it zsh.org/mla/workers//1999/msg0…

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




Okay, so this is going to cross some borders about where the issue might be... I'm not sure where the issue is, but hopefully someone might at least have a thought.

I long ago started writing an AFP client stack in Perl. Yes, I did that. The question isn't if that's possible. (If you're interested in seeing it, it's [https://github.com/demonfoo/afp-perl](here).)

When trying to run the code on UN*X platforms (Linux, macOS, *BSD, Solaris/OpenIndiana), it works well. I've even added sendfile() support for uploading, for the platforms that support it. Over my home network, from my Linux machine to my TrueNAS Core NAS, I can transfer data over 10GbE at 5-6 Gbps. So I like to think it's pretty efficient... but Windows is a whole other world of pain.

I've recently been optimizing it, and Devel::NYTProf has been very helpful. I'd tried running it on Windows in the past, and running into issues. I originally thought it might be an issue with Perl threads (yes, it's using those too...), but based on profiling, it's not. It sends a command packet, which is just 36 bytes long, which apparently Windows' TCP stack doesn't much appreciate. It sits there for a really long time waiting for the command data to send while uploading, and I'm not sure why; using Sys::Sendfile, which wraps the Win32 TransmitFile() function, takes 5x less time for some reason, even though each call to it sends 512 KiB. And yes, I am disabling Nagle's algorithm, and setsockopt() seems to indicate it worked.

Thoughts on what I'm doing wrong?

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




Hello everyone. We are writing a little script that sends a mail to a collegue or department in case of sickness. We have a website that we host that can also be accessed remote with a form to fill out.
Our problem is after trying some things that the Mail arrives with no Subject. The subject is always empty and we dont understand why. Any idea? Here is most of the Script:

if (eingabefehler() == 1) {
print $cgi->header(),
$cgi->start_html('Krankmeldung nicht abgeschickt!'),
$cgi->h1('Bitte alle Eingabefelder ausfüllen');
print $cgi->end_html();
}
else {
$abt = $cgi->param('abt');
$smtp = Net::SMTP->new('cluster.xx.xx',Timeout => 30);
$smtp->mail($ENV{USER});
switch($abt)

{

 case "xx" { $smtp->to('mail.address'); ) 

}

$smtp->cc('mail.address');

$smtp->mail($ENV{USER});

$smtp->data();

$smtp->datasend("From: Krankmeldeformular\n");

switch($abt)

 { 

case "xx" { $smtp->datasend("To: person"); }

}

$smtp->datasend("Subject: Krankmeldung\n");

$smtp->datasend("\n");

$smtp->datasend("Name: ",$cgi->param('name'),"\n\n");

$smtp->datasend("Datum: ",$cgi->param('datum'),"\n\n");

 switch($abt) 

{
 case "xx" { $smtp->datasend("department \\n\\n"); } 

}

$smtp->dataend();

$smtp->quit;

print $cgi->header(),

$cgi->start_html('Krankmeldung abgeschickt!'),

$cgi->h1('Mail versendet');

print $cgi->end_html();

}

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






SlapbirdAPM now generically supports DBI!Hey friends, a few weeks back we introduced SlapbirdAPM (an open-source Perl application performance monitor), and received some great feedback from the community!

Today we'd like to announce that you are now able to track DBI queries in your applications (only available for Dancer2 and Mojolicious for now), regardless of your database, ORM, etc. Here's what it looks like! You can see the dancer2 code that generated these queries here.

preview.redd.it/l2jvz1bne8nd1.…

This is just one of the many monitoring features provided by SlapbirdAPM, hopefully you find them as useful as we do! And a reminder we have a *forever* free tier available for everyone!

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



Since the language formerly known as Perl 6 has officially gone off on its own, has there been any effort to implement a true Perl 5 successor?

In my opinion, Raku tried to do too much with the syntax itself, scaled Perl's flexibility to infinity, and made itself unusable.

Perl 5 does not need much for it to become a "modern" language. Instead of extending the flexibility of the syntax, the direction for Perl 6 should emphasize standardizing core utilities to facilitate integration with modern workflows.

- Package/module management and import/export could benefit from streamlining
- Stronger LSP and debug/error tooling (Rust has spoiled me)
- "Prettier" auto-formatting for source code (For those 30yo system scripts, you know the ones I mean)

What would be on your wishlist?

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



Mo utilities for email.

Changes for 0.02 - 2024-04-26T23:02:53+02:00

  • Add tests for error parameters.
  • Rewrite the tests so that the functional tests are first and then the errors.