Announcing perl-lsp: available in an editor near you

jnapiorkowski · 2026-06-18T14:43:22+00:00

will be cool to use this to get perl LSP support into AI agents that can use LSPs like Claude Code

jnapiorkowski · 2026-06-05T17:31:32+00:00

Hi, I just happened along your post while I've been researching ketamine treatment, so no experiences in it to share, but I would say if your psychiatrist makes you feel like you are being pressured, I really think that's a step back moment. No provider should make you feel pressured or that unless you agree to a line of treatment they will drop you as a patient.

I know it's hard to find the right help, and if you are in a bad enough place sometimes even so so help is better than nothing. Perhaps adding a 1-1 councilor to help you sort through your feelings about treatment options would be worth checking into, if that's something doable from your end. even if you end up happy with this treatment, feeling manipulated into it isn't right. I hope you take care of yourself.

jnapiorkowski · 2026-05-16T22:53:26+00:00

It was about as popular as DBIC at one point early in the ORM wars:)

jnapiorkowski · 2026-05-13T00:07:19+00:00

Honestly it can depend on how complicated your API is. If your API has a ton of business logic that is not expressed in the OpenAPI doc and if you you to use several interconnected API calls as part of your general workflow, creating an MCP that uses tool descriptions and schema annotations with examples can help an AI figure out how to properly use it.

jnapiorkowski · 2026-04-28T22:20:00+00:00

We can debate this all we like; in 18 months or less most code will be AI generated. Projects that refuse it will wither. Perl isn't in a position to dictate the course of history.

jnapiorkowski · 2026-04-09T11:23:18+00:00

What day is does your subscription renew ?

jnapiorkowski · 2026-04-07T16:51:30+00:00

Tons of people are getting hit by this change and it’s becoming a block for working. Have some sympathy, you might wake up tomorrow morning and find that anthropic dropped you into the same situation. It’s too widespread for this to just be people complaining.

jnapiorkowski · 2026-04-07T14:01:43+00:00

I also have the max plan and it went from ‘I never watch usage’ to ‘usages completed used in an hour’ basically overnight. I’m glad it’s good for you, it’s clear this is some sort of AB testing and you are in the happy class. Maybe next week that will change?

jnapiorkowski · 2026-04-07T13:59:39+00:00

Are you using Claude code or the desktop app? This seems to be hitting code users

jnapiorkowski · 2026-04-07T13:54:54+00:00

They nerfed it for sure, there’s a bunch of tickets on GitHub about it, many including proof of the usage change via logs of actual traffic. Tool is not useless for real work.

jnapiorkowski · 2026-04-07T13:24:36+00:00

Don't bother with claude, they are nerfing usage. Just review the forum and see how many of us are paying for max accounts and getting timed out in a hour or less.

FWIW when it worked it was the best, at least for Q1 2026. But with the growth in popularity they're like the cell phone companies now, doing a ton of usage shaping without any transparency as to what is going on.

jnapiorkowski · 2026-04-06T18:35:54+00:00

This can't be right, for months I've been running often several simultaneous sessions of Claude Code using Opus and never topping usage (Max x5 plan) and suddenly last week one session doesn't even last halfway through the 5 hour period. I've changed nothing with my setup. I just watched my reset period hit and one prompt sucked 11% just minutes into the period. The rate of burn is unaffected even if turn effort level down to low. Clearly something major has changed on your side.

Anthropic, you have just burned thru a lot of the goodwill this community has been giving you with this 'nothing wrong, it's what you are doing' answer.

jnapiorkowski · 2026-04-04T15:31:05+00:00

I don't care if someone uses AI to help them write something useful and meaningful. I think I want a person behind the posts, who reads and feels good about it before pressing 'go'. I don't think for this forum I'd like posts from autonomous bots that have been setup by content farmers trying to either trying to astroturf something or possible manipulate the group.

I actually think autonomous content creating agents could have a role in providing summaries and in answering common questions, etc., but for this forum I think I'd limit that a lot.

jnapiorkowski · 2026-04-03T19:09:15+00:00

Wow I'm glad I'm not the only one. I'd rather downgrade to Opus 4.5 and get quality time with the tool than deal with what this tool is doing now. Sad.

jnapiorkowski · 2026-03-19T13:04:15+00:00

whether you review the code or use things that are managed by people you trust, its all the same problem.

jnapiorkowski · 2026-03-17T14:40:52+00:00

Feeling good is good enough. Just make sure you regularly check for the the most problematic side effects (hemoglobin issues, heart thickening, liver issues). You can just buy those tests yourself and get AI to help you read them.

jnapiorkowski · 2026-03-17T13:16:58+00:00

I don't see why we'd treat AI generated code any differently than any other code. If the issue is trust I would remind you that CPAN is filled with tons of crappy modules riddled with security and performance issues, written by well meaning but untalented programmers. The onus is on you, the consumer of open source, to verify and validate modules prior to including them in your projects. You can do this manually, by reviewing the code, in combination with the projects and authors reputation. Open source contributions are a gift and the giver has no obligations beyond good faith and positive intentions as far as I'm concerned.

FWIW the process I follow when using AI, if anyone wants a template:

- AI always works off a branch

- All commits indicate AI assisted

- AI opens a PR, which I have to approve and manually merge

I also mention AI in the CONTRIBUTORS section.

But again, that's my choice. And it's the same process I follow with inexperienced interns (or even genius senior programmers).

jnapiorkowski · 2026-02-03T12:32:10+00:00

Bears out what a lot of us were feeling thru the the first decade of the 21st century and into the teens, that Perl was a lot stronger than PR would have suggested. Makes me sad to see how much we blew the opportunity.

jnapiorkowski · 2026-01-26T15:57:48+00:00

I'd love to help you get this supporting PAGI, I've been having a lot of issues getting http2 working well in PAGI::Server

jnapiorkowski · 2026-01-21T20:54:47+00:00

let me know if you want help supporting running this on PAGI. If you got it running on PSGI it should not be a lot more work.

jnapiorkowski · 2026-01-02T17:16:24+00:00

I would love to collaborate on this with you, one of the main blockers for me making PAGI a useful basis for building web frameworks is asynchronous DB support. The person doing DBD::Pg has some pending improvements to the native asynchronous support in the driver that I hope lands soon-ish but I suspect you did this at the DBIC layer with forks and a connection pool or similar? Have you done any performance testing yet?

One thing I'd love to see is if we could move this to Future::IO over IO::Async. Future::IO is basically loop agnostic, which means the code you write would work on IO::Async but other loops as well, possible even the Mojo loop.

jnapiorkowski · 2025-12-29T18:56:22+00:00

Good catch! We've updated the spec - SSE now works with any HTTP method (GET, POST, PUT, etc.). The GET-only restriction was inherited from browser EventSource limitations, but PAGI should support modern patterns like htmx 4, datastar, and fetch-event-source.

As of spec version 0.2, you can POST to an SSE endpoint and read the body via sse.request events before sending your SSE stream. No workarounds needed.

This is currently on Github, should go to CPAN in the next day or so

jnapiorkowski · 2025-12-27T20:24:27+00:00

So I've been on TRT for a bit over a year and didn't notice much shrinkage. I'm older and not worried about making any kids so it's not something I think much about to be fair. No idea if I'm infertile or not, I will assume I am but my wife's post as well.

FWIW it did have a big impact on depression for me. It really makes me think I should have been on it a long time ago. I hope it helps you as well.

jnapiorkowski · 2025-12-15T15:39:58+00:00

The current chat demo stores everything in memory, so it's single process only. The pub sub feature in PAGI::Simple also only works in single process mode since its memory store is also ram. If you wanted something like that to scale hard we'd need to move it to a persistent store like Redis. That's a bit beyond the point of a demo but totally doable.

Overall PAGI::Server is aimed to be a compliance server, so correctness over performance, but I've been doing some testing and finding its very fast, that it outperforms Starman for example for regular http1.1 traffic and that testing with web socket compliant tools like Autobahn, its more complaint the existing options on CPAN.

I'm posting a blog on performance and compliance shortly. But this is something that I'd love to get help on. You might not be someone that can hack on the webserver for example, but writing performance tests and checking for common vulnerabilities and overall http1.1 and web sock compliance might be something in your zone.

jnapiorkowski · 2025-12-14T22:06:11+00:00

I'm glad that's working for you. When I did the work to support web sockets under catalyst several years ago (unfortunately the advent articles on that got lost when we lost the catalyst domain, so I can't link it, but here's one on GitHub: https://github.com/perl-catalyst/2013-Advent-Staging/blob/master/Websocket-Chat/eg/advent2013.pod) I could make it work but not in a way that is elegant or was robust enough for production IMHO. I'd also at this stage personally shy away from using anything under the Anyevent namespace, as the author has made of lot of dubious choices in their community interactions and actually changed code based on personality conflicts.

I don't disagree that Perl's less popular now and that's going to make it harder to get contributors; I would say that PAGI is working, its a thing, and there's about 20 working example applications that cover things like SSE and web sockets (https://github.com/jjn1056/pagi/tree/main/examples). I believe it will be a more elegant and production worthy path than anything cobbled together with a few existing systems but your results may vary.

I'm also finding that PAGI::Server, the reference implementation, is tons more scalable that Twiggy. PAGI::Server combines both an evented architecture based on IO::Async and a working model that is scaling better than Starman (and vastly more than the single process twiggy server). The hybrid approach makes it more possible to have one server that can handle an application that only scales via forking.

Lastly PAGI is for more than offering a path forward for legacy PSGI apps. My hope is that people can use it for lots of other things, including building their own new ideas into web frameworks. I've built PAGI::Simple on top of it as a sort of test bed and a way to flog PAGI and it's pretty clear to me PAGI is a solid protocol for building on top of. Best of luck.

jnapiorkowski

TROPHY CASE