On Monday, 5 September 2016 at 15:55:16 UTC, Dominikus Dittes
Scherkl wrote:
On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright
wrote:
On 9/4/2016 10:56 AM, David Nadlinger wrote:
The bug report I need is the assert location, and a test case
that causes it. Users do not need to supply
On Tuesday, 6 September 2016 at 05:46:51 UTC, Vladimir Panteleev
wrote:
On Tuesday, 6 September 2016 at 05:43:55 UTC, deadalnix wrote:
On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright
wrote:
I do that often. Binary search quickly reduces even the
biggest code size. Manually, or using
On Tuesday, 6 September 2016 at 05:43:55 UTC, deadalnix wrote:
On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright
wrote:
I do that often. Binary search quickly reduces even the
biggest code size. Manually, or using dustmite which works
amazingly well.
That is not true. I had
On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright wrote:
On 9/4/2016 10:56 AM, David Nadlinger wrote:
This is short-sighted, for the reason I pointed out in my
earlier post. How
would you go about reporting an ICE for a 100k LOC test case
without any idea
about where to start
On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright
wrote:
Except that asserts are checking for compiler bugs, not
diagnostics on user code. I don't expect users to debug the
compiler - if they get an assert they should file a bug report
to bugzilla and let us debug the compiler and
On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright wrote:
On 9/4/2016 10:56 AM, David Nadlinger wrote:
The bug report I need is the assert location, and a test case
that causes it. Users do not need to supply any other
information.
So, if we assume the user cannot debug if he hit an
David wrote
In fact, that's precisely what happened to the guys at Weka
before, although I'm certain they are not alone with this. They
encountered ICEs when updating the compiler version with no way
to narrow it down. Of course, *I* could just build DMD with
symbols and have a look at what
On 9/4/2016 10:56 AM, David Nadlinger wrote:
This is short-sighted, for the reason I pointed out in my earlier post. How
would you go about reporting an ICE for a 100k LOC test case without any idea
about where to start looking?
I do that often. Binary search quickly reduces even the biggest
On Sunday, 4 September 2016 at 17:56:08 UTC, David Nadlinger
wrote:
On Saturday, 3 September 2016 at 22:39:22 UTC, Walter Bright
wrote:
Because it's useless to anyone but the compiler devs, and it
adds cruft to the compiler. And even worse than useless, it
confuses the user into thinking it is
On Saturday, 3 September 2016 at 22:39:22 UTC, Walter Bright
wrote:
Because it's useless to anyone but the compiler devs, and it
adds cruft to the compiler. And even worse than useless, it
confuses the user into thinking it is a meaningful message.
This is short-sighted, for the reason I
On Sunday, 4 September 2016 at 10:33:44 UTC, Walter Bright wrote:
As I mentioned before, assert failures are usually the result
of the last edit one did. The problem is already narrowed down.
I got the error at the start of the thread because I added a
variable to a class. The class is having
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright wrote:
If you're willing to look at the file/line of where the assert
tripped, I don't see how a message would save any time at all.
The level builders at Remedy are going to be using D as a
scripting language. If they get an error
On 05/09/2016 2:19 AM, Shachar Shemesh wrote:
I understand you don't see the need, but I'd like you to consider the
possibility that having more people able to hack the front end is also
something that would help to give D a boost. If the cost of becoming a
compiler developer was lower, wouldn't
On Sunday, 4 September 2016 at 00:09:50 UTC, Stefan Koch wrote:
Perhaps the best error message would be "Please post this as a
bug to bugzilla."
I'd say that's in addition to getting rid of assert(0), not
instead of.
On Saturday, 3 September 2016 at 22:53:25 UTC, Walter Bright
wrote:
Adding more text to the assert message is not helpful to end
users.
Really? I've highlighted several cases just in this one function
in glue.c that would have saved me hours of time.
On 04/09/16 01:39, Walter Bright wrote:
On 9/3/2016 6:14 AM, Jacob Carlborg wrote:
What kind of issue due you see with trying to print some form of
information
when an assertion fails?
Because it's useless to anyone but the compiler devs, and it adds cruft
to the compiler. And even worse than
On Sunday, 4 September 2016 at 10:33:44 UTC, Walter Bright wrote:
On 9/4/2016 2:17 AM, John Colvin wrote:
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright
wrote:
On 9/3/2016 7:35 PM, John Colvin wrote:
In my experience getting a clue as to what is was the
compiler didn't like is
On Sunday, 4 September 2016 at 10:46:25 UTC, develop32 wrote:
Certainly just stating that an assert was triggered in this and
this line of the backend is not enough?
Often it is actually enough because compiler developer can check
last changes to related code and propose simple checks to nail
On Sunday, 4 September 2016 at 10:33:44 UTC, Walter Bright wrote:
As I mentioned before, assert failures are usually the result
of the last edit one did. The problem is already narrowed down.
That's just not true in my case. Most of the asserts I triggered
were after updating to a newer
On 9/4/2016 2:17 AM, John Colvin wrote:
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright wrote:
On 9/3/2016 7:35 PM, John Colvin wrote:
In my experience getting a clue as to what is was the compiler didn't like is
very useful. Often the only way I can find a workaround is by locating
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright wrote:
On 9/3/2016 7:35 PM, John Colvin wrote:
In my experience getting a clue as to what is was the compiler
didn't like is
very useful. Often the only way I can find a workaround is by
locating the
assert in the compiler source and
On 9/3/2016 7:35 PM, John Colvin wrote:
In my experience getting a clue as to what is was the compiler didn't like is
very useful. Often the only way I can find a workaround is by locating the
assert in the compiler source and working out what it might possibly be to do
with, then making
On Saturday, 3 September 2016 at 22:48:27 UTC, Walter Bright
wrote:
On 9/3/2016 6:20 AM, Adam D. Ruppe wrote:
On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright
wrote:
Except that asserts are checking for compiler bugs, not
diagnostics on user code.
Except that in the real world,
On 9/3/2016 5:09 PM, Stefan Koch wrote:
Perhaps the best error message would be "Please post this as a bug to bugzilla."
That's fine with me, and Dicebot made a PR to do it.
On Saturday, 3 September 2016 at 22:53:25 UTC, Walter Bright
wrote:
On 9/3/2016 3:05 PM, Ethan Watson wrote:
In the cases I've been bringing up here, it's all been user
code that's been the
problem *anyway*. Regardless of if the compiler author was
expecting code to get
to that point or not,
On 9/3/2016 3:05 PM, Ethan Watson wrote:
In the cases I've been bringing up here, it's all been user code that's been the
problem *anyway*. Regardless of if the compiler author was expecting code to get
to that point or not, erroring out with zero information is a bad user
experience.
Nobody
On 9/3/2016 6:20 AM, Adam D. Ruppe wrote:
On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright wrote:
Except that asserts are checking for compiler bugs, not diagnostics on user
code.
Except that in the real world, it is an irrelevant distinction because you have
stuff to do and
On 9/3/2016 6:14 AM, Jacob Carlborg wrote:
What kind of issue due you see with trying to print some form of information
when an assertion fails?
Because it's useless to anyone but the compiler devs, and it adds cruft to the
compiler. And even worse than useless, it confuses the user into
On Saturday, 3 September 2016 at 13:20:37 UTC, Adam D. Ruppe
wrote:
Except that in the real world, it is an irrelevant distinction
because you have stuff to do and can't afford to wait on the
compiler team to actually fix the bug.
If nothing else, you'd like to know where it is so you can
On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright
wrote:
Except that asserts are checking for compiler bugs, not
diagnostics on user code.
Except that in the real world, it is an irrelevant distinction
because you have stuff to do and can't afford to wait on the
compiler team to
On 2016-09-03 14:12, Walter Bright wrote:
Except that asserts are checking for compiler bugs, not diagnostics on
user code. I don't expect users to debug the compiler - if they get an
assert they should file a bug report to bugzilla and let us debug the
compiler and fix it.
What kind of issue
On 9/3/2016 3:57 AM, Ethan Watson wrote:
Browsing through that function, I can also see another assert that doesn't let
you use vector types unless you're running a 64-bit build or are on OSX. It
doesn't tell me that through an error message. I had to look at the source code
to work it out.
On Friday, 2 September 2016 at 21:52:57 UTC, Walter Bright wrote:
I understand your concern, and that's why we put a priority on
fixing asserts that are submitted to bugzilla. But without a
bug report, we are completely dead in the water in fixing it.
It is supposed to never happen, that is
On Friday, 2 September 2016 at 22:12:20 UTC, Walter Bright wrote:
Compiling with -v will usually show how far the compiler got.
It's curious that this topic should come up now – just a couple
of days ago, I thought about adding better user reporting for LDC
ICEs.
What I was planning to do
On Fri, Sep 02, 2016 at 02:52:57PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> I understand your concern, and that's why we put a priority on fixing
> asserts that are submitted to bugzilla. But without a bug report, we
> are completely dead in the water in fixing it. It is supposed to
On 9/2/2016 2:54 PM, Chris Wright wrote:
The second and third would be greatly benefitted by the compiler attempting to
tell us where the problem was encountered. For instance, if the assert was
triggered while trying to generate code for function
dmud.eventqueue.EventQueue!(Fiber).scheduleNear,
On Friday, 2 September 2016 at 21:16:02 UTC, Walter Bright wrote:
assert()s are there to check that impossible situations in the
compiler don't actually happen. They are not for diagnosing
errors in user code.
There are three things that will ideally happen when someone sees
an assert:
*
On 9/2/2016 2:25 PM, Ethan Watson wrote:
On Friday, 2 September 2016 at 21:16:02 UTC, Walter Bright wrote:
assert()s are there to check that impossible situations in the compiler don't
actually happen. They are not for diagnosing errors in user code.
If a user sees an assert, it is a compiler
On Friday, 2 September 2016 at 21:16:02 UTC, Walter Bright wrote:
assert()s are there to check that impossible situations in the
compiler don't actually happen. They are not for diagnosing
errors in user code.
If a user sees an assert, it is a compiler bug and hopefully
he'll submit a bug
On 9/2/2016 7:26 AM, Ethan Watson wrote:
That's 830 possible places where the compiler will give the user virtually no
help to track down what (if anything) they did wrong.
assert()s are there to check that impossible situations in the compiler don't
actually happen. They are not for
On Fri, Sep 02, 2016 at 08:43:30PM +0300, Dicebot via Digitalmars-d wrote:
> On 09/02/2016 06:45 PM, Wyatt wrote:
> > On the other, though, considering he's been using DMD for years and
> > didn't know that, I think there's a cogent argument for improving
> > even ICE messages. At the least, have
On Friday, 2 September 2016 at 14:26:37 UTC, Ethan Watson wrote:
Can we have a serious discussion in here about the quality of
DMD errors?
I've been alternately a dog chasing its own tail, and a dog
barking at a fire hydrant, chasing down errors deep in
templated and mixin code over the last
On 09/02/2016 06:45 PM, Wyatt wrote:
> On the other, though, considering he's been using DMD for years and
> didn't know that, I think there's a cogent argument for improving even
> ICE messages. At the least, have them print "Internal Compiler Error".
Great idea, I hacked a quick implementation
On Friday, 2 September 2016 at 15:12:48 UTC, Steven Schveighoffer
wrote:
This is an internal compiler error. It's not a standard way of
reporting errors in D code. It means the internal state of the
compiler is messed. Not much the compiler can do except crash.
On one hand, it's encouraging
On Friday, 2 September 2016 at 14:26:37 UTC, Ethan Watson wrote:
But compared to MSVC, I've found the error reporting of DMD to
be severely lacking. In most cases with MSVC, I have an error
code that I can google for which is (sometimes) thoroughly
documented.
You're not really comparing DMD
On 9/2/16 10:26 AM, Ethan Watson wrote:
Can we have a serious discussion in here about the quality of DMD errors?
I've been alternately a dog chasing its own tail, and a dog barking at a
fire hydrant, chasing down errors deep in templated and mixin code over
the last day. This has resulted
Can we have a serious discussion in here about the quality of DMD
errors?
I've been alternately a dog chasing its own tail, and a dog
barking at a fire hydrant, chasing down errors deep in templated
and mixin code over the last day. This has resulted in manually
reducing templates and mixins
47 matches
Mail list logo
