www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.experimental repo

reply Daniel N <no public.email> writes:
I don't use dub and I doubt I ever will.

As a ndslice user, I long dreaded this day:
2.074.0: "std.experimental.ndslice has been removed"

Well, I will deal with it, I was just thinking what could we do 
better for the future?

What if experimental was in a sub repo? Then everyone who gets a 
module accepted into experimental could get elevated access 
rights to the experimental module, since no other module should 
depend on an experimental module, it would be relatively safe, 
no? If this was the case maybe Ilya wouldn't have felt it was 
such a burden to maintain.
Mar 25 2017
parent reply XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 25 March 2017 at 09:42:07 UTC, Daniel N wrote:
 As a ndslice user, I long dreaded this day:
 2.074.0: "std.experimental.ndslice has been removed"
Are you aware that ndslice is available at https://github.com/libmir/mir-algorithm right? I believe the reason std.experimental.ndslice must have been removed is because it was an already out of date fork. The newest is forked out of Phobos because the author decided to stop working inside Phobos. Maybe Ilya can explain it better if he sees the thread.
Mar 25 2017
parent reply Seb <seb wilzba.ch> writes:
On Saturday, 25 March 2017 at 10:28:36 UTC, XavierAP wrote:
 On Saturday, 25 March 2017 at 09:42:07 UTC, Daniel N wrote:
 As a ndslice user, I long dreaded this day:
 2.074.0: "std.experimental.ndslice has been removed"
Are you aware that ndslice is available at https://github.com/libmir/mir-algorithm right? I believe the reason std.experimental.ndslice must have been removed is because it was an already out of date fork. The newest is forked out of Phobos because the author decided to stop working inside Phobos. Maybe Ilya can explain it better if he sees the thread.
Well, as the guy who removed Mir from Phobos, I can share a couple insights on why having Mir in Phobos is problematic: - different release cycle: - it takes minutes or hours for a bug fix in mir to be available and months for phobos - using proper semantic versioning deprecation issues are a greatly reduced (users always have the same code base and when they have time, they can upgrade to the latest and greatest) - lack of progress: - there aren't many reviewers for ndslice, so in the past PRs to ndslice got unnecessarily stalled - there was a huge discussion last summer when Ilya tried to move ndslice.iteration into std.experimental.ndslice (there were endless discussions about the naming of his functions) - dependency on LDC (fast math and previously proper FP math): mir wasn't compatible with DMD for a couple of releases - external dependencies: e.g. mir-glas depends on a different cpuid than the one in core.cpuid - Ilya has a huge focus on -betterC and the idea is that all Mir projects can be used without Phobos and druntime, so that it can easily be linked with C (see also his proposal for a small, modular and betterC-compatible standard library: https://forum.dlang.org/post/phexetutyelrssyrucvw forum.dlang.org) So in short: as long as a library is in active development, it's its death to put it into the standard library.
Mar 25 2017
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 25/03/2017 3:20 PM, Seb wrote:
 On Saturday, 25 March 2017 at 10:28:36 UTC, XavierAP wrote:
 On Saturday, 25 March 2017 at 09:42:07 UTC, Daniel N wrote:
 As a ndslice user, I long dreaded this day:
 2.074.0: "std.experimental.ndslice has been removed"
Are you aware that ndslice is available at https://github.com/libmir/mir-algorithm right? I believe the reason std.experimental.ndslice must have been removed is because it was an already out of date fork. The newest is forked out of Phobos because the author decided to stop working inside Phobos. Maybe Ilya can explain it better if he sees the thread.
Well, as the guy who removed Mir from Phobos, I can share a couple insights on why having Mir in Phobos is problematic: - different release cycle: - it takes minutes or hours for a bug fix in mir to be available and months for phobos - using proper semantic versioning deprecation issues are a greatly reduced (users always have the same code base and when they have time, they can upgrade to the latest and greatest) - lack of progress: - there aren't many reviewers for ndslice, so in the past PRs to ndslice got unnecessarily stalled - there was a huge discussion last summer when Ilya tried to move ndslice.iteration into std.experimental.ndslice (there were endless discussions about the naming of his functions) - dependency on LDC (fast math and previously proper FP math): mir wasn't compatible with DMD for a couple of releases - external dependencies: e.g. mir-glas depends on a different cpuid than the one in core.cpuid - Ilya has a huge focus on -betterC and the idea is that all Mir projects can be used without Phobos and druntime, so that it can easily be linked with C (see also his proposal for a small, modular and betterC-compatible standard library: https://forum.dlang.org/post/phexetutyelrssyrucvw forum.dlang.org) So in short: as long as a library is in active development, it's its death to put it into the standard library.
Or TLDR: it wasn't ready or appropriate for Phobos inclusion in the first place. But that was easier seen with hindsight sadly.
Mar 25 2017
prev sibling next sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 25 March 2017 at 14:20:53 UTC, Seb wrote:
 So in short: as long as a library is in active development, 
 it's its death to put it into the standard library.
That could be different for std.experimental.*? Or does that work only when development comes directly from the Foundation? Should it be different? Nothing against having very useful and established libraries also outside Phobos, if it's more agile. If Boost had to be inside the C++ standard we would have never had Boost or C++11. I like to think Phobos is less rigid than C++ standard but still.
Mar 25 2017
parent Daniel N <no public.email> writes:
On Saturday, 25 March 2017 at 16:50:18 UTC, XavierAP wrote:
 On Saturday, 25 March 2017 at 14:20:53 UTC, Seb wrote:
 So in short: as long as a library is in active development, 
 it's its death to put it into the standard library.
That could be different for std.experimental.*? Or does that work only when development comes directly from the Foundation? Should it be different?
That was kinda what I was hoping, there could be a 2nd bikeshedding/review before graduating out of experimental, but allowing the author to get some work done during the experimental phase.
 Nothing against having very useful and established libraries 
 also outside Phobos, if it's more agile. If Boost had to be 
 inside the C++ standard we would have never had Boost or C++11. 
 I like to think Phobos is less rigid than C++ standard but 
 still.
If there's 1 big library that's fine, but if you have to puzzle together 5 small ones... On Saturday, 25 March 2017 at 10:28:36 UTC, XavierAP wrote:
 On Saturday, 25 March 2017 at 09:42:07 UTC, Daniel N wrote:
 As a ndslice user, I long dreaded this day:
 2.074.0: "std.experimental.ndslice has been removed"
Are you aware that ndslice is available at https://github.com/libmir/mir-algorithm right?
yes, thanks.
Mar 25 2017
prev sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 25 March 2017 at 14:20:53 UTC, Seb wrote:
 https://forum.dlang.org/post/phexetutyelrssyrucvw forum.dlang.org)
This has struck me from Ilya's post, as a problem that we had at my previous job: code base of old platform too monolithic, not modular enough; which in that case could turn "existing code base" into "legacy code base" too easily as soon as requirements need some flexibility: On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote:
 3. Dependencies should be clear. Modularity is a proper way for 
 large std library. In phobos everything integrated with 
 everything. DRuntime -> Phobos abstraction is weird for betterC 
 because system modules can depends universal algorithms, but 
 universal algorithm are more portable if they have not system 
 dependencies.
Now I am aware this case is very different. A standard library, specially excluding std.experimental, should have very stable requirements, and it's ok to make everything depend on all of it because it's supposed to stay. But in the past I've argued[1] that D needs for commercial success a much broader standard library than std or the C++ parallel STL, emulating the more modern examples (not regarding language design but just functionality) of Java, Python or .NET. So I guess what I mean is that for me "std" would be "core", "core" would be "core.core", and I think D should work towards establishing and offer many other different modules, either as part of the standard library, or de facto standard (e.g. vibe, mir... gui??). But this is off topic and unfortunately far into the future. And then in this situation these additional modules could depend on the existing std, but not among each other. [1] http://forum.dlang.org/post/vzgxlcfxfxzdezrfxicr forum.dlang.org
Mar 25 2017