Most people don't write a basic compiler for C either, "relatively simple" or no. Most people would rather add a new target to an existing compiler, which is much easier.
It's also "relatively easy" to add a new backend to Rust.
It’s being sorted not once per frame, but once per item.
If you have 50 items in the list, then the list gets sorted 50 times. If you have 200 items in the list, the list is sorted 200 times.
This is unnecessary. The obvious alternative is a binary heap… which is what the fix does. Although it would also be obvious to reuse an existing binary heap implementation, rather than inventing your own.
> It’s being sorted not once per frame, but once per item.
Even if that were the case, sorting a list that's already sorted is basically free. Any reasonable sort method (like the builtin one in a JS runtime) will check for that before doing anything to the list.
> The obvious alternative is a binary heap… which is what the fix does.
The overhead of creating a heap structure out of JS objects will dwarf any possible benefit of avoiding a couple of calls to Array.sort().
> Even if that were the case, sorting a list that's already sorted is basically free. Any reasonable sort method (like the builtin one in a JS runtime) will check for that before doing anything to the list.
That’s n−1 pairs of elements that have to be compared with a a JS callback each time. (JavaScript’s combined language misfeatures that allow the array to be modified in many odd/indirect ways while it’s being sorted might add unusually high overhead to all sorting too – I’m not sure how much of a fast path there is.) Anyway, the code in question does include functionality to add new elements to the priority queue while it’s being processed.
> The overhead of creating a heap structure out of JS objects will dwarf any possible benefit of avoiding a couple of calls to Array.sort().
Not true even in general and with an unoptimized heap implementation, and in this case, there’s an array of JS objects involved either way. In fact, there’s no number of elements small enough for sorting to be faster in this benchmark in my environment (I have no idea whether it reflects realistic conditions in VS Code, but it addresses the point): https://gist.github.com/minitech/7ff89dbf0c6394ce4861903a232...
I’ve been using Magit at work because it’s what everyone uses, and it just does useful shit I need to do, like help me revert specific chunks from an old commit, or migrate chunks to a different branch, or whatever. Stuff that I know how to do in Git, but I’m tired and it turns out Magit is just a lot faster and more interactive.
I have a long history of hating Git UIs but somehow Magit is the one exception. I’ve done a lot of surgery on Git repos in the past so I’m no slouch on the command-line, Magit just lets me do it all faster.
I think they key to me is that it is really just helping you write git command lines. The menus are laid out exactly like the options of the relevant git sub-command, so that using Magit makes you more proficient at the CLI and vice versa. Other GUIs (including the awful ones that tend to be built into editors and IDEs) are instead hiding these details from you, so that if you are proficient at git on the CLI, you are still starting nearly from zero with the new interface and vice versa.
Idea: a general tool that helps you write command lines. It reads the help or man page and generates a GUI or TUI to present all the options in a logical way. You just fill out the form and it does the thing
Your comment caught my eye because as the de facto neurosurgeon, I’ve watched way, way too many UIs glitch a coworker into an impossible or unpleasant state and been the only one who didn’t immediately break eye contact. And remember they had someplace else to be. From CVS to SortaSafe to P4 to SVN. By the time I got to svn and saw the same issues I started spending political capital on convincing people to only use the CLI or maybe, maybe, JetBrains.
Usually the upvotes come from the casual users and the muttering from the heavy ones. In light of what I said, would you still recommend magit?
I’ve never met a casual Magit user. They’re usually people who have decided to invest time in learning Emacs or Spacemacs, at the very least. Some of them have massive .emacs files and take notes in org-mode. The casual users would probably be using VS Code or Jetbrains instead.
If anything, Magit has helped me AVOID getting in a bad state, because it automatically shows me more information and context than what I get from the Git command line (despite all this fancy Git stuff I put in my prompt). When I’m committing in Magit, I see some weird hunk I didn’t mean to commit, and I can seamlessly edit it, because I’m already in the editor.
I beg to differ. I wouldn't praise magit if it was just another power user UI that required to become a black belt to do anything.
magit is a (somehow) thin layer on top of git output, and the brilliance comes from
- keeps the information similar to git cli
- depending on the context it allows to use indirect features (chunk staging) live from the diff
- for most use cases it will infer obvious flags/parameters from where you're at.
e.g: if you're on branch and start rebasing, it will soft-infer the source and target branch.
another one, in the log view, selecting a few commits and diff will get you the diff for that range
it basically reify the informations from the output transparently for you and reuse it where useful, saving you input and efforts multiple times per day
- lastly very low complexity so it's quick and out of your way. every time I have to pair, my colleagues say they couldn't follow what I did because by the time I started talking about staging/pushing, I'm already finished and back to source
When I say “casual magit user”, I mean “magit user who is a casual user”, not “somebody who is a casual user of magit”. I just mean that I haven’t met people who use magit who don’t already know how to use git on the command line.
The inference of flags and parameters is also helpful, yeah. I’m remembering times where I’ve done something in magit and it’s auto-populated some commit or branch name, and I’m like, “Yup, that’s the right one” which saves me fifteen seconds of looking up the right name. It makes sense that the command-line interface to Git would expect me to be more explicit.
To emacs user, not knowing that magit is emacs is worth a down vote prima facie :)
I share your horror for GUIs ineffectively hiding the version control reality; but then, despite being an emacs and casual magit user, I still mostly git add files one by one, having git diff the files one by one, and assembling the changed files into coherent groups.
I have a keyboard dance that feels like choreography or maybe, at this point, ritual prayer.
There are definitely shortcuts I could take in some scenarios but walking the safe path even though it's a little longer is the sane response especially when you can type as fast as most of us and you've been using a bourne shell as long as I have.
Or if I'm being more charitable, it's about staying outside the yellow tape lines on the factory floor. No exceptions.
The only downside I've found to magit is that the UI refresh can be slow with very large commits: when you're adding a thousand generated files, doing a big find/replace, etc. In the shell you'd just be running `git status` or `git diff src/foo/` or some such targeted command and would get near-instant results.
The flip side is that I've never seen magit end up in an inconsistent state, which is probably for the same reason it's slow: it's not doing anything "clever," just directly showing you the information it got from git.
I don’t share work details. But everybody on my team uses either Emacs or Spacemacs. There are people at work who use other tools, like VS Code for sure, but Emacs and Spacemacs usage are widespread.
When I say “everyone” uses Magit, I want to clarify that I’m being hyperbolic.
A lot of consensus building with technical people who ask hard questions.
Code review is kind of brutal.
A lot of time spent dealing with custom systems that should have been replaced with off-the-shelf, open-source alternatives like five or ten years ago.
So, having been around a lot of different communication methods, I think email lists aren’t ideal, but for serious projects they’re better than all the alternatives.
Chat has a way of getting completely lost. All your knowledge that goes into chat either goes into somebody’s head or it just disappears into the ether. This includes Slack, Discord, Teams, etc. Useful as a secondary channel but serious projects need something more permanent.
Bug tracking systems just don’t support the kind of conversations you want to have about things. They’re focused on bugs and features. Searchability is excellent, but there are a lot of conversations which just end up not happening at all. Things like questions.
That brings us back to mailing lists. IMO… the way you fix it is by having redundancies on both sides of the list. People sending messages to the mailing list should send followup messages. You should also have multiple people reading the list, so if one person misses a message, maybe another gets it.
Mailing lists are not perfect, just better than the alternatives, for serious projects.
The static pages are there for browsing. They load fast, and I like the entire thread being on one page. No clickety-clicking and forgetting where you are in a forest of postings.
they are both messages in threads. what's different is the presentation.
some of the forums i use support both seamlessly, and i can choose which interface i prefer.
of course for the issue we are discussing, presentation is what matters. but, for most forums i do not believe they would have made it any easier to not miss a message. just look at hackernews. it is actually quite difficult to track which messages i have not read yet, (even if there is a marker on what's new) and it is therefore very easy to miss some.
that is not the case with email. because my mail client tracks the rad/unread status for each message. the problem with RMS has nothing to do with the form of a mailing list but with his particular async style of accessing the internet.
Piling on about chat. Slack threads are an abomination. They aren’t inline with the main channel so you can’t cut and paste an entire conversation with threads. And does exporting a channel include threads? Who knows because the admin wouldn’t do it for me.
Threads were introduced in, what, late 2016? The start of 2017? Some time around then, anyway. They were even more badly integrated at the start; there was no way to be notified about new messages in a thread, for example. By 2019 things were a little better, but - as you noticed - still not great.
And since then... nothing. No more improvements. Development seems to have more or less halted since the Salesforce acquisition.
I used irc for a couple of decades before Slack, so was happy with purely linear chat (yeah, I'm also one of those weirdos who likes rebasing in git). Threads make everything more horrible, but at this point it feels like I just have to put up with it.
> (yeah, I'm also one of those weirdos who likes rebasing in git).
I like both rebasing and threads. More generally, I hate hate hate the 20+ individual messages on a single topic in a channel. It's just so annoying, threads are great for stuff like that, and give you one target for a reminder/update on whatever the issue is.
And yet, every time I change companies I realise again how much most people just don't threads on Slack.
it's not the existence of threads that are the problem but their presentation. instead of hidden threads i'd prefer to be able to quote an message and have it shown inline. the fact that threads are so hidden is a major reason to avoid using them (for me at least)
alternatives:
discord has inline quoting and threads. treads are a bit more visible.
zulip creates a new thread for every message because it prompts you to set a topic, and then you browse the messages by topic.
Nobody uses them? You need better companies :-)) I've worked at a startup using Slack and a huge company using Slack plus I've seen a bunch of other companies. They were all using threads everywhere, they're incredibly useful, especially for big or active channels.
> Nobody uses them? You need better companies :-))
To be fair, this is hyperbolic. To clarify, small groups within most orgs tend not to use threads in their internal channels AND congratulate everyone on their birthdays. The combination of this irritates me due to repeated notification spam.
What are the current practical non-self-hosted options for an open source project mailing list? We (portaudio) are being (gently) pushed off our .edu-maintained mailing list server, google groups is the only viable option that I know about, and I know not everyone will be happy about that choice.
Freelists[1] is still around, LuaJIT hosts its mailing list there. So is Savannah[2]. Would also be interesting to know if it’s actually realistic to ask Sourceware[3] to give you a list or if those pages only reflect the state of affairs from two decades ago. (Only the last of these uses public-inbox, which I personally much prefer to Mailman.)
We use Mattermost and it’s working pretty well. The search is decent and it captures a lot more of the daily chitchat that isn’t long/serious enough for email and would otherwise be lost. The real benefit comes when you need to find some snippet that know was discussed 18 months ago and too much water’s passed under the bridge to remember exactly what was said.
All this hand-wringing about surveillance powers is not keeping up with how quickly our ability to surveil people is expanding. The fourth amendment seems kind of like a wet fart in a timeline where private companies can surveil the public and then simply choose to share their data with law enforcement.
I had to buy a surveillance camera recently, but I made sure mine doesn’t connect to the internet in any way.
How does your total solution work? Today, there's a lot of convenience with Nest. Is there an equivalent experience that doesn't involve exposing your data to megacorps?
Not having to expose data to mega corps is one part of the solution, but more so there should be a solution where government can’t so trivially circumvent 4th amendment by purchasing the data from corps they’re not allowed to collect w/o a warrant.
I mean the feed has to be written to a storage and this storage I immediately backup off-site in the case someone is clever enough to immediately go for such (e.g. burglary).
I think one of the traps we fall into is imagining that an attacker is somehow intelligent (someone who can immediately attack video storage) but simultaneously uncreative (doesn’t think of some way to make the surveillance footage irrelevant).
I’ve decided that I’m not a high-profile target for covert operatives, but I am a target of opportunity for people who have access to my data once that data is outside of my control. The decisions I make based on that are decisions like, “No surveillance feed goes into cloud services operated by companies I don’t trust,” but “I don’t need to encrypt my NAS”.
Stupid burglars get caught. It is only a matter of time till burglars learn to combat this. For example, a MITM on the camera. Thing is, neighbors also got one. If I get threatened to remove the video, I will oblige. If everything gets destroyed in a fire due to cobra's, there's a backup. That's my threat model. And silent data corrupt on the camera feed storage could also occur.
(Decay isn’t memory-less by definition, but we’ve empirically observed that it’s memory-less, and our current theories model it as memory-less. This is the opposite of “by definition”—“by observation” or “empirically”.)
Somehow this has been in the news recently but it’s been happening for a long, long time. There are some foods I just kinda dread and don’t order because they’re the same everywhere. If they’re the same everywhere, it’s because they’re little more than frozen bags and boxes shipped in from Sysco, and I can make the same thing at home.
If you like unique local eats that aren't chains and have regional specialties I recommend Roadfood website and book. It was started by two food critics who loved roadtrips and hated chains so they wanted to find authentic local places: https://roadfood.com/
Maybe you’ll hate me for this but when I hear food described as “authentic” I assume that the place is touristy! Something about the word “authentic” stands out like a red flag in restaurant reviews, warning me away.
I like places with negative reviews. The right people have to hate it in order for me to like it.
Heh.. I get your point! What I meant by authentic is more regional local faire, house-made. For example they recommended this place called Als in Barberton, Ohio that specializes in Barberton chicken which was one of the most amazing meals of my life. Totally worth visiting if you are driving through Ohio:
> The chicken recipe and the meal itself were brought to the New World from Serbia when the Topalsky family immigrated to the farmland of Ohio at the beginning of the 20th century. After they opened Belgrade Gardens, three more restaurants in town began serving the same chicken dinner, which is now Barberton’s claim to culinary fame. Barberton chicken aside, there is one other essential stop in town: Al’s Corner Restaurant. A modest storefront that serves only lunch, Monday through Friday, Al’s is affiliated with Al’s Quality Market just down the street, which is where its sausages are made. The sausages are divine, as is everything else on an Hungarian-accented menu that includes chicken paprikash, halushka, stuffed cabbage, and pierogies.
But literally everywhere I've tried that's been recommended in that book has beem a gem, I check it before every road trip to see what's nearby my planned route.
It depends on who's saying “authentic”; if it's a legit chef, food critic or expert in that type of cuisine, versus someone just trying to pump reviews and scores e.g. on Yelp.
The term “authentic” can be misused, just like “homemade” and many others...
Not necessarily the best idea. Often they are the only dry bulk(flour, etc.) or paper/plastic distributor that a restaurant can access. See if they also get deliveries from others before jumping to such conclusion.
Restaurants hate Sysco just like you do. They deliver late, get it wrong every time and argue about rejection when half their delivery is destroyed goods.
I've worked at Michelin starred restaurants in major cities that ordered paper products as well as commodity items from Sysco. Like I said, it isn't a particularly good metric.
I think unfortunately this is a massive conflux of many negative rentseeking factors that creates a blackhole of mediocrity.
A lot of local restaurants in Seattle can't afford space rent, but then when they leave those spaces stay empty. The restaurants that do thrive are part of big multinational chains or have to serve the same slop as everywhere else because it's the cheapest. Combined with increasing consolidation, everything converges towards low quality shit.
Fixing this would require, like a lot of our self-inflicted problems, realizing that big corporations and consolidation is slowly strangling everything.
Someone can break out their chemistry references, but I think N₂O is probably not workable as a fuel (or at best, not very good). It forms naturally in internal combustion engines, from air, at the temperature and pressures found in engines, given O₂ and N₂. If something has the habit of forming in an engine, I don’t think you could use it as fuel, but my thermodynamics is a bit too rusty to do any kind of ELI5 and I could just be wrong here. At the very least, it would be difficult to use or inefficient.
It decomposes into N₂ and O₂ at normal atmospheric temperatures and pressures, outside an engine.
You're probably thinking of NO2, which is indeed a pollutant that results from overly hot combustion in air. N2O is in fact used in engines, but it is not the fuel -- rather it is a supplementary oxidizer, which allows you to burn more fuel and therefore produce more power than you could if you only had the oxygen from air. At any rate, that means using N2O won't be a solution to the aircraft fuel problem -- you'd still need a combustible fuel for it to oxidize.
You are correct that N2O is the "nitro" afterburner used in different systems.
But the reaction 2 N2O => 2 N2 + O2 is very exothermic, in fact it is explosive (but not in the burning sense, since its autodecomposition). However adding a small amount of ethanol makes N2O stable so that sudden shocks or compressions don't result in initiating autodecomposition or explosion.
To power an engine one doesn't necessarily need to burn, or a redox reaction to happen, the reaction just needs to be exothermic and N2O is very exothermic.
It’s wild, but couldn’t we also explain this with a theory like “people have more trust in the institutions holding gold, and want better rates when they buy/sell?” Older generations seemed, to me at least, that they had some distrust in financial institutions, and maybe the newer gold buyers trust that their gold deposits work but don’t trust dollars or stocks as much.
Yeah, I feel the same way. JC2 and JC3 are great. Never clicked with JC4.
I had always thought the north island was empty because it was used for the train mission. Like, the island existed as a backdrop for a few missions near the end of the game.
Also nice to hear that the devs also thought the wingsuit was overpowered. That’s part of what I like about JC2: no wingsuit.
It's also "relatively easy" to add a new backend to Rust.
There's a policy document for Rust here: https://doc.rust-lang.org/rustc/target-tier-policy.html
There are a lot of things that can go wrong. You want to be able to test. Being able to test requires that someone has test hardware.
reply