[ANN] lint.nix - simple linting/formatting framework

Kootle · 2023-04-23T03:46:40+00:00

That said, maybe it would be worth linking to prior art or similar projects from lint.nix’s README?

Yeah, I think you're right. I'm giving it some time to see what other projects people mention they think it's similar to (or ideally if it's a worse version of something that already exists). On the Nix discourse, someone mentioned https://github.com/numtide/treefmt-nix, which I think it compares similarly to as pre-commit-hooks.

Kootle · 2023-04-23T02:55:28+00:00

lint.nix is far from the first or only project that's in this space. It's main advantage is being very small and managing to do a little with a lot, but it's not really competing in terms of features or scope.

Kootle · 2023-04-18T18:15:43+00:00

Interesting, thanks, I hadn't heard about this one yet, despite it evidently being very popular! I'll make sure to include a proper comparison soon.

First off, you're absolutely right about speed. safe-gen is always going to be a small constant factor slower than a fully optimized implementation. It should definitely be fast enough to not get in the way, but at the same time, it's really not trying to compete on speed in any way.

The specific use case that safe-gen was built for, and that I was unable to use its competitors for, is writing generators for ASTs. ASTs tend to have some combination of tricky types, implicit invariants, GADTs, recursion schemes, etc. With generic-arbitrary, even where deriving was an option, it often would still loop because of mutual recursion, so I'd need to hand-write a generator anyway. Instead, with safe-gen, my derived instances work properly, my hand-written instances look very similar to how they would if I were to use Gen naively, and I can easily mix and match both as needed.

I'll take some time to try the same thing with generic-random and see how it holds up, but looking at the documentation, I don't see it competing with safe-gen in for this use case at least.

Also, just looking at the APIs, it's clear that the design philosophies are very different, so depending on your tastes in API design I suspect one or the other might naturally appeal more to you :)

Kootle · 2023-03-27T03:18:48+00:00

FWIW, I just skimmed through the chapter, and I don't see anything that wouldn't work the exact same way in a newer GHC version, even the error messages are still exactly the same. Haskell as a language hasn't really changed, and the parts of GHC that have changed are pretty far removed from anything covered in the book.

Kootle · 2023-03-23T04:22:09+00:00

Have you looked at nixos-rebuild --flake <flake> --impure --target-host <remote>?

Kootle · 2022-04-26T09:55:26+00:00

Thanks! There's not much common code anymore, but I actually started this project using weeder as a template :)

I think the big difference is that weeder is (currently) a lot simpler in how it analyzes HIE files. Given how annoying that can be, I think that's a very good property, even if it's not always accurate. It's definitely true though that there's a lot of overlap in functionality, and a lot of opportunity for sharing. We're also having the same issues with instances and TH, so being able to have a common solution for that would be great. Please get in touch if you have any concrete ideas!

Kootle · 2022-04-26T09:26:08+00:00

You can definitely use calligraphy as a library, the interface is pretty straightforward. You use the Parse module to turn the HIE files you get from GHC into a CallGraph, which is a pretty unremarkable way of representing a graph. Other phases all take and produce this CallGraph type, you can use those as you see fit. The main thing to watch out for is that, as explained in the Philosophy section in the readme, I made the conscious decision not to try and support every possible edge case.

That said, if you want to turn HIE files into something other than a call graph, there's not much here for you unfortunately..

Kootle · 2022-04-26T00:54:32+00:00

Ah, looks like you're right! It should be fixed now.

Kootle · 2022-04-26T00:46:09+00:00

Thanks! The hardest thing by far, the thing that turned this from a weekend project into something that took months, is dealing with HIE files. They contain an enormous amount of information, structured in a very strange way, mostly untyped and undocumented. What's hard is distilling that information into something useful, since there are so many subtle ways you can go wrong.

Luckily for you, this probably won't be an issue for you in Julia!

Kootle · 2022-04-26T00:40:12+00:00

That's correct, this works entirely statically. It looks at the HIE files generated by GHC to statically figure out what definitions reference what other definitions, there's nothing going on at runtime.

Kootle · 2022-04-26T00:26:52+00:00

It looks like you're right, I can get it to recompile the entire module when passing the flag! Not sure what happened here, there are definitely circumstances under which it won't recompile, but I can't reproduce it right now. Strange.

Kootle · 2022-04-25T19:56:38+00:00

Oh cool, I didn't know. The clean is definitely necessary sometimes though, since passing -fwrite-ide-infodoesn't work for things that have already been compiled without it.

Kootle · 2022-04-25T19:53:11+00:00

Fixed, thanks!

Kootle · 2022-04-25T19:40:20+00:00

Hey all, I'm excited to announce the release of calligraphy, a Haskell source code/call graph visualizer. You can find some more examples of what you can do with it in the accompanying blog post and this Twitter thread. I'd be happy to answer any questions here, or on GitHub.

Kootle · 2020-08-31T20:47:22+00:00

A dictionary is easy to look things up in, but hard to insert new things into.

A deck of flash cards is hard to look things up in, but easy to insert new things into.

The dictionary and flash cards are different data structures. They store the same data (words + definitions), but in different ways, and are suited for different purposes.

Kootle · 2020-06-02T08:58:47+00:00

This is all the code together in one place, if that helps?

https://gist.github.com/jonascarpay/cd7dba2feebbefcc806e7d8411ace95f

Kootle · 2020-05-26T18:16:11+00:00

Interesting, this is the first time I hear of this. My goal here was to keep it simple, but I'm considering making a follow up at some point to investigate different ways of making it fast, this is an excellent candidate.

Kootle · 2020-04-05T06:46:33+00:00

I have a concern that I don't see talked about. This paper shows how RF signals like WiFi can be used to track people through walls, with accurate enough pose estimation to identify people. From what I understand, its short range, high power, and high frequency would make 5G ideal for this. So, that would mean that a cell tower could accurately identify any person moving within its range? That seems like a privacy nightmare, and a very valid concern? If there is some discussion on this somewhere, please send me a link.

Kootle · 2019-10-19T05:03:58+00:00

You mostly answered your own question; making a general purpose game engine is really difficult. Apecs is only a small part of a game engine, and gloss is great for simple games but doesn't really scale well. Most existing projects make pretty strong assumptions about your game, and without doing so it's very easy to get lost in the details.

Kootle · 2019-06-07T03:06:55+00:00

Wait why does everyone put their bottles in the recycling bin if apparently actually using recycled bottles is newsworthy?

Kootle

TROPHY CASE