www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D2 is really that stable as it is claimed to be?

reply "Zhouxuan" <pycerl qq.com> writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 LOCs 
written down.
Should I continue?

Despite these tiny issues, I see a lot of people complain about 
container, GC etc, but I can't found any offical reply, also no 
roadmap at all.
Sep 21 2013
next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=11086
 http://d.puremagic.com/issues/show_bug.cgi?id=11010
 http://d.puremagic.com/issues/show_bug.cgi?id=10970

 I've found and reported these bugs after about merely 100 LOCs 
 written down.
 Should I continue?

 Despite these tiny issues, I see a lot of people complain about 
 container, GC etc, but I can't found any offical reply, also no 
 roadmap at all.

Yes, it is unstable and still is advertized as being so. There are significant misfunctioning features which would break code when are fixed, let alone each release breaks something minor. For example, I was pissed off two days ago when git-head dmd rejected to compile large code base due to some 'enum overflow' error. Being watching bugzilla and github for two years, that change was neither expected nor clear for me. Now I see, that two years ago when I abandoned not reach for features but fully stable lang, I was undervaluing neccessity of a lang to be a stable.
Sep 21 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 11:03 AM, Maxim Fomin wrote:
 For example, I was pissed off two days ago when
 git-head dmd rejected to compile large code base due to some 'enum overflow'
 error. Being watching bugzilla and github for two years, that change was
neither
 expected nor clear for me.

Enum members with no initializer are defined to be set to the previous enum member's value + 1. This, of course, can overflow if the previous value is the max value for the type. For example, enum E { A = int.max, B } C:\cbx\mars>dmd test test.d(3): Error: enum member test.E.B overflow of enum value cast(E)2147483647 This change was made because the behavior of ignoring the overflow was listed as a bug. Since you said it was unclear, how could this be made clear? ------------------------------------ As C code: enum E { A = 2147483647, B }; and gcc reports: test.c:4: error: overflow in enumeration values
Sep 21 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 12:38 PM, eles wrote:
 On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote:
 On 9/21/2013 11:03 AM, Maxim Fomin wrote:

 test.c:4: error: overflow in enumeration values

It would be difficult to make the front-end track also the column number where it encountered (estimated) the error?

That's gcc, and 4 is the line number (and the wrong line number) of the error. No column number.
 This will make error messages a bit more clear (and in the line of thos in
gcc),
 especially for long code lines (where you could have, for example, several
 instructions on the line).

 At the beginning, until the feature is really implemented, the front-end could
 always provide "column=1", ie stick with current approach.

 But this will help the gdc/ldc-implementations to be in line with the messages
 provided by gcc and clang.

Tracking the column number is certainly doable, but it comes at a cost of memory consumption and some compile speed, since it has to be tracked in every token. I used to do it in the Digital Mars C compiler, but it was of only marginal utility and I dropped it.
Sep 21 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 21.09.2013 23:03, schrieb eles:
 On Saturday, 21 September 2013 at 19:47:08 UTC, Walter Bright wrote:
 On 9/21/2013 12:38 PM, eles wrote:
 On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote:
 On 9/21/2013 11:03 AM, Maxim Fomin wrote:

 test.c:4: error: overflow in enumeration values

It would be difficult to make the front-end track also the column number where it encountered (estimated) the error?

That's gcc, and 4 is the line number (and the wrong line number) of the error. No column number.

I knew that.
 This will make error messages a bit more clear (and in the line of
 thos in gcc),
 especially for long code lines (where you could have, for example,
 several
 instructions on the line).

 At the beginning, until the feature is really implemented, the
 front-end could
 always provide "column=1", ie stick with current approach.

 But this will help the gdc/ldc-implementations to be in line with the
 messages
 provided by gcc and clang.

Tracking the column number is certainly doable, but it comes at a cost of memory consumption and some compile speed, since it has to be tracked in every token. I used to do it in the Digital Mars C compiler, but it was of only marginal utility and I dropped it.

See this thread, pls: http://forum.dlang.org/thread/vtpcxubtuquvelsofafy forum.dlang.org Also, this link ("C family") for colors and caret: http://gcc.gnu.org/gcc-4.9/changes.html clang implemented this and pressure was put on gcc to do the same. Good and clear diagnostic messages/display are of big help, I think.

The funny thing is that this was already supported since a few years in the form of colorgcc. -- Paulo
Sep 21 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 5:11 PM, Sean Kelly wrote:
 Tracking the column number is certainly doable, but it comes at a cost of
 memory consumption and some compile speed, since it has to be tracked in
 every token. I used to do it in the Digital Mars C compiler, but it was of
 only marginal utility and I dropped it.

Can't you just hold a pointer to the beginning of the line and subtract to find the column? I agree that it's generally of marginal utility though.

Holding the pointer has a cost of memory consumption and compile speed :-) as well as having to have the source file buffer stay around throughout the compile (to compute column number you need the source in order to account for tabs & Unicode). Of course, we can cheat and use a byte to store the column number, as after all, nobody has more than 256 columns. Then you get a bug report where someone does. So raise it to an unsigned short, then, sigh, you get another bug report where someone's entire source file is on one line, and on it goes.
Sep 21 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 6:09 PM, Sean Kelly wrote:
 A single pointer per file isn't much memory and a write per line isn't much
 of a speed hit. Fair point about holding the file in memory except that DMD
 does this anyway. Mine wasn't a general comment so much as one specifically
 about the D front end. As for the rest, if you can see the problems with an
 approach before starting then don't do it that way. :-)

It isn't once per file, it's once per node in the AST, plus all the copying around of the value(s).
Sep 21 2013
next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-09-22 01:45:33 +0000, Walter Bright <newshound2 digitalmars.com> said:

 On 9/21/2013 6:09 PM, Sean Kelly wrote:
 A single pointer per file isn't much memory and a write per line isn't much
 of a speed hit. Fair point about holding the file in memory except that DMD
 does this anyway. Mine wasn't a general comment so much as one specifically
 about the D front end. As for the rest, if you can see the problems with an
 approach before starting then don't do it that way. :-)

It isn't once per file, it's once per node in the AST, plus all the copying around of the value(s).

You could *replace* the line number with a "byte from start of file" and then compute lazily either the line number or the column number for the rare times where you actually need to get the line or column number. (Ideally you'd also keep a map of the byte offset for the start of each line in a file to make that computation fast.) Column values are of interest in an IDE because it can pinpoint the error more precisely. The IDE can show exactly where the error is (for instance with a dotted red underline), often allowing you to fix the error without even reading the error message (especially when it's a typo). With a background-compilation-as-you-type system you know almost immediately when you make an error, and you know where it is. I do agree that it is of minor interest when you're reading the error log. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Sep 21 2013
next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-09-22 03:32:26 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:

 On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote:
 Column values are of interest in an IDE because it can pinpoint the
 error more precisely. The IDE can show exactly where the error is (for
 instance with a dotted red underline), often allowing you to fix the
 error without even reading the error message (especially when it's a
 typo). With a background-compilation-as-you-type system you know almost
 immediately when you make an error, and you know where it is.

A lexer being used by an IDE definitely needs the column number, but the normal compiler doesn't.

I was referring to how the IDE can show the compiler's error messages better when the column number is available, not to how it does syntax highlighting. Xcode uses this a lot, and clang's error log provides full character ranges for errors, not just a column number, making the visualization of errors much better and pleasant to work with. But indeed, no one *needs* that. Like everything else, it's just a convenience. I don't think it should be a priority, but rejecting the idea outright is shortsighted in my opinion. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Sep 21 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 8:54 PM, Michel Fortin wrote:
 I don't think it should be a priority, but rejecting the idea outright is
 shortsighted in my opinion.

I'm not rejecting the idea outright. I've actually implemented this in the dmc compiler. It's just not terribly useful, and it has costs.
Sep 21 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-22 07:22, Walter Bright wrote:

 I'm not rejecting the idea outright. I've actually implemented this in
 the dmc compiler. It's just not terribly useful, and it has costs.

Several people has asked for it and the LLVM community thinks it's worth it. -- /Jacob Carlborg
Sep 23 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2013 10:29 AM, Sean Kelly wrote:
 On Sep 21, 2013, at 10:22 PM, Walter Bright <newshound2 digitalmars.com>
 wrote:
 I'm not rejecting the idea outright. I've actually implemented this in the
 dmc compiler. It's just not terribly useful, and it has costs.

I'd consider it in a similar class as the dictionary lookup that occurs when an unknown symbol is encountered. Totally unnecessary, but it's a nice time-saver.

It's not in the same category, because that feature has zero cost. Again, it's about the cost of it.
Sep 24 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2013 10:33 AM, Iain Buclaw wrote:
 GCC has a carat too now.

DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user.
Sep 24 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/24/2013 10:26 PM, Walter Bright wrote:
 On 9/23/2013 10:33 AM, Iain Buclaw wrote:
 GCC has a carat too now.

DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user.

You have used lack of comments as an indicator of quality in the past.
Sep 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 3:27 PM, Timon Gehr wrote:
 You have used lack of comments as an indicator of quality in the past.

Lack of comments does mean something. BTW, as I wrote in another post here, I've prompted people about it, due to the silence. Read there what their response was.
Sep 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 4:43 PM, Dicebot wrote:
 You may underestimate power of marketing in IT world :)

i.e. compiler fashion!
 It does not matter how
 useful feature was on its own - clang guys has convinced the crowd it is useful
 so now it is useful. Its actual merit is irrelevant unless you want to invest
 into "counter-propaganda".

Probably the most insightful comment in this thread.
Sep 24 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/25/2013 01:55 AM, Walter Bright wrote:
 On 9/24/2013 4:43 PM, Dicebot wrote:
 You may underestimate power of marketing in IT world :)

i.e. compiler fashion!
 It does not matter how
 useful feature was on its own - clang guys has convinced the crowd it
 is useful
 so now it is useful. Its actual merit is irrelevant unless you want to
 invest
 into "counter-propaganda".

Probably the most insightful comment in this thread.

It should be noted however, that it is completely vacuous in a context where the goal is to infer something about the actual merit.
Sep 25 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 2:23 PM, David Nadlinger wrote:
 On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright wrote:
 On 9/23/2013 10:33 AM, Iain Buclaw wrote:
 GCC has a carat too now.

DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user.

Maybe that's because "not one single person" actually uses DMC? ;)

yes, I've had a fantasy business for the last 30 years.
Sep 24 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 2:56 PM, Andrej Mitrovic wrote:
 It seems nobody comments on almost anything DMC-related anyway. Isn't
 this the DMC newsgroup: http://forum.dlang.org/group/c++ ? If it is,
 there's hardly a single post per month..

You overlook that it's a very old compiler - 30 years. In its day it had maybe 100,000 users. People do still use it today, to compile dmd for Win32 for example, and nobody has yet EVER commented on that feature, unless I prompted them, when I have pointed it out many times over the decades, and the response is always: SO WHAT WHO CARES etc. So please forgive my grumpiness about if clang implements it, suddenly it's the greatest, most useful feature ever.
Sep 24 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 4:17 PM, Walter Bright wrote:
 So please forgive my grumpiness about if clang implements it, suddenly it's
 the greatest, most useful feature ever.

Don't get me wrong, I'm not automatically against anything that clang does. The spell-checking on undefined symbols is a nice idea, and we've now got our own version of it in dmd (and in dmc!).
Sep 24 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 5:39 PM, deadalnix wrote:
 It doesn't seem that surprising to me. If you want a compiler that is fast, you
 use DMC, if you want a compiler that will do coffee, you use GCC or clang
recently.
 I do think the user base you judge on is biased.

I'm sorry, I don't believe the dmc user base secretly loved that feature. Which is why I dropped it from dmd, despite having spent significant time making it work nice in dmc.
Sep 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 8:45 PM, deadalnix wrote:
 That is the exact opposite. People that like feature rich compiler already use
 another compiler. People that like minimal tooling and speed uses DMC.

Except that no other compiler at the time did the caret thing. It was a unique feature of DMC. DMC (or Zortech C++, back in the 80's), was the feature rich compiler of its day.
Sep 24 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 10:54 PM, "Luís Marques" <luis luismarques.eu>" wrote:
 Walter, I'm sorry to hear your frustration on this issue of the error caret,
and
 the lack of recognition you got for your dmc implementation of that concept.

 For what it's worth the following is my opinion:

 - I think I first met an error caret in the javac compiler, around 2000. I
found
 it very nice and useful. My positive experience was not preceded by any
 "marketing" of that feature, so I think we can conclude that my enjoyment was
 genuine.

 - When clang added nice error diagnostics in general (compared to GCC at the
 time) and the caret in particular that helped shape my perception of that
 compiler in a positive light, whatever the actual technical merits of that
 compiler may be.

 - In general I think dmd is quite a good compiler but I regularly mumble to
 myself "hmm, the compiler could have provided better diagnostics for this error
 I committed". I can start compiling a list of those errors with less than great
 error messages, if that's useful.

Yes, it is useful. Please do so, and add them to bugzilla.
 - Based on my experience with javac and clang, providing a caret (and ranges
 around the offending expressions, as in clang) is very useful *to me*, and I
 would be very pleased to see them on the D compilers, even if that information
 was not present in the debugger, so as not to regress compiler performance.

Thank you for a very reasonable reply.
Sep 24 2013
parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 25/09/2013 17:45, Sean Kelly wrote:
 On Sep 24, 2013, at 11:14 PM, Walter Bright <newshound2 digitalmars.com> wrote:

 On 9/24/2013 10:54 PM, "Lus Marques" <luis luismarques.eu>" wrote:

 - Based on my experience with javac and clang, providing a caret (and ranges
 around the offending expressions, as in clang) is very useful *to me*, and I
 would be very pleased to see them on the D compilers, even if that information
 was not present in the debugger, so as not to regress compiler performance.

Thank you for a very reasonable reply.

Yeah, I've never cared about having this information in the debugger. Only at compile time.

What does it even mean to have column/source-range information for errors in the debugger?? There is no notion of language errors or warnings in the debugger in the first place. Unless you mean for an expression evaluator (a pretty advanced feature)? -- Bruno Medeiros - Software Engineer
Sep 25 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-25 06:33, Walter Bright wrote:

 Except that no other compiler at the time did the caret thing. It was a
 unique feature of DMC.

 DMC (or Zortech C++, back in the 80's), was the feature rich compiler of
 its day.

Perhaps people didn't care about it back then. But oblivious people care now. You said "I'd have a different attitude about it if just one person had ever said "cool" when I showed them that feature". People _are_ asking for it now. -- /Jacob Carlborg
Sep 25 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/25/2013 01:17 AM, Walter Bright wrote:
 On 9/24/2013 2:56 PM, Andrej Mitrovic wrote:
 It seems nobody comments on almost anything DMC-related anyway. Isn't
 this the DMC newsgroup: http://forum.dlang.org/group/c++ ? If it is,
 there's hardly a single post per month..

You overlook that it's a very old compiler - 30 years. In its day it had maybe 100,000 users. People do still use it today, to compile dmd for Win32 for example, and nobody has yet EVER commented on that feature, unless I prompted them, when I have pointed it out many times over the decades, and the response is always: SO WHAT WHO CARES etc. So please forgive my grumpiness about if clang implements it, suddenly it's the greatest, most useful feature ever.

30 years (pitifully) seems to be a plausible time frame for an idea of merit to become fashionable.
Sep 25 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 4:59 PM, Sean Kelly wrote:
 I'm sure you know this, but no one ever comments on stuff they like.  Only
stuff they don't.

Except that people often did comment on things they liked about dmc, like its compile speed. Sure, not as often, but it's been 30 years. And, dmd users are often dmc users. Since dmd never had it, and dmc did, wouldn't anyone have suggested "hey, I like this dmc feature, why not put it in dmd?" But nope.
Sep 24 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-24 22:26, Walter Bright wrote:

 DMC has had a carat for 30 years now.

    int x x;
          ^
    test2.c(2) : Error: missing ',' between declaration of 'x' and 'x'

 Nobody ever gave a damn about that feature, i.e. not one single person
 commented on it, including not a single D user.

Honestly, I don't care if DMC does it or not. I want DMD to do it. -- /Jacob Carlborg
Sep 25 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2013 11:38 AM, bearophile wrote:
 2) The other improvement I'd like for D error messages and warnings is to give
a
 standard error number. This is a simple improvement, but it makes simpler to
 write explanation pages for the errors. The C# compiler and other compilers
have
 them.

I used to do that, but again, it was a completely unwanted feature, and I abandoned it. It's simple enough to grep for the error message text, and I myself prefer to do the grep method. What makes me grumpy is people only want these things when some other compiler does it, sort of a bandwagon thing.
Sep 24 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 4:38 PM, Brad Roberts wrote:
 I think it's less a bandwagon thing and more a the bar has been raised thing.
 30 years ago ide's were essentially unheard of.  Tooling around compilers and
 languages was almost non-existent.  The picture and expectations about user
 friendliness today are drastically different.  The past is not a perfect
 predictor of the present.

Borland pretty much invented the modern IDE back in the 80's, and before then Emacs served as an IDE (it was able to parse compiler output and display the location of errors and the associated messages). Besides, the ^ thing was for those who didn't use IDEs, not for people who do. I'd have a different attitude about it if just one person had ever said "cool" when I showed them that feature, and even in the (several) times this has come up before in this ng, and I point out that dmc does it, the reaction seems to be faint annoyance that dmc did it decades before clang :-) grump grump grump BTW, I don't really recall if dmc invented the feature or if I'd seen it before on some other compiler. Too long ago.
Sep 24 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2013 12:07 PM, Andrej Mitrovic wrote:
 On 9/23/13, bearophile <bearophileHUGS lycos.com> wrote:
 1) One of them is the "aka", that is showing both the name of
 aliases and the aliased types/values:
 http://d.puremagic.com/issues/show_bug.cgi?id=5004

I have a partial implementation of this in one of my branches, but IIRC it was difficult do cover all cases since the compiler internally inserts a bunch of aliases as well. Those could be marked that they're internal, so that's fixable. Another issue I ran into is that diagnostics are called after the retrieval of the aliased-to type, which basically means by the time the compiler issues errors the alias declaration is gone, the compiler only works on the target symbol. I had a workaround for this, but it's going to take more work to get done.

I worry that this is too complicated to be worthwhile.
Sep 24 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2013 3:04 PM, bearophile wrote:
 The problem with grepping is that it could lead to mistakes, you have to grep
 for the whole error message, otherwise you risk finding the wrong message.

It's hardly a risk. If you get 2 hits, you skip the one that's a mismatch.
 Another problem is that the wording could change, both in different versions of
 the same compiler and in different compilers, so every compiler needs its own
 wiki.

That problem is MUCH WORSE with error numbers. Remember, I have tried it in the past.
 Also, if you need to use a search, you must have all the error messages in
 the same page, while with error messages you could just go directly to the page
 number and you don't need to copy and paste several (all) the words of the
error
 message. Having a standard number across all D compilers allows for a
 standardization of tools (the IDE has to show the same error tooltips
regardless
 the D compiler you are using). Another advantage of numbers of error messages
is
 that if two different points of the same compiler have to generate the same
 error, using the same code number there is no risk the error message could go
 out of sync to each other. This has happened in DMD, where I have seen the same
 error give different error messages with the same dmd
 (http://d.puremagic.com/issues/show_bug.cgi?id=11094 ).

Standardization of error messages, let alone standardization of error message numbers, is a very bad idea. It presumes all implementations are identical, and hamstrings attempts at innovation.
 What makes me grumpy is people only want these things when some other
 compiler does it, sort of a bandwagon thing.

I have tried to show, here and in Issue 5004, that's not true.

I don't believe it, based on plenty of experience with "grass is greener" compiler ephemera.
Sep 24 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 8:17 PM, Michel Fortin wrote:
 You could *replace* the line number with a "byte from start of file" and then
 compute lazily either the line number or the column number for the rare times
 where you actually need to get the line or column number. (Ideally you'd also
 keep a map of the byte offset for the start of each line in a file to make that
 computation fast.)

That's an expensive computation. The trouble is, "compile with symbolic debug info on" is when you want fast compiles, and you'll need the line number everywhere.
 Column values are of interest in an IDE because it can pinpoint the error more
 precisely. The IDE can show exactly where the error is (for instance with a
 dotted red underline),

I do understand this.
Sep 21 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 9:34 PM, deadalnix wrote:
 Most issue are being worked on. That being said, changing semantic in a
 programming language is always a difficult matter, as people code relying on
the
 old bugguy behavior may break.

And often the same people who want semantic changes are the ones who complain when new features break things :-(
Sep 21 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/21/13 11:42 PM, deadalnix wrote:
 On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote:
 On 9/21/2013 9:34 PM, deadalnix wrote:
 Most issue are being worked on. That being said, changing semantic in a
 programming language is always a difficult matter, as people code
 relying on the
 old bugguy behavior may break.

And often the same people who want semantic changes are the ones who complain when new features break things :-(

Guilty here :D

We all are. Andrei
Sep 22 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/22/2013 02:33 AM, Walter Bright wrote:
 On 9/21/2013 5:11 PM, Sean Kelly wrote:
 Tracking the column number is certainly doable, but it comes at a
 cost of
 memory consumption and some compile speed, since it has to be tracked in
 every token. I used to do it in the Digital Mars C compiler, but it
 was of
 only marginal utility and I dropped it.

Can't you just hold a pointer to the beginning of the line and subtract to find the column? I agree that it's generally of marginal utility though.

Holding the pointer has a cost of memory consumption and compile speed :-)

(The current scheme is not optimal either.) struct Loc { const char *filename; // <-- unsigned linnum; Replace this pointer by a pointer or (global) offset to the first character in the source file buffer corresponding to the AST node. The file name can be recovered from this using an appropriate data structure. In order to find the first column index, decode backwards until you hit a newline character or the beginning of the source file. In order to find the last column index if that is wanted, re-invoke the parser. (Personally, I just store a slice into the source buffer.) This allows the compiler to underline the location where an error occurred: tt.d:7:14: error: need 'this' to access field 'S.member' auto x = S.member; ^~~~~~~~ tt.d:3:5: note: field was declared here int member; ^~~~~~~~~~~ Editors understand this format and can quickly jump to the location. You could also get rid of linnum by splitting the source file buffer into lines on demand and using binary search.
 as well as having to have the source file buffer stay around
 throughout the compile  ...

Which, as far as I understand, DMD does anyway? If you do not want to keep it around, release it and reload it on demand if an error actually occurs in that buffer. (Time taken to spit out an error message does not need to be optimized that much.)
Sep 22 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/22/2013 5:24 AM, Timon Gehr wrote:
[...]

Your proposal has a serious shortcoming: The fast path through the compiler is the one where people generate symbolic debug info. This requires file/line numbers for everything. Adding an arbitrarily expensive computation to get them makes for slow compiles.
Sep 22 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/22/2013 07:51 PM, Walter Bright wrote:
 ...
 The fast path through the compiler is the one where people generate
 symbolic debug info. This requires file/line numbers for everything.

Typically the file names of AST nodes that are processed consecutively coincide, and testing whether a location is in a given file is easy, so it is possible that this is not an issue at all. Line numbers can be stored without increasing the memory footprint in comparison with the current scheme.
 Adding an arbitrarily expensive computation to get them makes for slow
 compiles.

Tracking line numbers is likely worth it. I don't believe that providing column numbers in error messages necessitates a slowdown though. (Probably we should just implement/optimize and measure.)
Sep 22 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/22/2013 11:43 AM, Timon Gehr wrote:
 Tracking line numbers is likely worth it. I don't believe that providing column
 numbers in error messages necessitates a slowdown though.

Please consider that: IT ISN'T JUST FOR ERROR MESSAGES It would go in the symbolic debug info, too, where it will be required everywhere and will be right there on the fast path through the lexer/compiler. Now consider the lexer doing a fast skip over comment text (this ranks fairly high in the profile). This operation gets a lot slower if you're also keeping track of column number. Please note that: COLUMN NUMBER ISN'T THE OFFSET FROM THE START OF THE LINE because of tabs and UTF-8 sequences. Any proposal for column number tracking must take these issues into account. Also note that g++ and clang are hardly noted for their fast compile speeds. Also note that g++'s compile speed has dropped significantly lately - I don't know why, but it also added column number support recently (!).
Sep 22 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/22/2013 1:30 PM, bearophile wrote:
 If someone writes a front-end patch to show column numbers we'll have to
 benchmark it and decide how much complex/buggy it is and how much extra
 memory/time it asks for.

Sure.
Sep 22 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/22/2013 09:27 PM, Walter Bright wrote:
 On 9/22/2013 11:43 AM, Timon Gehr wrote:
 Tracking line numbers is likely worth it. I don't believe that
 providing column
 numbers in error messages necessitates a slowdown though.

Please consider that: IT ISN'T JUST FOR ERROR MESSAGES It would go in the symbolic debug info, too, where it will be required everywhere and will be right there on the fast path through the lexer/compiler. ...

There is no such thing as a law that obliges compiler writers to add column numbers in debug info when such information is available in frontend error messages. The trade-offs involved in both cases may be different and deserve separate consideration.
 Now consider the lexer doing a fast skip over comment text (this ranks
 fairly high in the profile). This operation gets a lot slower if you're
 also keeping track of column number.

I am not keeping track of column number.
 Please note that:

       COLUMN NUMBER ISN'T THE OFFSET FROM THE START OF THE LINE
 ...

Obviously. I compute the correct column number exactly in the case when an error message should actually be printed. It is not necessary to do any of this on the fast path. The additional memory word per location that I waste in comparison to DMD could be shaved off by using more computation in the error case (or by giving up support for exact underlining), but the project has not yet reached a stage where this is worth considering/measuring. Excerpts from actual code I wrote roughly two years ago: class Source{ // computes a slice of the entire first line // where some given slice occurs in the source buffer. // this allows to recover column information on the fly, and we // will also be able to print the line where an error occurred // without storing it explicitly. // running time is linear in output length string getLineOf(string rep)in{/*...*/}out{/*...*/}body{ string before=code[0..rep.ptr-code.ptr]; string after=code[rep.ptr-code.ptr..$]; immutable(char)* start=code.ptr, end=code.ptr+code.length; // It is fine to skip decoding here, because we are just // searching for ASCII characters. // TODO: support unicode line breaks? foreach_reverse(ref c; before) if(c=='\n'||c=='\r'){start = &c+1; break;} foreach(ref c; after) if(c=='\n'||c=='\r'){end = &c; break;} return start[0..end-start]; } // ... } struct Location{ string rep; // slice of the code representing the Location int line; // line number at start of location property Source source()const{ auto src = Source.get(rep); // (currently just a linear search) assert(src, "source for '"~rep~"' not found!"); return src; } // ... } int getColumn(Location loc, int tabsize){ int res=1; auto l=loc.source.getLineOf(loc.rep); for(;!l.empty&&l[0]&&l.ptr<loc.rep.ptr; l.popFront()){ if(l.front=='\t') res=res-res%tabsize+tabsize; else res++; } return res; }
Sep 23 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2013 12:19 PM, Timon Gehr wrote:
 There is no such thing as a law that obliges compiler writers to add column
 numbers in debug info when such information is available in frontend error
 messages.

I guarantee that if the error messages have column numbers, people will file bug reports that it doesn't show up in the debugger, and rightfully so.
Sep 24 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/24/2013 10:48 PM, Walter Bright wrote:
 On 9/23/2013 12:19 PM, Timon Gehr wrote:
 There is no such thing as a law that obliges compiler writers to add
 column
 numbers in debug info when such information is available in frontend
 error
 messages.

I guarantee that if the error messages have column numbers, people will file bug reports that it doesn't show up in the debugger, and rightfully so.

In case the performance argument is valid, no, they would not be right.
Sep 24 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/22/2013 05:24 PM, Peter Alexander wrote:
 On Sunday, 22 September 2013 at 12:24:03 UTC, Timon Gehr wrote:
 You could also get rid of linnum by splitting the source file buffer
 into lines on demand and using binary search.

Does that work with #line?

Well, yes. Eg. collect their locations/line number pairs into an array while lexing and then process that during line splitting.
Sep 22 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/22/2013 7:50 AM, Andrej Mitrovic wrote:
 I run into these all the time, and I have to spend half a minute
 scanning left and right trying to figure out where the damn missing
 brace went. Marginal benefit my ass.

I programmed into my editor (MicroEmacs) the F3 command. F3, when sitting on one of ()[]{}<> will find the matching character, even if nested. If it is not on one of those characters, it finds the next occurrence of that character. As a bonus, if it is on the # character at the beginning of the line, it will find the matching #if, #ifdef, #elif, #else, or #endif :-) I find it very, very handy. It's based on an elithp macro written for Emacs back in the 1980's. If your editor has any ability to have user-written extensions, this is a simple one, and I highly recommend it. Here's the corresponding MicroEmacs implementation: ----------------------------------------------------------------------- /********************************* * Examine line at '.'. * Returns: * HASH_xxx * 0 anything else */ #define HASH_IF 1 #define HASH_ELIF 2 #define HASH_ELSE 3 #define HASH_ENDIF 4 static int ifhash(clp) LINE *clp; { register int len; register int i,h; static char *hash[] = {"if","elif","else","endif"}; len = llength(clp); if (len < 3 || lgetc(clp,0) != '#') goto ret0; for (i = 1; ; i++) { if (i >= len) goto ret0; if (!isspace(lgetc(clp,i))) break; } for (h = 0; h < arraysize(hash); h++) if (len - i >= strlen(hash[h]) && memcmp(&clp->l_text[i],hash[h],strlen(hash[h])) == 0) return h + 1; ret0: return 0; } /********************************* * Search for the next occurence of the character at '.'. * If character is a (){}[]<>, search for matching bracket. * If '.' is on #if, #elif, or #else search for next #elif, #else or #endif. * If '.' is on #endif, search backwards for corresponding #if. */ int search_paren(f, n) { register LINE *clp; register int cbo; register int len; register int i; char chinc,chdec,ch; int count; int forward; int h; static char bracket[][2] = {{'(',')'},{'<','>'},{'[',']'},{'{','}'}}; clp = curwp->w_dotp; /* get pointer to current line */ cbo = curwp->w_doto; /* and offset into that line */ count = 0; len = llength(clp); if (cbo >= len) chinc = '\n'; else chinc = lgetc(clp,cbo); if (cbo == 0 && (h = ifhash(clp)) != 0) { forward = h != HASH_ENDIF; } else { if (inword()) { // Search for word the cursor is currently on int s; do s = backchar(FALSE, 1); while (s && inword()); if (s && forwchar(FALSE, 1)) { int start = curwp->w_doto; if (word_forw(FALSE, 1)) { cbo = curwp->w_doto; int i; for (i = 0; i < NPAT - 1 && start + i < cbo; i++) { pat[i] = lgetc(clp, start + i); } pat[i] = 0; if (Dsearchagain(f, n)) return backchar(FALSE, 1); } } mlwrite("Not found"); return FALSE; } forward = TRUE; /* forward */ h = 0; chdec = chinc; for (i = 0; i < 4; i++) if (bracket[i][0] == chinc) { chdec = bracket[i][1]; break; } for (i = 0; i < 4; i++) if (bracket[i][1] == chinc) { chdec = bracket[i][0]; forward = FALSE; /* search backwards */ break; } } while (1) /* while not end of buffer */ { if (forward) { if (h || cbo >= len) { clp = lforw(clp); if (clp == curbp->b_linep) /* if end of buffer */ break; len = llength(clp); cbo = 0; } else cbo++; } else /* backward */ { if (h || cbo == 0) { clp = lback(clp); if (clp == curbp->b_linep) break; len = llength(clp); cbo = len; } else --cbo; } if (h) { int h2; cbo = 0; h2 = ifhash(clp); if (h2) { if (h == HASH_ENDIF) { if (h2 == HASH_ENDIF) count++; else if (h2 == HASH_IF) { if (count-- == 0) goto found; } } else { if (h2 == HASH_IF) count++; else { if (count == 0) goto found; if (h2 == HASH_ENDIF) count--; } } } } else { ch = (cbo < len) ? lgetc(clp,cbo) : '\n'; if (eq(ch,chdec)) { if (count-- == 0) { /* We've found it */ found: curwp->w_dotp = clp; curwp->w_doto = cbo; curwp->w_flag |= WFMOVE; return (TRUE); } } else if (eq(ch,chinc)) count++; } } mlwrite("Not found"); return (FALSE); }
Sep 22 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-22 04:38, Paul Jurczak wrote:

 That would do: 255 means column 256 or higher (256+). You would please
 more than 99.99% of users :-)

We have lines with over 400 columns at work. Yes I know, horrible. -- /Jacob Carlborg
Sep 23 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-21 21:47, Walter Bright wrote:

 That's gcc, and 4 is the line number (and the wrong line number) of the
 error. No column number.

It's time you start using clang instead of gcc. -- /Jacob Carlborg
Sep 23 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 2:40 PM, Maxim Fomin wrote:
 Thanks, that is clear. Unfortunately, I cannot say that the explanation
improves
 my attidute to the language - dmd still breaks too often code and some
 significant features (like AAs, scope, shared) are at risk to be seriously
 changed which is a serious problem to the user.

I'm curious - was there a logic bug in your code with the overflow, or had that been the intended behavior?
Sep 21 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 3:11 PM, Maxim Fomin wrote:
 On Saturday, 21 September 2013 at 22:06:07 UTC, Walter Bright wrote:
 On 9/21/2013 2:40 PM, Maxim Fomin wrote:
 Thanks, that is clear. Unfortunately, I cannot say that the explanation
improves
 my attidute to the language - dmd still breaks too often code and some
 significant features (like AAs, scope, shared) are at risk to be seriously
 changed which is a serious problem to the user.

I'm curious - was there a logic bug in your code with the overflow, or had that been the intended behavior?

This was bug in gtkd sources when I tried to compile its most recent version (tried even from github) with git-head dmd. I think it is a problem of gtkd developers rather than dmd.

Ok, so it found a latent bug in the source code - I don't think that's a good example of dmd being unstable - it was a good change.
Sep 21 2013
parent reply Mike Wey <mike-wey example.com> writes:
On 09/22/2013 12:36 AM, Walter Bright wrote:
 On 9/21/2013 3:11 PM, Maxim Fomin wrote:
 On Saturday, 21 September 2013 at 22:06:07 UTC, Walter Bright wrote:
 On 9/21/2013 2:40 PM, Maxim Fomin wrote:
 Thanks, that is clear. Unfortunately, I cannot say that the
 explanation improves
 my attidute to the language - dmd still breaks too often code and some
 significant features (like AAs, scope, shared) are at risk to be
 seriously
 changed which is a serious problem to the user.

I'm curious - was there a logic bug in your code with the overflow, or had that been the intended behavior?

This was bug in gtkd sources when I tried to compile its most recent version (tried even from github) with git-head dmd. I think it is a problem of gtkd developers rather than dmd.

Ok, so it found a latent bug in the source code - I don't think that's a good example of dmd being unstable - it was a good change.

I've reduced the code causing the error to this: ``` public enum GTokenType { NONE, } public enum GtkRcTokenType { INVALID = GTokenType.NONE, INCLUDE, } ``` In this case the value of INVALID + 1 isn't large enough the overflow an int. In the actual code: https://github.com/gtkd-developers/GtkD/blob/master/src/gtkc/glibtypes.d#L1310 Setting NONE to a value lower than 87 makes it so the code compiles without error, which only makes things weirder. -- Mike Wey
Sep 22 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/22/2013 10:16 AM, Mike Wey wrote:
 I've reduced the code causing the error to this:

http://d.puremagic.com/issues/show_bug.cgi?id=11101
Sep 22 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/22/2013 10:43 AM, Walter Bright wrote:
 On 9/22/2013 10:16 AM, Mike Wey wrote:
 I've reduced the code causing the error to this:

http://d.puremagic.com/issues/show_bug.cgi?id=11101

Upon looking at it more closely, the bug is invalid, and the compiler is correct. See the report for the explanation.
Sep 22 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/22/13 1:12 AM, Paolo Invernizzi wrote:
 On Saturday, 21 September 2013 at 22:08:23 UTC, Andrej Mitrovic wrote:
 On 9/21/13, Maxim Fomin <maxim maxim-fomin.ru> wrote:
 (like AAs, scope, shared) are at risk to be seriously changed which is a
 serious problem to the user.

These are already a serious problem to the user when they're broken and under-implemented.

I'm really hoping for an improvement of shared and the concurrency field. It's a pity having someone that having read the concurrency chapter of TDPL (for free, also!) start toying with shared and... "hey, it does not works that way? where's the "actual" documentation then? what is the timeline? what? no timeline? gheeez" (really happened, BTY) /Paolo

Probably this should be the next focal area. Andrei
Sep 22 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Zhouxuan:

 http://d.puremagic.com/issues/show_bug.cgi?id=11086
 http://d.puremagic.com/issues/show_bug.cgi?id=11010
 http://d.puremagic.com/issues/show_bug.cgi?id=10970

 I've found and reported these bugs after about merely 100 LOCs 
 written down.

D is not claimed to be stable, or those claims are wrong. About three years ago I used to find a new compiler bug about every 20 lines of my code. Now the situation is improved a lot and I am able to write more lines before hitting bugs. They have fixed hundreds of the bugs I have submitted, so dmd is now more debugged for the code patterns I usually write. If your code patterns are different from mine, you will see significantly more bugs than me :-)
 Should I continue?

Of course you should continue to submit bugs. Fixing 100+ bugs in every D release is having positive visible effects on the language+compiler. If you submit bugs and they get fixed in some days/weeks/months/years, your code patterns will work more and more.
 Despite these tiny issues, I see a lot of people complain about 
 container, GC etc, but I can't found any offical reply, also no 
 roadmap at all.

There is no official roadmap because D is not developed in that way, and because there is not enough workforce. Perhaps someday a roadmap will be present. Bye, bearophile
Sep 21 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/21/13 1:06 PM, bearophile wrote:
 Jakob Bornecrantz:

 On the other
 hand unstable for that matter, none of those pages really
 convey that shit _IS_ going to break every new compiler
 release, proceed with caution.

I agree, and in my opinion this should be fixed adding a small note to the D home page, that explains that you should expect every new D version to break your older code and that someday this will stop. Is Andrei agreeing on this small homepage change?

I'm ambivalent because the matter is fuzzy. It is factually true that new releases will break code. On the other hand, that is the case with most compiler releases even for mature languages (at Facebook upgrading across minor gcc releases _always_ entails significant disruption). On the third hand (sic), there are companies and projects using D in the real world so stating that is unstable would do little else than either shoo people away for no good reason. Andrei
Sep 21 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 2:27 PM, bearophile wrote:
 While I don't have a solution for that that fuzzy problem, I can express some
 opinions:
 - My technical training has taught me to trust honest lists of problems more
 than advertisements of technology wonders that break at my first usage;

I believe that bugzilla is an honest list of the problems. It's the whole point of bugzilla.
Sep 21 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 3:27 PM, bearophile wrote:
 Walter Bright:

 I believe that bugzilla is an honest list of the problems. It's the whole
 point of bugzilla.

So are you saying that Bugzilla is enough for new or future D users that want to know how much stable D is?

It's an honest list of the problems, for anyone who wants to look at them, and they can then make up their own mind about stability based on their needs.
Sep 21 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-21 23:12, Andrei Alexandrescu wrote:

 I'm ambivalent because the matter is fuzzy. It is factually true that
 new releases will break code. On the other hand, that is the case with
 most compiler releases even for mature languages (at Facebook upgrading
 across minor gcc releases _always_ entails significant disruption). On
 the third hand (sic), there are companies and projects using D in the
 real world so stating that is unstable would do little else than either
 shoo people away for no good reason.

Some of these companies still use D1. About the code breakage. I think it's still an issue that bugfixes and language changes occur in the same release. No notation of major, minor and patch releases. -- /Jacob Carlborg
Sep 23 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=11086
 http://d.puremagic.com/issues/show_bug.cgi?id=11010
 http://d.puremagic.com/issues/show_bug.cgi?id=10970

 I've found and reported these bugs after about merely 100 LOCs 
 written down.
 Should I continue?

 Despite these tiny issues, I see a lot of people complain about 
 container, GC etc, but I can't found any offical reply, also no 
 roadmap at all.

D is not what I would call stable, but it is very usable. Apparently D is used at Facebook in some capacity, but Andrei won't tell us more than that :-) Not long ago I would find bugs every hour or so, but now I rarely find bugs. Perhaps I have just learned to write code in the subset of D that works well, but the language is definitely a lot more stable. Please continue to submit bugs. The D contributors do fix bugs very rapidly in general.
Sep 21 2013
prev sibling next sibling parent reply "QAston" <qaston gmail.com> writes:
On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=11086
 http://d.puremagic.com/issues/show_bug.cgi?id=11010
 http://d.puremagic.com/issues/show_bug.cgi?id=10970

 I've found and reported these bugs after about merely 100 LOCs 
 written down.
 Should I continue?

I have had similar feelings when I started with D i think. Well, as soon as you see a language which has so many capabilities you've never seen before in one place (reflection and native code - yay!) you start pushing it to the limit. Sometimes you're doing a thing noone even thought about before :). Exercising the capabilites of D is fun but there are some things which do not work yet. After some experience I've settled on using a simpler subset of D functionality; both because I think simpler sollutions are better and because simpler parts of D tend to work very well. Go ahead and report more bugs, this is improving the situation in longer term. People which will use D after you will be glad you've spent a little time on doing that because their experience will be smoother. It'd be nice if D was perfect already but things simply take a lot of time and effort to be done. It's hard to compete with already mature enviroments because of that.
 Despite these tiny issues, I see a lot of people complain about 
 container, GC etc, but I can't found any offical reply, also no 
 roadmap at all.

As for containers there's std.container and builtin arrays and hasmaps - that's somewhat a poor set, but you can use container libraries from github. Containers as planned for phobos need solving the issue of allocators for them. Andrei which is working on them is probably stuck in void somewhere between compiletime and runtime worlds :)
Sep 21 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/21/13 12:28 PM, QAston wrote:
 Containers as planned for phobos need solving the issue of allocators
 for them.  Andrei which is working on them is probably stuck in void
 somewhere between compiletime and runtime worlds :)

FWIW I am making solid progress on allocators. In places the design comes together really really unexpectedly nice. To the original poster: thanks for submitting those bugs. They concern simple code and it is an embarrassment for us that this kind of "out-of-the-box experience" bugs still appear. Andrei
Sep 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright 
wrote:
 On 9/21/2013 11:03 AM, Maxim Fomin wrote:

 test.c:4: error: overflow in enumeration values

It would be difficult to make the front-end track also the column number where it encountered (estimated) the error? This will make error messages a bit more clear (and in the line of thos in gcc), especially for long code lines (where you could have, for example, several instructions on the line). At the beginning, until the feature is really implemented, the front-end could always provide "column=1", ie stick with current approach. But this will help the gdc/ldc-implementations to be in line with the messages provided by gcc and clang.
Sep 21 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2013 10:41 AM, Zhouxuan wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=11086
 http://d.puremagic.com/issues/show_bug.cgi?id=11010
 http://d.puremagic.com/issues/show_bug.cgi?id=10970

 I've found and reported these bugs after about merely 100 LOCs written down.
 Should I continue?

 Despite these tiny issues, I see a lot of people complain about container, GC
 etc, but I can't found any offical reply, also no roadmap at all.

Thanks for taking the time to make some nice bug reports. They're a big help.
Sep 21 2013
prev sibling next sibling parent "Jakob Bornecrantz" <wallbraker gmail.com> writes:
On Saturday, 21 September 2013 at 18:23:20 UTC, bearophile wrote:
 Zhouxuan:

 http://d.puremagic.com/issues/show_bug.cgi?id=11086
 http://d.puremagic.com/issues/show_bug.cgi?id=11010
 http://d.puremagic.com/issues/show_bug.cgi?id=10970

 I've found and reported these bugs after about merely 100 LOCs 
 written down.

D is not claimed to be stable, or those claims are wrong.

Then again _NOWHERE_ on the start page, the overview page or the download* page is the word stable found. On the other hand unstable for that matter, none of those pages really convey that shit _IS_ going to break every new compiler release, proceed with caution. * Stable is found there but referring to the latest GDC release.
Sep 21 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jakob Bornecrantz:

 On the other
 hand unstable for that matter, none of those pages really
 convey that shit _IS_ going to break every new compiler
 release, proceed with caution.

I agree, and in my opinion this should be fixed adding a small note to the D home page, that explains that you should expect every new D version to break your older code and that someday this will stop. Is Andrei agreeing on this small homepage change? Bye, bearophile
Sep 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Saturday, 21 September 2013 at 19:47:08 UTC, Walter Bright 
wrote:
 On 9/21/2013 12:38 PM, eles wrote:
 On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright 
 wrote:
 On 9/21/2013 11:03 AM, Maxim Fomin wrote:

 test.c:4: error: overflow in enumeration values

It would be difficult to make the front-end track also the column number where it encountered (estimated) the error?

That's gcc, and 4 is the line number (and the wrong line number) of the error. No column number.

I knew that.
 This will make error messages a bit more clear (and in the 
 line of thos in gcc),
 especially for long code lines (where you could have, for 
 example, several
 instructions on the line).

 At the beginning, until the feature is really implemented, the 
 front-end could
 always provide "column=1", ie stick with current approach.

 But this will help the gdc/ldc-implementations to be in line 
 with the messages
 provided by gcc and clang.

Tracking the column number is certainly doable, but it comes at a cost of memory consumption and some compile speed, since it has to be tracked in every token. I used to do it in the Digital Mars C compiler, but it was of only marginal utility and I dropped it.

See this thread, pls: http://forum.dlang.org/thread/vtpcxubtuquvelsofafy forum.dlang.org Also, this link ("C family") for colors and caret: http://gcc.gnu.org/gcc-4.9/changes.html clang implemented this and pressure was put on gcc to do the same. Good and clear diagnostic messages/display are of big help, I think.
Sep 21 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I'm ambivalent because the matter is fuzzy. It is factually 
 true that new releases will break code. On the other hand, that 
 is the case with most compiler releases even for mature 
 languages (at Facebook upgrading across minor gcc releases 
 _always_ entails significant disruption). On the third hand 
 (sic), there are companies and projects using D in the real 
 world so stating that is unstable would do little else than 
 either shoo people away for no good reason.

While I don't have a solution for that that fuzzy problem, I can express some opinions: - My technical training has taught me to trust honest lists of problems more than advertisements of technology wonders that break at my first usage; - I am now keeping lot of D2 code updated and in use, and the work needed to keep it working release after release of dmd was a bit too much for me. If I fix the code only every release there are multiple different sources of breakage and they interact making fixing code harder. I solved that compiling dmd once or more every week. Dmd compiles in a very short time, and I test my whole code base in a short time, both at compile-time and in unittests. Now there only one source of breaking, I know what's the cause of the breaking because it's from the last days of merged patches, and fixing code takes a very short time. - Often the "breakage" is actually just an exposition of true or latent bugs in my D code. Such "breaking" is welcome and I want more of it. Bye, bearophile
Sep 21 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright 
wrote:
 On 9/21/2013 11:03 AM, Maxim Fomin wrote:
 For example, I was pissed off two days ago when
 git-head dmd rejected to compile large code base due to some 
 'enum overflow'
 error. Being watching bugzilla and github for two years, that 
 change was neither
 expected nor clear for me.

Enum members with no initializer are defined to be set to the previous enum member's value + 1. This, of course, can overflow if the previous value is the max value for the type. For example, enum E { A = int.max, B } C:\cbx\mars>dmd test test.d(3): Error: enum member test.E.B overflow of enum value cast(E)2147483647 This change was made because the behavior of ignoring the overflow was listed as a bug. Since you said it was unclear, how could this be made clear? ------------------------------------ As C code: enum E { A = 2147483647, B }; and gcc reports: test.c:4: error: overflow in enumeration values

Thanks, that is clear. Unfortunately, I cannot say that the explanation improves my attidute to the language - dmd still breaks too often code and some significant features (like AAs, scope, shared) are at risk to be seriously changed which is a serious problem to the user.
Sep 21 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Maxim Fomin:

 Thanks, that is clear. Unfortunately, I cannot say that the 
 explanation improves my attidute to the language - dmd still 
 breaks too often code and some significant features (like AAs, 
 scope, shared) are at risk to be seriously changed which is a 
 serious problem to the user.

The creation of such breaking changes should have priority over (= happen sooner than) most other compiler changes and bug fixes. Beside AAs, scope, and shared, another smaller example of such breaking changes was discussed a lot today: http://d.puremagic.com/issues/show_bug.cgi?id=11080 http://d.puremagic.com/issues/show_bug.cgi?id=4733 In Issue 11080 someone has asked to disallow code like: assert("something going wrong"); But I suggest to not add that rule and instead implement the small breaking change discussed in Issue 4733, that disallows the use of dynamic arrays in all boolean evaluation contexts. So Issue 11080 becomes a special case that needs no special testing code in the compiler. Bye, bearophile
Sep 21 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/21/13, Maxim Fomin <maxim maxim-fomin.ru> wrote:
 (like AAs, scope, shared) are at risk to be seriously changed which is a
 serious problem to the user.

These are already a serious problem to the user when they're broken and under-implemented.
Sep 21 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 21 September 2013 at 21:58:44 UTC, bearophile wrote:
 Maxim Fomin:

 Thanks, that is clear. Unfortunately, I cannot say that the 
 explanation improves my attidute to the language - dmd still 
 breaks too often code and some significant features (like AAs, 
 scope, shared) are at risk to be seriously changed which is a 
 serious problem to the user.

The creation of such breaking changes should have priority over (= happen sooner than) most other compiler changes and bug fixes. Beside AAs, scope, and shared, another smaller example of such breaking changes was discussed a lot today: http://d.puremagic.com/issues/show_bug.cgi?id=11080 http://d.puremagic.com/issues/show_bug.cgi?id=4733

Yes, unfortunately D problems are not limited to those mentioned.
 In Issue 11080 someone has asked to disallow code like:

 assert("something going wrong");

 But I suggest to not add that rule and instead implement the 
 small breaking change discussed in Issue 4733, that disallows 
 the use of dynamic arrays in all boolean evaluation contexts. 
 So Issue 11080 becomes a special case that needs no special 
 testing code in the compiler.

 Bye,
 bearophile

Well, it is an option to ban dynamic arrays in boolean conditions because the way they are implemented right now is buggy, but I consider fixing semantic and still keeping syntax to be a better option comparing to a complete ban.
Sep 21 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 21 September 2013 at 22:06:07 UTC, Walter Bright 
wrote:
 On 9/21/2013 2:40 PM, Maxim Fomin wrote:
 Thanks, that is clear. Unfortunately, I cannot say that the 
 explanation improves
 my attidute to the language - dmd still breaks too often code 
 and some
 significant features (like AAs, scope, shared) are at risk to 
 be seriously
 changed which is a serious problem to the user.

I'm curious - was there a logic bug in your code with the overflow, or had that been the intended behavior?

This was bug in gtkd sources when I tried to compile its most recent version (tried even from github) with git-head dmd. I think it is a problem of gtkd developers rather than dmd.
Sep 21 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I believe that bugzilla is an honest list of the problems. It's 
 the whole point of bugzilla.

So are you saying that Bugzilla is enough for new or future D users that want to know how much stable D is? Bye, bearophile
Sep 21 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Maxim Fomin:

 Well, it is an option to ban dynamic arrays in boolean 
 conditions
 because the way they are implemented right now is buggy, but I
 consider fixing semantic and still keeping syntax to be a better
 option comparing to a complete ban.

Right, fixing that semantic is another option I listed in Issue 4733 :-) Bye, bearophile
Sep 21 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 21, 2013, at 12:47 PM, Walter Bright <newshound2 digitalmars.com> wro=
te:

 On 9/21/2013 12:38 PM, eles wrote:
 On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote:
 On 9/21/2013 11:03 AM, Maxim Fomin wrote:
=20
 test.c:4: error: overflow in enumeration values

It would be difficult to make the front-end track also the column number w=


 it encountered (estimated) the error?

That's gcc, and 4 is the line number (and the wrong line number) of the er=

=20
 This will make error messages a bit more clear (and in the line of thos i=


 especially for long code lines (where you could have, for example, severa=


 instructions on the line).
=20
 At the beginning, until the feature is really implemented, the front-end c=


 always provide "column=3D1", ie stick with current approach.
=20
 But this will help the gdc/ldc-implementations to be in line with the mes=


 provided by gcc and clang.

Tracking the column number is certainly doable, but it comes at a cost of m=

y token. I used to do it in the Digital Mars C compiler, but it was of only m= arginal utility and I dropped it. Can't you just hold a pointer to the beginning of the line and subtract to f= ind the column? I agree that it's generally of marginal utility though.=20=
Sep 21 2013
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Saturday, 21 September 2013 at 20:00:52 UTC, Jakob Bornecrantz 
wrote:
 On Saturday, 21 September 2013 at 18:23:20 UTC, bearophile 
 wrote:
 Zhouxuan:

 http://d.puremagic.com/issues/show_bug.cgi?id=11086
 http://d.puremagic.com/issues/show_bug.cgi?id=11010
 http://d.puremagic.com/issues/show_bug.cgi?id=10970

 I've found and reported these bugs after about merely 100 
 LOCs written down.

D is not claimed to be stable, or those claims are wrong.

Then again _NOWHERE_ on the start page, the overview page or the download* page is the word stable found. On the other hand unstable for that matter, none of those pages really convey that shit _IS_ going to break every new compiler release, proceed with caution. * Stable is found there but referring to the latest GDC release.

I've found my code to not break very frequently anymore even using git head. The last thing that broke any of my code was the stringof change in git head, and that was a 2 minute fix. I think it's been 2-3 minor releases before that at least.
Sep 21 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 21, 2013, at 5:33 PM, Walter Bright <newshound2 digitalmars.com> wrot=
e:

 On 9/21/2013 5:11 PM, Sean Kelly wrote:
 Tracking the column number is certainly doable, but it comes at a cost o=



 memory consumption and some compile speed, since it has to be tracked in=



 every token. I used to do it in the Digital Mars C compiler, but it was o=



 only marginal utility and I dropped it.

Can't you just hold a pointer to the beginning of the line and subtract t=


 find the column?  I agree that it's generally of marginal utility though.=


=20
 Holding the pointer has a cost of memory consumption and compile speed :-)=

compile (to compute column number you need the source in order to account f= or tabs & Unicode).
=20
 Of course, we can cheat and use a byte to store the column number, as afte=

=20
 Then you get a bug report where someone does. So raise it to an unsigned s=

ile is on one line, and on it goes. A single pointer per file isn't much memory and a write per line isn't much o= f a speed hit. Fair point about holding the file in memory except that DMD d= oes this anyway. Mine wasn't a general comment so much as one specifically a= bout the D front end. As for the rest, if you can see the problems with an a= pproach before starting then don't do it that way. :-)=
Sep 21 2013
prev sibling next sibling parent "Paul Jurczak" <pauljurczak yahoo.com> writes:
On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote:
 On 9/21/2013 5:11 PM, Sean Kelly wrote:
 Tracking the column number is certainly doable, but it comes 
 at a cost of
 memory consumption and some compile speed, since it has to be 
 tracked in
 every token. I used to do it in the Digital Mars C compiler, 
 but it was of
 only marginal utility and I dropped it.

Can't you just hold a pointer to the beginning of the line and subtract to find the column? I agree that it's generally of marginal utility though.

Holding the pointer has a cost of memory consumption and compile speed :-) as well as having to have the source file buffer stay around throughout the compile (to compute column number you need the source in order to account for tabs & Unicode). Of course, we can cheat and use a byte to store the column number, as after all, nobody has more than 256 columns. [...]

That would do: 255 means column 256 or higher (256+). You would please more than 99.99% of users :-)
Sep 21 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, September 22, 2013 04:38:40 Paul Jurczak wrote:
 That would do: 255 means column 256 or higher (256+). You would
 please more than 99.99% of users :-)

Except that most of us don't care about the column number. It's of marginal benefit at best, and it harms compilation speed, so it's not worth it IMHO. - Jonathan M Davis
Sep 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 21 September 2013 at 19:51:42 UTC, Andrei 
Alexandrescu wrote:
 On 9/21/13 12:28 PM, QAston wrote:
 Containers as planned for phobos need solving the issue of 
 allocators
 for them.  Andrei which is working on them is probably stuck 
 in void
 somewhere between compiletime and runtime worlds :)

FWIW I am making solid progress on allocators. In places the design comes together really really unexpectedly nice.

That is the sign of great design, or because the error is so obviously that nobody checked against it. Can you give q quick update on that in some topic ?
Sep 21 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote:
 Column values are of interest in an IDE because it can pinpoint the
 error more precisely. The IDE can show exactly where the error is (for
 instance with a dotted red underline), often allowing you to fix the
 error without even reading the error message (especially when it's a
 typo). With a background-compilation-as-you-type system you know almost
 immediately when you make an error, and you know where it is.

A lexer being used by an IDE definitely needs the column number, but the normal compiler doesn't. - Jonathan M Davis
Sep 21 2013
prev sibling next sibling parent "Zhouxuan" <pycerl qq.com> writes:
 From what I see, as a new user of D, D's current feature set is 
so exciting and rich enough that I'm willing to give it a try. 
However, I feel frustrated because some simple usage about some 
feature I excerice failed, take AA for example, it's a basic 
feature as described in TDPL, but I even can't use it to store an 
array indexed by a string 
(http://d.puremagic.com/issues/show_bug.cgi?id=10970),no matter 
whatever you explaned, it's the truth that I feel AA is not 
usable and I give up AA (or maybe whole D given that AA is 
advertised to be a very basic feature).It's really a big problem 
and you guys should focus more on it if D wanna gain more 
popularity IMHO.
On the other hand, D's feature is attractive, no matter how much 
buggy is it, the expectation that it'll be solved once D gain 
more popularity and more and more programmers are innvolved in D 
may keep me learn and practise D as a hobby, but where's the 
expectation comes from? IMHO, D need a more organized team, meet 
once a week or two on irc, report your effort and finally post it 
to public (maybe filtered) like Rust meeting on its wiki page. So 
that every new user is convinced that D's in a virtuous circle 
and every issue they care about is being worked on, as well as a 
future plan (if not being worked ATM) on those issues most 
mentioned in NG/IRC etc like GC.
FYI, as a new user both to D and Rust, Rust is more convinced to 
me in every aspect except for its current unstable status.Its 
mainpage, wiki page and github repo are far more informative and 
active than D's counter-part, why don't we learn from Rust?

Sincerely hope/wish D to be more successful!
Sep 21 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 22 September 2013 at 03:37:02 UTC, Zhouxuan wrote:
 feature as described in TDPL, but I even can't use it to store 
 an array indexed by a string

If you use the built in arrays instead of the std.container Array type it will work. It still shouldn't be segfaulting, but this isn't quite as basic a flaw as it seems, since the library Array type is pretty complex.
Sep 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 22 September 2013 at 03:37:02 UTC, Zhouxuan wrote:
 From what I see, as a new user of D, D's current feature set is 
 so exciting and rich enough that I'm willing to give it a try. 
 However, I feel frustrated because some simple usage about some 
 feature I excerice failed, take AA for example, it's a basic 
 feature as described in TDPL, but I even can't use it to store 
 an array indexed by a string 
 (http://d.puremagic.com/issues/show_bug.cgi?id=10970),no matter 
 whatever you explaned, it's the truth that I feel AA is not 
 usable and I give up AA (or maybe whole D given that AA is 
 advertised to be a very basic feature).It's really a big 
 problem and you guys should focus more on it if D wanna gain 
 more popularity IMHO.

Yes, AA is definitively the fastest road toward problems.
 On the other hand, D's feature is attractive, no matter how 
 much buggy is it, the expectation that it'll be solved once D 
 gain more popularity and more and more programmers are 
 innvolved in D may keep me learn and practise D as a hobby, but 
 where's the expectation comes from? IMHO, D need a more 
 organized team, meet once a week or two on irc, report your 
 effort and finally post it to public (maybe filtered) like Rust 
 meeting on its wiki page. So that every new user is convinced 
 that D's in a virtuous circle and every issue they care about 
 is being worked on, as well as a future plan (if not being 
 worked ATM) on those issues most mentioned in NG/IRC etc like 
 GC.

Most issue are being worked on. That being said, changing semantic in a programming language is always a difficult matter, as people code relying on the old bugguy behavior may break.
Sep 21 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 21 September 2013 at 22:36:44 UTC, Walter Bright 
wrote:
 Ok, so it found a latent bug in the source code - I don't think 
 that's a good example of dmd being unstable - it was a good 
 change.

OK, this was a latent bug in sources. I think this is not the first and not the last event when dmd starts rejecting buggy code. However that means that before the change dmd accepted invalid and this jeopardizes D implementation. And anyway, irrespectively of whether issue is a true regression or fixing accepts-invalid bug, for majority of users this doesn't play much role but means creating problems of code breakage in each release.
Sep 21 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, September 21, 2013 23:54:26 Michel Fortin wrote:
 On 2013-09-22 03:32:26 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:
 On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote:
 Column values are of interest in an IDE because it can pinpoint the
 error more precisely. The IDE can show exactly where the error is (for
 instance with a dotted red underline), often allowing you to fix the
 error without even reading the error message (especially when it's a
 typo). With a background-compilation-as-you-type system you know almost
 immediately when you make an error, and you know where it is.

A lexer being used by an IDE definitely needs the column number, but the normal compiler doesn't.

I was referring to how the IDE can show the compiler's error messages better when the column number is available, not to how it does syntax highlighting. Xcode uses this a lot, and clang's error log provides full character ranges for errors, not just a column number, making the visualization of errors much better and pleasant to work with. But indeed, no one *needs* that. Like everything else, it's just a convenience. I don't think it should be a priority, but rejecting the idea outright is shortsighted in my opinion.

I don't think that it's at all worth it for compiling with the compiler on the command line. The situation changes somewhat when an IDE gets involved. - Jonathan M Davis
Sep 21 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--e89a8f502fea2acbdf04e6f2cf74
Content-Type: text/plain; charset=UTF-8

2013/9/22 Zhouxuan <pycerl qq.com>

 http://d.puremagic.com/**issues/show_bug.cgi?id=10970<http://d.puremagic.com/issues/show_bug.cgi?id=10970>

That is a long-standing bug around AA value setting and opAssign, and fortunately I recently tried to fix it by determining the language semantics. https://github.com/D-Programming-Language/dmd/pull/2539 Kenji Hara --e89a8f502fea2acbdf04e6f2cf74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/9/22 Zhouxuan <span dir=3D"ltr">&lt;<a href=3D"mailto= :pycerl qq.com" target=3D"_blank">pycerl qq.com</a>&gt;</span><br><div clas= s=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col= or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id=3D10970" target=3D= "_blank">http://d.puremagic.com/<u></u>issues/show_bug.cgi?id=3D10970</a></= blockquote><div><br></div><div>That is a long-standing bug around AA value = setting and opAssign, and fortunately I recently tried to fix it by determi= ning the language semantics.</div> <div><a href=3D"https://github.com/D-Programming-Language/dmd/pull/2539">ht= tps://github.com/D-Programming-Language/dmd/pull/2539</a><br></div><div><br=
</div><div>Kenji Hara</div></div><br></div></div>

--e89a8f502fea2acbdf04e6f2cf74--
Sep 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote:
 On 9/21/2013 9:34 PM, deadalnix wrote:
 Most issue are being worked on. That being said, changing 
 semantic in a
 programming language is always a difficult matter, as people 
 code relying on the
 old bugguy behavior may break.

And often the same people who want semantic changes are the ones who complain when new features break things :-(

Guilty here :D
Sep 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote:
 On 9/21/2013 5:11 PM, Sean Kelly wrote:
 someone's entire source file is on one line, and on it goes.

OTOH, this is exactly the showcase where such a feature would be *really* useful.
Sep 22 2013
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Saturday, 21 September 2013 at 22:08:23 UTC, Andrej Mitrovic 
wrote:
 On 9/21/13, Maxim Fomin <maxim maxim-fomin.ru> wrote:
 (like AAs, scope, shared) are at risk to be seriously changed 
 which is a
 serious problem to the user.

These are already a serious problem to the user when they're broken and under-implemented.

I'm really hoping for an improvement of shared and the concurrency field. It's a pity having someone that having read the concurrency chapter of TDPL (for free, also!) start toying with shared and... "hey, it does not works that way? where's the "actual" documentation then? what is the timeline? what? no timeline? gheeez" (really happened, BTY) /Paolo
Sep 22 2013
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote:
 On 9/21/2013 5:11 PM, Sean Kelly wrote:
 Tracking the column number is certainly doable, but it comes 
 at a cost of
 memory consumption and some compile speed, since it has to be 
 tracked in
 every token. I used to do it in the Digital Mars C compiler, 
 but it was of
 only marginal utility and I dropped it.

Can't you just hold a pointer to the beginning of the line and subtract to find the column? I agree that it's generally of marginal utility though.

Holding the pointer has a cost of memory consumption and compile speed :-) as well as having to have the source file buffer stay around throughout the compile (to compute column number you need the source in order to account for tabs & Unicode). Of course, we can cheat and use a byte to store the column number, as after all, nobody has more than 256 columns. Then you get a bug report where someone does. So raise it to an unsigned short, then, sigh, you get another bug report where someone's entire source file is on one line, and on it goes.

I'll go for a byte, and a well written ">256" in the message when necessary... a very good compromise I'll tell! /P
Sep 22 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote:
 On 9/21/2013 9:34 PM, deadalnix wrote:
 Most issue are being worked on. That being said, changing 
 semantic in a
 programming language is always a difficult matter, as people 
 code relying on the
 old bugguy behavior may break.

And often the same people who want semantic changes are the ones who complain when new features break things :-(

That is expected, logical and described to you several times :P
Sep 22 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/22/13, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 Except that most of us don't care about the column number. It's of marginal
 benefit at best, and it harms compilation speed, so it's not worth it IMHO.

You've never ran into lexer errors before have you? test.d(10): Error: found ',' when expecting ')' Now good luck finding where you forgot to put a closing brace in a statement that uses traits or is(typeof( checks, such as this: static assert(0, format("%s does not implement '%s'", __traits(identifier, typeof(this))), __FUNCTION__); It should have been: static assert(0, format("%s does not implement '%s'", __traits(identifier, typeof(this)), __FUNCTION__)); That's just a trivial case though. I run into these all the time, and I have to spend half a minute scanning left and right trying to figure out where the damn missing brace went. Marginal benefit my ass.
Sep 22 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 22 September 2013 at 12:24:03 UTC, Timon Gehr wrote:
 You could also get rid of linnum by splitting the source file 
 buffer into lines on demand and using binary search.

Does that work with #line?
Sep 22 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 22 September 2013 at 17:15:15 UTC, Mike Wey wrote:
 I've reduced the code causing the error to this:
 ```
 public enum GTokenType
 {
 	NONE,
 }

 public enum GtkRcTokenType
 {
 	INVALID = GTokenType.NONE,
 	INCLUDE,
 }
 ```

 In this case the value of INVALID + 1 isn't large enough the 
 overflow an int.

 In the actual code:
 https://github.com/gtkd-developers/GtkD/blob/master/src/gtkc/glibtypes.d#L1310
 Setting NONE to a value lower than 87 makes it so the code 
 compiles without error, which only makes things weirder.

Thanks, that's helpful.
Sep 22 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Any proposal for column number tracking must take these issues 
 into account.

 Also note that g++ and clang are hardly noted for their fast 
 compile speeds. Also note that g++'s compile speed has dropped 
 significantly lately - I don't know why, but it also added 
 column number support recently (!).

If someone writes a front-end patch to show column numbers we'll have to benchmark it and decide how much complex/buggy it is and how much extra memory/time it asks for. Bye, bearophile
Sep 22 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, September 22, 2013 09:36:45 eles wrote:
 On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote:
 On 9/21/2013 5:11 PM, Sean Kelly wrote:
 someone's entire source file is on one line, and on it goes.

OTOH, this is exactly the showcase where such a feature would be *really* useful.

True, but it's also a use case which is completely unreasonable and for which it would make no sense to even help out with, let alone optimize for. Anyone who writes source like that deserves to have problems finding where in the code an error is. - Jonathan M Davis
Sep 22 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Saturday, 21 September 2013 at 21:17:13 UTC, Paulo Pinto wrote:
 Am 21.09.2013 23:03, schrieb eles:
 On Saturday, 21 September 2013 at 19:47:08 UTC, Walter Bright 
 wrote:
 On 9/21/2013 12:38 PM, eles wrote:
 On Saturday, 21 September 2013 at 18:55:46 UTC, Walter 
 Bright wrote:
 On 9/21/2013 11:03 AM, Maxim Fomin wrote:




years in the form of colorgcc.

Yes, but it is only recently that gcc started to improve error messages, with 4.9 OTOH, column was displayed even before, but in plain text. For those using dmd or gdc and looking for something a bit on the line of colorgcc (albeit a coarser approach), check this piece of software: https://github.com/dmoulding/hilite/blob/master/hilite.c
Sep 22 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote:
 On 9/21/2013 5:11 PM, Sean Kelly wrote:

 buffer stay around throughout the compile (to compute column 
 number you need the source in order to account for tabs & 
 Unicode).

trade-off: print the offending line as seen in the analyzed file (after you process tabs&unicode), and refer the column wrt its beginning. Then display a caret on the next line. Even if not identical with the line in the original file, at least it's better than nothing.
Sep 22 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote:
 On 9/22/13, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 Except that most of us don't care about the column number. It's of
 marginal
 benefit at best, and it harms compilation speed, so it's not worth it
 IMHO.

You've never ran into lexer errors before have you? test.d(10): Error: found ',' when expecting ')' Now good luck finding where you forgot to put a closing brace in a statement that uses traits or is(typeof( checks, such as this: static assert(0, format("%s does not implement '%s'", __traits(identifier, typeof(this))), __FUNCTION__); It should have been: static assert(0, format("%s does not implement '%s'", __traits(identifier, typeof(this)), __FUNCTION__)); That's just a trivial case though. I run into these all the time, and I have to spend half a minute scanning left and right trying to figure out where the damn missing brace went. Marginal benefit my ass.

Except that because the compiler doesn't know where the terminator should have been, it can't give you a column number anyway. In that case, it can't even give you the correct line number. At best, it can tell you the line number where the unmatched symbol was, and that's often not helpful (especially with braces). And even with parens, because the compiler doesn't know what you actually meant to do, it's not like it can tell you where exactly in the expression or statement you need to fix your code anyway. I really don't think that a column number would help much here. - Jonathan M Davis
Sep 22 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/22/2013 2:17 PM, eles wrote:
 It is an important information when you have a LOC with 10 ')' and 20 commas.

Fortunately, D is not Lithp :-)
Sep 22 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Sunday, 22 September 2013 at 21:12:22 UTC, Jonathan M Davis 
wrote:
 On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote:
 On 9/22/13, Jonathan M Davis <jmdavisProg gmx.com> wrote:

know what you actually meant to do, it's not like it can tell you where

Maybe, but at least it can say: HERE, you see, HERE, this is the exact place where I was expecting a ')' and found a ','. I mean, HERE means the third comma on this line, not the second, not the fifth. It is an important information when you have a LOC with 10 ')' and 20 commas. Which comma is the trouble?
Sep 22 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 22 September 2013 20:27, Walter Bright <newshound2 digitalmars.com> wrote:
 On 9/22/2013 11:43 AM, Timon Gehr wrote:
 Tracking line numbers is likely worth it. I don't believe that providing
 column
 numbers in error messages necessitates a slowdown though.

Please consider that: IT ISN'T JUST FOR ERROR MESSAGES It would go in the symbolic debug info, too, where it will be required everywhere and will be right there on the fast path through the lexer/compiler. Now consider the lexer doing a fast skip over comment text (this ranks fairly high in the profile). This operation gets a lot slower if you're also keeping track of column number. Please note that: COLUMN NUMBER ISN'T THE OFFSET FROM THE START OF THE LINE because of tabs and UTF-8 sequences. Any proposal for column number tracking must take these issues into account. Also note that g++ and clang are hardly noted for their fast compile speeds. Also note that g++'s compile speed has dropped significantly lately - I don't know why, but it also added column number support recently (!).

Depends on what you mean by "recently". GCC has certainly gained a fair few compilation/optimisation passes over the past few releases. 4.3 - 223 passes (2008) 4.4 - 225 passes (2009) 4.5 - 239 passes (2010) 4.6 - 241 passes (2011) 4.7 - 252 passes (2012) 4.8 - 268 passes (2013) 4.9 - 269 passes (development) And showing column numbers has been turned on since gcc-4.4 (released in 2009). Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 22 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 23/09/13 07:12, Jonathan M Davis wrote:
 On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote:
 On 9/22/13, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 Except that most of us don't care about the column number. It's of
 marginal
 benefit at best, and it harms compilation speed, so it's not worth it
 IMHO.

You've never ran into lexer errors before have you? test.d(10): Error: found ',' when expecting ')' Now good luck finding where you forgot to put a closing brace in a statement that uses traits or is(typeof( checks, such as this: static assert(0, format("%s does not implement '%s'", __traits(identifier, typeof(this))), __FUNCTION__); It should have been: static assert(0, format("%s does not implement '%s'", __traits(identifier, typeof(this)), __FUNCTION__)); That's just a trivial case though. I run into these all the time, and I have to spend half a minute scanning left and right trying to figure out where the damn missing brace went. Marginal benefit my ass.

Except that because the compiler doesn't know where the terminator should have been, it can't give you a column number anyway. In that case, it can't even give you the correct line number. At best, it can tell you the line number where the unmatched symbol was, and that's often not helpful (especially with braces). And even with parens, because the compiler doesn't know what you actually meant to do, it's not like it can tell you where exactly in the expression or statement you need to fix your code anyway. I really don't think that a column number would help much here.

With my dunnart LALR(1) parser generator, the lexer that's generated as part of the generated parser passes its tokens as class instances that give access to the line number and column at which the token was found in the text and the exact slice of the input text that was matched to form the token. That information travels with the token (rather than being something you have ask the lexer for in most lexers e.g. flex) so it's always available no matter where the token pops up in the parser. Similarly, when the parser does a reduce, the non terminal grammar symbol acquires the positional data for the first token in the reduced sequence. Peter
Sep 22 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 21, 2013, at 10:22 PM, Walter Bright <newshound2 digitalmars.com> =
wrote:

 On 9/21/2013 8:54 PM, Michel Fortin wrote:
 I don't think it should be a priority, but rejecting the idea =


 shortsighted in my opinion.

I'm not rejecting the idea outright. I've actually implemented this in =

I'd consider it in a similar class as the dictionary lookup that occurs = when an unknown symbol is encountered. Totally unnecessary, but it's a = nice time-saver. Is it clang that displays the line in error with a = carat underneath the error? Though if there really isn't an efficient = way to do it in DMD then I don't think it's worthwhile. I was only = thinking of the parser when I mentioned the beginning-of-line pointer. = I hadn't considered the AST.=
Sep 23 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7bd75ac87014ca04e7106bff
Content-Type: text/plain; charset=ISO-8859-1

On Sep 23, 2013 6:30 PM, "Sean Kelly" <sean invisibleduck.org> wrote:
 On Sep 21, 2013, at 10:22 PM, Walter Bright <newshound2 digitalmars.com>

 On 9/21/2013 8:54 PM, Michel Fortin wrote:
 I don't think it should be a priority, but rejecting the idea outright



 shortsighted in my opinion.

I'm not rejecting the idea outright. I've actually implemented this in


 I'd consider it in a similar class as the dictionary lookup that occurs

nice time-saver. Is it clang that displays the line in error with a carat underneath the error? Though if there really isn't an efficient way to do it in DMD then I don't think it's worthwhile. I was only thinking of the parser when I mentioned the beginning-of-line pointer. I hadn't considered the AST. GCC has a carat too now. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7bd75ac87014ca04e7106bff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Sep 23, 2013 6:30 PM, &quot;Sean Kelly&quot; &lt;<a href=3D"mailto:sean = invisibleduck.org">sean invisibleduck.org</a>&gt; wrote:<br> &gt;<br> &gt; On Sep 21, 2013, at 10:22 PM, Walter Bright &lt;<a href=3D"mailto:news= hound2 digitalmars.com">newshound2 digitalmars.com</a>&gt; wrote:<br> &gt;<br> &gt; &gt; On 9/21/2013 8:54 PM, Michel Fortin wrote:<br> &gt; &gt;&gt; I don&#39;t think it should be a priority, but rejecting the = idea outright is<br> &gt; &gt;&gt; shortsighted in my opinion.<br> &gt; &gt;<br> &gt; &gt; I&#39;m not rejecting the idea outright. I&#39;ve actually implem= ented this in the dmc compiler. It&#39;s just not terribly useful, and it h= as costs.<br> &gt;<br> &gt; I&#39;d consider it in a similar class as the dictionary lookup that o= ccurs when an unknown symbol is encountered. =A0Totally unnecessary, but it= &#39;s a nice time-saver. =A0Is it clang that displays the line in error wi= th a carat underneath the error? =A0Though if there really isn&#39;t an eff= icient way to do it in DMD then I don&#39;t think it&#39;s worthwhile. =A0I= was only thinking of the parser when I mentioned the beginning-of-line poi= nter. =A0I hadn&#39;t considered the AST.</p> <p>GCC has a carat too now.</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --047d7bd75ac87014ca04e7106bff--
Sep 23 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Regarding the improving the error messages of D compilers, I 
think having the column number is nice, but there are two 
improvements that I think are more important:

1) One of them is the "aka", that is showing both the name of 
aliases and the aliased types/values:
http://d.puremagic.com/issues/show_bug.cgi?id=5004

2) The other improvement I'd like for D error messages and 
warnings is to give a standard error number. This is a simple 
improvement, but it makes simpler to write explanation pages for 
the errors. The C# compiler and other compilers have them.

Bye,
bearophile
Sep 23 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/23/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 I have a partial implementation of this in one of my branches

Also, I will not continue work on this unless Walter greenlights it. I'm not going to put any work that's inevitably going to be thrown away.
Sep 23 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/23/13, bearophile <bearophileHUGS lycos.com> wrote:
 1) One of them is the "aka", that is showing both the name of
 aliases and the aliased types/values:
 http://d.puremagic.com/issues/show_bug.cgi?id=5004

I have a partial implementation of this in one of my branches, but IIRC it was difficult do cover all cases since the compiler internally inserts a bunch of aliases as well. Those could be marked that they're internal, so that's fixable. Another issue I ran into is that diagnostics are called after the retrieval of the aliased-to type, which basically means by the time the compiler issues errors the alias declaration is gone, the compiler only works on the target symbol. I had a workaround for this, but it's going to take more work to get done.
Sep 23 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright 
wrote:
 On 9/23/2013 10:33 AM, Iain Buclaw wrote:
 GCC has a carat too now.

DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user.

Maybe that's because "not one single person" actually uses DMC? ;) I certainly find that feature very helpful in Clang. David
Sep 24 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/24/13, Walter Bright <newshound2 digitalmars.com> wrote:
 Nobody ever gave a damn about that feature, i.e. not one single person
 commented on it, including not a single D user.

It seems nobody comments on almost anything DMC-related anyway. Isn't this the DMC newsgroup: http://forum.dlang.org/group/c++ ? If it is, there's hardly a single post per month..
Sep 24 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/24/13, David Nadlinger <code klickverbot.at> wrote:
 Maybe that's because "not one single person" actually uses DMC? ;)

It's like building a bridge in the middle of Siberia and then saying that bridges are useless because hardly a dozen people use it a week.
Sep 24 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/24/13, Walter Bright <newshound2 digitalmars.com> wrote:
 I worry that this is too complicated to be worthwhile.

Unfortunately yes, the way the compiler is written right now would mean the feature would have to be implemented as a series of hacks. Perhaps if the implementation simplifies or we get another compiler.. :)
Sep 24 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I worry that this is too complicated to be worthwhile.

After seeing the error messages given by Clang I think it could be worthwhile. In C++ it has saved me debugging time.
 I used to do that, but again, it was a completely unwanted 
 feature, and I
 abandoned it.
 It's simple enough to grep for the error message text, and I 
 myself prefer
 to do the grep method.

At the moment in D learn people show the error messages generated by dmd and don't know what to do. An archive of errors, one error for each wiki page, is useful because the user sees a longer description of the error, plus two examples of it (where it could be recognized better if it's really the right error), plus explanations how to fix it, like to use "const" or "inout" or to use an alias inside a class etc. The problem with grepping is that it could lead to mistakes, you have to grep for the whole error message, otherwise you risk finding the wrong message. Another problem is that the wording could change, both in different versions of the same compiler and in different compilers, so every compiler needs its own wiki. Also, if you need to use a search, you must have all the error messages in the same page, while with error messages you could just go directly to the page number and you don't need to copy and paste several (all) the words of the error message. Having a standard number across all D compilers allows for a standardization of tools (the IDE has to show the same error tooltips regardless the D compiler you are using). Another advantage of numbers of error messages is that if two different points of the same compiler have to generate the same error, using the same code number there is no risk the error message could go out of sync to each other. This has happened in DMD, where I have seen the same error give different error messages with the same dmd (http://d.puremagic.com/issues/show_bug.cgi?id=11094 ).
 What makes me grumpy is people only want these things when some 
 other
 compiler does it, sort of a bandwagon thing.

I have tried to show, here and in Issue 5004, that's not true. And even if it's just a fashion as you say, I could argue that in computer science and programming there are far worse fashions people cling to. Sometimes when you create an engineering product it's not enough for it to be technically very good, you also have to wrap it in a colourful, fashion-aware and pretty paper. If you miss doing that, you are doing 99% of the necessary work for success but you are missing far more than the 1% of "overall appreciation" for your product. Bye, bearophile
Sep 24 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 Unfortunately yes, the way the compiler is written right now 
 would
 mean the feature would have to be implemented as a series of 
 hacks.
 Perhaps if the implementation simplifies or we get another 
 compiler..
 :)

You could show somewhere what are the implementation simplifications you need to implement that feature cleanly. Perhaps Kenji will be interested. Issue 5004 is not a fashion-based enhancement request. Don't let the status quo stop the improvement of the D compilers :-) Bye, bearophile
Sep 24 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 25/09/13 06:29, Walter Bright wrote:
 On 9/23/2013 11:38 AM, bearophile wrote:
 2) The other improvement I'd like for D error messages and warnings is
 to give a
 standard error number. This is a simple improvement, but it makes
 simpler to
 write explanation pages for the errors. The C# compiler and other
 compilers have
 them.

I used to do that, but again, it was a completely unwanted feature, and I abandoned it. It's simple enough to grep for the error message text, and I myself prefer to do the grep method. What makes me grumpy is people only want these things when some other compiler does it, sort of a bandwagon thing.

Grepping the text can be a problem if the output has been localised. I write GUI wrappers for programs such as Mercurial/Git/Quilt and have been forced to use the (equivalent) of the grep to obtain details of the failure of a Mercurial/Git/Quilt command in order to add niceties as offering a "refresh and retry" option if (say) a quilt push fails because the repository needs to be refreshed. The reason that I have to do this is that the error value returned by the commands isn't very useful (usually just 0 for success and -1 for failure). The downside of this is that if my user has a locale that uses a language other than English my greps fail and the user misses out on the added niceties that would otherwise have been available. The type of error return value I would have liked to have seen implemented in programs (I asked for changes but none were forthcoming) I write wrappers for would be a flag based system (I think that you can only count on 8 bits in the return value) to indicate the major characteristics of the failure. Peter
Sep 24 2013
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 9/24/13 1:29 PM, Walter Bright wrote:
 On 9/23/2013 11:38 AM, bearophile wrote:
 2) The other improvement I'd like for D error messages and warnings is to give
a
 standard error number. This is a simple improvement, but it makes simpler to
 write explanation pages for the errors. The C# compiler and other compilers
have
 them.

I used to do that, but again, it was a completely unwanted feature, and I abandoned it. It's simple enough to grep for the error message text, and I myself prefer to do the grep method. What makes me grumpy is people only want these things when some other compiler does it, sort of a bandwagon thing.

I think it's less a bandwagon thing and more a the bar has been raised thing. 30 years ago ide's were essentially unheard of. Tooling around compilers and languages was almost non-existent. The picture and expectations about user friendliness today are drastically different. The past is not a perfect predictor of the present.
Sep 24 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 24 September 2013 at 23:19:24 UTC, Walter Bright 
wrote:
 On 9/24/2013 3:27 PM, Timon Gehr wrote:
 You have used lack of comments as an indicator of quality in 
 the past.

Lack of comments does mean something. BTW, as I wrote in another post here, I've prompted people about it, due to the silence. Read there what their response was.

You may underestimate power of marketing in IT world :) It does not matter how useful feature was on its own - clang guys has convinced the crowd it is useful so now it is useful. Its actual merit is irrelevant unless you want to invest into "counter-propaganda".
Sep 24 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I don't believe it, based on plenty of experience with "grass 
 is greener" compiler ephemera.

Thank you for your answers Walter. (In this thread we are discussing three possible improvements for error messages, but of the three the only one I have asked in Bugzilla is Issue 5004, because it's the only one I am kinda sure it's an improvement for me). Bye, bearophile
Sep 24 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 24, 2013, at 1:26 PM, Walter Bright <newshound2 digitalmars.com> =
wrote:

 On 9/23/2013 10:33 AM, Iain Buclaw wrote:
 GCC has a carat too now.

DMC has had a carat for 30 years now. =20 int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' =20 Nobody ever gave a damn about that feature, i.e. not one single person =

I'm sure you know this, but no one ever comments on stuff they like. = Only stuff they don't.=
Sep 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 24 September 2013 at 23:17:57 UTC, Walter Bright 
wrote:
 On 9/24/2013 2:56 PM, Andrej Mitrovic wrote:
 It seems nobody comments on almost anything DMC-related 
 anyway. Isn't
 this the DMC newsgroup: http://forum.dlang.org/group/c++ ? If 
 it is,
 there's hardly a single post per month..

You overlook that it's a very old compiler - 30 years. In its day it had maybe 100,000 users. People do still use it today, to compile dmd for Win32 for example, and nobody has yet EVER commented on that feature, unless I prompted them, when I have pointed it out many times over the decades, and the response is always: SO WHAT WHO CARES etc. So please forgive my grumpiness about if clang implements it, suddenly it's the greatest, most useful feature ever.

It doesn't seem that surprising to me. If you want a compiler that is fast, you use DMC, if you want a compiler that will do coffee, you use GCC or clang recently. I do think the user base you judge on is biased.
Sep 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Bright 
wrote:
 On 9/24/2013 5:39 PM, deadalnix wrote:
 It doesn't seem that surprising to me. If you want a compiler 
 that is fast, you
 use DMC, if you want a compiler that will do coffee, you use 
 GCC or clang recently.
 I do think the user base you judge on is biased.

I'm sorry, I don't believe the dmc user base secretly loved that feature. Which is why I dropped it from dmd, despite having spent significant time making it work nice in dmc.

That is the exact opposite. People that like feature rich compiler already use another compiler. People that like minimal tooling and speed uses DMC.
Sep 24 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
Walter, I'm sorry to hear your frustration on this issue of the 
error caret, and the lack of recognition you got for your dmc 
implementation of that concept.

For what it's worth the following is my opinion:

- I think I first met an error caret in the javac compiler, 
around 2000. I found it very nice and useful. My positive 
experience was not preceded by any "marketing" of that feature, 
so I think we can conclude that my enjoyment was genuine.

- When clang added nice error diagnostics in general (compared to 
GCC at the time) and the caret in particular that helped shape my 
perception of that compiler in a positive light, whatever the 
actual technical merits of that compiler may be.

- In general I think dmd is quite a good compiler but I regularly 
mumble to myself "hmm, the compiler could have provided better 
diagnostics for this error I committed". I can start compiling a 
list of those errors with less than great error messages, if 
that's useful.

- Based on my experience with javac and clang, providing a caret 
(and ranges around the offending expressions, as in clang) is 
very useful *to me*, and I would be very pleased to see them on 
the D compilers, even if that information was not present in the 
debugger, so as not to regress compiler performance.
Sep 24 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Tuesday, 24 September 2013 at 23:11:24 UTC, Walter Bright 
wrote:
 On 9/24/2013 2:23 PM, David Nadlinger wrote:
 On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright 
 wrote:
 On 9/23/2013 10:33 AM, Iain Buclaw wrote:
 GCC has a carat too now.

DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user.

Maybe that's because "not one single person" actually uses DMC? ;)

yes, I've had a fantasy business for the last 30 years.

DMC? A compiler which produces obsolete object format which is not produced by anyone else and which is a reason of why dmd users experience problems in windows platform?
Sep 24 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Wednesday, 25 September 2013 at 06:57:52 UTC, Maxim Fomin 
wrote:
 On Tuesday, 24 September 2013 at 23:11:24 UTC, Walter Bright 
 wrote:
 On 9/24/2013 2:23 PM, David Nadlinger wrote:
 On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright 
 wrote:
 On 9/23/2013 10:33 AM, Iain Buclaw wrote:



not produced by anyone else and which is a reason of why dmd users experience problems in windows platform?

All that might be true, however I feel like is not fair to criticize DMC in such harsh words. First, because one should judge a compiler wrt its pairs (of the same age). Second, because I think it was quite a breakthrough at its time, and history should be respected, even if becomes obsolete (what does not?). One should not criticize IBM PC for being obsolete *today*. Third, because it is real (and hard) work behind that DMC compiler and it is available for free. Maybe not the latest, nor the greatest, but is a contribution to the software world and this should be appreciated. Besides, all work should be respected and appreciated. It is hard to work, and it is even harder to work hard. Fourth, because it attracted C/C++ fans to D. It is my case: I crawled the Internet back then in the search for a free C/C++ compiler, being a bit disappointed by Borland's (I think 5.5 was "freed") suite, specifically... its error messages. I gave DMC a try, then got caught into the D thing... Fifth, because as obsolete as DMC might be, it provided Walter a lot of experience and this lead him to D in the first place. Yes, me too I would prefer main focus to shift on GDC or LDC but, at the end of the day, I must acknowledge the fact that if DMC and Walter did not exist, with all shortcomings of DMC, we'd have today no GDC, nor LDC to complain about those not being given priority. Sixth, because from time to time we should express not only harsh truths, but kindness. Kindness, too, is true. We are eager to be harsh with others, but still we hope others to be kind with us.
Sep 25 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 24 September 2013 22:23, David Nadlinger <code klickverbot.at> wrote:
 On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright wrote:
 On 9/23/2013 10:33 AM, Iain Buclaw wrote:
 GCC has a carat too now.

DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user.

Maybe that's because "not one single person" actually uses DMC? ;)

That's a bit below the belt for you David. ;-) Saying that, I don't use dmc... -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 25 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Wednesday, 25 September 2013 at 07:39:32 UTC, eles wrote:
 DMC? A compiler which produces obsolete object format which is 
 not produced by anyone else and which is a reason of why dmd 
 users experience problems in windows platform?

All that might be true, however I feel like is not fair to criticize DMC in such harsh words. First, because one should judge a compiler wrt its pairs (of the same age).

I am not judging DMC compiler. I am essentially judging the author who decided not to invest time and sources into supporting proper object format for dmd on win32.
 Second, because I think it was quite a breakthrough at its 
 time, and history should be respected, even if becomes obsolete 
 (what does not?). One should not criticize IBM PC for being 
 obsolete *today*.

Where and which history did I disrespected?
 Third, because it is real (and hard) work behind that DMC 
 compiler and it is available for free. Maybe not the latest, 
 nor the greatest, but is a contribution to the software world 
 and this should be appreciated. Besides, all work should be 
 respected and appreciated. It is hard to work, and it is even 
 harder to work hard.

Who says that writing a compiler is a picnic? By the way, if you decided to raise the issue, I can say that someone doesn't need to move stuff from one backend file to another without obvious end-user value when there are outcrying problems with D implementation.
 Fourth, because it attracted C/C++ fans to D. It is my case: I 
 crawled the Internet back then in the search for a free C/C++ 
 compiler, being a bit disappointed by Borland's (I think 5.5 
 was "freed") suite, specifically... its error messages. I gave 
 DMC a try, then got caught into the D thing...

Did DMC attracted you to D? That's fine but I doubt it attracted at least 4 more persons. In my opinion most were attracted by completely different reasons.
 Fifth, because as obsolete as DMC might be, it provided Walter 
 a lot of experience and this lead him to D in the first place. 
 Yes, me too I would prefer main focus to shift on GDC or LDC 
 but, at the end of the day, I must acknowledge the fact that if 
 DMC and Walter did not exist, with all shortcomings of DMC, 
 we'd have today no GDC, nor LDC to complain about those not 
 being given priority.

What does this have to do with object format?
 Sixth, because from time to time we should express not only 
 harsh truths, but kindness. Kindness, too, is true. We are 
 eager to be harsh with others, but still we hope others to be 
 kind with us.

What does this have to do with object format?
Sep 25 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/25/13, Jacob Carlborg <doob me.com> wrote:
 People are asking for it now.

Yeah but it's not anonymous people on Reddit asking for it, it's just experienced D developers. It doesn't count.
Sep 25 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--001a11c2be66b1602e04e732fb50
Content-Type: text/plain; charset=ISO-8859-1

On Sep 25, 2013 11:16 AM, "Andrej Mitrovic" <andrej.mitrovich gmail.com>
wrote:
 On 9/25/13, Jacob Carlborg <doob me.com> wrote:
 People are asking for it now.

Yeah but it's not anonymous people on Reddit asking for it, it's just experienced D developers. It doesn't count.

Manu is not asking for it either. :o) *hugs Manu* Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --001a11c2be66b1602e04e732fb50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Sep 25, 2013 11:16 AM, &quot;Andrej Mitrovic&quot; &lt;<a href=3D"mailto= :andrej.mitrovich gmail.com">andrej.mitrovich gmail.com</a>&gt; wrote:<br> &gt;<br> &gt; On 9/25/13, Jacob Carlborg &lt;<a href=3D"mailto:doob me.com">doob me.= com</a>&gt; wrote:<br> &gt; &gt; People are asking for it now.<br> &gt;<br> &gt; Yeah but it&#39;s not anonymous people on Reddit asking for it, it&#39= ;s just<br> &gt; experienced D developers. It doesn&#39;t count.</p> <p>Manu is not asking for it either.=A0 :o)</p> <p>*hugs Manu*<br></p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --001a11c2be66b1602e04e732fb50--
Sep 25 2013
prev sibling next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
21.09.2013 21:41, Zhouxuan пишет:
 http://d.puremagic.com/issues/show_bug.cgi?id=11086
 http://d.puremagic.com/issues/show_bug.cgi?id=11010
 http://d.puremagic.com/issues/show_bug.cgi?id=10970

 I've found and reported these bugs after about merely 100 LOCs written
 down.
 Should I continue?

 Despite these tiny issues, I see a lot of people complain about
 container, GC etc, but I can't found any offical reply, also no roadmap
 at all.

A year or two ago it was a lot of wrong-code bugs with lambdas and nested functions making e.g. `std.algorithm` almost unusable. But it's only the beginning. OPTLINK bug causing random linking failures thus making the whole language unusable for real projects was fixed only about half a year ago. And all this time I liked D except "the language is stable" words. And when half a year ago D become fully usable I become happy. For me "enough stability" is an ability to grab my copy of tool-chain and work with it without random failures. Since then I had not any real problems with breaking changes or regressions. Generally regressions are fixed quickly and as for me the more breaking changes the better language we get. ) -- Денис В. Шеломовский Denis V. Shelomovskij
Sep 25 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 25 September 2013 at 03:10:20 UTC, Walter Bright 
wrote:
 And, dmd users are often dmc users.

Are they, still? I can't speak for everyone, but I know I've never used it. I wish I had had it for precisely the feature in question when I was first learning C, even though it would have spoiled me on other compilers until...2013, apparently. :/
 Since dmd never had it, and dmc did, wouldn't anyone have 
 suggested "hey, I like this dmc feature, why not put it in 
 dmd?" But nope.

In the few compilers I've used that had it, I've never begrudged its existence; it's usually been helpful, and never harmful. You could say I like it because it offers proper visualisation of the data. I didn't realise it was moving from "rare, nice perk" to "in-demand standard feature" until this thread. -Wyatt
Sep 25 2013
prev sibling next sibling parent "Jason King" <jhking airmail.net> writes:
 Of course, we can cheat and use a byte to store the column 
 number, as after all, nobody has more than 256 columns.

 Then you get a bug report where someone does. So raise it to an 
 unsigned short, then, sigh, you get another bug report where 
 someone's entire source file is on one line, and on it goes.

I realize putting "maximum line length 32767 characters" is an arbitrary limit, but if you add that to the language spec and make your column counter an unsigned short you're good forever. This might break some existing code but I can't imagine it would be much. There are advantages to owning the language spec!
Sep 25 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 24, 2013, at 8:45 PM, "deadalnix" <deadalnix gmail.com> wrote:
=20
 On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Bright wrote:
 On 9/24/2013 5:39 PM, deadalnix wrote:
 It doesn't seem that surprising to me. If you want a compiler that is fa=



 use DMC, if you want a compiler that will do coffee, you use GCC or clan=



 I do think the user base you judge on is biased.

I'm sorry, I don't believe the dmc user base secretly loved that feature.=


aking it work nice in dmc.
=20
 That is the exact opposite. People that like feature rich compiler already=

I don't know. I liked DMC specifically because of the nifty features. I used= VC++ for the debugging environment. But then I never worked on a Windows pr= oject where compile time was a problem. The really big stuff (ie. millions o= f LOC) has always been on some variant of Unix.=20=
Sep 25 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 24, 2013, at 11:14 PM, Walter Bright <newshound2 digitalmars.com> =
wrote:

 On 9/24/2013 10:54 PM, "Lu=EDs Marques" <luis luismarques.eu>" wrote:
=20
 - Based on my experience with javac and clang, providing a caret (and =


 around the offending expressions, as in clang) is very useful *to =


 would be very pleased to see them on the D compilers, even if that =


 was not present in the debugger, so as not to regress compiler =


=20
 Thank you for a very reasonable reply.

Yeah, I've never cared about having this information in the debugger. = Only at compile time.=
Sep 25 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 25, 2013, at 5:43 AM, Wyatt <wyatt.epp gmail.com> wrote:

 On Wednesday, 25 September 2013 at 03:10:20 UTC, Walter Bright wrote:
=20
 And, dmd users are often dmc users.

Are they, still? I can't speak for everyone, but I know I've never =

I was first learning C, even though it would have spoiled me on other = compilers until...2013, apparently. :/ If you're mixing D and C/C++ code, it certainly seems like the easiest = approach. Does DMC integrate with VisualStudio as well as DMD? That = would be the only issue for me if I still developed on Windows.=
Sep 25 2013
prev sibling next sibling parent Arjan <arjan ask.me> writes:
On Wed, 25 Sep 2013 17:53:41 +0200, Sean Kelly <sean invisibleduck.org>  
wrote:

 On Sep 24, 2013, at 8:45 PM, "deadalnix" <deadalnix gmail.com> wrote:
 On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Bright wrote:
 On 9/24/2013 5:39 PM, deadalnix wrote:
 It doesn't seem that surprising to me. If you want a compiler that is  
 fast, you
 use DMC, if you want a compiler that will do coffee, you use GCC or  
 clang recently.
 I do think the user base you judge on is biased.

I'm sorry, I don't believe the dmc user base secretly loved that feature. Which is why I dropped it from dmd, despite having spent significant time making it work nice in dmc.

That is the exact opposite. People that like feature rich compiler already use another compiler. People that like minimal tooling and speed uses DMC.

I don't know. I liked DMC specifically because of the nifty features. I used VC++ for the debugging environment. But then I never worked on a Windows project where compile time was a problem. The really big stuff (ie. millions of LOC) has always been on some variant of Unix.

Well we extensively used Symantec C/C++ and later DMC on various large projects om Windows. And I did appreciate the error caret in DMC at the time. I really loved the compiler and IDDE back then. We also used compilers from other vendors (Borland Watcom IBM KAI MS). The most remarkable memories are of course the compile speed but also (for a long time) the performance of the generated code! An other thing we really really really loved was the speed in response on reporting compiler bugs! Almost every time within 2 or 3 days we received a 'fixed' compiler in our inbox from Walter! (Thank You Walter!) Also often times DMC captured programming bugs during compilation not found by the Borland Watcom or MS compilers. It wasn't until 2004/2005 before I switched to VS2003/vS2005 because DMC was getting to much behind and the MS compiler had improved a lot. Arjan
Sep 25 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--001a1134487436f5ea04e74d1c2d
Content-Type: text/plain; charset=ISO-8859-1

On Sep 25, 2013 8:55 PM, "Arjan" <arjan ask.me> wrote:
 On Wed, 25 Sep 2013 17:53:41 +0200, Sean Kelly <sean invisibleduck.org>

 On Sep 24, 2013, at 8:45 PM, "deadalnix" <deadalnix gmail.com> wrote:
 On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Bright wrote:
 On 9/24/2013 5:39 PM, deadalnix wrote:
 It doesn't seem that surprising to me. If you want a compiler that is





 use DMC, if you want a compiler that will do coffee, you use GCC or





 I do think the user base you judge on is biased.

I'm sorry, I don't believe the dmc user base secretly loved that




significant time making it work nice in dmc.
 That is the exact opposite. People that like feature rich compiler



uses DMC.
 I don't know. I liked DMC specifically because of the nifty features. I


Windows project where compile time was a problem. The really big stuff (ie. millions of LOC) has always been on some variant of Unix.
 Well we extensively used Symantec C/C++ and later DMC on various large

time. I really loved the compiler and IDDE back then. We also used compilers from other vendors (Borland Watcom IBM KAI MS). The most remarkable memories are of course the compile speed but also (for a long time) the performance of the generated code!
 An other thing we really really really loved was the speed in response on

'fixed' compiler in our inbox from Walter! (Thank You Walter!)
 Also often times DMC captured programming bugs during compilation not

 It wasn't until 2004/2005 before I switched to VS2003/vS2005 because DMC

 Arjan

I guess moral of the story is: People don't compliment what they take for granted - only complain when it is missing. :) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --001a1134487436f5ea04e74d1c2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Sep 25, 2013 8:55 PM, &quot;Arjan&quot; &lt;<a href=3D"mailto:arjan ask.= me">arjan ask.me</a>&gt; wrote:<br> &gt;<br> &gt; On Wed, 25 Sep 2013 17:53:41 +0200, Sean Kelly &lt;<a href=3D"mailto:s= ean invisibleduck.org">sean invisibleduck.org</a>&gt; wrote:<br> &gt;<br> &gt;&gt; On Sep 24, 2013, at 8:45 PM, &quot;deadalnix&quot; &lt;<a href=3D"= mailto:deadalnix gmail.com">deadalnix gmail.com</a>&gt; wrote:<br> &gt;&gt;&gt;<br> &gt;&gt;&gt;<br> &gt;&gt;&gt;&gt; On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Br= ight wrote:<br> &gt;&gt;&gt;&gt;&gt;<br> &gt;&gt;&gt;&gt;&gt; On 9/24/2013 5:39 PM, deadalnix wrote:<br> &gt;&gt;&gt;&gt;&gt; It doesn&#39;t seem that surprising to me. If you want= a compiler that is fast, you<br> &gt;&gt;&gt;&gt;&gt; use DMC, if you want a compiler that will do coffee, y= ou use GCC or clang recently.<br> &gt;&gt;&gt;&gt;&gt; I do think the user base you judge on is biased.<br> &gt;&gt;&gt;&gt;<br> &gt;&gt;&gt;&gt;<br> &gt;&gt;&gt;&gt; I&#39;m sorry, I don&#39;t believe the dmc user base secre= tly loved that feature. Which is why I dropped it from dmd, despite having = spent significant time making it work nice in dmc.<br> &gt;&gt;&gt;<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; That is the exact opposite. People that like feature rich comp= iler already use another compiler. People that like minimal tooling and spe= ed uses DMC.<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; I don&#39;t know. I liked DMC specifically because of the nifty fe= atures. I used VC++ for the debugging environment. But then I never worked = on a Windows project where compile time was a problem. The really big stuff= (ie. millions of LOC) has always been on some variant of Unix.<br> &gt;<br> &gt;<br> &gt; Well we extensively used Symantec C/C++ and later DMC on various large= projects om Windows. And I did appreciate the error caret in DMC at the ti= me. I really loved the compiler and IDDE back then. We also used compilers = from other vendors (Borland Watcom IBM KAI MS). The most remarkable memorie= s are of course the compile speed but also (for a long time) the performanc= e of the generated code!<br> &gt; An other thing we really really really loved was the speed in response= on reporting compiler bugs! Almost every time within 2 or 3 days we receiv= ed a &#39;fixed&#39; compiler in our inbox from Walter! (Thank You Walter!)= <br> &gt; Also often times DMC captured programming bugs during compilation not = found by the Borland Watcom or MS compilers.<br> &gt; It wasn&#39;t until 2004/2005 before I switched to VS2003/vS2005 becau= se DMC was getting to much behind and the MS compiler had improved a lot.<b= r> &gt;<br> &gt; Arjan</p> <p>I guess moral of the story is: People don&#39;t compliment what they tak= e for granted - only complain when it is missing.=A0 :)</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --001a1134487436f5ea04e74d1c2d--
Sep 26 2013