In implementing Rust's serde_json library, I have dealt with both string-to-double and double-to-string. Of the two, I found string-to-double was more complex.
Unlike formatting, correct parsing involves high precision arithmetic.
Example: the IEEE 754 double closest to the exact value "0.1" is 7205759403792794*2^-56, which has an exact value of A (see below). The next higher IEEE 754 double has an exact value of C (see below). Exactly halfway between these values is B=(A+C)/2.
So for correctness the algorithm needs the ability to distinguish the following extremely close values, because the first is closer to A (must parse to A) whereas the second is closer to C:
The problem of "string-to-double for the special case of strings produced by a good double-to-string algorithm" might be relatively easy compared to double-to-string, but correct string-to-double for arbitrarily big inputs is harder.
I guess one aspect of it is that in really high performance fields where you're taking in lots of stringy real inputs (FIX messages coming from trading venues for example, containing prices and quantities) you would simply parse directly to a fixed point decimal format, and only accept fixed (not scientific) notation inputs. Except for trailing or leading zeros there is no normalisation to be done.
Parsing a decimal ASCII string to a decimal value already optimizes well, because you can scale each digit by it's power of 10 in parallel and just add up the result.
For those wishing to read up on this subject, an excellent starting point is this comprehensive post by one of the main contributors of the fast algorithm currently used in core:
> Unlike formatting, correct parsing involves high precision arithmetic.
Formatting also requires high precision arithmetic unless you disallow user-specified precision. That's why {fmt} still has an implementation of Dragon4 as a fallback for such silly cases.
For me the original https link fails with "SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG"
The http link redirected to safebrowse.io/warn.html where there is a "Proceed Anyway" link to get to the content.
The best forecast I know is Sean Parent's on ADSP episode 160.
[0:23:57] SP: We're also discussing internally around pending legislation around safety and security, what Adobe's response is going to be. Right now our thinking is we would like to publish a roadmap on how we're going to address that. That is not finalized yet in any form, but I expect a component of that roadmap is going to be that some of our critical components will get rewritten into Rust or another memory-safe language.
[0:24:28] CH: When you say "pending legislation", is that a nod to some pending legislation that you actually know is on the horizon? Or just anticipating that it's going to happen at some point?
[0:24:38] SP: Oh yeah, no. There are two bills (sorry I don't have...)
[0:24:44] CH: It's all right, we'll find them and link them in the show notes afterward.
[0:24:48] SP: Yeah, I can hunt down the links. The one in the U.S. that's pending basically says that the Department of Defense is going to within 270 days of the bill passing (and it's a funding bill which means it will probably pass late this year - early next year) that the Department of Defense will establish guidelines around safety and security including memory safety for software products purchased by Department of Defense. The E.U. has a similar wording in a bill that's slowly winding its way through their channels. I don't have insight into when that will pass. The U.S. one will almost certainly pass here within a month or two.
[0:25:43] CH: Oh. Wow.
[0:25:44] SP: There's a long way between having a bill pass that says almost a year later they have to establish a plan for what they're going to do, right. So it's not hard legislation in any way. But I view this-- I can send you a link. There was a podcast I listened to recently on macOS folklore. [...] It's talking about how in the early '90s there was a somewhat similar round of legislation that went around around POSIX compliance. Basically the Department of Defense decided that in order to have portable software, every operating system that they purchased had to have POSIX compliance. And there was a roadmap put into place. That's why Apple pursued building their own UNIX which was A/UX and eventually partnered with IBM to do AIX. And Microsoft in the same timeframe had a big push to get POSIX compliance in Windows OS. The thinking was eventually in order to sell to the government your operating system it would require POSIX compliance. What actually happened, if you wanted to buy just traditional Macintosh operating system you would just say "well I require Photoshop or pick-your-application and there is no alternative that runs under UNIX so therefore I need an exception to buy macOS" and it was extra paperwork but it got signed off on. So really never materialized into hard restrictions on sales of non-POSIX-compliant OSes. I expect the safety legislation to take somewhat the same route, which is, there will be pressure to write more software in memory-safe languages. When you don't write software in memory-safe languages there is going to be more pressure for you to document what your process is to mitigate the risks. And this is initially all in the realm of government sales, although there is some discussion in both the E.U. legislation and on the U.S. side of extending this to a consumer safety issue. But there will be an escape hatch because you couldn't wave any kind of magic wand as a legislator and say "you can't sell software anymore if it's written in C++". The world would grind to a halt. So there will be an escape hatch, and there will be pressure. So as a company you have to look at how are you going to mitigate that risk going forward. And what's your plan going to be so that you can continue to sell products to the government. And how do you make sure that you're not opening up a competitive threat. If you've got a competitor that can say "well we're written entirely in Rust so we don't have to do the paperwork" that becomes a faster path. So you want to make sure that you're aware of those issues and that you've got a plan in place to mitigate them.
Thank you. I have mostly heard people confusing the CISA stuff with "legislation," but this sounds like something that is actually legislation. I'll have to dig into it. Thank you.
I am quite sure I saw #01 at $10k earlier today and it's now higher, so I suspect he found out he initially misjudged what Destin's advice of "priced not to sell" would need to mean.
But if you wanted some of what makes this particular piece special you would also have to hire a camera crew to capture the backstory and provenance and an influencer to show it to most of a million people and care about it. The best art isn't just the end result!
My comment was intended to highlight that this kind of money can change someone's life - create a whole new career for them, give them employment. Translate it into developing country terms and you could do that for ten or more people.
Or you could spend the same amount to own a lump of pretty glass that appeared in a YouTube video. Which apparently makes it special for some reason.
I think Ford Escort means something different here in the UK. They've gone up in value hugely in the last 20 years and are generally worth a lot more than Model T Fords now. (Annoyingly they're worth much more than a contemporary Porsche 944, which was much more desirable when new. Annoyingly because I own a 944 and not an Escort).
In fairness, that's the RS2000 which is definitely not a regular ford escort. An ordinary 1980 ford escort isn't worth anything like that much. Maybe 1/10th of the price if in really good condition.
My grandfather was embarrassed because his family had a Model T in the 1940s. 20 years after the end of their production they were seen as junk that only poor people drove. It was better than the buggy his family used but everyone else had nice cars.
Model T's USED to be destined for junkyards.
The few that escaped that fate are now collectibles.
The Yugo used to be what your parents bought for you (paying just a little bit more than the 286 laptop they also got for you) so that you could have something to drive when you went off to college.
My first car was a Karman Ghia that I paid $500 for in the 90s. It was seen as junk. The floor pans were rusting out and it would have cost way more than it was worth for the owner to fix it up so rain didn't spray into the cabin from underneath while driving. Looking at the prices they go for now I highly regret driving it until it thew a rod and then junking it.
Yugo: they sold for $4K new, so a 50% return on something I had to keep in the corner of the garage for 30 years is a pretty poor "investment". And that's assuming someone even wants it; just because it's for sale doesn't mean it's collectible. Model Ts are distinctly different, even in comparison to their younger brother the Model A. Yugos are just shitty versions of what you're driving now. I suspect one will find the same with Ford Escorts.
As a library maintainer, closing and empathetically conveying why a pull request is not a net benefit to the project is an order of magnitude more effort than what it takes to throw up not-well-motivated pull requests on someone else's project.
I would argue that libraries have an additional problem in that there's a many to one relationship between users and maintainer. It feels like there should be a way to design the ecosystems so that the maintainer doesn't end up with so much default expectations.
I think a more generalized version of OP's concept goes into a lot of things.
I thought about this when I first played Minecraft on a multiplayer server where people had vandalized the world. Much harder to keep it tidy than making it ugly. I think they usually solved this by giving mods ability to rewind. Crude but effective.
Like, what makes Wikipedia work? It's easy to go back in the version history when somebody breaks stuff?
It looks like there should be a bunch of tricks that could be used to design these systems so that doing the right thing is easier than breaking stuff.
I see pull requests on my projects from new/outside contributors as suggestions, not actual demands.
Refusing a suggestion doesn't prompt for a full explanation, it also doesn't mean it won't ever be reconsidered potentially.
People who engage in open source contributions are usually aware of this, the fact that they generally can fork and use their own "improvement" for themselves is usually enough, and the people who feel entitled to get their code merged in your repository are usually not the kind of regular contributors you want to keep around in my experience.
There's also similarities with making any change to software.
It's relatively easy to merge code in, but takes much more effort and thought to remove the code later. Especially once other things are dependant on it...
Not automatic, but it already supports a measure of "how much" you depend on a project: boosting. You can boost dependencies up or down by up to a factor of 20 (e^3).
Note that the search you linked also includes crates that only have "rust" in the description or readme, not just the crate name -- that is why it shows a much higher count.
That's cool. I was not able to repro due to the buck2 instructions not working for me, two different ways
Compiling gazebo v0.8.1 (/home/jwb/buck2/gazebo/gazebo)
error[E0554]: `#![feature]` may not be used on the stable release channel
--> gazebo/gazebo/src/lib.rs:10:49
Then with the alternate instructions:
error: no such command: `+nightly-2023-01-24`
Cargo does not handle `+toolchain` directives.
Did you mean to invoke `cargo` through `rustup` instead?
FWIW buck2 doesn't seem to build with nightly-2023-01-24 at this time, nightly-2023-03-15 worked for me. (Nightlies from April cause an internal compiler error.)
Anyway regardless of the fact that my local Rust environment isn't cut out to repro your result, how much of that speedup is due to parallelism that Buck2 offers and Bazel does not? When I build your cxx repo with bazel and load the invocation trace, the build was fully serialized.
