Right.

As an example, Klipper (for running 3d printers) can update its configuration file directly when doing certain automatic calibration processes. The z-offset for between a BLtouch bed sensor and the head, for example. If you were to save it, you might end up with something like this:

[bltouch]
z_offset: 3.020
...
#*# <---------------------- SAVE_CONFIG ---------------------->
#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
#*#
[bltouch]
z_offset: 2.950

Thus overriding the value that had been set before, but now you have two entries for the same thing. (IIRC, Klipper does comment out the original value, as well.)

What I’d want is an interface where you can modify in place without these silly save blocks. For example:

let conf = get_config()
conf.set( 'bltouch.z_offset', 2.950 )
conf.add_comment_after( 'bltouch.z_offset', 'Automatically generated' )
conf.save_config()

Since we’re declaratively telling the library what to modify, it can maintain the AST of the original with whitespace and comments. Only the new value changes when it’s written out again, with a comment for that specific line.

Binary config formats, like the Windows Registry, almost have to use an interface like this. It’s their one advantage over text file configs, but it doesn’t have to be. We’re just too lazy to bother.

Is a very good idea providing much needed fixes to the JSON spec, but isn’t really what I’m getting at. Handling automatic updates in place is a software issue, and could be done on the older spec.

Benefit society, or go to support a pharmaceutical company that will in some way benefit society in exchange for making a few people rich?

No ethical consumption working conditions under capitalism.

What I’d like for a configuration language is a parser that can handle in-place editing while maintaining whitespace, comments, etc. That way, automatic updates don’t clobber stuff the user put there, or (alternatively) have sections of ### AUTOMATIC GENERATION DO NOT CHANGE###.

You need a parser that handles changes on its own while maintaining an internal representation. Something like XML DOM (though not necessarily that exact API). There’s a handful out there, but they’re not widespread, and not on every language.

Me talking about PNG in the late 90s. IE didn’t render certain features right (like transparency), and Adobe’s compressor in Photoshop sucked ass.

China built a few Ap1000 designs. The Sanmen station started in 2009 with completion expected in 2014 (2015 for the second unit). It went into 2019. The second, Haiyang, went about the same.

This is pretty similar to what happened in the US with Volgte.

And 5 years is what nuclear projects have promised at the start over the years. Everyone involved knows this is a gross lie.

Nuclear is nothing bog standard. If it was, it wouldn’t take 10 years. Almost every plant is a boutique job that requires lots of specialists. The Westinghouse AP1000 reactor design was meant to get around this. It didn’t.

The experts can stay where they are: maintaining existing nuclear power.

Renewables don’t take much skilled labor at all. It’s putting solar panels on racks in a field, or hoisting wind blades up a tower (crane operation is a specialty, but not on the level of nuclear engineering).

Then we just move the problem. Why should we do something that’s going to take longer and use more labor? Especially skilled labor.

Money is an imperfect proxy for the underlying resources in many ways, but it about lines up in this case. To force the issue, there would have to be a compelling reason beyond straight money.

That reason ain’t getting to 100% clean energy in a short time. There is another: building plants to use up existing waste rather than burying it.

Earthbound is a somewhat more traditional rpg with a lot of grinding/random combat.

One of the things that makes ChronoTrigger approachable is that all combat is prearranged by the design of the areas. You get the XP you need just by traversing it. Makes it easy compared to other rpgs from the time go. Take that as you will.

… it’s currently not possible to store the renewables anywhere

Every time someone argues this, it’s immediately obvious they haven’t actually paid attention how the storage market has been progressing.

Next, you’ll probably talk about problems with lithium, as if it’s the only storage technology.

If you’re going to do that, then also consider the co2 output of all the concrete needed for nuclear power plants.

No, you just pay out the nose up front.

If I had money to invest in the energy sector, I don’t know why I should pick nuclear. It’s going to double its budget and take 10 years before I see a dime of return. Possibly none if it can’t secure funding for the budget overrun, as all my initial investment will be spent.

A solar or wind farm will take 6-12 months and likely come in at or close to its budget. Why the hell would I choose nuclear?

But the technology to rely entirely on renewables isn’t really there either.

Yes, it is.

https://books.google.com/books/about/No_Miracles_Needed.html?id=aVKmEAAAQBAJ&source=kp_book_description

This is a book by a professor of Civil and Environmental Engineering that goes into the details. We don’t need nuclear. All the tech is there.

Except we have better options than we did 10 years ago.

I’d be all for nuclear if we rolled back the clock to 2010 or so. As it stands, solar/wind/storage/hvdc lines can do the job. The situation moved and my opinion moved.

Not sure about GP, but that’s basically what we did under “SAFe” (Scaled Agile Framework). PI planning means taking most of a sprint to plan everything for the next quarter or so. It’s like a whole week of ticket refinement meetings. Or perhaps 3 days, but when you’ve had 3 days of ticket refinement meetings, it might as well be the whole work week for as much a stuff as you’re going to get done otherwise.

It’s as horrible as you’re thinking, and after a lot of agitating, we stopped doing that shit.

Or wear them to kink spaces, because dominating class separation is part of the game.

They have x86_64 models.

They couldn’t play Doom (until much later). Even to this day, the Amiga ports are lackluster. Hardware wasn’t designed for that kind of game.