On 10/3/2014 8:43 AM, Sean Kelly wrote:
> My point, and I think Kagamin's as well, is that the entire plane is a system
> and the redundant internals are subsystems.  They may not share memory, but they
> are wired to the same sensors, servos, displays, etc.

No, they do not share sensors, servos, etc.


> Thus the point about shutting down the entire plane as a result of a small failure is fair.

That's a complete misunderstanding.


In NO CASE does avionics software do anything after an assert but get shut down and physically isolated from what it controls.

I've explained this over and over. It baffles me how twisted up this simple concept becomes when repeated back to me.

On Sat, 04 Oct 2014 01:06:14 -0700
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> It doesn't do that anymore (at least mostly not). The compiler only continues to issue error messages for code that is not dependent on the code that caused an error message.
but first it trues to guess what to skip to "get in sync" again. that's exactly the guessing i'm against. got error? stop parsing/analyzing and die.

On Friday, 3 October 2014 at 22:27:44 UTC, Piotrek wrote:
> On Friday, 3 October 2014 at 20:31:42 UTC, Paolo Invernizzi wrote:
>
>>
>> As one that has read the original report integrally, I think that you have taken a bad example: despite the autopilot was disengaged, the stall alarm ringed a pletora of times.
>
> My point was that the broken speed indicators shut down the autopilot systems.
>
> Piotrek

And that is still the only reasonable thing to do in that case.

---
/Paolo

On 10/3/2014 9:10 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> I think Walter forgets that you ensure integrity of a complex system of servers
> by utilizing a rock solid proven transaction database/task-scheduler for
> handling all critical information. If that fails, you probably should shut down
> everything, roll back to the last backup and reboot.

You don't ensure integrity of anything by running software after it has entered an unknown and unanticipated state.

There's no way you'd bet your life on it.


> rock solid proven

Yeah, right.


> If that fails

"When that fails" FTFY


> I think Walter forgets

I think you forget my background in designing critical flight controls systems. I know what works, and the proof is the incredible safety of airliners. Yeah, I know that's "appeal to authority", but I've backed it up, too.

On Saturday, 4 October 2014 at 01:52:41 UTC, ketmar via Digitalmars-d wrote:
> On Sun, 28 Sep 2014 17:09:57 -0700
> Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> If the program has entered an unknown state, its behavior from then
>> on cannot be predictable.
> and D compiler itself contradicts this principle. why it tries to
> "recover" from parsing/compiling errors? it should stop on the first
> encountered error and not trying to "recover" itself from unknown state.
> hate this. and it's inconsistent with your words.

I think that there's a big confusion about terms: there's nothing unknown in the parser state when it reach an error in the grammar.
---
/Paolo

On 10/3/2014 11:00 AM, Piotrek wrote:
> http://en.wikipedia.org/wiki/Air_France_Flight_447
>
> I just pick some interesting statements (there are other factors described as
> well):

The overriding failure in that accident was the pilot panicked and persistently did the wrong thing, the opposite of what every pilot is relentlessly trained to do.

On 10/3/2014 3:27 PM, Piotrek wrote:
> My point was that the broken speed indicators shut down the autopilot systems.

The alternative is to have the autopilot crash the airplane. The autopilot cannot fly with compromised airspeed data.

On 10/1/2014 6:17 AM, Bruno Medeiros wrote:
> Walter, you do understand that not all software has to be robust -

Yes, I understand that.


> in the critical systems sense - to be quality software? And that in fact, the majority
> of software is not critical systems software?...
>
> I was under the impression that D was meant to be a general purpose language,
> not a language just for critical systems. Yet, on language design issues, you
> keep making a series or arguments and points that apply *only* to critical
> systems software.

If someone writes non-robust software, D allows them to do that. However, I won't leave unchallenged attempts to pass such stuff off as robust.

Nor will I accept such practices in Phobos, because, as this thread clearly shows, there are a lot of misunderstandings about what robust software is. Phobos needs to CLEARLY default towards solid, robust practice.

It's really too bad that I've never seen any engineering courses on reliability.

http://www.drdobbs.com/architecture-and-design/safe-systems-from-unreliable-parts/228701716

On Saturday, 4 October 2014 at 08:25:22 UTC, Walter Bright wrote:
> On 10/3/2014 9:10 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> I think Walter forgets that you ensure integrity of a complex system of servers
>> by utilizing a rock solid proven transaction database/task-scheduler for
>> handling all critical information. If that fails, you probably should shut down
>> everything, roll back to the last backup and reboot.
>
> You don't ensure integrity of anything by running software after it has entered an unknown and unanticipated state.

Integrity is ensured by the transaction engine. The world outside of the transaction engine has NO WAY of affecting integrity.

D code that is written today belongs outside the transaction engine.

> There's no way you'd bet your life on it.

SAAB Gripen crashed in 1989 and 1993 due to control software, the pilots used their parachutes and sent the plane in a safe direction. Eurofighter is wire controlled, you most likely cannot keep it stable without electronic control. So if it fails, you have to use the parachute. Bye, bye $100.000.000.

Anyway, failure should not be due to "asserts", that should be covered by program verification and formal proofs. Failure can still happen if the stabilizing model is inadequate.

During peace time fighter jets stay grounded for many days every year due to technical issues, maybe as much as 50%. In war time they would be up fighting… So yes, you bet your life on it when you defend the air base. Your life is worth nothing in certain circumstances. It is contextual.

> I think you forget my background in designing critical flight controls systems. I know what works, and the proof is the incredible safety of airliners. Yeah, I know that's "appeal to authority", but I've backed it up, too.

That's a marginal use scenario and software for critical control systems should not rely on asserts in 2014. Critical software should be formally proven correct.

On 10/1/2014 6:44 AM, Bruno Medeiros wrote:
> This is incorrect.
>
> Yes, the primary purpose of Exceptions is not for debugging, but to report
> exceptional state to the user (or some other component of the system).
>
> But they also have a purpose for debugging, particularly the stack traces of
> exceptions. Take what you said:
>
> "Failure to respond properly to an input/environmental error is a bug.
> But the input/environmental error is not a bug. If it was, then the
> program should assert on the error, not throw. "
>
> So, some component/function Foo detects an environmental error, and throws and
> Exception, accordingly. Foo is not responsible for handling these errors, but
> some other component is.
>
> Component/function Bar is the one that should handle such an error (for example,
> it should display a dialog to the user, and continue the application). But due
> to a bug, it doesn't do so, and the Exception goes all the way through main().

This is like saying "if statements are for debugging".


> The programmer notices this happening, and clearly recognizes it's a bug (but
> doesn't know where the bug is, doesn't know that it's Bar that should be
> handling it). Now, what is best, to just have the Exception message (something
> like "File not found") displayed to the programmer - or even an end-user that
> could report a bug -, or to have the stack trace of the Exception so that the
> programmer can more easily look at which function should be handling it?

Would you agree that every time DMD reports a syntax error in user code, it should also include a stack trace of the DMD source code to where in DMD it reported the error?