FYI, macOS 26 Tahoe introduced a first-party clipboard manager too. Official docs are at https://support.apple.com/guide/mac-help/search-your-clipboa... and a more detailed guide is at https://www.cultofmac.com/how-to/mac-clipboard-history#enabl....
1,719 karma · joined March 23, 2009
Website: http://roryokane.com/
Keybase proof (though I don’t use Keybase for anything): [ my public key: https://keybase.io/roryokane; my proof: https://keybase.io/roryokane/sigs/sGwg5k79ih95jibooICWeZN7bdtiHdJ5YB4107c2x30 ]
Some features that may help with this:
After opening the Shift-Command-5 screenshot interface, in the “Options” menu, you can change the folder your screenshots are saved to from the Desktop to any other folder of your choice. Files will still be saved, but you may find it easier to organize those files, as they will be separated from anything else on your Desktop.
After opening the Shift-Command-5 screenshot interface, in the “Options” menu, you can change the save location to Clipboard. Or when taking a screenshot with any other shortcut, you can save just that screenshot to the clipboard by also holding Control. Copying to the clipboard ensures there is nothing to clean up afterward.
If you want to take two screenshots and then paste both, you can still use the clipboard if you enable macOS’s clipboard history feature. That would let you copy both screenshots, then paste them both into your app. To enable clipboard history, see official docs at https://support.apple.com/guide/mac-help/search-your-clipboa... or a more detailed guide at https://www.cultofmac.com/how-to/mac-clipboard-history#enabl....
Scribblenauts is not LLM-based – its first game was released in 2009. The creators just spent a lot of time making a database of objects that people might ask for, their game properties, and what they look like in the game’s simple art style. Scribblenauts is also different in that it is a 2D puzzle platformer set in small levels that have their own goals, rather than a top-down MMORPG like Asciidia.
While I found the concept of Scribblenauts cool, I quickly grew bored of the puzzle levels and the shallow combat mechanics. It didn’t help that a Black Hole could solve almost any problem by destroying an obstacle. This game’s monetary cost for casting solves that, at least, though I don’t know if the economy would be a significant limitation in the long term.
Some people have griefed the starting area by placing turrets that kill your character when you’re in range. It makes for a confusing first 10 minutes when you wander around and aren’t sure why you’re dying. Even after that, it’s not clear to me how to interact with hostile structures, or how to tell which structure is on my team and will therefore attack me.
I tried creating a few weapons, but neither worked. I had a Short Bow equipped and Arrows in my inventory, but the Short Bow kept saying “out of ammo”. Same with a Torpedo Launcher when I had Photon Torpedoes in my inventory. When I created a plain Torpedo, I could shoot it, but it just flew off and disappeared without affecting the structure I aimed at.
There is an NPC asking for a boat, which is a cool idea for using the conjuring system, but I can’t get near him for long without dying to a griefer’s turret, so I don’t feel like trying to solve his quest.
Other hypothetical prediction markets whose insights would be useful include those used in futarchy, a proposed government system in which decisions are made based on betting markets. The proposal: https://mason.gmu.edu/~rhanson/futarchy.html; some analysis: https://www.lesswrong.com/w/futarchy. In futarchy, prediction markets would be set up for, for example, “average happiness of citizens (as measured by regular survey) will increase in 1 year if Bill ABC passes” and “average happiness of citizens will increase in 1 year if Bill ABC does not pass”. The government would pass or reject proposed bills according to whichever market predicts higher happiness, and the market describing the event that did not happen would be closed and its money refunded.
It’s the same here. For example, this study concluded that most changes are safe and some are very bad, as opposed to most changes being slightly bad. That is not obvious, especially to infrequent LLM users.
Also, even “obvious” conclusions are within the scope of science. I’ve spent too long writing this already to look up an example, but I bet there have been countries in the past whose leaders chose “obviously-good” monetary policies that economic research could have shown was counterproductive. The world is complicated, and without systems of communication such as academia, it’s hard to be sure if what you see is what everyone else sees.
- Djot requires
- writing nested lists
- with blank lines in between
- successive list items at the same level
- can skip the blank line
- but not this list item
Djot could have avoided the blank line requirement by not trying to join hard-wrapped lines back into one paragraph / list item. That would work for me because I only soft wrap my text. Djot’s choice to support hard wrapping caused all of its users (including those who hard wrap) to have worse nested list syntax.
<<<<<<< left
||||||| base
def calculate(x):
a = x * 2
b = a + 1
return b
=======
def calculate(x):
a = x * 2
logger.debug(f"a={a}")
b = a + 1
return b
>>>>>>> right
I also use the merge tool of JetBrains IDEs such as IntelliJ IDEA (https://www.jetbrains.com/help/idea/resolve-conflicts.html#r...) when working in those IDEs. It uses a three-pane view, not a four-pane view, but there is a menu that allows you to easily open a comparison between any two of the four versions of the file in a new window, so I find it similarly efficient.
• Which of axe-core’s rules (https://github.com/dequelabs/axe-core/blob/develop/doc/rule-...) LLMs violate most often
• Which groups of users are most affected by those rule violations (e.g. blind users or deaf users)
• Whether it’s likely that I unintentionally violate those same rules in web pages I write
Examples of rule violations and statistics on most-violated rules would make the website more convincing by showing that the detected accessibility errors reflect real problems. It would rule out that the only detected error was a single noisy false positive rule in axe-core. I bet that most readers are not familiar enough with axe-core to trust that it has no false positive rules.
A better comparison would use, for example, a React component:
function Button({ children }) {
return (
<button
className="inline-flex items-center gap-2 px-4 py-2 rounded-full
border border-gray-300 bg-white text-gray-900
hover:bg-gray-50 focus:ring-2 focus:ring-blue-500"
>
{children}
</button>
);
}
// Usage:
<Button>Save</Button>
A better argument against Tailwind would be the added complexity of having a build system and a front-end framework or templating language, if your project doesn’t already have those for other reasons.
(adapted from my better-formatted comment at https://lobste.rs/c/oznzzj)
Also, from Jujutsu’s README (https://github.com/jj-vcs/jj#mandatory-google-disclaimer):
> I (Martin von Zweigbergk, martinvonz@google.com) started Jujutsu as a hobby project in late 2019, and it has evolved into my full-time project at Google, with several other Googlers (now) assisting development in various capacities.
Pronounced correctly, “segue” sounds just like “Segway” – not like “seg-oo”, as you might have assumed.
I see what you did in the second paragraph too. It’s another example of “a millimeter of difference in the length of a line” mattering in that it looks weird, though it’s not much harder to read.
The market correctly rewards those who bet NO in such a case. Therefore, bettors have no reason to bet YES if they really think NO.
That’s a misreading. If 30% of judges vote YES, then only 30% of the prediction’s market cap is awarded to those who bet YES, while the remaining 70% of the market cap is awarded to those who bet NO. The market correctly rewards those who bet NO in such a case. Therefore, bettors have no reason to bet YES if they really think NO.
I think those are better names for the two steps of moving files than Cut and Paste. Cut implies deleting the file immediately, which isn’t what Cut does in file browsers that support such a command.
Really? As a Lobsters reader, I occasionally review the first page of the Lobsters Moderation Log, which is public for transparency’s sake: https://lobste.rs/moderations. And I’ve never seen any log about a story’s authorship being reassigned, whether for a good reason or a bad one.
According to my reading of the source code of Lobsters (https://github.com/lobsters/lobsters/blob/96cf0b32ee81bb1bd7...), such a change would be described in the Moderation Log as “changed user from the_original_user to another_user”. I just searched all moderation logs of story changes in the last two years (39 pages of logs), and no log contains the string “changed user from”. So whether “stealing” of posts ever happened, I don’t think Lobsters users have to worry about that happening now.
Or are you also accusing the mods of hiding those specific changes from the Moderation Log somehow?
> 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.
The game was released on 2024-07-31.