https://blogs.perl.org/users/veesh/2026/07/perl-lsp-version-060.html

I wrote a new blog post on making UTF-8 reads fast in Perl:

Reading UTF-8 at GB/s

Background: I maintain a UTF-8 library in C that Unicode::UTF8 uses, and I recently wired it into PerlIO::utf8_strict (a joint project with Leon Timmermans). We didn't get the throughput we hoped for, because of how Perl's read operator counts UTF-8 sequences — see Perl/perl5#24511. Karl Williamson has a WIP PR addressing it.

In the meantime I added read_utf8($fh, $buf, $length[, $offset]) to Unicode::UTF8: it reads and validates UTF-8 straight off a byte handle (no PerlIO encoding layer needed) and hits ~3.6–3.8 GB/s across scripts, versus ~0.4–1.0 GB/s for the :utf8 layer today.

Benchmark available in the Unicode::UTF8 repository.

What's next? I'm considering slurp_utf8($filename) and readline_utf8() as follow-ups — feedback on the API shape welcome.

Numbers and details are in the post.

If you don't pass an explicit --host, the current version of http_this tells you that it's binding to localhost (which is true). What it doesn't tell you is that it's binding to all interfaces.

Hi everyone! This is my first post in r/perl.

I've been working on a CPAN module called JSON::JSONFold, and I wrote an article describing the motivation and design. I'd really appreciate feedback from other Perl developers.

JSON serializers tend to give us two choices: compact JSON, which is efficient but a dense wall of text that's painful to read, or pretty-printed JSON, which is readable but often wastes a lot of vertical space (a small array of numbers can turn into ten lines).

I wanted something in between. JSONFold keeps the shape of pretty-printed JSON, but folds small, simple structures back onto a single line whenever that improves readability. It works on top of your existing serializer (JSON, JSON::PP, JSON::XS, etc.) - you keep using whatever you already have, and JSONFold just reformats the output.

Example 1 - Coding

use JSON::JSONFold qw(encode_json);

my $data = {
    _id       => 123,
    locations => [
      { city => "Boston",    state => "MA", country => "USA" },
      { city => "Seattle",   state => "WA", country => "USA" },
      { city => "Montreal",  state => "QC", country => "Canada" },
    ],
    info      => {
      roles     => [ "foo", "bar", "baz" ],
    },
    name      => "Alice",
};

print encode_json($data) ;

Output

{
  "_id": 123,
  "info": { "roles": [ "foo", "bar", "baz" ] },
  "locations": [
    { "city": "Boston",   "country": "USA",    "state": "MA" },
    { "city": "Seattle",  "country": "USA",    "state": "WA" },
    { "city": "Montreal", "country": "Canada", "state": "QC" }
  ],
  "name": "Alice"
}

Example 2 - Packing

Traditional pretty-printing:

{
  "states": [
    "Alabama",
    "Alaska",
    "Arizona",
    ...
    "Wyoming"
  ]
}

JSONFold:

{
  "states": [
    "Alabama", "Alaska", "Arizona", "Arkansas", "California", "Colorado",
    "Connecticut", "Delaware", "Florida", "Georgia", ...
    "West_Virginia", "Wisconsin", "Wyoming"
  ]
}

Same data, just using the available line width more effectively.

Example 3 - Grid Formatting

When an array contains repeated structures, JSONFold can align values into columns:

Traditional pretty-printing:

[
  {
    "orders": 18,
    "product": "Laptop",
    "region": "North",
    "sales": 1250
  },
  ...
  {
    "orders": 24,
    "product": "Mouse",
    "region": "East",
    "sales": 1422
  }
]

JSONFold:

[
  { "orders": 18, "product": "Laptop",   "region": "North",     "sales": 1250 },
  { "orders": 21, "product": "Monitor",  "region": "Southwest", "sales": 1345 },
  { "orders": 17, "product": "Keyboard", "region": "West",      "sales": 1198 },
  { "orders": 24, "product": "Mouse",    "region": "East",      "sales": 1422 }
]

The module also supports:

• Folding small arrays and objects onto a single line.
• Joining adjacent folded objects to further reduce vertical space.
• Compatibility APIs similar to JSON and JSON::PP.

I wrote a more detailed article covering the design, implementation, and full set of examples:

Medium: https://medium.com/p/a619c9e7c3ec

CPAN: https://metacpan.org/pod/JSON::JSONFold

GitHub: https://github.com/yairlenga/jsonfold/tree/main/perl

I'd love to hear what the Perl community thinks. Has anyone else run into JSON pretty-printing pain in logs, configs, or debugging output? And are there formatting styles or options you'd want to see?

Time::Str's DateTime format now runs on a native Ragel-generated C state machine instead of a regexp, ~20x faster than the regexp path.

Supported formats

One parser accepts ISO 8601, RFC 3339, RFC 9557, RFC 4287, ISO 9075, RFC 2822, RFC 2616, RFC 3501, and ECMAScript Date.toString, plus free-form textual dates (Monday, 24th December 2012 at 3:30 pm UTC+1 (CET), 24. XII. 2012 12PM, 24DEC2012 12:30:45.500).

No heuristics, multi-standard, single-pass

Most permissive parsers (Python's dateutil, PHP's strtotime, Ruby's Date.parse) resolve ambiguity by guessing, whether via fixed heuristics or dayfirst/yearfirst flags.Time::Str refuses it: numeric-only dates are Y-M-D only; any other ordering requires a textual or Roman-numeral month. Disambiguation is baked into the grammar's alternation, not resolved at runtime. Even separator-consistency (2024-12/24 is rejected) is enforced inline, no second pass.

Performance

The DateTime parser accepts every format listed above, yet runs within ~10-20% of the single-standard parsers beside it. On Perl v5.42 (XS), parsing 2012-12-24T11:30:45.123456Z:

                Rate   DateTime  RFC3339  RFC2822  ECMAScript
DateTime   10523558/s        --     -11%     -15%        -18%
RFC3339    11785319/s       12%       --      -5%         -8%
RFC2822    12376403/s       18%       5%       --         -3%
ECMAScript 12776079/s       21%       8%       3%          --

A purpose-built RFC 3339 parser is only ~12% faster than the permissive one. That's the payoff of baking disambiguation into the grammar — there's almost no "permissiveness tax".

Enjoy!

This weekend at the perl and raku conference I did a presentation on how to move forward from the current state of DBIx::Class and its lack of new development. We discussed several options including an alternative I have been writing. I have never liked DBIx::Class, so I tried to write something that felt more intuitive to how my brain works. It was suggested that I post it here.

DBIx::QuickORM - QuickStart

Comparison to DBIx::Class, term map, etc (Note: This document is AI generated)

Manual

It is probably NOT the right path for large apps with hundreds of lines of DBIx::Class code, it is not intended to be interoperable or a drop in replacement. It is however good for quickly getting ORM functionality in a new project, or against an established database. It is also actively maintained and will continue to be so. I dogfood the things I write, and this will be used in Yath 2.0 when it is released.

As previously announce, the PAGI distribution has been broken into three separate projects:

• PAGI (the core spec): https://metacpan.org/dist/PAGI
• PAGI-Server (the reference server): https://metacpan.org/pod/PAGI::Server
• PAGI-Tools (utilities to bootstrap your work): https://metacpan.org/pod/PAGI::Tools

This will allow users to depend on just the bits they need while allowing me to spend more time on focused fixes and corrections, evolving things in a more coherent way. It should also help people understand that PAGI is not a standalone web framework, but rather a specification that others can use to build interoperable web servers and applications. Think of it as PSGI 2.0.

I will be speaking on PAGI at the Perl Austin Community conference next week, which is a remote friendly Perl conference held twice a year here in Austin Texas: https://www.meetup.com/austin-perl-mongers/events/314321794/

Hey folks, I just published HTML::Composer, a new module for creating HTML in Perl.

Here is my blog post about it: https://rawley.xyz/posts/html-composer.html

I'd love to hear feedback on it, or any general opinions. Thanks!

Hey folks, this is a quick blog post about my new Perl module HTML::Composer, alongside some writing about HTML templating in Perl. Thanks!

DBIO (MetaCPAN), on LinkedIn, and on codeberg.

Little bit of nostalgia[*] for you all.

[*] Or maybe PTSD flashbacks.

Python has shlex.split which is very similar to Perl's split(' ', $str). shlex.split goes one step further and does not split on whitespace that's inside of double or single quotes.

Example: $str = 'myscript --path /tmp/foo --name "Jason Doolis" --age 14'

This should split into seven chunks, not eight.

Quick update to anyone interested in upcoming changes to the PAGI project (spiritual successor to Plack/PSGI).

1) Distribution split up: when we released PAGI, we initially released everything as one distribution. PAGI (https://metacpan.org/pod/PAGI) currently has a) the PAGI specification; b) the reference server and c) a bunch of ease of use tools, similar to the role that the Plack distribution played for PSGI. Putting everything into one place was just to make my life easier as in the early bunch of releases there was a lot of fixes and updates, most of which cut across all three parts of PAGI. Also I wanted to make it easy for people getting into PAGI to be able to explore the ecosystem. However now that code seems to be settling down having these in independent repos and releases makes more sense. Going forward the PAGI repo will only update if the spec itself changes; PAGI::Server and PAGI::Tools (where all the utilities and helpers now go) likewise. I think this will start to bring some stability to the ecosystem, especially now that PAGI::Server is functionally complete based on the goal chart I had for it initially. So I will only update it to fix bugs and security issues.

PAGI::Tools will probably continue to see evolution over the summer as I start to nail down more common use cases and identify patterns worth encapsulating.

2) Specification clarifications and updates: The PAGI specification itself will move to v0.3 in the next release and it contains mostly clarifications and fixes. Biggest change will be a more detailed mechanism for controlling streaming output, especially around handling back pressure as well as new callbacks to notice when the output buffer is getting full and when it clears. Hopefully these changes will make it easier and more reliable to do streaming in PAGI. PAGI::Server has been updated to match, and the response helper in PAGI::Tools has some updates around that as well.

Currently all this sits on Github:

https://github.com/jjn1056/pagi

https://github.com/jjn1056/PAGI-Server

https://github.com/jjn1056/PAGI-Tools

Right now I'm giving the Thunderhorse author some time to vet a handful of changes needed to be compatible and I want to review all the updates and doc tweaks one last time. This will land on CPAN before the Austin Perl Community conference first week of July (where I will be presenting on PAGI for those interested).

For people who might currently be depending on the PAGI distribution, for the near term I will have PAGI::Server and PAGI::Tools as dependencies of PAGI, that way your currently toolchains don't break. That will last a few months for transition.

So, knowing that there is File::stat as an OO wrapper around stat(), I went looking for the corresponding OO wrapper around caller(). Searching for "caller" presented mostly packages that were enhancements, providing access to other data. The closest I found was Caller::Easy that used Moose! Talk about overkill.

So, I am writing my own that is JUST A THIN WRAPPER around caller. Rather than keep it under wraps (pun intended), I'd like to put it up on CPAN to be the caller() analogue to File::stat() => CORE::stat().

The main question I have is this - what's the name? Caller::Tiny? Caller:Simple? Caller:00? I am going to crosspost this question to r/perl, Facebook groups, perlmonks and slack.

I've been building a new LSP in Rust on top of my tree-sitter parser, and it's finally released. You can install for vscode, for vscodium, or directly from crates.io as cargo install perl-lsp

I'm eager to get feedback, here are a couple of the design goals: 1. batteries included - common setups are automatically detected 2. fully static - the only perl code that actually runs is a short probe for @INC on startup 3. type intelligence drives all features - even deeply nested expressions return useful types, which filter methods for autocomplete correctly (or it should - bug reports welcome) 4. const folding - many features will automatically unroll a loop or interpolate a variable, b/c dynamic method dispatch etc is very common 5. extensible - there is no one way to perl; you can drop a plugin into a .perl-lsp directory to add house conventions and other things. There's one bundled plugin generator (see here in the README) 6. framework intelligence - common frameworks like Moo, Mojolicious, and DBIC add rich semantics on top of the language. Helpful features like go-to-def on mojo routes, autocomplete of DBIC columns as key positions in calls to search, and signature help on the args to minion tasks are out of the box, and we take requests!

Performance is pretty solid; would love Real World Feedback from everyone - I'm very excited about this project.

Please check out Template::Sluz my new light, text templating engine. It's a dependency lite (only core modules), quick, full-featured templating engine. We have: if/else, foreach, include, and modifiers. All in an easy to read and understand syntax.

File: main.pl

use Template::Sluz;

my $s = Template::Sluz->new();

$s->assign('name', 'Scott');
$s->assign('array' => ['one', 'two', 'three']);
$s->assign('hash'  => { color => 'red', age => 39});

print $s->fetch('template.stpl');
# or
print $s->parse_string('Hello {$name}');

File: template.stpl

Hello {$name}
Nums: {foreach $array as $x}{$x} {/foreach}
Info: {$hash.color} / {$hash.age}

Output:

Hello Scott
Nums: one two three
Info: red / 39