www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tim Sweeney on Next Programming Language

reply Mike Parker <aldacron71 yahoo.com> writes:
Tim Sweeney of Epic Games recently gave a talk at POPL'06 titled "The 
Next Mainstream Programming Language: A Game Developer's Perspective". 
Using Epic's Unreal Engine 3 as an example, he goes through several 
limiting and costly issues with C++ and other current mainstream 
languages, then moves on to what he wants to do before closing with 
features he thinks the next mainstream language should have. If you 
aren't so interested in what he says about language features, it's 
interesting enough reading the insights he gives to the Unreal Engine.

http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
Feb 05 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message 
news:ds6bbn$1tp3$1 digitaldaemon.com...
 Tim Sweeney of Epic Games recently gave a talk at POPL'06 titled "The Next 
 Mainstream Programming Language: A Game Developer's Perspective". Using 
 Epic's Unreal Engine 3 as an example, he goes through several limiting and 
 costly issues with C++ and other current mainstream languages, then moves 
 on to what he wants to do before closing with features he thinks the next 
 mainstream language should have. If you aren't so interested in what he 
 says about language features, it's interesting enough reading the insights 
 he gives to the Unreal Engine.

 http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

Interesting how he comments time and time again how much he'd like null pointer dereferencing to be checked.. funny, last time I brought that up, Walter shot it down, since after all, access violations are more than enough! Right guys? Right?
Feb 05 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:ds6oia$26g5$1 digitaldaemon.com...
 Interesting how he comments time and time again how much he'd like null 
 pointer dereferencing to be checked.. funny, last time I brought that up, 
 Walter shot it down, since after all, access violations are more than 
 enough!  Right guys?  Right?

I looked for his email address, but couldn't find it. I'd ask him how checking for null pointers in software before dereferencing would result in fewer bugs than having the hardware check it automatically. Because it won't: assert(p != null); p[3] = 2; is not one whit more robust than: p[3] = 2; The bug is not dereferencing a null pointer, it is why that pointer is null in the first place. Often, pointers are null because: 1) uninitialized data (he mentions that this is a big source of problems) 2) often, functions return NULL when they fail rather than throw an exception (like malloc() does)
Feb 05 2006
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 6 Feb 2006 01:00:03 -0500, Jarrett Billingsley wrote:

 "Mike Parker" <aldacron71 yahoo.com> wrote in message 
 news:ds6bbn$1tp3$1 digitaldaemon.com...
 Tim Sweeney of Epic Games recently gave a talk at POPL'06 titled "The Next 
 Mainstream Programming Language: A Game Developer's Perspective". Using 
 Epic's Unreal Engine 3 as an example, he goes through several limiting and 
 costly issues with C++ and other current mainstream languages, then moves 
 on to what he wants to do before closing with features he thinks the next 
 mainstream language should have. If you aren't so interested in what he 
 says about language features, it's interesting enough reading the insights 
 he gives to the Unreal Engine.

 http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

Interesting how he comments time and time again how much he'd like null pointer dereferencing to be checked.. funny, last time I brought that up, Walter shot it down, since after all, access violations are more than enough! Right guys? Right?

I understood that this argument went something like ... One can have null pointers checked by the compiler, by software at run time, or by hardware at run time. The first is not always going to work (to find all cases), the second is (can be) a performance hit and is susceptible to compiler bugs, and the third is the fastest and always works (on modern CPU's anyway). So with the current D, one does get null pointer dereference checking; its just that it looks like an access violation instead. So maybe we can plead, cajole, whatever to make Walter give us a more meaningful message when an access violation is the result of a NULL pointer (file name and line number would be a bloody big help too). -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 6/02/2006 5:55:26 PM
Feb 05 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...
 So with the current D, one does get null pointer dereference checking; its
 just that it looks like an access violation instead. So maybe we can 
 plead,
 cajole, whatever to make Walter give us a more meaningful message when an
 access violation is the result of a NULL pointer (file name and line 
 number
 would be a bloody big help too).

Compile with -g, and run it under the debugger. When the access violation happens, the debugger gives you the location of the fault, as well as a call stack trace. It works even better than just a null check, it checks for any pointer value that falls outside of address space allocated to the process.
Feb 05 2006
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 5 Feb 2006 23:56:37 -0800, Walter Bright wrote:

 
 Compile with -g, and run it under the debugger. When the access violation 
 happens, the debugger gives you the location of the fault, as well as a call 
 stack trace.

I just *knew* you were going to say that <G> For those that need to know about this in Windows environments... You can get the Microsoft debugger from http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.6.03.5.exe And once you install it, compile your D program with the -g switch. To get it running under the debugger ... windbg mytest.exe then press F5 till it stops running ... then look at the register values and the assembly instruction to see what might be wrong. Easy eh? So you thought you only had to learn D --- silly you. A good knowledge of assembler is useful when using the debugger properly. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 6/02/2006 8:12:33 PM
Feb 06 2006
next sibling parent "Todor Totev" <umbra.tenebris list.ru> writes:
On Mon, 06 Feb 2006 11:16:36 +0200, Derek Parnell <derek psych.ward> wro=
te:

 On Sun, 5 Feb 2006 23:56:37 -0800, Walter Bright wrote:

 Compile with -g, and run it under the debugger. When the access  =


 violation
 happens, the debugger gives you the location of the fault, as well as=


 call
 stack trace.

I just *knew* you were going to say that <G> For those that need to know about this in Windows environments... You can get the Microsoft debugger from http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.6.03.5.=

 And once you install it, compile your D program with the -g switch.

 To get it running under the debugger ...

   windbg mytest.exe

 then press F5 till it stops running ... then look at the register valu=

 and the assembly instruction to see what might be wrong. Easy eh? So y=

 thought you only had to learn D --- silly you. A good knowledge of
 assembler is useful when using the debugger properly.

The standart answer Walter gives to that is "Microsoft's newer windbg's seem to have dropped support for codeview debug info. But the one that = comes on the Digital Mars CD *does* work." Anyway you can try this one: http://www.cs.nmt.edu/~cs221/jbpub/Detmer/Software/ Just download the exe & the dll files. Of course, that version does NOT work with obj files compiled with curre= nt = dmc so if you are trying to bridge C or even worse C++ code with D you are o= ut = of luck but see above. Another advice I receive is to use GDB but I really prefer to postpone m= y = serious usage of D that to come near that beast. Cheers, Todor
Feb 06 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1h25tvba9ut64.jgems5c0705k$.dlg 40tude.net...
 then press F5 till it stops running ... then look at the register values
 and the assembly instruction to see what might be wrong. Easy eh? So you
 thought you only had to learn D --- silly you. A good knowledge of
 assembler is useful when using the debugger properly.

When I run it under windbg, it pops up a window with the offending source line of code in context highlighted. gdb will display the source line, too. You can, of course, switch to an assembler view, but that isn't necessary.
Feb 06 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Tue, 07 Feb 2006 05:03:28 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:1h25tvba9ut64.jgems5c0705k$.dlg 40tude.net...
 then press F5 till it stops running ... then look at the register values
 and the assembly instruction to see what might be wrong. Easy eh? So you
 thought you only had to learn D --- silly you. A good knowledge of
 assembler is useful when using the debugger properly.

When I run it under windbg, it pops up a window with the offending source line of code in context highlighted. gdb will display the source line, too. You can, of course, switch to an assembler view, but that isn't necessary.

Yes, I can see now that we should use a debugger because there cannot be any other alternative. No one would be capable of writing a compiler to issue an helpful message in this situation. -- Derek Parnell Melbourne, Australia
Feb 06 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds70qm$2d28$1 digitaldaemon.com...
 Compile with -g, and run it under the debugger. When the access violation 
 happens, the debugger gives you the location of the fault, as well as a 
 call stack trace.

Yeah, that'd be fantastic if the break didn't always happen in the middle of NTDLL. And if the stack trace actually worked properly, which it doesn't, making it nearly impossible to find where the AV occurred. (VS6)
 The bug is not dereferencing a null pointer, it is why that pointer is 
 null
 in the first place. Often, pointers are null because:

 1) uninitialized data (he mentions that this is a big source of problems)

 2) often, functions return NULL when they fail rather than throw an
 exception (like malloc() does)

In D, neither of these really apply. All variables are initialized (including references to NULL, hint hint), and when functions fail, they throw an exception. So it's very easy to get a null pointer - just forget to initialize a reference, and then try to access one of its members. Or perhaps delete a reference (which, again, sets it to null) and try to access it. Fun fact: I've yet to have an access violation in D that _wasn't_ because of a null reference. And I've had quite a few.
Feb 06 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:ds7k3v$2ul7$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ds70qm$2d28$1 digitaldaemon.com...
 Compile with -g, and run it under the debugger. When the access violation 
 happens, the debugger gives you the location of the fault, as well as a 
 call stack trace.

Yeah, that'd be fantastic if the break didn't always happen in the middle of NTDLL. And if the stack trace actually worked properly, which it doesn't, making it nearly impossible to find where the AV occurred. (VS6)

For the stack trace to work properly, it must be compiled with -g. Otherwise, stack frames are omitted from the code generation.
Feb 06 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds83p5$bmf$2 digitaldaemon.com...
 For the stack trace to work properly, it must be compiled with -g. 
 Otherwise, stack frames are omitted from the code generation.

No kidding. Compiling without -g doesn't allow you to debug the program, period (unless you call stepping through unnamed assembly routines "debugging"). In VS6 (which uses WinDbg), the call stack view always gets messed up when debugging D programs - functions do not seem to stay on the stack. They just get overwritten. You also have a knack for responding to everything _but_ the most important part of a message.
Feb 06 2006
prev sibling next sibling parent reply "Charles" <noone nowhere.com> writes:
 Compile with -g, and run it under the debugger. When the access violation
 happens, the debugger gives you the location of the fault, as well as a

 stack trace.

Ummmm... What debugger, the 15 yeard old windbg that comes on the CD that you have to purchase ? Debugging D has become extremely painful , all these great new age techniques to speed productivity, then it takes 5 - 6 hours to setup an assembly level debugger , then a few years to learn assembly , and your ready to use D! The other access voilations throw line number and file, why this inconsitency ? "Walter Bright" <newshound digitalmars.com> wrote in message news:ds70qm$2d28$1 digitaldaemon.com...
 "Derek Parnell" <derek psych.ward> wrote in message
 news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...
 So with the current D, one does get null pointer dereference checking;


 just that it looks like an access violation instead. So maybe we can
 plead,
 cajole, whatever to make Walter give us a more meaningful message when


 access violation is the result of a NULL pointer (file name and line
 number
 would be a bloody big help too).

Compile with -g, and run it under the debugger. When the access violation happens, the debugger gives you the location of the fault, as well as a

 stack trace.

 It works even better than just a null check, it checks for any pointer

 that falls outside of address space allocated to the process.

Feb 06 2006
parent reply "Charles" <noone nowhere.com> writes:
Actually the debugger that comes with the IDE is pretty nice once you get
used to it , but for me it would still be 100 times better if we got line
number and file names with all exceptions, I dont see how this could hurt
anything -- only help.

Charlie


"Charles" <noone nowhere.com> wrote in message
news:ds7o54$121$1 digitaldaemon.com...
 Compile with -g, and run it under the debugger. When the access


 happens, the debugger gives you the location of the fault, as well as a

 stack trace.

Ummmm... What debugger, the 15 yeard old windbg that comes on the CD that you have to purchase ? Debugging D has become extremely painful , all

 great new age techniques to speed productivity, then it takes 5 - 6 hours

 setup an assembly level debugger , then a few years to learn assembly ,

 your ready to use D!

 The other access voilations throw line number and file, why this
 inconsitency ?


 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:ds70qm$2d28$1 digitaldaemon.com...
 "Derek Parnell" <derek psych.ward> wrote in message
 news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...
 So with the current D, one does get null pointer dereference checking;


 just that it looks like an access violation instead. So maybe we can
 plead,
 cajole, whatever to make Walter give us a more meaningful message when


 access violation is the result of a NULL pointer (file name and line
 number
 would be a bloody big help too).

Compile with -g, and run it under the debugger. When the access


 happens, the debugger gives you the location of the fault, as well as a

 stack trace.

 It works even better than just a null check, it checks for any pointer

 that falls outside of address space allocated to the process.


Feb 06 2006
parent reply Sebastián E. Peyrott <as7cf yahoo.com> writes:
I think Sweeney does make some valid points in his presentation, especially
regarding the future of computingthat seems to involve concurrency as it's main
paradigm. I'm a noob when it comes to those matters, so what should we expect
from D running on 20-core massively multithreaded systems?
He mentions manual synchronization (which I believe is what D provides, correct
me if wrong) as a problem in gameplay simulation (slide 49), what would the
solution be fot D?
Also, some of those Haskell concepts he mentions are interesting, I shall study
how they work.

[OT]Oh, I can envision a bright future where D is nearing v2.0 and Unreal Engine
4 is written completely in D...oh, yes, such a nice future.

--Sebastián
Feb 06 2006
parent Sean Kelly <sean f4.ca> writes:
Sebastián E. Peyrott wrote:
 I think Sweeney does make some valid points in his presentation, especially
 regarding the future of computingthat seems to involve concurrency as it's main
 paradigm. I'm a noob when it comes to those matters, so what should we expect
 from D running on 20-core massively multithreaded systems?
 He mentions manual synchronization (which I believe is what D provides, correct
 me if wrong) as a problem in gameplay simulation (slide 49), what would the
 solution be fot D?

The same at the moment. The "atomic" parallelized functions he describes could be accomplished pretty easily--I have a class to handle this manually in C++ (which I suppose should be ported to D). However, such parallelization requires the use of a semaphore, event, or condition variable to signal the work thread, so it really isn't worthwhile for very small tasks. Memory synchronization when the task is complete is another issue, though the x86 memory model generally handles this automatically (not so for PPC or for other architectures). I think he's right that transactional memory is likely the way things are going, but that has overhead issues as well. The original proposal required all memory involved in the transaction to be held in the CPU cache, which requires the transaction to be very small, and imposes architecture-dependent constraints on software design. A later proposal by the same people introduced the idea of virtual transactional memory which removes the CPU cache constraint in much the way that virtual memory support does for physical memory limitations. This is likely ideal, but as both of these proposals require hardware changes, it may be a while before anything happens here--from what I've heard, the hardware folks are waiting for the theory to mature a bit before investing in it. There have also been a bunch of all-software transactional designs that work by keeping multiple copies of objects around and messing with pointers to "commit" changes when the transaction is complete. The only drawback to this method is that the multiple copies it requires incurs memory overhead, and cloning objects can be expensive. However, this is something that's available now--there is a C# version available that works automatically (from what I understand, the C# compiler can be somehow extended in some ways?). Sean
Feb 06 2006
prev sibling next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 5 Feb 2006 23:56:37 -0800, Walter Bright  
<newshound digitalmars.com> wrote:
 "Derek Parnell" <derek psych.ward> wrote in message
 news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...
 So with the current D, one does get null pointer dereference checking;  
 its
 just that it looks like an access violation instead. So maybe we can
 plead,
 cajole, whatever to make Walter give us a more meaningful message when  
 an
 access violation is the result of a NULL pointer (file name and line
 number
 would be a bloody big help too).

Compile with -g, and run it under the debugger. When the access violation happens, the debugger gives you the location of the fault, as well as a call stack trace. It works even better than just a null check, it checks for any pointer value that falls outside of address space allocated to the process.

Customers/Clients can/will not run our programs in a debugger. Intermittent/situational faults often cannot be reliably reproduced in a debugger at a later stage. We need a way to reliably produce: - [at least] a file and line number for the fault. - [at best] a complete stack trace. - [dream] a snapshot of the running state which we can re-execute at a later stage in a debugger. To guarantee a piece of software is without fault is very hard (impossible?). To guarantee you will fix any such fault in a short space of time is much easier, the above will make that even easier still. A large percentage of the code in the software I currently work on is there to guarantee that we can find and fix faults. We have memory tracking, handle tracking, deadlock detection, stack trace generation, a monitor process to restart the main process, etc. When I was working on CGI applications I had my code store all it's input in a file. This file could be used at a later stage to reproduce that request. It made debugging reported faults trivial. Regan
Feb 06 2006
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Walter,

My primary work is web-related software.  For example, I might write 
software that is loaded into Apache as a shared library.  My library 
might be threaded, and handle multiple requests at once.  This is just 
an example.

If my library segfaults, or gets an access violation, or whatever... 
Apache dies.  Say goodbye to my program, and possibly my job if it 
results in a lot of downtime.  Boy, that's a dangerous thing, those 
"useful access violations"...

Luckily, I haven't had that many run-ins with this problem.  Still, if 
it were to happen, I would most certainly want an exception thrown - I 
had thought - which could then be caught, and handled gracefully (read: 
show the user a 500 Internal Server Error message, not die and give them 
nothing.)  After all, a null pointer doesn't necessarily mean the server 
blew up.  Maybe it could even send me an email to set me straight.

However, I do believe you have significantly more experience than I do 
as it comes to compilers and programming.  What should I do, excepting 
"never dereference null pointers" (which I already mean to do, I want a 
backup plan.)

I do realize that Apache could be changed to more gracefully handle 
this; for example, Firefox detects access violations caused by plugins 
such as Flash and Java, and gives you an error message suggesting you 
restart as soon as possible.  However, this is out of scope; I cannot 
change Apache.

I also realize that if a pointer is actually invalid (which is one thing 
forced initialization is there to avoid) this won't save me, but alas 
you cannot have it all.

Thanks,
-[Unknown]


 "Derek Parnell" <derek psych.ward> wrote in message 
 news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...
 So with the current D, one does get null pointer dereference checking; its
 just that it looks like an access violation instead. So maybe we can 
 plead,
 cajole, whatever to make Walter give us a more meaningful message when an
 access violation is the result of a NULL pointer (file name and line 
 number
 would be a bloody big help too).

Compile with -g, and run it under the debugger. When the access violation happens, the debugger gives you the location of the fault, as well as a call stack trace. It works even better than just a null check, it checks for any pointer value that falls outside of address space allocated to the process.

Feb 06 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:ds9e1j$1dpu$1 digitaldaemon.com...
 However, I do believe you have significantly more experience than I do as 
 it comes to compilers and programming.  What should I do, excepting "never 
 dereference null pointers" (which I already mean to do, I want a backup 
 plan.)

Under Linux, you can set up a signal handler to intercept the seg faults, and use it to shut down your plug in gracefully.
Feb 07 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Walter,

I am aware of that ability, but the missing link for me is that I don't 
know how to unwind the stack from the signal handler.

In other words, consider a case where I am eight function calls deep 
into the program, and a problem occurs.  I want to send a 500 error 
message to the client.  To do this, I need to get back to the main 
function, so I can return to Apache and Apache can be happy.  I don't 
know how to do this other than by an exception.

I suppose... I could throw an exception in the signal handler.  This 
thought does not seem like one that might be completely assured to work, 
however.  Would it?

Thanks again,
-[Unknown]


 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
 news:ds9e1j$1dpu$1 digitaldaemon.com...
 However, I do believe you have significantly more experience than I do as 
 it comes to compilers and programming.  What should I do, excepting "never 
 dereference null pointers" (which I already mean to do, I want a backup 
 plan.)

Under Linux, you can set up a signal handler to intercept the seg faults, and use it to shut down your plug in gracefully.

Feb 07 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Unknown W. Brackets wrote:
 Walter,
 
 I am aware of that ability, but the missing link for me is that I don't 
 know how to unwind the stack from the signal handler.
 
 In other words, consider a case where I am eight function calls deep 
 into the program, and a problem occurs.  I want to send a 500 error 
 message to the client.  To do this, I need to get back to the main 
 function, so I can return to Apache and Apache can be happy.  I don't 
 know how to do this other than by an exception.
 
 I suppose... I could throw an exception in the signal handler.  This 
 thought does not seem like one that might be completely assured to work, 
 however.  Would it?

I don't think this is legal. Signal handlers have fairly tight restrictions on what's allowed. The pragmatic approach might simply be to use a proxy program that in turn calls the main program. If that program aborts or fails to return the correct data then the proxy program can report a "500" error to the client and restart the target app if appropriate. Since the code in such proxy apps is exceedingly simple, the chance of it crashing is pretty much nil. I consider this almost a required technique for 100% uptime services. Sean
Feb 07 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:dsadrj$2ac0$1 digitaldaemon.com...
 I am aware of that ability, but the missing link for me is that I don't 
 know how to unwind the stack from the signal handler.

 In other words, consider a case where I am eight function calls deep into 
 the program, and a problem occurs.  I want to send a 500 error message to 
 the client.  To do this, I need to get back to the main function, so I can 
 return to Apache and Apache can be happy.  I don't know how to do this 
 other than by an exception.

 I suppose... I could throw an exception in the signal handler.  This 
 thought does not seem like one that might be completely assured to work, 
 however.  Would it?

I am less familiar with how signals work on Linux than I ought to be. It should work - as long as the signal is on the same thread.
Feb 07 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Unknown W. Brackets wrote:
 
 If my library segfaults, or gets an access violation, or whatever... 
 Apache dies.  Say goodbye to my program, and possibly my job if it 
 results in a lot of downtime.  Boy, that's a dangerous thing, those 
 "useful access violations"...
 
 Luckily, I haven't had that many run-ins with this problem.  Still, if 
 it were to happen, I would most certainly want an exception thrown - I 
 had thought - which could then be caught, and handled gracefully (read: 
 show the user a 500 Internal Server Error message, not die and give them 
 nothing.)  After all, a null pointer doesn't necessarily mean the server 
 blew up.  Maybe it could even send me an email to set me straight.
 

But in D, the Access Violations are Exceptions, and you can catch them. This post had made me think otherwise, when I first read it, but today I checked it. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 09 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:

 But in D, the Access Violations are Exceptions, and you can catch them. 

On Windows, that is... --anders
Feb 09 2006
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
(on which you'd generally not run a webserver.)

-[Unknown]


 Bruno Medeiros wrote:
 
 But in D, the Access Violations are Exceptions, and you can catch them. 

On Windows, that is... --anders

Feb 13 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Derek Parnell wrote:
 
 So with the current D, one does get null pointer dereference checking; its
 just that it looks like an access violation instead. So maybe we can plead,
 cajole, whatever to make Walter give us a more meaningful message when an
 access violation is the result of a NULL pointer (file name and line number
 would be a bloody big help too).
 

form of throwing an exception, as was also was noted. Implementing this (throwing an exception) should be simple enough, just modify some code in the access violation handler. But showing the line number on a violation I'm not sure it's that easy. The exception handler would have to have some very complicated debugger-like code, no? These are all suppositions as I'm not very knowledgeable in this, so explain to me, if I'm wrong. I wonder how that other fellow (shinichiro) implemented the stack trace. Does it show only the called functions, or line nunmbers too, ŕ la Java? -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 08 2006
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Bruno Medeiros wrote:
 Derek Parnell wrote:
 
 So with the current D, one does get null pointer dereference checking; 
 its
 just that it looks like an access violation instead. So maybe we can 
 plead,
 cajole, whatever to make Walter give us a more meaningful message when an
 access violation is the result of a NULL pointer (file name and line 
 number
 would be a bloody big help too).

form of throwing an exception, as was also was noted. Implementing this (throwing an exception) should be simple enough, just modify some code in the access violation handler. But showing the line number on a violation I'm not sure it's that easy. The exception handler would have to have some very complicated debugger-like code, no? These are all suppositions as I'm not very knowledgeable in this, so explain to me, if I'm wrong. I wonder how that other fellow (shinichiro) implemented the stack trace. Does it show only the called functions, or line nunmbers too, ŕ la Java?

Has anyone bothered to look at the code in deh.c in phobos? It's all right there. Bruno is correct - the Access Violation is a D exception that was translated from a Windows SEH. In order for the Windows SEH to know about D source code lines we'd have to modify it, and I don't see that happening any time soon. There is a solution that I can see: Assumptions: * We have the memory address in D code at which the access violation occurred. * We know which executable the access violation occurred in. (look it up by the memory address ranges for all DLLs/EXEs loaded by the application) * We can read the CV debugging information from the executable directly. (DDL can certainly provide support here - does it support reading CV information?) (Would this read be from within memory or from the executable file itself? I'm not sure if CV information is copied into memory...) Following that, it is a simple matter of looking up the code address (possibly after some translation) and retrieving the filename and line number. Then, the Exception class should be modified to account for this extra information (if it does not already), or perhaps simply encode it within the Exception's message string. However, this is largely dependent on implementation details. We know that Digital Mars makes use of CodeView (CV) debugging information and this is also a Windows-specific modification. Similar work can be done for Linux. Of course this is all a hefty price tag for such a useful feature. Is it worth it? -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++ ------END GEEK CODE BLOCK------ James Dunne
Feb 08 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message 
news:dsd2bk$1nlm$1 digitaldaemon.com...
 Of course this is all a hefty price tag for such a useful feature.  Is it 
 worth it?

Or, like I suggested before, insert an implicit assert(objReference !is null) Before dereferencing any object references. The compiler already does something like this for array bounds checking. And like array bounds checking, this could be turned on or off.
Feb 08 2006
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Jarrett Billingsley wrote:
 "James Dunne" <james.jdunne gmail.com> wrote in message 
 news:dsd2bk$1nlm$1 digitaldaemon.com...
 
Of course this is all a hefty price tag for such a useful feature.  Is it 
worth it?

Or, like I suggested before, insert an implicit assert(objReference !is null) Before dereferencing any object references. The compiler already does something like this for array bounds checking. And like array bounds checking, this could be turned on or off.

Why not just use the Phobos hack ? -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y ------END GEEK CODE BLOCK------ Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Feb 08 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Tom S" <h3r3tic remove.mat.uni.torun.pl> wrote in message 
news:dsdo9a$293t$1 digitaldaemon.com...
 Why not just use the Phobos hack ?

You're right. I forgot that it checks for all kinds of access violations. What a wonderful hack :)
Feb 08 2006
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Bruno Medeiros wrote:
 I wonder how that other fellow (shinichiro) implemented the stack trace. 
 Does it show only the called functions, or line nunmbers too, ŕ la Java?

It displays both, e.g. Unhandled win32 exception! backtrace: 00402055 _Dmain (+9) console_main.d:19 0040235f main (+77) 00412b35 mainCRTStartup (+a9) 7c816d4f ??? And it acually is a stack trace for a simple program which uses null pointers... -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y ------END GEEK CODE BLOCK------ Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Feb 08 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dscnvs$1eb4$1 digitaldaemon.com...
 I wonder how that other fellow (shinichiro) implemented the stack trace.

I took a brief look at it. What he did was intercept the exception generated by the operating system, then used the Microsoft debug interface to read the debug data in the executable to associate a file/line number with it. It is the same thing that a debugger does, and so it relies on the executable being compiled with -g (full debug info). To implement this requires a pretty advanced technical knowledge of how Windows SEH works, and shinichiro deserves a lot of respect for figuring this out, since it's mostly undocumented. The code is highly Windows dependent, and none of it is useful under Linux. But the equivalent could presumably be done on Linux given someone who knows how debuggers work under Linux.
Feb 08 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Bruno Medeiros wrote:
 Derek Parnell wrote:
 So with the current D, one does get null pointer dereference checking;
 its
 just that it looks like an access violation instead. So maybe we can
 plead,
 cajole, whatever to make Walter give us a more meaningful message 


 access violation is the result of a NULL pointer (file name and line
 number
 would be a bloody big help too).

form of throwing an exception, as was also was noted.

This is in error. Under Unknown W. Brackets assumption I thought that access violations didn't throw Exceptions but they do. Someone should have corrected us. Walter Bright wrote:
 "Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
 news:dscnvs$1eb4$1 digitaldaemon.com...
 I wonder how that other fellow (shinichiro) implemented the stack trace.

I took a brief look at it. What he did was intercept the exception generated by the operating system, then used the Microsoft debug interface to read the debug data in the executable to associate a file/line number with it. It is the same thing that a debugger does, and so it relies on the executable being compiled with -g (full debug info). To implement this requires a pretty advanced technical knowledge of how Windows SEH works, and shinichiro deserves a lot of respect for figuring this out, since it's mostly undocumented. The code is highly Windows dependent, and none of it is useful under Linux. But the equivalent could presumably be done on Linux given someone who knows how debuggers work under Linux.

Based on this new perspective, I now agree that a stack trace is not a prioritary feature. It would require non-trivial code, and different implementations for each platform, and it's quite some work. But still, we could have line numbers for explicitly thrown exceptions, as that is quite easy to implement. Since throw is a static construct, it is known at compile the line and file were it occurs (similarly to assert), and so it could add such info to the thrown Exception.
 To implement this requires a pretty advanced technical knowledge of how
 Windows SEH works, and shinichiro deserves a lot of respect for figuring
 this out, since it's mostly undocumented.

-- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 09 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:

  > If this should be made, and I too agree it should, it should work in the
  > form of throwing an exception, as was also was noted.
 
 This is in error. Under Unknown W. Brackets assumption I thought that 
 access violations didn't throw Exceptions but they do. Someone should 
 have corrected us.

They only throw exceptions with DMD/Win, and in fact it seems that you *lose* some valuable information because of that... ? (which might have been rectified somewhat by the new patch, but) Some info on how it looks on other platforms can be found in: http://www.digitalmars.com/d/archives/digitalmars/D/14342.html In fact, it also looks similar on Windows when using GDC/MinGW: Program received signal SIGSEGV, Segmentation fault. 0x00401290 in _Dmain () at null.d:4 4 o.toString(); (gdb) bt #0 0x00401290 in _Dmain () at null.d:4 #1 0x004013b9 in _d_run_main (argc=1, argv=0x3d2448, main_func=0x401280 <_Dmain>) at ../../../libphobos/internal/dgccmain2.d:81 #2 0x004012e3 in main (argc=1, argv=0x3d2448) at ../../../libphobos/internal/cmain.d:5 (gdb) This was when running "null.exe" with gdb.exe, on Windows XP. Walter has said that the signals "should" (i.e. eventually) be converted into D exceptions on the other platforms too, but I'm not all that sure if that's such a great idea... ? If there's such an exception, it should at least have all info. --anders
Feb 09 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Anders F Björklund wrote:
 Bruno Medeiros wrote:
 
  > If this should be made, and I too agree it should, it should work 
 in the
  > form of throwing an exception, as was also was noted.

 This is in error. Under Unknown W. Brackets assumption I thought that 
 access violations didn't throw Exceptions but they do. Someone should 
 have corrected us.

They only throw exceptions with DMD/Win, and in fact it seems that you *lose* some valuable information because of that... ? (which might have been rectified somewhat by the new patch, but)

 Some info on how it looks on other platforms can be found in:
 http://www.digitalmars.com/d/archives/digitalmars/D/14342.html
 In fact, it also looks similar on Windows when using GDC/MinGW:
 

 Walter has said that the signals "should" (i.e. eventually)
 be converted into D exceptions on the other platforms too,
 but I'm not all that sure if that's such a great idea... ?
 

with gdb as one gets now? -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 09 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:

 Walter has said that the signals "should" (i.e. eventually)
 be converted into D exceptions on the other platforms too,
 but I'm not all that sure if that's such a great idea... ?

with gdb as one gets now?

Yes. (Just get a generic runtime error, with some basic message) I'm not chronically against the idea, if it works OK as in Java ? Just that if it can't be all the way, might as well be as in C... --anders PS. This is somewhat similar to how string literals are writable in DMD/Win, but how they cause access violations in other setups... "Implementation Defined"
Feb 09 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Anders F Björklund wrote:
 Bruno Medeiros wrote:
 
 Walter has said that the signals "should" (i.e. eventually)
 be converted into D exceptions on the other platforms too,
 but I'm not all that sure if that's such a great idea... ?

with gdb as one gets now?

Yes. (Just get a generic runtime error, with some basic message) I'm not chronically against the idea, if it works OK as in Java ? Just that if it can't be all the way, might as well be as in C... --anders PS. This is somewhat similar to how string literals are writable in DMD/Win, but how they cause access violations in other setups... "Implementation Defined"

Yes, loosing such functionality wouldn't be nice. However, there should some workaround/fix. For example, one can put a breakpoint in the D runtime code that would handle the access violations (where the exception is created and thrown), so that all the debug info would still be available? And could gdb be hacked/fixed/wraped so that this breakpoint setting is done automatically? -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 11 2006
prev sibling parent nick <nick.atamas gmail.com> writes:
Jarrett Billingsley wrote:
 Interesting how he comments time and time again how much he'd like null 
 pointer dereferencing to be checked.. funny, last time I brought that up, 
 Walter shot it down, since after all, access violations are more than 
 enough!  Right guys?  Right? 
 

Cyclone is a language (based on C) that introduced array bounds checks and fat pointers: http://www.research.att.com/projects/cyclone/online-manual/main-screen002.html#toc3 When I took a OSs course with Michael Hicks' (one of the people behind Cyclone) he urged students to use Cyclone in order to make their life easier. Somehow it never caught on. I had no problems finishing any of the projects in plain C, but I always wondered if Cyclone would have made things easier. The bug that caused me the most grief was not a pointer issue. I was calling a WriteBlock() function to READ a page from the drive(that didn't work, DUH). The bug was caused by a copy pasting error. The experience has taught me that NULL pointers are quite manageable. Also, I don't know that Sweeny's desire for dereference checking is justified. I would like to see some hard numbers to be convinced. Finally, I believe this is best left to tools like LINT.
Feb 05 2006
prev sibling parent Lucas Goss <lgoss007 gmail.com> writes:
This discussion came up in gamedev.net too. D was mentioned but sort of 
blown off. Here's a few of the comments ...

"D isn't much different from C++ therefore suffer the same 
problems/issues, there fundamentally imperative languages"

"Also, the "key" feature here, IMO, is STM. It really is the first 
concurrency abstraction to come around (ever) which is really useful. 
And it only came around in Nov 2004 (and AFIK it's only available in 
Haskell at the moment).

"I don't think it can be solved with a design pattern in an existing 
language."

And yes there are concurrent OO design patterns but that means very 
little here, it doesn't help/change the fact that most numerical 
computations are purely functional and in some places you may need to do 
state-full computation locally. It' s not going to change the fact that 
the way we keep going with inappropriate tools there will be to much 
shared mutable state flying around for reliable, maintainable, correct & 
clean concurrent code written by a medium to large team of developers 
who want to be productive."

http://www.gamedev.net/community/forums/topic.asp?topic_id=373751
(page 2, towards the bottom)
Feb 10 2006