www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Compiler does not give *any* useful level of error context!

reply "Matthew" <admin.hat stlsoft.dot.org> writes:
At the moment I'm getting

"..\..\std\dtl\functions\predicates.d(133): cannot implicitly convert int to
bit"

And that's it. It's spectacularly unhelpful stuff.

I'm trying to get a minimally compilable distr of DTL, and whatever small
changes I made late last night have now
escaped me, so I'm just trolling around in the dark with /+ +/. If this was
C++, I'd get some helpful additional context
and be on it in a flash. Truely, I can track and fix this kind of stuff in C++
in less than a minute. I've been trying
to track down this bleeder for the last 45 minutes!!!!

Using -v isn't exactly helpful:

"
parse     list_test
semantic  list_test
semantic2 list_test
semantic3 list_test
..\..\std\dtl\functions\predicates.d(133): cannot implicitly convert int to bit
"

Well thanks very much Einstein, I could have told myself that.

Please, please, please, PLEASE, can the compiler be amended to give rich
contextual information. I'm transgressing a
template's definition. Tell me in which instantiation this is happening! Tell
me where (file/line) this is happening! If
that's inside another template instantiation, tell me all about that! Repeat
for up to 10 levels!

I don't care if you give me too much info - that's what Perl/Python/Ruby was
invented for. But not enough information is
no longer tolerable: I cannot continue loosing such huge tracts of my time on
these pointless wild-goose chases.
Jul 30 2004
parent reply "Walter" <newshound digitalmars.com> writes:
Try breaking up line 133 into multiple lines.

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cef8jv$jk9$1 digitaldaemon.com...
 At the moment I'm getting

 "..\..\std\dtl\functions\predicates.d(133): cannot implicitly convert int

 And that's it. It's spectacularly unhelpful stuff.

 I'm trying to get a minimally compilable distr of DTL, and whatever small

 escaped me, so I'm just trolling around in the dark with /+ +/. If this

 and be on it in a flash. Truely, I can track and fix this kind of stuff in

 to track down this bleeder for the last 45 minutes!!!!

 Using -v isn't exactly helpful:

 "
 parse     list_test
 semantic  list_test
 semantic2 list_test
 semantic3 list_test
 ..\..\std\dtl\functions\predicates.d(133): cannot implicitly convert int

 "

 Well thanks very much Einstein, I could have told myself that.

 Please, please, please, PLEASE, can the compiler be amended to give rich

 template's definition. Tell me in which instantiation this is happening!

 that's inside another template instantiation, tell me all about that!

 I don't care if you give me too much info - that's what Perl/Python/Ruby

 no longer tolerable: I cannot continue loosing such huge tracts of my time


Jul 30 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
I'm assuming you're making a gag in an to attempt to difuse/dissipate my
obvious frustrations. (Didn't work, btw, but
playing football with the boys outside for 30 mins has at least taken the edge
off.)

Notwithstanding, I'll address your comment seriously.

Line 133 looks like, in context:

    template FunctionPredicate(F, A) { class FunctionPredicate
        : public Predicate!(A)
    {
    public:
        alias   FunctionPredicate   class_type;
    public:
        this(F f)
        {
            m_f = f;
        }
    public:
        bool opCall(argument_type v)
        {
            return m_f(v);        // !!!! Line 133 !!!!
        }
    private:
        F   m_f;
    }}


Splitting a line's not going to do much, is it?

Can you ignore the specifics of this case, and address my general point. I am
perfectly serious that my
recognition/diagnosis of bad-template-instantiation is usually measured in
seconds in C++, and almost always measured in
minutes in D. Surely you must concede that this is indicative of something
"wrong" with D? As I said below, I suggest
that it's the lack of contextual information in the compiler, though I must to
concede that my own unfamiliarity with
the language will play a part.

I would simplistically suggest that contextual information would trim the D:C++
"error grok" latency relationship from
its current 50-100:1 to about 5-10:1. That's pretty massive, and it might even
be better than that once I'm more
ensconced in the ways of D. Doubtless many others who are well practised in C++
might experience similar improvements.
Is this not something you would want for D? Would this not help reduce the
amount of time _you_ must spend in answering
ill-tempered semi-rants on the NG, or on boiling down code that others have
failed/faultered on?

I tell you, if "Try breaking up line 133 into multiple lines." is really your
serious response to my predicament, then I
can only be thankful that I shave my head with a 2mm setting, otherwise I'd be
about tearing my hair out now.

FWIW: I dreamt up the bulk of DTL's concept/design in a couple of days, and
wrote most of the code in two stints in
March (3 days) and two weeks ago (1.5 days), include anything that one might
reasonably term "debugging". All told
that's less than a week. I'd honestly estimate that I've spent about another
15-20 days over the last 4-5 months just
playing around trying to get the compiler to do what I want, or playing /++/
roulette; none of that time has been what
one might call design/coding/debugging/testing, just wasted time wandering
around a dark room with a bag on my head.

As I said to you the other day, the experiences I am having may (or may not) be
unique now, but they most certainly will
not be once D 1.0 is released. The TMP-world and all their bad-haired friend's
will be making a beeline for D armed with
arcane lore and recondite code. DTL will seem like child's play in comparison.
If D does not handle complex concepts, or
fail more gracefully/informatively, it'll be saddled with a bad name for
generics that may be *very* hard to shake.

Given the amount of time and effort I'm investing in D, I don't want that to
happen. I want D to kick arse in generics,
and I'd quite like DTL to be seen favourably. <g>

Can you give me a switch to flick to turn dmd.exe into a garrulous little
puppy? Please.





"Walter" <newshound digitalmars.com> wrote in message
news:cefc3j$ko1$1 digitaldaemon.com...
 Try breaking up line 133 into multiple lines.

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cef8jv$jk9$1 digitaldaemon.com...
 At the moment I'm getting

 "..\..\std\dtl\functions\predicates.d(133): cannot implicitly convert int

 And that's it. It's spectacularly unhelpful stuff.

 I'm trying to get a minimally compilable distr of DTL, and whatever small

 escaped me, so I'm just trolling around in the dark with /+ +/. If this

 and be on it in a flash. Truely, I can track and fix this kind of stuff in

 to track down this bleeder for the last 45 minutes!!!!

 Using -v isn't exactly helpful:

 "
 parse     list_test
 semantic  list_test
 semantic2 list_test
 semantic3 list_test
 ..\..\std\dtl\functions\predicates.d(133): cannot implicitly convert int

 "

 Well thanks very much Einstein, I could have told myself that.

 Please, please, please, PLEASE, can the compiler be amended to give rich

 template's definition. Tell me in which instantiation this is happening!

 that's inside another template instantiation, tell me all about that!

 I don't care if you give me too much info - that's what Perl/Python/Ruby

 no longer tolerable: I cannot continue loosing such huge tracts of my time



Jul 30 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cefeq2$lde$1 digitaldaemon.com...
 I'm assuming you're making a gag in an to attempt to difuse/dissipate my

 playing football with the boys outside for 30 mins has at least taken the

No, I was serious. Sometimes people fill up a line with stuff, and breaking it up can help.
 Notwithstanding, I'll address your comment seriously.

 Line 133 looks like, in context:

     template FunctionPredicate(F, A) { class FunctionPredicate
         : public Predicate!(A)
     {
     public:
         alias   FunctionPredicate   class_type;
     public:
         this(F f)
         {
             m_f = f;
         }
     public:
         bool opCall(argument_type v)
         {
             return m_f(v);        // !!!! Line 133 !!!!
         }
     private:
         F   m_f;
     }}


 Splitting a line's not going to do much, is it?

I would guess that the problem is that m_f() returns an int. Or perhaps v is an int, and m_f() takes a bit as an argument.
 Can you ignore the specifics of this case, and address my general point. I

 recognition/diagnosis of bad-template-instantiation is usually measured in

 minutes in D. Surely you must concede that this is indicative of something

 that it's the lack of contextual information in the compiler, though I

 the language will play a part.

 I would simplistically suggest that contextual information would trim the

 its current 50-100:1 to about 5-10:1. That's pretty massive, and it might

 ensconced in the ways of D. Doubtless many others who are well practised

 Is this not something you would want for D? Would this not help reduce the

 ill-tempered semi-rants on the NG, or on boiling down code that others

 I tell you, if "Try breaking up line 133 into multiple lines." is really

 can only be thankful that I shave my head with a 2mm setting, otherwise

 FWIW: I dreamt up the bulk of DTL's concept/design in a couple of days,

 March (3 days) and two weeks ago (1.5 days), include anything that one

 that's less than a week. I'd honestly estimate that I've spent about

 playing around trying to get the compiler to do what I want, or playing

 one might call design/coding/debugging/testing, just wasted time wandering

 As I said to you the other day, the experiences I am having may (or may

 not be once D 1.0 is released. The TMP-world and all their bad-haired

 arcane lore and recondite code. DTL will seem like child's play in

 fail more gracefully/informatively, it'll be saddled with a bad name for

 Given the amount of time and effort I'm investing in D, I don't want that

 and I'd quite like DTL to be seen favourably. <g>

 Can you give me a switch to flick to turn dmd.exe into a garrulous little

Good error messages are an art, they take time to develop. C++ has been working on trying to improve template error messages for over 10 years now, with some success, even though C++ is still *notorious* for very obtuse error messages. Error messages in DMD are slowly getting better. Also, don't underestimate the familiarity you might be with the particular C++ tool you are using. That can make a big difference in figuring out why a particular message is happening.
Jul 31 2004
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cefhan$ndo$2 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:cefeq2$lde$1 digitaldaemon.com...
 I'm assuming you're making a gag in an to attempt to difuse/dissipate my

 playing football with the boys outside for 30 mins has at least taken the

No, I was serious. Sometimes people fill up a line with stuff, and breaking it up can help.
 Notwithstanding, I'll address your comment seriously.

 Line 133 looks like, in context:

     template FunctionPredicate(F, A) { class FunctionPredicate
         : public Predicate!(A)
     {
     public:
         alias   FunctionPredicate   class_type;
     public:
         this(F f)
         {
             m_f = f;
         }
     public:
         bool opCall(argument_type v)
         {
             return m_f(v);        // !!!! Line 133 !!!!
         }
     private:
         F   m_f;
     }}


 Splitting a line's not going to do much, is it?

I would guess that the problem is that m_f() returns an int. Or perhaps v is an int, and m_f() takes a bit as an argument.
 Can you ignore the specifics of this case, and address my general point. I

 recognition/diagnosis of bad-template-instantiation is usually measured in

 minutes in D. Surely you must concede that this is indicative of something

 that it's the lack of contextual information in the compiler, though I

 the language will play a part.

 I would simplistically suggest that contextual information would trim the

 its current 50-100:1 to about 5-10:1. That's pretty massive, and it might

 ensconced in the ways of D. Doubtless many others who are well practised

 Is this not something you would want for D? Would this not help reduce the

 ill-tempered semi-rants on the NG, or on boiling down code that others

 I tell you, if "Try breaking up line 133 into multiple lines." is really

 can only be thankful that I shave my head with a 2mm setting, otherwise

 FWIW: I dreamt up the bulk of DTL's concept/design in a couple of days,

 March (3 days) and two weeks ago (1.5 days), include anything that one

 that's less than a week. I'd honestly estimate that I've spent about

 playing around trying to get the compiler to do what I want, or playing

 one might call design/coding/debugging/testing, just wasted time wandering

 As I said to you the other day, the experiences I am having may (or may

 not be once D 1.0 is released. The TMP-world and all their bad-haired

 arcane lore and recondite code. DTL will seem like child's play in

 fail more gracefully/informatively, it'll be saddled with a bad name for

 Given the amount of time and effort I'm investing in D, I don't want that

 and I'd quite like DTL to be seen favourably. <g>

 Can you give me a switch to flick to turn dmd.exe into a garrulous little

Good error messages are an art, they take time to develop. C++ has been working on trying to improve template error messages for over 10 years now, with some success, even though C++ is still *notorious* for very obtuse error messages. Error messages in DMD are slowly getting better.

I don't need good ones, I just need some clues. You already have the context somewhere in your state machines - just dump it out.
 Also, don't underestimate the familiarity you might be with the particular
 C++ tool you are using. That can make a big difference in figuring out why a
 particular message is happening.

Maybe, but I use more than 20 different C++ compilers, and can make sense of almost all of their output.
Jul 31 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter wrote:
 
 Good error messages are an art, they take time to develop. C++ has been
 working on trying to improve template error messages for over 10 years now,
 with some success, even though C++ is still *notorious* for very obtuse
 error messages. Error messages in DMD are slowly getting better.

Definately. In Matthew's case however, it would have been useful to know the full type of FunctionPredicate and the context in which opCall was called. Or heck, even just the context. Sure you can always find the offending line, but why spend 30 minutes doing text searches when the compiler can tell you where to look? Sometimes I think templates were just invented to make compiler writer's lives difficult ;) Sean
Jul 31 2004
parent Andy Friesen <andy ikagames.com> writes:
Sean Kelly wrote:

 Walter wrote:
 
 Good error messages are an art, they take time to develop. C++ has been
 working on trying to improve template error messages for over 10 years 
 now,
 with some success, even though C++ is still *notorious* for very obtuse
 error messages. Error messages in DMD are slowly getting better.

Definately. In Matthew's case however, it would have been useful to know the full type of FunctionPredicate and the context in which opCall was called. Or heck, even just the context. Sure you can always find the offending line, but why spend 30 minutes doing text searches when the compiler can tell you where to look? Sometimes I think templates were just invented to make compiler writer's lives difficult ;)

I think it's just an unavoidable side effect: Code that operates on code is always hard. (sure seems that way, anyhow) It's true even in Python, where the only difference is that you're creating instances of a class called 'type'. (fun sidenote: the 'type' class is its own type, and therefore an instance of itself) -- andy
Jul 31 2004