Ada-Oriented GUI

Ada-Oriented GUI

[Jeffrey R. Carter]

I've written on here before that I think the traditional 
register-callbacks-and-call-a-procedure GUI interface is a hack only suitable 
for sequential languages, and attempted to describe my idea of how a GUI for a 
concurrent language like Ada should work. Some have expressed the opinion that 
such an interface is not possible.

I've now written a very minimal GUI interface embodying my concepts. It 
implements text boxes and buttons, as that is the minimum for an example that 
actually does something faintly interesting. For an example, I've used the 
Random_Int demo from Gnoga.

I've also made a quick and dirty implementation of the interface on top of 
Gnoga, and a version of Random_Int using the interface. Though the Gnoga version 
of Random_Int is very simple and fairly easy to understand, this version is 
easier to understand.

Those interested can find Ada_GUI at

https://github.com/jrcarter/Ada_GUI

Those who like programming by extension won't like it.

-- 
Jeff Carter
"Insufficient laughter--that's grounds for divorce."
Play It Again, Sam
126

Re: Ada-Oriented GUI

[Dan'l Miller]

On Sunday, March 18, 2018 at 8:33:26 AM UTC-5, Jeffrey R. Carter wrote:
> I've written on here before that I think the traditional 
> register-callbacks-and-call-a-procedure GUI interface is a hack only suitable 
> for sequential languages, and attempted to describe my idea of how a GUI for a 
> concurrent language like Ada should work. Some have expressed the opinion that 
> such an interface is not possible.

Jeffrey, you are very insightful & wise (and correct).  Apparently independent of your efforts, Microsoft Research (of all organizations on the planet!) effectively concurs with you.  Over the past decade, Microsoft Research has been spreading their Reactive Extensions (and Interactive Extensions, LINQ) presentation of a very similar idea as to the one that you have:  GUIs could focus on a linear river of dataflows, not on callbacks.  The Rx community smears the current tangled callback set of competing concerns (that are extraordinarily difficult to get right at scale) as “callback hell”.  Microsoft Research is the progenitor of the Rx and Ix libraries for C#, F#, and C++.  Allied but competing efforts are porting variants of Microsoft Research's Rx and Ix libraries to Java, Kotlin, Swift, Lua, JavaScript, Scala, Clojure, Ruby, Python, Go, Groovy, Elixir, and Dart—just about every general-purpose language except Ada (and Fortran, but hardly anyone has considered Fortran a nonnumerical/general-purpose language since Prime Computer switch from writing compilers & OSes in Fortran to PL/P).  But more to you point, Jeffrey, are the RxNetty for .NET, RxAndroid, and RxCocoa for GUIs/OSes with numerous competing information flows (e.g., interactive GUI events, app lifecycle events, network events, realtime events).  At some level, Rx conforms to your vision.

http://reactivex.io/languages.html

Although there are numerous hackerish books out there for Rx, I would recommend Microsoft Research's seminal reference:  _Introduction to Rx: A step-by-step guide to the Reactive Extensions to .NET_ by Ian Campbell.  This book is less about .NET & C# than using .NET & C# as concrete examples of more theoretical/abstract concepts.  Then, the best book by far that I have read for RxAndroid is _Reactive Android Programming_ by Tadas Subonis, which is actually mediocre but all the others for Android and Cocoa are truly abysmal!  Nearly all of these books expend far far far too much effort giving playbaby playtoy examples with sequences of integers and not nearly enough truly teaching how to wire up rivers of data flows for all the interesting Rx-rivers-of-dataflows scenarios is GUIs & OSes.  (I say rivers here merely to paint an instant understandable motivational picture in the mind's eye; the normative term is sequence, but the RxJava-influenced subculture of Rx also uses streams instead of sequences.)

I encourage you to meld your work with Rx, plus also you should seriously consider being the primary developer of RxAda, which is not yet extant to my knowledge.  Indeed, the Rx world is still quite bleeding-edge and in flux; all of Rx in all languages could still be shaped by your work in the ways that it differs.  (Of course in Ada, tasks are part of the language, whereas, in other languages, those languages must rely on the OS framework for threads and schedulers—but the moral of the story of your vision for an RxAda using the vision that you describe can be ported to some degree to the other Rx-capable languages as well.)

Re: Ada-Oriented GUI

[Dan'l Miller]

On Sunday, March 18, 2018 at 9:03:41 PM UTC-5, Dan'l Miller wrote:
> ... Allied but competing efforts are porting variants of Microsoft Research's Rx and Ix libraries to Java, Kotlin, Swift, Lua, JavaScript, Scala, Clojure, Ruby, Python, Go, Groovy, Elixir, and Dart—just about every general-purpose language except Ada (and Fortran, ...
> 
> http://reactivex.io/languages.html

I will need to take a portion of that back; there was some initial attempt at an RxAda that was reported last year:

https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/RxAdaSlidesShort.pdf

Perhaps this initial foray into an RxAda by Alejandro Mosteo is a starting point, or at least a prior reference to critique.

Re: Ada-Oriented GUI

[Alejandro R. Mosteo]

On 19/03/18 15:10, Dan'l Miller wrote:
> On Sunday, March 18, 2018 at 9:03:41 PM UTC-5, Dan'l Miller wrote:
>> ... Allied but competing efforts are porting variants of Microsoft Research's Rx and Ix libraries to Java, Kotlin, Swift, Lua, JavaScript, Scala, Clojure, Ruby, Python, Go, Groovy, Elixir, and Dart—just about every general-purpose language except Ada (and Fortran, ...
>>
>> http://reactivex.io/languages.html
> 
> I will need to take a portion of that back; there was some initial attempt at an RxAda that was reported last year:
> 
> https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/RxAdaSlidesShort.pdf
> 
> Perhaps this initial foray into an RxAda by Alejandro Mosteo is a starting point, or at least a prior reference to critique.

RxAda is right now somewhat down in my stack of priorities, but actually 
a demo over GtkAda/Gnoga is among the things I want to attempt sooner or 
later.

Álex.

Re: Ada-Oriented GUI

[Dan'l Miller]

On Wednesday, March 21, 2018 at 4:49:39 AM UTC-5, Alejandro R. Mosteo wrote:
> On 19/03/18 15:10, Dan'l Miller wrote:
> > I will need to take a portion of that back; there was some initial attempt at an RxAda that was reported last year:
> > 
> > https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/RxAdaSlidesShort.pdf
> > 
> > Perhaps this initial foray into an RxAda by Alejandro Mosteo is a starting point, or at least a prior reference to critique.
> 
> RxAda is right now somewhat down in my stack of priorities, but actually 
> a demo over GtkAda/Gnoga is among the things I want to attempt sooner or 
> later.
> 
> Álex.

I was hoping that you would reply to this thread.  Thank you, for the reply and for all your valuable & appreciated work on RxAda.  (Comp.lang.ada is more exciting when principle people contribute their expertise regarding fresh trends in Ada, rather than merely students seeking to cheat on their homework/test questions.) Is RxAda released publicly?  If not yet, might RxAda be released publicly as part of that GtkAda/Gnoga demonstration?

Also, (other than lack of free time) what has been the biggest obstacle to your development of RxAda?  Ada lacks lambdas/anonymous-subroutines but even the RxJava community sometimes prefers named methods over lambdas in app-domain code that utilizes RxJava, even in the latest versions of Java that have full-fledged lambdas in the language now.  What other language features or lack there of in Ada cause concern in your development of RxAda?  Have you envisioned language features unique to (current or future) Ada that would allow RxAda to go beyond the state of the art in the Rx libraries for all the other languages?

Re: Ada-Oriented GUI

[briot.emmanuel]

I was also working on similar similar at the time (starting with promises (https://github.com/briot/Ada-promises, though there's also a branch there were I started to look at reactive programming).

For me, the biggest obstacles were the need to instantiate a lot of generics, because the streams are associated with data, then get combined to create other types of data, and so on. So we ended up with a soup of instantiations (on the user side), which I had not quite managed to tame.

The lack of anonymous subprograms was not a very significant issue to me, though indeed having some simple "anonymous expression functions" for the simple transformation cases would be nice.

But indeed I agree there's something to be done in that area.

Re: Ada-Oriented GUI

[Shark8]

On Wednesday, March 21, 2018 at 12:43:51 PM UTC-6, briot.e...@gmail.com wrote:
> I was also working on similar similar at the time (starting with promises (https://github.com/briot/Ada-promises, though there's also a branch there were I started to look at reactive programming).
> 
> For me, the biggest obstacles were the need to instantiate a lot of generics, because the streams are associated with data, then get combined to create other types of data, and so on. So we ended up with a soup of instantiations (on the user side), which I had not quite managed to tame.

I had an idea about that, though even if I submit it now it wouldn't be put in Ada 2020 -- but anyway, the idea was a sort of automatic instantiation.

Given

Generic
  Type Some_Type is private;
Procedure Generic_Swap( A, B : in out Some_Type );

you could say

Generic
  Type Element is private;
  Type Index is (<>);
  Type Array_Type is Array(Index range <>) of Element;
  USE Procedure Swap is new Generic_Swap( Element );
Procedure Generic_Sort( Input : in out Array_Type );

--...
Type Integer_Array is new Array(Integer range <>) of Integer;
Procedure Sort is new Generic_Sort( Integer, Integer, Integer_Array );

where the USE would instantiate Swap in Sort's instantiation; Swap itself could be reached via Sort.Swap and used in that manner, thereby cleaning up a lot of one-off instantiations.

Re: Ada-Oriented GUI

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:3ff0cd7d-c3c5-4b03-a686-3cb21f3fbfa6@googlegroups.com...
On Wednesday, March 21, 2018 at 12:43:51 PM UTC-6, briot.e...@gmail.com 
wrote:
...
>> For me, the biggest obstacles were the need to instantiate a lot of 
>> generics,
>> because the streams are associated with data, then get combined to create
>> other types of data, and so on. So we ended up with a soup of
>> instantiations (on the user side), which I had not quite managed to tame.
>
>I had an idea about that, though even if I submit it now it wouldn't be put 
>in
> Ada 2020 -- but anyway, the idea was a sort of automatic instantiation.

Actually, there is an open AI on automatic instantiation, so this idea would 
get added to that AI. And this idea is *WAAAYYY* more sensible than that 
one, so I'd hope it was in the hopper. OTOH, we're in the process of 
prioritizing work for Ada 2020, and that is one of many AIs that might be on 
the chopping block (we have something like 60 open AIs and time to handle 
maybe 20, so something has to go).

This is a long-winded way of saying that you should submit it, there's some 
chance it might be acted on but it's hard to say how much.

 ...
>where the USE would instantiate Swap in Sort's instantiation; Swap itself 
>could
>be reached via Sort.Swap and used in that manner, thereby cleaning up a lot 
>of
>one-off instantiations.

Makes sense to me.

                     Randy.

Re: Ada-Oriented GUI

[Shark8]

On Wednesday, March 21, 2018 at 4:40:32 PM UTC-6, Randy Brukardt wrote:
> 
> Actually, there is an open AI on automatic instantiation, so this idea would 
> get added to that AI. And this idea is *WAAAYYY* more sensible than that 
> one, so I'd hope it was in the hopper.

I tried to find this AI, spent 30-40 minutes looking via the AI-Search but couldn't find it. / I'd like to add my idea on to it, as it seems a sensible way to reduce the objects (really [explicit] compilation_units) that have to be carried around both in the source and in the programmer's head. (Win-win, I think.)

> OTOH, we're in the process of 
> prioritizing work for Ada 2020, and that is one of many AIs that might be on 
> the chopping block (we have something like 60 open AIs and time to handle 
> maybe 20, so something has to go).

It's true that there has to be prioritization, but I think that this could be of great utility to users, allowing some significant simplification... especially to GNAT projects which require an extra file for each [library-level] instantiation.

> This is a long-winded way of saying that you should submit it, there's some 
> chance it might be acted on but it's hard to say how much.

I'll do it if I can find the AI.

Re: Ada-Oriented GUI

[briot.emmanuel]

> > Actually, there is an open AI on automatic instantiation, so this idea would 
> > get added to that AI. And this idea is *WAAAYYY* more sensible than that 
> > one, so I'd hope it was in the hopper.
> 
> I tried to find this AI, spent 30-40 minutes looking via the AI-Search but couldn't find it. / I'd like to add my idea on to it, as it seems a sensible way to reduce the objects (really [explicit] compilation_units) that have to be carried around both in the source and in the programmer's head. (Win-win, I think.)


Try

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0205-1.txt?rev=1.2&raw=N

That's a similar idea to yours, which I submitted (via other AdaCore people) a year ago or so.

Re: Ada-Oriented GUI

[Shark8]

On Thursday, March 22, 2018 at 12:50:02 AM UTC-6, briot.e...@gmail.com wrote:
> > > Actually, there is an open AI on automatic instantiation, so this idea would 
> > > get added to that AI. And this idea is *WAAAYYY* more sensible than that 
> > > one, so I'd hope it was in the hopper.
> > 
> > I tried to find this AI, spent 30-40 minutes looking via the AI-Search but couldn't find it. / I'd like to add my idea on to it, as it seems a sensible way to reduce the objects (really [explicit] compilation_units) that have to be carried around both in the source and in the programmer's head. (Win-win, I think.)
> 
> 
> Try
> 
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0205-1.txt?rev=1.2&raw=N
> 
> That's a similar idea to yours, which I submitted (via other AdaCore people) a year ago or so.

Awesome / thank you.
I'll give it a read, write up my proposal (as part of discussion) and pop a message to the ARG. (I think that's how it's supposed to be done, procedurally.)

Re: Ada-Oriented GUI

[Shark8]

On Wednesday, March 21, 2018 at 4:40:32 PM UTC-6, Randy Brukardt wrote:
> 
> This is a long-winded way of saying that you should submit it, there's some 
> chance it might be acted on but it's hard to say how much.

I sent an email to arg(at)ada-auth.org; subject: "Re: AI12-0205-1 (Defaults for generic formal parameters)"

(a) Was that the correct procedure?
(b) Was the AI the proper one?
(c) Did you receive the e-mail?

Re: Ada-Oriented GUI

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:748d6aa7-3d37-43e4-a38c-5e852b54b915@googlegroups.com...
> On Wednesday, March 21, 2018 at 4:40:32 PM UTC-6, Randy Brukardt wrote:
>>
>> This is a long-winded way of saying that you should submit it, there's 
>> some
>> chance it might be acted on but it's hard to say how much.
>
> I sent an email to arg(at)ada-auth.org; subject: "Re: AI12-0205-1 
> (Defaults for generic formal parameters)"
>
> (a) Was that the correct procedure?

It's OK, since you're an observer and thus subject to the "designated 
experts" deadlines. You could have sent it to Ada-Comment as well.

> (b) Was the AI the proper one?

I was thinking of AI12-0215-1 "Implicit Instantiations", but AI12-0205-1 
works as well. Since you're an observer, it might end up as a new AI as 
well.

> (c) Did you receive the e-mail?

Yes, I saw it, and I think it went out to everyone.

             Randy.

Re: Ada-Oriented GUI

[Mehdi Saada]

Dear Randy,
about that statement:"Better yet, don't use any language at all, since most programming will be gone by then anyway."
I'm not sure if
1) it was sarcastic or not
2) you believe this because people are too dumb to think things right, or because complex systems has gone too far for human programmers to cope with them ? I read that more or less complete automatic code generation was going to be the future. I don't believe it one heck, but your opinion on that interests me a lot. In fact you might already have talked about that somewhere, I'm not sure.

As for "convinced that Ada as it stands is not going to be able to appropriately
support safe parallel programming"... not like I want you to badmouth your collegues, but dare I ask more information ?

Re: Ada-Oriented GUI

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:45d67d0b-8212-45aa-b654-08ac486b3bb9@googlegroups.com...
Dear Randy,
>about that statement:"Better yet, don't use any language at all, since most
>programming will be gone by then anyway."
>I'm not sure if
>1) it was sarcastic or not
>2) you believe this because people are too dumb to think things right, or 
>because
>complex systems has gone too far for human programmers to cope with them ?

Part the latter, and part that truly high-level programming will have 
progressed far enough that most things (especially GUIs and the like) won't 
need to be conventionally written. There's also the possibility of some 
non-programming technique taking over much of what is now programming 
(neural networks is the current leader there). The main thing being that 
advancing the state-of-the-art in hardware is going to require radical 
changes, and radical changes are likely to require radical programming 
changes.

>As for "convinced that Ada as it stands is not going to be able to 
>appropriately
>support safe parallel programming"... not like I want you to badmouth your
>collegues, but dare I ask more information ?

You can ask, but I think it is better to let the process play out. It 
doesn't help to air frustration in public.

               Randy.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 27/03/2018 00:09, Randy Brukardt wrote:
> There's also the possibility of some
> non-programming technique taking over much of what is now programming
> (neural networks is the current leader there).

How training a system to solve *same* problem may help designing GUI?

[Unless it is translation from a language of specifications into the 
code, which is equivalent to having just another programming language. 
BTW, all sorts of GUI generators were here for decades. None worked for 
production-grade code.]

> The main thing being that
> advancing the state-of-the-art in hardware is going to require radical
> changes, and radical changes are likely to require radical programming
> changes.

That is possible, however programming involves another kind of hardware: 
the human brain. That is not going to change. I would rather expect 
programming adapting more to the limitations and weaknesses of 
programmers than to the "metal".

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p9crpe$ue3$1@gioia.aioe.org...
> On 27/03/2018 00:09, Randy Brukardt wrote:
>> There's also the possibility of some
>> non-programming technique taking over much of what is now programming
>> (neural networks is the current leader there).
>
> How training a system to solve *same* problem may help designing GUI?

I've never thought that a GUI is the end-all interface. Voice command is 
probably closer, or perhaps some sort of brain-wave control? Playing around 
with a pointing device and a screen is just a way station (with a few 
exceptions of things that are inherently visual - photo processing, maps, 
etc.).

One result is that solving the problems of GUI creation is less necessary 
for the long-term than people make out.

                          Randy.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 28/03/2018 01:58, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p9crpe$ue3$1@gioia.aioe.org...
>> On 27/03/2018 00:09, Randy Brukardt wrote:
>>> There's also the possibility of some
>>> non-programming technique taking over much of what is now programming
>>> (neural networks is the current leader there).
>>
>> How training a system to solve *same* problem may help designing GUI?
> 
> I've never thought that a GUI is the end-all interface. Voice command is
> probably closer, or perhaps some sort of brain-wave control? Playing around
> with a pointing device and a screen is just a way station (with a few
> exceptions of things that are inherently visual - photo processing, maps,
> etc.).
> 
> One result is that solving the problems of GUI creation is less necessary
> for the long-term than people make out.

Replaced by more difficult problems? Older devices usually have much 
simpler interfaces, Dial disk telephone vs. mobile phone?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Alejandro R. Mosteo]

On 21/03/18 14:58, Dan'l Miller wrote:
> On Wednesday, March 21, 2018 at 4:49:39 AM UTC-5, Alejandro R. Mosteo wrote:
>> On 19/03/18 15:10, Dan'l Miller wrote:
>>> I will need to take a portion of that back; there was some initial attempt at an RxAda that was reported last year:
>>>
>>> https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/RxAdaSlidesShort.pdf
>>>
>>> Perhaps this initial foray into an RxAda by Alejandro Mosteo is a starting point, or at least a prior reference to critique.
>>
>> RxAda is right now somewhat down in my stack of priorities, but actually
>> a demo over GtkAda/Gnoga is among the things I want to attempt sooner or
>> later.
>>
>> Álex.
> 
> I was hoping that you would reply to this thread.  Thank you, for the reply and for all your valuable & appreciated work on RxAda.  (Comp.lang.ada is more exciting when principle people contribute their expertise regarding fresh trends in Ada, rather than merely students seeking to cheat on their homework/test questions.) Is RxAda released publicly?  If not yet, might RxAda be released publicly as part of that GtkAda/Gnoga demonstration?

Thanks for these kind words. Sure, the repository is public: 
https://bitbucket.org/amosteo/rxada

> Also, (other than lack of free time) what has been the biggest obstacle to your development of RxAda?  Ada lacks lambdas/anonymous-subroutines but even the RxJava community sometimes prefers named methods over lambdas in app-domain code that utilizes RxJava, even in the latest versions of Java that have full-fledged lambdas in the language now.  What other language features or lack there of in Ada cause concern in your development of RxAda?  Have you envisioned language features unique to (current or future) Ada that would allow RxAda to go beyond the state of the art in the Rx libraries for all the other languages?

There are some thoughts about my experience writing RxAda in the website 
above. Besides that, I mostly concur with what Emmanuel Briot has said 
in another reply.

The need for so many generics is troublesome. I tried to make the 
library as easy to use as I could, but I couldn't go below one 
instantiation per user type and per type transformation. I haven't yet 
used RxAda in any real project, so I still lack the hands-on experience 
to see to what extent it is practical or not (hence my desire to test it 
with a real GUI).

I missed lambdas a bit, but not as much as I expected to. My recent 
experiences with expression functions make me think that those could be 
good candidates for "lambdification". As for your comments about the 
RxJava community, I'm afraid I don't know. I used for a while RxJava for 
some Android apps but then I had to move on. Though it was enough to get 
me sufficiently excited about it to write RxAda.

Java really has managed a hit with its implicit generics, though the 
editor I was using, the IntelliJ one, gets half of the merit with its 
on-the-fly suggestions for simplifications.

Also, the twisted use of generics + interfaces + "&" operator made me 
feel that I was using Ada in a way that was not the intended one. But it 
compiles and runs, so, who knows.

Re: Ada-Oriented GUI

[Dan'l Miller]

On Thursday, March 22, 2018 at 12:34:04 PM UTC-5, Alejandro R. Mosteo wrote:
> On 21/03/18 14:58, Dan'l Miller wrote:
> > On Wednesday, March 21, 2018 at 4:49:39 AM UTC-5, Alejandro R. Mosteo wrote:
> >> On 19/03/18 15:10, Dan'l Miller wrote:
> >>> I will need to take a portion of that back; there was some initial attempt at an RxAda that was reported last year:
> >>>
> >>> https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/RxAdaSlidesShort.pdf
> >>>
> >>> Perhaps this initial foray into an RxAda by Alejandro Mosteo is a starting point, or at least a prior reference to critique.
> >>
> >> RxAda is right now somewhat down in my stack of priorities, but actually
> >> a demo over GtkAda/Gnoga is among the things I want to attempt sooner or
> >> later.
> >>
> >> Álex.
> > 
> > I was hoping that you would reply to this thread.  Thank you, for the reply and for all your valuable & appreciated work on RxAda.  (Comp.lang.ada is more exciting when principle people contribute their expertise regarding fresh trends in Ada, rather than merely students seeking to cheat on their homework/test questions.) Is RxAda released publicly?  If not yet, might RxAda be released publicly as part of that GtkAda/Gnoga demonstration?
> 
> Thanks for these kind words. Sure, the repository is public: 
> https://bitbucket.org/amosteo/rxada

Thank you so much!

> There are some thoughts about my experience writing RxAda in the website 
> above

Over there you mention that a design goal of RxAda was to avoid RxCpp's cryptosyntax.  What specifically was the origin of that RxCpp cryptosyntax?  Something in RxCpp itself?  Or C++11/C++14/C++17's lambda's cryptosyntax in general?

(I had a nightmare one time where the ISO14889 C++ standards body started to utilize APL symbols to take the cryptosyntax to a whole new level.)

Re: Ada-Oriented GUI

[Shark8]

On Thursday, March 22, 2018 at 11:50:13 AM UTC-6, Dan'l Miller wrote:
> 
> I had a nightmare one time where the ISO14889 C++ standards body started to utilize APL symbols to take the cryptosyntax to a whole new level.

That's hilarious.
If I were a member of the standards body, I would write a proposal for that and submit it [maybe on 01 Apr] to see if it would get any 'bites'... it could also require bringing back triglyphs!

Re: Ada-Oriented GUI

[Alejandro R. Mosteo]

On 22/03/18 18:50, Dan'l Miller wrote:
> On Thursday, March 22, 2018 at 12:34:04 PM UTC-5, Alejandro R. Mosteo wrote:
>> On 21/03/18 14:58, Dan'l Miller wrote:
>>> On Wednesday, March 21, 2018 at 4:49:39 AM UTC-5, Alejandro R. Mosteo wrote:
>>>> On 19/03/18 15:10, Dan'l Miller wrote:
>>>>> I will need to take a portion of that back; there was some initial attempt at an RxAda that was reported last year:
>>>>>
>>>>> https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/RxAdaSlidesShort.pdf
>>>>>
>>>>> Perhaps this initial foray into an RxAda by Alejandro Mosteo is a starting point, or at least a prior reference to critique.
>>>>
>>>> RxAda is right now somewhat down in my stack of priorities, but actually
>>>> a demo over GtkAda/Gnoga is among the things I want to attempt sooner or
>>>> later.
>>>>
>>>> Álex.
>>>
>>> I was hoping that you would reply to this thread.  Thank you, for the reply and for all your valuable & appreciated work on RxAda.  (Comp.lang.ada is more exciting when principle people contribute their expertise regarding fresh trends in Ada, rather than merely students seeking to cheat on their homework/test questions.) Is RxAda released publicly?  If not yet, might RxAda be released publicly as part of that GtkAda/Gnoga demonstration?
>>
>> Thanks for these kind words. Sure, the repository is public:
>> https://bitbucket.org/amosteo/rxada
> 
> Thank you so much!
> 
>> There are some thoughts about my experience writing RxAda in the website
>> above
> 
> Over there you mention that a design goal of RxAda was to avoid RxCpp's cryptosyntax.  What specifically was the origin of that RxCpp cryptosyntax?  Something in RxCpp itself?  Or C++11/C++14/C++17's lambda's cryptosyntax in general?

That was a bit of a tongue-in-cheek comment... But yes, while 
researching for RxAda I read mostly RxJs, RxJava and RxCpp, and with the 
former two I had no problems, but RxCpp examples where very ugly/messy 
to my eyes. It's true that at the time I had very little experience with 
C++ lambdas.

> (I had a nightmare one time where the ISO14889 C++ standards body started to utilize APL symbols to take the cryptosyntax to a whole new level.)

Re: Ada-Oriented GUI

[Dan'l Miller]

On Sunday, March 18, 2018 at 8:33:26 AM UTC-5, Jeffrey R. Carter wrote:
> Those interested can find Ada_GUI at
> 
> https://github.com/jrcarter/Ada_GUI

“… a better design for a GUI is for the GUI to have its own task, so it doesn't require that its client give up a thread of control. GUI events are communicated to the client through a protected queue of events. The client software can be written in the clearest way possible, unconstrained by the GUI.”

Although I am sympathetic to your goals* in general, please allow me to play devil's advocate for the current status quo thread design in nearly all GUI-equipped OSes.  The GUI does in fact have its own thread:  the main thread of the process.  The “client software can be written in the clearest way possible, unconstrained by the GUI” by executing on one or more threads other than the main thread.  These other threads may be of any design imaginable (other than being the main thread).

* One laudable goal is your de-emphasizing/eliminating of subroutine invocation on the main thread.  In most modern app designs, nearly all processing that is not highly-tied to the GUI is performed on additional threads other than the main thread.  But invariably the final stage of processing is to do something that delivers the results to the GUI executing on the main thread.  Invariably, nearly all modern GUI-equipped OSes have a execute-this-subroutine/lambda-on-the-main-thread call in the GUI framework.  This is silly over-emphasis on subroutines, when an interthread message queue (from the backend-processing threads to the GUI thread) would be the superior design.  Asynchronous subroutine invocations from the GUI on the main thread (with this concomitant increase in callbacks contributing to Callback Hell) is yet another dubious ‘innovation’ needed to work around the lack of a message-queue-based GUI; one gets async for free implicitly with message-queue-based designs.

> Those who like programming by extension won't like it.

No programming by extension?  I'd say that you just haven't gone far enough down that message-based design road yet:  Note that tag-length-value (TLV) has been successfully utilized for decades throughout many IETF message formats to provide programming-by-extension-esque capabilities to message-queue-/messaging-based systems, when operating under the proviso that any tag that the recipient does not recognize is to be ignored due to being from a subsequent/newer release of software.  Hence, programming-by-extension(-via-OO-methods-as-subroutine-invocations) as commonly conceived is not entirely incompatible with messages in a message-queue-based system.  The focus changes from subroutine invocation to ignoring TLVs in recipients equipped with older/less-featured software and processing those feature-added TLVs in recipients equipped with newer/more-full-featured software.  The mechanism of programming by extension merely changes; the concept itself does not.

Re: Ada-Oriented GUI

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:f69b294b-414c-46ff-8c2b-23eb0ab4ccd6@googlegroups.com...
On Sunday, March 18, 2018 at 8:33:26 AM UTC-5, Jeffrey R. Carter wrote:
>> Those interested can find Ada_GUI at
>>
>> https://github.com/jrcarter/Ada_GUI
>
>". a better design for a GUI is for the GUI to have its own task, so it
>doesn't require that its client give up a thread of control. GUI events are
>communicated to the client through a protected queue of events. The
>client software can be written in the clearest way possible, unconstrained
>by the GUI."
>
>Although I am sympathetic to your goals* in general, please allow me to
>play devil's advocate for the current status quo thread design in nearly 
>all
> GUI-equipped OSes.  The GUI does in fact have its own thread:  the
> main thread of the process.  ...

I can't speak to all such systems, but the above is definitely not true of 
Windows Win32. The GUI can be on any thread that it likes, the restriction 
is that one needs to use a single thread to create windows and receive 
messages. (Any thread can do other operations.) We took advantage of this in 
the design of Claw, where there is a separate Ada task created solely for 
the purpose of managing the GUI. On top of this we built a fairly 
conventional OOP design where the GUI task dispatches to appropriate 
subprograms. This allows Ada programs fairly free access to the GUI from any 
task. (It also has the downside of bringing in tasking issues into any Claw 
program, even if there aren't any explicit tasks.)

It would be easy for Jeff to build his GUI design on top of Win32, it would 
be organized somewhat like Claw internally but using a different interface 
to interact with it.

                         Randy.


                        Randy.

Re: Ada-Oriented GUI

[Dan'l Miller]

On Tuesday, March 20, 2018 at 4:34:59 PM UTC-5, Randy Brukardt wrote:
> I can't speak to all such systems, but the above is definitely not true of 
> Windows Win32. The GUI can be on any thread that it likes, the restriction 
> is that one needs to use a single thread to create windows and receive 
> messages.

That is actually not quite true either.  A window can be created by any thread, but henceforth for that window that thread becomes the UI thread for that window.  Another window with overlapping lifetime can be created on any thread (including the prior window's UI thread), but henceforth for this new window whichever thread it was created on becomes the UI thread fro that window.  The default is for all windows to be created on the Main thread, for which a dispatcher is provided.  Other threads must establish their own dispatcher for Windows events, as it is not already provided on non-Main threads.

This becomes more pronounced in post-Win32/WoW •frameworks•, such as UWP (nee WinRT).  The underlying OS is still Win32-based, but Win32 is increasingly unutilized in modern Microsoft programming.  Nowadays instead of Win32, we access all Microsoft operating systems via frameworks that are derived from ATL/COM technology, presented as DLLs with .WinMD supplementary mark-up that is accessible to the CLR for the CLR-based managed-runtime languages (i.e., C#, F#, Visual Basic, C++/CLI) and accessible in translation to processor-native languages (i.e., C++/CX*, C++/WinRT**).

* C++/CX is C++/CLI reworked to not compile to bytecode, but using the same grafted-on “divided by” C#-esque language to access the DLLs-with-.winMD-markup.

** C++/WinRT is ISO standard C++ that uses a code generator to move much of what C++/CX does at runtime to access the DLLs-with-.winMD-markup to build-time, so that /CLI's & /CX's grafted-on “divided by” C#-esque language is no longer necessary to access the DLLs-with-.windMD-markup.

Because Win32 is increasingly obsolescent, let's look at precisely what I was mentioning above regarding back-end processing threads submitting subroutines to execute on the window's “contract” UI thread.  Note CoreDispatcher's RunAsync family of methods that do precisely what I mentioned originally:  “Invariably, nearly all modern GUI-equipped OSes have a execute-this-subroutine/lambda-on-the-main-thread call in the GUI framework.”  To handle the UWP/WinRT era since Windows 8, I should have defined the term “each window's contract UI thread” and then said that on Android, iOS, and MacOS the contract UI thread is absolutely limited to the main thread for all windows/views, and the path of least resistance on UWP/WinRT is for the main thread to be the sole contract UI thread for all windows.

https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Core.CoreDispatcher

> (Any thread can do other operations.) We took advantage of this in 
> the design of Claw, where there is a separate Ada task created solely for 
> the purpose of managing the GUI. On top of this we built a fairly 
> conventional OOP design where the GUI task dispatches to appropriate 
> subprograms. This allows Ada programs fairly free access to the GUI from any 
> task. (It also has the downside of bringing in tasking issues into any Claw 
> program, even if there aren't any explicit tasks.)
> 
> It would be easy for Jeff to build his GUI design on top of Win32,

I never said that it wouldn't be.  I was saying that rarely is a design tied to absolutely running nontrivial amounts of non-UI code on the Main thread.  Let's assume that the ID of Main thread is fixed as 0 or 1 is all OSes.  Very rarely is a design so incredibly fixated on running on the thread with that ID.  Most designs don't care that they are running code on thread whose ID is 17 instead of the initial/Main thread, as long as there exists a way to find thread 17 when absolutely necessary when executing code on non17 threads.  (But better designs would not make such demands.)  My devil's-advocate point is:  what on Earth is the big deal about this design flexibility to demand that UI processing be performed on one or more non-Main thread(s)?  If a design is fixated on this dubious axiom as a immovable-mountain requirement, then it absolutely is •never• portable to Android, iOS, and MacOS to name a few, where UI processing is absolutely limited to executing on the main thread in the modern frameworks (legacy antiques such as XQuartz and Carbon notwithstanding on Mac).

Re: Ada-Oriented GUI

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:0a1e0664-f657-4596-9672-5440ebe4caf2@googlegroups.com...
...
>I never said that it wouldn't be.  I was saying that rarely is a design
>tied to absolutely running nontrivial amounts of non-UI code on the Main 
>thread.

Conventional sequential programs ran all of their code (UI and otherwise) on 
a single thread.

Requiring the program to be executed around the GUI forces anything 
substantial into tasks (threads), with all of the problems that entails 
(deadlock/livelock/data races/nondeterminism/required synchronization). 
Since Ada already defines the purpose and definition of the environment task 
(what you're calling the main thread), requiring using it for the GUI forced 
the entire program to be used by the GUI. And the GUI is necessarily a tiny 
part of any program that Ada is very appropriate for (that is, programs that 
need to be close to the metal and/or verifiable - a GUI itself being neither 
of these).

The problem with Claw was that it implicitly dragged those tasking issues 
into even sequential programs. Insisting on the GUI being primary makes 
those problems even worse. I'd like to see a design where the GUI was truly 
secondary (I couldn't figure it out, and I'm done caring personally).

                   Randy. 

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 21/03/2018 22:50, Randy Brukardt wrote:

> The problem with Claw was that it implicitly dragged those tasking issues
> into even sequential programs. Insisting on the GUI being primary makes
> those problems even worse. I'd like to see a design where the GUI was truly
> secondary.

Absolutely.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Bojan Bozovic]

On Wednesday, March 21, 2018 at 10:51:01 PM UTC+1, Randy Brukardt wrote:
> "Dan'l Miller" <optikos@verizon.net> wrote in message 
> news:0a1e0664-f657-4596-9672-5440ebe4caf2@googlegroups.com...
> ...
> >I never said that it wouldn't be.  I was saying that rarely is a design
> >tied to absolutely running nontrivial amounts of non-UI code on the Main 
> >thread.
> 
> Conventional sequential programs ran all of their code (UI and otherwise) on 
> a single thread.
> 
> Requiring the program to be executed around the GUI forces anything 
> substantial into tasks (threads), with all of the problems that entails 
> (deadlock/livelock/data races/nondeterminism/required synchronization). 
> Since Ada already defines the purpose and definition of the environment task 
> (what you're calling the main thread), requiring using it for the GUI forced 
> the entire program to be used by the GUI. And the GUI is necessarily a tiny 
> part of any program that Ada is very appropriate for (that is, programs that 
> need to be close to the metal and/or verifiable - a GUI itself being neither 
> of these).
> 
> The problem with Claw was that it implicitly dragged those tasking issues 
> into even sequential programs. Insisting on the GUI being primary makes 
> those problems even worse. I'd like to see a design where the GUI was truly 
> secondary (I couldn't figure it out, and I'm done caring personally).
> 
>                    Randy.

But I can imagine cases where gui would need to be verified, together with the OS itself, banking applications and applications used in hospitals to queue patient records come to mind. You're absolutely correct that applications shouldn't be designed around gui, but gui agnostic, but its all in vain if the OS itself isn't verified and nobody will bother (here's an idea, make one verified - as much as possible - posix/unix system for general use, market real time version to embedded developers which traditionally use Ada commercially, verified to DO-178C, ISO 26262 and other standards for automation, transportation and industrial use, use drivers that aren't verified from Linux or some *BSD for general use and have verified drivers for boards used in safety critical domains. There is also a problem with formal methods not being integrated in the language itself, so it's programming in Z or B with tools that generate Ada or C source, where, ideally, such intermediate steps needn't be taken. Whether programmer would use formal methods in a language or not it would depend on actual needs of a project. I havent (yet) read the book on Alphard by Shaw, Wulf and London, but they had that idea to have code verification in a language itself which could be paired with modern theorem provers. In my ideal world there wouldn't be any bugs in code, as the damage done by buggy code and hackers exploiting is enormous already. Verification would make hacking obsolete.

Re: Ada-Oriented GUI

[Bojan Bozovic]

On Thursday, March 22, 2018 at 11:58:12 AM UTC+1, Bojan Bozovic wrote:
> On Wednesday, March 21, 2018 at 10:51:01 PM UTC+1, Randy Brukardt wrote:
> > "Dan'l Miller" <optikos@verizon.net> wrote in message 
> > news:0a1e0664-f657-4596-9672-5440ebe4caf2@googlegroups.com...
> > ...
> > >I never said that it wouldn't be.  I was saying that rarely is a design
> > >tied to absolutely running nontrivial amounts of non-UI code on the Main 
> > >thread.
> > 
> > Conventional sequential programs ran all of their code (UI and otherwise) on 
> > a single thread.
> > 
> > Requiring the program to be executed around the GUI forces anything 
> > substantial into tasks (threads), with all of the problems that entails 
> > (deadlock/livelock/data races/nondeterminism/required synchronization). 
> > Since Ada already defines the purpose and definition of the environment task 
> > (what you're calling the main thread), requiring using it for the GUI forced 
> > the entire program to be used by the GUI. And the GUI is necessarily a tiny 
> > part of any program that Ada is very appropriate for (that is, programs that 
> > need to be close to the metal and/or verifiable - a GUI itself being neither 
> > of these).
> > 
> > The problem with Claw was that it implicitly dragged those tasking issues 
> > into even sequential programs. Insisting on the GUI being primary makes 
> > those problems even worse. I'd like to see a design where the GUI was truly 
> > secondary (I couldn't figure it out, and I'm done caring personally).
> > 
> >                    Randy.
> 
> But I can imagine cases where gui would need to be verified, together with the OS itself, banking applications and applications used in hospitals to queue patient records come to mind. You're absolutely correct that applications shouldn't be designed around gui, but gui agnostic, but its all in vain if the OS itself isn't verified and nobody will bother (here's an idea, make one verified - as much as possible - posix/unix system for general use, market real time version to embedded developers which traditionally use Ada commercially, verified to DO-178C, ISO 26262 and other standards for automation, transportation and industrial use, use drivers that aren't verified from Linux or some *BSD for general use and have verified drivers for boards used in safety critical domains. There is also a problem with formal methods not being integrated in the language itself, so it's programming in Z or B with tools that generate Ada or C source, where, ideally, such intermediate steps needn't be taken. Whether programmer would use formal methods in a language or not it would depend on actual needs of a project. I havent (yet) read the book on Alphard by Shaw, Wulf and London, but they had that idea to have code verification in a language itself which could be paired with modern theorem provers. In my ideal world there wouldn't be any bugs in code, as the damage done by buggy code and hackers exploiting is enormous already. Verification would make hacking obsolete.

Not queue but handle. English is a distant second language to me, and I hope you will forgive my error.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 18/03/2018 14:33, Jeffrey R. Carter wrote:
> I've written on here before that I think the traditional 
> register-callbacks-and-call-a-procedure GUI interface is a hack only 
> suitable for sequential languages, and attempted to describe my idea of 
> how a GUI for a concurrent language like Ada should work. Some have 
> expressed the opinion that such an interface is not possible.

Why do you believe that event-loop architecture is better than callback 
one? In the latter there at least no need to have an explicit loop and 
more importantly it can be made type safe if callback are primitive 
operations of interfaces.

As Randy already mentioned, your design is quite close to Windows GDK, 
but very different from other architectures.

In any case I do not see how this responds to major challenges of GUI 
design, e.g. structured filtering of events (widgets swallow events and 
re-emit higher-level ones) or inversion when a button emits events, but 
it is the handler that must process them, so the case-statement or 
dispatching choice constrained by button interface must be in the 
handler code, not in the button or its descendant.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Dan'l Miller]

On Wednesday, March 21, 2018 at 3:25:14 AM UTC-5, Dmitry A. Kazakov wrote:
> Why do you believe that event-loop architecture is better than callback 
> one? In the latter there at least no need to have an explicit loop and 
> more importantly it can be made type safe if callback are primitive 
> operations of interfaces.

The Rx family of libraries across all various languages clearly reveals that there exists a 3rd way of what API/personality is to be presented to app-domain source code, which is neither raw callbacks nor (even worse) raw event loops.

> In any case I do not see how this responds to major challenges of GUI 
> design, e.g. structured filtering of events (widgets swallow events and 
> re-emit higher-level ones)

Rx is directly aiming at solving that entire problem space.  Quite well, btw, especially regarding concurrent scheduler-based handling events arriving haphazard from drastically-different concerns:  human GUI events, application lifetime events, network traffic arrival events, asynchronous OS events (e.g., filesystem I/O), and so forth.

> or inversion when a button emits events, but 
> it is the handler that must process them, so the case-statement or 
> dispatching choice constrained by button interface must be in the 
> handler code, not in the button or its descendant.

In Rx, a different locality-of-reference is the guiding software-architectural principle:  the app-domain source code that instantiated a collection of GUI element(s) (e.g., button and its containing window/view) then almost immediately ‘declares’ (unfortunately via imperative function invocations in today's era of languages) who is to handle those events & on which threads those events are to be scheduled.  (Observation and handling those events can be declared on different threads, such as observation on the window's contract UI thread (or •the• UI thread, depending on OS) and handling on backend-processing threads.  So instead of Button or subclass thereof housing the locality-of-reference infrastructurally (as a purely library/framework matter, where the GUI infrastructure has no clue about the app-lifetime events or the network packet-arrival events or the async filesystem I/O events or so forth), it is the point of allocation/instantiation in the app-domain source code (as a balance-all-the-wildly-competing-concerns matter for the app-domain, where the app-domain can herd these disparate cats more effectively from the GUI events, lifetime events, network events, or async OS events).  Rx comes much much closer to a •composable system•, where the app-domain programmer can say effectively, “I want this river of events and that river of events and yet another river of events and still another river of events handled sanely even if interleaved arbitrarily without any of the events interrupting or conflicting with the processing of any of the other events.”  (As one might expect from a constellation of innovative technologies all coming from Microsoft Research,) Rx transforms MVVM to be a pure upstream-to-downsteam single river.  I think that it accomplishes the same river simplification to VIPER, but I am currently in the process of working all that out.  Clearly Rx's single-direction river of data(flow) in MVVM is an astronomical advance over, say, the oft-cited Callback Hell in MVC that basically become Big Ball of Mud software architecture in any significantly-complex app.

A background on callback-based VIPER & MVVM without Rx added:
https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

Re: Ada-Oriented GUI

[vincent.diemunsch]

Le mercredi 21 mars 2018 15:30:03 UTC+1, Dan'l Miller a écrit :

> The Rx family of libraries across all various languages clearly reveals that there exists a 3rd way of what API/personality is to be presented to app-domain source code, which is neither raw callbacks nor (even worse) raw event loops.
> Rx is directly aiming at solving that entire problem space.  

> Clearly Rx's single-direction river of data(flow) in MVVM is an astronomical advance over, say, the oft-cited Callback Hell in MVC that basically become Big Ball of Mud software architecture in any significantly-complex app.
> 
> A background on callback-based VIPER & MVVM without Rx added:
> https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

Dear all,

This is really impressive! It seems really appealing for lightweight parallelism.
- What are the main papers from Microsoft Research, which describe this innovative concept?
- Regarding GUI, how does the concept compares to Objective-C / Smalltalk / Classic-Ada?

Regards,

Vincent

Re: Ada-Oriented GUI

[Dan'l Miller]

On Wednesday, March 21, 2018 at 10:57:09 AM UTC-5, vincent....@gmail.com wrote:
> - What are the main papers from Microsoft Research, which describe this innovative concept?

  http://www.IntroToRx.com

  The book that I mentioned above is now free.  I had the author incorrect; he is Lee Campbell, not Ian Campbell.  (Btw, I detest Amazon's lack of Apple-iOS-esque unpinch zoom-out on deficient-UI Kindle devices to read flyspeck book-cover fonts on Kindle!)  Please refer to that book's bibliography for seminal references in the history of Rx.

> - Regarding GUI, how does the concept compares to Objective-C / Smalltalk / Classic-Ada?

I am uncertain precisely what you intend there.  Rx libraries have been ported with varying degrees of fidelity from their origin in C# and .NET
1) to nearly all general-purpose languages except for Objective-C (although a Swift port exists), Smalltalk (except a Scala port exists), and not yet publicly released for Ada
and
2) to major OS GUI frameworks:  e.g., Cocoa on iOS & MacOS; Android SDK on Android OS.

Generally, Rx for C# on .NET and Rx for Java on Android are fairly clearly the 2 most actively in the driver's seat of steering the reactive-extensions community over the past several years.  A 3-way divergence has appeared among factions of the Rx community regarding whether:
a) backpressure is best handled by Ix (interactive extensions), which is the Microsoft Research viewpoint;
b) backpressure is best handled by duplicating the entire Rx world so that in addition to Observable (which lacks backpressure) there should be Flowable (whose sole reason to exist is to provide sophisticated back pressuring mechanisms with some overhead);
c) if you think that you need backpressure in Rx, you are just not right in the head, which appears to be RxSwift community's viewpoint.  Clearly, the RxSwift community envision Rx to not apply to problem spaces that can churn out immense quantities of data flow, such reading records in a file or traversing a lengthy database table.  Clearly, the RxJava and Microsoft Research Rx communities think that LINQ-esque processing is within the purview of Rx (or its sibling Ix).

Plus, the Rx family of libraries are not the only ones available.  For example, Reactive Swift and Reactive Cocoa are coming at the reactive solution space from an entirely different perspective than the RxSwift and RxCocoa libraries in the Rx family of libraries.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 21/03/2018 15:30, Dan'l Miller wrote:

> Rx is directly aiming at solving that entire problem space.  Quite well, btw, especially regarding concurrent scheduler-based handling events arriving haphazard from drastically-different concerns:  human GUI events, application lifetime events, network traffic arrival events, asynchronous OS events (e.g., filesystem I/O), and so forth.

Scheduling implies that order of events is not preserved, right? How 
consistency is achieved?

>> or inversion when a button emits events, but
>> it is the handler that must process them, so the case-statement or
>> dispatching choice constrained by button interface must be in the
>> handler code, not in the button or its descendant.
> 
> In Rx, a different locality-of-reference is the guiding software-architectural principle:  the app-domain source code that instantiated a collection of GUI element(s) (e.g., button and its containing window/view) then almost immediately ‘declares’ (unfortunately via imperative function invocations in today's era of languages) who is to handle those events & on which threads those events are to be scheduled.

That looks like inversion, exactly, when a method is bound to the 
instance of a source GUI element and not the instance of the target. 
(e.g. to the button rather than the container box holding the button).

> “I want this river of events and that river of events and yet another river of events and still another river of events handled sanely even if interleaved arbitrarily without any of the events interrupting or conflicting with the processing of any of the other events.”

That sounds like an excellent source of deadlocks and live-locks.

But the main question is lack of structure. The hierarchy of events is 
of interest, flows do not matter.

Any GUI has 3 dimensions:

1. Events (click)
2. Containment (parent-child)
3. Functional hierarchy (button-toggle button)

Only one of them can be mapped onto a hierarchy of types. Most GUI 
choose #3. Would it be #1 instead?

> Clearly Rx's single-direction river of data(flow) in MVVM is an astronomical advance over, say, the oft-cited Callback Hell in MVC that basically become Big Ball of Mud software architecture in any significantly-complex app.

How would this work in the case of for a tree view?

> A background on callback-based VIPER & MVVM without Rx added:
> https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

OK.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Dan'l Miller]

On Wednesday, March 21, 2018 at 11:27:56 AM UTC-5, Dmitry A. Kazakov wrote:
> On 21/03/2018 15:30, Dan'l Miller wrote:
> 
> > Rx is directly aiming at solving that entire problem space.  Quite well, btw, especially regarding concurrent scheduler-based handling events arriving haphazard from drastically-different concerns:  human GUI events, application lifetime events, network traffic arrival events, asynchronous OS events (e.g., filesystem I/O), and so forth.
> 
> Scheduling implies that order of events is not preserved, right? How 
> consistency is achieved?

The order of each sequence of events from a single-threaded sender is strictly preserved in Rx (including under the numerous filtering mechanisms).  Conversely, there is no order to preserve between different single-threaded senders.  E.g., async filesystem I/O events can interleave GUI human-activity events can interleave application-lifecycle events can interleave network packet-arrival events arbitrarily and differently each execution.  Having a software architecture that obfuscates this natural lack of any inter-sender ordering is what causes deep & severe & pernicious bugs (actually worse that bugs, usually fatal-to-the-feature back-to-the-drawingboard nonrealtime design flaws and much head-scratching).  Having a software architecture that effectively says, “Hey, we've done the heavy lifting of flowing all these rivers of data to you without ruining them; now you need to do the hey-dummy-don't-ruin-them-by-comingling-them-illogically too, such as implicitly expecting a GUI event to arrive ahead of a network packet or vice versa, or implicitly expecting an app-lifecycle event to never arrive before an async filesystem I/O event.”  Rx brings •composable system• to realtime event arrival by (nearly-)demanding that the arbitrary-order events are blatantly obvious *between* different sequences (by making the preserved-order events blatantly obvious *within* any one sequence).

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 2018-03-21 18:04, Dan'l Miller wrote:
> On Wednesday, March 21, 2018 at 11:27:56 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 21/03/2018 15:30, Dan'l Miller wrote:
>>
>>> Rx is directly aiming at solving that entire problem space.  Quite well, btw, especially regarding concurrent scheduler-based handling events arriving haphazard from drastically-different concerns:  human GUI events, application lifetime events, network traffic arrival events, asynchronous OS events (e.g., filesystem I/O), and so forth.
>>
>> Scheduling implies that order of events is not preserved, right? How
>> consistency is achieved?
> 
> The order of each sequence of events from a single-threaded sender is strictly preserved in Rx (including under the numerous filtering mechanisms).

So it is inconsistent unless packed into single thread. No difference, 
exiting GUI do just same.

> Conversely, there is no order to preserve between different single-threaded senders.

Surely there is. The order is application level semantics. Threads are 
possibly implementation artifacts, e.g. worker tasks.

(This is a general problem of event-driven architectures. They are 
non-scalable, non-composable, unstructured and unmaintainable when 
become large).

> E.g., async filesystem I/O events can interleave GUI human-activity events can interleave application-lifecycle events can interleave network packet-arrival events arbitrarily and differently each execution.

I don't see how this is related to GUI design issues, except that when 
file system I/O indirectly cause GUI events. Then ordering of the events 
(output-pending, output-complete) must evidently be preserved when used 
in a progress indicator.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Dan'l Miller]

On Wednesday, March 21, 2018 at 12:43:04 PM UTC-5, Dmitry A. Kazakov wrote:
> So it is inconsistent unless packed into single thread. No difference, 
> exiting GUI do just same.

  Yes, it is customary (or required in most OSes/frameworks) for all UI processing to be in the same single thread.  Even in Microsoft Windows' various API/personality flavors, it is required for all UI processing within the same window to be performed in the same single thread.  From my reading of Jeffrey Carter's description of his work, he was continuing this precedent of all UI processing in a single thread, simply moving it off from the main thread to some other single thread.

> > Conversely, there is no order to preserve between different single-threaded senders.
> 
> Surely there is.

  Surely in the progress of time in reality, there is not.  This asynchrony is the basis of realtime systems.

> The order is application level semantics.

  Then the application is maldesigned, not conforming to the asynchrony of the various autonomous timelines in reality.

> (This is a general problem of event-driven architectures. They are 
> non-scalable, non-composable, unstructured and unmaintainable when 
> become large).

  Rx is clearly chipping away at that increasingly obsolescent state of affairs.  Please read the books.

> > E.g., async filesystem I/O events can interleave GUI human-activity events can interleave application-lifecycle events can interleave network packet-arrival events arbitrarily and differently each execution.
> 
> I don't see how this is related to GUI design issues,

It is unrelated to designing a GUI per se at Microsoft or at Apple or at Google.  It is highly related to designing an •application• that is built atop that GUI infrastructure.

> except that when 
> file system I/O indirectly cause GUI events. Then ordering of the events 
> (output-pending, output-complete) must evidently be preserved when used 
> in a progress indicator.

So you don't see that all permutations of unavoidable race conditions in disparate topics (that naturally occur in reality before a software design ever existed) need to be sanely handled a posteriori in a nonpanicky methodical disciplined-structure way.  Apparently, you think that all race conditions from every nook & cranny of every corner of reality can somehow be defined away a priori by some sort of superdooper clever design.  Well, more power to you then, because you can show all those Rx folks where their entire worldview is horribly wrong from the git-go.  We look forward to seeing that superdooper clever a priori design that shows all the aficionados of a posteriori where they went awry.

Re: Ada-Oriented GUI

[Simon Wright]

"Dan'l Miller" <optikos@verizon.net> writes:

> On Wednesday, March 21, 2018 at 12:43:04 PM UTC-5, Dmitry A. Kazakov wrote:

>> except that when file system I/O indirectly cause GUI events. Then
>> ordering of the events (output-pending, output-complete) must
>> evidently be preserved when used in a progress indicator.
>
> So you don't see that all permutations of unavoidable race conditions
> in disparate topics (that naturally occur in reality before a software
> design ever existed) need to be sanely handled a posteriori in a
> nonpanicky methodical disciplined-structure way.

I suspect that Dmitry only meant that output-pending must occur before
output-complete, whichever thread you view it from.

Re: Ada-Oriented GUI

[Dan'l Miller]

On Wednesday, March 21, 2018 at 2:11:13 PM UTC-5, Simon Wright wrote:
> I suspect that Dmitry only meant that output-pending must occur before
> output-complete, whichever thread you view it from.

I assume that output here is event emission from the head-end of the river from the upstream perspective of producing output to downstream receivers that handle that output-from-upstream as input.  Event emission occurs in sequence from a single-threaded source in Rx.  Operating under than axiom, of course, events in flight within a sequence must occur and do get transmitted in sequence prior to later transaction-ending events unless those events in flight were declared (at the time of subscription) to be lossy & worthless upon successful or aberrant termination of the sequence.  Each sequence lacks asynchrony within itself, hence the term sequence.  Each sequence (as per a composable system) may be declared to retire/commit its own transactions independently of any pestering from any other sequences.  Each sequence (as per a composable system) may be declared to merge events from 2 or more sequences where those upstream events impact the processing of each other (e.g., Twitter newsfeed event arrival need to be rendered differently now that the human being rotated from portrait to landscape orientation; all that needs to done more power-conservingly now that the battery just crossed the 20% capacity in the downward direction; oh forget about all that right now! your all-hands-on-deck the-sky-is-falling stock-price trigger that you set last month just fired indicating that you should be urgently managing at your investment portfolio, not wasting time & precious battery power on Twitter; and so forth among drastically disparate realtime concerns).

(Here I am eliding the Rx jargon.  The river metaphor here is properly Rx's sequence [or also stream in RxJava].  The head-end metaphor here is properly Rx's Observable.  The downstream receiver metaphor here is properly Rx's Subscriber.  and so forth)

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 2018-03-21 20:51, Dan'l Miller wrote:
> On Wednesday, March 21, 2018 at 2:11:13 PM UTC-5, Simon Wright wrote:
>> I suspect that Dmitry only meant that output-pending must occur before
>> output-complete, whichever thread you view it from.
> 
> I assume that output here is event emission from the head-end of the river from the upstream perspective of producing output to downstream receivers that handle that output-from-upstream as input.  

This is not how asynchronous I/O works in many cases. The I/O request is 
queued in one thread, initiated in another, processed in third, 
completed in fourth.

Your approach seem to impose some heavy constraint not just on GUI as 
many existing frameworks do, which people really hate, but on all 
system. Good luck with that, but don't expect everybody to embrace that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Dan'l Miller]

On Wednesday, March 21, 2018 at 3:11:34 PM UTC-5, Dmitry A. Kazakov wrote:
> Your approach

  It is not (!) •my• approach!

Re: Ada-Oriented GUI

[Dan'l Miller]

Dmitry wrote: 
> This is not how asynchronous I/O works in
> many cases. The I/O request is 
> queued in one thread, initiated in another,
> processed in third, completed in fourth.

(Other than message-queue-based software architectures,) please name even one async ••system call•• on any OS or OS-framework thereof that requires traversal of those 4 ••app-domain•• threads to produce results (e.g., filesystem read) asynchronously.  I’ll bet that you cannot name even one actually extant async system call in any OS in the past 50 years to requires such a convoluted 4 (!) app-domain thread opportunity for reordering via differently-interleaved queuing at each/any of those 4 threads.

What you describe can be a hallmark of message-queue-based software architectures, message-queue software architectures are synonymous with async I/O.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 21/03/2018 23:16, Dan'l Miller wrote:
> Dmitry wrote:
>> This is not how asynchronous I/O works in
>> many cases. The I/O request is
>> queued in one thread, initiated in another,
>> processed in third, completed in fourth.
> 
> (Other than message-queue-based software architectures,)

A great number of protocol stacks work this way. Almost all I/O 
libraries deploy callbacks on data arrival.

Some have the design alike to GUI when you are forced to call something 
like Do_IO from a thread and get a callback from within Do_IO.

But in general nothing in said or required about the contexts of any 
calls and callbacks.

> please name even one async ••system call•• on any OS or OS-framework thereof that requires traversal of those 4 ••app-domain•• threads to produce results (e.g., filesystem read) asynchronously.

I don't really know what you mean.

Windows overlapped I/O queues a request from your thread. When I/O is 
initiated it can traverse a number of kernel threads (e.g. Deferred 
Procedure Call etc). Any number of user-space threads can wait for 
associated Windows event objects or poll the overlapped I/O result.

> What you describe can be a hallmark of message-queue-based software architectures, message-queue software architectures are synonymous with async I/O.

No, it is not. Messaging means marshaling.

That is not always required or used. Some implementations do in-place 
I/O by mapping user buffers into the memory if the process margin must 
be crossed.

BTW, Ada's rendezvous model was designed to avoid marshaling.

Anyway, as Randy already said, it is incredibly uncomfortable to build 
the whole application around GUI. The first and foremost requirement for 
a decent GUI framework is to let us breath.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Dan'l Miller]

On Thursday, March 22, 2018 at 4:12:17 AM UTC-5, Dmitry A. Kazakov wrote:
> On 21/03/2018 23:16, Dan'l Miller wrote:
> > Dmitry wrote:
> >> This is not how asynchronous I/O works in
> >> many cases. The I/O request is
> >> queued in one thread, initiated in another,
> >> processed in third, completed in fourth.
> > 
> > (Other than message-queue-based software architectures,)
> 
> A great number of protocol stacks work this way. Almost all I/O 
> libraries deploy callbacks on data arrival.
> 
> Some have the design alike to GUI when you are forced to call something 
> like Do_IO from a thread and get a callback from within Do_IO.
> 
> But in general nothing in said or required about the contexts of any 
> calls and callbacks.
> 
> > please name even one async ••system call•• on any OS or OS-framework thereof that requires traversal of those 4 ••app-domain•• threads to produce results (e.g., filesystem read) asynchronously.
> 
> I don't really know what you mean.

Yes, you are correct:  you do not understand.

> Windows overlapped I/O queues a request from your thread. When I/O is 
> initiated it can traverse a number of kernel threads (e.g. Deferred 
> Procedure Call etc). Any number of user-space threads can wait for 
> associated Windows event objects or poll the overlapped I/O result.

You would put app-domain GUI and GUI-facing presentation (e.g., VIPER presenter) layers in the kernel?  Oh my goodness you are incredibly bad at software architecture.  Rx is a technology for within an app-domain UI and UX processing, and perhaps the UX-facing interface-façade of backend processing.

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

VIPER architecture best partitions UI, UX, and back-end processing for an app-domain—none of which is unwisely in the kernel as you would suggest.  The nonportable peculiar-to-OS/framework portions of the app-domain's UI (either GUI or ChUI or command-line) go in a VIPER view layer.  The portable generic-among-all-OSes/frameworks portions of the app-domain's UX go in a VIPER presenter and router layers. VIPER interactor and entities layer is where all the app-domain backend processing occurs.  Rx is intended for the VIPER view, presenter, and router layers.  Rx or Ix overt representation of dataflows-of-VIPERentities might find usefulness in some portions of the interactor layer, but this is a matter of personal taste.  Certainly, Rx and Ix (as currently formulated) would never cross into kernel space.  Dmitry, you are so far off in the weeds there.

> Anyway, as Randy already said, it is incredibly uncomfortable to build 
> the whole application around GUI.

  I agree.  That is why VIPER is the best software architecture so far for app-domains that contain UI/UX (when compared to the MVC and MVVM ilk) because VIPER clearly quarantines UX away from backend processing, and VIPER clearly quarantines nonportable OS-specific/framework-specific app-domain UI from portable UX.  Dmitry, if you haven't stayed current with VIPER, you really should, because VIPER is embraces your/our school of thought.

> The first and foremost requirement for 
> a decent GUI framework is to let us breath[e].

  VIPER's strict quarantining of UX & UI away from all backend processing in interactors & entities provides you not only the enormous space to breathe, but also sharp & fierce software-architectural weapons to push back on the UI/UX people to stay within only their quarantined areas, not polluting the backend processing.

That being said, Ix begat Rx historically; Ix originated within backend processing (what VIPER calls interactors) of data (what VIPER calls entities, as a hat tip to thin OO representation of each record).  Then someone noticed that Ix's pull-based semantics could be reversed as push-based semantics to be repurposed to event-driven UI/UX.  Even in backend app-domain processing (in user-space, not kernel-space, as you suggest), there is a natural progression to move away from thinking about verb-centric actions (i.e., 1970s structured programming) to verbs-subjugated-to-noun-centric encapsulation (i.e., 1980s/1990s OO) to rivers of nouns/data/entities channelized into verb processing (i.e., Rx and Ix in the 2010s).  Rx is not unlike wire-speed processing of packets in modern network processors:  focus on the channelized dataflow as a river flowing by, picking out a filtered datum as it flows by to operate on it under realtime deadlines to keep up with the flowrate of the river.  It is merely the natural progression of the Zeitgeist, whose societal exhaled-breath wind has been blowing in this direction for around 50 years now.

Re: Ada-Oriented GUI

[Bojan Bozovic]

That's a bit contrived, if we look at program and presentation as client server architecture, client or the UI must know how the server functions and then use some form of IPC to communicate to the server, server needn't know anything about the client. Example chess engine uses IPC to communicate e2-e4 to UI which must respond for example e7-e5 player response within certain time no matter whether it uses ncurses, 2D graphics, or OpenGL, and receive next move e. Kf3 to display to the player. How this can be done to fully separate UI client from the chess engine server? Sorry if the question is dumb :-) I can't get how Apple separated UI from logic

Re: Ada-Oriented GUI

[Dan'l Miller]

On Wednesday, March 21, 2018 at 5:16:18 PM UTC-5, Dan'l Miller wrote:
> What you describe can be a hallmark of message-queue-based software architectures, message-queue
> software architectures are synonymous with async I/O.

I left out the not there.  Obviously in the flow of logic there, I meant:

What you describe can be a hallmark of message-queue-based software architectures, message-queue
software architectures are NOT synonymous with async I/O.

Re: Ada-Oriented GUI

[Alejandro R. Mosteo]

On 21/03/18 21:11, Dmitry A. Kazakov wrote:
> On 2018-03-21 20:51, Dan'l Miller wrote:
>> On Wednesday, March 21, 2018 at 2:11:13 PM UTC-5, Simon Wright wrote:
>>> I suspect that Dmitry only meant that output-pending must occur before
>>> output-complete, whichever thread you view it from.
>>
>> I assume that output here is event emission from the head-end of the 
>> river from the upstream perspective of producing output to downstream 
>> receivers that handle that output-from-upstream as input. 
> 
> This is not how asynchronous I/O works in many cases. The I/O request is 
> queued in one thread, initiated in another, processed in third, 
> completed in fourth.

I'm not sure I'm understanding the gist of this point of the 
conversation, but exactly that kind of thread-hopping is trivial to 
write in Rx.

> Your approach seem to impose some heavy constraint not just on GUI as 
> many existing frameworks do, which people really hate, but on all 
> system. Good luck with that, but don't expect everybody to embrace that
Rx certainly imposes a way of thinking, most like using a functional 
language does. It's not an all-or-nothing thing though, there is a 
well-defined entry and exit point. Also, there's something pleasurable 
about it, is like connecting dots to make a picture, or matching puzzle 
pieces.

Re: Ada-Oriented GUI

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com...
...
>> The order is application level semantics.
>
>  Then the application is maldesigned, not conforming to the
> asynchrony of the various autonomous timelines in reality.

Maybe, but analysis of such asychronous events (unless *completely* 
separate, in which case they should be in separate programs) is beyond the 
capabilities of tools or humans except in the most trivial of cases. This 
leads to either being able to have correct code or code that really well 
models the system -- but never both. Ada of course leans toward correctness, 
as do I. The alternative is primarily garbage - that might appear to work 
but no one will ever know for sure.

                      Randy.

Re: Ada-Oriented GUI

[G. B.]

Randy Brukardt <randy@rrsoftware.com> wrote:
> The alternative is primarily garbage - that might appear to work 
> but no one will ever know for sure.

In other words, the alternative to correctness oriented
Ada is the perfect choice for sales.

Re: Ada-Oriented GUI

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com...
On Wednesday, March 21, 2018 at 12:43:04 PM UTC-5, Dmitry A. Kazakov wrote:
>> So it is inconsistent unless packed into single thread. No difference,
>> exiting GUI do just same.

>Well, more power to you then, because you can show all those Rx folks
>where their entire worldview is horribly wrong from the git-go.

Obviously. :-) Their worldview appears to be that writing software that is 
actually correct is impossible, so let's not even try. The dustbin of 
history is full of ideas spawned by intelligent, well-meaning people (I can 
give plenty of examples even with Ada).

If I'm wrong, then kill me. Please! A world where no program can be correct 
is not a world that I can contribute to nor have any interest in living in.

                            Randy.

Re: Ada-Oriented GUI

[Dan'l Miller]

On Wednesday, March 21, 2018 at 5:33:43 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller"  wrote in message 
> news:26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com...
> On Wednesday, March 21, 2018 at 12:43:04 PM UTC-5, Dmitry A. Kazakov wrote:
> >> So it is inconsistent unless packed into single thread. No difference,
> >> exiting GUI do just same.
> 
> >Well, more power to you then, because you can show all those Rx folks
> >where their entire worldview is horribly wrong from the git-go.
> 
> Obviously. :-) Their worldview appears to be that writing software that is 
> actually correct is impossible, so let's not even try.

Here you seem to considering the only correct program to be one that cavalierly mandates a designer-prescribed order to the arrival of UX-affecting events, from all of the UI, the OS, the network, and the completion of long-running backend processing.  Why is such an engineering-time whim the only definition of correctness.  Why is an engineering-time a-priori prescriptive order of event-arrival more correct than Rx's a-posteriori meticulous categorization & marshaling of a descriptive order of event-arrival so that all the outcome orderings can be overtly handled properly?

> The dustbin of 
> history is full of ideas spawned by intelligent, well-meaning people (I can 
> give plenty of examples even with Ada).

Some people have been trying to throw Ada into the dustbin of history several times over the decades.  And their efforts have partially succeeded:  the pro-Ada fervor on university campuses from the late-1970s through around 1990-ish* seems to have faded in North America, supplanted by Java Java Everywhere as the new mantra.

* when C++ non-cfront machine-code-generating-backend compilers reached some fractional degree of feature parity with then-extant Ada compilers

> If I'm wrong, then kill me. Please! A world where no program can be correct 
> is not a world that I can contribute to nor have any interest in living in.

A circle of friends devise a way of disciplining & marshaling & scheduling the arrival of an otherwise disparate cacophony of event flows occurring as a nature-of-the-beast in the real world, where that circle of friends has relatively little overlap with your circle of friends—and that is why you want to end it all?  Sheesh.  I don't know if I can talk you down from the ledge, Randy.  :-)  I suppose you could try to suppress the release of any RxAda library from now until the end of time to keep humanity safe from the reactive scourge of introducing a form of data-flow processing to Ada.  That would be one strategy to make life worth living, I suppose.

Re: Ada-Oriented GUI

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com...
On Wednesday, March 21, 2018 at 5:33:43 PM UTC-5, Randy Brukardt wrote:
>> "Dan'l Miller"  wrote in message
>> news:26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com...
>> On Wednesday, March 21, 2018 at 12:43:04 PM UTC-5, Dmitry A. Kazakov 
>> wrote:
>> >> So it is inconsistent unless packed into single thread. No difference,
>> >> exiting GUI do just same.
>>
>> >Well, more power to you then, because you can show all those Rx folks
>> >where their entire worldview is horribly wrong from the git-go.
>>
>> Obviously. :-) Their worldview appears to be that writing software that 
>> is
>> actually correct is impossible, so let's not even try.
>
>Here you seem to considering the only correct program to be one that 
>cavalierly
>mandates a designer-prescribed order to the arrival of UX-affecting events,
>from all of the UI, the OS, the network, and the completion of long-running
>backend processing.

No, a correct program is one that can be reasoned about. And one cannot 
reason about programs that contain race conditions ("unavoidable" or not). 
One has to impose some sort of structure to avoid race conditions/dead 
locks/live locks, lest the program be unanalyzable. And to have any chance 
of believing a program is correct requires analysis.

> Why is such an engineering-time whim the only definition of correctness.
> Why is an engineering-time a-priori prescriptive order of event-arrival 
> more
> correct than Rx's a-posteriori meticulous categorization & marshaling of a
> descriptive order of event-arrival so that all the outcome orderings can 
> be
> overtly handled properly?

I have no idea what this even means. One has to architect the application so 
that there is very limited interaction between tasks, and that interaction 
has to be carefully controlled (usually via rendezvous or protected 
objects). This has nothing to do with the UI or IO or any other "events". 
It's probably easiest for most to just manage the UI in the single task, 
because that gets the mess of "events" away from the bulk of the processing. 
(Ada is wildly inappropriate for applications that are mostly GUI - use some 
web-based langauge for that and use Ada for the heavy-duty processing.)

>> The dustbin of
>> history is full of ideas spawned by intelligent, well-meaning people (I 
>> can
>> give plenty of examples even with Ada).
>
>Some people have been trying to throw Ada into the dustbin of history
>several times over the decades.  And their efforts have partially
>succeeded:  the pro-Ada fervor on university campuses from the
>late-1970s through around 1990-ish* seems to have faded in North
>America, supplanted by Java Java Everywhere as the new mantra.

For my purposes, the possibility of Ada ever being commercially successful 
were done by 1990, even though it took me until about 1998 to admit it. 
Since I stopped caring about that, I sleep a lot better. Most people are 
idiots after all, and there is a point at which one should admit defeat on 
appealing to them...

Why have I stuck with Ada since? Mainly because everything else out there is 
far worse, and there's little chance of success with them, either. If I'm 
going to be a failure, at least I will have failed with the best possible 
programming language.

>> If I'm wrong, then kill me. Please! A world where no program can be 
>> correct
>> is not a world that I can contribute to nor have any interest in living 
>> in.
>
>A circle of friends devise a way of disciplining & marshaling & scheduling 
>the
>arrival of an otherwise disparate cacophony of event flows occurring as a
>nature-of-the-beast in the real world,

Sorry, I don't buy the notion that a "cacophony of event flows" is a 
requirement in the real world. One can reasonably impose order without 
harming the modelling of the "real world". And one has to do that if they 
want any reliability in the resulting program.

>...where that circle of friends has relatively little overlap with your 
>circle of
>friends-and that is why you want to end it all?  Sheesh.  I don't know if I
>can talk you down from the ledge, Randy.  :-)

Don't try, my mother has never been able to do it...

>I suppose you could try to suppress the release of any RxAda library from
>now until the end of time to keep humanity safe from the reactive scourge
>of introducing a form of data-flow processing to Ada.  That would be one
>strategy to make life worth living, I suppose.

The presence of one more library that no one much uses isn't going to bother 
me much. :-)

But I've spent my entire life attempting to bring correctness to 
programming, with the ultimate (unachievable) goal of a compiler/language 
system that detects/prevents all possible bugs from ever going undetected in 
a fielded system. (Let's temper "possible" here with the idea that a system 
that does precisely what the programmer intended -- but that intent is 
wrong -- is not considered a bug in this model.)

I came to Ada in large part because it promised to be a great platform for 
such a system (well, that and the fact that it had by far the most sensible 
syntax of the contenders in 1980).

For sequential programs, Ada is pretty much there. I've been working on 
Janus/Ada infrastructure improvements without even trying to find the code 
that needs to be modified -- the compiler/run-time tells me where changes 
are needed far quicker than trying to look for them by hand. (One has to 
design their code to enable this sort of thing in the first place, but that 
pays off many times if the program has any sort of lifetime.)

One of the goals of Ada 2020 is to bring that level of reliability to 
parallel programming. That means the compiler has to (conservatively) 
diagnose and reject data races between separately executed code.

A system that decides to just ignore race conditions as "unavoidable" is 
going in the wrong direction. Most likely, it will kill us all when it's 
running self-driving cars and autopilots.

                                       Randy.

Re: Ada-Oriented GUI

[Dan'l Miller]

On Thursday, March 22, 2018 at 6:47:28 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com...
> On Wednesday, March 21, 2018 at 5:33:43 PM UTC-5, Randy Brukardt wrote:
> >> "Dan'l Miller"  wrote in message
> >> news:26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com...
> >> On Wednesday, March 21, 2018 at 12:43:04 PM UTC-5, Dmitry A. Kazakov 
> >> wrote:
> >> >> So it is inconsistent unless packed into single thread. No difference,
> >> >> exiting GUI do just same.
> >>
> >> >Well, more power to you then, because you can show all those Rx folks
> >> >where their entire worldview is horribly wrong from the git-go.
> >>
> >> Obviously. :-) Their worldview appears to be that writing software that 
> >> is
> >> actually correct is impossible, so let's not even try.
> >
> >Here you seem to considering the only correct program to be one that 
> >cavalierly
> >mandates a designer-prescribed order to the arrival of UX-affecting events,
> >from all of the UI, the OS, the network, and the completion of long-running
> >backend processing.
> 
> No, a correct program is one that can be reasoned about. And one cannot 
> reason about programs that contain race conditions ("unavoidable" or not). 
> One has to impose some sort of structure to avoid race conditions/dead 
> locks/live locks, lest the program be unanalyzable. And to have any chance 
> of believing a program is correct requires analysis.
> 
> > Why is such an engineering-time whim the only definition of correctness.
> > Why is an engineering-time a-priori prescriptive order of event-arrival 
> > more
> > correct than Rx's a-posteriori meticulous categorization & marshaling of a
> > descriptive order of event-arrival so that all the outcome orderings can 
> > be
> > overtly handled properly?
> 
> I have no idea what this even means.

Then you should study up on Rx, especially from the more-academic research origins.  Rx is trying to teach something regarding completely inventorying, categorizing, and mapping/folding/conflating the otherwise combinatorial explosion of different event-arrival orderings to instead be of linear or sublinear complexity that is manageable in a design (and verifiable at compile-time if Rx were moved to compile-time declarations to an Rx-equipped compiler).

> One has to architect the application so 
> that there is very limited interaction between tasks,

Not everything in the world is an Ada task of calculable maximum realtime execution time.

> ...
> >I suppose you could try to suppress the release of any RxAda library from
> >now until the end of time to keep humanity safe from the reactive scourge
> >of introducing a form of data-flow processing to Ada.  That would be one
> >strategy to make life worth living, I suppose.
> 
> The presence of one more library that no one much uses isn't going to bother 
> me much. :-)

By the 2020s (the target marketstpace for Ada2020), Rx won't be in mere libraries.  Rx will have been moved to compile-time declarations of the dataflows so that they can be checked for completeness to assure that no categorization is incomplete.

> But I've spent my entire life attempting to bring correctness to 
> programming, with the ultimate (unachievable) goal of a compiler/language 
> system that detects/prevents all possible bugs from ever going undetected in 
> a fielded system.

  Then move Rx to compile-time declarations instead.  Just as in omitting a case can be detected for enumerations at compile-time, omitted categorization of an unhandled order of arrival can conceivably be detected at compile-time if the declarations were known to an Rx-equipped compiler at compile-time.  Today's Rx is merely a prototype of what is to come in future languages at compile-time.

> ... I've been working on 
> Janus/Ada infrastructure improvements without even trying to find the code 
> that needs to be modified -- the compiler/run-time tells me where changes 
> are needed far quicker than trying to look for them by hand. (One has to 
> design their code to enable this sort of thing in the first place, but that 
> pays off many times if the program has any sort of lifetime.)

Hear hear!  I have been doing that myself for nearly 20 years.  I call it having a conversation with the compiler.

> One of the goals of Ada 2020 is to bring that level of reliability to 
> parallel programming. That means the compiler has to (conservatively) 
> diagnose and reject data races between separately executed code.

How will the ARG assure itself that it is not on a fool's errand?  There is always at least one more origin of events outside not only your control, but outside your visibility.  Arrival of a packet over a network.  Completion of long-running batch operation.  The requested async filesystem read just arrived.  Ooops, your virtual machine was migrated between data-centers in the cloud, and while you were dormant all sorts of once-pending events arrived & finished all higgly piggly as no longer pending, including some rare timeouts that need to be retried only in this bizarre data-center-migration situation.  The compiler's omniscience can never be omniscient enough to see all event dependencies outside a program.  Hence, the Ada2020-compliant compiler will be provably correct for a minority subset of events contained only in the small world of Ada source code and completely blind to a majority of the real-world events arriving from outside Ada source code.

> A system that decides to just ignore race conditions as "unavoidable" is 
> going in the wrong direction. Most likely, it will kill us all when it's 
> running self-driving cars and autopilots.

An entirely a-priori system that fails to a-posteriori-ly overtly inventory, categorize, and map/fold (i.e., prune/conflate the branches of) the combinatorial explosion of this-before-that and that-before-this uncontrollable arrival times of real-world events to conflate it to, say, linear or sublinear growth instead of the natural exponential-growth combinatorial explosion is a system whose excessively myopic compile-time mathematical proofs are based on the wrong axiom system and the wrong possible-world in modal logic.

Re: Ada-Oriented GUI

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:a913d10c-7799-4ec3-9357-d94e9da2deb7@googlegroups.com...
On Thursday, March 22, 2018 at 6:47:28 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message
> news:656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com...
...
>> > Why is such an engineering-time whim the only definition of 
>> > correctness.
>> > Why is an engineering-time a-priori prescriptive order of event-arrival 
>> > more
>> > correct than Rx's a-posteriori meticulous categorization & marshaling 
>> > of a
>> > descriptive order of event-arrival so that all the outcome orderings 
>> > can be
>> > overtly handled properly?
>>
>> I have no idea what this even means.
>
>Then you should study up on Rx, especially from the more-academic research
>origins.  Rx is trying to teach something regarding completely 
>inventorying,
>categorizing, and mapping/folding/conflating the otherwise combinatorial
>explosion of different event-arrival orderings to instead be of linear or
>sublinear complexity that is manageable in a design (and verifiable at
>compile-time if Rx were moved to compile-time declarations to an
>Rx-equipped compiler).

A complete waste of time to stidy the jargon de-jour. Most of these things 
fade away without a trace in a couple of years. And the "problem" is 
self-inflicted - if you model anything as "events", you are already lost, 
regardless of how one implements that.

Microsoft in particular invents and releases some totally new technology 
every year or two. Most ends up with no traction whatsoever. I learned to 
stop caring because otherwise trying to keep up would drive one insane (and 
also prevent actually accomplishing anyway -- I've always figured that was 
one of Microsoft's main goals with developers, as it explains most of the 
things that they do from Solitare to changing the GUI every year.)

Moreover, I am not much interested in purely academic ideas. Particularly 
about programming, since the majority of it will be gone in a decade or so 
anyway. (Luckily, that corresponds with my official retirement date...). I'm 
mostly interested in the part that requires correctness, and that part has 
little to do with "events".

>> One has to architect the application so
>> that there is very limited interaction between tasks,
>
>Not everything in the world is an Ada task of calculable maximum realtime 
>execution time.

??? I've never once used an Ada task with "maximum realtime execution time". 
That's part of the problem using any parallel execution, IMHO

>> ...
>> >I suppose you could try to suppress the release of any RxAda library 
>> >from
>> >now until the end of time to keep humanity safe from the reactive 
>> >scourge
>> >of introducing a form of data-flow processing to Ada.  That would be one
>> >strategy to make life worth living, I suppose.
>>
>> The presence of one more library that no one much uses isn't going to 
>> bother
>> me much. :-)
>
>By the 2020s (the target marketstpace for Ada2020), Rx won't be in mere
>libraries. ...

Most likely, it will have completely disappeared. ;-)

>Rx will have been moved to compile-time declarations of the dataflows so
>that they can be checked for completeness to assure that no categorization
>is incomplete.

Ada is not the language for that, regardless of whether it works in some 
scheme, just like Ada is not the language for functional programming, even 
if you sort of can fake it for some purposes. Use a language better 
targetted to those weird special cases. Better yet, don't use any language 
at all, since most programming will be gone by then anyway. (I'm becoming 
convinced that Ada as it stands is not going to be able to appropriately 
support safe parallel programming, so we may very well be at the end of the 
lifespan of Ada anyway.)

>> But I've spent my entire life attempting to bring correctness to
>> programming, with the ultimate (unachievable) goal of a compiler/language
>> system that detects/prevents all possible bugs from ever going undetected 
>> in
>> a fielded system.
>
>  Then move Rx to compile-time declarations instead.  Just as in omitting a 
> case
>can be detected for enumerations at compile-time, omitted categorization of 
>an
>unhandled order of arrival can conceivably be detected at compile-time if 
>the
>declarations were known to an Rx-equipped compiler at compile-time. 
>Today's
>Rx is merely a prototype of what is to come in future languages at 
>compile-time.

I'm not talking about "omitting cases", something Ada has always been able 
to do very well at compile-time. Just use an appropriate enumeration. Most 
of the stuff that has come later really does not help for that (like OOP). 
The academics made such a complaint about needing to update case statements, 
but turning the declarations 90 degrees fixes nothing -- now you need to 
implement interminable overridings instead. It obviously depends on the 
problem as to whether the case statements or the overridings are bigger --  
in my programs, the overridings were much worse to deal with than updating 
the case statements.

Correctness is about verifying (preferably at compile-time) constraints and 
invariants -- on data, code, and anything else around. That is, finding bugs 
before they happen. Flow is part of that, but only a relatively small part. 
And of course, making all of those checks statically is the holy grail.


>> One of the goals of Ada 2020 is to bring that level of reliability to
>> parallel programming. That means the compiler has to (conservatively)
>> diagnose and reject data races between separately executed code.
>
>How will the ARG assure itself that it is not on a fool's errand?

We can't; that's a topic of discussion. For me personally, if we can't do 
this, then Ada is dead and I will want to be dead - there is no future in 
such a world.

>There is always at least one more origin of events outside not only your 
>control, but
>outside your visibility.  Arrival of a packet over a network.  Completion 
>of
>long-running batch operation.  The requested async filesystem read just 
>arrived.
>Ooops, your virtual machine was migrated between data-centers in the cloud, 
>and
>while you were dormant all sorts of once-pending events arrived & finished 
>all
>higgly piggly as no longer pending, including some rare timeouts that need 
>to be
>retried only in this bizarre data-center-migration situation.

If such events (that you're not interested in) aren't isolated from your 
application by the kernel, then you have a very bad architecture. And a 
massive security problem. Such an architecture has no real future unless ATT 
etc convince the public that there is no value to security and privacy. (See 
"I'd rather be dead", above.)

If they are isolated, who cares what they do? If the application depends 
upon them, then of course the compiler knows about them in the sense that 
they are handled.

>The compiler's omniscience can never be omniscient enough to see all event
>dependencies outside a program.

Why would we care about anything that happens outside of a program? One 
assumes that the virtualization and isolation of the kernel actually work. 
:-)

>Hence, the Ada2020-compliant compiler will be provably correct for a
>minority subset of events contained only in the small world of Ada source
>code and completely blind to a majority of the real-world events arriving
>from outside Ada source code.

The majority of irrelevant events. And if those events have any effect 
whatsoever on the running program (other than timing), there's a major 
archtectual problem. Besides, if you really care, you'll write the entire 
system in Ada -- Ada itself makes a fine kernel -- and then there are no 
other events even possible.

> A system that decides to just ignore race conditions as "unavoidable" is
> going in the wrong direction. Most likely, it will kill us all when it's
> running self-driving cars and autopilots.

An entirely a-priori system that fails to a-posteriori-ly overtly inventory, 
categorize, and map/fold (i.e., prune/conflate the branches of) the 
combinatorial explosion of this-before-that and that-before-this 
uncontrollable arrival times of real-world events to conflate it to, say, 
linear or sublinear growth instead of the natural exponential-growth 
combinatorial explosion is a system whose excessively myopic compile-time 
mathematical proofs are based on the wrong axiom system and the wrong 
possible-world in modal logic. 

Re: Ada-Oriented GUI

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> An entirely a-priori system that fails to a-posteriori-ly overtly
> inventory, categorize, and map/fold (i.e., prune/conflate the branches
> of) the combinatorial explosion of this-before-that and
> that-before-this uncontrollable arrival times of real-world events to
> conflate it to, say, linear or sublinear growth instead of the natural
> exponential-growth combinatorial explosion is a system whose
> excessively myopic compile-time mathematical proofs are based on the
> wrong axiom system and the wrong possible-world in modal logic.

I don't think I'll try to match that. Must be catchng. So -

Huh?!

Re: Ada-Oriented GUI

[Jeffrey R. Carter]

On 03/23/2018 12:47 AM, Randy Brukardt wrote:
> 
> A system that decides to just ignore race conditions as "unavoidable" is
> going in the wrong direction. Most likely, it will kill us all when it's
> running self-driving cars and autopilots.

Autopilots have to be certified to DO178B/C. They'll continue to be written in 
Ada and not kill us.

Self-driving cars, though operating in a much more complex environment, don't 
seem to need any certification, and will probably kill us all.

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: Ada-Oriented GUI

[Bojan Bozovic]

On Friday, March 23, 2018 at 10:05:08 AM UTC+1, Jeffrey R. Carter wrote:
> On 03/23/2018 12:47 AM, Randy Brukardt wrote:
> > 
> > A system that decides to just ignore race conditions as "unavoidable" is
> > going in the wrong direction. Most likely, it will kill us all when it's
> > running self-driving cars and autopilots.
> 
> Autopilots have to be certified to DO178B/C. They'll continue to be written in 
> Ada and not kill us.
> 
> Self-driving cars, though operating in a much more complex environment, don't 
> seem to need any certification, and will probably kill us all.
> 
> -- 
> Jeff Carter
> "From this day on, the official language of San Marcos will be Swedish."
> Bananas
> 28

So true, but complexity sells instead of correctness, so we have generations of programmers which continue to write sloppy code instead doing the right thing, and always thinking whether the work would be liked by Tony Hoare or late Edsger W. Dijkstra. For program code to be correct, DO-178B/C isn't needed, though following DO-178B/C results in correct program code.

Re: Ada-Oriented GUI

[Alejandro R. Mosteo]

On 23/03/18 10:05, Jeffrey R. Carter wrote:

> Autopilots have to be certified to DO178B/C. They'll continue to be 
> written in Ada and not kill us.
> 
> Self-driving cars, though operating in a much more complex environment, 
> don't seem to need any certification, and will probably kill us all.

I have so much fun bringing this up with my C++ mobile robotics 
colleagues :)

Killing software and certification (was: Ada-Oriented GUI)

[Alejandro R. Mosteo]

On 23/03/18 10:05, Jeffrey R. Carter wrote:

> Autopilots have to be certified to DO178B/C. They'll continue to be 
> written in Ada and not kill us.
> 
> Self-driving cars, though operating in a much more complex environment, 
> don't seem to need any certification, and will probably kill us all.

I'd like to revisit this point in light of the recent Uber news, but 
also let's not forget for example this one which is simpler than fully 
autonomous cars:

https://en.wikipedia.org/wiki/2009–11_Toyota_vehicle_recalls

I'm not in the industry, and I'd be surprised that unverified software 
were allowed to run in civilian environments where failures basically 
amount to a very dangerous situation. True, a human driver is still 
required to be ready, but let's not be disingenuous about how well that 
can work for several hours of testing/driving.

After a bit of googling around I see that there are automotive standards 
for certification (the one I see more often mentioned is ISO 26262). 
About enforcement, I also read that regulation varies by US state. I 
haven't found anything definite about Europe.

Also, it's not the same software for a drive-by-wire part than for an 
autonomous car.

I'm under the impression that these autonomous car outfits are at the 
time closer to a research environment than to that of a well-established 
industry. I.e., code is produced faster, hence bugs are more likely.

In the end I'm not sure where I want to go with this post. It's simply 
that I find the topic very interesting. If anyone with actual knowledge 
on the status of automotive software certification (or any informed 
ideas) would share some thoughts I'll be eager to read.

Álex.

Re: Killing software and certification

[Dmitry A. Kazakov]

On 2018-03-27 20:32, Alejandro R. Mosteo wrote:
> On 23/03/18 10:05, Jeffrey R. Carter wrote:
> 
>> Autopilots have to be certified to DO178B/C. They'll continue to be 
>> written in Ada and not kill us.
>>
>> Self-driving cars, though operating in a much more complex 
>> environment, don't seem to need any certification, and will probably 
>> kill us all.
> 
> I'd like to revisit this point in light of the recent Uber news, but 
> also let's not forget for example this one which is simpler than fully 
> autonomous cars:
> 
> https://en.wikipedia.org/wiki/2009–11_Toyota_vehicle_recalls
> 
> I'm not in the industry, and I'd be surprised that unverified software 
> were allowed to run in civilian environments where failures basically 
> amount to a very dangerous situation.

Why should it surprise you? How are you going to verify it? Black box 
test is impossible. White box test isn't either, assuming any NN 
involved. There is nothing to prove.

> After a bit of googling around I see that there are automotive standards 
> for certification (the one I see more often mentioned is ISO 26262). 
> About enforcement, I also read that regulation varies by US state. I 
> haven't found anything definite about Europe.

If any certification will ever be set up, it will be certification of 
the tools and developing processes/teams, not certification of the 
actual software. That is the usual backdoor to go around any questions 
about correctness.

> Also, it's not the same software for a drive-by-wire part than for an 
> autonomous car.
> 
> I'm under the impression that these autonomous car outfits are at the 
> time closer to a research environment than to that of a well-established 
> industry. I.e., code is produced faster, hence bugs are more likely.

The code used in the ECU and other car subsystems is not any better from 
that point of view. It is much simpler, deploys well-established 
algorithms and, importantly, is testable with a large set of test 
hardware and software available. That is the reason why it works better. 
But otherwise, it is just same. There is no any guarantee for it to work.

> In the end I'm not sure where I want to go with this post. It's simply 
> that I find the topic very interesting. If anyone with actual knowledge 
> on the status of automotive software certification (or any informed 
> ideas) would share some thoughts I'll be eager to read.

My understanding is that it is possible to certify about anything 
regardless the correctness.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Killing software and certification

[Alejandro R. Mosteo]

On 27/03/18 21:25, Dmitry A. Kazakov wrote:
> On 2018-03-27 20:32, Alejandro R. Mosteo wrote:
>> On 23/03/18 10:05, Jeffrey R. Carter wrote:
>>
>>> Autopilots have to be certified to DO178B/C. They'll continue to be 
>>> written in Ada and not kill us.
>>>
>>> Self-driving cars, though operating in a much more complex 
>>> environment, don't seem to need any certification, and will probably 
>>> kill us all.
>>
>> I'd like to revisit this point in light of the recent Uber news, but 
>> also let's not forget for example this one which is simpler than fully 
>> autonomous cars:
>>
>> https://en.wikipedia.org/wiki/2009–11_Toyota_vehicle_recalls
>>
>> I'm not in the industry, and I'd be surprised that unverified software 
>> were allowed to run in civilian environments where failures basically 
>> amount to a very dangerous situation.
> 
> Why should it surprise you? How are you going to verify it? Black box 
> test is impossible. White box test isn't either, assuming any NN 
> involved. There is nothing to prove.

I can think of an spectrum of regulatory/practical positions between 
'nothing can be done, so everyone brace' and 'this won't ever fail, under 
every [un]conceivable situation'. It's the apparent nonchalance of the 
general public that coexists with these testing cars, the 
brashness/recklessness of those expecting to get rich with it and the 
apparent willingness of politicians that I find fascinating (that's the 
first ones that comes to mind).

I can understand the appeal for politicians to be the first city with a 
working fleet (or whatever contributions they're getting to favor live 
testing). As a technophile, I want autonomous cars to become reality, so 
I can understand that too. As a researcher familiar with the algorithms 
involved and with the kind of C/C++/Python heaps that implement them I 
get chills about thinking that a car can be on the highway with a 
semi-awake safety driver as the only fallback in a split second.

All in all, I find the tension between all forces in conflict captivating 
to watch from a distance.

> 
>> After a bit of googling around I see that there are automotive 
>> standards for certification (the one I see more often mentioned is ISO 
>> 26262). About enforcement, I also read that regulation varies by US 
>> state. I haven't found anything definite about Europe.
> 
> If any certification will ever be set up, it will be certification of the 
> tools and developing processes/teams, not certification of the actual 
> software. That is the usual backdoor to go around any questions about 
> correctness.

I understand that now.

> 
>> Also, it's not the same software for a drive-by-wire part than for an 
>> autonomous car.
>>
>> I'm under the impression that these autonomous car outfits are at the 
>> time closer to a research environment than to that of a 
>> well-established industry. I.e., code is produced faster, hence bugs 
>> are more likely.
> 
> The code used in the ECU and other car subsystems is not any better from 
> that point of view. It is much simpler, deploys well-established 
> algorithms and, importantly, is testable with a large set of test 
> hardware and software available. That is the reason why it works better. 
> But otherwise, it is just same. There is no any guarantee for it to work.
> 
>> In the end I'm not sure where I want to go with this post. It's simply 
>> that I find the topic very interesting. If anyone with actual knowledge 
>> on the status of automotive software certification (or any informed 
>> ideas) would share some thoughts I'll be eager to read.
> 
> My understanding is that it is possible to certify about anything 
> regardless the correctness.

That's something to put in a frame :-)

Re: Killing software and certification

[Dmitry A. Kazakov]

On 28/03/2018 15:54, Alejandro R. Mosteo wrote:
> On 27/03/18 21:25, Dmitry A. Kazakov wrote:
>> On 2018-03-27 20:32, Alejandro R. Mosteo wrote:

>>> I'm not in the industry, and I'd be surprised that unverified 
>>> software were allowed to run in civilian environments where failures 
>>> basically amount to a very dangerous situation.
>>
>> Why should it surprise you? How are you going to verify it? Black box 
>> test is impossible. White box test isn't either, assuming any NN 
>> involved. There is nothing to prove.
> 
> I can think of an spectrum of regulatory/practical positions between 
> 'nothing can be done, so everyone brace' and 'this won't ever fail, 
> under every [un]conceivable situation'. It's the apparent nonchalance of 
> the general public that coexists with these testing cars, the 
> brashness/recklessness of those expecting to get rich with it and the 
> apparent willingness of politicians that I find fascinating (that's the 
> first ones that comes to mind).
> 
> I can understand the appeal for politicians to be the first city with a 
> working fleet (or whatever contributions they're getting to favor live 
> testing). As a technophile, I want autonomous cars to become reality, so 
> I can understand that too. As a researcher familiar with the algorithms 
> involved and with the kind of C/C++/Python heaps that implement them I 
> get chills about thinking that a car can be on the highway with a 
> semi-awake safety driver as the only fallback in a split second.

As much as I hate C and the ilk, the problem is much deeper, I'm afraid. 
Even if it were 100% SPARK Ada, a self teaching system [I don't consider 
here simple cases where one can prove convergence of the training method 
to a defined goal], is in the same relation as a program is to the CPU.

You can verify and certify the CPU as much as you wish. That would say 
nothing about the program running on it. The weights of a NN is a 
"program". The system core written in whatever language is a "CPU".

I have no slightest idea of an approach to define correctness of the 
trained weights, even less about proving it. It is a fundamental 
challenge we will have to deal with, if this kind of "emerging 
programming" to take hold.

A kind of biblical disaster when you, like God did, see in dismay what 
your creatures would do after you granted them "free will". Would you 
drown them all? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Killing software and certification

[Alejandro R. Mosteo]

On 28/03/18 16:23, Dmitry A. Kazakov wrote:
> On 28/03/2018 15:54, Alejandro R. Mosteo wrote:
>> On 27/03/18 21:25, Dmitry A. Kazakov wrote:
>>> On 2018-03-27 20:32, Alejandro R. Mosteo wrote:
> 
>>>> I'm not in the industry, and I'd be surprised that unverified 
>>>> software were allowed to run in civilian environments where failures 
>>>> basically amount to a very dangerous situation.
>>>
>>> Why should it surprise you? How are you going to verify it? Black box 
>>> test is impossible. White box test isn't either, assuming any NN 
>>> involved. There is nothing to prove.
>>
>> I can think of an spectrum of regulatory/practical positions between 
>> 'nothing can be done, so everyone brace' and 'this won't ever fail, 
>> under every [un]conceivable situation'. It's the apparent nonchalance 
>> of the general public that coexists with these testing cars, the 
>> brashness/recklessness of those expecting to get rich with it and the 
>> apparent willingness of politicians that I find fascinating (that's the 
>> first ones that comes to mind).
>>
>> I can understand the appeal for politicians to be the first city with a 
>> working fleet (or whatever contributions they're getting to favor live 
>> testing). As a technophile, I want autonomous cars to become reality, 
>> so I can understand that too. As a researcher familiar with the 
>> algorithms involved and with the kind of C/C++/Python heaps that 
>> implement them I get chills about thinking that a car can be on the 
>> highway with a semi-awake safety driver as the only fallback in a split 
>> second.
> 
> As much as I hate C and the ilk, the problem is much deeper, I'm afraid. 
> Even if it were 100% SPARK Ada, a self teaching system [I don't consider 
> here simple cases where one can prove convergence of the training method 
> to a defined goal], is in the same relation as a program is to the CPU.
> 
> You can verify and certify the CPU as much as you wish. That would say 
> nothing about the program running on it. The weights of a NN is a 
> "program". The system core written in whatever language is a "CPU".
> 
> I have no slightest idea of an approach to define correctness of the 
> trained weights, even less about proving it. It is a fundamental 
> challenge we will have to deal with, if this kind of "emerging 
> programming" to take hold.
> 
> A kind of biblical disaster when you, like God did, see in dismay what 
> your creatures would do after you granted them "free will". Would you 
> drown them all? (:-))

This line of thinking is often brought by a colleague working on 
"classical" solutions to problems that are nowadays trendy on deep 
learning circles. When feeling optimistic I see it as the complexity of 
the simplex method: linear on average but worst case exponential. I tend 
to think that the same you could have a watchdog for a stray simplex, you 
could have some fallback for a DNN behaving badly (if you can detect it 
in the first place :P).

In other words: if DNNs prove to be as useful as they promise, they'll 
find a way to statistically cover the desired percent of reliability. 
Maybe this is another field of research in the making. I'm also told that 
"we solve X with a DNN" is no longer acceptable in the main conferences, 
that you have to also provide some insight on the DNN workings. But this 
is hearsay that I pass along.

Re: Killing software and certification

[Dmitry A. Kazakov]

On 2018-03-28 19:06, Alejandro R. Mosteo wrote:

> This line of thinking is often brought by a colleague working on 
> "classical" solutions to problems that are nowadays trendy on deep 
> learning circles. When feeling optimistic I see it as the complexity of 
> the simplex method: linear on average but worst case exponential. I tend 
> to think that the same you could have a watchdog for a stray simplex, 
> you could have some fallback for a DNN behaving badly (if you can detect 
> it in the first place :P).

If you are sure that it converges to the "right" thing. Does it? How do 
you know when the "right thing" is not even defined?

> In other words: if DNNs prove to be as useful as they promise, they'll 
> find a way to statistically cover the desired percent of reliability. 
> Maybe this is another field of research in the making.

Huh, you cannot use mathematical statistics here. You don't know what 
are elementary events here. You cannot use models because any sample set 
will be too small for testing any hypothesis. That is for the case of 
using brute force. In other words, to make mathematical statistics work 
there must some solid set of known laws describing things, but there is 
none.

> I'm also told 
> that "we solve X with a DNN" is no longer acceptable in the main 
> conferences, that you have to also provide some insight on the DNN 
> workings. But this is hearsay that I pass along.

This is another can of worms: knowledge extraction. If you can extract 
knowledge from the trained system, then you can build another system 
based on that knowledge that would deploy a direct decision making 
method without any training. If you cannot, you still have no idea what 
the system does now and what it will do next time.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Killing software and certification

[Jeffrey R. Carter]

On 03/28/2018 03:54 PM, Alejandro R. Mosteo wrote:
> On 27/03/18 21:25, Dmitry A. Kazakov wrote:
>>
>> If any certification will ever be set up, it will be certification of the 
>> tools and developing processes/teams, not certification of the actual 
>> software. That is the usual backdoor to go around any questions about 
>> correctness.
> 
> I understand that now.

I've seen S/W developed by a company that was CMMI Level 5 certified. It might 
have some use as fertilizer. That's what you get when you certify processes.

-- 
Jeff Carter
"One day he told me he was a gynecologist. He
couldn't speak no foreign languages."
Take the Money and Run
147

Re: Killing software and certification

[Dennis Lee Bieber]

On Wed, 28 Mar 2018 17:47:34 +0200, "Jeffrey R. Carter"
<spam.jrcarter.not@spam.not.acm.org> declaimed the following:

>
>I've seen S/W developed by a company that was CMMI Level 5 certified. It might 
>have some use as fertilizer. That's what you get when you certify processes.

	That's about what I got out of the CMMI effort... A big (I hate to use
the redundancy here) process for defining processes for how to modify
(tailor) processes -- with nothing actually proving the software itself is
correct, only documentation that "we did what the process says to do".


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/ 

Re: Killing software and certification

[Dan'l Miller]

On Wednesday, March 28, 2018 at 10:47:36 AM UTC-5, Jeffrey R. Carter wrote:
> I've seen S/W developed by a company that was CMMI Level 5 certified. It might 
> have some use as fertilizer. That's what you get when you certify processes.

(sigh)  Not all certification programs are bona fide quality-management regimes.  And not all bona fide quality-management regimes are rigorous.  There exists a pecking order.  Don't go with certification programs from which all the other hens have picked the feathers off.  The following lengthy humorous example is likely to be certifiable as CMMI Level 5 without—not only ever mentioning such rigorous quality-management regimes as AS9000 in aerospace, DO-178B/C in realtime systems, or IATF 16949 in automotive—but also without even developing any executable software at all.  CMMI alone is worthless at assuring any definition of goodness of executable software ever gets designed, implemented, and released, as shown below.

You need to couple CMMI Level 4 or 5 with one of the industry-specific quality-management regimes that actually have required content with teeth pertaining to realtime software/hardware systems.  Even then, some degree of mind-games can be played with an AS9000 in aerospace or TL9000 in telecom or IATF 16949 in automotive.  If the process does not require, say, DO-178B/C or some other form of actual rigor, then that organization is trying to get by with their analogue of saying that rubbing their tummy and patting their head is the key to good quality.  The awesome part of AS9000, TL9000, and IATF 16949 is that each manufacturer & subcontractor is required to divulge (some of it publicly) data that reveal how serious they are taking it versus how much they are playing mind-games merely to look good (fraudulently?) with mere wallpapering the front-door vestibule with certification papers along with the obligatory wall of granted-patent wooden plaques.  The embarrassment resulting from someone who cares combing deeply through the publicly-disclosed quality-management data is usually enough of a whip to crack over an organization to put at least some major effort into scoring well against their peer-group of competitors in the publicly-reported data, so that they are not in last place or not in the bottom half when compared to their AS9000/TL9000/IATF16949 peers.  Personally, I am most intimately familiar with TL9000's rigor in this regard.

Maturity Level 1 - Unmanaged chaos

We record videos of us playing around. Er, only sometimes.  Other times we record over yesterday's video.

Maturity Level 2 - Managed

CM - Configuration Management

We store those videos here in an organized fashion in ascending chronological order per employee with backups so that no such video is ever lost or unplayable.

MA - Measurement and Analysis

We count how many times per minute each person in the video rubbed their tummy.  We measure the time duration from the completion of the prior video to the commencement of the subsequent video.  We measure how many likes these videos receive on social media.

PPQA - Process and Quality Assurance

We have a person who makes sure that we do what we say we do.

REQM - Requirements Management

Each person's playing around shall be rubbing their tummy and patting their head in the video.

SAM - Supplier Agreement Management

We require our suppliers to submit videos of them rubbing their tummy and patting their head according to this process.

SD - Service Delivery

We post these videos on YouTube for the public to have their LOLs.

WMC - Work Monitoring and Control

We train our managers to make sure that each employee is doing what we say herein.

WP - Work Planning

Each employee is required to estimate the production time of the videos described herein.

Maturity Level 3 - Defined

CAM - Capacity and Availability Management

We estimate how many such videos we can make per day and per year, given staffing levels.

DAR - Decision Analysis and Resolution

We put in place a committee to decide what defines actual tummy rubbing and head patting or lack thereof.

IRP - Incident Resolution and Prevention

We watch the videos to assure that tummy rubbing and head patting is occurring concurrently.  We retake videos where the person's tummy rubbing and head patting lacked concurrency.

IWM - Integrated Work Managements

Each person must record their video in their cubicle as a normal part of their daily work activity.

OPD - Organizational Process Definition

We wrote this here document that states everything that we promise that we do regarding these videos.

OPF - Organizational Process Focus...

Our organization is totally focused on making these videos as described herein according to the OPD's document.

OT - Organizational Training

We require each employee to be trained regarding how to operate the video-recording equipment.

RSKM - Risk Management

We monitor how full the recording medium is on the video-recording equipment.

Maturity Level 4 - Quantitatively Managed

OPP - Organizational Process Performance

We have a department that looks at spreadsheets that monitor the degree of compliance to OPD's document is occurring.

QWM - Quantitative Work Management

OPP's data is fed back to our managers to manage employees greater fidelity of compliance to OPD's document.

Maturity Level 5 - Optimizing

CAR - Causal Analysis and Resolution

We identify all the reason(s) for noncompliance with OPD's document.  We perform root-cause analysis thereon to identify top-priority issues to fix versus cascading ramifications.

OPM - Organizational Performance Management.

We adapt this process to attempt to preclude the reason(s) for noncompliance with OPD's document that OPM found.

Re: Killing software and certification (was: Ada-Oriented GUI)

[Dan'l Miller]

On Tuesday, March 27, 2018 at 1:32:32 PM UTC-5, Alejandro R. Mosteo wrote:
> On 23/03/18 10:05, Jeffrey R. Carter wrote:
> 
> > Autopilots have to be certified to DO178B/C. They'll continue to be 
> > written in Ada and not kill us.
> > 
> > Self-driving cars, though operating in a much more complex environment, 
> > don't seem to need any certification, and will probably kill us all.
> 
> I'd like to revisit this point in light of the recent Uber news, but 
> also let's not forget for example this one which is simpler than fully 
> autonomous cars:
> 
> https://en.wikipedia.org/wiki/2009–11_Toyota_vehicle_recalls
> 
> I'm not in the industry, and I'd be surprised that unverified software 
> were allowed to run in civilian environments where failures basically 
> amount to a very dangerous situation. True, a human driver is still 
> required to be ready, but let's not be disingenuous about how well that 
> can work for several hours of testing/driving.
> 
> After a bit of googling around I see that there are automotive standards 
> for certification (the one I see more often mentioned is ISO 26262). 
> About enforcement, I also read that regulation varies by US state. I 
> haven't found anything definite about Europe.

https://en.wikipedia.org/wiki/ISO/TS_16949

IATF 16949:2016 is the active quality-management regime for the automotive industry that replaces QS9000 (North-American-only analogue of the aerospace industry's AS9000 and the telecom industry's TL9000) and prior ISO 16949 editions.  Just as AS9000 and TL9000 and the predecessor QS9000, IATF 16949 is ISO9001 with some teeth (e.g., transparent publicly-visible anonymized degree-of-compliance-versus-competitors statistics; effectively the same recursive requirements on all subcontractors and suppliers as on the top-level automobile-assembly manufacturer).

That said, USA law is effectively an extrapolated variant of pre-1776 British common law (with the exceptions of Louisiana which is effectively extrapolated Napoleon-era French law at the time of the Louisiana Purchase and a few states that are derivatives of the then Spanish Empire).  What that means is that generally we have a collection of systems of law that demand that companies (and individuals) act responsibly a priori on their own volition to avoid being negligent and thus liable in civil lawsuits that a-posteriori-ly claw back money for the cascading ramifications of negligence.  In particular, most of the USA (neither at the state nor federal nor municipal levels) has nothing much that resembles socialist system of laws that criminalize noncompliance with (our voluntary-membership industry-/guild-internal) regulations.  Indeed, being a member of an inferior “guild” of unwise industry ‘best practices’ (e.g., joining a nonrigorous industry-standard organization) or lack thereof is generally not illegal, hence why Silicon Valley often declares that they follow different/looser regimes of industry best practices than joining the more rigorous modern equivalent of guilds.  (I use guild there to call to mind the state of British law's thinking in the centuries leading up to 1776.)  The primary laws in that criminalize bad-acts themselves (as opposed to mere civil-law clawback/fine penalties for perceived negligence) are in the financial/embezzlement domain, not the technical engineering domain (except in the domains regulated by licensed professional engineers providing services directly to the public).  Indeed, compliance as an industry/guild to best practices in the industry can be almost tantamount to a safe harbor from judgements in civil-law prosecution, especially when a jury is taught about the company's meticulous adherence to the regime of best practices.  Given the existence of that de facto safe harbor in lawsuits, it is unclear why Silicon Valley companies tend to abhor joining such quality-management organizations and abhor performing their work under a regime of rigor that would not only improve their quality but also insulate them to a degree from lawsuits.  [I am not a lawyer; do not rely on these statements in any legalistic way.]

In other words, in the USA, our laws are effectively historically libertarian, not socialist:  it is up to the consumer to read the label on a product to see whether the product has been designed and manufactured in accordance with various voluntary regimes of best-practices in industry-standards (i.e., the ones that that individual holds dear at a personal level as their own personal belief system), not on the manufacturer to be forced to join those organizations, not on the management within those companies to obey those industry standards or be prosecuted, not at a one-size-fits-all societal level.  If you as a consumer buy an inferior-designed product, then it sucks to be you for not engaging in caveat-emptor/buyer-beware, except to claw back wrongs after a mishap/wreck/death/maiming, and except certain categories of consumer goods for children that are more tightly regulated since children cannot speak for themselves due to being minors.

Re: Killing software and certification (was: Ada-Oriented GUI)

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:0e59a988-ed21-4e45-a2ed-7a51995dbe6c@googlegroups.com...
...
> ... it is up to the consumer to read the label on a product to see whether
> the product has been designed and manufactured in accordance with
> various voluntary regimes of best-practices in industry-standards.

That's surely helpful for the lady that was run over crossing the street.

Self-driving cars have safety requirements near those of avionics software. 
But the actual requirements on such software is far from the same. I'm 
afraid it will take a bunch of lawsuits to get the automakers in line, and 
quite possibly not even that. (I hear they actively want to avoid making 
software that actually is known to work.)

                        Randy.

Re: Killing software and certification (was: Ada-Oriented GUI)

[Dan'l Miller]

On Tuesday, March 27, 2018 at 7:04:46 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:0e59a988-ed21-4e45-a2ed-7a51995dbe6c@googlegroups.com...
> ...
> > ... it is up to the consumer to read the label on a product to see whether
> > the product has been designed and manufactured in accordance with
> > various voluntary regimes of best-practices in industry-standards.
> 
> That's surely helpful for the lady that was run over crossing the street.
> 
> Self-driving cars have safety requirements near those of avionics software. 
> But the actual requirements on such software is far from the same. I'm 
> afraid it will take a bunch of lawsuits to get the automakers in line, and 
> quite possibly not even that. (I hear they actively want to avoid making 
> software that actually is known to work.)
> 
>                         Randy.

My point is that self-driving-automobile companies that, say, adopt DO-178B/C level of rigor (and implement in Ada with proper RTOS) will have vastly more de facto safe harbor in a lawsuit from either that lady's estate, the attorney general, or the FTC/NTSB.  Conversely, companies that cannot demonstrate adherence to regimes of rigor (or demonstrate adherence to a relatively worthless regime of rigor) are wide open to lawsuits incoming from multiple trajectories, precisely aimed at their deep pockets.

Randy, if you want to achieve your goal of Ada2020 saving lives in self-driving vehicles, then you (personally and as all of ARG in the plural) need to hitch your Ada2020 wagon to IATF 16949 or other automotive quality-management best-practices to bring DO-178B/C or equivalent requirements to the automotive industry.  Ada2020 can have the most perfect solution to provably-correct tasking, but if its adoption is neither required nor strongly motivated by a quality-management regime, then no one will even know of your achievement.

There exists an expedient backdoor to forcibly ramming Ada and DO-178B/C-esque requirements on the self-driving automotive industry (and/or the larger drive-by-wire automotive industry, e.g., the Toyota debacle).  That backdoor is the automotive property-casualty insurance industry.  If no insurer will affordably insure self-driven automobiles that lack, say, DO-178B/C compliance (and better yet the promised Ada2020 provable-correctness in tasking), then Ada will win the safety-critical-vehicles war and many of the major battles in that war.  Trusting that Ada2020's forthcoming awesome goodness will magically appear in automobiles by passive osmosis would be a recipe for being a coulda-woulda-shoulda footnote in the history books.  Statutory laws tend to follow whatever the automotive property-casualty insurance industry's lobbyists demand in Washington DC and in state legislatures.

(Here I am assuming that your Ada2020 goals come to fruition practically.  I hope that they do, even though I am skeptical.)

Re: Killing software and certification

[Alejandro R. Mosteo]

On 28/03/18 02:04, Randy Brukardt wrote:
> "Dan'l Miller" <optikos@verizon.net> wrote in message
> news:0e59a988-ed21-4e45-a2ed-7a51995dbe6c@googlegroups.com...
> ...
>> ... it is up to the consumer to read the label on a product to see whether
>> the product has been designed and manufactured in accordance with
>> various voluntary regimes of best-practices in industry-standards.
> 
> That's surely helpful for the lady that was run over crossing the street.

Yes, that's where the informed consumer idea falls somewhat apart.

> Self-driving cars have safety requirements near those of avionics software.
> But the actual requirements on such software is far from the same. I'm
> afraid it will take a bunch of lawsuits to get the automakers in line, and
> quite possibly not even that. (I hear they actively want to avoid making
> software that actually is known to work.)

That would be to be able to ignore that it deviates from expected 
performance?

Álex.

> 
>                          Randy.
> 
> 
> 
> 

Re: Killing software and certification (was: Ada-Oriented GUI)

[Jere]

On Tuesday, March 27, 2018 at 2:32:32 PM UTC-4, Alejandro R. Mosteo wrote:
> 
> In the end I'm not sure where I want to go with this post. It's simply 
> that I find the topic very interesting. If anyone with actual knowledge 
> on the status of automotive software certification (or any informed 
> ideas) would share some thoughts I'll be eager to read.
> 
> Álex.

This is quite a bit tangential, but here is a blog post from an expert
who viewed Toyota's code for one of the unintended acceleration cases.
He was called as an expert witness and had some pretty interesting experience
with it.

most recent blog post:
https://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/

older blog posts on the topic:
https://embeddedgurus.com/barr-code/2011/03/unintended-acceleration-and-other-embedded-software-bugs/
https://embeddedgurus.com/barr-code/2011/03/what-nhtsanasa-didnt-consider-re-toyotas-firmware/

redacted jury slides:
http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf

testimony transcript:
http://www.safetyresearch.net/Library/Bookout_v_Toyota_Barr_REDACTED.pdf

I thought you might be interested.  It isn't about autonomous vehicles, but
it gives a minimum baseline possibly.

Re: Killing software and certification

[Alejandro R. Mosteo]

On 28/03/18 02:21, Jere wrote:
> On Tuesday, March 27, 2018 at 2:32:32 PM UTC-4, Alejandro R. Mosteo wrote:
>>
>> In the end I'm not sure where I want to go with this post. It's simply
>> that I find the topic very interesting. If anyone with actual knowledge
>> on the status of automotive software certification (or any informed
>> ideas) would share some thoughts I'll be eager to read.
>>
>> Álex.
> 
> This is quite a bit tangential, but here is a blog post from an expert
> who viewed Toyota's code for one of the unintended acceleration cases.
> He was called as an expert witness and had some pretty interesting experience
> with it.

In fact I had read some of these, but not all of them, thanks!

Incidentally, thanks everybody for chiming in. I have now a clearer idea 
of the situation. I guess that it's going to be a long road to autonomous 
cars, paved with lucrative lawsuits.

Álex.

> 
> most recent blog post:
> https://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/
> 
> older blog posts on the topic:
> https://embeddedgurus.com/barr-code/2011/03/unintended-acceleration-and-other-embedded-software-bugs/
> https://embeddedgurus.com/barr-code/2011/03/what-nhtsanasa-didnt-consider-re-toyotas-firmware/
> 
> redacted jury slides:
> http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf
> 
> testimony transcript:
> http://www.safetyresearch.net/Library/Bookout_v_Toyota_Barr_REDACTED.pdf
> 
> I thought you might be interested.  It isn't about autonomous vehicles, but
> it gives a minimum baseline possibly.
> 

Re: Ada-Oriented GUI

[Alejandro R. Mosteo]

On 23/03/18 00:47, Randy Brukardt wrote:
> (...)
> 
> No, a correct program is one that can be reasoned about. And one cannot
> reason about programs that contain race conditions ("unavoidable" or not).
> One has to impose some sort of structure to avoid race conditions/dead
> locks/live locks, lest the program be unanalyzable. And to have any chance
> of believing a program is correct requires analysis.
 >
> (...) 
 >
> One has to architect the application so
> that there is very limited interaction between tasks, and that interaction
> has to be carefully controlled (usually via rendezvous or protected
> objects). 

That's one strong point of Rx precisely.

> This has nothing to do with the UI or IO or any other "events".
> It's probably easiest for most to just manage the UI in the single task,
> because that gets the mess of "events" away from the bulk of the processing.
> (Ada is wildly inappropriate for applications that are mostly GUI - use some
> web-based langauge for that and use Ada for the heavy-duty processing.)
 >
> (...)
> 
> For sequential programs, Ada is pretty much there. I've been working on
> Janus/Ada infrastructure improvements without even trying to find the code
> that needs to be modified -- the compiler/run-time tells me where changes
> are needed far quicker than trying to look for them by hand. (One has to
> design their code to enable this sort of thing in the first place, but that
> pays off many times if the program has any sort of lifetime.)
> 
> One of the goals of Ada 2020 is to bring that level of reliability to
> parallel programming. That means the compiler has to (conservatively)
> diagnose and reject data races between separately executed code.

Matlab has some of what is planned and I'm counting the time until Ada 
will too. It's fantastic.

> A system that decides to just ignore race conditions as "unavoidable" is
> going in the wrong direction. Most likely, it will kill us all when it's
> running self-driving cars and autopilots.

I think the argument about race conditions has derailed. Rx does not 
embrace the idea that race conditions (in the sense of real bugs) are 
unavoidable. If correct execution is guaranteed independently of the 
particular interleaving of events I'd say that's not a real race 
condition, and that's what Rx abstracts away (or helps you to, safely).

I (humbly) think that people not knowing Rx but arguing against it are 
barking at the wrong tree. It's not something that can do everything 
better. It's just a tool (paradigm if you wish) that precisely 
simplifies handling a certain kind of systems that with traditional 
techniques are prone to difficult to diagnose bugs and uncomfortable 
code (as the discussion on GUI libraries show). It goes in the direction 
of "this can't cause a race condition", not the contrary.

To me, Rx vs imperative [for suitable problems] it's like tasking in Ada 
vs other languages. Ada is in entirely another league wrt simplicity and 
safety. Still, you can misdesign spaguetti code that deadlocks, 
livelocks, that calls blocking operations from blocking operations, 
raises Tasking_Error... but Ada makes things easy if you know the Ada 
way, and enables some kinds of analysis, sure, if you adhere to some 
practices.

I'm really not an Rx expert, so I'm not sure what kind of research is 
being done on it that could be relevant for safety-minded people. What I 
know is that the principles are simple and elegant, and my instinct says 
that it would interact very well with Ada protected objects, so I would 
be surprised if nothing good could be deducted starting from there.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 23/03/2018 13:31, Alejandro R. Mosteo wrote:

> I (humbly) think that people not knowing Rx but arguing against it are 
> barking at the wrong tree.

Yes, but this is a natural defense reflex against snake oil sellers.

> To me, Rx vs imperative [for suitable problems] it's like tasking in Ada 
> vs other languages. Ada is in entirely another league wrt simplicity and 
> safety.

If you mean comparing languages with no tasking support to Ada, that is 
not like imperative vs. declarative. [Event-controlled is not really 
declarative]

> I'm really not an Rx expert, so I'm not sure what kind of research is 
> being done on it that could be relevant for safety-minded people. What I 
> know is that the principles are simple and elegant, and my instinct says 
> that it would interact very well with Ada protected objects, so I would 
> be surprised if nothing good could be deducted starting from there.

If principles are simply and elegant they certainly could be explained 
in a few words understandable for residents of comp.lang.ada.

[There is nothing simple or elegant in event-controlled architectures. 
Doing this for 20+ years (this is state of the art in automation 
systems), I am pretty sure of.]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Dan'l Miller]

On Friday, March 23, 2018 at 7:59:38 AM UTC-5, Dmitry A. Kazakov wrote:
> On 23/03/2018 13:31, Alejandro R. Mosteo wrote:
> 
> > I (humbly) think that people not knowing Rx but arguing against it are 
> > barking at the wrong tree.
> 
> Yes, but this is a natural defense reflex against snake oil sellers.

But, Dmitry, you cocoon yourself in a layer of ignorance-is-BLISS (substituting several topics for that old DEC language) or perhaps even more than one layer.  To actually know that Rx and Ix are snake oil, you must first directly examine the actual product for sale, perhaps scientifically by deep empirical examination fitting of a biological dissection or plotting of Copernican planetary motion during The Enlightenment.  You've done nothing of the sort.  Your condemnations would be much more meaningful if you came back after 30 or 365 days to report that based on your in-depth analysis of actually extant source code and empirical executions thereof, the entire reactive-systems ideology is flawed at this & that points of departure at the git-go on which an entire house of cards is built.  But you've done nothing of the sort.

Just as in so many pseudo-science topics in the media today, science isn't some expert opining vociferously about topics based on hearsay or propaganda.  Science is not about pontificating a clung-to belief system; there exists a pontiff already for that.  Science is not about 97% of the mob-justice saying such-&-such.  Science is deliberate reproducible empirical examination (preferably via the Scientific Method with a control group and varying only a single variable) of extant reality.  Multiple people over a span of a decade are showing that by comparing the same app design before and after introduction of Rx in Swift and in Java and in C# eliminates defects by Rx's easing the visualization of how to properly handle multiple disparate eventflow arrival orderings in a very structured and disciplined way of focusing on river(s) of nouns rather than structured-programming-esque imperative verb-first mentality.  And that is today's bleeding-edge prototypical kludgy Rx at run-time, just to help out the human designer's mental clarity.  Imagine what Rx at compile-time with did-you-cover-all-the-cases checks could do.  Imagine compile-time checks on over or under conflation/folding/mapping of categories of event arrivals.  That doesn't sound like snake oil at all.  That sounds precisely like something an Ada-esque language would meticulously verify at compile-time.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 2018-03-23 17:16, Dan'l Miller wrote:
> On Friday, March 23, 2018 at 7:59:38 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 23/03/2018 13:31, Alejandro R. Mosteo wrote:
>>
>>> I (humbly) think that people not knowing Rx but arguing against it are
>>> barking at the wrong tree.
>>
>> Yes, but this is a natural defense reflex against snake oil sellers.
> 
> But, Dmitry, you cocoon yourself in a layer of ignorance-is-BLISS (substituting several topics for that old DEC language) or perhaps even more than one layer.

Sure.

> To actually know that Rx and Ix are snake oil, you must first directly examine the actual product for sale,

Impossible, there are too many sellers of that oil. Therefore the 
reaction goes towards the art of the presentation. When something is 
advertised as a new paradigm, groundbreaking, "how I lose my weight in 
just 1 week" etc, alarm bells start to ring.

> perhaps scientifically by deep empirical examination fitting of a biological dissection or plotting of Copernican planetary motion during The Enlightenment.  You've done nothing of the sort.

Yes, see above. Skepticism is a pillar of scientific method. BTW, 
Copernicus was wrong and that was an empiric fact already in his time.

I merely expected a rational explanation how Rx or whatever would solve 
real problems of GUI design.

Continuing your example, Copernican model did not solve anything. It 
took Kepler and Newton who actually did.

> Your condemnations would be much more meaningful if you came back after 30 or 365 days to report that based on your in-depth analysis of actually extant source code and empirical executions thereof, the entire reactive-systems ideology is flawed at this & that points of departure at the git-go on which an entire house of cards is built.  But you've done nothing of the sort.

In some peer-reviewed journal maybe, but in a news conference?

> Just as in so many pseudo-science topics in the media today, science isn't some expert opining vociferously about topics based on hearsay or propaganda.  Science is not about pontificating a clung-to belief system; there exists a pontiff already for that.  Science is not about 97% of the mob-justice saying such-&-such.  Science is deliberate reproducible empirical examination (preferably via the Scientific Method with a control group and varying only a single variable) of extant reality.

True, but S/W is not science, not even engineering. It is a craft.

> Multiple people over a span of a decade are showing that by comparing the same app design before and after introduction of Rx in Swift and in Java and in C# eliminates defects by Rx's easing the visualization of how to properly handle multiple disparate eventflow arrival orderings in a very structured and disciplined way of focusing on river(s) of nouns rather than structured-programming-esque imperative verb-first mentality.

Sorry, but that reads like an advertising prospect again.

> And that is today's bleeding-edge prototypical kludgy Rx at run-time, just to help out the human designer's mental clarity.  Imagine what Rx at compile-time with did-you-cover-all-the-cases checks could do.  Imagine compile-time checks on over or under conflation/folding/mapping of categories of event arrivals.  That doesn't sound like snake oil at all.  That sounds precisely like something an Ada-esque language would meticulously verify at compile-time.

No, that sounds like a NP problem, if decidable, of the later I am not 
sure too. But a demonstration or explanation using a typical GUI beyond 
buttons, e.g. a tree view, could help.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Dan'l Miller]

On Friday, March 23, 2018 at 12:18:52 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-03-23 17:16, Dan'l Miller wrote:
> > On Friday, March 23, 2018 at 7:59:38 AM UTC-5, Dmitry A. Kazakov wrote:
> >> On 23/03/2018 13:31, Alejandro R. Mosteo wrote:
> >>
> >>> I (humbly) think that people not knowing Rx but arguing against it are
> >>> barking at the wrong tree.
> >>
> >> Yes, but this is a natural defense reflex against snake oil sellers.
> > 
> > But, Dmitry, you cocoon yourself in a layer of ignorance-is-BLISS (substituting several topics for that old DEC language) or perhaps even more than one layer.
> 
> Sure.
> 
> > To actually know that Rx and Ix are snake oil, you must first directly examine the actual product for sale,
> 
> Impossible, there are too many sellers of that oil. Therefore the 
> reaction goes towards the art of the presentation. When something is 
> advertised as a new paradigm, groundbreaking, "how I lose my weight in 
> just 1 week" etc, alarm bells start to ring.

You sound like an anti-vaccination or anti-GMO person, who cannot even annunciate a path of inquiry that you yourself could travel to even consider the safety or lack thereof of vaccines or GMOs.  For those people, vaccines and GMOs are verboten as pure (irrational?) belief system and no amount of rational thought or scientific-experiment evidence would convince them (to even open their mind to to the mere potential of being convinced), because rational thought and scientific-experiment evidence would threaten their sacred golden-calf that they worship.  They spent so much time & effort smelting the gold to cast their golden-calf statue that they cannot give up on worshipping the golden calf now.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 2018-03-23 19:31, Dan'l Miller wrote:
> On Friday, March 23, 2018 at 12:18:52 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-03-23 17:16, Dan'l Miller wrote:
>>> On Friday, March 23, 2018 at 7:59:38 AM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 23/03/2018 13:31, Alejandro R. Mosteo wrote:
>>>>
>>>>> I (humbly) think that people not knowing Rx but arguing against it are
>>>>> barking at the wrong tree.
>>>>
>>>> Yes, but this is a natural defense reflex against snake oil sellers.
>>>
>>> But, Dmitry, you cocoon yourself in a layer of ignorance-is-BLISS (substituting several topics for that old DEC language) or perhaps even more than one layer.
>>
>> Sure.
>>
>>> To actually know that Rx and Ix are snake oil, you must first directly examine the actual product for sale,
>>
>> Impossible, there are too many sellers of that oil. Therefore the
>> reaction goes towards the art of the presentation. When something is
>> advertised as a new paradigm, groundbreaking, "how I lose my weight in
>> just 1 week" etc, alarm bells start to ring.
> 
> You sound like an anti-vaccination or anti-GMO person, who cannot even annunciate a path of inquiry that you yourself could travel to even consider the safety or lack thereof of vaccines or GMOs.

Neither vaccination nor gene engineering is advertised as new paradigm. 
Anybody with a primary school education can reason about usefulness of 
these. But yes, if you are going to tell me about a new vaccine against 
cancer, influenza, short-sightedness and feet smell, the bells will 
start ringing.

> For those people, vaccines and GMOs are verboten as pure (irrational?) belief system and no amount of rational thought or scientific-experiment evidence would convince them (to even open their mind to to the mere potential of being convinced), because rational thought and scientific-experiment evidence would threaten their sacred golden-calf that they worship.  They spent so much time & effort smelting the gold to cast their golden-calf statue that they cannot give up on worshipping the golden calf now.

You seem never heard anti-GMO people. Continental Europe is full of 
them. They don't understand rational arguments, in particular weighting 
risks against advantages. This has nothing to do with golden-calves. It 
is a "WHAT-IF" argumentation method. What if all water molecules in a 
boiling kettle will start to move in the same direction burning you to 
death? The probability is not zero, let's outlaw kettles.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Mehdi Saada]

And you BOTH seem awfully prejudiced against continentals !
I am a continental European, anti-GMO and anti-vaccine, so I feel quite irritated by this smug self-righteous tone. You might as well be the one not being able to weight risks and advantages, blinded by your progressive ideology. Don't forget Ada was designed by a FRENCH, not by some light-headed *colonials* :-P

... I know I ask to stop, yet added fuel to the fire.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 2018-03-23 21:48, Mehdi Saada wrote:
> And you BOTH seem awfully prejudiced against continentals !

Hi from Germany, BTW. (:-))

> I am a continental European, anti-GMO and anti-vaccine, so I feel quite irritated by this smug self-righteous tone. You might as well be the one not being able to weight risks and advantages, blinded by your progressive ideology.

"Progressive" like leftist post-Marxism (AKA social "progress"), or like 
being for scientific progress? These weren't equal since the second half 
of XIX century...

Anti-GMO and anti-vaccination are utterly anti-scientific.

> Don't forget Ada was designed by a FRENCH, not by some light-headed *colonials* :-P

or Canut revolts in Lyon... (:-))

> ... I know I ask to stop, yet added fuel to the fire.

Yes, let's keep this outside comp.lang.ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Alejandro R. Mosteo]

On 23/03/18 13:59, Dmitry A. Kazakov wrote:
> On 23/03/2018 13:31, Alejandro R. Mosteo wrote:
> 
>> I (humbly) think that people not knowing Rx but arguing against it are 
>> barking at the wrong tree.
> 
> Yes, but this is a natural defense reflex against snake oil sellers.

Just like Ada enthusiasts pestering C/C++/Rust/... people are seen? ;-)

>> To me, Rx vs imperative [for suitable problems] it's like tasking in 
>> Ada vs other languages. Ada is in entirely another league wrt 
>> simplicity and safety.
> 
> If you mean comparing languages with no tasking support to Ada, that is 
> not like imperative vs. declarative. [Event-controlled is not really 
> declarative]

I mean, e.g., Ada vs Java Thread/Runnable; it was not a technical 
analogy anyway. Just a gut-feeling one.

The primitive tasking facilities of most popular languages, 20+ years 
after Ada, is one of the things that most amazes me (in a bad way).

>> I'm really not an Rx expert, so I'm not sure what kind of research is 
>> being done on it that could be relevant for safety-minded people. What 
>> I know is that the principles are simple and elegant, and my instinct 
>> says that it would interact very well with Ada protected objects, so I 
>> would be surprised if nothing good could be deducted starting from there.
> 
> If principles are simply and elegant they certainly could be explained 
> in a few words understandable for residents of comp.lang.ada.

Hehe. I'd say: it's simple enough, and there's so much information 
available, that anyone with genuine interest can get its bearings in the 
time spent arguing here, and with better explanations than mine using 
mere ASCII. But since you ask (or not) I will give the bare minimum and 
then some quickly triaged links:

----8<----

Rx Observer contract:

OnNext* (OnCompleted | OnError)?

Events arrive once, thread-safely (OnNext call). End of sequences is 
notified once with success or failure, so cleanup is trivial.

The emitter of events is an Observable. The consumer is an Observer. 
Combinations of both are Operators. There are many predefined Operators 
to make life easy, addressing most needs that would be otherwise complex 
(e.g. tasking ones).

For my own specification package: https://goo.gl/WQfpeV

----END----

Links (in somewhat loose reading order):

1) Original reference: https://go.microsoft.com/fwlink/?LinkID=205219
Sections 4.1 - 4.3 focus on the essentials. They're very short. The rest 
is only useful when you already know the basics and jargon.

2) 2-minute intro to Rx:
https://medium.com/@andrestaltz/2-minute-introduction-to-rx-24c8ca793877

2.5/3.5, can't decide) Marble diagrams:
https://medium.com/@jshvarts/read-marble-diagrams-like-a-pro-3d72934d3ef5

3) The whole http://reactivex.io site. I'd start by:
http://reactivex.io/intro.html
http://reactivex.io/documentation/contract.html
http://reactivex.io/documentation/operators.html

Never) I have a paper on my RxAda implementation. Section 2 attempts to 
be an introduction to Adaists not knowing Rx:
Paper: 
https://www.researchgate.net/publication/318135797_RxAda_An_Ada_implementation_of_the_ReactiveX_API
Slides: 
https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/RxAdaSlidesShort.pdf

...

Since you asked about TreeViews elsewhere, I see they somehow do it (but 
don't ask me how. It's probably ugly JS):
https://react.rocks/tag/TreeView

> [There is nothing simple or elegant in event-controlled architectures. 
> Doing this for 20+ years (this is state of the art in automation 
> systems), I am pretty sure of.]

The most elegant designs can turn ugly once things get real, that's for 
sure...

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 2018-03-24 12:36, Alejandro R. Mosteo wrote:

> Rx Observer contract:
> 
> OnNext* (OnCompleted | OnError)?
> 
> Events arrive once, thread-safely (OnNext call). End of sequences is 
> notified once with success or failure, so cleanup is trivial.

Well, how is that triviality any new or groundbreaking? The interfaces I 
have in Simple Components for communication protocols are just like this.

> The emitter of events is an Observable. The consumer is an Observer. 
> Combinations of both are Operators. There are many predefined Operators 
> to make life easy, addressing most needs that would be otherwise complex 
> (e.g. tasking ones).

Since I am using this model too, this is by no means any better than 
other methods. In fact it is far worse! The reason why I am using it is 
because there is no other way dealing with asynchronous I/O under the 
constraint of limited number of tasks. The implementations of all 
protocols in Simple Components are asynchronous.

Now, programming this is like scratching your left ear with the right 
hand. I keep on asking for co-routines in Ada to break out of this lousy 
awful mess. To rein assorted mess of events/callbacks into a sequence 
imperative calls to be a able to program it as if it were an 
uninterrupted thread of control maintaining its state, just like if the 
I/O were synchronous.

> For my own specification package: https://goo.gl/WQfpeV

Good work, BTW.

[...]

> Since you asked about TreeViews elsewhere, I see they somehow do it (but 
> don't ask me how. It's probably ugly JS):
> https://react.rocks/tag/TreeView

Too simple to judge. Usually problems start with columns, rendering 
nodes differently depending on conditions, evaluation of the three 
dimensions etc.

>> [There is nothing simple or elegant in event-controlled architectures. 
>> Doing this for 20+ years (this is state of the art in automation 
>> systems), I am pretty sure of.]
> 
> The most elegant designs can turn ugly once things get real, that's for 
> sure...

No. This is another set properties: scalability, composability.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Alejandro R. Mosteo]

On 24/03/18 14:12, Dmitry A. Kazakov wrote:
> On 2018-03-24 12:36, Alejandro R. Mosteo wrote:
> 
>> Rx Observer contract:
>>
>> OnNext* (OnCompleted | OnError)?
>>
>> Events arrive once, thread-safely (OnNext call). End of sequences is 
>> notified once with success or failure, so cleanup is trivial.
> 
> Well, how is that triviality any new or groundbreaking? The interfaces I 
> have in Simple Components for communication protocols are just like this.

I'd say, more than groundbreaking, is a neat tool that fulfills a need 
and that has reached critical mass, so that you can find lots of 
resources and practitioners.

>> The emitter of events is an Observable. The consumer is an Observer. 
>> Combinations of both are Operators. There are many predefined Operators 
>> to make life easy, addressing most needs that would be otherwise 
>> complex (e.g. tasking ones).
> 
> Since I am using this model too, this is by no means any better than 
> other methods. In fact it is far worse! The reason why I am using it is 
> because there is no other way dealing with asynchronous I/O under the 
> constraint of limited number of tasks. The implementations of all 
> protocols in Simple Components are asynchronous.

I'll take a look.

> Now, programming this is like scratching your left ear with the right 
> hand. I keep on asking for co-routines in Ada to break out of this lousy 
> awful mess. To rein assorted mess of events/callbacks into a sequence 
> imperative calls to be a able to program it as if it were an 
> uninterrupted thread of control maintaining its state, just like if the 
> I/O were synchronous.

I've never used coroutines. Since this kind of "imperative-like" 
sequences is what Rx provides, I understand that coroutines will allow 
the same without staying in the declarative realm?

There are AIs for generators in Ada, maybe these will be among the chosen 
ones?

>> For my own specification package: https://goo.gl/WQfpeV
> 
> Good work, BTW.

Thanks!

Álex.

> 
> [...]
> 
>> Since you asked about TreeViews elsewhere, I see they somehow do it 
>> (but don't ask me how. It's probably ugly JS):
>> https://react.rocks/tag/TreeView
> 
> Too simple to judge. Usually problems start with columns, rendering nodes 
> differently depending on conditions, evaluation of the three dimensions etc.
> 
>>> [There is nothing simple or elegant in event-controlled architectures. 
>>> Doing this for 20+ years (this is state of the art in automation 
>>> systems), I am pretty sure of.]
>>
>> The most elegant designs can turn ugly once things get real, that's for 
>> sure...
> 
> No. This is another set properties: scalability, composability.
> 

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 28/03/2018 16:09, Alejandro R. Mosteo wrote:
> On 24/03/18 14:12, Dmitry A. Kazakov wrote:

>> Now, programming this is like scratching your left ear with the right 
>> hand. I keep on asking for co-routines in Ada to break out of this 
>> lousy awful mess. To rein assorted mess of events/callbacks into a 
>> sequence imperative calls to be a able to program it as if it were an 
>> uninterrupted thread of control maintaining its state, just like if 
>> the I/O were synchronous.
> 
> I've never used coroutines. Since this kind of "imperative-like" 
> sequences is what Rx provides, I understand that coroutines will allow 
> the same without staying in the declarative realm?

I think so. Let you have Start_Write call and Write_Complete callback. 
The idea is to be able to write code in a "blocking" manner like:

    declare
       State : ...; -- Data local to the co-routine
    begin
       Start_Write (...);
       Wait_For_Complete (...); -- Give up the thread of control until
       ...                      -- Write_Complete
       Start_Write (...);
       ...

My understanding is that the "functional" style with closures is an 
alternative to this which calls Start_Write and then queues a closure to 
be called on Write_Complete. The closure will carry State with it and 
perform chained actions.

Needless to say that I don't find closures any appealing.

> There are AIs for generators in Ada, maybe these will be among the 
> chosen ones?

AFAIK, this is not what is required in order to support the above. A 
co-routine needs a local stack not bound to any task and a method to 
convert blocking calls into "save state, give up, wait for a 
callback/event".

P.S. Maybe all this would become irrelevant for processors with 
thousands of cores. Then we would be able to run anything in a blocking 
manner without context switching penalty. I think that memory bottleneck 
would likely kill such architectures, but who knows...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Alejandro R. Mosteo]

On 28/03/18 17:02, Dmitry A. Kazakov wrote:
> On 28/03/2018 16:09, Alejandro R. Mosteo wrote:
>> On 24/03/18 14:12, Dmitry A. Kazakov wrote:
> 
>>> Now, programming this is like scratching your left ear with the right 
>>> hand. I keep on asking for co-routines in Ada to break out of this 
>>> lousy awful mess. To rein assorted mess of events/callbacks into a 
>>> sequence imperative calls to be a able to program it as if it were an 
>>> uninterrupted thread of control maintaining its state, just like if 
>>> the I/O were synchronous.
>>
>> I've never used coroutines. Since this kind of "imperative-like" 
>> sequences is what Rx provides, I understand that coroutines will allow 
>> the same without staying in the declarative realm?
> 
> I think so. Let you have Start_Write call and Write_Complete callback. 
> The idea is to be able to write code in a "blocking" manner like:
> 
>     declare
>        State : ...; -- Data local to the co-routine
>     begin
>        Start_Write (...);
>        Wait_For_Complete (...); -- Give up the thread of control until
>        ...                      -- Write_Complete
>        Start_Write (...);
>        ...
> 
> My understanding is that the "functional" style with closures is an 
> alternative to this which calls Start_Write and then queues a closure to 
> be called on Write_Complete. The closure will carry State with it and 
> perform chained actions.

I think your understanding is right. Talking Rx, the data being processed 
should ideally be the state. Actions need not be technically closures, 
since they receive and return the data to pass along (I might be 
imprecise here about closures; this is a problem of having studied CS in 
another [human] language).

You can have actual closures too, and lambdas in recent Java. In my Ada 
implementation subprograms cannot be closures since they have to be at 
library level (I guess those and instantiations can be considered 
closures on the library level, I fear I'm mixing theoretical and 
implementation concepts here. I'm referring as a closure to a subprogram 
that accesses the enclosing subprogram scope.)

A similar example in RxAda would be:

procedure Write (Item : in Item_Type) is ...
    -- Take as much time as needed to write the Item
end Write;

declare
    S : Subscription :=
      Generator_Of_Items &      -- May generate them at any pace
      --  Pre-write actions would go here
      On_Next (Write'Access) &  -- Write as they come
      --  Post-write-actions would come here
      Subscribe;
begin
    null; -- Nothing to do here
end;

Or you can:

declare
    S : Subscription :=
      Generator_Of_Items &         -- May generate them at any pace
      Subscribe_On (Background) &  -- Ensures Generator goes to BG
      Map (Process'Access) &       -- Preprocess/transform items
      Observe_On (Writer_Pool) &   -- Use a pool of dedicated tasks
      On_Next (Write'Access) &     -- Writes one item
      Subscribe;
begin
    null; -- Proceed with other things
end;

> Needless to say that I don't find closures any appealing.

I seem to remember your objections from other threads, but I don't 
remember why exactly (I found them very cumbersome for the standard 
containers before the latest syntax sugar).

>> There are AIs for generators in Ada, maybe these will be among the 
>> chosen ones?
> 
> AFAIK, this is not what is required in order to support the above. A 
> co-routine needs a local stack not bound to any task and a method to 
> convert blocking calls into "save state, give up, wait for a 
> callback/event".
> 
> P.S. Maybe all this would become irrelevant for processors with thousands 
> of cores. Then we would be able to run anything in a blocking manner 
> without context switching penalty. I think that memory bottleneck would 
> likely kill such architectures, but who knows...

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 2018-03-28 20:07, Alejandro R. Mosteo wrote:
> On 28/03/18 17:02, Dmitry A. Kazakov wrote:
>> On 28/03/2018 16:09, Alejandro R. Mosteo wrote:
>>> On 24/03/18 14:12, Dmitry A. Kazakov wrote:
>>
>>>> Now, programming this is like scratching your left ear with the 
>>>> right hand. I keep on asking for co-routines in Ada to break out of 
>>>> this lousy awful mess. To rein assorted mess of events/callbacks 
>>>> into a sequence imperative calls to be a able to program it as if it 
>>>> were an uninterrupted thread of control maintaining its state, just 
>>>> like if the I/O were synchronous.
>>>
>>> I've never used coroutines. Since this kind of "imperative-like" 
>>> sequences is what Rx provides, I understand that coroutines will 
>>> allow the same without staying in the declarative realm?
>>
>> I think so. Let you have Start_Write call and Write_Complete callback. 
>> The idea is to be able to write code in a "blocking" manner like:
>>
>>     declare
>>        State : ...; -- Data local to the co-routine
>>     begin
>>        Start_Write (...);
>>        Wait_For_Complete (...); -- Give up the thread of control until
>>        ...                      -- Write_Complete
>>        Start_Write (...);
>>        ...
>>
>> My understanding is that the "functional" style with closures is an 
>> alternative to this which calls Start_Write and then queues a closure 
>> to be called on Write_Complete. The closure will carry State with it 
>> and perform chained actions.
> 
> I think your understanding is right. Talking Rx, the data being 
> processed should ideally be the state. Actions need not be technically 
> closures, since they receive and return the data to pass along (I might 
> be imprecise here about closures; this is a problem of having studied CS 
> in another [human] language).

If this is only data, then it is just standard OO approach:

    type IO_Request is abstract ...
    procedure Complete_Write (Request : in out IO_Request) is abstract;

    procedure Start_Write
              (  File : in out File_Type;
                 Request : in out IO_Request'Class
              );

You derive from IO_Request, override Complete_Write, queue it using 
Start_Write.

The problem is that the program logic is split between bodies, which 
makes this method so uncomfortable.

> You can have actual closures too, and lambdas in recent Java. In my Ada 
> implementation subprograms cannot be closures since they have to be at 
> library level (I guess those and instantiations can be considered 
> closures on the library level, I fear I'm mixing theoretical and 
> implementation concepts here. I'm referring as a closure to a subprogram 
> that accesses the enclosing subprogram scope.)

Yes, this is what I meant.

> A similar example in RxAda would be:
> 
> procedure Write (Item : in Item_Type) is ...
>     -- Take as much time as needed to write the Item
> end Write;
> 
> declare
>     S : Subscription :=
>       Generator_Of_Items &      -- May generate them at any pace
>       --  Pre-write actions would go here
>       On_Next (Write'Access) &  -- Write as they come
>       --  Post-write-actions would come here
>       Subscribe;
> begin
>     null; -- Nothing to do here
> end;
> 
> Or you can:
> 
> declare
>     S : Subscription :=
>       Generator_Of_Items &         -- May generate them at any pace
>       Subscribe_On (Background) &  -- Ensures Generator goes to BG
>       Map (Process'Access) &       -- Preprocess/transform items
>       Observe_On (Writer_Pool) &   -- Use a pool of dedicated tasks
>       On_Next (Write'Access) &     -- Writes one item
>       Subscribe;
> begin
>     null; -- Proceed with other things
> end;

Replacing ";" with "&"? (:-)) The real horrors start with conditional 
choices, loops, passing results from earlier steps down the chain, 
handling exceptions, honoring time constraints etc, everything we can 
keep simple and elegant in the "blocking" approach.

>> Needless to say that I don't find closures any appealing.
> 
> I seem to remember your objections from other threads, but I don't 
> remember why exactly (I found them very cumbersome for the standard 
> containers before the latest syntax sugar).

It not much the closures, but the programming style which forces program 
logic inversion. The things of primary reader's interest happen in 
bodies you pass as parameters or as primitive operations of parameters 
(in OO case). This is just a bad model. In that aspect it is no 
different from traditional callbacks.

OO decomposition wraps these callbacks into primitive operations.

"Functional" decomposition wraps callbacks into closures.

In both case the mess stays.

Choosing between these two I clearly in favor of OO, because it 
encapsulates the state into the object while the closure does it in some 
implicit way. Using plain access-to-subprogram instead of closure is the 
worst approach because maintaining the state is left to the programmer, 
which ends up with ugly void * User_Data passed around to be cast from 
type to type at run-time.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Robert I. Eachus]

On 3/28/2018 11:02 AM, Dmitry A. Kazakov wrote:
> On 28/03/2018 16:09, Alejandro R. Mosteo wrote:
>> On 24/03/18 14:12, Dmitry A. Kazakov wrote:
> 
>>> Now, programming this is like scratching your left ear with the right 
>>> hand. I keep on asking for co-routines in Ada to break out of this 
>>> lousy awful mess. To rein assorted mess of events/callbacks into a 
>>> sequence imperative calls to be a able to program it as if it were an 
>>> uninterrupted thread of control maintaining its state, just like if 
>>> the I/O were synchronous.
>>
>> I've never used coroutines. Since this kind of "imperative-like" 
>> sequences is what Rx provides, I understand that coroutines will allow 
>> the same without staying in the declarative realm?
> 
> I think so. Let you have Start_Write call and Write_Complete callback. 
> The idea is to be able to write code in a "blocking" manner like:
> 
>     declare
>        State : ...; -- Data local to the co-routine
>     begin
>        Start_Write (...);
>        Wait_For_Complete (...); -- Give up the thread of control until
>        ...                      -- Write_Complete
>        Start_Write (...);
>        ...
> 
> My understanding is that the "functional" style with closures is an 
> alternative to this which calls Start_Write and then queues a closure to 
> be called on Write_Complete. The closure will carry State with it and 
> perform chained actions.
> 
> Needless to say that I don't find closures any appealing.

My brain hurts.  It is possible to generate symmetric co-routines in 
Ada.  But you keep falling off the wagon since non-symmetric co-routines 
and especially non-blocking routines are SO much simpler.  The idea here 
is apparently to create a write "thing" that abstracts the timing 
characteristics of the physical devices involved in the writing away. 
Start with a library package that creates a hidden task type:

with Ada.Finalization;
generic
   type Object is private;
   type File is new Ada.Finalization.Limited_Controlled with
     Name: ...--parameters for creating the output target.
   end record;
package Asynch_Writes is
   procedure Create(...);
   procedure Write(Obj: Object);
   procedure Close;
end Asynch_Writes;

Strange, this looks a lot like the interface to Text_IO. ;-)  The File 
has a controlled part to insure that when the File object goes away, the 
File instance does too, and attempts to call Write raise an exception. 
(Close should do nothing if the File is already closed. ;-)  File type 
is limited to insure that copies are not made.

What does a blocking package look like?  Much the same, except for the 
name.  You don't need to create a task in the body with an entry Write, 
but that is implementation detail. ;-)  If you want, you can replace the 
task with a protected object to get co-routine semantics.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 03/04/2018 00:13, Robert I. Eachus wrote:
> On 3/28/2018 11:02 AM, Dmitry A. Kazakov wrote:
>> On 28/03/2018 16:09, Alejandro R. Mosteo wrote:
>>> On 24/03/18 14:12, Dmitry A. Kazakov wrote:
>>
>>>> Now, programming this is like scratching your left ear with the 
>>>> right hand. I keep on asking for co-routines in Ada to break out of 
>>>> this lousy awful mess. To rein assorted mess of events/callbacks 
>>>> into a sequence imperative calls to be a able to program it as if it 
>>>> were an uninterrupted thread of control maintaining its state, just 
>>>> like if the I/O were synchronous.
>>>
>>> I've never used coroutines. Since this kind of "imperative-like" 
>>> sequences is what Rx provides, I understand that coroutines will 
>>> allow the same without staying in the declarative realm?
>>
>> I think so. Let you have Start_Write call and Write_Complete callback. 
>> The idea is to be able to write code in a "blocking" manner like:
>>
>>     declare
>>        State : ...; -- Data local to the co-routine
>>     begin
>>        Start_Write (...);
>>        Wait_For_Complete (...); -- Give up the thread of control until
>>        ...                      -- Write_Complete
>>        Start_Write (...);
>>        ...
>>
>> My understanding is that the "functional" style with closures is an 
>> alternative to this which calls Start_Write and then queues a closure 
>> to be called on Write_Complete. The closure will carry State with it 
>> and perform chained actions.
>>
>> Needless to say that I don't find closures any appealing.
> 
> My brain hurts.  It is possible to generate symmetric co-routines in 
> Ada.  But you keep falling off the wagon since non-symmetric co-routines 
> and especially non-blocking routines are SO much simpler.  The idea here 
> is apparently to create a write "thing" that abstracts the timing 
> characteristics of the physical devices involved in the writing away. 
> Start with a library package that creates a hidden task type:
> 
> with Ada.Finalization;
> generic
>    type Object is private;
>    type File is new Ada.Finalization.Limited_Controlled with
>      Name: ...--parameters for creating the output target.
>    end record;
> package Asynch_Writes is
>    procedure Create(...);
>    procedure Write(Obj: Object);
>    procedure Close;
> end Asynch_Writes;
> 
> Strange, this looks a lot like the interface to Text_IO. ;-)

Yes, the idea is to have same interfaces.

> The File 
> has a controlled part to insure that when the File object goes away, the 
> File instance does too, and attempts to call Write raise an exception. 
> (Close should do nothing if the File is already closed. ;-)  File type 
> is limited to insure that copies are not made.
> 
> What does a blocking package look like?  Much the same, except for the 
> name.  You don't need to create a task in the body with an entry Write, 
> but that is implementation detail. ;-)  If you want, you can replace the 
> task with a protected object to get co-routine semantics.

My brain hurts too. I don't understand how this is not blocking. When 
Write is called it does not return until I/O is complete. Protected 
object or not, the caller is stuck there. Co-routines are supposed to 
steal the caller's task and pass it to another thread of control while 
awaiting for Write to complete.

It is just tasking without time sharing and scheduling.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Robert I. Eachus]

On 4/3/2018 4:31 AM, Dmitry A. Kazakov wrote:
>>
>> Strange, this looks a lot like the interface to Text_IO. ;-)
> 
> Yes, the idea is to have same interfaces.
> 
>> The File has a controlled part to insure that when the File object 
>> goes away, the File instance does too, and attempts to call Write 
>> raise an exception. (Close should do nothing if the File is already 
>> closed. ;-)  File type is limited to insure that copies are not made.
>>
>> What does a blocking package look like?  Much the same, except for the 
>> name.  You don't need to create a task in the body with an entry 
>> Write, but that is implementation detail. ;-)  If you want, you can 
>> replace the task with a protected object to get co-routine semantics.
> 
> My brain hurts too. I don't understand how this is not blocking. When 
> Write is called it does not return until I/O is complete. Protected 
> object or not, the caller is stuck there. Co-routines are supposed to 
> steal the caller's task and pass it to another thread of control while 
> awaiting for Write to complete.
> 
> It is just tasking without time sharing and scheduling.

I hope we are in full agreement.  We just have a different picture of 
what the Write procedure does.  So let me provide my version. To get 
asynch semantics there is a task hidden in the body which has an entry 
called by Write.  Let's use WT for the task, and WE for the entry. 
Write will pass its parameters to WE and return.  WT looks like:

     task body WE is
     begin
         ... -- Set up output device.
       loop
         select
           accept WE(...) do
             ... -- Copy any by reference parameters. No potentially
                 -- blocking actions please.
           end WE;
             .. -- do work here, such as multiple writes to disk.
                -- Blocking is not just allowed, it is expected.
           or accept Close;
             ... -- Normal file close. Blocking allowed.
             exit;
           or terminate;
         end select;
       end loop;
     exception
       -- Whatever is needed.
     end WE;

This task is what does the asynch part of setup, Write, and Close.  The 
setup actions take place at the begin corresponding to the declarative 
part containing the task declaration.  Write calls WE, any necessary 
copies are done, and the actions following the accept alternative for WE 
happen in parallel to the main program.

If you want pure co-routine semantics, move the code following end WE; 
just before it.  Wrap the code following Close in a do...end Close; and 
finally, move the code after the begin into the (generic) package.  When 
you test that version, either the main program should be running, or the 
task, or they should be in a rendezvous.  Single thread of control, 
swapped back and forth.  As I pointed out in the original post, you 
could replace the task with a protected object.

Technically, an implementation could implement the protected object as a 
task.  Notice that all of the potentially blocking actions above are not 
inside the accept statement.  In practice we expect compilers to run 
short bits of glue code from protected objects in the thread of the 
caller.  Why make the compiler writer's job harder by putting 
potentially blocking code in what looks like glue code?

What happens if you want it to be possible for hundreds of write actions 
to be pending?  Left as an exercise for the reader.  Hint: requeue ;-) 
Note that if I was grading this homework, I would take a lot of points 
off for not limiting the size of the queue.  Whether the number 
permitted to be waiting was 100, 1000, or whatever would not be that 
important.  Testing to find the value that works best is extra credit.

Re: Ada-Oriented GUI

[Dmitry A. Kazakov]

On 04/04/2018 00:32, Robert I. Eachus wrote:
> On 4/3/2018 4:31 AM, Dmitry A. Kazakov wrote:
>>>
>>> Strange, this looks a lot like the interface to Text_IO. ;-)
>>
>> Yes, the idea is to have same interfaces.
>>
>>> The File has a controlled part to insure that when the File object 
>>> goes away, the File instance does too, and attempts to call Write 
>>> raise an exception. (Close should do nothing if the File is already 
>>> closed. ;-)  File type is limited to insure that copies are not made.
>>>
>>> What does a blocking package look like?  Much the same, except for 
>>> the name.  You don't need to create a task in the body with an entry 
>>> Write, but that is implementation detail. ;-)  If you want, you can 
>>> replace the task with a protected object to get co-routine semantics.
>>
>> My brain hurts too. I don't understand how this is not blocking. When 
>> Write is called it does not return until I/O is complete. Protected 
>> object or not, the caller is stuck there. Co-routines are supposed to 
>> steal the caller's task and pass it to another thread of control while 
>> awaiting for Write to complete.
>>
>> It is just tasking without time sharing and scheduling.
> 
> I hope we are in full agreement.  We just have a different picture of 
> what the Write procedure does.  So let me provide my version. To get 
> asynch semantics there is a task hidden in the body which has an entry 
> called by Write.  Let's use WT for the task, and WE for the entry. Write 
> will pass its parameters to WE and return.  WT looks like:
> 
>      task body WE is
>      begin
>          ... -- Set up output device.
>        loop
>          select
>            accept WE(...) do
>              ... -- Copy any by reference parameters. No potentially
>                  -- blocking actions please.
>            end WE;
>              .. -- do work here, such as multiple writes to disk.
>                 -- Blocking is not just allowed, it is expected.
>            or accept Close;
>              ... -- Normal file close. Blocking allowed.
>              exit;
>            or terminate;
>          end select;
>        end loop;
>      exception
>        -- Whatever is needed.
>      end WE;
> 
> This task is what does the asynch part of setup, Write, and Close.

No, that does not work. The task must handle multiple I/O operations 
running simultaneously. As an example consider a socket selector that 
handles 1000+ sockets. The goal is to write a thread of control for each 
of the sockets in a way one would do with a blocking socket but without 
1000+ tasks chocking the scheduler.

A socket selector tells its owner which socket can be read/written 
without blocking. The implementation should switch to the co-routine 
handling the socket, read or write a portion of the buffer provided in 
the "blocking" call done by the co-routine. If all buffer read/written 
it passes the control to the co-routine, which then handles the protocol 
a usual sequential way. The co-routine gives control up when it needs 
another portion of data from the socket and does next "blocking" call. 
When the buffer is not completed, the task services another socket and 
another co-routine. This is a kind of light-weight scheduler driven by 
I/O events rather than by clock.

> What happens if you want it to be possible for hundreds of write actions 
> to be pending?  Left as an exercise for the reader.  Hint: requeue ;-) 

No, that does not work either. Requeue re-queues a *task" of the caller 
side. The problem is that there is no task to re-queue.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada-Oriented GUI

[Jeffrey R. Carter]

On 03/24/2018 12:36 PM, Alejandro R. Mosteo wrote:
> 
> The primitive tasking facilities of most popular languages, 20+ years after Ada, 
> is one of the things that most amazes me (in a bad way).

The basics of Ada tasking have been around since Ada 83, so > 30 yrs.

-- 
Jeff Carter
"Mr. President, we must not allow a mine-shaft gap!"
Dr. Strangelove
33

Re: Ada-Oriented GUI

[Dan'l Miller]

On Thursday, March 22, 2018 at 6:47:28 PM UTC-5, Randy Brukardt wrote:
> (Ada is wildly inappropriate for applications that are mostly GUI - use some 
> web-based langauge for that and use Ada for the heavy-duty processing.)

So “Ada is wildly inappropriate for” graphical user interfaces in avionics cockpits?  Well, I guess that we can mark that one off the list then.  Real-time avionics backend to control the fly-by-wire hardware of the airplane in Ada, and the GUI for the cockpit in C# or Java on CLR or JVM bytecode VMs, right?

Re: Ada-Oriented GUI

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:ef8da3f2-70b3-4412-8a28-cedfc463d7ff@googlegroups.com...
On Thursday, March 22, 2018 at 6:47:28 PM UTC-5, Randy Brukardt wrote:
>> (Ada is wildly inappropriate for applications that are mostly GUI - use 
>> some
>> web-based langauge for that and use Ada for the heavy-duty processing.)

>So "Ada is wildly inappropriate for" graphical user interfaces in avionics 
>cockpits?
>Well, I guess that we can mark that one off the list then.  Real-time 
>avionics
>backend to control the fly-by-wire hardware of the airplane in Ada, and the
>GUI for the cockpit in C# or Java on CLR or JVM bytecode VMs, right?

Calling an avionics display a "GUI" is confusing at best; there is little 
relationship because of the strict requirements on avionics software. 
(Something like RX would be unlikely to fly - pun intended - there can't be 
"unexpected" anything in avionics software.)

For a conventional GUI (as in Windows or phone apps), some sort of web 
technology seems like the way to go. If done right, very little code in a 
conventional programming language is needed. One could use something like 
Gnoga for that code. So I'm thinking of more like Ada + HTML rather than Ada 
+ some other programming language.

                               Randy.

Re: Ada-Oriented GUI

[Dan'l Miller]

On Monday, March 26, 2018 at 5:29:08 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:ef8da3f2-70b3-4412-8a28-cedfc463d7ff@googlegroups.com...
> On Thursday, March 22, 2018 at 6:47:28 PM UTC-5, Randy Brukardt wrote:
> >> (Ada is wildly inappropriate for applications that are mostly GUI - use 
> >> some
> >> web-based langauge for that and use Ada for the heavy-duty processing.)
> 
> >So "Ada is wildly inappropriate for" graphical user interfaces in avionics 
> >cockpits?
> >Well, I guess that we can mark that one off the list then.  Real-time 
> >avionics
> >backend to control the fly-by-wire hardware of the airplane in Ada, and the
> >GUI for the cockpit in C# or Java on CLR or JVM bytecode VMs, right?
> 
> Calling an avionics display a "GUI" is confusing at best; there is little 
> relationship because of the strict requirements on avionics software. 
> (Something like RX would be unlikely to fly - pun intended - there can't be 
> "unexpected" anything in avionics software.)
> 
> For a conventional GUI (as in Windows or phone apps), some sort of web 
> technology seems like the way to go. If done right, very little code in a 
> conventional programming language is needed. One could use something like 
> Gnoga for that code. So I'm thinking of more like Ada + HTML rather than Ada 
> + some other programming language.

I agree with you for the majority of database-retrieval-from-servers apps on mobile devices, but I vociferously disagree the more the app differs from database-retrieval-from-servers:

https://www.abiresearch.com/market-research/product/1006117-mobile-augmented-reality

So unlike the augmented-reality on a cockpit, augmented-reality in consumer mobile devices is unworthy of the grand Ada.

So unlike the gyroscopes on an airplane, the gyroscopic sensors in consumer mobile devices are unworthy of the grand Ada.

So unlike the GPU physics-processor in the cockpit of an airplane, the GPU physics-processor in consumer mobile devices are unworthy of the grand Ada.

So unlike the realtime crisp low-latency relatively high-frames-per-second images in cockpit displays, the low-latency relatively-high-frames-per-second imagery in a game or augmented reality in consumer mobile devices is unworthy of the grand Ada's compilation to processor-native instruction sets, but rather mobile consumer devices should display game & augmented-reality images should have the sluggish user experience as if they are executing on a Commodore 64, due to HTML and Javascript implementations.  By the way, perhaps this Commodore 64 emulator in Javascript would complete that vision of sluggishness, jitter, slowness, and high latency: 

http://badassjs.com/post/875129932/commodore-64-and-gameboy-emulation-in-javascript

I presume that this lack of worthiness of the grand Ada is because consumer mobile devices have no defense contractor with deep pockets shelling out gobs of money for compiler toolchain licenses & support fees.

Re: Ada-Oriented GUI

[Dennis Lee Bieber]

On Mon, 26 Mar 2018 17:29:06 -0500, "Randy Brukardt" <randy@rrsoftware.com>
declaimed the following:


>Calling an avionics display a "GUI" is confusing at best; there is little 
>relationship because of the strict requirements on avionics software. 
>(Something like RX would be unlikely to fly - pun intended - there can't be 
>"unexpected" anything in avionics software.)
>
	Yeah... The typical display is a dedicated processor of its own,
accepting a limited set of commands if it is a text display (the interface
to the flight management computers, say) with less capability than
/curses/, and a number of discrete function keys. The display processor
collects any inputs, and only sends to the FMC when a "commit" discrete is
pressed.

	Navigation displays would be similarly limited -- a dedicated processor
for the display, accepting a limited set of data for presentation (such as
a way-point/coordinates list).

	Health management system is the closest to something running a "GUI",
and those systems are not flight critical (if it fails, one just loses
health information meant for later analysis).


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/ 

Re: Ada-Oriented GUI

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> Health management system is the closest to something running a "GUI",
> and those systems are not flight critical (if it fails, one just loses
> health information meant for later analysis).

Or the patient dies.

Re: Ada-Oriented GUI

[Dennis Lee Bieber]

On Tue, 27 Mar 2018 08:52:07 +0100, Simon Wright <simon@pushface.org>
declaimed the following:

>Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>
>> Health management system is the closest to something running a "GUI",
>> and those systems are not flight critical (if it fails, one just loses
>> health information meant for later analysis).
>
>Or the patient dies.

	I was talking about /aircraft/ health management -- which essentially
just logs results of self-tests from other critical components. Things like
landing cycles (to produce suggestions for service of components rated for
/x/-cycles, etc.). Temperature trends, other stuff that in post-analysis
might reveal a potential problem. And possibly also manages data loading
for those other components (in place of a dedicated data loader for each --
of course, data loading is still limited to being on-ground, engines-off).



-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/ 

Re: Ada-Oriented GUI

[Robert I. Eachus]

On 3/26/2018 6:29 PM, Randy Brukardt wrote:

> Calling an avionics display a "GUI" is confusing at best; there is little
> relationship because of the strict requirements on avionics software.
> (Something like RX would be unlikely to fly - pun intended - there can't be
> "unexpected" anything in avionics software.)

Sorry Randy I think I know what you were intending to say, but I suspect 
that many readers here will get the wrong impression.

Military Avionics software has to be written to minimize the effect of 
unexpected events,   If a sudden hole appears through the fuselage--and 
the avionics, the pilot would very much like the controls to work until 
he (or she) is back over friendly territory.  The government which paid 
$100 million plus for the aircraft would like it even more if the pilot 
can land the plane.

Both F-15E and A-10 have been successfully landed "on a wing and a 
prayer" with one wing missing.  To do this you need to design with most 
systems doing automatic fallbacks if some of its inputs are missing. (If 
one aileron is missing, it would be nice if the one on the remaining 
wing still worked.) More important, any system which is fubared (fouled 
up beyond all recovery) needs to tell the pilot that it has failed--and 
shut up.  Diagnostics are for after landing.  The A-380 passenger plane 
got this one wrong.  It took the crew hours to shut down systems which 
were periodically saying that they were inoperable, so they could figure 
out what was working and what wasn't, and land the plane.

I'd apologize for the rant, but I figure that if one person reads this 
and designs a system correctly it will have been worthwhile.  And this 
audience is probably a target rich environment for avionics software 
designers. ;-)

Re: Ada-Oriented GUI

[Andrew Shvets]

On Sunday, March 18, 2018 at 9:33:26 AM UTC-4, Jeffrey R. Carter wrote:
> I've written on here before that I think the traditional 
> register-callbacks-and-call-a-procedure GUI interface is a hack only suitable 
> for sequential languages, and attempted to describe my idea of how a GUI for a 
> concurrent language like Ada should work. Some have expressed the opinion that 
> such an interface is not possible.
> 
> I've now written a very minimal GUI interface embodying my concepts. It 
> implements text boxes and buttons, as that is the minimum for an example that 
> actually does something faintly interesting. For an example, I've used the 
> Random_Int demo from Gnoga.
> 
> I've also made a quick and dirty implementation of the interface on top of 
> Gnoga, and a version of Random_Int using the interface. Though the Gnoga version 
> of Random_Int is very simple and fairly easy to understand, this version is 
> easier to understand.
> 
> Those interested can find Ada_GUI at
> 
> https://github.com/jrcarter/Ada_GUI
> 
> Those who like programming by extension won't like it.
> 
> -- 
> Jeff Carter
> "Insufficient laughter--that's grounds for divorce."
> Play It Again, Sam
> 126

I agree that it's a "hack".  This seemed like a forced solution for the problem at hand.  I'll have a look at your implementation.