timhh

That's a maximum. It's extremely unlikely that they would actually get jail time. Maybe a suspended sentence at worst.

Explanation of Bradley-Terry here: https://stats.stackexchange.com/a/131270/60526

It's such a great and simple algorithm. I feel like it deserves to be more widely known.

I used it at Dyson to evaluate really subjective things like how straight a tress of hair is - pretty much impossible to say if you just look at a photo, but you can ask a bunch of people to compare two photos and say which looks straighter, then you can get an objective ranking.

I mean... you can probably see why they don't spend any effort on that.

I have a C library (I've also done a Python one in the past) that you load into the executable you want to debug. It activated based on an environment variable so normally I just permanently link it.

When it is loaded it will automatically talk to VSCode and tell it to start a debugger and attach to it & it waits for the debugger to attach.

End result is you just have to run your script with an environment variable set and it will automatically attach a nice GUI debugger to the process no matter how deeply buried in scripts and Makefiles it is.

https://github.com/Timmmm/autodebug

I currently use this for debugging C++ libraries that are dynamically loaded into Questa (a commercial SystemVerilog simulator) that is started by a Python script running in some custom build system.

In the past I used it to debug Python code running in an interpreter launched by a C library loaded by Questa started by a Makefile started by a different Python interpreter that was launched by another Makefile. Yeah. It wasn't the only reason by a long shot but that company did not survive...

Yeah I agree - in fact I ran into this very issue only hours ago. The entire error message was literally "operation not supported on this platform". Yeay.

https://github.com/rust-lang/rust/issues/141854

> I'll also note that this was quite annoying to debug since the error message in its entirety was `operation not supported on this platform`, you can't use RUST_BACKTRACE, rustfmt doesn't have extensive logging, and I don't fancy setting up WASM debugging. I resorted to tedious printf debugging. (Side rant: for all the emphasis Rust puts on compiler error messages its runtime error messages are usually quite terrible!)

Even with working debugging it's hard to find the error since you can't set a breakpoint on `Err()` like you can with `throw`.

I don't think anyone disagrees with that, but 80 characters is clearly waaay too restrictive. I think 120 is much more reasonable.

> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. This is however a much lower number than the 60-70% that are commonly repeated, originating from a few big companies and projects. If this is because of a difference in counting or us actually having a lower amount of C problems, I cannot tell.

When I counted I got about 55% which is pretty close to the standard 2/3.

https://blog.timhutt.co.uk/curl-vulnerabilities-rust/

It is possible to survive the lunar night. See

https://space.stackexchange.com/a/67918/40677

No, I mean why can't you select commits in the graph and copy/paste them. I wasn't talking about copy/pasting the lines of text in the `git rebase -i` file.

I meant any variation of `git log --graph`.

`git log --graph` is just a really really bad GUI. Why not use a good GUI instead?

Although in fairness it's quite hard to find a good Git GUI because there are so many bad ones. The only good ones I've found all have some kind of flaw:

* GitX - the clearest design IMO, but it's one of those "gazillion forks" bits of software like TomatoUSB, and Mac only. Plus it has some annoying bugs.

* Git Extensions - I didn't even realise this was a Git GUI until relatively recently because it its terrible name. It's pretty decent, but Windows only.

* VSCode 'Git Graph' extension - my current favourite - it integrates into VSCode too which is much better than a standalone app, especially when using Remote SSH. However it is abandonware and although the source is available, the license doesn't let you republish it so it's not "open source" and nobody can take it over.

Disappointingly even these don't let you do things that a GUI obviously should let you do, like copy & pasting commits, dragging and dropping to rebase.

Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V?

But, they're still miles better than `git log --graph`.

Yeah... how long do you think librewolf is going to survive if Mozilla dies?

That's fine until you have to ask a question that isn't answered anywhere on the internet. Then you post a perfectly reasonable question and get it downvoted to hell...

https://stackoverflow.com/q/79461875/265521

That's just the latest one I've asked. Here are some more examples:

Case insensitive string comparison is "opinion based": https://stackoverflow.com/q/11635/265521

How to catch Ctrl-C "needs more focus" (this was closed but has since been reopened): https://stackoverflow.com/q/1641182/265521

This reasonable question had 13 downvotes by power-mods but has climbed back to positive when discovered by actual users: https://stackoverflow.com/q/41015509/265521

Another example of idiotic downvotes. This started off at -3: https://stackoverflow.com/q/79050597/265521

It's a common pattern that questions get a lot of downvotes initially from people trawling new questions who see a lot of genuinely bad questions (seriously there are loads), then see a good question that they can't understand in 1 second so they just downvote/close it too. So you quickly get downvotes and then later you get people coming from Google who are actually looking for that thing that upvote it.

I think SO actually did try to improve matters once. I can't find it now but they were going to make it impossible to go below 0 votes and allow one free "reopen", or something like that. But the power mods absolutely hated that idea and SO sort of depends on them so they chickened out. Now they're paying the price.

> PR_SET_CHILD_SUBREAPER

I wrote a tool that does just this: https://github.com/timmmm/anakin

If you run `anakin <some command>` it will kill any orphan processes that <some command> makes.

However is still isn't the true "orphans of this process must automatically die" option that everyone writing job control software wants - if `anakin` itself somehow crashes then the orphans can live again.

Still it was the best I could come up with that didn't need root.

Not e-ink though so the display isn't always-on and you need a power supply. This can hang on the wall and you just have to recharge it every few months.

> Give me wifi, e-ink display, and the ability to write a regular program that writes unicode chracters to STDOUT (and have that rendered to the display) and I'll give you my money right now.

I bought an Inkplate 10 from eBay for like £80, which is an absolute bargain. 10" display, ESP-32. You do have to buy a battery but they're cheap and available and it has the charging circuits built in.

The only real downsides I've found are:

1. No case. I don't want an ugly 3D printed one so I ended up buying a custom sized picture frame online (£17 I think), and mounting it in that.

2. The software is Arduino based. Arduino is trash, but I don't want to have to figure out how to set up something sane like PlatformIO or Rust, so I've opted to put as little software on it as possible. All it does is download an image, display it, and then go to sleep for however long the server says. I even made a simple custom image format so I didn't have to deal with PNG or whatever.

Yes it is. Code quality is abysmal. There's no CLI interface to their build system so you have to use their gimped editor. It doesn't even support incremental compilation, which means a one-line change takes like 5 minutes to deploy while it rebuilds SSL libraries etc. every single time.

Having said that I probably would have just bought this if it was available at the time. Only 7 inches, which is tiny, but a lot less effort!

So you have to already have all the linters installed? Ok I am planning to solve that problem too, but we'll have to see whether it's actually possible to compile e.g. rustfmt to WASI. In my experience so far WASI is pretty alpha quality.

I don't really understand. Pkl seems to be a configuration language? How are you going to run clang-format, rustfmt, go fmt, pyright, etc. using Pkl?

Yes. Those are both more effort and less reliable than what I am planning (a static binary with WASI plugins).

Interesting. I've been working on a pre-commit replacement too, written in Rust but using WASI for all plugins (no exceptions!). I haven't got very far but I think this will have huge advantages over pre-commit, mostly in reliability.

Me and my colleagues have had numerous issues setting up pre-commit because it inherits Python's atrocious infrastructure.

I'm curious how this is going to deal with actually running plugins? Will it take the same approach as pre-commit and add dedicated not-very-good support for a load of different languages?

Maybe they're not implying this kind of limited dependent type system but surely it is still dependently typed? It's just not the "full fat" dependent typing.

Another example of a language with limited dependent typing is Sail. It has "lightweight" dependent types for integers and array lengths (pretty similar to Ada from what it sounds like).

It's very good in my experience - it lets you do a lot of powerful stuff without having to have a PhD in formal verification (again, sounds similar to Ada).

> An example of something you can do in a dependently typed language is write a sorting function in such a way that the type checker proves that the output will always be in sorted order.

Yeah you can't do that but you can have the type checker say things like "n^m is positive if n is positive or even" or "foo(x) -> (bits(n), bits(m)) with m+n=x" (not the actual syntax). I'm pretty sure you can't do that stuff in a type system without dependent types right?

Clever. You can see how it works by looking at the shadows of her hand. The "shadow" from the big cylinder is fake; it's actually printed on.

The people I am referring to are not helping. At this point they are making SO worse.

The problems are two-fold:

1. Any community with volunteer moderators attracts the kind of people you don't want to be moderators. They enjoy rigidly enforcing the rules even if it makes no sense.

2. There are two ways to find questions and answer them: random new questions from the review queue, and from Google when you're searching for a problem you have. SO encourages the former, and unfortunately the vast majority of questions are awful. If you go and review questions like this you will go "downvote close, downvote close, downvote close". You're going to correctly close a load of trash questions that nobody cares about and a load of good questions you just don't understand.

I've started recording a list of questions I've asked that get idiotic downvotes or closed, so I can write a proper rant about it with concrete examples. Otherwise you get people dismissing the problem as imaginary.

These mods now hold SO hostage. SO is definitely aware of the problem but they can't instigate proper changes to fix it because the mods like this situation and they revolt if SO tries to remedy it.

I disagree. It was useful because the UI was (and is!) great. Easy to use markdown input, lists of answers sorted by votes, very limited ads, etc. The gamification was also well done.

Compared to anything before it (endless phpBB forums, expertsexchange, etc.) it was just light years ahead.

Even today compared the SO UI with Quora. It's still 10x better.

Stackoverflow mods and power users being arseholes reduces the use of Stackoverflow. ChatGPT is just the first viable alternative.

Maybe you could if you weren't clearly intending this as a way to violate copyright.

It still isn't a magic copyright eraser. The law doesn't fall for mathematical "aha but!" tricks like HN commenters assume it does.

No you can't, any more than you can encode a Disney film as a prime number or in the digits of pi and avoid copyright that way.

Read this classic essay: https://ansuz.sooke.bc.ca/entry/23

(2022)

Difficult to draw conclusions with no code here.

An interesting thing they didn't mention is that Matplotlib's point-in-path code is actually already in C. So this isn't really a case of Rust being X times faster than Python, it's X times faster than some other C algorithm. That's probably why X is only ~4 (they don't actually give a single-thread comparison), instead of ~50.

https://github.com/matplotlib/matplotlib/blob/cb487f3c077c93...

I expect the Rust code is faster because that code is waaaaay more complicated than what they probably need (https://stackoverflow.com/q/11716268/265521) - e.g. it handles stroke widths.

IMO this result is not very interesting.

Maybe it's just me but I just use a proper debugger. Debugpy and VSCode work fantastically.

In a previous company I set things up so that when there's an uncaught exception it will automatically start a VSCode debug session and connect to it.

Here's the extension: https://github.com/Timmmm/autodebug/

Unfortunately the Python part of that is not open source but it was only a few lines of code - should be easy to recreate. That repo does contain a C library that does a similar thing.

You might just say "why not just run your program directly with the debugger?" and yeah that is better when you can do it, but I'm working with complicated silicon verification flows that are often several layers of Python and Make, followed by a simulator (e.g. Questa or VCS) that itself loads the library you want to debug. Very difficult to make debugging work through all those layers, but it's quite easy to write some code at the bottom of the stack that says to a debugger "I'm here, debug me!".