And well, one can always prompt "review my feature branch" or "review this file for bugs" with these tools; code analysis plays into the strengths of LLMs far more than code generation, since false positives/hallucinations aren't a problem with the former.

By the way, I have something related rather large in the works, look forward for a "Show HN" ;) (hopefully this quarter!)

> better support than Nintendo does with all their trillion-Yen revenue available to them

Well, they had to develop the entire OS, all GUI applications and SDK (and docs, and tooling...). It would also be far from surprising if they moved significant headcount to developing the Switch after the 3DS launched (and considering the Wii U's apparent failure).

There have been traces of Switch 2 stuff in Switch 1 kernel 3 years (?) before the S2 launched, so, in terms of planning, this tracks.

> My only hesitation is the firmware update

If you "hack" your 3DS you will not have to worry about sysupdates anymore. It is slightly more straightforward to do so if your system version is <= 11.14, and quite trivial if <= 11.3.

As for homebrew dev on 3DS, you have a lot more RAM and a "proper" CPU with somewhat modern CPU concepts (an actual OS, virtual memory, caches, multicore).

Unlike the DS and GBA, the 3DS has an actual GPU (well, kinda, it doesn't have programmable fragment shaders), which was designed around a custom flavor of OpenGL ES and it shows; citro3d is a shim, other than stateful state tracking and mem allocation, it mostly exposes the GPU hw as-is.

Overall, I think it is easier for people to get started with 3DS homebrew development and that it provides more transferable skills (w/r/t OpenGL-like APIs).

Disclaimer: I'm the lead maintainer of Luma3DS, am a core maintainer of libctru, and wrote significant parts of the exploit chains the guide uses. Feel free to ask around.

Honestly, I think why the GBA is more popular than the DS for that kind of thing is because it only has one screen (much less awkward to emulate), has high-quality emulators that are mostly free of bugs (mGBA most notably), and its aspect ratio is better than the DS anyway (3:2 upscales really well on 16:10 devices). That is to say, it's much easier to emulate GBA software on a phone or a Steam Deck than it is to emulate DS software.

This police ordinance from 1800 was abolished in 2013

> requiring permission of the husband to work

Repealed in 1965

> require the STL

That it has to heap-allocate if non-inlined is a misconception. This is only the default behavior.

One can define:

void *operator new(size_t sz, Foo &foo)

in the coro's promise type, and this:

- removes the implicitly-defined operator new

- forces the coro's signature to be CoroType f(Foo &foo), and forwards arguments to the "operator new" one defined

Therefore, it's pretty trivial to support coroutines even when heap cannot be used, especially in the non-recursive case.

Yes, green threads ("stackful coroutines") are more straightforward to use, however:

- they can't be arbitrarily destroyed when suspended (this would require stack unwinding support and/or active support from the green thread runtime)

- they are very ABI dependent. Among the "few registers" one has to save FPU registers. Which, in the case of older Arm architectures, and codegen options similar to -mgeneral-regs-only (for code that runs "below" userspace). Said FPU registers also take a lot of space in the stack frame, too

Really, stackless coros are just FSM generators (which is obvious if one looks at disasm)

std::bit_cast is

-Wextra catches stuff like this, alas I know of a few people that think "-Wextra is evil" (even though annoying warnings can be selectively disabled)

In both personal projects and $dayjob tasks, the highest time-saving AI tasks were:

- "review this feature branch" (containing hand-written commits)

- "trace how this repo and repo located at ~/foobar use {stuff} and how they interact with each other, make a Mermaid diagram"

- "reverse engineer the attached 50MiB+ unstripped ELF program, trace all calls to filesystem functions; make a table with filepath, caller function, overview of what caller does" (the table is then copy-pasted to Confluence)

- basic YAML CRUD

Also while Anthropic has more market share in B2B, their model seems optimized for frontend, design, and literary work rather than rigorous work; I find it to be the opposite with their main competitor.

Claude writes code rife with safety issues/vulns all the time, or at least more than other models.

> what's the point of globally visible singletons except "everything is an object" cargo-culting?

Having the singleton be an object becomes interesting when:

1) it contains attributes that themselves have non-trivial constructors and/or destructors. Order of initialization and destruction is guaranteed (init is in forward order of declaration, destruction in reverse order)

2) more rarely, inheritance (code reuse)

In the case of 1), you can just opt to construct the singleton on a sufficiently-aligned byte buffer in-place with `std::construct_at`. This gets rid of static-init order fiasco, __cxa bloat (if applicable), atexit bloat, and you can chose to just not call `std::destroy_at` if you don't need to.

In these two scenarios it's a lot more efficient to group many related objects into a bigger object.

It's just that I value the right to reveal my identity on my own terms a lot higher than $1200 (using my username and project name is fine). For the offer to become enticing they would need it to be 5~10y instead of 6mo, or to simply remove the $realname part of the "publicity" section

I was tempted about applying but that part is everything but nice and I think I'll just pass

Yep, no excuse for this, feature branches exist for this very reason. wip commits -> git rebase -i master -> profit

It sure does and Codex is great, but do you think they'll maintain the current prices after/if it eventually dominates Claude Code in terms of marketshare and mindshare?

Honestly, if faced with such a situation, instead of just blocking, I would report the acc to GH Support, so that they nuke the account and its associated PRs/issues.

"Assuming the group consists only of “the two fathers and the two sons” (i.e., every person in the group is counted as a father and/or a son), the total number of distinct people can only be 3 or 4.

Reason: you are taking the union of a set of 2 fathers and a set of 2 sons. The union size is 2+2−overlap, so it is 4 if there’s no overlap and 3 if exactly one person is both a father and a son. (It cannot be 2 in any ordinary family tree.)"

Here it clearly states its assumption (finite set of people that excludes non-mentioned people, etc.)

https://chatgpt.com/share/698b39c9-2ad0-8003-8023-4fd6b00966...