*sigh*
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 :(
Re: *sigh*
On Tue, Dec 27, 2011 at 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* > 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 :( Have you tried Dustmite? https://github.com/CyberShadow/DustMite It works excellently for reducing ICE bugs. More Linux friendly than Windows because you've got to write some shell scripts, but it's worth it.
Re: *sigh*
2011/12/27 Caligo > 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 :( > You can use Dustmite to make it easier to isolate bugs. Together we can work to make dmd all better. http://d.puremagic.com/issues/show_bug.cgi?id=6774
Re: *sigh*
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.
Re: *sigh*
On Tue, Dec 27, 2011 at 1:59 AM, Andrew Wiley wrote:
> On Tue, Dec 27, 2011 at 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*
> > 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 :(
>
> Have you tried Dustmite?
> https://github.com/CyberShadow/DustMite
>
> It works excellently for reducing ICE bugs. More Linux friendly than
> Windows because you've got to write some shell scripts, but it's worth
> it.
>
I'll take a look at DustMite in the morning, and once I get some rest.
But, I found the bug!
---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.
I'll check in the morning if it's already been bug reported.
Re: *sigh*
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.
Re: *sigh*
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
Re: *sigh*
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
Re: *sigh*
On Tuesday, 27 December 2011 at 08:59:33 UTC, Caligo wrote: But, I found the bug! I'm pretty sure that's the same bug I hit over the weekend, but couldn't get isolated. In my case, it was caused by one of the parameters being of type __error__ which isn't handled in the totym() switch.
Re: *sigh*
"Andrew Wiley" wrote in message
news:mailman.1922.1324972797.24802.digitalmar...@puremagic.com...
>
>Have you tried Dustmite?
>https://github.com/CyberShadow/DustMite
>
>It works excellently for reducing ICE bugs. More Linux friendly than
>Windows because you've got to write some shell scripts, but it's worth
>it.
It doesn't have to be a shell script. You could just write the test in D or
any other language and use things like system("...cmd..."), etc. I've done
that.
It is *faster* in Linux though. Apperently due to Linux's faster process
creation. And segfaults are handled better on linux because linux merely
prints a message to stderr instead of popping up a dialog box that you, or a
program (one is available on the DustMite wiki) must click "Ok" on to
continue.
Re: *sigh*
On Tue, Dec 27, 2011 at 9:10 AM, Adam D. Ruppe wrote: > On Tuesday, 27 December 2011 at 08:59:33 UTC, Caligo wrote: > >> But, I found the bug! >> > > I'm pretty sure that's the same bug I hit over the weekend, > but couldn't get isolated. > > In my case, it was caused by one of the parameters being > of type __error__ which isn't handled in the totym() switch. > I think DMD should just give error and refuse to compile: "Error: expression (b1 - b2).fun() is void and has no value" http://d.puremagic.com/issues/show_bug.cgi?id=7173
Re: *sigh*
On 12/27/11, Nick Sabalausky wrote: > And segfaults are handled better on linux because linux merely > prints a message to stderr instead of popping up a dialog box that you, or a > program (one is available on the DustMite wiki) must click "Ok" on to > continue. I wonder if it would be faster if dustmite were to hook into w32 and intercept these dialog box invocations.
Re: *sigh*
I've posted a patch to fix the bug. https://github.com/D-Programming-Language/dmd/pull/587 Please wait until be merged it. (But I don't know when it will be done.) Kenji Hara 2011/12/28 Caligo : > > > On Tue, Dec 27, 2011 at 9:10 AM, Adam D. Ruppe > wrote: >> >> On Tuesday, 27 December 2011 at 08:59:33 UTC, Caligo wrote: >>> >>> But, I found the bug! >> >> >> I'm pretty sure that's the same bug I hit over the weekend, >> but couldn't get isolated. >> >> In my case, it was caused by one of the parameters being >> of type __error__ which isn't handled in the totym() switch. > > > I think DMD should just give error and refuse to compile: "Error: expression > (b1 - b2).fun() is void and has no value" > > > http://d.puremagic.com/issues/show_bug.cgi?id=7173
Re: *sigh*
> 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
Re: *sigh*
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
Re: *sigh*
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.
Re: *sigh*
On Tuesday, 27 December 2011 at 17:05:59 UTC, Andrej Mitrovic wrote: On 12/27/11, Nick Sabalausky wrote: And segfaults are handled better on linux because linux merely prints a message to stderr instead of popping up a dialog box that you, or a program (one is available on the DustMite wiki) must click "Ok" on to continue. I wonder if it would be faster if dustmite were to hook into w32 and intercept these dialog box invocations. It wouldn't be much easier than writing a stand-alone program. It's doable, but I found that a polling program coupled with a virtual desktop tool and temporarily disabling "Windows Sounds" works well enough.
Re: *sigh*
On Tue, Dec 27, 2011 at 9:25 AM, Andrei Alexandrescu < seewebsiteforem...@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.
Re: *sigh*
On 12/27/11, Vladimir Panteleev wrote: > and temporarily disabling "Windows Sounds" > works well enough. Oh man, I forgot those could block. But I had them off anyway. They were fun back in Win98 days with those cool space themes. They had awesome intro's. :)
Re: *sigh*
On Tuesday, 27 December 2011 at 22:51:20 UTC, Andrej Mitrovic wrote: On 12/27/11, Vladimir Panteleev wrote: and temporarily disabling "Windows Sounds" works well enough. Oh man, I forgot those could block. But I had them off anyway. They were fun back in Win98 days with those cool space themes. They had awesome intro's. :) Heh, it's not the blocking, it's the incessant distracting beeping :) If a program starts calling MessageBeep in a loop, the system will keep beeping for a long time after, even if you kill the program. I think restarting the Windows Audio service gets rid of it.
Re: *sigh*
On 12/27/2011 12:05 PM, Andrej Mitrovic wrote: On 12/27/11, Nick Sabalausky wrote: And segfaults are handled better on linux because linux merely prints a message to stderr instead of popping up a dialog box that you, or a program (one is available on the DustMite wiki) must click "Ok" on to continue. I wonder if it would be faster if dustmite were to hook into w32 and intercept these dialog box invocations. I think it's the 'hard error' mode of the process that determines whether a dialog is invoked. If you could change the hard error handler of the process (which I believe is CSRSS normally) you could prevent this from happening. Not sure though.
