Max Samukha wrote:
> On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright
> <newshound1@digitalmars.com> wrote:
> 
>> If you've got a system that relies on the software continuing to function after an unexpected null seg fault, you have a VERY BADLY DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize this enough.
> 
> I have an example of such a software:
> http://www.steinberg.net/en/products/audiopostproduction_product/nuendo4.html
> 
> It loads third-party plugins into the host process's address space, an
> consequently it may fail at any moment. The software's design is not
> the best ever but it gives the user last chance to save his work in
> case of fatal error. This feature has saved my back a couple of times.

I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground.

Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe.

> 
>> P.S. I worked for Boeing for years on flight critical systems. Normally I eschew credentialism, but I feel very strongly about this issue and wish to point out that my knowledge on this is based on decades of real world experience by aviation companies who take this issue extremely seriously.
> 
> Then, instead of sticking with Windows and the likes, you may want to
> think about porting dmd to a more serious environment specifically
> designed for developing such systems. What about a real-time
> microkernel OS like this one:
> http://www.qnx.com/products/neutrino_rtos/ ?

dmd targets Windows because that's where probably half the programmers are. I'd certainly like to do embedded systems, too, but realistically that's going to be the purview of gdc or ldc.

On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Max Samukha wrote:
>>
>> On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>>> If you've got a system that relies on the software continuing to function after an unexpected null seg fault, you have a VERY BADLY DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize this enough.
>>
>> I have an example of such a software:
>>
>> http://www.steinberg.net/en/products/audiopostproduction_product/nuendo4.html
>>
>> It loads third-party plugins into the host process's address space, an consequently it may fail at any moment. The software's design is not the best ever but it gives the user last chance to save his work in case of fatal error. This feature has saved my back a couple of times.
>
> I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground.
>
> Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe.
>

You spent quite a bit of effort explaining that segfaults never cause memory corruption, so it seems fairly reasonable to assume that some parts of the application state could still be valid and useful not to throw away.

>>
>>> P.S. I worked for Boeing for years on flight critical systems. Normally I eschew credentialism, but I feel very strongly about this issue and wish to point out that my knowledge on this is based on decades of real world experience by aviation companies who take this issue extremely seriously.
>>
>> Then, instead of sticking with Windows and the likes, you may want to think about porting dmd to a more serious environment specifically designed for developing such systems. What about a real-time microkernel OS like this one: http://www.qnx.com/products/neutrino_rtos/ ?
>
> dmd targets Windows because that's where probably half the programmers are. I'd certainly like to do embedded systems, too, but realistically that's going to be the purview of gdc or ldc.
>

I'm not sure if LDC will ever support D2 (at least wont be by my hand)

== Quote from Tomas Lindquist Olsen (tomas.l.olsen@gmail.com)'s article
> I'm not sure if LDC will ever support D2 (at least wont be by my hand)

What is it about D2 that makes this unlikely?  I thought after LDC D1 support was stable and the D2 spec and front end were stable, the natural progression of things would be for LDC to support D2.

On Tue, Nov 17, 2009 at 4:45 PM, dsimcha <dsimcha@yahoo.com> wrote:
> == Quote from Tomas Lindquist Olsen (tomas.l.olsen@gmail.com)'s article
>> I'm not sure if LDC will ever support D2 (at least wont be by my hand)
>
> What is it about D2 that makes this unlikely?  I thought after LDC D1 support was stable and the D2 spec and front end were stable, the natural progression of things would be for LDC to support D2.
>

LDC requires a lot of changes to the frontend.

* DMD is not written as a cross compiler
* The runtime interfaces are hardcoded into the frontend semantics
* The ast rewrites dmd does are destructive and buggy
* The dmd codegen is all over the frontend code, it wasn't meant to be
used with another backend

But most of all: someone has to do it.

Keeping the two in sync is a major PITA, the original merge of our frontend changes, to the D2 frontend was done in a error prone way, which introduced a lot of bugs, codegen that worked in D1 still compiles, and generates code that compiles, but the code doesn't run. This requires time consuming debugging/reviewing and of course fixing.

So most of all, like most of things D, it's about a lack of manpower. I personally no longer have the time to maintain LDC besides critical bugfixes now and then, and other devs are in similar situations.

Another factor may be more ideological (or something), not everyone is happy about how D evolved, and who want to implement something they don't really care about ?

-Tomas

Tomas Lindquist Olsen Wrote:

> On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> >
> > I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground.
> >
> > Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe.
> >
> 
> You spent quite a bit of effort explaining that segfaults never cause memory corruption, so it seems fairly reasonable to assume that some parts of the application state could still be valid and useful not to throw away.

At the moment the segfault occurs, sure.  But if the process eats the segfault and continues, what happens?  If an app is programmed in such a way that segfaults are a part of normal processing (I worked on a DB that performed dynamic loading this way) that's one thing.  But other apps are almost definitely going to try and write data near 0x00 after such an occurrence.

Sean Kelly wrote:
> Tomas Lindquist Olsen Wrote:
> 
>> On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>> I suppose nobody much cares if it writes out a corrupted audio file. People
>>> care very much if their airplane suddenly dives into the ground.
>>>
>>> Be that as it may, it is certainly possible to catch seg faults in an
>>> exception handler and write files out. That would be an unacceptable
>>> behavior, though, in a system that needs to be safe.
>>>
>> You spent quite a bit of effort explaining that segfaults never cause
>> memory corruption, so it seems fairly reasonable to assume that some
>> parts of the application state could still be valid and useful not to
>> throw away.
> 
> At the moment the segfault occurs, sure.  But if the process eats the segfault and continues, what happens?  If an app is programmed in such a way that segfaults are a part of normal processing (I worked on a DB that performed dynamic loading this way) that's one thing.  But other apps are almost definitely going to try and write data near 0x00 after such an occurrence.

I think throwing an Error object instead of failing immediately would be occasionally useful. (Same goes about other trapped errors such as integral division by zero.) There are applications out there that want to partially recover from a null pointer error. I wrote a few, so it's difficult to convince me they don't exist.

Andrei

Tomas Lindquist Olsen:

> LDC requires a lot of changes to the frontend.
> 
> * DMD is not written as a cross compiler
> * The runtime interfaces are hardcoded into the frontend semantics
> * The ast rewrites dmd does are destructive and buggy
> * The dmd codegen is all over the frontend code, it wasn't meant to be
> used with another backend

LLVM is one of the best thing happened to D1, so maybe Walter can improve the situation, to allow a simpler/better attach of the D2 front-end to LLVM. If you keep your muzzle shut things will never improve. Maybe someone can write a list of all the points where D2 causes such port problems, so Walter may improve/fix them some.

This is quite important, more than most syntax details discussed in the last weeks.

Bye,
bearophile

On Tue, Nov 17, 2009 at 5:58 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Tomas Lindquist Olsen:
>
>> LDC requires a lot of changes to the frontend.
>>
>> * DMD is not written as a cross compiler
>> * The runtime interfaces are hardcoded into the frontend semantics
>> * The ast rewrites dmd does are destructive and buggy
>> * The dmd codegen is all over the frontend code, it wasn't meant to be
>> used with another backend
>
> LLVM is one of the best thing happened to D1, so maybe Walter can improve the situation, to allow a simpler/better attach of the D2 front-end to LLVM. If you keep your muzzle shut things will never improve. Maybe someone can write a list of all the points where D2 causes such port problems, so Walter may improve/fix them some.
>

Walter seems to be fairly rigid to work with. While the latest improvements, like DMD in a SVN repo, is a great step, I just don't have as much time for LDC as I used to, so the little difference it makes doesn't really help me that much.

I agree it would be good with more developer documentation. But LDC is really not implemented very cleanly and writing such would be a huge amount of work. When I started on LDC I had no idea how DMD worked, and I made a lot of mistakes along the way.

Now, since then, a lot of people have joined, and helped out. But it still suffers from some of the issues introduced very early.

Another point is motivation. Personally, I've achieved what I originally planned for LDC, and quite a lot more. New projects await out there.

Don't get me wrong. I *use* D (1.0 + Tango). And I need a x86-64 compatible D compiler, so I'm not abandoning LDC. But other people will have to step in for D2 support. Unless of course I somehow magically convert to liking D2. But I doubt that's going to happen.

-Tomas

P.S. LDC is an open source project, and while I started it, many other people now have write access to the repository. I'm not holding anyone back from making the changes needed for D2 support. And in case someone out there wants it, I'll be happy to give you access as well (after seeing a first patch).

Tomas Lindquist Olsen wrote:
> You spent quite a bit of effort explaining that segfaults never cause
> memory corruption, so it seems fairly reasonable to assume that some
> parts of the application state could still be valid and useful not to
> throw away.

When a seg fault occurs, it is because your program is in a state that you, the programmer, never anticipated. Therefore, you cannot know what state your data is in. Therefore, your data is unreliable. While it may not be in a bad state from memory corruption, it could very well be in a bad state from your program's logic being wrong.

Do you want to bet your life on assuming your program and its data is still valid?

Tomas Lindquist Olsen wrote:
> LDC requires a lot of changes to the frontend.

If you send me the changes, I can incorporate at least some of them, making subsequent versions easier to port to LDC.