dmd 1.041 and 2.026 releases

[Andrei Alexandrescu]

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> I wish somehow all this nice philosophy about aircraft would somehow 
>> found its way in the compiler implementation.
> 
> I was referring to the language design, but yes, I think some of it is 
> in the compiler implementation. In your criticism, you should also 
> realize the Boeing is extremely conservative about adopting new designs. 
> D is not conservative in that way at all, we're constantly trying out 
> new things, and that means crashes and the occasional blowup on the 
> launch pad <g>.
> 
> It took about 20 years of flying jet engines in aircraft, and iterative 
> improvements, to really work the usability problems out.
> 
> I once had an illuminating conversation with the lead engineer of the 
> 757 cockpit design. I (stupidly) said it was obvious how to design the 
> controls. He mildly replied that everything that looked obvious was paid 
> for by someone who splattered his brains over the instrument panel, and 
> the obviousness of the right way to do it was discovered only later 
> after careful analysis.
> 
> 
>> Or perhaps it *is* the main cause of the problems with the compielr 
>> implementation.  I finally found out why dmd was crashing on my 
>> program with nothing but "Segmentation fault":
>>
>> assert(puu.is_empty());
>>
>> was used in my old code instead of:
>>
>> assert(puu.empty());
>>
>> This was inside a template class and was enough to have the compiler 
>> segfault leaving me with no line and not even file information. 
>> Combine that with templates and multiple files and -lib compiling, and 
>> you'll see just how pernicious that is. (If you answer and the answer 
>> contains "binary search", I'll drop to the ground and start kicking it 
>> with my arms and legs. Binary search for where compilation fails DOES 
>> NOT WORK! It is search but NOWHERE NEAR binary.)
> 
> I agree that the line number thing is a constant problem. It really is a 
> load of special cases.
> 
> 
>> If you allow me a little criticism, I did notice different pattern 
>> which may also be derived from a systematic mechanical engineering 
>> approach: there generality could be improved. From the hail of bugs 
>> that hit my face on a daily basis, I notice that stuff that works 
>> works only for the situations it was tested, and subsequently bug 
>> fixes only fix one particular situation, not an entire class of 
>> problems. That's why reenactments of bugs are not infrequent. Without 
>> having looked at the dmd source, I'd conjecture that it contains in 
>> many places a hodge-podge of particular cases instead of consistently 
>> looking to nail the general problem. I guess this would be the way to 
>> go in mechanical engineering, where restrictions of the natural world 
>> make the by-case analysis easier to carry exhaustively.
> 
> In my defense, I'll point out that you said that when you did "Modern 
> C++ Design" you had similar issues with C++ compilers not working. You 
> are writing code right out on the edge, and often over the edge, of what 
> has been implemented in the compiler.
> 
> I'm not making excuses, but it's often hard to see what the general case 
> is until after the special cases are accounted for. Then it's time for 
> refactoring can cleanup.
> 
> When I implement a new feature, there isn't (by definition) any existing 
> body of code that uses it. So I have no test cases, nothing, other than 
> what I cobble together. You're often the first person to use the feature 
> in a substantive way.
> 
> Special cases are an odd thing with computers. What a computer sees as a 
> special case a user sees as a generalization, and vice versa. 
> Programming languages struggle with this dissonance all the time. For a 
> recent example on the n.g., 'void' is a special case to the compiler, 
> but a general case to the programmer.
> 
> Back in college, a science historian did a nice lecture on how research 
> was done. He said that in reading the scientists' notebooks, he found 
> that they went all over the place in trying to find a solution. When 
> they finally found it, they wrote a paper where they presented their 
> activities as a straight line progression from hypothesis to proof, 
> whereas the reality of how it actually happened was nothing like that.
> 
> I also wish to point out that despite dmd being written in C++, it has 
> had very few memory corruption bugs in the last 10 years. (Lars found 
> one I introduced with the Mac port.) I attribute that to changing my 
> coding style to a way which heads them off, but that wasn't possible 
> without long experience with them. The problems you're seeing are with 
> the new stuff, not the old stuff.

Well this is all nice and dandy, but lately dmd does next to nothing to 
improve my mood. I gotta tell about this bug because it's very illustrative.

The newly-added local instantiation continued to not work in one rather 
obvious case when it should have, with the error:

std/algorithm.d(4228): function std.algorithm.topNIndex!("a > 
b",cast(SwapStrategy)0,int[],ubyte[]).topNIndex.BinaryHeap!(ubyte[],indirectLess).BinaryHeap.heapify 
cannot get frame pointer to indirectLess

The pointed-to line was:

public void heapify(Range r, size_t i)

I spent a couple of of hours on figuring out what was going on. I tried 
simpler cases - they all compiled. I tried to comment out code in 
std.algorithm until there was only a shell of empty function - it didn't 
compile.

At some point, in a bout of exasperation, I removed the redundant 
"public". (I've put it there to remind myself and you about a bug that 
disallows private functions.) In the context it was redundant - it did 
absolutely nothing. As soon as I removed it, the unittest compiled, 
linked, and ran.

I have no idea how the redundant "public" is so important to something 
completely unrelated. But I can tell that a design that needs to handle 
that as a special case, and in which the very interaction is allowed to 
occur on separate code paths,... well, I better stop here.


Andrei