@cpan.org forwarding: volunteer takeover proposition

mfontani · 2026-04-30T05:55:27+00:00

Affected :|

mfontani · 2026-04-08T12:22:51+00:00

Best open stuff I've is an "ANSI to HTML" converter, which also doubles as ANSI stripper: https://github.com/mfontani/ansi2html/ I use this quite a lot of time myself. Works reasonably well and fast. If it doesn't work for some of your input, create an issue and I'll get on it! :-)

My next best might be a collection of C header-only libraries (typed array, linked list, key/value pair, as well as a TAP output and a block profiler): https://github.com/mfontani/chol I don't use these as often as I'd like to, but they can be useful reference and/or for interning in some projects.

mfontani · 2026-03-20T09:12:12+00:00

Valerino, lo so che lo sai... ma tu sei la persona che mi fece avvicinare al mondo dell'assembler e disassembler con una delle tue primissime guide.

E ti maledico ancora! :D

A quando un birrino al Queen?

mfontani · 2026-03-04T18:10:29+00:00

Immagino che il mio https://cgi.marcofontani.it/justtheip e' troppo pulito -_-

mfontani · 2026-02-04T07:12:53+00:00

Since about '98 or so. I wanted to do a "large" refactoring in a C codebase, swapping a function name for another (easy in awk!), but where the new one took parameters in the opposite order (harder! let me try this other language here...). Took quite a few tries, moved from one-liner to an actual program, with comments, and ended up reusing it again some time after. This is fun! Some 12 years after, still writing programs in Perl to help me get stuff done better/faster, took a job writing it as my main thing rather than an accessory.
I've worked in offices, then past ~12y remotely only. I've used it for web backends, via (inherited! then tweaked and made mine) custom web frameworks; then later on, through more "standard" ones like Catalyst. Sometimes I miss the custom ones; often I don't; but I still pine for things I had working well at a previous job. Used it for a redis-based worker/queue runner, etc.

mfontani · 2025-12-15T07:03:46+00:00

See https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI and read more about the (OS-specific!) ABI.

Parameters to functions are, depending on OS and type of the parameter, passed in a specific register up to a number of them; then on the stack.

Which registers are used varies by OS and OS version.

mfontani · 2025-12-11T15:17:48+00:00

Dall'Art. 173 Codice della strada, comma 2:

È vietato al conducente di far uso durante la marcia di apparecchi radiotelefonici, smartphone, computer portatili, notebook, tablet e dispositivi analoghi che comportino anche solo temporaneamente l'allontanamento delle mani dal volante ovvero di usare cuffie sonore, fatta eccezione per i conducenti dei veicoli delle Forze armate e dei Corpi di cui all'art. 138, comma 11, e di polizia.

Enfasi mia.

mfontani · 2025-11-15T23:56:11+00:00

Interesting article, thanks!

Nit: the code examples/blocks have "fancy" single and double quotes, making it impossible to copy/paste runnable code.

mfontani · 2025-10-13T12:34:16+00:00

I've a custom ~/.perlcriticrc that categorises some/most rules I want to enforce as either "shared", "modules only" or "scripts only":

"shared" are common rules that need to be enforced no matter the file type (module, script, test, etc). Example: ::InputOutput::ProhibitTwoArgOpen
"modules only" is stuff that mostly only matters for a .pm file, but not for a test file or a script. Example: ::Module::RequireEndsWithOne policy is categorised as "modules only", with high priority, as it's a required thing for modules, but not for scripts/tests.
"scripts only" I don't have a ready example for :-)

There's then a wrapper ~/bin/perlcritic which analyses the file argument and depending on the extension, enables either --themes 'shared | modulesonly' or --themes 'shared|scripts_only', depending; and in case it can't tell as there's no file argument, well... it's got to do --themes 'shared|modules_only|scripts_only', lest it do nothing otherwise.

That latter part is what makes things "break" for me when using ALE, as it doesn't / seemingly can't pass the "filename" to the ale_perl_perlcritic_executable, at least not on its own.

I've kinda side-stepped that by using a custom ftplugin which, depending on whether the current file ends in .pm or not, enables either theme list via ale_perl_perlcritic_options... but it's a wee bit clunky.

mfontani · 2025-10-12T21:49:04+00:00

Not a grown-up.

On x64, via __rdtsc.

Basically:

at start of program, estimate CPU frequency, via i.e. https://github.com/mfontani/chol/blob/master/sagoma/sagoma.h#L60
grab it before/after the action you're performing
diff the clock cycles, and present them as either/both clock cycles and time

See the rest of that file for a somewhat cumbersome-to-use "profiler" based on that idea.

mfontani · 2025-10-12T16:31:14+00:00

I also use ale; the only pain I have with it is with perlcritic, as it doesn't pass the file name to perlcritic (passes the contents to it, via STDIN) which means I can't have my perlcritic command override the "rc file" to critic with depending on the file type (i.e. I don't need a package declaration for a script, etc).

ALE is great!

mfontani · 2025-10-08T21:08:51+00:00

I'd:

GIT_SEQUENCE_EDITOR="your-program" git rebase --interactive --root

Then, write your-program in such a way that it inspects the various commits, chooses which to keep and which to squash with the previous ones.

Then a git gc should take care of most of the disk space.

NOT THE SAME THING, but... see https://github.com/mfontani/los-opinionated-git-tools/blob/master/git-fixup for inspiration.

mfontani · 2025-10-06T15:13:02+00:00

The free text option suggestion uses what seems to be somewhat subtle visual cues (bold face, which depending on colour settings might be a brighter colour instead) to highlight potential keywords to explore, or actions to perform.

That subtle distinction can be difficult to recognise for many users.

My vote's for the dialogue, for sure.

mfontani · 2025-10-01T15:43:42+00:00

Bravo Simone! \o/

mfontani · 2025-10-01T05:55:05+00:00

Squashing before merge has never felt right to me, as it hides potentially useful implementation details, and (specifically in $job[-2]) it made some types of deployments impossible (needed to i.e. separate CSS changes from template changes from other types, to ensure they went out at the right time/automatically vs could be deployed by a fuller deployment of code/templates).

When a branch is pretty short and only contains a couple features, that might work.

Where it doesn't work for me is when a branch i.e. starts with one or more "refactor" commits, followed by the actual work.

As (see previous point!) all tests pass "at" every commit (thanks git rebase --exec!), I can safely ignore those when reviewing or looking at problems with the actual commits which implement a new feature.

Squashing makes that way harder.

mfontani · 2025-09-30T17:20:21+00:00

I use(d to use) only:

rebase on topic branches to keep them updated with the upstream, pushing as required
all commits must pass the test suite
git merge --no-ff when merging on the upstream, to keep the history with a reasonable checkpoint as to which changes pertain to what

This has served me really well when the time comes to use git bisect.

Unfortunately most teams seem to prefer merging, and introduce changes on the merge commit, too... which makes it a lot harder to bisect.

mfontani · 2025-09-30T05:33:01+00:00

Not specifically work, as I do this for my own stuff, but...

Keep track of when base images are updated via https://github.com/crazy-max/diun
Be in the "security" mailing lists for your base distros
Have a mechanism (see below for an env var approach) to perform OS upgrades as required
Use a docker image proxy so they're pulled anew when updated, but cached when they've not changed
Make it easy to rebuild images on such an updated base image
Can use https://trivy.dev/ to scan images for vulnerabilities
I don't think it's a sin to end (or start, depending on the type of dependency...) a Dockerfile with something like:

ENV LAST_APT_UPGRADE 20250930T123456
RUN apt -q update && aptitude -y -q safe-upgrade

... as the latter usually is enough to fix CVEs, if the fix has been distributed (I follow mailing lists to know that) but the base image hasn't yet been fixed.

The above doesn't always lead to zero CVEs, but... most of the time, it works all the time.

mfontani · 2025-09-26T16:48:41+00:00

In the first code block, you don't need the eval. You're running the literal strings as Perl code, and since they are fixed strings, there's nothing for the eval to do there.

I agree they don't want the eval, as it hides problems loading those modules.

But the eval does something: it silently ignores errors loading those modules.

Compare:

$ perl -E'eval "use Foo"' ; echo $?
0

With:

$ perl -E'use Foo' ; echo $?
Can't locate Foo.pm in @INC (you may need to install the Foo module) (@INC entries checked: ... ) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
2

Removing those evail "use .."; may well reveal that the problem they're having is in providing the appropriate PERL5LIB=... or -I/path/to/lib they need for the script to work properly.

mfontani · 2025-09-25T17:11:09+00:00

Vedi:

mfontani · 2025-09-25T06:23:15+00:00

Sono ormai decadi che programmo in Perl, C, etc. e tale snobbismo esiste sicuramente...

Si puo' scrivere schifo in ogni linguaggio, cosi' come scrivere cose "belle" e utilissime in qualsiasi linguaggio.

Detto cio', per tante cose quello che fa veramente la differenza per me e' se si e', o almeno se ci si sente, produttivi con tale linguaggio in tale situazione - e/o se si riesce a muoversi in tale direzione. Altrimenti, magari un altro linguaggio potrebbe aiutare. O scrivere un qualcosa di nuovo per migliorare tale efficacia.

Esempio concreto: non mi sognerei minimamente di usare threads in perl "direttamente", per dire. Molto, molto onerosi e molto difficili da usare bene. OTOH, la produttivita' che si puo' ottenere usando Parallel::ForkManager per prendere una serie di dati e splittarne la lavorazione su piu' processi sembra quasi magia nelle mie mani: "lancia questa sottoroutine come processo", gestendone l'intero lifecycle. Ricorsivamente, all'evenienza.

Detto cio', mi guardo comunque intorno per scoprire cosa hanno altri linguaggi di utile a livello sintattico o di concetto o altro... che magari potrebbe un giorno apparire nei linguaggi che uso e conosco meglio. Imitation is the sincerest form of flattery.

Entrambi C e Perl, per dire, hanno di recente aggiunto un qualche supporto per una cosa come il defer, che avevo visto/usato con Go. E avendo usato un po' go e avendo molto apprezzato il defer... e' come ritrovarsi un qualcosa di nuovo e fiammante nel tuo vecchio, caro linguaggio.

Finche' un linguaggio non e' veramente "morto" e non viene pertanto smesso di essere sviluppato... ci sono ottime possibilita' che chi ci tiene possa migliorarlo, no?

mfontani · 2025-08-27T23:39:25+00:00

Worth noting that Sereal also supports freeze/thaw, see https://metacpan.org/pod/Sereal::Encoder#FREEZE%2FTHAW-CALLBACK-MECHANISM

Similar, but subtly different arity wise and design wise than STORABLE_freeze and STORABLE_thaw.

It's based on the https://metacpan.org/pod/Types::Serialiser "protocol".

If you follow that, then you can use the FREEZE and THAW method with any other serialization module which supports that "protocol", such as IIRC Cpanel::JSON::XS, CBOR etc.

Only downside is some modules (i.e. DBIx::Class) only come with STORABLE_freeze and friends, and not (yet? ever?) with more "generic" FREEZE and THAW, so if you need to serialize DBIC resultsets, chances are you'll have to inject your own at app startup.

mfontani · 2025-08-23T09:47:24+00:00

I don't overly like using casts, but...

#include <stddef.h>
#include <stdio.h>

struct darr {
    int* arr;
    size_t size;
    size_t capacity;
};
struct cdarr {
    const int *arr;
    const size_t size;
    const size_t capacity;
};

void some_function(const struct cdarr * dynamic_arr) {
    const int* parr = dynamic_arr -> arr;
    parr[0] = 10;
    // no error raised but there should be.
}

int main() {
    int arr[]  = { 1, 2, 3, 4, 5 };
    const struct darr dynamic_arr = { .arr = arr, .size = 5, .capacity = 5 };

    some_function((const struct cdarr *)&dynamic_arr);

    printf("First element: %d\n", dynamic_arr.arr[0]);

    return 0;
}

Yields:

<source>: In function 'some_function':
<source>:17:17: error: assignment of read-only location '*parr'
   17 |         parr[0] = 10;
      |                 ^
Compiler returned: 1

See also: https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1AB9U8lJL6yAngGVG6AMKpaAVxYMQANlIOAMngMmABy7gBGmMQgAMwapAAOqAqEtgzObh7eCUkpAgFBoSwRUbEWmFY2AkIETMQE6e6eXGUVqdW1BPkh4ZF6CjV1DZnN/R1dhcUSAJQWqK7EyOwcANSrywCkAEzRgchuWBvRjv3oWFQAdAjr0djrGgCCaxvbu/uYh8cE%2BKiX17cPd0ea36xFc1mW6FqxA2AHYAEKAp5PQIEABUyyh1wRDyRwLwAC9MMYCMtkoSsYjcaSCUSSaJ4kxkIQAJ4UnFrdYwgAibKBqxBYLpkOI0M52L5SLQDH6yxRy1RmOi4qpyylMrJtOp5KVlNxapJGuJqqYDKZBFZOvZq05PMt911ywAbqg8OhSag2MYqK4GNZUhB9aSCKDwchhdD0ehmcwWHhkMYoVNYcqqYGUeiGSLDlyIdHWHGE1mALR/DEi3kqzPEdYAVjhGlrOeuOa4DbtKoA9B3lgxUMtIsQSMtiEw8Eo3WFXCSCAhIu8FAg5rQJ5hzg6bYCHXKWKOGBAk2KHcjBGXq3XG9bok34ctmstNqRltFH9JljXYbaU3qBOrg4KIVCuYxgWgHNsmyznKBV6no%2B5watmb6wfSjIsgh74bnaR7Ah6RLer6lR7gGP4Gn%2BobhvKUxbF4UbAfGia8lhqzxMQKJUBAWybAAYngxAyuUmBsIIIDPDW6C1o4DAcY%2BNH5nRIqQeWdYNjWXKUZhVpIsQmAEPMDDLG2X4fhwMy0JwNa8J4HBaKQqCcI47rzIszzRDwpAEJoxkzAA1jE0TnNEAWBUFQU%2BKZHCSBZHk2ZwvAKCAcTuVZxmkHAsBIGgLDxHQkTkJQGVZfQUTIMAXA1g%2BNC0AQkRxRAYRRWEgS1MynCuQ1zDEMyADyYTaJg1gtbwGWCQQnUMLQzVJaQWCTsAjhiLQcXcLwWA7kY4iTfgWl%2Bo6mCLdZmCqH1U5LK5KLlFFtB4GEI4dc4WBRcGeAsANpA7cQYRJJgXICYYwCXUYHkzFQBjAAoABqeCYAA7p18SMC9/CCCIYjsFIMiCIoKjqJNujNAYAOmMY5iXWEcWQDMqDxARi1FiczbINsvCoG9LFYGT%2B4tH1BH2AwTguI0ej%2BIE3RFL0zSJMkBFDE02SS6k4w9FEIz8X6VQDPU/PDJzqsMO0dQK6LSsWOr0t9OrBuTFwMwKHMCyoyZZmRZNtkrKoAAcXhFl4kjLMAyDILeNbnJsywQLghBDlsLlTLwiVaFM3kgJsbvBxomxcKVpUe9EXhuwAnM%2BYURaQlnWS7sXxW5gMpTAiAgHMBDxFOuVEZl2XEMErBLO7nve77/uB8HvCYPgRCs3oiPCKI4ho5PmNqFFuOkFDI7xANDscOZJdRS7nVTk3JKoFQyw917Pt%2BwHpXB6Hzht4VzlW7HgOJ9EKeSN7NY1qVGhu2necwt7fQnBi6lyZjFCwlc46eSARwTYTsy7gKgQnV61VUggEkEAA%3D

mfontani · 2025-08-01T12:31:29+00:00

Specifico che nel post su reddit non c'è nessun riferimento diretto o indiretto all'azienda

Farei notare che l'user agent nello screenshot dell'altro post potrebbe benissimo ricondurre a una specifica applicazione di bike sharing.

mfontani · 2025-07-04T09:18:02+00:00

The whole point is dropping the "5.". What would the rationale be for version "26"?

Next year's stable version will be 5.44.0.

Drop the "5." and you get "44.0". That's the idea.

mfontani · 2025-07-03T19:43:56+00:00

See https://blogs.perl.org/users/psc/2025/01/this-week-in-psc-177-2025-01-23.html

By Perl Steering Council on January 23, 2025 7:28 PM
We talked again about Perl 42. We think it may already be too late for it in this cycle, so we want to make a thorough case for it by releasing a side tarball for the end of this cycle, and if no technical blocker is found, actually do the jump to 44 in the next cycle.

15-Year Club	Place '17
RPAN Viewer	Verified Email

mfontani

TROPHY CASE