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.

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

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

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

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

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

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