Walter Bright wrote:
> Leandro Lucarella wrote:
>> Walter Bright, el  5 de marzo a las 11:37 me escribiste:
>>> Tomas Lindquist Olsen wrote:
>>>> Compiling on linux from source is broken! Looks like you forgot to include the total.h file!
>>> You don't need it, I'll fix the makefile. total.h is for precompiled headers, which don't even exist on gcc.
>>
>> I don't know exactly what you mean, but: http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
>>
> 
> I suppose it's been added since the last time I looked. gcc has thousands of switches.

There are days when I can get upset at you for not implementing feature X.  I really need X, damnit.  Do you have any idea how badly I want X?!

...

And then I do something that requires me to look at the man page for gcc.  And then I die a little inside.

It's strange at times, but I do appreciate that you take a considerable amount of convincing.  It's a bit like the situation with Archchancellor Mustrum Ridcully from Discworld; he holds the view that if someone is still trying to explain something to him after about 2 minutes, it must be worth listening to, and if they give up earlier, it was not worth bothering him with in the first place.

Obviously, s/minutes/years/ :P

  -- Daniel

Daniel Keep wrote:
> 
> Walter Bright wrote:
>> Leandro Lucarella wrote:
>>> Walter Bright, el  5 de marzo a las 11:37 me escribiste:
>>>> Tomas Lindquist Olsen wrote:
>>>>> Compiling on linux from source is broken! Looks like you forgot to
>>>>> include the total.h file!
>>>> You don't need it, I'll fix the makefile. total.h is for precompiled
>>>> headers, which don't even exist on gcc.
>>> I don't know exactly what you mean, but:
>>> http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
>>>
>> I suppose it's been added since the last time I looked. gcc has
>> thousands of switches.
> 
> There are days when I can get upset at you for not implementing feature
> X.  I really need X, damnit.  Do you have any idea how badly I want X?!
> 
> ...
> 
> And then I do something that requires me to look at the man page for
> gcc.  And then I die a little inside.

Every command line switch that a compiler has is a failure of design. It reminds me of early jet engine controls for aircraft. There were all kinds of tweaks for it, and the pilot often got it wrong. The thing was eventually boiled down to a fantastically complicated mechanical box, that had one lever on it - "gimme more power".


> It's strange at times, but I do appreciate that you take a considerable
> amount of convincing.  It's a bit like the situation with Archchancellor
> Mustrum Ridcully from Discworld; he holds the view that if someone is
> still trying to explain something to him after about 2 minutes, it must
> be worth listening to, and if they give up earlier, it was not worth
> bothering him with in the first place.

The C++ standards committee has a good system for that. They won't consider any ideas unless they are submitted as papers. The idea is that if someone doesn't care enough about a feature to write a paper about it, it isn't worth the committee's time.

I'm not willing to go that far, but working on D is a full time job for me. New ideas and proposals come in *every single day*. I cannot even *read* them all, let alone prepare an intelligent reply even in saying it's not a good idea.

Walter Bright wrote:
> Daniel Keep wrote:
>>
>> Walter Bright wrote:
>>> Leandro Lucarella wrote:
>>>> Walter Bright, el  5 de marzo a las 11:37 me escribiste:
>>>>> Tomas Lindquist Olsen wrote:
>>>>>> Compiling on linux from source is broken! Looks like you forgot to
>>>>>> include the total.h file!
>>>>> You don't need it, I'll fix the makefile. total.h is for precompiled
>>>>> headers, which don't even exist on gcc.
>>>> I don't know exactly what you mean, but:
>>>> http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
>>>>
>>> I suppose it's been added since the last time I looked. gcc has
>>> thousands of switches.
>>
>> There are days when I can get upset at you for not implementing feature
>> X.  I really need X, damnit.  Do you have any idea how badly I want X?!
>>
>> ...
>>
>> And then I do something that requires me to look at the man page for
>> gcc.  And then I die a little inside.
> 
> Every command line switch that a compiler has is a failure of design. It reminds me of early jet engine controls for aircraft. There were all kinds of tweaks for it, and the pilot often got it wrong. The thing was eventually boiled down to a fantastically complicated mechanical box, that had one lever on it - "gimme more power".

I wish somehow all this nice philosophy about aircraft would somehow found its way in the compiler implementation. 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.)

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.


Andrei

Walter Bright:
> New ideas and proposals come in *every single day*.

Consider yourself a very lucky person for this.

Bye,
bearophile

bearophile wrote:
> Walter Bright:
>> New ideas and proposals come in *every single day*.
> 
> Consider yourself a very lucky person for this.

Sure. It's an embarrassment of riches.

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.

Walter Bright wrote:
> [...] 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. [...]

Reminds me of Parnas' "A rational design process: How and why to fake it"... =)

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

Download page says so:
http://www.digitalmars.com/d/download.html

I've never noticed this until i make proposal for my friends.
Thanks.

On Fri, 13 Mar 2009 13:12:47 -0400, The Anh Tran wrote:

> Download page says so:
> http://www.digitalmars.com/d/download.html
>
> I've never noticed this until i make proposal for my friends.
> Thanks.


The whole 1.0 branch is supposed to be stable (meaning, no new features only bug fixes).  There have been releases that were unusable due to obscure introduced bugs, but there are definitely more recent versions than 1.030 that were usable.  I use 1.038 at the moment.

I have no idea why 1.030 is annointed the stable version.

-Steve