From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3db17e1869f3a33d X-Google-Attributes: gid103376,public From: michael@ifr.luftfahrt.uni-stuttgart.de Subject: Re: Ada95 Streams Question Date: 1996/06/24 Message-ID: <4qlshm$1j9e@info4.rus.uni-stuttgart.de>#1/1 X-Deja-AN: 161824517 references: <9606232338.AA12517@nile.gnat.com> organization: Comp.Center (RUS), U of Stuttgart, FRG newsgroups: comp.lang.ada Date: 1996-06-24T00:00:00+00:00 List-Id: Robert Dewar wrote: > "I have connected an Ada95 executable to a C++ executable using streams. The Ada > is the brains of the application, and the C++ is the Motif pretty face. On both > sides I have defined a set of portable types which application types are > converted to for transmission and converted from on receipt." > > This should work reasonably reliably with GNAT, cannot say for other > Ada 95 compilers which might do something completely different for > stream rerpresentations of primitive data. > > It is a bit of a puzzle to us why you don't just use a procedural > interface. It would be MUCH more portable, and MUCH more efficient Of course I can only speculate why such an approach might make sense for the original poster of this question (I don't know who that was) but I can say that I can think of a lot of reasons to try this because we are facing exactly the same problem. We are in the busyness of vehicle trajectory optimization. The software package we have developed for this purpose manly consists of two parts. One part, which the original poster called the "pretty face", is the graphical user interface which controls the whole operation of the software and the second part is "the brains of the application" which does all the numerics and contains the user provided procedures to describe the vehicle model. When you are working with a model this "brain" has to be recompiled and relinked several times and this process is controlled by the "pretty face". According to this setup it obviously makes sense to keep these two parts separate and not link them into one big executable. But, when the "brain" is working it has to closely interact with the "pretty face" which is, e.g. showing the progress of the optimization process. The two processes are connected with each other via files and pipes and it would now be very elegant to use streams to read and write the data. I always thought that this is exactly what streams are made for. A further advantage of this separation is that you can run the "brain" on another computer, maybe a high performance server. This kind of distribution seems to be quite natural to me but I sometimes have the feeling that the Ada community has not yet understood the benefits of distribution and client server computing. The first problem arises when you try to exchange stream data files between computers of different architectures. This is just not foreseen by the Ada 95 standard (see implementation advice in RM and current practice of GNAT). For the described setup it would be even more elegant to utilize an implementation of the distributed system annex but as this builds on the stream facility as well you face the same problem as mentioned above. If you just look at the wording of this annex the big picture is a huge monolithic program that is now broken into pieces (partitions) and executed as a whole on a homogenous network of computers. That is definitely not what I understand by distributed computing. Although this could certainly be interpreted in a more open way, this is exactly what is currently implemented for GNAT. This is not meant as a criticism of the GNAT team. They do a marvelous job and just implemented what the standard suggests. I just want the Ada community to reconsider the real "openness" of Ada with respect to heterogeneous computer environments and client server computing. Michael -- ------------------------------------------------------------------------ --Dipl.-Ing. Michael Paus (Member: Team Ada) --University of Stuttgart, Inst. of Flight Mechanics and Flight Control --Forststrasse 86, 70176 Stuttgart, Germany --Phone: (+49) 711-121-1434 FAX: (+49) 711-634856 --Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)