www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A couple of thoughts/queries.

reply Robby <robby.lansaw gmail.com> writes:
Haven't watched the ng for a while, but I was curious on a couple of things.

1.) Could we perhaps put a lot of the proposals for const on a wiki? I 
like the discussions that are going around it, but I must admit that 
they're all starting to really, really blend together.

2.) Between here and d.learn there's starting to get a lot of valuable 
information coming in as answers to other programmers queries. Could 
dsource.org or similar setup a basic faq system so we maybe there can be 
some cross posting of the answers to something more accessible?

Wouldn't take much I wouldn't think, tagging would take care of the 
categorization, or I guess we could just start it on the wiki. Should 
help with a lot of the duplicate requests too (and would be a bonus if 
some of the feature requests that have been hashed out over and over had 
a place there, along with decided rationale.)

3.) A language feature.  Thoughts on something similar on the following?
After a lot of tests, and a lot of debate we're heading towards a full 
port over time to D and only D, so we can get out of the c, ruby, and 
java entanglement we've been in for years.

On the java side we've been running into what I'd consider language 
implementation cruft that we're having to bring over.

class Show
{
   ...
}
...
function orig_func(Show s) {
	if (s !is null)
		
}

...
function some_func(enforce Show s) {
	// s is never null.

}
Show s = new Show();
some_func(s);	//ok
some_func(null);// error

I hate the idea of playing "i need another keyword", but I can't really 
see how it could be done and backwards compatible.

Anyways, what I'm in hopes of finding is a way to tell the compiler that 
I never want null, ever. I want an instance of the class and that's 
that. The whole idea of taking every lil runtime hit for checking  and 
the code cruft for writing it when in fact it's something that seems to 
be easy for a compiler to do the work for me.

Unless I'm missing something? Or an obvious hindrance to this entire 
thought process?

4.) SWT. Yeah, *that* SWT.
	We're considering sponsoring the inital port of SWT over to D for Linux 
and Windows (during hobby time I'd love to do a mac, but I'll have to 
grab a mini to get it going). I'm trying to get upper management to 
allow me to take a few weeks to run through the Windows implementation 
at first. We'll see if they let me.

We're trying to simplify our tooling and development requirements over 
2008. We have a lot of SWT based code and developers used to developing 
for it. So it's why a port is being considered. (The main contender 
funny enough is xulrunner (read:mozilla) sigh).

SWT has a yearly release cycle and a fairly static api, so once it's 
built it shouldn't be too hard to keep up. From what I can tell what 
hurt DWT is D's volatility at the time more than Eclipse's. (and of 
course no one to work on it).

Tioport being a java translator has a couple of faults that aren't 
something we could jump in and just fix. The jni cruft that is in SWT 
gets translated into a D that doesn't even look like D. classes that 
should be structs in internals.* for one. I'm not knocking the tool, but 
it's clear that the overhead it's already producing that putting 
javaisms into D directly by means of translation feels cumbersome.

So knowing I'm heading into Monday needing to make a decent case for the 
cost of the SWT port I'm looking to see if there would be interest in 
help maintaining and enhancing an SWT port should I do all of the heavy 
lifting?

With Eclipse running well on Vista it seems that we'll at least be 
pretty forward looking on the windows side of things and from what I can 
tell the linux gtk side of things seems a lot simpler to do anyways.

Anyways, Food for thought.

Back to work.
Dec 07 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robby wrote:

 Anyways, what I'm in hopes of finding is a way to tell the compiler that 
 I never want null, ever. I want an instance of the class and that's 
 that. The whole idea of taking every lil runtime hit for checking  and 
 the code cruft for writing it when in fact it's something that seems to 
 be easy for a compiler to do the work for me.


The hardware will do the check for null pointer for you every time you 
do a dereference.
Dec 08 2007
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Walter Bright schrieb:

 Robby wrote:

 Anyways, what I'm in hopes of finding is a way to tell the compiler
 that I never want null, ever. I want an instance of the class and
 that's that. The whole idea of taking every lil runtime hit for
 checking  and the code cruft for writing it when in fact it's
 something that seems to be easy for a compiler to do the work for me.


 
 The hardware will do the check for null pointer for you every time you
 do a dereference.


I think he is talking about compile time check.
Something like non nullable storage class?
Dec 08 2007
parent Robby <robby.lansaw gmail.com> writes:
Frank Benoit wrote:

 Walter Bright schrieb:

 Robby wrote:

 Anyways, what I'm in hopes of finding is a way to tell the compiler
 that I never want null, ever. I want an instance of the class and
 that's that. The whole idea of taking every lil runtime hit for
 checking  and the code cruft for writing it when in fact it's
 something that seems to be easy for a compiler to do the work for me.


 The hardware will do the check for null pointer for you every time you
 do a dereference.


 
 I think he is talking about compile time check.
 Something like non nullable storage class?


Exactly.

Having a storage class 'enforce' that only allows non nullable types 
allows has a few advantages as far as I see it.

It's self documenting. It gives a contractual saftey to the implementor 
of the method/function. and it removes a lot of the cruft that the 
compiler already knows. (which is something I took notice D tends to do 
on a lot of other things.)

I know that the general consensus around D tends to be c/c++, but 
there's a solid selling point for us Java shops too, and this is one 
crufty piece that is littered through our code we'd really like to try 
and remove at some point.
Dec 12 2007
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:

 Robby wrote:

 Anyways, what I'm in hopes of finding is a way to tell the compiler
 that I never want null, ever. I want an instance of the class and
 that's that. The whole idea of taking every lil runtime hit for
 checking  and the code cruft for writing it when in fact it's
 something that seems to be easy for a compiler to do the work for me.


 
 The hardware will do the check for null pointer for you every time you
 do a dereference.


<summary>

Non-nullable types != null deref exceptions.
Non-nullable types > null deref exceptions.
Non-nullable types > contracts.

</summary>

<rant>

That's not the point.  Null dereference errors aren't all that helpful.
 They tell you that something's gone wrong, but they don't tell you *why*.

Let's pretend for a moment that appending ' ' to an object type makes it
a non-nullable type.  For example:

    Object  o = null;

That would be a *compile-time error* since Object s cannot be null.  It
also means that (in the general case) this won't work:

    Object o1 = new Object;
    Object  o2 = o1;

That's because o1 could possibly contain a null.  So in order to do
this, you'd have to check that o1 is not null, and then cast.  Heck, the
compiler could even do that for you:

    Object  o2 = cast( ) o1

Why is this better than a null dereference exception?  Because it will
throw the exception when you try to *introduce the null* into your
program's state, *not* when you try to use it.  Normally, all a null
dereference tells you is that somewhere along the line, you screwed up.
 This tells you *when* you screw up.

What's more, this makes code cleaner, easier to check, and faster.
Instead of having this all over the place:

    // the_object is a parameter, and could be null, so we'd best check
    // it!  We can't assert directly or the check will be elided in
    // -release builds.
    if( the_object is null ) assert(false);

...we need only check exactly once: where we introduce the object.
After that, there's zero runtime cost, since we've already guaranteed
that the reference is not null.  This is unlike contracts and invariants
which exact an overhead, not to mention the fact that you can always
either forget to write the assertion, or write it incorrectly.

Tim Sweeny (the lead programmer at Epic) once commented that the
majority of bugs in the Unreal engine were caused by null dereferences;
they knew the bugs were there, they just couldn't work out where the
nulls were coming from.  He said he'd kill to have non-nullable objects
in C++. [1]

This is something I've wanted for ages [2], if only for all the checks
it would let me not write.  I understand that there are lots of things
people want you to implement, and you can't fit them all in.  But don't
mistake this for null dereference exceptions.

	-- Daniel

[1] I'm recalling from memory; too tired to go tracking down the paper
itself.  Something about the next big programming language for games.
Incidentally, he put his money on a Haskell-style language with C-style
syntax.  And non-nullable types. :P

[2] Actually, what I *really* want is some form of type constraints.
Something like:

    alias real:{$ != 0 && $ == $} real_not_zero_or_nan;

    Assuming '$' means "current value".  At the moment, the best tool we
have for this is, unfortunately, Hungarian notation (apps Hungarian, not
that pointless system Hungarian.)

</rant>
Dec 08 2007
parent Robby <robby.lansaw gmail.com> writes:
Daniel Keep wrote:

 
 Walter Bright wrote:

 Robby wrote:

 Anyways, what I'm in hopes of finding is a way to tell the compiler
 that I never want null, ever. I want an instance of the class and
 that's that. The whole idea of taking every lil runtime hit for
 checking  and the code cruft for writing it when in fact it's
 something that seems to be easy for a compiler to do the work for me.


 The hardware will do the check for null pointer for you every time you
 do a dereference.


 
 <summary>
 
 Non-nullable types != null deref exceptions.
 Non-nullable types > null deref exceptions.
 Non-nullable types > contracts.
 
 </summary>
 
 <rant>
 
 That's not the point.  Null dereference errors aren't all that helpful.
  They tell you that something's gone wrong, but they don't tell you *why*.
 
 Let's pretend for a moment that appending ' ' to an object type makes it
 a non-nullable type.  For example:
 
     Object  o = null;
 
 That would be a *compile-time error* since Object s cannot be null.  It
 also means that (in the general case) this won't work:
 
     Object o1 = new Object;
     Object  o2 = o1;
 
 That's because o1 could possibly contain a null.  So in order to do
 this, you'd have to check that o1 is not null, and then cast.  Heck, the
 compiler could even do that for you:
 
     Object  o2 = cast( ) o1
 
 Why is this better than a null dereference exception?  Because it will
 throw the exception when you try to *introduce the null* into your
 program's state, *not* when you try to use it.  Normally, all a null
 dereference tells you is that somewhere along the line, you screwed up.
  This tells you *when* you screw up.
 
 What's more, this makes code cleaner, easier to check, and faster.
 Instead of having this all over the place:
 
     // the_object is a parameter, and could be null, so we'd best check
     // it!  We can't assert directly or the check will be elided in
     // -release builds.
     if( the_object is null ) assert(false);
 
 ....we need only check exactly once: where we introduce the object.
 After that, there's zero runtime cost, since we've already guaranteed
 that the reference is not null.  This is unlike contracts and invariants
 which exact an overhead, not to mention the fact that you can always
 either forget to write the assertion, or write it incorrectly.
 
 Tim Sweeny (the lead programmer at Epic) once commented that the
 majority of bugs in the Unreal engine were caused by null dereferences;
 they knew the bugs were there, they just couldn't work out where the
 nulls were coming from.  He said he'd kill to have non-nullable objects
 in C++. [1]
 
 This is something I've wanted for ages [2], if only for all the checks
 it would let me not write.  I understand that there are lots of things
 people want you to implement, and you can't fit them all in.  But don't
 mistake this for null dereference exceptions.
 
 	-- Daniel
 
 [1] I'm recalling from memory; too tired to go tracking down the paper
 itself.  Something about the next big programming language for games.
 Incidentally, he put his money on a Haskell-style language with C-style
 syntax.  And non-nullable types. :P
 
 [2] Actually, what I *really* want is some form of type constraints.
 Something like:
 
     alias real:{$ != 0 && $ == $} real_not_zero_or_nan;
 
     Assuming '$' means "current value".  At the moment, the best tool we
 have for this is, unfortunately, Hungarian notation (apps Hungarian, not
 that pointless system Hungarian.)
 
 </rant>


Totally agree.

I was thinking more in the lines of having the 'contract' within the 
function/method declaration rather than having it with the object 
passing so that the api could have the final say, rather than the object 
passing in. And a storage class does have a backwards compat story 
without adding anything to the allowed identifier grammar.

I would just love to get out of the watch for and except loop that we 
always seem to be in.

I remember reading some where that dealing with nulls and exceptions 
therein is a lot like C and memory issues, and c++ has both dramas. I'm 
not overly C++ literate so I can't really comment.

In Ruby we tend to develop in a duck typing fashion, and since D is 
obviously statically typed, I'd love for the compiler to actually take 
care of some of the work for me, since it'll know anyways and i can 
delcare not wanting it.
Dec 12 2007
prev sibling next sibling parent James Dennett <jdennett acm.org> writes:
Walter Bright wrote:

 Robby wrote:

 Anyways, what I'm in hopes of finding is a way to tell the compiler
 that I never want null, ever. I want an instance of the class and
 that's that. The whole idea of taking every lil runtime hit for
 checking  and the code cruft for writing it when in fact it's
 something that seems to be easy for a compiler to do the work for me.


 
 The hardware will do the check for null pointer for you every time you
 do a dereference.


Often, yes, but not always.  Presumably compilers are smart enough
*not* to count on this for large offsets into objects and add explicit
code when they guarantee to diagnose dereferences from null pointers.
(But I'd check the generated code if I was going to rely on such a
thing instead of ensuring that it didn't happen in the first place.)

-- James
Dec 24 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/8/07, Walter Bright <newshound1 digitalmars.com> wrote:

 The hardware will do the check for null pointer for you every time you
 do a dereference.


By which you mean, the program will crash. I don't see that as a good thing.
Dec 24 2007
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:

 Robby wrote:

 Anyways, what I'm in hopes of finding is a way to tell the compiler 
 that I never want null, ever. I want an instance of the class and 
 that's that. The whole idea of taking every lil runtime hit for 
 checking  and the code cruft for writing it when in fact it's 
 something that seems to be easy for a compiler to do the work for me.


 
 The hardware will do the check for null pointer for you every time you 
 do a dereference.


I wouldn't mind this. Only problem is, you don't get a file or line 
number. You don't get any clue where the problem is. You're left with 
debugging by printfs or attaching a debugger, and D doesn't have great 
debugger support at the moment. Either way takes much more time than 
simply reading an exception.

You might be able to trap SIGSEGV and output the last file and line 
number executed. The former's easy; the latter might require more upkeep 
than watching pointer dereferences.
Dec 25 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Christopher Wright wrote:

 Walter Bright wrote:

 Robby wrote:

 Anyways, what I'm in hopes of finding is a way to tell the compiler 
 that I never want null, ever. I want an instance of the class and 
 that's that. The whole idea of taking every lil runtime hit for 
 checking  and the code cruft for writing it when in fact it's 
 something that seems to be easy for a compiler to do the work for me.


 The hardware will do the check for null pointer for you every time you 
 do a dereference.


 
 I wouldn't mind this. Only problem is, you don't get a file or line 
 number. You don't get any clue where the problem is. You're left with 
 debugging by printfs or attaching a debugger, and D doesn't have great 
 debugger support at the moment. Either way takes much more time than 
 simply reading an exception.
 
 You might be able to trap SIGSEGV and output the last file and line 
 number executed. The former's easy; the latter might require more upkeep 
 than watching pointer dereferences.


ddbg does a pretty decent job on Windows.  Still, it gives me no stack 
trace upon "access violation" a significant fraction of the time.  When 
it works it's great, though.  You should definitely be using it if 
you're on Windows.  I have also found that Windbg can sometimes get a 
stack trace when ddbg can't.

If you're not on Windows then I presume gdb works?  I guess that doesn't 
have any D-specific knowledge.  Support for D in zerobugs is still 
vaporware?

Still, I'm with you.  Getting a stack trace should be easier. 
Especially considering there have been patches to phobos floating around 
for a year at least that already implement it.

--bb
Dec 25 2007
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/26/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:

 Getting a stack trace should be easier.
 Especially considering there have been patches to phobos floating around
 for a year at least that already implement it.


I don't need a whole stack tracing mechanism. I only want to know
which line of source code tried to dereference a null pointer. More
than that is overkill.

Ideally, I'd want runtime checks for null dereference compiled into
the code whenever -debug is present on the command line.
Alternatively, if that's too general, why not invent a new compiler
switch, say -nullcheck?

(And speaking of compiler switches, could we possibly allow them to
start with /two/ minus signs instead of one, e.g. --dubug?)
Dec 25 2007
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Bill Baxter wrote:

 
 If you're not on Windows then I presume gdb works?  I guess that doesn't
 have any D-specific knowledge.  Support for D in zerobugs is still
 vaporware?


I did a quick test, and zerobugs has at least some D support. Types seems to
be correctly demangled in the variables view, whereas functions and method
names in the stack trace are not. I wasn't immediately able to pinpoint the
location of my segfault though (a real one that I knew of), although the
stacktrace showed up. Definately better looking than gdb, all in all :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Dec 26 2007
parent reply John Reimer <terminal.node gmail.com> writes:
On Wed, 26 Dec 2007 10:33:40 +0100, Lars Ivar Igesund wrote:


 Bill Baxter wrote:

 
 If you're not on Windows then I presume gdb works?  I guess that
 doesn't have any D-specific knowledge.  Support for D in zerobugs is
 still vaporware?


 
 I did a quick test, and zerobugs has at least some D support. Types
 seems to be correctly demangled in the variables view, whereas functions
 and method names in the stack trace are not. I wasn't immediately able
 to pinpoint the location of my segfault though (a real one that I knew
 of), although the stacktrace showed up. Definately better looking than
 gdb, all in all :)



Yes, just recently I've been experimenting with zerobugs.  It was much 
easier to use with D than the other linux debuggers since D symbols are 
demangled. The stacktrace does kind of show the general position of the 
segfault also.  I like the way it opens any associated shared libraries 
and shows the disassembly in a new tab as you step into the function 
calls.

One frustration is that char[] still are represented as a length and 
pointer, thus you don't get to see the text object associated with it. 
But even then, sometimes you can see it by expanding the related tree for 
the ptr object.

-JJR
Dec 26 2007
parent reply Cristian Vlasceanu <cristian zerobugs.org> writes:
John Reimer wrote:

 On Wed, 26 Dec 2007 10:33:40 +0100, Lars Ivar Igesund wrote:
 

 Bill Baxter wrote:

 If you're not on Windows then I presume gdb works?  I guess that
 doesn't have any D-specific knowledge.  Support for D in zerobugs is
 still vaporware?






The debugger cannot help much when the debug information produced by the 
compiler is not 100% accurate.


 I did a quick test, and zerobugs has at least some D support. Types
 seems to be correctly demangled in the variables view, whereas functions
 and method names in the stack trace are not. I wasn't immediately able
 to pinpoint the location of my segfault though (a real one that I knew
 of), although the stacktrace showed up. Definately better looking than
 gdb, all in all :)


  


An outline of how ZeroBUGS handles stack unwinding: if there is DWARF 
information present, then look for frame-unwinding information. 
Otherwise, assume the System V ABI for the i386 and PowerPC and Itanium 
ABI for X86_64.

Again, do not blame the debugger for what the compiler does not produce.

Unless you have a 100% accurate stack trace from another debugger for 
the same executable and platform, in which case I do beg you to send me 
a bug report.



 Yes, just recently I've been experimenting with zerobugs.  It was much 
 easier to use with D than the other linux debuggers since D symbols are 
 demangled. 


I use a very slightly modified version of Thomas Kuehne's demangler 
(basically I added a function to show his copyright when I display the 
About window, and tweaked the config.h). It is built as a shared object 
so  you are free to tinker with it, the code is here: 
http://www.zerobugs.org/demangle_d.tgz




 The stacktrace does kind of show the general position of the 
 segfault also.  I like the way it opens any associated shared libraries 
 and shows the disassembly in a new tab as you step into the function 
 calls.
 
 One frustration is that char[] still are represented as a length and 
 pointer, thus you don't get to see the text object associated with it. 
 But even then, sometimes you can see it by expanding the related tree for 
 the ptr object.
 


Do you have an associative array of chars, or just char[]? Associative 
arrays do not work yet (it is coming though, I promise), but char[] 
should work I just tried it today with dmd 2.0, see snapshot here: 
http://zero-bugs.com/zero-char.png

Best Regards and a Happy new Year();
  Cristian
Dec 26 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Cristian Vlasceanu wrote:


 An outline of how ZeroBUGS handles stack unwinding: if there is DWARF 
 information present, then look for frame-unwinding information. 
 Otherwise, assume the System V ABI for the i386 and PowerPC and Itanium 
 ABI for X86_64.
 
 Again, do not blame the debugger for what the compiler does not produce.


I hope you have filed bugs in bugzilla about which information the 
compiler is not generating.

--bb
Dec 26 2007
parent Cristian Vlasceanu <cristian zerobugs.org> writes:
Bill Baxter wrote:

 Cristian Vlasceanu wrote:
 

 An outline of how ZeroBUGS handles stack unwinding: if there is DWARF 
 information present, then look for frame-unwinding information. 
 Otherwise, assume the System V ABI for the i386 and PowerPC and 
 Itanium ABI for X86_64.

 Again, do not blame the debugger for what the compiler does not produce.


 
 I hope you have filed bugs in bugzilla about which information the 
 compiler is not generating.
 
 --bb
 


You mean issues like this one, for example:
http://d.puremagic.com/issues/show_bug.cgi?id=136

They never get addressed, so what's the point? I have limited resources 
so I am picking my fights.

But I hope that once Walter, Andrei and Company get their philosophical 
issues on const and unsigned settled, someone will have a weekend or two 
to spare on making the backend better.

Meanwhile I am enjoying my vacation in the Columbia Gorge ;)
Dec 26 2007
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Cristian Vlasceanu wrote:

 John Reimer wrote:

 On Wed, 26 Dec 2007 10:33:40 +0100, Lars Ivar Igesund wrote:


 Bill Baxter wrote:

 If you're not on Windows then I presume gdb works?  I guess that
 doesn't have any D-specific knowledge.  Support for D in zerobugs is
 still vaporware?






 The debugger cannot help much when the debug information produced by the 
 compiler is not 100% accurate.
 

 I did a quick test, and zerobugs has at least some D support. Types
 seems to be correctly demangled in the variables view, whereas functions
 and method names in the stack trace are not. I wasn't immediately able
 to pinpoint the location of my segfault though (a real one that I knew
 of), although the stacktrace showed up. Definately better looking than
 gdb, all in all :)


  


 
 An outline of how ZeroBUGS handles stack unwinding: if there is DWARF 
 information present, then look for frame-unwinding information. 
 Otherwise, assume the System V ABI for the i386 and PowerPC and Itanium 
 ABI for X86_64.
 
 Again, do not blame the debugger for what the compiler does not produce.
 
 Unless you have a 100% accurate stack trace from another debugger for 
 the same executable and platform, in which case I do beg you to send me 
 a bug report.
 
 

 Yes, just recently I've been experimenting with zerobugs.  It was much 
 easier to use with D than the other linux debuggers since D symbols 
 are demangled. 


 
 I use a very slightly modified version of Thomas Kuehne's demangler 
 (basically I added a function to show his copyright when I display the 
 About window, and tweaked the config.h). It is built as a shared object 
 so  you are free to tinker with it, the code is here: 
 http://www.zerobugs.org/demangle_d.tgz
 
 
 

 The stacktrace does kind of show the general position of the segfault 
 also.  I like the way it opens any associated shared libraries and 
 shows the disassembly in a new tab as you step into the function calls.

 One frustration is that char[] still are represented as a length and 
 pointer, thus you don't get to see the text object associated with it. 
 But even then, sometimes you can see it by expanding the related tree 
 for the ptr object.


 Do you have an associative array of chars, or just char[]? Associative 
 arrays do not work yet (it is coming though, I promise), but char[] 
 should work I just tried it today with dmd 2.0, see snapshot here: 
 http://zero-bugs.com/zero-char.png
 
 Best Regards and a Happy new Year();
  Cristian


The arrays are not associative.  They are char[][] from the main 
argument list.  I'm not sure why they weren't working.  Maybe I have an 
older version?  I'll have a look.

You've done great work with zerobugs, Christian.  Thanks for the 
contribution, despite the odds. :o)

-JJR
Dec 26 2007
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Bill Baxter wrote:

 ddbg does a pretty decent job on Windows.  Still, it gives me no stack 
 trace upon "access violation" a significant fraction of the time.  When 
 it works it's great, though.  You should definitely be using it if 
 you're on Windows.  I have also found that Windbg can sometimes get a 
 stack trace when ddbg can't.
 
 If you're not on Windows then I presume gdb works?  I guess that doesn't 
 have any D-specific knowledge.  Support for D in zerobugs is still 
 vaporware?
 
 Still, I'm with you.  Getting a stack trace should be easier. Especially 
 considering there have been patches to phobos floating around for a year 
 at least that already implement it.
 
 --bb


So, given traced exceptions, you trap the sigsegv with a function that 
throws an exception? And you'd put the stuff to catch the signal in a 
module constructor so you just have to import the segfault exception module.

I just did it in the past half hour; it's not much trouble. There's just 
a portability concern. But since DMD only works on Windows and Linux, 
that's less of a concern.

As a side note, Phobos doesn't seem to have anything related to signals, 
and Tango's translation of the header is quite brief, not including 
anything to trap signals.

And now I see a post about two years old with the same stuff, only better.
Dec 26 2007
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Bill Baxter Wrote:

 If you're not on Windows then I presume gdb works?  I guess that doesn't 
 have any D-specific knowledge.  Support for D in zerobugs is still 
 vaporware?


It looks like it's going that way.  Looking at the zerobugs FAQ, I see:

 Does Zero work with other languages than C/C++?
    A: I have not tested it with other languages. However, the debug
information in STABS and DWARF is language-independent.
The only language-dependent part in Zero is the interpreter which can only
evaluate C++ expressions.

I have started some preliminary work to support Walter Bright's D Programming
Language, and a D demangler has been contributed by the D community. However,
this work is in an experimental stage.
Dec 26 2007
parent John Reimer <terminal.node gmail.com> writes:
Jason House wrote:

 Bill Baxter Wrote:

 If you're not on Windows then I presume gdb works?  I guess that doesn't 
 have any D-specific knowledge.  Support for D in zerobugs is still 
 vaporware?


 
 It looks like it's going that way.  Looking at the zerobugs FAQ, I see:
 
  Does Zero work with other languages than C/C++?
     A: I have not tested it with other languages. However, the debug
information in STABS and DWARF is language-independent.
 The only language-dependent part in Zero is the interpreter which can only
evaluate C++ expressions.
 
 I have started some preliminary work to support Walter Bright's D Programming
Language, and a D demangler has been contributed by the D community. However,
this work is in an experimental stage. 



I guess the fact that the author answered these very posts says otherwise?
Dec 26 2007
prev sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
Bill Baxter wrote:

 ddbg does a pretty decent job on Windows.  Still, it gives me no stack 
 trace upon "access violation" a significant fraction of the time.


a good chunk of which was caused by a bug introduced in 0.11 that is 
fixed now in 0.11.2.


  When 
 it works it's great, though.  You should definitely be using it if 
 you're on Windows.  I have also found that Windbg can sometimes get a 
 stack trace when ddbg can't.


always feel free to drop test-cases in my mailbox, if possible ;)
Dec 26 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jascha Wetzel wrote:

 Bill Baxter wrote:

 ddbg does a pretty decent job on Windows.  Still, it gives me no stack 
 trace upon "access violation" a significant fraction of the time.


 
 a good chunk of which was caused by a bug introduced in 0.11 that is 
 fixed now in 0.11.2.


You gotta announce these things!

Thanks to 0.11.2 I was at last able to track down a tricky null 
dereference that was only happening sporadically.  With 0.11.1 I was 
getting zilch from the debugger.

Thanks!

--bb
Dec 29 2007
parent BCS <ao pathlink.com> writes:
Reply to Bill,


 Jascha Wetzel wrote:
 

 Bill Baxter wrote:
 

 ddbg does a pretty decent job on Windows.  Still, it gives me no
 stack trace upon "access violation" a significant fraction of the
 time.
 


 a good chunk of which was caused by a bug introduced in 0.11 that is
 fixed now in 0.11.2.
 


 You gotta announce these things!
 
 Thanks to 0.11.2 I was at last able to track down a tricky null
 dereference that was only happening sporadically.  With 0.11.1 I was
 getting zilch from the debugger.
 
 Thanks!
 
 --bb
 


Put the ___ thing in SVN (the .exe if nothing else). I have about a dozen 
repos I download on a regular basis, I'd almost bet I wouldn't be the only 
one who would benefit.
Dec 30 2007
prev sibling parent Frank Benoit <keinfarbton googlemail.com> writes:
Robby schrieb:

 4.) SWT. Yeah, *that* SWT.


News on this?
I sent you an email.

Frank
Dec 26 2007