Re: Visual D 1.0.0 released
On Tue, Jul 7, 2020 at 10:00 PM JN via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze wrote: > > See > > https://rainers.github.io/visuald/visuald/VersionHistory.html > > for the complete list of changes. > > > > Cheers, > > Rainer > > Anyone who uses VisualD and Code-D can compare the two? (Yes, I > know the difference between Visual Studio and Visual Studio Code). > The difference is night vs day... VisualD is, by far, like REALLY FAR, the most mature and useful IDE and debug environment for D. TL;DR: if you are a D dev, and you use Windows, you should definitely try Visual Studio + VisualD. I for one couldn't work without it!
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 23:56:45 UTC, kinke wrote: On Tuesday, 7 July 2020 at 23:52:05 UTC, 9il wrote: On Tuesday, 7 July 2020 at 16:38:39 UTC, kinke wrote: So wouldn't the trivial 'fix' be using `strtod` for double literals and `strtof` for floats? [For LDC, we wouldn't rely on the host C runtime or a mir implementation, but use LLVM facilities anyway.] This should work if the C runtime handles the values correctly. I've just opened a PR for DMD (and LDC too): https://github.com/dlang/dmd/pull/11387 Does this actually mean DMD wouldn't be able to compile itself with DigigtalMars C runtime? Sorry, I don't understand. - I think this excess precision was at some point considered a feature (but probably only for D, not for DigitalMars C), there's even a test making sure 0.9L and 0.9 are parsed to the same compile-time value. DMC strtod [1] isn't IEEE compatible. Just nitpick. Unlikely it is used to compile DMD thought. [1] https://github.com/DigitalMars/dmc/blob/9a774f3f2b3227fd416ec3a83cb9eb8f8751425f/src/core/strtod.c
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 23:52:05 UTC, 9il wrote: On Tuesday, 7 July 2020 at 16:38:39 UTC, kinke wrote: So wouldn't the trivial 'fix' be using `strtod` for double literals and `strtof` for floats? [For LDC, we wouldn't rely on the host C runtime or a mir implementation, but use LLVM facilities anyway.] This should work if the C runtime handles the values correctly. I've just opened a PR for DMD (and LDC too): https://github.com/dlang/dmd/pull/11387 Does this actually mean DMD wouldn't be able to compile itself with DigigtalMars C runtime? Sorry, I don't understand. - I think this excess precision was at some point considered a feature (but probably only for D, not for DigitalMars C), there's even a test making sure 0.9L and 0.9 are parsed to the same compile-time value.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 16:38:39 UTC, kinke wrote: On Saturday, 4 July 2020 at 20:35:48 UTC, Walter Bright wrote: On 6/21/2020 8:24 AM, 9il wrote: [...] Great work! Would you like to add it to dmd? AFAIU, the 'problem' is that *all* floating-point literals are parsed as real_t values, which for DMD is x87 real (usually using the host C runtime's `strtold`). When emitting them as double or float literals, the compiler converts these values to a lower precision, where the increased intermediate precision might break the 'banker's rule'. So wouldn't the trivial 'fix' be using `strtod` for double literals and `strtof` for floats? [For LDC, we wouldn't rely on the host C runtime or a mir implementation, but use LLVM facilities anyway.] This should work if the C runtime handles the values correctly. Does this actually mean DMD wouldn't be able to compile itself with DigigtalMars C runtime?
Re: Quick create serverside project based on Hunt Framework 3.2.0
On Tuesday, 7 July 2020 at 19:21:17 UTC, zoujiaqing wrote: https://github.com/huntlabs/hunt-framework-articles/blob/master/quick-create-serverside-project/quick-create-serverside-project.md Thank you Brian! Its very awesome the content you're creating for Hunt Framework.
Quick create serverside project based on Hunt Framework 3.2.0
https://github.com/huntlabs/hunt-framework-articles/blob/master/quick-create-serverside-project/quick-create-serverside-project.md
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tue, Jul 07, 2020 at 01:47:59PM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote: > On 7/7/20 1:37 PM, H. S. Teoh wrote: > > cf. the repeated problems we had over the years with libcurl, zlib, > > etc. > > zlib is actually included copy-paste style in Phobos [1]. So it's > interesting that you cite it as an example of causing problems because > we don't include a copy of it. [...] Ah, haha, I think it was mainly libcurl that was causing problems. Now that I think about it again, I don't recall zlib causing problems, probably because we *didn't* rely on it being available on the target machine! T -- Dogs have owners ... cats have staff. -- Krista Casada
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote: Phobos is the stdlib of the language. Mir is not. I'm not sure why you point this out. No one is arguing that it is. On the other hand, it does many things better already. Likewise, you've made the std.experimental.allocator on DUB depends on mir-core... stdlib shouldn't depend on non-stdlib, there isn't anything to debate on this point. stdx-allocator [1] is not "stdlib" and not meant to be part of Phobos (the opposite actually). It's a fork of the code in Phobos made with the obvious intention of doing things differently than Phobos. If you want to use Phobos, then... use Phobos :D Actually, mir-core is not a dependency of stdx-allocator in general, just in V3. You can still use the 2.77.z branch which doesn't have any dependencies [2]. Many projects do use it. [1]: https://github.com/dlang-community/stdx-allocator [2]: https://github.com/dlang-community/stdx-allocator/blob/2.77.z/dub.sdl
Re: Decimal string to floating point conversion with correct half-to-even rounding
On 7/7/20 1:37 PM, H. S. Teoh wrote: cf. the repeated problems we had over the years with libcurl, zlib, etc. zlib is actually included copy-paste style in Phobos [1]. So it's interesting that you cite it as an example of causing problems because we don't include a copy of it. -Steve [1] https://github.com/dlang/phobos/tree/ea070e9a5c168de2e8460413e44bff1d406ff5c3/etc/c/zlib
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tue, Jul 07, 2020 at 03:08:33PM +, Adam D. Ruppe via
Digitalmars-d-announce wrote:
> On Tuesday, 7 July 2020 at 13:00:04 UTC, Steven Schveighoffer wrote:
> > Doing that these days would be silly. You can depend on a specific
> > version of a repository without problems.
>
> I always have problems when trying to do that. git submodules bring
> pretty consistent pain in my experience.
git submodules serves a very specific niche; using it for anything
outside of that most definitely brings in gigantic pain.
That very specific niche is this: there's an external repository R that
contains code you'd like to use, BUT that you'll never edit (unless you
wish to push it back upstream). You check it out in some subdirectory
of your source tree, say ./someRepo/*, and add it as a submodule. This
adds the SHA hash of the exact revision of the code in .gitmodules,
meaning that you depend on that exact version of R. Occasionally, you
want to update R to some (presumably newer) version, so you do a `git
submodule foreach git pull ...` to pull the revision you want. This
updates .gitmodules to point to the new revision.
What you do *not* want to do is to edit the contents of the submodule,
because that will start creating diverging branches in the submodule,
which generally leads to a gigantic mess, like when somebody checks out
your code and tries to fetch submodules, they may not find the revision
being referred to (you haven't pushed the commits upstream, upstream
rejected it, etc).
Basically, git submodules let you refer to a specific commit in a
specific repo. Don't expect it to do anything else for you, including
housekeeping that you *thought* it ought to do.
I've used git submodules quite happily for my own projects, where I want
to pull in code from another project but don't want to have to worry
about version compatibility and all of that dependency hell. Basically
you update a submodule to a new revision when and only when *you*
initiate it, and don't commit the submodule update until you've verified
that the new revision didn't break your code. The submodule SHA ensures
that you'll get the exact version of the submodule that you last checked
in, not some random new version or some corrupted/edited version that
some unreliable network source have given you instead.
> But it probably isn't so bad if the submodule rarely changes.
Yeah, you do *not* want to use submodules if you're interested in
keeping up with the latest bleeding edge from upstream. Well I mean you
*can*, but just don't expect it to automate anything for you. The onus
is upon you to test everything with the new revision before committing
it.
Oh, and another point: it's *probably* a good idea to git clone (i.e.
fork in github parlance) the submodule into a local copy, so that if the
network source vanishes into the ether, you aren't left with
uncompilable code. Don't laugh, the way modern software development is
going, I will be SO not surprised when one day some obscure project that
everyone implicitly depends on suddenly vanishes into the ether and the
rest of the world collapses because everybody and his neighbour's dog
blindly assumed that "if it's on the network, it'll be there forever".
> Just for 100% control anyway nothing beats copy/paste. Then there's
> zero difference between you writing it yourself.
I highly recommend this approach when your dependency is small. Or if
you want to ensure no external dependencies. There have been far, FAR
too many times IME in the past few years where I encountered a project
that was no longer compilable because one or more dependencies have
vanished into the ether. Or the code no longer compiles with the
dependency because the latest version of said dependency has migrated to
a brand new codebase, and the old revision that the project depended on
is not compatible with the new version. Or said project itself has
moved on and happily broke functionality I depended on.
These days, my policy is: download the danged source code for the
specific version of the specific project I'm depending on, AND download
the danged source code of the danged dependencies of that project, etc.,
and keep a local copy of the whole recursive dependency tree so that I
can ensure I can always build that specific version of that specific
project with that specific functionality that I'm using. Trying to keep
up with projects that gratuitously break stuff, or abandoned projects
whose dependencies are no longer compatible with it, etc., is a hell I
wish to have no part in. I've lost faith in the emperor's code reuse
clothes; copy-n-paste is what gives the real guarantees.
And I'm not alone in this -- I've noticed that quite a few open source
projects are distributing a copy of the sources of the librar{y,ies}
they depend on in their own source tree as a fallback, in case the
target system's version of that library doesn't exist, or is hard to
find, or is somehow incompatible with the version
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Saturday, 4 July 2020 at 20:35:48 UTC, Walter Bright wrote: On 6/21/2020 8:24 AM, 9il wrote: So excited to finally announce we can correctly parse floating-point numbers according to IEEE round half-to-even (bankers) rule like in C/C++, Rust, and others. Great work! Would you like to add it to dmd? AFAIU, the 'problem' is that *all* floating-point literals are parsed as real_t values, which for DMD is x87 real (usually using the host C runtime's `strtold`). When emitting them as double or float literals, the compiler converts these values to a lower precision, where the increased intermediate precision might break the 'banker's rule'. So wouldn't the trivial 'fix' be using `strtod` for double literals and `strtof` for floats? [For LDC, we wouldn't rely on the host C runtime or a mir implementation, but use LLVM facilities anyway.]
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 15:08:33 UTC, Adam D. Ruppe wrote: On Tuesday, 7 July 2020 at 13:00:04 UTC, Steven Schveighoffer wrote: Doing that these days would be silly. You can depend on a specific version of a repository without problems. I always have problems when trying to do that. git submodules bring pretty consistent pain in my experience. But it probably isn't so bad if the submodule rarely changes. Just for 100% control anyway nothing beats copy/paste. Then there's zero difference between you writing it yourself. I kinda wish the D upstream were more willing to do that. My view is it shouldn't be on independent developers to add stuff to Phobos, for example, instead the Phobos team should just be copying and testing modules they are interested in on their own. git subtree it's like submodules but also like copy-paste.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On 7/7/20 11:08 AM, Adam D. Ruppe wrote: On Tuesday, 7 July 2020 at 13:00:04 UTC, Steven Schveighoffer wrote: Doing that these days would be silly. You can depend on a specific version of a repository without problems. I always have problems when trying to do that. git submodules bring pretty consistent pain in my experience. But it probably isn't so bad if the submodule rarely changes. It's cumbersome in my experience, I do it on some iOS projects that I have. But as long as you don't touch ANY FILES inside the cloned submodule, and just use git to update it (i.e. git checkout v1.x when upgrading), you are just versioning which commit your code depends on. Xcode makes this difficult because it tries to write some temporary files inside the submodule, and I have to clear those out before upgrading. But that problem shouldn't exist here. Like all things git, it's hard until you figure it out, and then it becomes easy. Just for 100% control anyway nothing beats copy/paste. Then there's zero difference between you writing it yourself. I kinda wish the D upstream were more willing to do that. My view is it shouldn't be on independent developers to add stuff to Phobos, for example, instead the Phobos team should just be copying and testing modules they are interested in on their own. The problem here is that you are maintaining a separate copy. There is always the chance that you don't copy it right (e.g. you copy a local checkout that has some test changes you made, or you copy the wrong version). Imagine how fun the reviews will be when you have to check that all the cumulative changes from 1.0 to 1.5 match what the source repository has. We have computers and software to do source control for a reason. -Steve
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 12:04:43 UTC, Steven Schveighoffer wrote: Guys, this is all open source, all licensed identically. There are ways to solve this. Practically speaking, just because DMD depends on Mir, doesn't mean that Mir has control over how the dependency works. DMD can depend on a specific version of Mir, upgraded when reasonable (i.e. it should take a PR change to DMD for upgrading which code exactly is depended on) and if something changes in the future, you can fork it, or move back to using libc. This way, the code is only maintained in one place unless something catastrophic happens. Well, for avoidance of doubt, I'm not personally opposed per se to the use of 3rd party libs in DMD or druntime/phobos. It just struck me as important that everyone understands clearly each other's concerns. What I think provoked concern was not the idea of using mir-algorithm as a 3rd party lib, but this alternative suggestion: The second solution is to move `mir.bignum` and `mir.parse` to DRuntime/Phobos. In this case, I would like to preserve the `mir.` namespace and the same authority and veto right for this part of the codebase as I have at Mir Org. ... where what's being asked is a rather stronger commitment, and not really workable: if the code's going to live in D foundation repos then any maintainer or veto rights are going to be provisional. It's just not reasonable for the maintainer of 2 stdlib modules to be able to unilaterally veto changes, or force breaking change. There's no reason per se why 3rd party libs can't be used under the hood to provide implementations, but druntime and phobos maintainers need to be able to make their own API guarantees.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 13:00:04 UTC, Steven Schveighoffer wrote: Doing that these days would be silly. You can depend on a specific version of a repository without problems. I always have problems when trying to do that. git submodules bring pretty consistent pain in my experience. But it probably isn't so bad if the submodule rarely changes. Just for 100% control anyway nothing beats copy/paste. Then there's zero difference between you writing it yourself. I kinda wish the D upstream were more willing to do that. My view is it shouldn't be on independent developers to add stuff to Phobos, for example, instead the Phobos team should just be copying and testing modules they are interested in on their own.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 13:01:10 UTC, 9il wrote: This would be good advertising for DFL, haha. I don't know what you mean...
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 12:52:35 UTC, Adam D. Ruppe wrote: On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote: Businesses will not want to commit to a balkanized project. It's been ages since I worked on a software project for a business that didn't have many random third (and fourth and fifth and sixth and seventh.) party dependencies. Trying to remove or avoid them would universally encounter pushback from management. "Don't reinvent the wheel" they say. It is really absurd. But anyway this whole debate is moot because if you like the code, you can simply copy/paste it (with attribution as required by Boost copyright of course) into your own files. You keep full control and get all the benefits of using it. This would be good advertising for DFL, haha.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On 7/7/20 8:52 AM, Adam D. Ruppe wrote: On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote: Businesses will not want to commit to a balkanized project. It's been ages since I worked on a software project for a business that didn't have many random third (and fourth and fifth and sixth and seventh.) party dependencies. Trying to remove or avoid them would universally encounter pushback from management. "Don't reinvent the wheel" they say. It is really absurd. +1 To any customer who is shy to include 3rd party dependencies, isn't using DMD a 3rd party dependency? But anyway this whole debate is moot because if you like the code, you can simply copy/paste it (with attribution as required by Boost copyright of course) into your own files. You keep full control and get all the benefits of using it. Doing that these days would be silly. You can depend on a specific version of a repository without problems. Git even allows you to add a dependency on another git project, and freeze it at that version. -Steve
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote: Businesses will not want to commit to a balkanized project. It's been ages since I worked on a software project for a business that didn't have many random third (and fourth and fifth and sixth and seventh.) party dependencies. Trying to remove or avoid them would universally encounter pushback from management. "Don't reinvent the wheel" they say. It is really absurd. But anyway this whole debate is moot because if you like the code, you can simply copy/paste it (with attribution as required by Boost copyright of course) into your own files. You keep full control and get all the benefits of using it.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 12:04:43 UTC, Steven Schveighoffer wrote: On 7/7/20 7:13 AM, 9il wrote: [...] Guys, this is all open source, all licensed identically. There are ways to solve this. Practically speaking, just because DMD depends on Mir, doesn't mean that Mir has control over how the dependency works. DMD can depend on a specific version of Mir, upgraded when reasonable (i.e. it should take a PR change to DMD for upgrading which code exactly is depended on) and if something changes in the future, you can fork it, or move back to using libc. This way, the code is only maintained in one place unless something catastrophic happens. In this sense, the DLF *does* control which code is used, as well as if it were in the DMD repository itself. We have a boost license for a reason. -Steve Exactly. Thank you
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote: On Tuesday, 7 July 2020 at 10:58:25 UTC, 9il wrote: From a business point of view, having slightly more correct string to float conversion holds very little value. I'll stick with sscanf thanks... For a high tech real markets (airspace, automotive, science, military-industrial complex) having a correct decimal literal parsing... Phobos is the stdlib of the language. Mir is not. Likewise, you've made the std.experimental.allocator on DUB depends on mir-core... stdlib shouldn't depend on non-stdlib, there isn't anything to debate on this point. Mir is stdlib for my business. Phobos is not. It wasn't me who proposed to use Mir code in DMD. I have heard Walter. There isn't anything to debate on this point.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 12:35:57 UTC, jmh530 wrote: On Tuesday, 7 July 2020 at 12:33:40 UTC, jmh530 wrote: On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote: [...] Is that not an example of how Steve thinks it should work? Both are Boost licensed. mir-core has no external dependencies. Ilya could split the parse/bignum packages to a separate repo with no other dependencies and then public import them in mir-algorithm and just normally import them elsewhere. [...] Walter's original comment was about adding it to DMD. He may have intended Phobos, but I read it as DMD. Eh, it looks like parse.d depends on std. So it wouldn't make sense to add to DMD since then the compiler would depend on the standard library. All std.* dependencies in Mir are minor and can be replaced in a day.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 12:33:40 UTC, jmh530 wrote: On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote: [snip] Likewise, you've made the std.experimental.allocator on DUB depends on mir-core... Is that not an example of how Steve thinks it should work? Both are Boost licensed. mir-core has no external dependencies. Ilya could split the parse/bignum packages to a separate repo with no other dependencies and then public import them in mir-algorithm and just normally import them elsewhere. stdlib shouldn't depend on non-stdlib, there isn't anything to debate on this point. Walter's original comment was about adding it to DMD. He may have intended Phobos, but I read it as DMD. Eh, it looks like parse.d depends on std. So it wouldn't make sense to add to DMD since then the compiler would depend on the standard library.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote: [snip] Likewise, you've made the std.experimental.allocator on DUB depends on mir-core... Is that not an example of how Steve thinks it should work? Both are Boost licensed. mir-core has no external dependencies. Ilya could split the parse/bignum packages to a separate repo with no other dependencies and then public import them in mir-algorithm and just normally import them elsewhere. stdlib shouldn't depend on non-stdlib, there isn't anything to debate on this point. Walter's original comment was about adding it to DMD. He may have intended Phobos, but I read it as DMD.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 10:58:25 UTC, 9il wrote: From a business point of view, having slightly more correct string to float conversion holds very little value. I'll stick with sscanf thanks... For a high tech real markets (airspace, automotive, science, military-industrial complex) having a correct decimal literal parsing... Phobos is the stdlib of the language. Mir is not. Likewise, you've made the std.experimental.allocator on DUB depends on mir-core... stdlib shouldn't depend on non-stdlib, there isn't anything to debate on this point.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On 7/7/20 7:13 AM, 9il wrote: On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote: On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote: On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote: There is no risk for DMD and DFL to depend on a Mir's Boost licensed library. If something happens with Mir or Mir change the license, DFL will be able to fork the required code at any point in the Boost licensed part of git history. Can't speak for Walter or the D foundation here, but I'm not sure the concern is really about licensing. It's about putting in place a required dependency on code where maintenance decisions are outside the hands of the D Foundation. That's right, it's not about the licensing. It's that the DLF should control the code it distributes. Businesses will not want to commit to a balkanized project. The proposal is for Mir to become a central required component of DMD and Phobos. This means it needs to become part of the D Language Foundation. These don't serve my business needs. DLF doesn't serve my business needs. DLF blocks the initiatives my business needs. For the current state of things being a part of DLF codebase for Mir is nonsense. Guys, this is all open source, all licensed identically. There are ways to solve this. Practically speaking, just because DMD depends on Mir, doesn't mean that Mir has control over how the dependency works. DMD can depend on a specific version of Mir, upgraded when reasonable (i.e. it should take a PR change to DMD for upgrading which code exactly is depended on) and if something changes in the future, you can fork it, or move back to using libc. This way, the code is only maintained in one place unless something catastrophic happens. In this sense, the DLF *does* control which code is used, as well as if it were in the DMD repository itself. We have a boost license for a reason. -Steve
Re: Visual D 1.0.0 released
On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze wrote: See https://rainers.github.io/visuald/visuald/VersionHistory.html for the complete list of changes. Cheers, Rainer Anyone who uses VisualD and Code-D can compare the two? (Yes, I know the difference between Visual Studio and Visual Studio Code).
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote: On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote: On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote: There is no risk for DMD and DFL to depend on a Mir's Boost licensed library. If something happens with Mir or Mir change the license, DFL will be able to fork the required code at any point in the Boost licensed part of git history. Can't speak for Walter or the D foundation here, but I'm not sure the concern is really about licensing. It's about putting in place a required dependency on code where maintenance decisions are outside the hands of the D Foundation. That's right, it's not about the licensing. It's that the DLF should control the code it distributes. Businesses will not want to commit to a balkanized project. The proposal is for Mir to become a central required component of DMD and Phobos. This means it needs to become part of the D Language Foundation. These don't serve my business needs. DLF doesn't serve my business needs. DLF blocks the initiatives my business needs. For the current state of things being a part of DLF codebase for Mir is nonsense.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 09:28:26 UTC, Guillaume Piolat wrote: On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote: That's right, it's not about the licensing. It's that the DLF should control the code it distributes. Businesses will not want to commit to a balkanized project. From a business point of view, having slightly more correct string to float conversion holds very little value. I'll stick with sscanf thanks... For a high tech real markets (airspace, automotive, science, military-industrial complex) having a correct decimal literal parsing has a little but absolutely mandatory value. If SpaceX is lending a rocket, they want it located on the platform, something around wouldn't make sense. Note, that these companies hold a huge amount of the legacy C/C++ code and they are potential Dlang markets. But only if Dlang will be able to match C exactly for numeric code. Otherwise merging C/C++ code would have a huge negative impact on them.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote: That's right, it's not about the licensing. It's that the DLF should control the code it distributes. Businesses will not want to commit to a balkanized project. From a business point of view, having slightly more correct string to float conversion holds very little value. I'll stick with sscanf thanks...
Re: Decimal string to floating point conversion with correct half-to-even rounding
On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote: On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote: There is no risk for DMD and DFL to depend on a Mir's Boost licensed library. If something happens with Mir or Mir change the license, DFL will be able to fork the required code at any point in the Boost licensed part of git history. Can't speak for Walter or the D foundation here, but I'm not sure the concern is really about licensing. It's about putting in place a required dependency on code where maintenance decisions are outside the hands of the D Foundation. That's right, it's not about the licensing. It's that the DLF should control the code it distributes. Businesses will not want to commit to a balkanized project. The proposal is for Mir to become a central required component of DMD and Phobos. This means it needs to become part of the D Language Foundation.
Re: Visual D 1.0.0 released
Very nice! Please consider writing an article about your work!
