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

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

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?

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.

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

On 7/7/2020 3:58 AM, 9il wrote:
> 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.

I agree with the importance of being correct to the last bit.

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.
>
> 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.

This argument seems a bit odd given ... when D code was contributed to gcc, did you follow the FSF rule of assigning copyright to FSF?

On Saturday, 11 July 2020 at 10:58:31 UTC, Dibyendu Majumdar wrote:
> This argument seems a bit odd given ... when D code was contributed to gcc, did you follow the FSF rule of assigning copyright to FSF?

The issue is about maintenance of the codebase, not about who owns the copyright.

On 6/21/2020 8:24 AM, 9il wrote:
> [0] https://github.com/libmir/mir-algorithm
> [1] http://mir-algorithm.libmir.org/mir_parse.html#.fromString[2] https://issues.dlang.org/show_bug.cgi?id=20951
> [3] https://issues.dlang.org/show_bug.cgi?id=20952
> [4] https://issues.dlang.org/show_bug.cgi?id=20953
> [5] https://issues.dlang.org/show_bug.cgi?id=20963
> [6] https://issues.dlang.org/show_bug.cgi?id=20967
> [7] https://www.researchgate.net/publication/2295884_How_to_Read_Floating_Point_Numbers_Accurately 
> 

As an update, I've gotten 20963 working now. It's a foundational fix, and without it I expect correcting the other issues would be unduly difficult and frustrating.

https://github.com/dlang/dmd/pull/11393

On 7/7/20 8:04 AM, Steven Schveighoffer wrote:
> 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.

FWIW it would be wisest to simply copy the code from Mir into druntime now with due credit. It's a minimally committal decision than can be easily revisited later. It is legal, appropriate, and there's no shame to it any more than it is for other projects to fork (parts of) dmd, druntime, or phobos.