48
49

Mago 1.47 allows writing custom rules in PHP (mago.carthage.software)

eingereicht von Tomas_Votruba

Alle 17 Kommentare
sortiert nach:
Neu
besteTopKontroversAltq&a
FormatierungshilfeVerstecke die HilfeNoun: Inhaltsrichtlinien

[–]nickchomey 2 Punkte3 Punkte  (5 Kinder)

I came across mago recently. I'm curious: how are people making use of it? 

[–]wdesportes 2 Punkte3 Punkte  (4 Kinder)

https://github.com/wdes/plouf.rs I made my own Graft tool and it uses Mago 💪

[–]HenkPoley 1 Punkt2 Punkte  (3 Kinder)

Maybe write in the repo that you mean NanoNets Graft. A bit sloppy, but maybe like this:

# plouf.rs

A code map for software developers and coding agents. Inspired by NanoNets Graft.

plouf.rs analyzes a source code repository and creates a map of how the code is connected.

It shows relationships between files, classes, functions, routes, templates, and database objects.

Examples:

- Find what code calls a function.
- Find where a database table is used.
- Find which routes use a controller.
- Find which templates depend on a component.

plouf.rs does not change your code.
It only reads the repository and creates a searchable code map.

[–]wdesportes 1 Punkt2 Punkte  (2 Kinder)

Thank you !
I applied all your feedback, and a new version is released 🎉

[–]HenkPoley 1 Punkt2 Punkte  (1 Kind)

😵‍💫 sloppy run-on sentences in the README.md.

Handwaves towards ASD-STE100.

[–]wdesportes 1 Punkt2 Punkte  (0 Kinder)

Well, I am open to better sentences. Can you provide some? English is not my main language

[–]mnavarrocarter 0 Punkte1 Punkt  (0 Kinder)

Pretty clever, kinda like mdbook extensions. Will try later.

[–]FluffyDiscord 0 Punkte1 Punkt  (9 Kinder)

So does the Mago "compiles" the rule to rust so it's benefitting from the speed improvements, or are we back to phpstan/php speeds? If not, then its just a duct-tape solution tbh. Wouldn't Lua or FFI rust extensions work better?

[–]gempir 2 Punkte3 Punkte  (0 Kinder)

For the php ecosystem it just makes sense to be able to write extension in PHP.

The best performance obviously would be to write them directly in Mago, most rules should live there.

But if you have some very niche requirement that you want to assert, this now lets you write a check for that.

There are also companies recompiling mago and letting the optimizer optimize the binary of mago for their codebase, which let's them gain even more speed.

[–]Fit_Tailor_6796 1 Punkt2 Punkte  (6 Kinder)

To be honest, speed is not a consideration for me when it comes to the tool-chain output itself. I mean what is a minute for the WP codebase? In the bugger scheme of things, accuracy and cover is more important than speed, I think.

[–]OndrejMirtes 0 Punkte1 Punkt  (0 Kinder)

On my machine (5 year old MacBook Pro with M1 Pro) it takes about 24 seconds without result cache to analyse the wordpress-develop codebase with PHPStan (with the config the repo actually uses in CI).

[–]Tomas_Votruba[S] 5 Punkte6 Punkte  (0 Kinder)

2 s vs 1,5 min is huge difference

been using similar Go-based alternative to Rector and I never want to go back

[–]umulmrum 3 Punkte4 Punkte  (3 Kinder)

For our codebase, speed could make a huge difference. On my machine, PHPStan takes about 10 minutes and I have to configure it so that it uses fewer CPU cores, or everything will freeze. With Mago, it's 15 seconds and no config fiddling. This is the difference whether I actually run the tools locally or have to rely on the CI pipeline, with longer feedback cycles and higher resource usage. Also, Claude could use the tools casually and iteratively on the local system.

(yet this is theoretical, as we don't use Mago Analyze but only the other components; still it's what I have been hoping for since I did the performance tests)

[–]staabm 0 Punkte1 Punkt  (2 Kinder)

In case PHPStan runs 10 minutes on your machine there is verly likely something wrong.

Either outdated PHPStan version, or e.g. not properly working result-cache

Sometimes there is a few single files which are very slow to analyse, see  https://phpstan.org/blog/debugging-performance-identify-slow-files

Please try to reproduce your slow case and report a issue

[–]umulmrum 0 Punkte1 Punkt  (1 Kind)

Yes, I have to set `maximumNumberOfProcesses` to something lower than the default (don't know if the default is flawed or if it's only problematic on my machine), which invalidates the cache which leads to longer execution times. Also, there are a few huge legacy files which take a lot of time. Maybe it would be enough if there was a CLI switch for `maximumNumberOfProcesses` that doesn't invalidate the cache.

(I appreciate especially your efforts in improving performance btw.)

[–]OndrejMirtes 0 Punkte1 Punkt  (0 Kinder)

The default has been "not the maximum" for some time, precisely to prevent unusable rest of the OS.

Changing `maximumNumberOfProcesses` does not invalidate the result cache.

[–]kryyova 2 Punkte3 Punkte  (0 Kinder)

extension can be in any language (as long as you write an sdk for this language), it just should speak the same protocol over stdin/stdout. speed improvement is still here cuz parsing and analysis is in mago

having first-party php sdk makes more sense than any other language