roryokane

I don’t think the article is overcomplicating the Git commands to falsely represent how complicated Git is. I can easily believe that in some contexts, a Git user really would need to do all the steps the author describes.

> 1) do your test in your current branch, it's related to what you are doing.

The article describes a scenario where you “feel reasonably assured that green CI will mean you’re on the right track, and you’ve been removing parts of the old parser as you introduce the new”. But this one parser feature you discovered was not under test. “The original parser is half-taken to bits,” so perhaps you already deleted the implementation of that feature, not knowing it was depended on. If the implementation were missing, of course you couldn’t test it on your current branch.

Okay, let’s say you didn’t delete the implementation yet – but the implementation calls some of the methods you already modified. If you write a test on your current branch, it would only show that your already-modified parser passes the test. You couldn’t be confident that the expectations in the test you wrote actually match the behavior of the old parser. If the old parser acted differently from your tests (even if it was due to a bug), you need to know about that so you can update callers of the old parser to not rely on that behavior any more.

To be confident that your new test accurately describes behavior you need to support, you need to run the new test against the “develop” branch.

> 2) … You're going to squash rebase at the end anyway...

Why would you assume that? Some teams prefer to express changes as a series of independent commits when possible, and they merge PRs while keeping those individual commits. My current team is one example. On such teams, keeping a Git feature branch’s history organized is a real need.

If you wonder why a team wouldn’t just squash rebase, I think the goals of keeping commits separate on the main branch are to make debugging tools such as `git log`, `git blame`, and `git bisect` more useful.

In summary, Smack Studio is a fighting game with a character editor that can rotate any 2D pixel art sprite as if it were 3D by extrapolating a depth map. You can export the resulting sprites for use outside of the game.

The game was released on 2024-07-31.

I can save you some of that research. The KeePass family of password managers are open source and based around a shared file format. They save your passwords in an encrypted file on your computer or phone’s local drive. An ecosystem of apps by different people can parse that file format (after you enter your master password), and at least one app can export as CSV or HTML, so migration is not a problem.

Since your passwords are in a local file, there is no online password manager that can be hacked. If you worry that your local password manager software will have malicious updates posted, you only have to read news at the time you download an update, which can be as infrequent as you like.

If you need to share passwords among your devices, you can store the encrypted file in a generic file syncing service such as Google Drive or Dropbox. Those services are less of a target for hackers than dedicated password managers, and even if someone obtains that file, your passwords will be safe as long as your master password is strong.

Specific KeePass clients I recommend: https://keepassxc.org/ on desktop, https://github.com/PhilippC/keepass2android on Android.

Phorge (https://phorge.it/) already exists. It’s a still-maintained fork of Phabricator.

The more relevant post is the the one from the cohost maintainers linked in that post’s first comment: https://cohost.org/staff/post/6403911-may-2024-financial-u. In summary, at that time Stripe forbade use of their service to pay for tips or subscriptions that do not result in access to exclusive content.

Neither is true.

In Finder you could always drag and drop a file to move it. (In certain cases I forget the details of, holding Command is necessary to move instead of copy, as indicated by the cursor.)

Since about 8 years ago, you can also move a file via the keyboard by selecting the file, hitting Command-C to Copy, navigating to the new folder, and hitting Option-Command-V to Move the pasted file. This doesn’t match Windows’s Cut/Paste workflow, but I think Copy makes more sense as a first step. For consistency with Cut elsewhere, one would expect Cut to delete the file until it is pasted, but on Windows it doesn’t.

Finder windows are resizeable in the same way as all other macOS windows. In older versions you had to drag the drag handle in the bottom right. For a while now, you can drag on any window border, when the cursor turns into a double arrow. You can also click or Option-click the green window button to make the window full-screen or zoom it to show all contents.

ZetaSQL’s docs for the ‘OVER’ keyword you mention: https://github.com/google/zetasql/blob/master/docs/window-fu...

I disagree that the paper not mentioning ‘OVER’ implies that the paper authors secretly think pipe syntax is a bad idea. They probably just wanted to keep the paper concise, or forgot about that one less-used bit of syntax.

Do you think that ‘OVER’ keyword implies something fundamentally wrong about pipe syntax? If so, how?

Hacker News filters out Unicode emoji characters from comments (example: ), so it’s not “of course”. I assume the developers think emoji are too distracting.

Link: https://timoni.sh/

`git blame` lets you identify the commit that changed the line you’re looking for, but doesn’t make it easy to then view further details. The author might prefer GitHub’s blame view because it has these features:

• each hunk has a link to the commit that changed it, as opposed to needing to copy a line’s SHA and then run a new `git show …` command

• each hunk has a link to view the `blame` as of that older commit, as opposed to needing to copy a line’s SHA and then run a new `git blame … path/to/same/file` command

• the code is syntax highlighted by default, without you needing to configure your local Git install to use https://github.com/dandavison/delta

These features lead to a better experience than `git blame`. Various IDEs, editor plugins, TUIs, and GUIs provide similar features.

On macOS, I’m happily using Meta for Mac (€25) to edit music metadata tags of individual files: https://www.nightbirdsevolve.com/meta/ .

I still store most of my music in iTunes (renamed to Music in later macOS versions). I’m also happy with the tag editing of iTunes, especially after installing some custom tag-editing AppleScripts from https://dougscripts.com/itunes/index.php and modifying some of those scripts.

However, I am rethinking storing all my music in iTunes given that it can’t play Opus or FLAC files (last I checked) and it makes loud glitchy sounds when it plays an MP3 file whose sample rate is 32k instead of 44.1k. I’ve already had to give up on storing all my music files in the iTunes folder now that my entire music library doesn’t fit on my laptop’s storage. Thus, I have been using Meta more.

Edit: I see another commenter also mentioned Meta and Music.app: https://news.ycombinator.com/item?id=40471849

That’s not an “other” gateway path… it’s an example of the same path described in the post you replied to.

What is an MSP?

Good point, but I think Crichton’s original example still makes some sense. One’s choice of newspaper could affect the trustworthiness of articles by multiple journalists:

• Some articles may be edited by the same editor. If you see inaccuracies in an article by one journalist, you may worry that the editor is bad at fact-checking.

• Even if every article is edited by a different editor, if the newspaper’s work environment is rushed such that editors are told not to spend more than two minutes thinking about accuracy, it might have more inaccuracies than a newspaper that allows more fact-checking time. (In other words, newspapers have their own publication standards.)

• Newspapers set standards for what journalists to hire and retain. A newspaper that keeps paying for articles by a journalist who have been known to make mistakes is more likely to not care about mistakes they know of by their other journalists.

Bringing this analogy back to LLMs: if you see one LLM make mistakes, you should be suspicious of the accuracy of a competing LLM to the extent that the competing LLM has similar “journalism” and “publication standards”.

For reference, `git log --topo-order` docs: https://git-scm.com/docs/git-log#Documentation/git-log.txt--...

Thanks. This slower-paced video is more precisely explained and more visually comprehensible than the Rachael Ray video linked in another comment.

Just like lelanthra currently applies custom CSS `body { max-width: 38rem; }` to this page, if the page had that maximum width set by default, you would equally have the ability to apply the CSS `body { max-width: unset; }` to the page. So you would not be denied the option of longer lines.

This page from 2023-07-12 says OBS can capture audio of individual windows in Windows 10 and up: https://obsproject.com/kb/application-audio-capture-guide

Both are wrong. tcmb didn’t use ‚comma-apostrophe’ – they opened with , U+201A SINGLE LOW-9 QUOTATION MARK (not U+002C COMMA) and closed with ‘ U+2018 LEFT SINGLE QUOTATION MARK (otherwise known as an open single quotation mark).

This matches the German convention described on https://en.wikipedia.org/wiki/Quotation_mark#German.

This submission from 10 hours later has comments: https://news.ycombinator.com/item?id=39187294

A product description is available if you click the “View full details” link to the bottom right of the Buy button, which leads to https://migswitch.store/products/mig-switch-pre-order. I agree that that information should be more prominent.

Yeah, or over https://github.com/sindresorhus/execa?

And given the existence of those npm packages, is there any aspect of Bun Shell that required it to be built into the Bun runtime instead of published to npm?

I agree with the above rationale, so I just flagged Super Mario Run for Android and iOS with an explanation along those lines.

According to a survey summarized in this post from 2021 (https://www.astralcodexten.com/p/updated-look-at-long-term-a...), “people who work in ‘AI safety and governance’” “mostly assign “low” probability (~10%) that unaligned AI will result in human extinction”. They more commonly worry about other scenarios that are still very bad for humanity.

To give one example, an AI could be instructed to reduce the crime rate, but rather than preventing people from committing crimes, the AI could decide it’s easier to prevent all victims from reporting crimes to anybody. That would remove the threat of law enforcement that currently prevents many people from turning to crime. Such a society probably wouldn’t cause human extinction, but would still be horrific and worth preventing.

If you are skeptical that AI that is trapped in software could gain any significant real-world power (not necessarily the power to kill all of humanity), https://slatestarcodex.com/2015/04/07/no-physical-substrate-... describes some possible mechanisms.

I agree that “learning your mother tongue did not require you to sit and study” is an exaggeration – my schooling included years of sitting and studying grammar during the English class for native speakers, and I probably learned to speak better as a result.

However, I think at least a significant subset of grammar is only learned implicitly, never taught in school. The classic example of this is adjective order (https://www.grammarly.com/blog/adjective-order/): native English speakers know that “the nice orange cat” sounds better than “the orange nice cat”, but most can’t explain why.

Maybe they was intending to say that “they” is painful when paired with singular verbs like “is”, “are”, and “was”? I, at least, find that previous sentence painful.

I agree that the patience diff algorithm generally produces better results, but you don’t need the patdiff tool for that. You can configure Git’s own diffs to use patience: https://git-scm.com/docs/git-config#Documentation/git-config...

I see that patdiff also provides word-level diffing. You could instead get that feature with `git diff --word-diff` or Delta (https://github.com/dandavison/delta).

P4Merge (https://www.perforce.com/products/helix-core-apps/merge-diff...) is a similarly powerful (and similarly ugly) tool for plain text diffs and three-way merges. It’s free, and though the 500 MB download includes Perforce, you can install P4Merge by itself. Unlike Beyond Compare, though, P4Merge cannot highlight syntax in the compared files.

(2019)

Past discussions:

https://news.ycombinator.com/item?id=21693431

https://news.ycombinator.com/item?id=21698619

https://news.ycombinator.com/item?id=27533684

It’s not just user error – it’s a problem with the YAML format and culture. The YAML format allows most strings to be written without quotes. And YAML culture, as communicated through most YAML snippets in documentation and YAML files in the wild, is to take advantage of this by only adding quotes when necessary. That makes certain categories of user error much more likely. Someone might write `09` and confirm it’s a string, then change `9` to `7` and not notice that their string has turned into a number.

The JSON format avoids this problem because it requires that all strings be quoted. If you start with `["09", "08"]` and change one of the digits inside the quotes, the string will stay a string. In JSON, strings becoming not-strings – removal of quotes or addition of backslash escaping – is more obvious than in YAML.