mst

13 days late but for posterity:

Yes. Not Wanting To Do That was the motivating factor for coming up with this approach :D

8 days late but for posterity:

So far I've only ever been using a private symbol that only exists within the codebase in question (and is then exported to other parts of said codebase as required).

If I ever decide to generalise the approach a bit, I'll hopefully remember to do precisely what you describe.

Possibly with the addition of providing an "I am overriding this deliberately" flag that blows up if it doesn't already have said symbol.

But for the moment, the maximally dumbass approach in my original post is DTRT for me so far.

Oh my word.

    const defer = f => ({ [Symbol.dispose]: f })

    using defer(() => cleanup())

That only just occurred to me. To everybody else who finds it completely obvious, "well done" but it seemed worthy of mention nonetheless.

I regularly add Symbol based features to JS libraries I'm using (named methods are riskier, of course)

    import { SomeStreamClass as SomeStreamClass_ } from "some/library"
    export class SomeStreamClass extends SomeStreamClass_ {
      [someSymbol] (...) { ... }
      ...
    }

I have not blown my foot off yet with this approach but, uh, no warranty, express or implied.

It's been working excellently for me so far though.

If you want to play with this, Bun 1.0.23+ seems to already have support: https://github.com/oven-sh/bun/discussions/4325

I feel like it would be creepy if the kid was using it without anybody ever checking up on it ... but I think all of my friends with kids would say that the answer to that is "parenting."

I mean, giving a kid an unlocked iPad and not bothering to do basic supervision can also have really creepy results, so I'm unconvinced that something like your work actually makes anything worse in the negligent parenting situation, and seems like it could be a lot of fun in the competent parenting one.

If you haven't already done this, I'd note that I can think of a number of parents who would probably rather enjoy a version of story mode that let them collaborate with their child and your code to put together a bedtime story before they turn it off for the night and tuck the kid into bed.

OpenAI stuff in general seems (to me, at least) to be overly positive and confident in terms of how it replies.

While I make no foolish claims that it's perfect, I've found Claude feels much less arrogant, and was genuinely appreciative when one of its replies started with an (accurate, of course I checked primary sources to verify that) analysis of the first half of my question, and then for the more obscure second half said "I'm not sure if I can answer that without hallucinating, but here's some stuff you could try researching."

Certainly Claude's tone and "attitude" (FSVO) works much better for me than any other LLM I've tried, though mileage will, of course, vary.

(I have zero connection to the company and am still on a free account, I'm just quietly impressed relative to the competition)

I absolutely agree with your analysis wrt current tech - however, I suspect the person you're replying to is talking about "what would be really cool" in terms of it happening in a future where the relevant underpinnings had advanced to the point where it could actually manage the situational/nuance stuff properly.

I almost certainly wouldn't want to use something that tried to implement it now but it's a lovely dream and the state of the art keeps advancing at quite the speed (i.e. faster than I would have predicted, even when I do my best to take into account that it keeps advancing faster than I would have predicted ;).

It does kinda make sense to me that the various non-US subsidiaries that survived did so at least in part because those places didn't have anything like Walmart.

Whether they'll be able to continue to survive in a world containing the current incarnation of Amazon is a different question and I've honestly no idea how that will turn out.

Lots of people not in the US saying they got redirected to various places due to (I guess) some sort of GEOIP detection rubbish, me included.

There's a (just about readable, the background is greyed out due to a popup, although thankfully the popup doesn't cover any of the text) archive at https://archive.ph/3HvjM - far from perfect, and I understand if people would rather not bother than deal with the low contrast ick of the archive, but I found it interesting enough to maximise my screen brightness and read it anyway.

I got redirected to history.co.uk/ (the root, so lol, no article for you)

There's a (just about readable, the background is greyed out due to a popup) archive at https://archive.ph/3HvjM - far from perfect, and I understand if people would rather not bother than deal with the low contrast ick of the archive, but I found it interesting enough to maximise my screen brightness and read it anyway.

Once you get as far as FDIC insurance being involved, the bank generally ceases to exist (ideally via a fire sale to another, more stable bank) and the shareholders generally get (all but) wiped out, at best.

Competent risk management so that doesn't (generally) happen is a core competency for a bank, and if regulators think you're doing it wrong they will come down on the bank's leadership like a ton of bricks.

If anybody reading this comment would like to learn more from people who understand the area far better than I do, I would recommend patio11's 'Bits About Money' and Matt Levine's 'Money Stuff.'

I remember some years ago we got somebody joining irc.perl.org #perl to ask for help replacing perl with lua as a game scripting system.

Obviously, a few people were like "uh, why would -we- want to help you with that?"

As soon as I saw an example of this existing code, however, I told said people to STFU ... because for some arsef_cked reason I don't understand at all, they'd used EmbPerl of all things for the scripting, which is basically "PHP for mod_perl" and exactly as horrible as you might imagine even when used for its actual purpose rather than in this case for something completely unrelated.

Even if sensible perl would've been an acceptable approach (and speaking as a veteran perl programmer, I would still consider lua to be more suitable; I strongly consider an importand part of the Zen of Perl to be knowing when to use something else) the approach they had taken was an abomination unto Nuggan and very much deserved to die.

What they had was very definitely the sort of perl code that justifiably contributes to people hating perl, and I considered it a service to perl to help them rip it out in favour of lua code that actually made sense.

(I, personally, think perl works very well as a scripting layer for e.g. irssi, though you might come away disagreeing if you read the average irssi script rather than ones written with a little care and concern ... but for a game? Nah, lua all the frigging way)

If the map editor is an extension (and they have lots of example extensions on github, all of which I've checked are under normal open source licenses) rather than a set of patches to the core code itself, it isn't subject to the Defold License in the first place.

(so if the extension API is missing something, contribute the feature(s) you need back to core, then you can write your extension free of issues, so far as I can tell)

Paid extensions are allowed, which seems like a neat compromise.

If you need to add an extra API or something to the core to make your paid extension work, you can't charge for that, which I think is designed to incentivise "improve the extension API, contribute that back to the core project, then go wild on your commercial extension and see if you can get people to pay for it."

I have no clue whether this approach will turn out to work in the medium-to-long term, but it's a fascinating idea and seems at the very least like an experiment very much worth conducting.

They seem to be fairly explicit that _they_ believe that extensions aren't covered by those restrictions.

Possibly the license text needs to be tweaked to make that more clear (IANAL too) but I read it as meaning that commercial extensions were fine, just not commercialising a patched version of the core code.

Your concerns do seem entirely reasonable, but if, in practice, they become an issue, it seems like the codified-in-law goals of the foundation (see https://defold.com/foundation/) strongly suggest they _would_ tweak the license text as required.

I dunno, I don't think the harsh restrictions you mention exist, and I'd hope that if any actual lawyers read them as existing then their employers will direct them to help get the license bugfixed.

So colour me "cautiously optimistic" here.

> Yeah but the open source ones ARE guaranteed. Even if they later become closed source, the code up till that point will remain open source forever.

The changes from the Apache 2.0 license are sufficiently minimal that you can _still_ fork it from that point, you just (a) won't be able to use the trademark (b) won't be able to sell it.

Given the clearly stated goals of the foundation and hence the project, that seems to be providing exactly the guarantees they intend to provide, and while your point about assurances is entirely fair, I think you're underestimating the level of legal guarantees that you do get here.

My first Archimedes came with a ring bound user's manual that was, IIRC, about 1/3 a guide to using the Risc OS GUI, and then 2/3 a programming guide to the version of BBC BASIC that shipped with it.

(I remember reading it end to end as a child laid on my parents' bed because the light was better in there than in my room, shortly followed by developing the programming addiction that has stuck with me the rest of my life ;)

It didn't cover arm2 assembly, but my parents bought me an extremely good book that did - and described the chip architecture itself in detail as well.

I only touched a Commodore at a friend's place to play games on it, but it sounds like they also understood hobbyists :D

Having cut my teeth on early Archimedes machines, I have a deep fondness for arm2's 16 instructions and the (lost during a house move, I suspect) assembly book I had that gave me enough of a description of the internals of the chip that I could desk check my assembly in my head with reasonable confidence that I was mentally emulating what the chip was actually doing rather than just what outputs I'd get for a given set of inputs.

Having to remember where I'd put the relevant chunk of assembler any time I needed a division routine was, admittedly, less fun, but the memories remain fond nevertheless :)

Turing complete YAML ends up being an app specific terrible programming language.

Many of us would rather use a less terrible programming language instead.

Honestly, "using the same language as the application" is often a solid choice no matter what the application is written in. (and I suspect that for any given language somebody might propose as an exception to that rule, there's more than one team out there doing it anyway and finding it works better for them than everything else they've tried)

You could use docker export to sluro the container contents (see article for example)

Aha! Doom noclip so you can run through walls.

(the first google result I got for idspispopd did not say _which_ cheat code it was, so figured I'd mention)

> I think every run that claims to be RNG-edited should post RNG seed for verification

If I understood the later parts of the article right, that's now basically a standard or nobody believes you.

Yes, but I think it's also true that LLMs are acting as a force multiplier to the underlying effect you describe.

Something like (my apologies to maths for the abuse) LLMs are adding one to the exponent of the adoption feedback cycle.

Possible middle ground if you can't immediately get what you're hoping for: Explain to the new Director that in the medium term you'd still like to be able to also work with the prior domain, and try to negotiate roughly "if I can fix this team to the point where it doesn't need me, then I get moved to cross-domain work."

This has obvious risks of them not coming through once you achieve the first part, but if this team is as screwed as you describe and management are confident in you being able to unfuck it - and of needing somebody at your level of competence to do so - then it might turn out to be a net positive route for you, your career, the team, and the company.

Also might be easier to sell to the new boss, and a deadline for them to actually deliver on that promise if you can get it made of "when said stock vests" would fit your being willing to leave then and their being aware you've passed the vesting deadline for a decent chunk of options will probably give you a stronger position from which to press them to deliver at that point.

(of course there's lots of details here you know and I don't and I'm still on my first pot of coffee, but hopefully the general shape of the idea provides some inspiration that fits the full situation)

If a static binary's --help doesn't tell me where the repository lives then I hope the author steps on a lego.

A more experienced Perl hacker would probably rewrite it as 100 lines of less dense code that people could actually read and comprehend.

I'd probably end up rewriting it as 50 lines of code that used a bunch of pure perl libraries and then use https://p3rl.org/App::FatPacker to bolt the dependencies onto the front for distribution so it was still a single file to install for everybody else.

(there's a lot of perl out there that uses techniques I would switch away from as soon as I got past a one liner in the middle of a pipeline, alas, but it doesn't have to be that way, perl just doesn't stop you blowing both feet off ;)

IIRC thezvi's summary post on R1 mentioned that R1 is amazing for general reasoning and is very clearly a successful proof of concept/capability but a lot of effort seems to have been put into making o1 Good At Code as a practical matter, whereas R1 seems to have been more a research project which proved out the approaches and then was released without sanding the rough edges off because that wasn't the point.

I'm (genuinely) fascinated by people having opinions about the splash image at all. When I click through to an article my first action is to PgDn past it without even registering the image, be it a photo (on a 'normal' new site), stock, or generated.

If I actually try and think about it, I also marginally prefer AI because of the content tailoring thing, and thought the different elements that were coaxed out of the generator in this case were kinda neat.

But people forming opinions about trustworthiness from the image is entirely alien to me (this is not to say they're wrong to do so, I simply ... don't).