On Friday, 24 August 2018 at 00:46:14 UTC, Mike Franklin wrote:

> But I need it to implement `memcpy` and `memcmp` in D, so we can remove the dependency on the D standard library :-)

Gah! What a typo.  I mean the C standard library.

On Friday, 24 August 2018 at 00:47:18 UTC, Mike Franklin wrote:
> On Friday, 24 August 2018 at 00:46:14 UTC, Mike Franklin wrote:
>
>> But I need it to implement `memcpy` and `memcmp` in D, so we can remove the dependency on the D standard library :-)
>
> Gah! What a typo.  I mean the C standard library.

Do you also mean to reimplement everything related to FILE*?
floating-point parsing and conversion to string?
multithreaded malloc?

On Friday, 24 August 2018 at 00:53:20 UTC, Guillaume Piolat wrote:

> Do you also mean to reimplement everything related to FILE*?
> floating-point parsing and conversion to string?
> multithreaded malloc?

Only what's need for druntime.  That would include multi-threaded malloc, but not the FILE* string-related stuff.

On Friday, 24 August 2018 at 00:56:10 UTC, Mike Franklin wrote:
> On Friday, 24 August 2018 at 00:53:20 UTC, Guillaume Piolat wrote:
>
>> Do you also mean to reimplement everything related to FILE*?
>> floating-point parsing and conversion to string?
>> multithreaded malloc?
>
> Only what's need for druntime.  That would include multi-threaded malloc, but not the FILE* string-related stuff.

D programs tend to use the C runtime directly, and quite a lot of it:
https://github.com/search?l=D&q=%22import+core.stdc%22&type=Code

On Friday, 24 August 2018 at 00:58:35 UTC, Guillaume Piolat wrote:

> D programs tend to use the C runtime directly, and quite a lot of it:
> https://github.com/search?l=D&q=%22import+core.stdc%22&type=Code

I know.  They should get that from https://github.com/D-Programming-Deimos/libc or perhaps even Dub.

On 08/23/2018 07:28 PM, H. S. Teoh wrote:
> On Thu, Aug 23, 2018 at 06:39:32PM +0200, ag0aep6g via Digitalmars-d wrote:
[...]
>> Regressions aren't being fixed (78 open). Wrong-code don't get fixed
>> (170!).  Etc., and so on. So why even bother?
> 
> I think this is unfair.  Regressions *are* being fixed... but they're
> getting reported at a faster rate than they're being fixed.  Wrong-code
> bugs also *are* getting fixed... just not as fast as we'd like, but I
> think it's unfair to say they aren't getting fixed.

Yeah, it was hyperbole for sure. Of course bugs are being fixed. But it feels like it takes longer and longer.

Elsewhere in this thread, Kenji Hara was mentioned. I had a look at my bug report history, and before Kenji left, he had managed to fix a third of the DMD bugs I had reported by that time. After Kenji's leaving, the fix rate dropped significantly and Walter had to step in more often.

So it's very possible that I'm just missing Kenji.

On Friday, 24 August 2018 at 00:46:14 UTC, Mike Franklin wrote:
> It seems, from someone without much historical perspective, that Phobos was intended to be something like the .Net Framework for D.  Perhaps there are a few fundamentals (std.algorithm, std.allocator, etc.) to keep, but for the others... move 'em to Dub and let the "free market" sort it out.

That might work for some use cases, but not for others. For my use cases, a rock solid standard library is a basic requirement (think STL, Boost, etc). These don't normally come out of a loose knit community of individuals, there needs to be some sort of organizational presence involved to ensure quality, consistency, completeness, etc. If Phobos or an equivalent wasn't available at its present level of quality then D wouldn't be in the consideration set.

On the other hand, my use-cases don't have the requirements that drive other folks towards removing dependence on druntime and similar. An individual or organization's prioritization preferences will depend on their goals.

--Jon

On 23/08/18 23:46, Walter Bright wrote:
> In my experience with debugging code, if drilling down to find the cause of the problem is not done, there is no way to conclude whether whether it is a compiler bug or a user bug.
> 
> (Of course, compiler internal errors are always compiler bugs.)
> 
> Drilling down and finding it to be a compiler problem also usually suggests a practical workaround for it.

Consider the following line from the weka code base:

        _trustedData.opIndex(diskIdx) &= NotBitmap(toDistrust);

That's strange. Why didn't Shachar just do?

        _trustedData[diskIdx] &= NotBitmap(toDistrust);

Answer: Because the compiler decided that it needs to call _trustedData.opIndexAssign, and then failed the compilation because it has none. There is no way that that is a bug in the code. This is a compiler bug (maybe since fixed. This is fairly old code).

So, where's the issue number, I hear you ask? There is none. This problem only happens inside the code base. Once I tried to isolate it, I couldn't reproduce.

At this point I can either use the work-around I already have and (try to, obviously unsuccessfully) forget about it, file a bug report that will be (justifiably) ignored because no-one else can reproduce it, or spend an unknown amount of time (two days would probably be low-balling at this point) in trying to get this to reproduce on a watered down version of the code.

Which would you pick?

Shachar

On Thursday, August 23, 2018 3:31:41 PM MDT Walter Bright via Digitalmars-d wrote:
> On 8/23/2018 9:19 AM, Jonathan M Davis wrote:
> > D was designed to have RAII, and it does. It's just that the implementation is buggy (which is obviously a serious problem), so depending on what your program is doing, it's not going to work correctly. It's not like we opted to not have RAII in D, and I'm sure that it will be fixed at some point. So, while it can certainly be argued that we've dropped the ball by not getting it fully fixed by now, I don't really see how it could be termed a missed opportunity.
>
> As far as I know, the only known bug in RAII is https://issues.dlang.org/show_bug.cgi?id=14246 where constructors are not properly unwinding partially constructed objects.

Yeah. I've used RAII plenty in D without problems, but the fact remains that certain uses of it are very broken right now thanks to the constructor issue. I suspect that Shachar's as negative about this as he is in part because having RAII go wrong with the kind of low-level stuff Weka does would be a serious problem, whereas if you're not dealing with some sort of resource management in the constructor, having it not unwind properly on failure isn't likely to be a big deal (much as it's still not good), because it's just going to leave the constructed object in a worse state, and it's not going to be used anyway, because the constructor failed.

> My personal opinion is that constructors that throw are an execrable programming practice, and I've wanted to ban them. (Andrei, while sympathetic to the idea, felt that too many people relied on it.) I won't allow throwing constructors in dmd or any software I have authority over.

Wow. I'm surprised by this. I definitely agree with David on this one. Without being able to throw from a constructor, you can't really have it fail, and there are times when it needs to be able to fail. Not being able to have throwing constructors basically means having to do two-part initialization which I would have thought was almost universally considered bad. I would consider constructors and exceptions to go absolutely hand-in-hand and wouldn't expect a language without exceptions to have constructors unless maybe it constructed all objects on the heap such that the result could be null and could thus checked for failure afterwards.

> (Having throwing destructors is even worse, it's just madness. Although it is allowed in C++, it doesn't actually work.)

Yeah. We probably should have required that destructors be nothrow and force destructor failures to be treated as Errors. I recall Herb Sutter wanting to making default destructors in C++11 to be noexcept, but the committee decided not to because of some stray code base that was doing something insane with exceptions and destructors. We could probably still fix it in D (particularly since I think that it is generally accepted that throwing from destructors is a bad idea), but it would undoubtedly break code simply because of functions being called which aren't nothrow but won't actually throw - thus forcing stuff like

try
{
    ...
}
catch(Exception)
    assert(0);

I expect that you'd have a riot on your hands though if you actually tried to push for getting rid of throwing constructors.

- Jonathan M Davis

On Friday, 24 August 2018 at 01:57:03 UTC, Shachar Shemesh wrote:
> At this point I can either use the work-around I already have and (try to, obviously unsuccessfully) forget about it, file a bug report that will be (justifiably) ignored because no-one else can reproduce it, or spend an unknown amount of time (two days would probably be low-balling at this point) in trying to get this to reproduce on a watered down version of the code.
>

1. use the work-around, then
2. spend two man days, spread over two weeks 30-60 minutes at a time, trying to reproduce on a watered down version of code , i.e. trying to isolate the problem
3. refactor once the real problem is found

from this nice article written by one of the better visionary developer John Ousterhout
> If you don't know what the problem was, you haven't fixed it
http://web.stanford.edu/~ouster/cgi-bin/sayings.php