Re: Ada's (in)visibility

Re: Ada's (in)visibility

[Mic hael Hagerty]

In a message to ALL, KEVIN RODGERS writes:

K.                                             Back about four years ago,
K. the word was that all of our deliverable vehicle simulations for future
K. contracts would be required to be in Ada (they are currently in
K. Fortran). Several of us forward-looking regular engineers went out,
K. learned Ada, and became reasonably proficient in it.  What happens?
K. Either the gov't decides not to specify Ada for the sim (and sometimes
K. not even the flight software) or our management weasels out of it.

I've seen a similar situation (Navy/FORTRAN shop) where a number of the
software types seem eager to learn the "A" language and have gone out of
the way to take classes, etc.  Unfortunately, management is reluctant to
move to Ada, but seems very willing to fully embrace C instead...  As I
live and learn, I am continually amazed!

K. From what I've seen, the Army is the most reluctant to move to Ada.

Well, golly...  I sat at a table for dinner with Grace Hopper the week that
"green" became Ada.  Her comment was that if she had her way, she would
"scuttle it"...  I see system after system being done by or for the Navy
in C (and FORTRAN) and never hear of approved waivers.

The most coneheaded response I've heard to the question, "Why didn't you
do it in Ada, the mandated language?" was, "We had to be compatible with
X-windows, the Navy standard, and there was no requirement for Ada."  Of
course the Navy had yet (has it since then?) to select a windowing standard
of any kind.  The more I see of this, the more disheartened I become.  It
seems that all the excuses are like a**holes; everyone has one and they all
stink...

Regards, Mikey (michael.hagerty@nitelog.com)

---
Statements and opinions are mine alone -- I have no idea what my company
thinks about these issues.
---
 . JABBER v1.3.1 #.042 . Be suspicious of all native-born Esperanto speakers.
                                                                               
                                                      

Re: Ada's (in)visibility

[Dag Bruck]

In <comp.lang.ada> michael.hagerty@nitelog.com (Michael Hagerty)  writes:
>
>The most coneheaded response I've heard to the question, "Why didn't you
>do it in Ada, the mandated language?" was, "We had to be compatible with
>X-windows, the Navy standard, and there was no requirement for Ada."

What _is_ the preferred Ada interface to X11R5?  Can you use Ada
tasking and X11 callbacks in the same program?

People I have reasonable confidence in have told me that there are
problems, but I would be grateful for some more detailed comments.

		-- Dag

Re: Ada's (in)visibility

[munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!brt.deakin.edu.au!dougcc]

In article <244.237.uupcb@nitelog.com>, michael.hagerty@nitelog.com
(Michael Hagerty) writes:

> The most coneheaded response I've heard to the question, "Why didn't you
> do it in Ada, the mandated language?" was, "We had to be compatible with
> X-windows, 

I suppose their documentation for Xlib calls used C syntax, so they think
this means they have to use C?  Coneheaded indeed.

> It seems that all the excuses are like a**holes; everyone has one and
> they all stink...

How true...

Re: Ada's (in)visibility

[Larry Maturo]

In article <1992Sep29.152124.8143@brt.deakin.edu.au> dougcc@brt.deakin.edu.au (
Douglas Miller) writes:
>In article <244.237.uupcb@nitelog.com>, michael.hagerty@nitelog.com
>(Michael Hagerty) writes:
>
>> The most coneheaded response I've heard to the question, "Why didn't you
>> do it in Ada, the mandated language?" was, "We had to be compatible with
>> X-windows, 
>
>I suppose their documentation for Xlib calls used C syntax, so they think
>this means they have to use C?  Coneheaded indeed.
>
>> It seems that all the excuses are like a**holes; everyone has one and
>> they all stink...
>
>How true...


To be fair Xlib is not suitable to mulitasking and most large Ada systems use
tasking.  There is no good solution to this probelem yet.  There are kludgy
workarounds however.  C++ will face this same problem if it ever gets tasking
added to it.  Modula-3 is the only language I know of that has a good multitask
ing
X-Windows compatible solution.  By the way, we use Ada and an X-Windows kludge
here so I'm not knocking Ada.

+-----------------------------------+----------------------------------------+
|                                   |                                        |
| Larry Maturo                      | Opinions expressed herein must be      |
| Tactical Simulation Division      | yours, neither I nor my employer have  |
| Applied Research Laboratories     | any.                                   |
| University of Texas at Austin     |                                        |
| P.O. Box 8029                     +----------------------------------------+
| Austin, Texas 78713-8029          |                                        |
|                                   | When you're as great as I am it's hard |
| larry@titan.tsd.arlut.utexas.edu  | to be modest, but I succeed where      |
|                                   | others fail.                           |
+-----------------------------------+----------------------------------------+

Re: Ada's (in)visibility

[David Emery]

>To be fair Xlib is not suitable to mulitasking and most large Ada systems use
>tasking.  There is no good solution to this problem yet.  

There is a very good solution to this.  Don't use tasks.  Write
sequential Ada.  This provides EXACTLY the same kind of program you
would get if you wrote the application in C.  Just because Ada has
tasking, there is no obligation to use it in any specific application.
I'm always bothered by people who use lack of support for Ada's
advanced featuers to write a program in C that can be done in
equivalent Ada (without tasking, for instance).

An true Ada binding to Xlib should handle the tasking issue (perhaps
by abstracting a kludge).  This is one of the things that makes doing
good Ada bindings non-trivial.  If someone tries to sell a "binding"
to Xlib that does not handle tasks, he's not selling a binding.
Instead, he's selling PRAGMA INTERFACE(C), without doing any of the
real work.  

The real solution for Ada and X Windows will occur when X Windows is
multi-threaded in a way that meshes with Ada tasks.  

				dave

Re: Ada's (in)visibility

[Dag Bruck]

In <comp.lang.ada> emery@Dr_No.mitre.org (David Emery) writes:
>
>The real solution for Ada and X Windows will occur when X Windows is
>multi-threaded in a way that meshes with Ada tasks.  

My _guess_ is that X will be compatible with POSIX threads, if X ever
gets threaded.  The question then is how compatible POSIX threads and
Ada tasks are...

Re: Ada's (in)visibility

[David Emery]

>My _guess_ is that X will be compatible with POSIX threads, if X ever
>gets threaded.  The question then is how compatible POSIX threads and
>Ada tasks are...

Once POSIX threads are an approved standard (or at least are
"stable"), I'm sure you are correct.  Right now IEEE P1003.4a is still
in ballot, and it's my understanding that they are not very close to
completion.  In the interim, I don't know what thread/concurrency
model X11R6 is/will be based on.

IEEE P1003.20 is specifically tasked with working out how Ada tasks
and POSIX Threads interact.  There'll be a meeting of this group as
part of the POSIX meetings in Utrecht, Netherlands 19-23 October 1992.

				dave

Re: Ada's (in)visibility

[cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!goodsenj]

emery@Dr_No.mitre.org (David Emery) writes:
>
>>To be fair Xlib is not suitable to mulitasking and most large Ada systems use
>>tasking.  There is no good solution to this problem yet.
>
>There is a very good solution to this.  Don't use tasks.  Write
>sequential Ada.  This provides EXACTLY the same kind of program you
>would get if you wrote the application in C.  
>

This is a poor solution.  It is quite feasible to use Ada
tasking with Xlib applications, however, you must design
the application up front to ensure that only a single thread
is making Xlib calls up front.  The problem gets harder if
you attempt to address the potential for deadlock within a task
caused by a callback into the application.  In this case, you
need access to the task id to ensure you don't lock out the same
thread more than once.  See the Xhibition 91 conference proceedings
for a paper on this subject.

>Just because Ada has
>tasking, there is no obligation to use it in any specific application.
>I'm always bothered by people who use lack of support for Ada's
>advanced featuers to write a program in C that can be done in
>equivalent Ada (without tasking, for instance).
>


>
>An true Ada binding to Xlib should handle the tasking issue (perhaps
>by abstracting a kludge).  This is one of the things that makes doing
>good Ada bindings non-trivial.  If someone tries to sell a "binding"
>to Xlib that does not handle tasks, he's not selling a binding.
>Instead, he's selling PRAGMA INTERFACE(C), without doing any of the
>real work.
>

There do exist commercial bindings which are thread safe for the
Verdix Ada compiler in Xlib applications.

>
>The real solution for Ada and X Windows will occur when X Windows is
>multi-threaded in a way that meshes with Ada tasks.

Xlib will never be multi-threaded, however, there is a high
probability that R6 will support multiple threads (unix threads), by
using extending the null locking macros to be a complete
implementation.  This will only make Xlib thread safe, not
multi-threaded in it's own right.  In addition, this doesn't
necessarily mean that it will be *safe* to use with Ada tasks, unless
an Ada task maps directly to a unix thread.

Because of this, you must rely on tasking safe bindings which perform
the locking or use an Ada toolkit, like GRAMMI which directly
addresses and solves the multi-tasking problem.

John Goodsen
goodsenj@ajpo.sei.cmu.edu

Re: Ada's (in)visibility

[Thomas N Erickson]

>To be fair Xlib is not suitable to mulitasking and most large Ada systems use
>tasking.  There is no good solution to this probelem yet.  There are kludgy
>workarounds however.  C++ will face this same problem if it ever gets tasking
>added to it.  Modula-3 is the only language I know of that has a good multitas
king
>X-Windows compatible solution.  By the way, we use Ada and an X-Windows kludge
>here so I'm not knocking Ada.


We at Alsys have just released a product call AdaXlib, which is an Ada
implementation of the X library, including support for multi-tasking. 
This should address much of the needs for Ada support for X-Windows.

Tom Erickson
Alsys
tne@world.std.com

(617)270-0030