csande17

Maybe I misread the article, but I think the Nothing photos app is literally ignoring the second tap, not just failing to provide feedback

> Why? How, even, have they implemented this?

This is really common because of two design features that most UI frameworks share:

- The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler has some last-ditch check that aborts the action, like the "don't rotate the image if it's in the middle of the rotate animation" check from the article, often there's no way for it to tell the button to cancel the color change. (And conversely sometimes the "on click" handler can fire even if the color change animation doesn't play correctly.)

- Buttons usually change color when you press down the mouse button, but only perform the action when you release the mouse button. Sometimes this is used to intentionally give you a chance to cancel the action at the very last minute by dragging your mouse off the button while it's still held down (or, on mobile, to e.g. reinterpret your interaction as scrolling instead of clicking), other times it just creates more opportunities for something to happen that prevents the action from working after the color change has already happened.

Rust has a feature called "tuple structs" where the properties of the struct are accessed by numeric indices instead of names: https://doc.rust-lang.org/book/ch05-01-defining-structs.html... / https://doc.rust-lang.org/book/ch05-02-example-structs.html#...

In most other languages this would be written as "this.current_index" or some other property name.

iOS has an accessibility option called "Ignore Repeats", which seems like a better approach because it's system-wide. So people who need that kind of accommodation can have it in places like the on-screen keyboard too, without needing everyone else to slow down their typing.

It's not really a question of how many taps they support, but how fast.

This same issue also seems like it would prevent you from quickly double-tapping the button to turn an image upside-down, a much more common use case.

As I understand it, Zig is trying to bring in almost all the stuff that would usually be done by external tools. Zig has its own solution for finding system libraries (instead of pkg-config), it integrates its own C/C++ compiler, and you can do code generation with comptime (or, worst-case, a Zig program that can also be compiled to WebAssembly) instead of an external script. So I think there's a good chance that you'll be able to build most Zig projects entirely inside the sandbox someday.

There's still the obvious problem that if the build system emits malicious code, you'll probably run that code anyway. Personally I think this kind of sandboxing is more useful for enforcing build reproducibility rather than, like, protecting you from viruses in the build.zig file.

Not really? This change is about the code for downloading and extracting third-party packages. The @cImport change was part of an effort to (eventually) make Zig's dependency on LLVM/libclang optional, so that it could (eventually) be put into a third-party package, but it doesn't seem directly related.

Do you have any links/context on how this party plans to restrict freedom of expression?

Given that the most recent time Anthropic attempted regulatory capture, the US government responded by saying "alright, we agree that Mythos is too dangerous to release, so we've banned you from releasing Mythos," I can't wait to see what the outcome of this next push is.

It's not clear how the strategy in the article differs from the one used by Wordle Bot, the analysis/feedback system that Wordle links to on the victory screen at the end of the game: https://www.nytimes.com/interactive/2022/upshot/wordle-bot.h...

The first page of the published paper ( https://orb.binghamton.edu/nejcs/vol8/iss1/6/ ) also claims that the game was developed by "Josh Wordle", so maybe it just isn't the highest-quality scholarship in the world.

> For instance, I think that every single verb that ends in "-rimasu" in the polite form (other than just arimasu?) is a godan -ru word.

Not quite: https://jisho.org/search/%23words%20%23v1%20%3F*%E3%82%8A%E3...

I definitely remember only learning about two groups, personally. Is the third group, like, "irregular verbs", or do some books teach "the -suru verbs" as the third group (instead of "suru" being a single irregular verb that you can attach nouns to)?

Technically, it's possible to write the "si" sound as スィ, similarly to much more common constructions like ファ and ティ.

Wiktionary lists eight whole words that use it! (The entry for スィ itself, a couple obscure loanwords and proper names, and a couple alternate spellings of words that Japanese people normally pronounce using the "shi" sound.) https://en.wiktionary.org/wiki/Category:Japanese_terms_spell...

I used to get these terms mixed up all the time because some textbooks use "Group 1" and "Group 2" to refer to these verbs, but Group 1 doesn't mean ichidan.

For all that I'm not totally sold on this article's idea of "stems" and "suffixes", I think it does a good job of avoiding this pitfall and correctly explaining the groups.

"Disappearing consonant" doesn't work for the potential form, unless you expand the representation to allow writing -[rar]eru. (Edit: And I think imperative would require like "-[ro](e)".)

Which, like, is clean in the sense that Redux is technically Turing-complete (you can encompass _any_ difference between two strings by saying that one string uses the stuff in brackets and the other string uses the stuff in parentheses), but that doesn't make it a good idea.

I'm not totally sure this "stems and suffixes" mental model really works well for everything else. Forms like the imperative (食べろ), volitional (食べよう), provisional (食べれば), potential (食べられる), and causative (食べさせる) aren't cleanly handled either -- they work similarly for godan verbs, but you have to add a different suffix for ichidan verbs.

It's definitely useful to understand how "chi" and "tsu" fit into the hiragana chart, and if your asterisk notation helps you remember which verbs are ichidan vs godan then that's great, but I'm not sure it's worth trying to unify -masu and -nai into one model.

Similarly, when complaining about how you have to memorize a big table of verb conjugations in the intro, the author links to a table of... -ta forms, a verb form for which the author later concludes you just have to memorize a big table.

I think what's actually happening is that the game only counts your swipe as an input once you lift your finger off the touch screen.

You can kind of get away with that if you're implementing, like, 2048 (although the official version at play2048.co doesn't do this), but it feels way too unresponsive to be usable in an action game.

This project appears to be vibe-coded; the game itself was added in a single squashed commit, but the author then used Claude for an extremely trivial "add a link to the bottom of the page" follow-up. The code for the game also has some comments that look pretty reminiscent of AI (e.g. describing the game board as being "validated", as in the LLM double-checked that it made sense).

As a game it doesn't seem especially well-designed. In particular the author has missed a key aspect of the original Pac-Man, which is that ghosts have to run back to the start when they're eaten and that gives Pac-Man time to freely move around and eat dots. Instead, getting eaten teleports both you and Pac-Man back to the starting positions and consumes a life. You get three lives, so it's way too easy to just tank two power pellets and then keep Pac-Man trapped in the bottom half of the level forever (aided by his not-great AI logic, as other commentors mention).

Personally, I found this take on the "Pac-Man but you're the ghosts" idea more interesting and less obviously plagiarized: https://youtu.be/96xNkL1Z_8M

http://troubles.md/posts/why-do-we-need-the-relooper-algorit... has a more detailed version of this argument: if WebAssembly had used a CFG as the basis for its control flow, it would have been easier to compile to and easier to efficiently execute/translate while maintaining safety, and maybe GCC would have released a WebAssembly backend by now.

The author alleges that the real reason WebAssembly uses loop/block is because that's how V8 worked internally at the time and Google didn't want to go to the trouble of implementing something different. But more recently V8 has started moving towards CFGs ( https://v8.dev/blog/leaving-the-sea-of-nodes ) so maybe there's hope in the future.

As a human, it is possible for you to create copyrightable works and transfer the copyright to Microsoft in exchange for money. It is not possible for Claude Code to do those things because Claude Code is not a human.

UIKit apps can already resize fluidly on Mac Catalyst and iPadOS. I suspect the issue here is more related to the video encoding / streaming used for iPhone Mirroring.

Apple has used this kind of blurry resizing animation in the past. For example, circa macOS 10.14 Mojave resizing windows in Split View would have the same effect: https://youtu.be/KDDMUxBtnkI

It would be very funny if Apple's next innovative flagship product is a Surface Duo

Steam was rewritten in React relatively recently. I think most people formed their opinion of Steam back when it was mostly developed in VGUI, the same in-house native UI framework Valve used in games for stuff like the Half-Life 2 title screen and the TF2 server browser.

As I understand it, these cards work basically the same way as transit card systems in other countries, like the SF Bay Area's "Clipper" cards.

The overall model is similar to tap-to-pay debit cards. They're only used for consumer-to-business payments. When you tap the card, the card sends over an account number / signature / etc, which the merchant sends to a central clearinghouse to finalize the transactions.

The main difference is that the card itself keeps a running balance of how much money the customer has available to spend. In many cases, this gives the merchant enough confidence to e.g. let you through the train turnstile without actually waiting for the central clearinghouse to confirm the transaction. (I think in practice they usually send all the transactions in batches, daily or weekly or something.)

The readers do some trusted-computing/secure-enclave type stuff but are not especially hard to obtain; I think there have even been cases where companies like Nintendo have built them into consumer products, so that you could e.g. tap your card to your Nintendo 3DS to buy a video game.

I imagine there's a bit more security on the machines that let you load money on the cards, but it's probably not completely impossible to make a fake card. But the low value limit (usually a couple hundred dollars, depending on the card provider), the inability to get cash out of the system (often you can't even buy things like postage stamps), and the fact that you'll get caught relatively quickly (once the central clearinghouse notices the transactions don't match up) make it unattractive to do it in practice.

> [...] the website tries to aggressively make me download Firefox, with multiple links on the site for it.

> What makes it aggressive?

The parent comment already contained the answer to your question (the multiple links are what makes it aggressive, in GP's opinion). Your comment might have been seen as more constructive if it engaged with that directly.

The Content-Encoding header allows any page to be a literal zip-bomb. That's how early versions of Tailwind worked; you'd deliver a 50KB Brotli payload that exploded into 2MB of CSS ( https://v1.tailwindcss.com/docs/controlling-file-size ). So pages potentially being zip-bombs is already a well-accepted part of the Web platform.

It would be pretty wild if this feature allowed you to go back and add/remove individual tokens from earlier in the document and re-apply all the tree construction rules, like an even more unhinged version of document.write(). I think the actual proposal is expressed in terms of moving DOM nodes around and doesn't allow stuff like this.

As far as I can tell, this is not actually allowed by the current proposal. The definition of the "find markers" algorithm in https://github.com/whatwg/html/pull/11818 requires that the <?end> marker be a sibling of the <?start> marker in the DOM, so they can't have different parents like this.

Well, you're allowed to write it, but the browser will just ignore the <?end> marker. The range will end at the </em> tag, the same place https://github.com/WICG/declarative-partial-updates/blob/mai... says it goes by default if you don't write the <?end> at all. (That default wouldn't make a ton of sense if patch ranges were allowed to break out of their parent elements like this.)

Jake Archibald thinks it'd be cool to use a similar syntax to do CSS highlights, but there are other problems with that (like not being able to create overlapping ranges), and he's not on the Chrome team that's pushing this proposal.