Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Licensing under an Apache2.0/MIT License? #72

Open
Alexhuszagh opened this issue Dec 7, 2024 · 1 comment
Open

Licensing under an Apache2.0/MIT License? #72

Alexhuszagh opened this issue Dec 7, 2024 · 1 comment

Comments

@Alexhuszagh
Copy link
Contributor

Alexhuszagh commented Dec 7, 2024

I'd be interested in having discussions with merging this algorithm into the Rust standard library, since Rust currently uses Grisu and it has known issues including in the Rust implementation. However, this would require dual licensing it under the MIT license. Since I've already done much of the work porting this to Rust, it might be useful contributing to the core library, if desirable.

This would require discussion since the tradeoffs with Ryu, which would be better for embedded systems, might be noticeable in limited resource environments.

Related to: rust-lang/rust#52811

Another issue could be requiring all contributors to sign off on this change, which might be difficult.

@jk-jeon
Copy link
Owner

jk-jeon commented Dec 9, 2024

First of all, thanks for your contribution and continued interest!

Regarding the license, (1) I do not want to change the license of this library, and (2) but I do not mind redistributing a derivative of my work with MIT. Actually I already did so, as you can see here: https://github.com/jbeder/yaml-cpp/blob/9ce5a25188d83b43dd5cd633f2975be10f5d6608/src/contrib/dragonbox.h#L6 All I want is to just a short note of my agreement as written there. I'm not a lawyer so am not sure if that's enough (b/c technically speaking there are contributors other than me) but since the file dragonbox.h specifically is almost entirely written by myself, I believe it should not cause any problem. It's especially so since what is to be distributed is not this library itself but just a derivative.

Regarding the stack size issue, I believe the main cause of the bloat for Grisu is the fallback implementation (Dragon4 maybe?) which requires bignum math. Since Ryu and Dragonbox both only do math within 192-bits, I think the stack usage should be similar. I guess Dragonbox probably uses a bit more locals though. But note that for embedded usage, the table size would be an issue, in which case it's advised to use the compact table. That will increase the code size and stack usage a bit more. I have been doing some experiments on embedded usage recently by the way: #57

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants