zulu-inuoe

I'm looking forward to being able to use this. It doesn't sound like much but those extra three lines and variable assignment is duplicated a ton of times across our codebase so it'll be a nice change

I thought exactly the same thing

Incorrect. If I throw my plastic bags out on the road it's much easier. It'll find its way to the Pacific eventually

I think it's really cute and endeared me to it immediately

A nice enjoyable read, thank you

My understanding of Odin is that it's a relatively thin layer of preprocessor around C. So.. C but nicer?

Of all the hills to die on. What an unbelivably silly one. CRLF sucks, suck it up. As many others have noted, there are millions of devices this idea puts in jeopardy for absolutely no reason. We should be reducing the exceptions, not creating them

3000% agree. I have been bitten endlessly by autocrlf. It is absolutely insane to me that anyone ever considered your having your SOURCE CONTROL tool get/set different content than what's in the repo

You can use CCL

But that output is wildly more variant between applications, especially for cases involving escape sequences, whitespace handling, and so on. All of these are specified in JSON

One of my values contains a literal ,

I would keep things simple and make an Electron app, then either bundle ffmpeg or use ffi to call out to it. That'll get you going right away with the performance you need

That's very interesting to hear. This last weekend down here in Florida was unbearable. I got my first sunburn in like 20 years, just last Saturday. And I'm out in the sun every weekend wakeskating.

This looks great, but within the first 5 seconds I'm surprised by the lack of an Undo/Redo facility. I can't imagine myself using a tool like this without it

Good question. Maybe 'format' or just 'file'?

I really wish I'd thought of this method when I was building a search based application. It was my first time and I struggled with structuring everything

404 on that Torvalds link

What I find so interesting is that we all effectively do TDD, except without commitment to it - Imagine writing some code and not at least testing it out with several test cases.

The absolute bare minimum should be for you to write those informal tests down and commit them to the repo. That's some golden knowledge I've gotten over time

It just requires the overhead of setting up the test runner

Of course somebody thought of this already

Thank you! Now when you say json logging, are there any common patterns you can guide me to look at? Just looking around for JSON logging gives me results like [1] which talk about JSONL (object per line, presumably JSON serializer makes sure to not emit literal newlines).

But some other places describe this a bit more liberally. And [2] notes that I should include a time stamp in each log entry which makes sense.

[1]: https://stackoverflow.com/questions/10699953/format-for-writ... [2]: https://www.papertrail.com/solution/tips/8-essential-tips-fo...

Say I'm building a logging library, is there any sort of generally agreed-upon standard per what a log file should look like? I know there's several formats that lnav supports, but I'm not familiar with them.

I've always had trouble before figuring out what a good compromise between log format and flexibility looks like. Especially wrt newlines in the log message itself (eg if I want to log a stack trace)

Any thoughts for a format that would generally work ootb in lnav or other log viewers?

I hate you

They did mention it. They use it for some of their older games but it seems like Ruffle isn't yet feature-complete with Action Script 3 and thus cannot be used to run their newer games

Ditto.

If I hadn't used it at work at a large C++ shop, I'd never have stumbled upon how great Incredibuild is

Closest equivalent that I can think of is the change-class function in CL. That one also happens to be generic so you can control the finer details of what it means to change A to B

Not only that, but you can definitely apply modern style zeroing equipment to bows so you "just have to aim in a straight line".

The article lost me pretty early with these glaring oversights.

You have to put it in context, though. This was back in 1999. Plenty of people even today push for semantic HTML. HTML is said to represent a document, and documents have structure. So I'm sure it wasn't all that uncommon to take it to mean that this structure was machine readable.

This comment makes me thankful to live in a place where somebody stealing my car isn't even in my top 100 concerns.

Store what? The BlurHash ?