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 "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
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 reply "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
parent reply 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
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:








 The funny thing is that this was already supported since a few 
 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 reply 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


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




here

 it encountered (estimated) the error?


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


ror. No column number.

=20

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




n gcc),

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




l

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




ould

 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=




sages

 provided by gcc and clang.


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


emory consumption and some compile speed, since it has to be tracked in ever=
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
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 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=






f

 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=






f

 only marginal utility and I dropped it.


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




o

 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 :-)=


 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 f=
or tabs & Unicode).

=20
 Of course, we can cheat and use a byte to store the column number, as afte=


r all, nobody has more than 256 columns.

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


hort, then, sigh, you get another bug report where someone's entire source f=
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
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 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
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
next sibling 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 reply 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 =




outright is

 shortsighted in my opinion.


=20
 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.  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
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 parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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>


wrote:

 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.

 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.

GCC has a carat too now.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 23 2013
next sibling parent reply "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 


Bye,
bearophile
Sep 23 2013
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 reply 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
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
next sibling parent reply 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
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 parent reply "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
parent reply 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
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 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

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
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

 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 parent reply 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

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
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 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 "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
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 reply 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
parent reply "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
parent reply "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:






 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).

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
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 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 reply 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
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 "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
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 "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
next sibling 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 =?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
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 reply 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 =




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.

=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
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 reply 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
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 parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Sep 25 2013
prev sibling parent reply 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=






st, you

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






g recently.

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


=20
 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 m=
aking it work nice in dmc.

=20
 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 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
parent reply 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
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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>


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


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';
Sep 26 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 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 "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
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 reply 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.


=20
 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 =


commented on it, including not a single D user.



I'm sure you know this, but no one ever comments on stuff they like.  =
Only stuff they don't.=
Sep 24 2013
parent reply 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
parent reply "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
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.


=20
 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. :/

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 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 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 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 "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
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 reply "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
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
next sibling parent reply "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
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 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 parent Kenji Hara <k.hara.pg gmail.com> writes:
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
Sep 21 2013
prev sibling next sibling parent reply "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
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 reply 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
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.


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);

	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 next sibling parent reply "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
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 "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 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 "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
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 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 reply "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
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 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 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 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:


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).


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 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 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 parent reply "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
next sibling parent reply "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
parent reply "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
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 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 "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
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
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 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
next sibling 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 "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 parent reply 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
parent reply "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
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 "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
next sibling parent reply "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
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 "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
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 reply "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
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 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 "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 reply 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
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 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 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 reply "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:


 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


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
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 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 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