On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote:
> On 01/09/2018 12:40 PM, tide wrote:
>> On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:
>>> On 8/31/2018 2:40 PM, tide wrote:
>>>> I don't think I've ever had a **game** hung up in a black screen and not be able to close it.
>>>
>>> I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix.
>> 
>> Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries.
>
> And yet they manage to run a JVM with Java on it.

Not the one's Walter is talking about. I rarely have to power cycle any smart device, even my phone which is running so much shit on it.

On Saturday, 1 September 2018 at 07:59:27 UTC, Walter Bright wrote:
> On 8/31/2018 5:40 PM, tide wrote:
>> On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:
>>> On 8/31/2018 2:40 PM, tide wrote:
>>>> I don't think I've ever had a **game** hung up in a black screen and not be able to close it.
>>>
>>> I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix.
>> 
>> Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries.
>
> Doesn't matter. It's clear that DVD player software is written by cowboy programmers who likely believe that it's fine to continue running a program after it has entered an invalid state, presumably to avoid annoying customers.
>
> Newer DVD/Bluray players have an ethernet port on the back. I'd never connect such a P.O.S. malware incubator to my LAN.

It does matter, I've programmed on embedded systems where the filename length was limited to 10 or so characters. There were all kinds of restrictions, how do you know when you have to power cycle that isn't an assert being hit and having the powercycle is the result of a hardware limitation that these "cowboy programmers" had no control over ? You are making a lot of wild assumptions to try and prove a point, and that all bugs can be solved with asserts (which they can't). Hey guys race conditions aren't a problem, just use an assert, mission fucking accomplished.

On Saturday, 1 September 2018 at 08:05:58 UTC, Walter Bright wrote:
> On 8/31/2018 5:47 PM, tide wrote:
>> I've already read them before. Why don't you explain what is wrong with it rather than posting articles.
>
> Because the articles explain the issues at length. Explaining why your proposal is deeply flawed was the entire purpose I wrote them.

I didn't write a proposal. I was explaining a flaw in your proposal.

>> You are just taking one line comments without even thinking about the context.
>
> We can start with the observation that a fly-by-wire is not a fundamentally different system than a fully powered hydraulic system or even a pilot muscle cable system, when we're talking about safety principles.

It is vastly different, do you know what fly by wire is? It means the computer is taking input digitally and applying the commands from the digital input into actual output. If the system controlling that just stops working, how do you expect the pilot to fly the plane? While all they are doing is moving a digital sensor that is doing nothing because the system that reads it input hit an assert.

> There's nothing magic about software. It's just more complicated (a fact that makes it even MORE important to adhere to sound principles, not throw them out the window).

I didn't say to throw them the door, I'm saying there's a lot of different ways to do things. And using asserts isn't the one ring to rule all safety measures. There are different methods, and depending on the application, as with anything, has it's pros and cons where a different method will be more suitable.

On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote:
> On 8/31/2018 7:28 PM, tide wrote:
>> I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ?
>
> Experience will guide you on where to put the asserts.
>
> But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up.
>
> Apply common sense and assert on unreasonable results, because your code is broken.

That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with.

On 02/09/2018 12:21 AM, tide wrote:
> On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote:
>> On 01/09/2018 12:40 PM, tide wrote:
>>> On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:
>>>> On 8/31/2018 2:40 PM, tide wrote:
>>>>> I don't think I've ever had a **game** hung up in a black screen and not be able to close it.
>>>>
>>>> I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix.
>>>
>>> Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries.
>>
>> And yet they manage to run a JVM with Java on it.
> 
> Not the one's Walter is talking about. I rarely have to power cycle any smart device, even my phone which is running so much shit on it.

For some reason I have memories related to DVD players containing a JVM to provide interactivity. But it doesn't look like those memory were based on anything. So ignore me.

On 02/09/2018 12:37 AM, tide wrote:
> On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote:
>> On 8/31/2018 7:28 PM, tide wrote:
>>> I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ?
>>
>> Experience will guide you on where to put the asserts.
>>
>> But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up.
>>
>> Apply common sense and assert on unreasonable results, because your code is broken.
> 
> That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with.

If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color.

But that isn't something I'd go test... Too much system-y stuff that can modify it.

On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote:
> On 02/09/2018 12:37 AM, tide wrote:
>> On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote:
>>> On 8/31/2018 7:28 PM, tide wrote:
>>>> I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ?
>>>
>>> Experience will guide you on where to put the asserts.
>>>
>>> But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up.
>>>
>>> Apply common sense and assert on unreasonable results, because your code is broken.
>> 
>> That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with.
>
> If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color.
>
> But that isn't something I'd go test... Too much system-y stuff that can modify it.

And you're putting that into production code? Cause that's the entire point of this topic :).

On 02/09/2018 12:57 AM, tide wrote:
> On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote:
>> On 02/09/2018 12:37 AM, tide wrote:
>>> On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote:
>>>> On 8/31/2018 7:28 PM, tide wrote:
>>>>> I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ?
>>>>
>>>> Experience will guide you on where to put the asserts.
>>>>
>>>> But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up.
>>>>
>>>> Apply common sense and assert on unreasonable results, because your code is broken.
>>>
>>> That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with.
>>
>> If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color.
>>
>> But that isn't something I'd go test... Too much system-y stuff that can modify it.
> 
> And you're putting that into production code? Cause that's the entire point of this topic :).

Goodness no. I can BSOD Windows just by writing user-land code that pretty much every program uses (yes related). Some things can definitely be tested in an assert, however like Walter has been arguing, are better left untested in production.

Keep in mind, a window whose decorations has changed color, is a very reasonable and should be expected situation. It is no where near an error.

This is one of the reasons I wouldn't bother with automated UI testing. Too many things can make it fail that is not related to your code, and integration may as well not exist cross-platform anyway. Let alone be well defined.

On Saturday, 1 September 2018 at 13:03:50 UTC, rikki cattermole wrote:
> On 02/09/2018 12:57 AM, tide wrote:
>> On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote:
>>> On 02/09/2018 12:37 AM, tide wrote:
>>>> On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote:
>>>>> On 8/31/2018 7:28 PM, tide wrote:
>>>>>> I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ?
>>>>>
>>>>> Experience will guide you on where to put the asserts.
>>>>>
>>>>> But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up.
>>>>>
>>>>> Apply common sense and assert on unreasonable results, because your code is broken.
>>>>
>>>> That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with.
>>>
>>> If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color.
>>>
>>> But that isn't something I'd go test... Too much system-y stuff that can modify it.
>> 
>> And you're putting that into production code? Cause that's the entire point of this topic :).
>
> like Walter has been arguing, are better left untested in production.

That's not what Walter has been arguing.

On Saturday, September 1, 2018 6:46:38 AM MDT rikki cattermole via Digitalmars-d wrote:
> On 02/09/2018 12:21 AM, tide wrote:
> > On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote:
> >> On 01/09/2018 12:40 PM, tide wrote:
> >>> On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:
> >>>> On 8/31/2018 2:40 PM, tide wrote:
> >>>>> I don't think I've ever had a **game** hung up in a black screen and not be able to close it.
> >>>>
> >>>> I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix.
> >>>
> >>> Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries.
> >>
> >> And yet they manage to run a JVM with Java on it.
> >
> > Not the one's Walter is talking about. I rarely have to power cycle any smart device, even my phone which is running so much shit on it.
>
> For some reason I have memories related to DVD players containing a JVM to provide interactivity. But it doesn't look like those memory were based on anything. So ignore me.

I don't know if any DVD players have ever used Java, but all Blu-ray players do require it, because unfortunately, the Blu-ray spec allows for the menus to be done via Java (presumably so that they can be fancier than what was possible on DVDs).

- Jonathan M Davis