• Matthew (21/21) Jul 30 2004 At the moment I'm getting
• Walter (13/34) Jul 30 2004 Try breaking up line 133 into multiple lines.
• Matthew (48/92) Jul 30 2004 I'm assuming you're making a gag in an to attempt to difuse/dissipate my...
• Walter (37/84) Jul 31 2004 obvious frustrations. (Didn't work, btw, but
• Matthew (4/98) Jul 31 2004 I don't need good ones, I just need some clues. You already have the con...
• Sean Kelly (9/14) Jul 31 2004 Definately. In Matthew's case however, it would have been useful to
• Andy Friesen (8/26) Jul 31 2004 I think it's just an unavoidable side effect: Code that operates on code...

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

"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

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.

"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

 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.

"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

obvious frustrations. (Didn't work, btw, but
 playing football with the boys outside for 30 mins has at least taken the

edge off.)

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

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.

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.

"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

 obvious frustrations. (Didn't work, btw, but
 playing football with the boys outside for 30 mins has at least taken the

 edge off.)

 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

 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.

 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.

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

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