A small Ada success story

A small Ada success story

[Steffen Huber]

Hi,

after reading this newsgroup for some time now, I thought I should tell you
about a small, but very successful project implemented in Ada 95. Just to
show those that think that Ada is only used in the military industry how
wrong they are ;-)

Let me start with some history. It was the summer of 1996 when I bought
(together with some friends) a CD writer. Unfortunately, I was only able to
use it with my PC, but not with my preferred platform (RISC OS on a Risc PC
from Acorn) due to lack of software. After obtaining the necessary
documentation for programming the CD writer, I started to implement a small
prototype of a CD writing application capable of reading and writing audio
and data tracks. This implementation was done in BBC Basic V, widely
considered as the fastet interpreted BASIC around (the interpreter is
included in the ROM of RISC OS, so it is usually used for quick-and-small
projects and prototypes, or as a glorified scripting language).

Some companies expressed an interest to turn this prototype into
a commercial product. So I had to decide which way to go:
a) further development in BASIC (even the prototype was quite nicely
   modularised and structured, so it was indeed an option)
b) new implementation in C (everybody on this platform uses either
   C or assembler...I don't know why ;-))
c) new implementation using another language

At university, I already implemented two projects in Ada, so I had
a basic knowledge of Ada (Ada 83, to be more precise), and the results
and experiences were very positive. After I discovered that a port
of GNAT was available for the RISC OS platform, I decided to take
option c) and implement everything in Ada.

Now, over two years later, the project is still alive and happy, and
despite the continuous development, the maintainability is still
very high. The features of CDBurn (the name of the product) now include
an ISO formatter with support for a very flexible filename translation
scheme, Joliet and on-the-fly writing. CDBurn is also capable of driving
a wide range of available drives, and supports disc-at-once writing.
All this functionality is controlled by a very nice UI (for those of
you wondering about RISC OS, the GUI is IMHO still the best thing since
sliced bread), and everything is 100% Ada.

Several key advantages of Ada surfaced during the project - especially
the powerful structuring possibilities and the full control over
representation issues (very valuable when interfacing with SCSI devices).

All in all, I am sure that taking one of the alternative routes would
have resulted in a more time consuming (overall development effort
was around 3 man months until now, and this includes the work done on
the bindings to RISC OS - I was the first developer to use GNAT on
RISC OS, so I had to do this on my own ;-)) and less powerful/less
maintainable solution.

So long, Steffen

-- 
Steffen Huber           LambdaComm System - Welcome to Trollinger Country
hubersn@lcs.wn.bawue.de                       acorn2@ftp.uni-stuttgart.de
... Bosheit ist nicht in der Lage, Dummheit vollstaendig zu simulieren. (JL)

Re: A small Ada success story

[Tom Moran]

> Just to
>show those that think that Ada is only used in the military industry how
>wrong they are ;-)
  A few years ago I did some work for a stock&commodity data retailer.
They had historical data plus real time satellite feeds and they sold
requested data to dial-up customers  (in the style HP nowadays calls
an E-Service)..
  One project involved their buying historical stock price data from
another vendor and merging it with their own - filling gaps and
correcting errors.  This involved a substantial volume of data and
algorithms and heuristics to distinguish error from price
fluctuations, splits, etc.  I used an Ada 9X beta compiler.  The
database prices were already stored as fixed point with a delta of
1/8.  The main program copied and merged, spinning off questionable
situations to a task that displayed a price history graphically for a
human decision maker. 
  I well remember one early demo where the program got a
Constraint_Error at such and such a line number.  Within a few minutes
I had it explained, fixed, recompiled, and was re-running the demo.
The client was impressed.  In C there would have been no error, just
bad data in the database.   
  As of last year the company was still growing (they asked me for
changes to handle some new hardware). 

Re: A small Ada success story

[dennison]

In article <36efef1c.3265725@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
>   I well remember one early demo where the program got a
> Constraint_Error at such and such a line number.  Within a few minutes
> I had it explained, fixed, recompiled, and was re-running the demo.
> The client was impressed.  In C there would have been no error, just
> bad data in the database.

I sure wish more compiler vendors made this information (line number of an
exception occurrence) available without using a debugger.


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A small Ada success story

[Nick Roberts]

Well done, Steffen!  It comes as no great shock to those who have been using
Ada for years when someone reports such delight in their decision to use Ada
for a project, but it always comes as a pleasure.

SIGAda has a list of success stories
(http://www.acm.org/sigada/education/success.html), as do some other sites:
you may be able to get yourself listed!  Also see the
http://www.adahome.com/FAQ/team-ada.html site.

I hope very much that your product has much further success.

-------------------------------------
Nick Roberts
-------------------------------------

Re: A small Ada success story

[Corey Ashford]

dennison@telepath.com wrote:
> 
> In article <36efef1c.3265725@news.pacbell.net>,
>   tmoran@bix.com (Tom Moran) wrote:
> >   I well remember one early demo where the program got a
> > Constraint_Error at such and such a line number.  Within a few minutes
> > I had it explained, fixed, recompiled, and was re-running the demo.
> > The client was impressed.  In C there would have been no error, just
> > bad data in the database.
> 
> I sure wish more compiler vendors made this information (line number of an
> exception occurrence) available without using a debugger.
> 

Shameless plug:

Rational Apex 3.0.0b provides something that's better in some ways.

There's a set of stack trace utilities that allows you to get a complete PC stack trace
as well as the values of the machine registers when the exception was raised.
This information can be dumped to a file in ASCII and forwarded to whomever
produced the application.  Even better, if one exception was raised and then
translated to another exception (i.e. a different exception was raised)
from within the handler, the stack trace will show
the entire chain of exceptions that led to the final exception which was unhandled.
There are some other nice features as well, such as being able to obtain a stack
trace from arbitrary execution points in an application.

Currently, it doesn't have the capability of generating a file name and line number at run time,
but end-users of applications usually don't care to see that kind of information anyway.
You can rig your application to automatically dump the stack trace to the file.
When the customer calls and says, "hey!  this stupid thing crashed with an
unhandled exception!" you calm them down and then ask them to send you the small
dump file via email.  You then read this file into the debugger and it will show
you the symbolic stack trace where the program crashed (including line numbers, etc.)
Or you can chase down the line numbers by hand using the PC's from the dump file.

Alternatively, you can rig the application to generate a core dump image when an
unhandled exception occurs.  This gives you far more debugging information at the
expense of making it more difficult to transmit the dump file to the developer.

- Corey

Re: locating exceptions (was: Ada success story)

[Markus Kuhn]

dennison@telepath.com writes:
|> In article <36efef1c.3265725@news.pacbell.net>,
|>   tmoran@bix.com (Tom Moran) wrote:
|> >   I well remember one early demo where the program got a
|> > Constraint_Error at such and such a line number.  Within a few minutes
|> > I had it explained, fixed, recompiled, and was re-running the demo.
|> > The client was impressed.  In C there would have been no error, just
|> > bad data in the database.
|> 
|> I sure wish more compiler vendors made this information (line number of an
|> exception occurrence) available without using a debugger.

Or better produce a core dump (which contains much more info than just
the line number).

That is actually the single thing I particularly dislike about
the current GNAT version: An unhandeled exception gives you
no useful information whatsoever unless you had the application
running in a debugger. But you use a debugger normally only if
you expect an error, so unexpected constraint errors cause a
lot of hazzle to locate (rerun everything inside gdb in the hope
you can reproduce the circumstances).

Things where actually easier in C: If you got a segmentation
violation, the OS would produce a core dump, in which you then can
locate with gdb not only the place where the process violated its
memory limits, but you also could inspect the values of variables
that led to this. GNAT's Ada code practically never produced a core
dump, which can be very inconvenient.

It would be a very significant improvement if the code produced by
GNAT with option -g would always produce a core dump as a result of an
unhandeled exception, with the program counter at the place where the
exception was first triggered and the call stack of all threads intact.
Then I could claim that debugging Ada is really more convenient than
debugging C because then I could use gdb as easily to dig around in the
extremely useful core files.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: A small Ada success story

[bill]

In article <36F0A77F.B0151962@rocketmail.com>, Corey says...
 
>> I sure wish more compiler vendors made this information (line number of an
>> exception occurrence) available without using a debugger.
>> 
>
>Shameless plug:
>
>Rational Apex 3.0.0b provides something that's better in some ways.
>
 

Java does all that out of the box. I found Ada exception tracing to be weak
compared to Java more powerfull exceptions. In Java, an exception is an object,
that contains very usefull info that one can use.

Bill.

Re: A small Ada success story

[dewar]

In article <36F0A77F.B0151962@rocketmail.com>,
  Corey Ashford <yeroca@rocketmail.com> wrote:
> Currently, it doesn't have the capability of generating a
> file name and line number at run time, but end-users of
> applications usually don't care to see that kind of
> information anyway.

Well perhaps not end users, but in my opinion it is VERY
useful to have such information, and the GNAT design for
exception trace back (as currently implemented on Solaris,
which is the first target for which we have provided this
capability), allows you to specify whether you want
symbolic tracebacks with file names and line numbers or
not. If not, then you can use addr2line to convert the
non-symbolic values to symbolic ones.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A small Ada success story

[Michael F Brenner]

>>   I well remember one early demo where the program got a
>> Constraint_Error at such and such a line number.  Within a few minutes
>> I had it explained, fixed, recompiled, and was re-running the demo.
>> The client was impressed.  In C there would have been no error, just
>> bad data in the database.

T.E.D.> I sure wish more compiler vendors made this 
      > information (line number of an exception occurrence) 
      > available without using a debugger.


I agree, this would be a welcome enhancement.

Re: A small Ada success story

[Fraser Wilson]

paene lacrimavi postquam bill@newsguy.com scribavit:

>Java does all that out of the box. I found Ada exception tracing to be weak
>compared to Java more powerfull exceptions. In Java, an exception is an object,
>that contains very usefull info that one can use.

I often wondered about an extension to the exception declaration syntax:

    Error : exception with record Exception_Type : Natural;  end record;

(Not that I'd ever use a Natural in this way of course!)

Mind you, Ada 95 gives you messages and stuff.

I think the problem with attaching a bunch of arbitrary information to an
exception is that the exception itself is supposed to be, well, exceptional.
Furthermore, if you read the Quality and Style guide, you'll notice that
it suggests providing query functions that can be used to prevent an
exception from being raised; e.g. for array-based stacks, a function
Stack_Is_Full.

Given all that, what would all this extra info buy you, apart from a
temptation to use exceptions as flow control?  In any case, you can always
query the package that raised the exception to find out what went wrong.

I fear I sound like one of the "Ada does it this way; therefore it must
be correct" zealots.  Oh, well.

Fraser.
(change i's to y's for my real email address)

Re: A small Ada success story

[Larry Kilgallen]

In article <7crpn2$kt6@drn.newsguy.com>, bill <bill@newsguy.com> writes:

> Java does all that out of the box. I found Ada exception tracing to be weak
> compared to Java more powerfull exceptions. In Java, an exception is an object,
> that contains very usefull info that one can use.

Information regarding Ada95 exceptions can be retrieved;
I am not convinced that saying they "contain" the data or
that they are "objects" would enhance anything.

Larry Kilgallen

Re: locating exceptions (Ada vs. Java)

[Markus Kuhn]

In article <7crpn2$kt6@drn.newsguy.com>, bill <bill@newsguy.com> writes:
|> Java does all that out of the box. I found Ada exception tracing to be weak
|> compared to Java more powerfull exceptions. In Java, an exception is an object,
|> that contains very usefull info that one can use.

What does Java do in the case of out-of-memory exceptions in small
embedded systems (e.g., Java smartcard with 256 bytes RAM), where
there might not be space free for allocating an exception object?
Ada's exception mechanism sounds to me less comfortable, but more
foolproof here, as it does not rely on an operational heap. Also
remember that Ada was designed to allow using a heap-free subset
of the language for high-assurance applications (you do not want
to rely on malloc() in pacemakers and chemical process control
software).

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: locating exceptions (Ada vs. Java)

[bill]

In article <7cvu1s$14g$2@pegasus.csx.cam.ac.uk>, mgk25@cl.cam.ac.uk says...
>
 
>What does Java do in the case of out-of-memory exceptions in small
>embedded systems (e.g., Java smartcard with 256 bytes RAM), where
>there might not be space free for allocating an exception object?

I am not an expert on this subject, but I understand there is a special 
version of the JVM run-time for embedded Java stuff? 

check for example http://java.sun.com/products/javacard/

selected quotes:

"The Java Card specifications enable Java technology to run
 on smart cards and other devices with limited memory."

"Java Card technology preserves many of the benefits of the
 Java programming language - productivity, security,
 robustness, tools, and portability - while enabling Java
 technology for use on smart cards. The Virtual Machine
 (VM), the language definition, and the core packages have
 been made more compact and succinct to bring Java
 technology to the resource - constrained environment of smart cards."

"The Java Card Application Environment can run in devices
 with memory as small as 24K of ROM, 16K of EEPROM, and
 512 bytes of RAM."

Also check : http://java.sun.com/products/personaljava/

"
             technology-enabled micro web browser
             for consumer devices, part of its Personal
             Applications product suite."


There seem to be all sort of Java stuff running on small devices, Java 
in wireless devices, etc.. So, I assume these things do work?

Second, the way JVM works is that it pre-allocate memory for its 
heap usage at the start. so, when doing new() something, memory 
is always allocated from that reserved memory.  the JVM does not go 
to the OS everytime it needs to allocate memory.  (i.e. malloc(), free()
works against this pre-allocated memory).

So, I guess for embedded stuff, the JVM will allocate whatever memory on
the board, or the device, there is or as configured and re-use only that. 

>Ada's exception mechanism sounds to me less comfortable, but more
>foolproof here, as it does not rely on an operational heap. 

Well, I don't see the difference between pre-allocating some large
amount of memory for use by the JVM as the heap and working within
that limit throught the running of the program, and between pre-allocating
some large amount of static memory. Heap and stack and static memory, are
all the same thing, it is just memory !

Again, I am not an expert on this, but I just wanted to say that Java
is allready being used in small devices (based on what I read, I 
have no personal expierence with this) , so I assume it works fine even
on small devices!

Bill.

Re: A small Ada success story

[Ehud Lamm]

> paene lacrimavi postquam bill@newsguy.com scribavit:
> 
> >Java does all that out of the box. I found Ada exception tracing to be weak
> >compared to Java more powerfull exceptions. In Java, an exception is an object,
> >that contains very usefull info that one can use.
> 

This is a fun topic to think about. I am far from sure which approach is
better. It is clear that the exception-as-object approach is by definition
more flexibale and more complicated.

I wrote a little "extra hard" question on this once, see
http://www2.cybercities.com/e/ehud/ada/extra.html and the question about
filtering exceptions.

You can achive what you want without the added functionality of Ada95!

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
 

Re: A small Ada success story

[robert_dewar]

In article
<Pine.A41.3.96-heb-2.07.990321112735.44958A-100000@pluto.ms
cc.huji.ac.il>,
  Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:
> This is a fun topic to think about. I am far from sure
> which approach is better. It is clear that the
> exception-as-object approach is by definition
> more flexibale and more complicated.

One important issue here is to have a clear idea of what
exceptions are for. I am constantly amazed to see Ada
code which very badly abuses exceptions, and uses them
essentially as an (out of) control form in a general way.
I fear that adding capability to exception handling can
further encourage such misuse.

The Burns and Welling book pretty clearly shows that you
can use Ada exceptions to cleanly model the usual error
detection and recovery paradigms, and so I am far from
convinced that it is a good idea to decorate this
particular feature of the language any further!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A small Ada success story

[Tom Moran]

>constantly amazed to see Ada
>code which very badly abuses exceptions, and uses them
>essentially as an (out of) control form in a general way.
If many people "abuse" something in the same way, what lesson should
we learn?  Is there something people want to do that is reasonable,
but the only way they can think of to do it is by "abusing" a feature
intended by the designers for something else, or are there just a lot
of ignorant people trying to use fancy features of Ada in
short-sighted ways?  
  Should we be considering changes/additions to Ada 200X, or
changes/additions to Ada textbooks?

Re: A small Ada success story

[robert_dewar]

In article <36f5511a.1615664@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> If many people "abuse" something in the same way, what
> lesson should
> we learn?  Is there something people want to do that is
> reasonable,
> but the only way they can think of to do it is by
> "abusing" a feature
> intended by the designers for something else, or are
> there just a lot
> of ignorant people trying to use fancy features of Ada in
> short-sighted ways?
>   Should we be considering changes/additions to Ada 200X,
> or changes/additions to Ada textbooks?

I don't think there is much to learn here. It is certainly
true that some people like to use fancy features for their
own sake, but in any case, an awful lot of poor code is
written in Ada, as is the case for other languages. With
regard to exceptions, Jean has sometimes wondered if we
made a mistake in having more than one exception (the other
design model is a single exception where you can query
to find out the cause of the exception). His thinking was
precisely that people tend to get too fancy with
exceptions.

The first design of posix had a separate exception for
every posix error code! Pretty amazing, but there are
people who actually thought that was good idea and a good
style!



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: A small Ada success story

[Simon Wright]

robert_dewar@my-dejanews.com writes:

> One important issue here is to have a clear idea of what
> exceptions are for. I am constantly amazed to see Ada
> code which very badly abuses exceptions, and uses them
> essentially as an (out of) control form in a general way.
> I fear that adding capability to exception handling can
> further encourage such misuse.

Perhaps this has roots in Lisp/Scheme? (letcc, try/catch/throw ..)

I suppose you "need" the technique in a language without 'return'.

Disclaimer: I'm just reading this section in "The Seasoned Schemer".

Re: A small Ada success story

[Steve Quinlan]

> T.E.D.> I sure wish more compiler vendors made this
>       > information (line number of an exception occurrence)
>       > available without using a debugger.
>
> I agree, this would be a welcome enhancement.

  This is becoming more common. OC Systems compiler has had this for years.
Not only does an unhandled exception give a symbolic traceback to stdout, but
there are interfaces to get this information in the runtime as well, so that
a program which has an exception can record (through some error reporting
service) the information about that exception needed to debug it. In domains
where your app. is running in an environment where there is no user sitting
at a terminal to see and record the screen dump, this has been very important
to use in being able to debug problems. We have an entire Error
Reporting/Recording architecture built around the ability of programs to
detect error conditions, pass data to the Error Reporting Service, and get
the data as well as symbolic tracebacks recorded for later offline analysis.

I did a compiler trade study last year to select an Ada compiler for a new
FAA Air Traffic Control project, and one criteria was that the compiler
either have or be willing to develop support for getting symbolic exception
tracebacks with line numbers at runtime. In addition, we want to be able to
get symbolic stackbacks from any arbitrary point in the code (not necessarily
in an exception scope). Aonix was already adding the exception support.
Rational was as well, but only wanted to provided non-symbolic PC values
which would have to be run through a tool to get symbolics. GNAT developed
such a feature for us.

Of course, it is true that there is no standard across vendors, but I don't
see that as too much of a problem. We've managed to encapsulate these things
in the Error Reporting service.  Whether we use OCS or GNAT specific
interfaces is hidden from the application programs that detect and record
their own errors.

         Steve Quinlan