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.

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.

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>

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 next 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 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 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?



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.
 

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

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?



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.

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.
 

fixed now in 0.11.2.

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