www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - *sigh*

reply Caligo <iteronvexor gmail.com> writes:
At the moment I don't see how anything serious can be done with D.  In the
past few weeks, while working on a _toy_ project, I've encountered several
bugs that have caused a lot of problems and wasted a lot of time.  Sorry,
but it's just frustrating.  it's gotten to the point where I have to rum
DMD every time I add/modify 10 lines of code just to make sure the compiler
doesn't die.

Two of the bugs were causing 'internal errors', but I never managed to
isolate the issue so that I could bug report them.  I can't reproduce them
outside of my project, but at the moment I have managed to not have them
get triggered.  I also use GDC-4.6, which sometimes performs better.

*sigh*
Now that I got that off my chest...

I need to figure out what this is because I can't compile my code anymore,
and I get this:

  dmd: glue.c:1065: virtual unsigned int Type::totym(): Assertion `0'
failed.
  Aborted

I don't want to spend hours shuffling code around to find out what's
causing it :(
Dec 26 2011
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 27/12/2011 08:56, Caligo a écrit :

 At the moment I don't see how anything serious can be done with D.  In
 the past few weeks, while working on a _toy_ project, I've encountered
 several bugs that have caused a lot of problems and wasted a lot of
 time.  Sorry, but it's just frustrating.  it's gotten to the point where
 I have to rum DMD every time I add/modify 10 lines of code just to make
 sure the compiler doesn't die.


I would say that this is a good practice, bugguy compiler or not. If you 
test often, you spot errors earlier, and can fix them earlier. And the 
earlier you do so, the easier it is.
Dec 27 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 1:56 AM, Caligo wrote:

 At the moment I don't see how anything serious can be done with D. In
 the past few weeks, while working on a _toy_ project, I've
 encountered several bugs that have caused a lot of problems and
 wasted a lot of time.  Sorry, but it's just frustrating.  it's
 gotten to the point where I have to rum DMD every time I add/modify
 10 lines of code just to make sure the compiler doesn't die.

 Two of the bugs were causing 'internal errors', but I never managed
 to isolate the issue so that I could bug report them.  I can't
 reproduce them outside of my project, but at the moment I have
 managed to not have them get triggered.  I also use GDC-4.6, which
 sometimes performs better.

 *sigh*


The way I see it is, you are a customer (and one who has had enough
faith to hang around for a while), so your issues should be given
priority. We can and we should improve quality in the abstract, but at
the end of the day it's about the human beings who are using the language.

---------------------------8<------------------------------8<--------------------------------------------------

 struct A{

 A opBinary(string op)(const ref A a){ A rt; return rt; }

 void fun(){ } }

 struct B{

 A _a; alias _a this; }


 void main(){

 B b1, b2, b3; b3 = (b1 - b2).fun(); }


--------------------------->8------------------------------>8--------------------------------------------------

 Which causes:

 dmd: glue.c:1065: virtual unsigned int Type::totym(): Assertion `0'
 failed. Aborted

 DMD 2.57, 64-bit.


Let me make a couple of points about this code. (To be clear, neither 
justifies the presence of an internal compiler error.)

First, you are returning a reference to a local. That is automatically 
suspicious, although I assume this is reduced code from something 
meaningful.

Second, you are exploring a territory that is hardly accessible with 
other languages - operator overloading with consolidated implementation 
in conjunction with subtyping. That means it's not run-of-the-mill stuff 
the compiler is failing with, it's stuff that you would need to abandon 
wholesale if you switched languages.

Again, that's not a justification for the code not working with a 
meaningless error message. I want to warn against the paradoxical "I 
can't get creative use of feature X working, therefore I'm going back to 
my old language where I can't even think of X."

That _all_ being said, creative use of creative D features is a prime 
attraction factor of D and we must have them down perfectly. As I 
mentioned once, very often the first use of D by newcomers is not some 
shit task; shit tasks can be done in any language. It's some difficult 
task that D features promise a miraculous solution for, one that would 
be quite hard to achieve with other languages.


Andrei
Dec 27 2011
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 27/12/2011 16:25, Andrei Alexandrescu a écrit :

 Again, that's not a justification for the code not working with a
 meaningless error message. I want to warn against the paradoxical "I
 can't get creative use of feature X working, therefore I'm going back to
 my old language where I can't even think of X."


That is correct. But you have to consider some side element of the 
language : IDE support, toolchain, etc . . .

So if you can't use advaned feature of D, it is rationnal to go back to 
java/C++/whatever that have a way better IDE support and toolchain.
Dec 27 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 27-12-2011 17:14, deadalnix wrote:

 Le 27/12/2011 16:25, Andrei Alexandrescu a écrit :

 Again, that's not a justification for the code not working with a
 meaningless error message. I want to warn against the paradoxical "I
 can't get creative use of feature X working, therefore I'm going back to
 my old language where I can't even think of X."


 That is correct. But you have to consider some side element of the
 language : IDE support, toolchain, etc . . .

 So if you can't use advaned feature of D, it is rationnal to go back to
 java/C++/whatever that have a way better IDE support and toolchain.


I think with Mono-D and Visual D, we have pretty decent IDE support 
these days.

- Alex
Dec 27 2011
prev sibling next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
 I want to warn against the paradoxical "I can't get creative use of feature X
working, therefore I'm going back to my old language where I can't even think
of X."


It may seem paradoxical at first, but isn't. That feature X, often together
with Y and Z, could be one of the main reasons for choosing the language - so
if that feature doesn't deliver, or isn't reliable enough, this is a valid
reason to go back to a maybe less powerful, but at least reliable language. Not
only because of the current failure, but also out of fear of what else may
break.

artur
Dec 27 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/27/11 11:37 AM, Artur Skawina wrote:

 I want to warn against the paradoxical "I can't get creative use of
 feature X working, therefore I'm going back to my old language
 where I can't even think of X."


 It may seem paradoxical at first, but isn't. That feature X, often
 together with Y and Z, could be one of the main reasons for choosing
 the language - so if that feature doesn't deliver, or isn't reliable
 enough, this is a valid reason to go back to a maybe less powerful,
 but at least reliable language. Not only because of the current
 failure, but also out of fear of what else may break.

 artur


You may want to also quote the paragraph following that, which is very 
close to what you said :o). In brief, I entirely agree.

Andrei
Dec 27 2011
prev sibling parent Caligo <iteronvexor gmail.com> writes:
On Tue, Dec 27, 2011 at 9:25 AM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 The way I see it is, you are a customer (and one who has had enough
 faith to hang around for a while), so your issues should be given
 priority. We can and we should improve quality in the abstract, but at
 the end of the day it's about the human beings who are using the language.


I prefer to be called a "user" rather than a "customer".  Even better, a
"member" of _D_ revolution.
:-)

Let me make a couple of points about this code. (To be clear, neither

 justifies the presence of an internal compiler error.)

 First, you are returning a reference to a local. That is automatically
 suspicious, although I assume this is reduced code from something
 meaningful.

 Second, you are exploring a territory that is hardly accessible with other
 languages - operator overloading with consolidated implementation in
 conjunction with subtyping. That means it's not run-of-the-mill stuff the
 compiler is failing with, it's stuff that you would need to abandon
 wholesale if you switched languages.

 Again, that's not a justification for the code not working with a
 meaningless error message. I want to warn against the paradoxical "I can't
 get creative use of feature X working, therefore I'm going back to my old
 language where I can't even think of X."

 That _all_ being said, creative use of creative D features is a prime
 attraction factor of D and we must have them down perfectly. As I mentioned
 once, very often the first use of D by newcomers is not some shit task;
 shit tasks can be done in any language. It's some difficult task that D
 features promise a miraculous solution for, one that would be quite hard to
 achieve with other languages.


 Andrei


Actually, in regards to this issue, there isn't anything meaningful in my
code because:

somewhere in my project there is a member function that returns void,
represented in the code I posted by "fun()".  Then there is a another
member function that returns non-void, and its name differs only by a
letter (we'll call it here funs() ).  When I was coding I meant to call
funs(), and not fun().  When it came time to compiling the code, I got the
non-informative error message. This

b3 = (b1 - b2).funs();

made the error go away, but it wasn't easy to find.  This has been an
accidental bug discovery, :-)

I know bitching about issues isn't productive, but sometimes it gets
frustrating.  Programming in D is very exciting and fun, and
compiler/language bugs get in the way.
Dec 27 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/26/2011 11:56 PM, Caligo wrote:

 I need to figure out what this is because I can't compile my code anymore, and
I
 get this:

    dmd: glue.c:1065: virtual unsigned int Type::totym(): Assertion `0' failed.
    Aborted


Kenji prepared a fix for it, and I'm testing it now.
Dec 27 2011