digitalmars.D.bugs - Aliases not passed down to child classes
- Matthew Wilson (61/61) Jul 16 2004 Consider the following:
- Walter (43/43) Jul 17 2004 I modified your example, as your example was incomplete (missing import
- Matthew Wilson (5/48) Jul 17 2004 Bah! I thought that'd be the case. I guess I'm just stretching the
-
Walter
(9/13)
Jul 17 2004
Hence my robotic request for reproducible examples
. - Matthew Wilson (87/100) Jul 18 2004 Ok, I'm trying to boil down the compiler-crash / recursion problem. I've...
- Walter (23/23) Jul 19 2004 Thanks. I boiled it down much further:
- Sean Kelly (29/34) Jul 19 2004 I think if a problem can be defined then it can be simplified. The prob...
- J C Calvarese (14/43) Jul 19 2004 I'm more inclined to think it's one or both of these reasons:
- J C Calvarese (10/35) Jul 19 2004 Well, as threatened:
- John Reimer (2/9) Jul 19 2004 What about runnons that would be bad!
- Walter (3/5) Jul 20 2004 I put a link to it on www.digitalmars.com/bugs.html. Thanks!
- Walter (13/20) Jul 20 2004 100 lines isn't bad, but I get a lot of "I'll ship you my whole 5 mb of
- Matthew (7/30) Jul 19 2004 I think it's part skill - and no surprise that you're the most skilled -...
- Walter (14/19) Jul 20 2004 and part
- Roberto Mariottini (18/23) Jul 21 2004 I speak out of my own experience: I've finally found a bug in the embedd...
- Lars Ivar Igesund (4/11) Jul 22 2004 I believe the lack of this skill in most cases turns out to be lazyness.
Consider the following:
/*
//////////////////////////////////////////////////////////////////////////
*/
module std.dtl.functions.categories;
interface IFunction
{}
interface IPredicate
: public IFunction
{}
template Predicate(A) { class Predicate
: public IPredicate
{
public:
alias bool return_type;
alias A argument_type;
}}
/*
//////////////////////////////////////////////////////////////////////////
*/
/*
//////////////////////////////////////////////////////////////////////////
*/
module std.dtl.functions.predicates;
template Not(F) { class Not
: public Predicate!(argument_type_selector!(F).argument_type)
{
public:
this(F f)
{
m_f = f;
}
public:
bool opCall(argument_type v)
{
return !m_f(v);
}
private:
F m_f;
}}
/*
//////////////////////////////////////////////////////////////////////////
*/
/*
//////////////////////////////////////////////////////////////////////////
*/
class IsOdd
: public Predicate!(int)
{
public:
bool opCall(int i)
{
return 0 != (i % 2);
}
};
/*
//////////////////////////////////////////////////////////////////////////
*/
I'm getting the error: "no property 'argument_type' for type 'IsOdd'"
I presume this is a bug. Is that so? If so, can it be fixed? If not, is
there a reason that'd preclude a language change to facilitate this?
Jul 16 2004
I modified your example, as your example was incomplete (missing import
statements):
-------------------------------------------
interface IFunction
{}
interface IPredicate : public IFunction
{}
template Predicate(A)
{ class Predicate
: public IPredicate
{
public:
alias bool return_type;
alias A argument_type;
}
}
template Not(F) { class Not
: public Predicate!(argument_type_selector!(F).argument_type)
{
public:
this(F f)
{
m_f = f;
}
public:
bool opCall(argument_type v)
{
return !m_f(v);
}
private:
F m_f;
}}
class IsOdd
: public Predicate!(int)
{
public:
bool opCall(int i)
{
return 0 != (i % 2);
}
};
----------------------------------------------------
and it compiles successfully.
Jul 17 2004
Bah! I thought that'd be the case. I guess I'm just stretching the
complexity limits.
Want the full-zip to play with? ;)
"Walter" <newshound digitalmars.com> wrote in message
news:cdansf$15pg$1 digitaldaemon.com...
I modified your example, as your example was incomplete (missing import
statements):
-------------------------------------------
interface IFunction
{}
interface IPredicate : public IFunction
{}
template Predicate(A)
{ class Predicate
: public IPredicate
{
public:
alias bool return_type;
alias A argument_type;
}
}
template Not(F) { class Not
: public Predicate!(argument_type_selector!(F).argument_type)
{
public:
this(F f)
{
m_f = f;
}
public:
bool opCall(argument_type v)
{
return !m_f(v);
}
private:
F m_f;
}}
class IsOdd
: public Predicate!(int)
{
public:
bool opCall(int i)
{
return 0 != (i % 2);
}
};
----------------------------------------------------
and it compiles successfully.
Jul 17 2004
"Matthew Wilson" <admin.hat stlsoft.dot.org> wrote in message news:cdasb9$16vs$2 digitaldaemon.com...Bah! I thought that'd be the case.Hence my robotic request for reproducible examples <g>.I guess I'm just stretching the complexity limits.I sincerely doubt it. DMD doesn't have complexity limits (other than running out of memory).Want the full-zip to play with? ;)No, I'll just boringly repeat that 99% of problems can be reduced to 10 lines or less of code. Just copy it all to another directory, and then whack away at it. I've had people send me literally megabytes of source they assured me couldn't be reduced that whacked down to 10 lines (!).
Jul 17 2004
Ok, I'm trying to boil down the compiler-crash / recursion problem. I've not
got that yet, but here's an example of the alias/property problem. To
suppress it, swap the commented line over.
template HackSelector(T)
{
alias T selected_type;
}
interface NotionalRangeTag
{}
template NotionalRange(V) { interface NotionalRange
: public NotionalRangeTag
{
public:
alias V value_type;
alias NotionalRangeTag range_category;
public:
bool is_open();
value_type current();
void advance();
}}
template MatchedNotionalRange(R, F) { class MatchedNotionalRange
: public NotionalRange!(R.value_type)
// : public
NotionalRange!(HackSelector!(typeof(R.value_type)).selected_type)
{
public:
bool is_open()
{
return false;
}
value_type current()
{
return value_type.init;
}
void advance()
{
}
public:
template select(F) { .MatchedNotionalRange!(R, F) select(F f = new
F())
{
return null;
}}
}}
template List(V) { class List
{
public:
alias V value_type;
public:
class Range
{
public:
alias V value_type;
}
template select(F) { MatchedNotionalRange!(Range, F) select(F f =
new F())
{
return null;
}}
}}
class SomeFunc1
{
public:
bool opCall(int i)
{
return 0 != i;
}
}
class SomeFunc2
{
public:
bool opCall(int i)
{
return 0 == (i % 3);
}
}
int main()
{
alias List!(int) int_list_t;
int_list_t l = new int_list_t();
l.select!(SomeFunc1)().select!(SomeFunc2)();
return 0;
}
"Walter" <newshound digitalmars.com> wrote in message
news:cdbpg8$1g7n$1 digitaldaemon.com...
"Matthew Wilson" <admin.hat stlsoft.dot.org> wrote in message
news:cdasb9$16vs$2 digitaldaemon.com...
Bah! I thought that'd be the case.
Hence my robotic request for reproducible examples <g>.
I guess I'm just stretching the
complexity limits.
I sincerely doubt it. DMD doesn't have complexity limits (other than
running
out of memory).
Want the full-zip to play with? ;)
No, I'll just boringly repeat that 99% of problems can be reduced to 10
lines or less of code. Just copy it all to another directory, and then
whack
away at it. I've had people send me literally megabytes of source they
assured me couldn't be reduced that whacked down to 10 lines (!).
Jul 18 2004
Thanks. I boiled it down much further:
------------------------------------------------
interface NotionalRange(V)
{
}
class MatchedNotionalRange(R)
: NotionalRange!(R.value_type)
{
}
class Range
{
alias int value_type;
}
class List
{
MatchedNotionalRange!(Range) x;
}
-----------------------------------------------------------
I'm a bit befuddled, though. While I believe it is straightforward to boil
these problems down to their essentials, almost nobody else (besides
Christof Meerwald) seems to be able to do it. Am I sadly mistaken in
thinking this is straightforward, or is it an unusual skill? Can it be
taught?
Jul 19 2004
Sean Kelly <sean f4.ca> In article <cdhf4o$pur$1 digitaldaemon.com>, Walter says...I'm a bit befuddled, though. While I believe it is straightforward to boil these problems down to their essentials, almost nobody else (besides Christof Meerwald) seems to be able to do it. Am I sadly mistaken in thinking this is straightforward, or is it an unusual skill? Can it be taught?I think if a problem can be defined then it can be simplified. The problem in many cases is that people encounter an odd bug and don't know what's causing it. Another factor may be laziness. It's easier to post broken code then spend the time to investigate what's going on and try to create a minimal repro. I've personally posted a few screw-ups mostly because the fault seemed simple and I didn't spend the time to double-check that it really existed. Some part of this may be that bug reports are filed in a forum rather than through some more structured method. It may be a fault of the interface that people feel they can open a dialog here to narrow down a problem rather than doing the work themselves and posting something more detailed. Either way, I believe the skill can certainly be taught, as it is a lot like debugging. Assuming there are people that really can't do this (and at the risk of straying from the topic a bit) I think part of the problem may be with how programming is taught these days. In attempting to make it easy to learn I think too many details are being glossed over and the focus is mostly on producing code that will compile, with little thought to maintenance or to how the machine does what you've told it to. Assuming this is a real issue, maybe a Q&A forum would be a good place for new folks to ask questions and such. The main D forum serves that purpose now, but it's intermingled with noise from feature requests and other stuff. It would also be nice to have greater cohesion between documentation and feature changes. The bug reports are useful and I've noticed you update the online docs pretty well, but there are still language features with little or no documentation which can cause confusion about whether something is a bug or not. However, this would obviously take away from development time so I'm hesitant to really push for it. Perhaps there are some willing volunteers who would ask around and fill in these sections? Sean
Jul 19 2004
Walter wrote:
Thanks. I boiled it down much further:
------------------------------------------------
interface NotionalRange(V)
{
}
class MatchedNotionalRange(R)
: NotionalRange!(R.value_type)
{
}
class Range
{
alias int value_type;
}
class List
{
MatchedNotionalRange!(Range) x;
}
-----------------------------------------------------------
I'm a bit befuddled, though. While I believe it is straightforward to boil
these problems down to their essentials, almost nobody else (besides
Christof Meerwald) seems to be able to do it. Am I sadly mistaken in
thinking this is straightforward, or is it an unusual skill? Can it be
taught?
I'm more inclined to think it's one or both of these reasons:
1. You're just much, much, more intelligent that any of the rest of us
(except Mr. Meerwald).
2. Perhaps after spending 5 hours condensing it from 50,000 lines to 100
lines, we decide we're tired and it's small enough for you to work with.
(And yes, the TV was on the entire time, and I'm sure it wouldn't have
taken so long to do if I turned it off.)
I really doubt it's lack of ability though. I think it's lack of time.
By the way, I've thought about writing up some hints for how to condense
down bug reports, but I suspect I'm the only one who would read it. :)
--
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Jul 19 2004
J C Calvarese wrote:Walter wrote:...Well, as threatened: http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/BugReports Hopefully, it makes a little sense. I'm crossing my fingers that I didn't end every sentence with a preposition. and used some good Capitalization. And no sentence fragments... -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/I'm a bit befuddled, though. While I believe it is straightforward to boil these problems down to their essentials, almost nobody else (besides Christof Meerwald) seems to be able to do it. Am I sadly mistaken in thinking this is straightforward, or is it an unusual skill? Can it be taught?I'm more inclined to think it's one or both of these reasons: 1. You're just much, much, more intelligent that any of the rest of us (except Mr. Meerwald). 2. Perhaps after spending 5 hours condensing it from 50,000 lines to 100 lines, we decide we're tired and it's small enough for you to work with. (And yes, the TV was on the entire time, and I'm sure it wouldn't have taken so long to do if I turned it off.) I really doubt it's lack of ability though. I think it's lack of time. By the way, I've thought about writing up some hints for how to condense down bug reports, but I suspect I'm the only one who would read it. :)
Jul 19 2004
Well, as threatened: http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/BugReports Hopefully, it makes a little sense. I'm crossing my fingers that I didn't end every sentence with a preposition. and used some good Capitalization. And no sentence fragments...What about runnons that would be bad!
Jul 19 2004
"J C Calvarese" <jcc7 cox.net> wrote in message news:cdi2tj$10io$1 digitaldaemon.com...Well, as threatened: http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/BugReportsI put a link to it on www.digitalmars.com/bugs.html. Thanks!
Jul 20 2004
"J C Calvarese" <jcc7 cox.net> wrote in message news:cdhm8t$sen$1 digitaldaemon.com...2. Perhaps after spending 5 hours condensing it from 50,000 lines to 100 lines, we decide we're tired and it's small enough for you to work with. (And yes, the TV was on the entire time, and I'm sure it wouldn't have taken so long to do if I turned it off.)100 lines isn't bad, but I get a lot of "I'll ship you my whole 5 mb of source", and that's a tough slog since I have no idea what the code is and what it's supposed to be doing.I really doubt it's lack of ability though. I think it's lack of time.But also everyone wants their particular bug addressed. And I want to get to them all. But to be frank, the ones that are reduced to the minimum move to the front of the queue, the ones that are 5 Mb of source fall to the back. Also, reducing the code to the minimum usually suggests a workaround, and that'll keep your project moving.By the way, I've thought about writing up some hints for how to condense down bug reports, but I suspect I'm the only one who would read it. :)If it's good, I'll put it up on the web site. Anyone want to see consistently top drawer bug reports, just check out Christof's work in the digitalmars C++ group.
Jul 20 2004
"Walter" <newshound digitalmars.com> wrote in message
news:cdhf4o$pur$1 digitaldaemon.com...
Thanks. I boiled it down much further:
------------------------------------------------
interface NotionalRange(V)
{
}
class MatchedNotionalRange(R)
: NotionalRange!(R.value_type)
{
}
class Range
{
alias int value_type;
}
class List
{
MatchedNotionalRange!(Range) x;
}
-----------------------------------------------------------
I'm a bit befuddled, though. While I believe it is straightforward to boil
these problems down to their essentials, almost nobody else (besides
Christof Meerwald) seems to be able to do it. Am I sadly mistaken in
thinking this is straightforward, or is it an unusual skill? Can it be
taught?
I think it's part skill - and no surprise that you're the most skilled - and
part
other things. For me, those "other things" are generally a combination of time
pressure and a genuine confusion as to where the error may lie due to the
complexity and unfamiliarity with D; if it were C++ I could boil things down
more.
Jul 19 2004
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:cdhn59$so6$1 digitaldaemon.com...I think it's part skill - and no surprise that you're the most skilled -and partother things. For me, those "other things" are generally a combination oftimepressure and a genuine confusion as to where the error may lie due to the complexity and unfamiliarity with D; if it were C++ I could boil thingsdownmore.Part of boiling it down is turning off one's brain about what might be wrong, and simply whacking away at it. (And there's just no way I understand complex template code, I just whack away at it.) Get rid of aliases, replace complex types with 'int', delete statements with wild abandon, remove every unused declaration, delete the function bodies, etc. Part of it is to create a simple cc.bat file to compile it, then the 'whack-compile-whack-compile' loop is pretty quick. I also use a text editor that automatically creates backup files, so if a whack removed the failure, then I just copy back the backup and whack off something else.
Jul 20 2004
In article <cdhf4o$pur$1 digitaldaemon.com>, Walter says...[...]I'm a bit befuddled, though. While I believe it is straightforward to boil these problems down to their essentials, almost nobody else (besides Christof Meerwald) seems to be able to do it. Am I sadly mistaken in thinking this is straightforward, or is it an unusual skill? Can it be taught?I speak out of my own experience: I've finally found a bug in the embedded OS we are using that was bugging me for months. Not that I worked full time to the bug discovering task, but I've dedicated many days to it. It was a nightmare: every test case I put up was perfectly working, while the full app was not. Obviously, I was searching the bug where it wasn't. One day, to do some unrelated testing, I completely excluded the part of the program that (I thougth) contained the bug, and the bug was still there! Now it was easy to track it down, looking where I never looked before. I think the main problem was the little I knew of the underlying OS internals, that made me look in the wrong places (enlarging the size of a buffer made the bug appear less than 1/100 than before, but the bug was elsewhere). Apart from lazyness and short time, IMHO the main reason for the difficulty to find a short test case resides in the little knowing of the language syntax and the compiler internals. So for me it's not surprising that you, knowing better than anyone else the language and the compiler, are the bes test case maker. Ciao
Jul 21 2004
Walter wrote: ----------------------------------------------------------I'm a bit befuddled, though. While I believe it is straightforward to boil these problems down to their essentials, almost nobody else (besides Christof Meerwald) seems to be able to do it. Am I sadly mistaken in thinking this is straightforward, or is it an unusual skill? Can it be taught?I believe the lack of this skill in most cases turns out to be lazyness. Lars Ivar Igesund
Jul 22 2004