If you liked FF-Shrine, there are some active successor sites. Search for Sitting on Clouds (which is like FFShrine’s Galbadia Hotel) and SquidBoard (a forum).
HN user
roryokane
Email: “rory” + “@” + “roryokane.com”
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 ]
If anyone’s curious about games like this, the Scribblenauts series also has games that allow you to type the name of an object and spawn it in with game-like properties.
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.
Cool idea for sure, but at this point, it’s more confusing than fun for a new player trying to learn the systems and goals of game.
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.
Hypothetically, someone who doesn’t live in the United States and is considering accepting a job there might appreciate the insight from prediction markets on the upcoming U.S. presidential election. If the likely candidate promises to enact policies that would make that person’s life worse, that would give them reason to reject the job offer.
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.
Many diff tools, such as delta (https://github.com/dandavison/delta) and the ones built into VS Code and IDEs by JetBrains, can configured to highlight changes within each line (by word) and ignore changes to whitespace. Those features save me a lot of time when I review diffs that include indentation changes or variable renames.
In history, why did scientists research gravity for so long? Were they too stupid to realize that they were obviously being pulled towards the ground? No. They hoped to learn about the details. Eventually they learned details that were not apparent from everyday experience, such as the formula for how gravity scales with mass.
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.
While larger icons might be ideal, note that (according to those linked discussions) those icons also have associated keyboard shortcuts, which are displayed when you hover over each icon. If you memorized those shortcuts, you would no longer have to “pixel hunt” to switch modes.
I like most of Djot’s simplifications, but its requirement to write nested lists with blank lines between every change in indentation is a dealbreaker for me:
- 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
Yes, supporting indented list items without blank lines in between would make Djot’s parser more complicated. But I write nested lists all the time in my notes, and extra blank lines would distract from the content. For me, it’s not worth it to make my raw text ugly just to make the file easier to parse.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.
Even if you don’t use p4merge, you can set Git’s merge.conflictStyle config to "diff3" or "zdiff3" (https://git-scm.com/docs/git-config#Documentation/git-config...). If you do that, Git’s conflict markers show the base version as well:
<<<<<<< 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
With this configuration, a developer reading the raw conflict markers could infer the same information provided by Manyana’s conflict markers: that the right side added the logging line.Did you know that VS Code added support for the same four-pane view as p4merge years ago? I used p4merge as my merge tool for a long time, but I switched to VS Code when I discovered that, as VS Code’s syntax highlighting and text editing features are much better than p4merge’s.
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.
The whitepaper says that the benchmark counted accessibility problems using the tool axe-core (https://github.com/dequelabs/axe-core). It’s too bad that neither the site nor the paper contains any examples of an LLM output and its list of detected problems. I am curious about these aspects:
• 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.
The section “Utility Classes: Yes, They Still Exist” is unfair in its comparison of Tailwind with pure CSS. It doesn’t take into account Tailwind’s recommendation in https://tailwindcss.com/docs/styling-with-utility-classes#us... that “if you need to reuse some styles across multiple files, the best strategy is to create a component” in your front-end framework or templating language. So its example of a “typical Tailwind component” is incomplete.
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>
This would counter all of the article’s arguments in favor of pure CSS. If the website used a `Button` component like this, it would also be true that the “HTML stays readable”, that “changes cascade”, that “variants compose”, and that “media queries live with components”.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)
It’s not just on mobile – PC Gamer’s website does that on desktop too. Even with uBlock Origin. :(
standardly’s comment has only hyphens, not em dashes. Em dashes are much longer: - vs. —
Jujutsu’s changelog (https://jj-vcs.github.io/jj/latest/changelog/) goes all the way back to 2022 and shows there was a release as recently as two weeks ago. I don’t see why the maintainers would stop at this point.
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.
I made the “sit” gloss long: “to rest your body on your bum (while your bum is on a thing such as a chair or the ground) while your back is up”.
I don’t see anything specifically about boyhood or childhood on that page or on the rest of that sub-Reddit’s wiki. Do you have a more precise link?
Context: the Online Safety Act (https://en.wikipedia.org/wiki/Online_Safety_Act_2023) is a law of the United Kingdom. Previous discussion on Hacker News: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
the two words do not sound even remotely the same
Pronounced correctly, “segue” sounds just like “Segway” – not like “seg-oo”, as you might have assumed.
An excellent example of why dash length matters. Because of the wrong usage of ‘—’ and ‘-’, it took me 10 more seconds of rereading and re-parsing your comment to understand what that first sentence meant.
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.
That’s a misreading of the phrase “proportion of YES votes”. If 30% of judges vote YES, then only 30% – not 100% – of the prediction’s market cap is awarded to those who bet YES. 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.
[The Manifold prediction market] only requires 30% of judges to vote YES for it to resolve to YES.
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.
Finder already has equivalent functionality. You can Copy (Command-C) a file, then Paste and Move (Option-Command-V) it to the destination.
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.
Yeah, I was about to post that it looked like some hybrid of a voronoi diagram and a treemap. More about those diagram types that can be combined in this manner:
1. The mods there can "steal" your post and any credit for it, reassigning its authorship to one of their friends. This happens more often than you would think.
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?
How would you know whether Modified3019’s comment is factual and correct? sureglymop wrote “note: this was a different registrar than mentioned here”, and they haven’t written any other comments in the thread that might identify the registrar.
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.