* Re: Running Python code from GPRBuild (Calling from GNAT Studio)
@ 2022-11-11 18:12 8% ` Rego, P.
0 siblings, 0 replies; 67+ results
From: Rego, P. @ 2022-11-11 18:12 UTC (permalink / raw)
> Note that Linker does not take language e.g. ("Python") you just write:
> package Linker is
> for Driver use "pyinstaller.exe";
did that... got some more ugly messages
gprbuild -d -PP:\Gnat\testpy.gpr P:\Gnat\src\Analysis.py
Compile
[python] analysis.py
gprbuild: raised ADA.ASSERTIONS.ASSERTION_ERROR : Invalid Id 0
[C:\GNAT\2021\bin\gprbuild.exe]
0x8db0d6
0x648431
0x648671
0x4832bc
0x492553
0x49260e
0x4932d4
0x413bd5
0x948929
0x401423
0x40113b
[C:\WINDOWS\System32\KERNEL32.DLL]
0x7ffc052b7032
[C:\WINDOWS\SYSTEM32\ntdll.dll]
0x7ffc05e6269f
[2022-11-11 15:10:07] process exited with status 4, elapsed time: 04.03s
and now I oversimplified the Analysis.py to
import os
import sys
print('test')
maybe I'm pushing harder than should (trying to compile/run/whatever Python from GPS),
but still curious.
> You have to tinker a bit since there is no object files to feed the
> Linker. Maybe you could sell it *.py as an "archive" (static library).
> Whatever... (:-))
Who knows :p
^ permalink raw reply [relevance 8%]
* ANN: SweetAda 0.7 released
@ 2021-06-01 20:18 5% Gabriele Galeotti
0 siblings, 0 replies; 67+ results
From: Gabriele Galeotti @ 2021-06-01 20:18 UTC (permalink / raw)
Hi all.
I've just released SweetAda 0.7.
SweetAda is a lightweight development framework to create Ada systems on a wide range
of machines. Please refer to https://www.sweetada.org.
Downloads available @ https://sourceforge.net/projects/sweetada.
Release notes
-------------
- updated targets in master Makefile ("all" was tagged default instead of "help");
the targets "kernel_info" and "kernel_libinfo" are now exposed (kernel_libinfo
produces listings of library objects even if the kernel build is not successful)
- added implicit dependencies for console unit
- elftool will emit spaces instead of TABs when performing an ELF section dump, this
will be noted in the next toolchain release
- the linker script filename can now be declared in the platform configuration.in
by specifying "LD_SCRIPT := <linker_script_filename>", otherwise it takes a default
"linker.lds"
- the C library now implements Ada stubs for malloc/free/calloc/realloc, so C code
can call these Ada subprograms via stdlib wrappers; this has also the benefit of
resolve references to malloc() when secondary stack tries to return heavy (i.e.,
unconstrained) objects, but be sure to add "USE_LIBGCC := Y" and "USE_CLIBRARY := Y"
to the configuration.in file, either the generic one in the top-level directory,
or the platform-dependent one
- SFP RTS: a-except: Raise_Exception calls Last_Chance_Handler
- SFP RTS: added Ada.Assertions (for pragma Assert you need to turn on -gnata in
the "Ada Run-Time Checks switches" section of Makefile.tc.in)
- core/bits: added BITZERO/BITONE/BITL/BITH/BITOFF/BITON declarations
- core/console: Print (Boolean), emits "T" or "F"
- core/llutils: HexDigit_To_U8 uses a case instead of longer ifs
- modules/definitions: added a few definitions
- added various Volatile_Full_Access aspects here and there
- corrected some section wildcards in linker scripts for ARM platforms
- x86_64 lacks some low-level CPU subprograms (but thay are empty anyway) and so the
build could fail with unresolved objects, added
- new libutils/libopenocd.tcl file, useful for small OpenOCD function helpers
- Digi Connect ME (NET+ARM NS7520): some more register definitions; adopted a Tcl
script as front-end to OpenOCD
- Synergy S5D9: OpenOCD cfg file renamed to standard "openocd.cfg"
- Synergy S5D9: more register definitions, SCI almost completely parameterized
- platform Spartan3E renamed as Spartan3E-SK
- new target: Avnet Xilinx Spartan-3A Evaluation Kit (Spartan3A-EK, MicroBlaze v7.00.b),
only able to blink a LED; the programmer.tcl front-end will download the bitstream by
directly interfacing with the on-board Cypress PSoC via USB protocol (no external
tools needed in a Linux environment)
- targets involving OpenOCD (DigiConnectME, FRDM-KL46Z, HiFive1, MSP432P401R,
STM32F769I, Synergy-S5D9) now should specify in the platform configuration.in the
OpenOCD prefix (in Windows is the installation directory, i.e., that which is the
parent of bin/, etc); the default is the *nix path "/usr/local"
- in the top-level directory there are the two files .cproject and .project for Eclipse
CDT; no big deal since you have absolutely no Ada support, but if you import the
project and configure the *.adb and *.ads files as textual source files, you could
do a make build cycle, with error signalling (clicking on the error shown in console
should redirect you to the offending source line)
- typos, cosmetics and minor adjustments
Quick notes
-----------
As usual, download the three packages core, RTS and LibGCC (since many changes are
system-wide), and please save your work before overwrite the filesystem.
G
^ permalink raw reply [relevance 5%]
* Re: Lower bounds of Strings
@ 2021-01-07 0:17 6% ` Randy Brukardt
0 siblings, 0 replies; 67+ results
From: Randy Brukardt @ 2021-01-07 0:17 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:rt3uv2$1nrd$1@gioia.aioe.org...
> On 2021-01-06 04:08, Randy Brukardt wrote:
>> IMHO, "String" shouldn't be an array at all. In a UTF-8 world, it makes
>> little sense to index into a string - it would be expensive to do it
>> based
>> on characters (since they vary in size), and dangerous to do it based on
>> octets (since you could get part of a character).
>
> It will not work. There is no useful integral operations defined on
> strings. It is like arguing that image is not an array of pixels because
> you could distort objects in there when altering individual pixels.
>
>> The only real solution is to never use String in the first place. A
>> number
>> of people are building UTF-8 abstractions to replace String, and I expect
>> those to become common in the coming years.
>
> This will never happen. Ada standard library already has lots of integral
> operations defined on strings. They are practically never used. The UTF-8
> (or whatever encoding) abstraction thing simply does not exist.
>
>> Indeed, (as I've mentioned before) I would go further and abandon arrays
>> altogether -- containers cover the same ground (or could easily) -- the
>> vast
>> complication of operators popping up much after type declarations,
>> assignable slices, and supernull arrays all waste resources and cause
>> oddities and dangers. It's a waste of time to fix arrays in Ada -- just
>> don't use them.
>
> How these containers are supposed to be implemented?
Built-in to the implementation, of course. Implementing these things in Ada
is a nice capability, because that allows simple quick-and-dirty
implementations. But for things that are commonly used, that necessarily
leads to lousy performance. One has to have at least some special cases even
for the Ada.Containers to get adequate performance, so there's no problem
extending that.
...
> How Stream_Element_Array is supposed to be an opaque container?
It should already be an opaque container. You use language-defined stream
attributes to implement user-defined stream attributes - not unportable
direct byte twiddling.
> How file read operation is supposed to assign part of a container?
??? Why would you want to do that? Streaming a bounded vector (which almost
all existing arrays should be) naturally would read only the active part of
the vector. Non-streaming reading is left over Ada 83 nonsense; all I/O
should be built on top of streams (as a practical matter, the vast majority
is anyway).
> You cannot rid of array interface with all its types involved: index,
> index set (range), element, element set (array). A containers without the
> array interface cannot replace array. Any language must support them. The
> problem is that Ada has array interfaces once built-in and as an ugly lame
> monstrosity of helper tagged types, a mockery of array.
There no reason that a container interface cannot have those things --
Ada.Containers.Vectors does. The things that Vectors is missing (mainly the
ability to use enumeration and modular indexes) was a mistake that I
complained about repeatedly during the design, but I lost on that.
> Array implementation is a fundamental building block of computing.
Surely. But one does not need the nonsense of requiring an underlying
implementation (which traditional arrays do) in order to get that building
block. You always talk about this in terms of an "interface", which is
essentially the same idea. One cannot have any sort of non-contigious or
persistent arrays with the Ada interface, since operations like assigning
into slices are impossible in such representations. One has to give those
things up in order to have an "interface" rather than the concrete form for
Ada arrays.
I prefer to not call the result an array, since an array implies a
contiguous in-memory representation. Of course, some vectors will have such
a representation, but that needs to be a requirement only for vectors used
for interfacing. (And those should be used rarely.)
> That does not go either. Of course you could have two languages, one with
> arrays to implement containers and one without them for end users. But
> this is neither Ada philosophy nor a concept for any good
> universal-purpose language.
Compilers implement arrays in Ada; there is no possibility a user doing it.
I see no difference between that and having the compiler implement a bounded
vector instead as the fundamental building block. You seem fixated on the
form of declaration (that is a generic package vs. some sort of built-in
syntax) -- there's no fundamental difference. There are many Ada packages
that are built-in to compilers (for Janus/Ada, these include System and
Ada.Exceptions and Ada.Assertions) -- there's no body or even source of
these to be seen.
We're not even talking about different syntax for the use of vectors (and it
would be easy to have some syntax sugar for declarations - we already have a
proposal on those lines for Ada). Indeed, in a new language, one would
certainly call these "array" containers (couldn't do that in Ada as the word
"array" is reserved).
Sometimes, one has to step back and look at the bigger picture and not
always at the way things have always been done. Arrays (at least as defined
in Ada) have outlived their usefulness.
Randy.
^ permalink raw reply [relevance 6%]
* Re: GNAT CE 2019 bug: Predicate check not performed
2020-04-19 22:31 0% ` Anh Vo
@ 2020-04-19 22:32 0% ` Anh Vo
0 siblings, 0 replies; 67+ results
From: Anh Vo @ 2020-04-19 22:32 UTC (permalink / raw)
On Sunday, April 19, 2020 at 3:31:15 PM UTC-7, Anh Vo wrote:
> On Sunday, April 19, 2020 at 2:28:18 AM UTC-7, AdaMagica wrote:
> > The problem is with GNAT CE 2019.
> > GNAT CE 2018 was correct.
> > ------------------------------------------------
> > with Ada.Text_IO;
> > use Ada.Text_IO;
> > with Ada.Assertions;
> > use Ada.Assertions;
> >
> > procedure Ass is
> >
> > pragma Assertion_Policy (Check);
> >
> > subtype String_5 is String with Dynamic_Predicate => String_5'First = 5;
> >
> > procedure P (X: String_5) is
> > begin
> > Put_Line ("P expects 5:" & X'First'Image);
> > end P;
> >
> > procedure Q (X: String) is
> > begin
> > P (X); -- Why no predicate check here?
> > end Q;
> >
> > S: constant String := "Lady Ada";
> >
> > begin
> >
> > begin
> > Q (S); -- prints 1, expected Assertion_Error
> > Put_Line ("Problem Q: Assertion_Error not raised.");
> > exception
> > when Assertion_Error => Put_Line ("Q: Assertion_Error raised as expected.");
> > end;
> >
> > begin
> > P (S); -- Assertion_Error raised here
> > Put_Line ("Problem P: Assertion_Error not raised.");
> > exception
> > when Assertion_Error => Put_Line ("P: Assertion_Error raised as expected.");
> > end;
> >
> > end Ass;
> > ---------------------
> > Result GNAT CE 2018
> > C:\Users\Grein\Documents\Christoph\Ada\Spielplatz\ausprobieren.exe
> > Q: Assertion_Error raised as expected.
> > P: Assertion_Error raised as expected.
> > [2020-04-18 19:33:34] process terminated successfully, elapsed time: 07.47s
> > Result GNAT CE 2019
> > C:\Users\Grein\Documents\Christoph\Ada\Spielplatz\ausprobieren.exe
> > P expects 5: 1
> > Problem Q: Assertion_Error not raised.
> > P: Assertion_Error raised as expected.
> > [2020-04-18 19:58:20] process terminated successfully, elapsed time: 04.25s
>
> It takes time to look thru the LRM to if this behavior is expected or not. However if String_5 is changed to type and lines 19 and 34 are adjusted for compilation, then it behaves as in GNAT CE 2018. By the way, GNAT Community 2019 on Windows 10 is for this check.
It takes time to look thru the LRM to see if...
^ permalink raw reply [relevance 0%]
* Re: GNAT CE 2019 bug: Predicate check not performed
2020-04-19 9:28 11% GNAT CE 2019 bug: Predicate check not performed AdaMagica
@ 2020-04-19 22:31 0% ` Anh Vo
2020-04-19 22:32 0% ` Anh Vo
0 siblings, 1 reply; 67+ results
From: Anh Vo @ 2020-04-19 22:31 UTC (permalink / raw)
On Sunday, April 19, 2020 at 2:28:18 AM UTC-7, AdaMagica wrote:
> The problem is with GNAT CE 2019.
> GNAT CE 2018 was correct.
> ------------------------------------------------
> with Ada.Text_IO;
> use Ada.Text_IO;
> with Ada.Assertions;
> use Ada.Assertions;
>
> procedure Ass is
>
> pragma Assertion_Policy (Check);
>
> subtype String_5 is String with Dynamic_Predicate => String_5'First = 5;
>
> procedure P (X: String_5) is
> begin
> Put_Line ("P expects 5:" & X'First'Image);
> end P;
>
> procedure Q (X: String) is
> begin
> P (X); -- Why no predicate check here?
> end Q;
>
> S: constant String := "Lady Ada";
>
> begin
>
> begin
> Q (S); -- prints 1, expected Assertion_Error
> Put_Line ("Problem Q: Assertion_Error not raised.");
> exception
> when Assertion_Error => Put_Line ("Q: Assertion_Error raised as expected.");
> end;
>
> begin
> P (S); -- Assertion_Error raised here
> Put_Line ("Problem P: Assertion_Error not raised.");
> exception
> when Assertion_Error => Put_Line ("P: Assertion_Error raised as expected.");
> end;
>
> end Ass;
> ---------------------
> Result GNAT CE 2018
> C:\Users\Grein\Documents\Christoph\Ada\Spielplatz\ausprobieren.exe
> Q: Assertion_Error raised as expected.
> P: Assertion_Error raised as expected.
> [2020-04-18 19:33:34] process terminated successfully, elapsed time: 07.47s
> Result GNAT CE 2019
> C:\Users\Grein\Documents\Christoph\Ada\Spielplatz\ausprobieren.exe
> P expects 5: 1
> Problem Q: Assertion_Error not raised.
> P: Assertion_Error raised as expected.
> [2020-04-18 19:58:20] process terminated successfully, elapsed time: 04.25s
It takes time to look thru the LRM to if this behavior is expected or not. However if String_5 is changed to type and lines 19 and 34 are adjusted for compilation, then it behaves as in GNAT CE 2018. By the way, GNAT Community 2019 on Windows 10 is for this check.
^ permalink raw reply [relevance 0%]
* GNAT CE 2019 bug: Predicate check not performed
@ 2020-04-19 9:28 11% AdaMagica
2020-04-19 22:31 0% ` Anh Vo
0 siblings, 1 reply; 67+ results
From: AdaMagica @ 2020-04-19 9:28 UTC (permalink / raw)
The problem is with GNAT CE 2019.
GNAT CE 2018 was correct.
------------------------------------------------
with Ada.Text_IO;
use Ada.Text_IO;
with Ada.Assertions;
use Ada.Assertions;
procedure Ass is
pragma Assertion_Policy (Check);
subtype String_5 is String with Dynamic_Predicate => String_5'First = 5;
procedure P (X: String_5) is
begin
Put_Line ("P expects 5:" & X'First'Image);
end P;
procedure Q (X: String) is
begin
P (X); -- Why no predicate check here?
end Q;
S: constant String := "Lady Ada";
begin
begin
Q (S); -- prints 1, expected Assertion_Error
Put_Line ("Problem Q: Assertion_Error not raised.");
exception
when Assertion_Error => Put_Line ("Q: Assertion_Error raised as expected.");
end;
begin
P (S); -- Assertion_Error raised here
Put_Line ("Problem P: Assertion_Error not raised.");
exception
when Assertion_Error => Put_Line ("P: Assertion_Error raised as expected.");
end;
end Ass;
---------------------
Result GNAT CE 2018
C:\Users\Grein\Documents\Christoph\Ada\Spielplatz\ausprobieren.exe
Q: Assertion_Error raised as expected.
P: Assertion_Error raised as expected.
[2020-04-18 19:33:34] process terminated successfully, elapsed time: 07.47s
Result GNAT CE 2019
C:\Users\Grein\Documents\Christoph\Ada\Spielplatz\ausprobieren.exe
P expects 5: 1
Problem Q: Assertion_Error not raised.
P: Assertion_Error raised as expected.
[2020-04-18 19:58:20] process terminated successfully, elapsed time: 04.25s
^ permalink raw reply [relevance 11%]
* Re: GNAT bug with assertions
2018-08-10 10:29 11% GNAT bug with assertions AdaMagica
@ 2018-08-10 14:23 0% ` Anh Vo
0 siblings, 0 replies; 67+ results
From: Anh Vo @ 2018-08-10 14:23 UTC (permalink / raw)
On Friday, August 10, 2018 at 3:29:34 AM UTC-7, AdaMagica wrote:
> I would have expected that predicates are also checked on return values as they are checked on parameters.
> In the following test, no exception is raised on call of funcction Wrong although it returns a value not fulfilling the predicate.
>
> Is this a GNAT bug or my wrong expectation?
>
> package Pack is
>
> type Priv is private;
> C: constant Priv;
>
> function Test (X: Priv) return Boolean;
> subtype Subt is Priv with Dynamic_Predicate => (Test (Subt));
>
> function Wrong return Subt;
> function Good (X: Subt) return Boolean;
>
> private
>
> type Priv is new Integer;
> C: constant Priv := -1;
>
> function Test (X: Priv) return Boolean is (X > 0);
>
> function Wrong return Subt is (-1);
> function Good (X: Subt) return Boolean is (True);
>
> end Pack;
>
> with Ada.Assertions, Ada.Text_IO;
> use Ada.Assertions, Ada.Text_IO;
>
> with Pack;
> use Pack;
>
> procedure Test_Pack is
> begin
>
> begin
> Put_Line (Good (C)'Image);
> exception
> when Assertion_Error =>
> Put_Line ("Good (C) raises Assertion_Error => OK");
> end;
>
> declare
> X: Priv;
> begin
> X := Wrong;
> Put_Line ("Assertion_Error expected by calling Wrong => KO");
> exception
> when Assertion_Error =>
> Put_Line ("Wrong raises Assertion_Error => OK");
> end;
>
> end Test_Pack;
I assume you used -gnata switch for your GNAT compilation. Otherwise, you will not see the effect.
Anh Vo
^ permalink raw reply [relevance 0%]
* GNAT bug with assertions
@ 2018-08-10 10:29 11% AdaMagica
2018-08-10 14:23 0% ` Anh Vo
0 siblings, 1 reply; 67+ results
From: AdaMagica @ 2018-08-10 10:29 UTC (permalink / raw)
I would have expected that predicates are also checked on return values as they are checked on parameters.
In the following test, no exception is raised on call of funcction Wrong although it returns a value not fulfilling the predicate.
Is this a GNAT bug or my wrong expectation?
package Pack is
type Priv is private;
C: constant Priv;
function Test (X: Priv) return Boolean;
subtype Subt is Priv with Dynamic_Predicate => (Test (Subt));
function Wrong return Subt;
function Good (X: Subt) return Boolean;
private
type Priv is new Integer;
C: constant Priv := -1;
function Test (X: Priv) return Boolean is (X > 0);
function Wrong return Subt is (-1);
function Good (X: Subt) return Boolean is (True);
end Pack;
with Ada.Assertions, Ada.Text_IO;
use Ada.Assertions, Ada.Text_IO;
with Pack;
use Pack;
procedure Test_Pack is
begin
begin
Put_Line (Good (C)'Image);
exception
when Assertion_Error =>
Put_Line ("Good (C) raises Assertion_Error => OK");
end;
declare
X: Priv;
begin
X := Wrong;
Put_Line ("Assertion_Error expected by calling Wrong => KO");
exception
when Assertion_Error =>
Put_Line ("Wrong raises Assertion_Error => OK");
end;
end Test_Pack;
^ permalink raw reply [relevance 11%]
* Re: Community Input for the Maintenance and Revision of the Ada Programming Language
2017-09-06 15:02 0% ` Johan Söderlind Åström
@ 2017-09-06 21:21 0% ` Randy Brukardt
0 siblings, 0 replies; 67+ results
From: Randy Brukardt @ 2017-09-06 21:21 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3984 bytes --]
"Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message
news:e9e2556d-9b23-4e7f-9058-776dd506f73c@googlegroups.com...
>On Sunday, September 3, 2017 at 3:30:23 AM UTC+2, Randy Brukardt wrote:
>> "Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message
>> news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
>> ...
>> >procedure Algorithm (Item : Integer_Array) is
>> > use Ada.Assertions;
>> > X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
>>
>> The use of address clauses other than for interfacing is evil (and not
>> guaranteed to work in the case of overlaying Ada code). Don't do that.
>>
>> You can change the bounds of an array with a type conversion to a
>> constrained subtype, which is likely to be cheaper and not break if you
>> change compilers.
>What do you mean with cheaper? Faster execution?, Less memory footprint?
Both. The address clause adds an extra level of indirection that the type
conversion doesn't necessarily add. (In Janus/Ada, the conversion would
remove or replace the bounds descriptor, making the access cost identically
to the original array accesses; an address clause always adds a level of
indirection.) But I forgot about the cost to copy the array (usually
insignificant, but not always).
>Which compiler will break my code?
Any compiler could; 13.3(16) says that it only required for 'Address to have
a "useful result" if the prefix is aliased or by-reference (neither which is
true for the parameter Item of type Integer_Array). Ergo, such a usage is
not portable (even if many compilers allow it). Dunno if it will actually
break in any implementation, but it is best to avoid these sorts of
non-portable things.
As discussed,
procedure Algorithm (Item : Integer_Array) is
subtype Zero_Array is Integer_Array (0 .. Item'Length - 1);
X : constant Zero_Array := Zero_Array (Item);
has the same effect (modulo probably making an extra copy of the data), is
always going to work (assuming Item'Length is short enough to fit in the
index subtype - the point of Stephen Leake), doesn't need any assertions,
and is much easier to read.
>I do not know how Ada accesses a array element internally. But a zero
>indexed array must be cheaper than a custom indexed array, see:
>
>Accessing nth element from zero indexed array:
>(base_address + index*element_size).
>
>Accessing nth element from a custom indexed array:
>(base_address + (index - first)*element_size)
In most cases, that is not an issue. Whenever Item'First is static (that is
known to the compiler), the compiler will fold it into the base address so
the cost is the same. (And there is a cost to rebasing the array, no matter
how you do it.)
Specifically, the general form:
(base_address + (index - first)*element_size)
is the same as:
(base_address - (first*element_size) + (index*element_size))
In the usual case, when both first and element_size are known to the
compiler, the code generation will be
((base_address - (first*element_size)) + (index*element_size))
with the first part calculated by the compiler and generated as a single
item. The only runtime operations are the + and second *, just as in the
zero-based form.
Moral: Compilers can eliminate most of the supposedly extra costs; it pays
only to worry about those that are known (via experiment) to be significant
in the runtime of a program. (The 90-10 rule says that the performance of
90% of the code has no effect on the result.)
Moral2: Premature optimization is the root of much evil. Only worry about
the performance of code that is demonstrably too slow. Otherwise,
readability and maintainability are the most important goals after
correctness. YMMV.
Randy.
I do not think that accessing a element from a array is a complicated thing
and starting from a zero indexed array is even simpler, then why would a
compiler not guarantee such a simple thing to work?
^ permalink raw reply [relevance 0%]
* Re: Community Input for the Maintenance and Revision of the Ada Programming Language
2017-09-03 1:30 0% ` Randy Brukardt
@ 2017-09-06 15:02 0% ` Johan Söderlind Åström
2017-09-06 21:21 0% ` Randy Brukardt
0 siblings, 1 reply; 67+ results
From: Johan Söderlind Åström @ 2017-09-06 15:02 UTC (permalink / raw)
On Sunday, September 3, 2017 at 3:30:23 AM UTC+2, Randy Brukardt wrote:
> "Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message
> news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
> ...
> >procedure Algorithm (Item : Integer_Array) is
> > use Ada.Assertions;
> > X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
>
> The use of address clauses other than for interfacing is evil (and not
> guaranteed to work in the case of overlaying Ada code). Don't do that.
>
> You can change the bounds of an array with a type conversion to a
> constrained subtype, which is likely to be cheaper and not break if you
> change compilers.
>
> Randy.
What do you mean with cheaper? Faster execution?, Less memory footprint?
Which compiler will break my code?
I do not know how Ada accesses a array element internally. But a zero indexed array must be cheaper than a custom indexed array, see:
Accessing nth element from zero indexed array:
(base_address + index*element_size).
Accessing nth element from a custom indexed array:
(base_address + (index - first)*element_size)
I do not think that accessing a element from a array is a complicated thing and starting from a zero indexed array is even simpler, then why would a compiler not guarantee such a simple thing to work?
^ permalink raw reply [relevance 0%]
* Re: Community Input for the Maintenance and Revision of the Ada Programming Language
2017-09-02 17:19 0% ` Jeffrey R. Carter
@ 2017-09-04 20:52 0% ` Johan Söderlind Åström
0 siblings, 0 replies; 67+ results
From: Johan Söderlind Åström @ 2017-09-04 20:52 UTC (permalink / raw)
On Saturday, September 2, 2017 at 7:19:47 PM UTC+2, Jeffrey R. Carter wrote:
> On 09/02/2017 01:21 PM, Johan Söderlind Åström wrote:
> >
> > type Integer_Array is array (Integer range <>) of Integer;
> >
> > procedure Algorithm (Item : Integer_Array) is
> > use Ada.Assertions;
> > X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
> > begin
> > for I in 0 .. Item'Length - 1 loop
> > Assert (X (I) = Item (Item'First + I));
> > end loop;
> > end Algorithm;
>
> type Ptr is access Integer_Array;
>
> P : Ptr := new Integer_Array (-1 .. Integer'Last);
>
> Algorithm (P.all);
>
> --
> Jeff Carter
> It's better to be root than to reboot.
> 119
I tried to run that but it raises STORAGE_ERROR : "object is too large" at line P : Ptr.
^ permalink raw reply [relevance 0%]
* Re: Community Input for the Maintenance and Revision of the Ada Programming Language
2017-09-03 1:35 0% ` Randy Brukardt
@ 2017-09-03 10:32 0% ` Alejandro R. Mosteo
0 siblings, 0 replies; 67+ results
From: Alejandro R. Mosteo @ 2017-09-03 10:32 UTC (permalink / raw)
On 03/09/17 03:35, Randy Brukardt wrote:
> "Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message
> news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
>> I usually cast a array to array that starts at zero index when implementing
>> algorithms.
> OK, but just do that and don't use any overlays...
>
>> type Integer_Array is array (Integer range <>) of Integer;
>>
>> procedure Algorithm (Item : Integer_Array) is
>> use Ada.Assertions;
>> X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
>
> subtype Zero_Array is Integer_Array (0 .. Item'Length - 1);
> X : Zero_Array := Zero_Array (Item);
Wouldn't that possibly involve a copy? If so, would using "constant"
guarantee a free renaming?
And is there a difference to using rename?:
X : Zero_Array renames Item;
(I was actually surprised that you can't explicitly write
Zero_Array(Item) with renames).
Álex.
> ...
>
> Randy.
>
>
^ permalink raw reply [relevance 0%]
* Re: Community Input for the Maintenance and Revision of the Ada Programming Language
2017-09-02 11:21 9% ` Johan Söderlind Åström
` (2 preceding siblings ...)
2017-09-03 1:30 0% ` Randy Brukardt
@ 2017-09-03 1:35 0% ` Randy Brukardt
2017-09-03 10:32 0% ` Alejandro R. Mosteo
3 siblings, 1 reply; 67+ results
From: Randy Brukardt @ 2017-09-03 1:35 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
"Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message
news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
>I usually cast a array to array that starts at zero index when implementing
>algorithms.
OK, but just do that and don't use any overlays...
>type Integer_Array is array (Integer range <>) of Integer;
>
>procedure Algorithm (Item : Integer_Array) is
> use Ada.Assertions;
> X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
subtype Zero_Array is Integer_Array (0 .. Item'Length - 1);
X : Zero_Array := Zero_Array (Item);
...
Randy.
^ permalink raw reply [relevance 0%]
* Re: Community Input for the Maintenance and Revision of the Ada Programming Language
2017-09-02 11:21 9% ` Johan Söderlind Åström
2017-09-02 15:22 0% ` Vincent DIEMUNSCH
2017-09-02 17:19 0% ` Jeffrey R. Carter
@ 2017-09-03 1:30 0% ` Randy Brukardt
2017-09-06 15:02 0% ` Johan Söderlind Åström
2017-09-03 1:35 0% ` Randy Brukardt
3 siblings, 1 reply; 67+ results
From: Randy Brukardt @ 2017-09-03 1:30 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
"Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message
news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
...
>procedure Algorithm (Item : Integer_Array) is
> use Ada.Assertions;
> X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
The use of address clauses other than for interfacing is evil (and not
guaranteed to work in the case of overlaying Ada code). Don't do that.
You can change the bounds of an array with a type conversion to a
constrained subtype, which is likely to be cheaper and not break if you
change compilers.
Randy.
^ permalink raw reply [relevance 0%]
* Re: Community Input for the Maintenance and Revision of the Ada Programming Language
2017-09-02 11:21 9% ` Johan Söderlind Åström
2017-09-02 15:22 0% ` Vincent DIEMUNSCH
@ 2017-09-02 17:19 0% ` Jeffrey R. Carter
2017-09-04 20:52 0% ` Johan Söderlind Åström
2017-09-03 1:30 0% ` Randy Brukardt
2017-09-03 1:35 0% ` Randy Brukardt
3 siblings, 1 reply; 67+ results
From: Jeffrey R. Carter @ 2017-09-02 17:19 UTC (permalink / raw)
On 09/02/2017 01:21 PM, Johan Söderlind Åström wrote:
>
> type Integer_Array is array (Integer range <>) of Integer;
>
> procedure Algorithm (Item : Integer_Array) is
> use Ada.Assertions;
> X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
> begin
> for I in 0 .. Item'Length - 1 loop
> Assert (X (I) = Item (Item'First + I));
> end loop;
> end Algorithm;
type Ptr is access Integer_Array;
P : Ptr := new Integer_Array (-1 .. Integer'Last);
Algorithm (P.all);
--
Jeff Carter
It's better to be root than to reboot.
119
^ permalink raw reply [relevance 0%]
* Re: Community Input for the Maintenance and Revision of the Ada Programming Language
2017-09-02 11:21 9% ` Johan Söderlind Åström
@ 2017-09-02 15:22 0% ` Vincent DIEMUNSCH
2017-09-02 17:19 0% ` Jeffrey R. Carter
` (2 subsequent siblings)
3 siblings, 0 replies; 67+ results
From: Vincent DIEMUNSCH @ 2017-09-02 15:22 UTC (permalink / raw)
Le samedi 2 septembre 2017 13:21:28 UTC+2, Johan Söderlind Åström a écrit :
> I usually cast a array to array that starts at zero index when implementing algorithms.
>
> type Integer_Array is array (Integer range <>) of Integer;
>
> procedure Algorithm (Item : Integer_Array) is
> use Ada.Assertions;
> X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
Very clever ! That nice hack shows that some of us have that same concern !
Regards,
Vincent
^ permalink raw reply [relevance 0%]
* Re: Community Input for the Maintenance and Revision of the Ada Programming Language
@ 2017-09-02 11:21 9% ` Johan Söderlind Åström
2017-09-02 15:22 0% ` Vincent DIEMUNSCH
` (3 more replies)
0 siblings, 4 replies; 67+ results
From: Johan Söderlind Åström @ 2017-09-02 11:21 UTC (permalink / raw)
> 2. Allow a special indexing syntax, that I called relative indexing. Adding a Unary + operator (that has no other purpose ! :-) ) in front of an index expression means starting from A'First. Unary plus would then become the ordinal operator.
>
> A(+i) simply means A(A'First +i).
>
> This is an elegant and above all retro-compatible way of permitting to start every array at zero which is easier in algorithms, cf. Dijkstra (EWD 831 "Why numbering should start at zero") or Wirth's Oberon. Using A'Range is not possible outside the basic cases. Anytime you want to compute indexes you fall on relative indexes from 0 to N-1 and convoluted expressions that add or suppress A'First.
I usually cast a array to array that starts at zero index when implementing algorithms.
type Integer_Array is array (Integer range <>) of Integer;
procedure Algorithm (Item : Integer_Array) is
use Ada.Assertions;
X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
begin
for I in 0 .. Item'Length - 1 loop
Assert (X (I) = Item (Item'First + I));
end loop;
end Algorithm;
^ permalink raw reply [relevance 9%]
* Re: win32 interfacing check (SetClipboardData)
2017-08-30 21:17 0% ` Dmitry A. Kazakov
@ 2017-09-01 12:51 0% ` Xavier Petit
0 siblings, 0 replies; 67+ results
From: Xavier Petit @ 2017-09-01 12:51 UTC (permalink / raw)
Le 30/08/2017 à 23:17, Dmitry A. Kazakov a écrit :
> On 2017-08-30 20:41, Xavier Petit wrote:
>> Thank you but I always get the error ERROR_INVALID_PARAMETER from
>> GetLastError, using it like this :
>>
>> UTF16_Code_Page : constant := 1200;
>>
>> Length := MultiByteToWideChar (CodePage => UTF16_Code_Page,
>> DwFlags => MB_PRECOMPOSED,
>> LpMultiByteStr => Addr (Source),
>> CchMultiByte => -1,
>> LpWideCharStr => Encoded,
>> CchWideChar => 0);
>
> The output must be null when its length is. And it looks like
> MB_PRECOMPOSED does not work. So (without error handling):
and I was using the wrong code page (UTF-16 instead of UTF-8).
On why MB_PRECOMPOSED does not work (from MSDN MultiByteToWideChar) :
“Note For *UTF-8* or code page 54936 (GB18030, starting with Windows
Vista), dwFlags must be set to either 0 or MB_ERR_INVALID_CHARS.
Otherwise, the function fails with ERROR_INVALID_FLAGS.”
> --
> -- UTF-8 to UTF-16 conversion using MultiByteToWideChar
> --
Perfectly works, thank you very much, I can now get rid of -gnatW8 &
Wide_Wide_String.
>>> Why should it need gnatW8 or gnata? You get characters by encoding
>>> them, I suppose.
>> I use gnata to trigger Ada.Assertions errors, I could use the pragma
>> Assertion_Policy (Check) too.
>> I have tested the following Wide_String : "123〠" with or without
>> -gnatW8.
>> It only worked with, but thanks to you I know that my procedure was
>> wrong anyway.
>
> I see. IMO, it is a bad idea to use non-ASCII characters in the source.
> When I need a special character I take its UNICODE code position and
> convert that to String.
Thanks but even with Set_Clipboard (Ada.[Wide_]Wide_Text_IO.Get_Line); I
was getting weird clipboard text without -gnatW8 flag.
^ permalink raw reply [relevance 0%]
* Re: win32 interfacing check (SetClipboardData)
2017-08-30 18:41 8% ` Xavier Petit
@ 2017-08-30 21:17 0% ` Dmitry A. Kazakov
2017-09-01 12:51 0% ` Xavier Petit
0 siblings, 1 reply; 67+ results
From: Dmitry A. Kazakov @ 2017-08-30 21:17 UTC (permalink / raw)
On 2017-08-30 20:41, Xavier Petit wrote:
> Le 30/08/2017 à 18:04, Dmitry A. Kazakov a écrit :
>> It looks OK. Except that formally Wide_String is UCS-2 and Windows is
>> UTF-16.
> Thank you for pointing that out.
>
>> I would use UTF-8 encoded string as the input and recode it into
>> UTF-16 to have CF_UNICODETEXT, e.g. by using MultiByteToWideChar.
> Thank you but I always get the error ERROR_INVALID_PARAMETER from
> GetLastError, using it like this :
>
> UTF16_Code_Page : constant := 1200;
>
> Length := MultiByteToWideChar (CodePage => UTF16_Code_Page,
> DwFlags => MB_PRECOMPOSED,
> LpMultiByteStr => Addr (Source),
> CchMultiByte => -1,
> LpWideCharStr => Encoded,
> CchWideChar => 0);
The output must be null when its length is. And it looks like
MB_PRECOMPOSED does not work. So (without error handling):
--
-- UTF-8 to UTF-16 conversion using MultiByteToWideChar
--
function Convert (Text : String) return Wide_String is
use type Win32.INT;
Length : Win32.INT;
begin
Length := MultiByteToWideChar -- Determine length
( CodePage => CP_UTF8,
DwFlags => 0,
LpMultiByteStr => Addr (Text),
CchMultiByte => -1,
LpWideCharStr => null,
CchWideChar => 0
);
declare
Result : Wide_String (1..Integer (Length));
begin
Length := MultiByteToWideChar -- Do conversion
( CodePage => CP_UTF8,
DwFlags => 0,
LpMultiByteStr => Addr (Text),
CchMultiByte => -1,
LpWideCharStr => Addr (Result),
CchWideChar => Length
);
Put_Line (Win32.INT'Image (Length));
return Result;
end;
end Convert;
And Text must end with Character'Val (0). Of course you can do
GlobalAlloc for the second call instead of returning Ada string.
>> Why should it need gnatW8 or gnata? You get characters by encoding
>> them, I suppose.
> I use gnata to trigger Ada.Assertions errors, I could use the pragma
> Assertion_Policy (Check) too.
> I have tested the following Wide_String : "123〠" with or without -gnatW8.
> It only worked with, but thanks to you I know that my procedure was
> wrong anyway.
I see. IMO, it is a bad idea to use non-ASCII characters in the source.
When I need a special character I take its UNICODE code position and
convert that to String.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: win32 interfacing check (SetClipboardData)
@ 2017-08-30 18:41 8% ` Xavier Petit
2017-08-30 21:17 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 67+ results
From: Xavier Petit @ 2017-08-30 18:41 UTC (permalink / raw)
Le 30/08/2017 à 18:04, Dmitry A. Kazakov a écrit :
> It looks OK. Except that formally Wide_String is UCS-2 and Windows is
> UTF-16.
Thank you for pointing that out.
> I would use UTF-8 encoded string as the input and recode it into UTF-16
> to have CF_UNICODETEXT, e.g. by using MultiByteToWideChar.
Thank you but I always get the error ERROR_INVALID_PARAMETER from
GetLastError, using it like this :
UTF16_Code_Page : constant := 1200;
Length := MultiByteToWideChar (CodePage => UTF16_Code_Page,
DwFlags => MB_PRECOMPOSED,
LpMultiByteStr => Addr (Source),
CchMultiByte => -1,
LpWideCharStr => Encoded,
CchWideChar => 0);
> Why should it need gnatW8 or gnata? You get characters by encoding them,
> I suppose.
I use gnata to trigger Ada.Assertions errors, I could use the pragma
Assertion_Policy (Check) too.
I have tested the following Wide_String : "123〠" with or without -gnatW8.
It only worked with, but thanks to you I know that my procedure was
wrong anyway.
If I call this procedure with Source => "𐐷𤭢" and -gnatW8 I get the
error “literal out of range of type Standard.Wide_Character”.
Without the flag, the code compiles but the clipboard has a weird text.
So I have a working version of the code :
https://pastebin.com/raw/5ss5m5QY
...but using Wide_Wide_String/UCS-2/UTF32 as input *and* -gnatW8 flag.
So not at all like your idea (UTF-8 String and no special flag).
Thank you very much for your help
^ permalink raw reply [relevance 8%]
* Re: Dynamic_Predicate failure -> Assertion_Error?
2014-05-13 11:22 10% Dynamic_Predicate failure -> Assertion_Error? Jacob Sparre Andersen
@ 2014-05-13 21:26 10% ` Randy Brukardt
0 siblings, 0 replies; 67+ results
From: Randy Brukardt @ 2014-05-13 21:26 UTC (permalink / raw)
"Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message
news:87tx8tncss.fsf@adaheads.sparre-andersen.dk...
>I am experimenting a bit with GNAT-GPL-2013 and some of the new features
> in Ada 2012.
>
> % cat primes.ads
> package Primes is
> subtype Prime is Integer range 2 .. Integer'Last
> with Dynamic_Predicate
> => (for all N in 2 .. Prime - 1 => Prime mod N /= 0);
> end Primes;
> % cat test_primes.adb
> with Ada.Assertions,
> Ada.Text_IO;
> with Primes;
>
> procedure Test_Primes is
> use Primes;
> P : Prime;
> begin
> for I in 1 .. 25 loop
> begin
> P := I;
> Ada.Text_IO.Put_Line (Prime'Image (P) & " is a prime.");
> exception
> when Constraint_Error =>
> Ada.Text_IO.Put_Line (Integer'Image (I) &
> " is not a prime (constraint).");
> when Ada.Assertions.Assertion_Error =>
> Ada.Text_IO.Put_Line (Integer'Image (I) &
> " is not a prime (predicate).");
> end;
> end loop;
> end Test_Primes;
> % gnatmake -gnat12 -gnata -gnato -fstack-check test_primes
> gcc -c -gnat12 -gnata -gnato -fstack-check test_primes.adb
> gcc -c -gnat12 -gnata -gnato -fstack-check primes.ads
> gnatbind -x test_primes.ali
> gnatlink test_primes.ali -fstack-check
> % ./test_primes
> 1 is not a prime (constraint).
> 2 is a prime.
> 3 is a prime.
> 4 is not a prime (constraint).
> [...]
>
> As I read 3.2.4(31/3) the raised exception for 4 should be
> Assertion_Error and not Constraint_Error. Is this correct?
No, but the reason is subtle. (I fooled around with your test program for a
while before I figured out the problem.)
And on top of that, there is some weird behavior.
If one removes the 1 from the loop (so it starts at 2), then I get:
2 is a prime.
3 is a prime.
4 is a prime.
5 is a prime.
6 is a prime.
...
11.4.2(10.4/3) says that "if no such Assertion_Policy pragma exists, the
policy is implementation-defined". That means, that if you want to ensure
assertions to be checked (in an ACATS test or in your code), you need a
pragma Assertion_Policy(Check) somewhere. GNAT seems to default to Ignore or
something similar; definitely not full Check.
If you put that pragma into Test_Prime:
with Ada.Assertions, Ada.Text_IO;
with Primes;
procedure TestP is
pragma Assertion_Policy(Check); -- <<---!!!!
use Primes;
P : Prime;
...
Then I get the following if the loop starts at 2:
2 is a prime.
3 is a prime.
4 is not a prime (predicate).
5 is a prime.
6 is not a prime (predicate).
7 is a prime.
...
But if the loop starts at 1, I get your original result.
Your guess is as good as mine as to why that would be. It's obviously some
sort of weird compiler bug. It seems to be keeping the first exception
raised through the loop and reusing it on subsequent iterations, rather that
treating each separately as one would hope.
> If I am correct, is there any likelihood that I could get a test for
> this into ACATS (assuming that I can figure out how to formulate it
> properly)?
Well, as this is a weird compiler bug and not an outright mistake in the
implementation (since it depends solely on the bounds of the loop - it works
properly when no loop is involved), it's not a good candidate for the ACATS.
Especially as it seems to be more likely an exception processing problem
rather than an assertion problem.
Moreover, AI12-0054-2 and AI12-0071-1 extensively changed the rules in this
area (they were much too loose for practical usability). There will need to
be tests for those AIs, but they have to wait until AI12-0071-1 is approved
by WG 9 (expected in June).
That said, we'd love to have more tests for Ada 2012's contract assertions.
A variety of programming styles helps the quality of the ACATS. Contact me
at agent@ada-auth.org if you need more information, or see Annex E in the
ACATS documentation (http://www.ada-auth.org/acats-files/3.1/docs/UG-E.HTM).
Randy.
^ permalink raw reply [relevance 10%]
* Dynamic_Predicate failure -> Assertion_Error?
@ 2014-05-13 11:22 10% Jacob Sparre Andersen
2014-05-13 21:26 10% ` Randy Brukardt
0 siblings, 1 reply; 67+ results
From: Jacob Sparre Andersen @ 2014-05-13 11:22 UTC (permalink / raw)
I am experimenting a bit with GNAT-GPL-2013 and some of the new features
in Ada 2012.
% cat primes.ads
package Primes is
subtype Prime is Integer range 2 .. Integer'Last
with Dynamic_Predicate
=> (for all N in 2 .. Prime - 1 => Prime mod N /= 0);
end Primes;
% cat test_primes.adb
with Ada.Assertions,
Ada.Text_IO;
with Primes;
procedure Test_Primes is
use Primes;
P : Prime;
begin
for I in 1 .. 25 loop
begin
P := I;
Ada.Text_IO.Put_Line (Prime'Image (P) & " is a prime.");
exception
when Constraint_Error =>
Ada.Text_IO.Put_Line (Integer'Image (I) &
" is not a prime (constraint).");
when Ada.Assertions.Assertion_Error =>
Ada.Text_IO.Put_Line (Integer'Image (I) &
" is not a prime (predicate).");
end;
end loop;
end Test_Primes;
% gnatmake -gnat12 -gnata -gnato -fstack-check test_primes
gcc -c -gnat12 -gnata -gnato -fstack-check test_primes.adb
gcc -c -gnat12 -gnata -gnato -fstack-check primes.ads
gnatbind -x test_primes.ali
gnatlink test_primes.ali -fstack-check
% ./test_primes
1 is not a prime (constraint).
2 is a prime.
3 is a prime.
4 is not a prime (constraint).
[...]
As I read 3.2.4(31/3) the raised exception for 4 should be
Assertion_Error and not Constraint_Error. Is this correct?
If I am correct, is there any likelihood that I could get a test for
this into ACATS (assuming that I can figure out how to formulate it
properly)?
Greetings,
Jacob
--
"I don't want to gain immortality in my works.
I want to gain it by not dying."
^ permalink raw reply [relevance 10%]
* Re: about the new Ada 2012 pre/post conditions
2012-06-25 16:26 11% ` stefan-lucks
@ 2012-06-25 19:42 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 67+ results
From: Dmitry A. Kazakov @ 2012-06-25 19:42 UTC (permalink / raw)
On Mon, 25 Jun 2012 18:26:18 +0200, stefan-lucks@see-the.signature wrote:
> On Mon, 25 Jun 2012, Dmitry A. Kazakov wrote:
>
>> Hilbert's program by no means was intended to justify logic or mathematics
>> themselves. This is outright wrong.
>
> Hilbert's program was an attempt to re-build the very foundations of
> Mathematics. No more, no less. See
> <http://en.wikipedia.org/wiki/Hilbert%27s_program>.
Right, and this had nothing to do with justification either logic or
mathematics by means of themselves. Such an epic task would rather be a job
for baron Muenchausen. Just scroll through the Hilbert's program list of
problems:
http://en.wikipedia.org/wiki/Hilbert_problems
>> If Ada precondition is neither implementation (#1) nor
>> specification/contract (#2) then what is it?
>
> A syntax for specifications.
Syntax only?
>>> *Secondly*, you seem to overlook that there are three semantical options,
>>> rather than the two you mention:
>>>
>>> 1 ignore the conditions
>>>
>>> 2 check them dynamically at run time
>>>
>>> 3 prove them statically at compile time
>>
>> I didn't:
>>
>> Assuming #1, only no.2 is possible. #1 <=> no.2
>>
>> Assuming #2, you have only choice between no.1 and no.3. #2 <=> no.1 or
>> no.2.
>>
>> One *cannot* mix no.1/3 with no.2, that is what upsets me.
>
> But you are not locked into either option 1, 2, or 3, you can choose,
> without having to change the language, or to rewrite a single character
> of your program source.
Same syntax for things which are far more apart than just semantically
different. What a bizzare idea! You would be switching between contract
specification and implementation per compiler switch! Is this C
preprocessor or Ada?
>> That clearly precludes no.2: handling is within the checker, checker is
>> outside the testee.
>
> Well, this separation is ideal. But most of the time, a testee that
> discovers itself being in a faulty state (and that is, what a failed
> dynamic check actually reveals), the testee is still able to write some
> information to a log file. Sure, you can construct or find the odd
> counterexample -- but in practice almost all the time this approach works.
> (OK, I am assuming your system allows to write some log output at all.)
Tracing is OK, but what happens afterwards? If continuation is possible,
that requires some cleanup, rollback, retry etc, which has the goal of
putting the system into some definite state. This is not over before over.
>> And, very importantly, we want to contract exceptions some day, don't we?
>
> Sure! So what?
How are going to marry exceptions propagating from contracts with contracts
on exceptions? Some exceptions are more exceptional than others? Aren't we
fed up with Program_Error?
> Ada.Assertions.Assertion_Error is one exception like Constraint_Error or
> the like. Either, you prove that this or that exception will not be
> raised. Or you claim that such an exception is not raised. If it is
> actually raised this is a violation of the contract. Which is a big deal
> for, say, Constraint_Error, but not for Ada.Assertions.Assertion_Error ...
> the exception that indicates the violation of a contract, anyway. (Assuming
> that Ada.Assertions.Assertion_Error is not raised manually -- but no sane
> programmer would do that.)
>
> Actually, there is one exception that is difficult to specify. It is our
> old fellow
>
> Storage_Error.
>
> On the level of source code analysis, you
> actually cannot prove that this exception will not be raised.
Firstly, you if you don't want to prove anything about a certain exception,
you would add this exception to all contracts involved and take care about
exceptions of interest.
Secondly, you would rather prove conditionals, like: Storage_Error is not
propagated when given amount of memory is available in the specified pools.
This is good enough for most cases, which are not about any exact bound,
but about existence of such bound, i.e. about memory leak detection.
Thirdly, you would be able to provide axioms. E.g. for some complex
recursive operation, you could just specify the upper memory consumption
bound known to you from other sources, and let the prover to go with that
(the oracle).
I think conservative Storage_Errror proof is pretty doable. If you move the
upper bound a pair Kbytes upward it would eliminate most of problems.
We certainly could learn from Java mistakes rather than repeating them
(e.g. interfaces).
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: about the new Ada 2012 pre/post conditions
@ 2012-06-25 16:26 11% ` stefan-lucks
2012-06-25 19:42 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 67+ results
From: stefan-lucks @ 2012-06-25 16:26 UTC (permalink / raw)
On Mon, 25 Jun 2012, Dmitry A. Kazakov wrote:
> Hilbert's program by no means was intended to justify logic or mathematics
> themselves. This is outright wrong.
Hilbert's program was an attempt to re-build the very foundations of
Mathematics. No more, no less. See
<http://en.wikipedia.org/wiki/Hilbert%27s_program>.
> If Ada precondition is neither implementation (#1) nor
> specification/contract (#2) then what is it?
A syntax for specifications.
> I said nothing about the syntax. It could be better, but syntax is always
> the most difficult part.
OK.
> > *Secondly*, you seem to overlook that there are three semantical options,
> > rather than the two you mention:
> >
> > 1 ignore the conditions
> >
> > 2 check them dynamically at run time
> >
> > 3 prove them statically at compile time
>
> I didn't:
>
> Assuming #1, only no.2 is possible. #1 <=> no.2
>
> Assuming #2, you have only choice between no.1 and no.3. #2 <=> no.1 or
> no.2.
>
> One *cannot* mix no.1/3 with no.2, that is what upsets me.
But you are not locked into either option 1, 2, or 3, you can choose,
without having to change the language, or to rewrite a single character
of your program source.
> > Even SPARK may soon support the Ada 2012 syntax for its annotations.
>
> That is OK to me, however, considering syntax I wished a clearer separation
> of pre-/post-conditions from other declarations. But since GPS rules, I
> suppose it would not be much difficult to have a view cutting
> pre-/post-conditions off and displaying them in a side-by-side window
> scrolled upon mouse hovering etc.
That is a matter of taste. In any case, emacs rules. ;-)
> > *Thirdly*, you seem to assume that a tool that can be used in a
> > destructive way cannot also be used properly.
>
> In this particular case (#2 + no.3) we wave a very strong evidence:
> accessibility checks. It was a disaster.
I agree that dynamic accessibility checks have failed to become a good
tool for reliable program development. But the standard requires no
compiler switch to allow them turning on and off on demand -- in contrast
to assertions and Ada 2012 conditions.I.e., the accessibility checks are
really part of the language, the checks are a tool that you have the
freedom to use or not to use!
> No objection whatsoever. I covered this case earlier. It is OK to check
> dynamically under the condition that the checker is an *independent*
> program. A debugger, checker, reasonably protected Ada run-time verifying
> preconditions and *handling* failed checks is perfectly consistent and
> advisable.
Agreed.
> That clearly precludes no.2: handling is within the checker, checker is
> outside the testee.
Well, this separation is ideal. But most of the time, a testee that
discovers itself being in a faulty state (and that is, what a failed
dynamic check actually reveals), the testee is still able to write some
information to a log file. Sure, you can construct or find the odd
counterexample -- but in practice almost all the time this approach works.
(OK, I am assuming your system allows to write some log output at all.)
> And, very importantly, we want to contract exceptions some day, don't we?
Sure! So what?
Ada.Assertions.Assertion_Error is one exception like Constraint_Error or
the like. Either, you prove that this or that exception will not be
raised. Or you claim that such an exception is not raised. If it is
actually raised this is a violation of the contract. Which is a big deal
for, say, Constraint_Error, but not for Ada.Assertions.Assertion_Error ...
the exception that indicates the violation of a contract, anyway. (Assuming
that Ada.Assertions.Assertion_Error is not raised manually -- but no sane
programmer would do that.)
Actually, there is one exception that is difficult to specify. It is our
old fellow
Storage_Error.
On the level of source code analysis, you
actually cannot prove that this exception will not be raised.
--
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany ----
<http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------ I love the taste of Cryptanalysis in the morning! ------
^ permalink raw reply [relevance 11%]
* Re: How many Ada compiler bugs are here?
2012-01-13 12:43 11% ` Georg Bauhaus
@ 2012-01-13 13:06 0% ` AdaMagica
0 siblings, 0 replies; 67+ results
From: AdaMagica @ 2012-01-13 13:06 UTC (permalink / raw)
On 13 Jan., 13:43, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> package P is
> type T (<>) is private;
> private
> type T is new Integer;
> function Raises_Assertion_Error return T;
> end P;
>
> package P.Dummies is
> Raising_Dummy : constant T;
> private
> Raising_Dummy : constant T := Raises_Assertion_Error;
> end P.Dummies;
>
> -- or make Raising_Dummy a constructing function that raises,
> -- so that raising happens where Raising_Dummy is written.
>
> with Ada.Assertions;
> package body P is
> function Raises_Assertion_Error return T is
> use Ada.Assertions;
> begin
> raise Assertion_Error with "FIXME";
> return Raises_Assertion_Error;
> end Raises_Assertion_Error;
> end P;
>
> Is this about statically ascertaining that a meaningful initial value
> has been stored in an object of type T, where "meaningful" is a statically
> known consequence of using some construction feature of non-Ada, or
> not-yet-Ada?
I do not see what you are trying to accomplish. As written, P.Dummies
will raise an exception upon elaboration.
package P is
type T (<>) is private;
function F (...) return T;
private
...
end P;
This *is* the Ada way to force meaningful initial values. You may have
as many functions returning a T as you like with whatever parameter
profile. There is no need for any further apparatus. (Or am I missing
something?)
^ permalink raw reply [relevance 0%]
* Re: How many Ada compiler bugs are here?
@ 2012-01-13 12:43 11% ` Georg Bauhaus
2012-01-13 13:06 0% ` AdaMagica
0 siblings, 1 reply; 67+ results
From: Georg Bauhaus @ 2012-01-13 12:43 UTC (permalink / raw)
On 13.01.12 12:39, Dmitry A. Kazakov wrote:
> On 13 Jan 2012 10:38:04 GMT, georg bauhaus wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>
>>>
>>> package P is
>>> type T (<>) is private;
>>> private
>>> type T is new Integer;
>>> end P;
>>>
>>
>> package P.Dummies is
>> Meaningless_Dummy : constant T;
>> Raising_Dummy : constant T;
>> private
>> ...
>> End P.Dummies;
>
> Which of course defies the very idea of requiring T initialized. If there
> exist some Meaningless_Dummy constant, then that could serve as an initial
> value for T.
I'd drop Meaningless_Dummy, then, and declare only the dummy
that raises an exception:
package P is
type T (<>) is private;
private
type T is new Integer;
function Raises_Assertion_Error return T;
end P;
package P.Dummies is
Raising_Dummy : constant T;
private
Raising_Dummy : constant T := Raises_Assertion_Error;
end P.Dummies;
-- or make Raising_Dummy a constructing function that raises,
-- so that raising happens where Raising_Dummy is written.
with Ada.Assertions;
package body P is
function Raises_Assertion_Error return T is
use Ada.Assertions;
begin
raise Assertion_Error with "FIXME";
return Raises_Assertion_Error;
end Raises_Assertion_Error;
end P;
Is this about statically ascertaining that a meaningful initial value
has been stored in an object of type T, where "meaningful" is a statically
known consequence of using some construction feature of non-Ada, or
not-yet-Ada?
^ permalink raw reply [relevance 11%]
* Aspect programming
@ 2011-07-27 16:29 10% Anh Vo
0 siblings, 0 replies; 67+ results
From: Anh Vo @ 2011-07-27 16:29 UTC (permalink / raw)
If I understand the ARM 2012 and Ada 2012 Rationale correctly, the
following test code should raise Ada.Assertions.Assertion_Error.
However, Stack_Error is raised instead. I am using GNAT-GPL-2011. Is
it my bug or compiler's bug?
pragma Assertion_Policy (Check);
-- pragma Check_Policy (Postconditions, On);
-- pragma Check_Policy (Preconditions, On);
with Ada.Assertions;
with Ada.Text_Io;
with Ada.Exceptions;
with Stacks;
procedure Aspect_Programming_Test is
use Ada;
use Text_Io;
package Int_Stacks is new Stacks (Integer);
My_Int_Stack : Int_Stacks.Stack;
My_Int : Integer := -1;
begin
Put_Line ("Learning Aspect-Oriented Software Programming");
for Index in 1 .. 10 loop
My_Int_Stack.Push (Index);
end loop;
Put_Line ("Next Push operation will trigger Stack Full problem /
exception");
My_Int_Stack.Push (1);
for Index in 1 .. 10 loop
My_Int_Stack.Pop (My_Int);
end loop;
Put_Line ("Next Pop operation will trigger Stack Empty problem /
exception");
My_Int_Stack.Pop (My_Int);
exception
when Ada.Assertions.Assertion_Error =>
Put_Line ("Pragma Assertion_Policy is in effect");
when Error : Int_Stacks.Stack_Error =>
Put_Line ("Pragma Assertion_Policy is ignored");
Put_Line (Exceptions.Exception_Information (Error));
when Error : others =>
Put_Line ("Let's see what is going on => ");
Put_Line (Exceptions.Exception_Information (Error));
end Aspect_Programming_Test;
generic
type Item is private;
Size : Positive := 10;
package Stacks is
type Stack is tagged private;
function Is_Empty (S : Stack) return Boolean;
function Is_Full (S : Stack) return Boolean;
procedure Push (S : in out Stack;
X : in Item)
with Pre => not Is_Full (S),
Post => not Is_Empty (S);
procedure Pop (S : in out Stack;
X : out Item)
with Pre => not Is_Empty (S),
Post => not Is_Full (S);
Stack_Error: exception;
private
type Data_Array is array (Natural Range 1 .. Size) of Item;
type Stack is tagged record
Data : Data_Array;
Index : Positive := 1;
end record;
function Current_Items (S : Stack) return Natural;
end Stacks;
pragma Assertion_Policy (Check);
package body Stacks is
protected Mutex is -- Mutex object section starts
entry Take;
procedure Release;
private
Resource_Available : Boolean := True;
end Mutex;
protected body Mutex is
entry Take when Resource_Available is
begin
Resource_Available := False;
end Take;
procedure Release is
begin
Resource_Available := True;
end Release;
end Mutex; -- Mutex object section ends
function Is_Empty (S : Stack) return Boolean is
Condition : Boolean := True;
begin
Mutex.Take;
Condition := S.Index = 1;
Mutex.Release;
return Condition;
end Is_Empty;
function Is_Full (S : Stack) return Boolean is
Condition : Boolean := True;
begin
Mutex.Take;
Condition := S.Index = Size + 1;
Mutex.Release;
return Condition;
end Is_Full;
procedure Push (S : in out Stack;
X : in Item) is
begin
Mutex.Take;
if S.Index = Size + 1 then
Mutex.Release;
raise Stack_Error with "Stack is full!!!";
end if;
S.Data(S.Index) := X;
S.Index := S.Index + 1;
Mutex.Release;
end Push;
procedure Pop (S : in out Stack;
X : out Item) is
begin
Mutex.Take;
if S.Index = 1 then
Mutex.Release;
raise Stack_Error with "Stack is empty!!!";
end if;
S.Index := S.Index - 1;
X := S.Data(S.Index);
Mutex.Release;
end Pop;
function Current_Items (S : Stack) return Natural is
Items_Count : Natural := 0;
begin
Mutex.Take;
Items_Count := S.Index - 1;
Mutex.Release;
return Items_Count;
end Current_Items;
end Stacks;
^ permalink raw reply [relevance 10%]
* Re: Should representation clauses be complete for each bit?
2011-07-23 15:12 0% ` Robert A Duff
@ 2011-07-26 21:10 0% ` Randy Brukardt
0 siblings, 0 replies; 67+ results
From: Randy Brukardt @ 2011-07-26 21:10 UTC (permalink / raw)
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc62mtav52.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> I would do this slightly differently (in fact we did, in Claw where we
>> had
>> this exact problem):
>>
>> type T is
>> record
>> One : Boolean;
>> Gap1 : Bits2 := 0; -- must be zero
>> Tooth : Boolean;
>> Gap2 : Bits11 := 0; -- must be zero
>> Ree : Boolean;
>> end record
>> with Predicate => T.Gap1 = 0 and T.Gap2 = 0;
>>
>> with the same record rep clause.
>> Then the (correct) aggregates don't need to mention the gaps explicitly:
>>
>> with Ada.Assertions; use Ada.Assertions;
>> procedure P.Main is
>> -- X : T := (One | Tooth | Ree => True, Gap1 => 0, Gap2 => 0); -- OK
>> X : T := (One | Tooth | Ree => True, others => <>); -- OK
>
> Hmm. That seems reasonable, although it makes me nervous that
> you might accidentally say:
>
> X : T := (One | Tooth => True, others => <>);
>
> which evilly leaves junk in Ree. That sort of bug is likely if you add
> new components to a record.
Ugh. There really should be a restriction or something to prevent using <>
for uninitialized things. We have such a rule for discriminants, it would
seem easy enough to have it for all types (admittedly, it would be
complicated by the recursive nature for record types). It can't be very
common that the program actually wants to write aggregates that fill the
aggregate with junk.
Randy.
^ permalink raw reply [relevance 0%]
* Re: Should representation clauses be complete for each bit?
2011-07-22 23:50 11% ` Randy Brukardt
@ 2011-07-23 15:12 0% ` Robert A Duff
2011-07-26 21:10 0% ` Randy Brukardt
0 siblings, 1 reply; 67+ results
From: Robert A Duff @ 2011-07-23 15:12 UTC (permalink / raw)
"Randy Brukardt" <randy@rrsoftware.com> writes:
> I would do this slightly differently (in fact we did, in Claw where we had
> this exact problem):
>
> type T is
> record
> One : Boolean;
> Gap1 : Bits2 := 0; -- must be zero
> Tooth : Boolean;
> Gap2 : Bits11 := 0; -- must be zero
> Ree : Boolean;
> end record
> with Predicate => T.Gap1 = 0 and T.Gap2 = 0;
>
> with the same record rep clause.
> Then the (correct) aggregates don't need to mention the gaps explicitly:
>
> with Ada.Assertions; use Ada.Assertions;
> procedure P.Main is
> -- X : T := (One | Tooth | Ree => True, Gap1 => 0, Gap2 => 0); -- OK
> X : T := (One | Tooth | Ree => True, others => <>); -- OK
Hmm. That seems reasonable, although it makes me nervous that
you might accidentally say:
X : T := (One | Tooth => True, others => <>);
which evilly leaves junk in Ree. That sort of bug is likely if you add
new components to a record.
- Bob
^ permalink raw reply [relevance 0%]
* Re: Should representation clauses be complete for each bit?
2011-07-20 14:51 10% ` Robert A Duff
2011-07-21 7:36 0% ` Martin
@ 2011-07-22 23:50 11% ` Randy Brukardt
2011-07-23 15:12 0% ` Robert A Duff
1 sibling, 1 reply; 67+ results
From: Randy Brukardt @ 2011-07-22 23:50 UTC (permalink / raw)
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcczkk9ngxy.fsf@shell01.TheWorld.com...
...
> I think the unused bits should be explicitly declared.
I agree.
...
> How about the following?
>
> package P is
> type Bits2 is mod 2**2;
> pragma Assert (Bits2'Size = 2);
> type Bits11 is mod 2**11;
> pragma Assert (Bits11'Size = 11);
>
> type T is
> record
> One : Boolean;
> Gap1 : Bits2; -- must be zero
> Tooth : Boolean;
> Gap2 : Bits11; -- must be zero
> Ree : Boolean;
> end record
> with Predicate => T.Gap1 = 0 and T.Gap2 = 0;
I would do this slightly differently (in fact we did, in Claw where we had
this exact problem):
type T is
record
One : Boolean;
Gap1 : Bits2 := 0; -- must be zero
Tooth : Boolean;
Gap2 : Bits11 := 0; -- must be zero
Ree : Boolean;
end record
with Predicate => T.Gap1 = 0 and T.Gap2 = 0;
with the same record rep clause.
Then the (correct) aggregates don't need to mention the gaps explicitly:
with Ada.Assertions; use Ada.Assertions;
procedure P.Main is
-- X : T := (One | Tooth | Ree => True, Gap1 => 0, Gap2 => 0); -- OK
X : T := (One | Tooth | Ree => True, others => <>); -- OK
Randy.
^ permalink raw reply [relevance 11%]
* Re: Should representation clauses be complete for each bit?
2011-07-20 14:51 10% ` Robert A Duff
@ 2011-07-21 7:36 0% ` Martin
2011-07-22 23:50 11% ` Randy Brukardt
1 sibling, 0 replies; 67+ results
From: Martin @ 2011-07-21 7:36 UTC (permalink / raw)
On Jul 20, 3:51 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> okellogg <okell...@users.sourceforge.net> writes:
> > Picking up an age old thread,
> >http://groups.google.com/group/comp.lang.ada/browse_thread/thread/9ab...
>
> Wow. 1998.
>
> > IMHO it would be a real gain if we could explicitly mention the unused
> > bits in the rep spec.
>
> I think the unused bits should be explicitly declared.
>
>
>
>
>
>
>
>
>
> > Reusing the example from the OP,
>
> >> type x is record
> >> one : boolean;
> >> two : boolean;
> >> three : boolean;
> >> end record;
> >> for x use record
> >> one at 0 range 0..0;
> >> two at 0 range 3..3;
> >> three at 0 range 15..15;
> >> end record;
>
> > What I imagine is something like,
>
> > for x use record
> > one at 0 range 0 .. 0;
> > null at 0 range 1 .. 2; // note reserved word "null"
> > two at 0 range 3 .. 3;
> > null at 0 range 4 .. 14;
> > three at 0 range 15 .. 15;
> > end record;
> > for x'Size use 16;
>
> > The components with "null" would instruct the compiler to fill the
> > bits with 0.
>
> How about the following?
>
> package P is
> type Bits2 is mod 2**2;
> pragma Assert (Bits2'Size = 2);
> type Bits11 is mod 2**11;
> pragma Assert (Bits11'Size = 11);
>
> type T is
> record
> One : Boolean;
> Gap1 : Bits2; -- must be zero
> Tooth : Boolean;
> Gap2 : Bits11; -- must be zero
> Ree : Boolean;
> end record
> with Predicate => T.Gap1 = 0 and T.Gap2 = 0;
>
> for T use
> record
> pragma Complete_Representation;
> One at 0 range 0..0;
> Gap1 at 0 range 1..2;
> Tooth at 0 range 3..3;
> Gap2 at 0 range 4..14;
> Ree at 0 range 15..15;
> end record;
> end P;
>
> with Ada.Assertions; use Ada.Assertions;
> procedure P.Main is
> X : T := (One | Tooth | Ree => True, Gap1 => 0, Gap2 => 0); -- OK
> begin
> begin
> X := T'(One | Tooth | Ree => True, Gap1 => 1, Gap2 => 2); -- Wrong.
> exception
> when Assertion_Error => null; -- OK
> end;
> pragma Assert (X = (One | Tooth | Ree => True, Gap1 => 0, Gap2 => 0));
> end P.Main;
>
> By the way, I find Ada's representation clauses to be at the wrong
> level of abstraction. Why can't I just write a single line of code
> that means "put all the components in declaration order with no gaps
> in between"?
>
> - Bob
A bit like Telegen2's "pragma Preserve_Layout" (if my memory hasn't
rusted too much)?...
-- Martin
^ permalink raw reply [relevance 0%]
* Re: Should representation clauses be complete for each bit?
@ 2011-07-20 14:51 10% ` Robert A Duff
2011-07-21 7:36 0% ` Martin
2011-07-22 23:50 11% ` Randy Brukardt
0 siblings, 2 replies; 67+ results
From: Robert A Duff @ 2011-07-20 14:51 UTC (permalink / raw)
okellogg <okellogg@users.sourceforge.net> writes:
> Picking up an age old thread,
> http://groups.google.com/group/comp.lang.ada/browse_thread/thread/9ab165cd2cc73cb
Wow. 1998.
> IMHO it would be a real gain if we could explicitly mention the unused
> bits in the rep spec.
I think the unused bits should be explicitly declared.
> Reusing the example from the OP,
>
>> type x is record
>> one : boolean;
>> two : boolean;
>> three : boolean;
>> end record;
>> for x use record
>> one at 0 range 0..0;
>> two at 0 range 3..3;
>> three at 0 range 15..15;
>> end record;
>
> What I imagine is something like,
>
> for x use record
> one at 0 range 0 .. 0;
> null at 0 range 1 .. 2; // note reserved word "null"
> two at 0 range 3 .. 3;
> null at 0 range 4 .. 14;
> three at 0 range 15 .. 15;
> end record;
> for x'Size use 16;
>
> The components with "null" would instruct the compiler to fill the
> bits with 0.
How about the following?
package P is
type Bits2 is mod 2**2;
pragma Assert (Bits2'Size = 2);
type Bits11 is mod 2**11;
pragma Assert (Bits11'Size = 11);
type T is
record
One : Boolean;
Gap1 : Bits2; -- must be zero
Tooth : Boolean;
Gap2 : Bits11; -- must be zero
Ree : Boolean;
end record
with Predicate => T.Gap1 = 0 and T.Gap2 = 0;
for T use
record
pragma Complete_Representation;
One at 0 range 0..0;
Gap1 at 0 range 1..2;
Tooth at 0 range 3..3;
Gap2 at 0 range 4..14;
Ree at 0 range 15..15;
end record;
end P;
with Ada.Assertions; use Ada.Assertions;
procedure P.Main is
X : T := (One | Tooth | Ree => True, Gap1 => 0, Gap2 => 0); -- OK
begin
begin
X := T'(One | Tooth | Ree => True, Gap1 => 1, Gap2 => 2); -- Wrong.
exception
when Assertion_Error => null; -- OK
end;
pragma Assert (X = (One | Tooth | Ree => True, Gap1 => 0, Gap2 => 0));
end P.Main;
By the way, I find Ada's representation clauses to be at the wrong
level of abstraction. Why can't I just write a single line of code
that means "put all the components in declaration order with no gaps
in between"?
- Bob
^ permalink raw reply [relevance 10%]
* Re: Ada vs Eiffel - Ada programmer approach
2009-06-04 13:25 0% ` Robert A Duff
@ 2009-06-04 13:39 0% ` Martin
0 siblings, 0 replies; 67+ results
From: Martin @ 2009-06-04 13:39 UTC (permalink / raw)
On Jun 4, 2:25 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
> > I think my point was precisely that Ada assertions were different from
> > Eiffel's. I like the fact that, in Ada, I can place assertions in the
> > middle of a complex subprogram; this is not possible Eiffel, as you
> > aptly described.
>
> It's possible in Eiffel -- Eiffel has a feature analogous to Ada's
> pragma Assert.
>
> Newer versions of GNAT have pragmas Precondition and Postcondition.
> We're thinking about adding pragma Invariant.
>
> The ARG is also thinking about adding pre/post/inv features to
> the language.
>
> - Bob
Please! :-)
Cheers
-- Martin
^ permalink raw reply [relevance 0%]
* Re: Ada vs Eiffel - Ada programmer approach
2009-06-04 7:55 13% ` Ludovic Brenta
2009-06-04 8:45 0% ` Georg Bauhaus
@ 2009-06-04 13:25 0% ` Robert A Duff
2009-06-04 13:39 0% ` Martin
1 sibling, 1 reply; 67+ results
From: Robert A Duff @ 2009-06-04 13:25 UTC (permalink / raw)
Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
> I think my point was precisely that Ada assertions were different from
> Eiffel's. I like the fact that, in Ada, I can place assertions in the
> middle of a complex subprogram; this is not possible Eiffel, as you
> aptly described.
It's possible in Eiffel -- Eiffel has a feature analogous to Ada's
pragma Assert.
Newer versions of GNAT have pragmas Precondition and Postcondition.
We're thinking about adding pragma Invariant.
The ARG is also thinking about adding pre/post/inv features to
the language.
- Bob
^ permalink raw reply [relevance 0%]
* Re: Ada vs Eiffel - Ada programmer approach
2009-06-04 8:45 0% ` Georg Bauhaus
@ 2009-06-04 9:03 0% ` Ludovic Brenta
0 siblings, 0 replies; 67+ results
From: Ludovic Brenta @ 2009-06-04 9:03 UTC (permalink / raw)
Georg Bauhaus wrote on comp.lang.ada:
> Ludovic Brenta schrieb:
>
> > I think my point was precisely that Ada assertions were different from
> > Eiffel's. I like the fact that, in Ada, I can place assertions in the
> > middle of a complex subprogram; this is not possible Eiffel,
>
> Yes, you can. You can place an assertion anywhere in an Eiffel program.
> That is what the reserved word "check" is for.
OK, I stand corrected. Thanks for that. But I think my earlier point
about DbC remains valid; what you just showed is that you can do Ada-
like assertions in Eiffel, too, instead of or as a complement to pre/
post conditions and invariants.
--
Ludovic Brenta.
^ permalink raw reply [relevance 0%]
* Re: Ada vs Eiffel - Ada programmer approach
2009-06-04 7:55 13% ` Ludovic Brenta
@ 2009-06-04 8:45 0% ` Georg Bauhaus
2009-06-04 9:03 0% ` Ludovic Brenta
2009-06-04 13:25 0% ` Robert A Duff
1 sibling, 1 reply; 67+ results
From: Georg Bauhaus @ 2009-06-04 8:45 UTC (permalink / raw)
Ludovic Brenta schrieb:
> I think my point was precisely that Ada assertions were different from
> Eiffel's. I like the fact that, in Ada, I can place assertions in the
> middle of a complex subprogram; this is not possible Eiffel,
Yes, you can. You can place an assertion anywhere in an Eiffel program.
That is what the reserved word "check" is for.
^ permalink raw reply [relevance 0%]
* Re: Ada vs Eiffel - Ada programmer approach
@ 2009-06-04 7:55 13% ` Ludovic Brenta
2009-06-04 8:45 0% ` Georg Bauhaus
2009-06-04 13:25 0% ` Robert A Duff
0 siblings, 2 replies; 67+ results
From: Ludovic Brenta @ 2009-06-04 7:55 UTC (permalink / raw)
On Jun 4, 9:30 am, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:
> On 26 mai, 15:37, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
> > [...] Ada's pragma Assert provides what I
> > need in these (rare) cases because I can put such pragmas in the
> > middle of a subprogram, for example.
>
> > --
> > Ludovic Brenta.
>
> This is not the same as Eiffel assertions. Eiffel's assertions are
> aware of the invokation contexte. Let say you have a class C and a
> method M and the class C has an invariant I. Then, if a client invoks
> M, the invariant will be checked before M returns. That's Ok, this is
> the same as with "in code assertions". But if M is invoked by anoher
> method of the class, i.e. as an implementation method (this is very
> common to use a public method for internal purpose), you will have
> this : the client of C invok a method M2 which in turn will invok M
> (the client may or may not know about it). In this context, the class
> invariant will obviously be checked before returning from M2, but *it
> will not be check before return from M*.
>
> That is beceause M is allowed to left the class invariant in an
> illegal state, as it may be the sole responsability of M2.
>
> So, Eiffel's assertions are not the same as "in code assertions".
> Eiffel's assertions are well formalized.
I think my point was precisely that Ada assertions were different from
Eiffel's. I like the fact that, in Ada, I can place assertions in the
middle of a complex subprogram; this is not possible Eiffel, as you
aptly described. I agree that Eiffel's assertions are well-defined but
my argument is that they are less useful and more diffucult to use in
practice than the beauty of the design suggests.
--
Ludovic Brenta.
^ permalink raw reply [relevance 13%]
* Re: How to put 200 into an integer sub-type of 16 bits (code included)
[not found] ` <3d3719f4-355c-4094-9902-495d612d46fe@n33g2000pri.googlegroups.com>
2009-01-14 12:47 6% ` Brian Drummond
@ 2009-01-14 12:53 6% ` Brian Drummond
1 sibling, 0 replies; 67+ results
From: Brian Drummond @ 2009-01-14 12:53 UTC (permalink / raw)
On Tue, 13 Jan 2009 20:33:19 -0800 (PST), ChristopherL
<clusardi2k@aol.com> wrote:
>On Jan 13, 9:33�pm, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:
>> what are you really trying to do?
>>
>> - Brian
>
>
>What I want to do is this. I have a variable holding the base 10 value
>200. It has a certain bit representation. If the variable was an
>integer of 16 bits it's representation would be something such as
>0000000011001000. For give me if I'm wrong. Anyway, what I'd like to
>do is put that exact bit representation in another variable of a
>different type.
>
>How do I proceed?
UNCHECKED_CONVERSION is central to this.
But unless you are trying to write C in Ada, take Ludovic's suggestions
seriously.
You may not have LONG_LONG_INTEGER, and FLOAT may not be the size you
expect. If you want specific representations, then specify what you
want.
Making a couple of unjustified wild assumptions about what you want to
do:
(a) by FLOAT you mean IEEE P754 32-bit single precision (or something
closely compatible with it; there are sloppy implementations out there)
(b) you need to translate from your 16 bit integer input to the
identical number represented as 32-bit integer as a first step; there
may be endian issues to worry about here; THEN to FLOAT
(c) you don't want to translate 200 (16#C8#) to 200.0 (otherwise you'd
simply convert it!) but to some very very small denormalised number
(16#000000C8# is in the region below 10^-37)
(Aside to Ludovic: it's a legal FLOAT value in any FP representation
I've seen; but may be invalid for obscure or prehistoric machines)
(d) All your 16 bit inputs translate to denorms, which makes me wonder
if this is really what you want. But if you want the inputs in the most
significant bits of the 32-bit type you have to say so...
>I was thinking of trying to do it with code such as the below. The
>below code is not mine and came from this group. So, tomorrow I am
>planning on modifying my first example above to use the below code.
>What are my chances of doing it?
>package INT_IO is new TEXT_IO.INTEGER_IO(LONG_LONG_INTEGER);
Type Float_32 is new digits 7;
-- hack warning: most systems will adopt IEEE 754 SP for this
-- I think "Float" could be 64 bit in some implementations
-- Either way CHECK the size you get...
pragma Assert(Float'Size = 32);
-- you need to use Ada.Assertions
Type Integer_32_bit is -- ... see Ludovic's code
package INT_32_IO is new TEXT_IO.INTEGER_IO(Integer_32_bit);
>INT:=2#11111111100000000000000000000000#;
Unless you are better at counting zeroes than I am,
>INT:=2#1111_1111_1000_0000_0000_0000_0000_0000#;
(aha! positive infinity...)
or better
INT := 16#3f800000#; -- known 1.0 in P754 SP
and TEST this independently of your 16-bit to 32-bit translation
Disclaimer: I am new to Ada, but slightly familiar with FP bit wrangling
in the closely related language VHDL.
- Brian
^ permalink raw reply [relevance 6%]
* Re: How to put 200 into an integer sub-type of 16 bits (code included)
[not found] ` <3d3719f4-355c-4094-9902-495d612d46fe@n33g2000pri.googlegroups.com>
@ 2009-01-14 12:47 6% ` Brian Drummond
2009-01-14 12:53 6% ` Brian Drummond
1 sibling, 0 replies; 67+ results
From: Brian Drummond @ 2009-01-14 12:47 UTC (permalink / raw)
On Tue, 13 Jan 2009 20:33:19 -0800 (PST), ChristopherL
<clusardi2k@aol.com> wrote:
>On Jan 13, 9:33�pm, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:
>> what are you really trying to do?
>>
>> - Brian
>
>
>What I want to do is this. I have a variable holding the base 10 value
>200. It has a certain bit representation. If the variable was an
>integer of 16 bits it's representation would be something such as
>0000000011001000. For give me if I'm wrong. Anyway, what I'd like to
>do is put that exact bit representation in another variable of a
>different type.
>
>How do I proceed?
UNCHECKED_CONVERSION is central to this.
But unless you are trying to write C in Ada, take Ludovic's suggestions
seriously.
You may not have LONG_LONG_INTEGER, and FLOAT may not be the size you
expect. If you want specific representations, then specify what you
want.
Making a couple of unjustified wild assumptions about what you want to
do:
(a) by FLOAT you mean IEEE P754 32-bit single precision (or something
closely compatible with it; there are sloppy implementations out there)
(b) you need to translate from your 16 bit integer input to the
identical number represented as 32-bit integer as a first step; there
may be endian issues to worry about here; THEN to FLOAT
(c) you don't want to translate 200 (16#C8#) to 200.0 (otherwise you'd
simply convert it!) but to some very very small denormalised number
(16#000000C8# is in the region below 10^-37)
(Aside to Ludovic: it's a legal FLOAT value in any FP representation
I've seen; but may be invalid for obscure or prehistoric machines)
(d) All your 16 bit inputs translate to denorms, which makes me wonder
if this is really what you want. But if you want the inputs in the most
significant bits of the 32-bit type you have to say so...
>I was thinking of trying to do it with code such as the below. The
>below code is not mine and came from this group. So, tomorrow I am
>planning on modifying my first example above to use the below code.
>What are my chances of doing it?
>package INT_IO is new TEXT_IO.INTEGER_IO(LONG_LONG_INTEGER);
Type Float_32 is new digits 7;
-- hack warning: most systems will adopt IEEE 754 SP for this
-- I think "Float" could be 64 bit in some implementations
-- Either way CHECK the size you get...
pragma Assert(Float'Size = 32);
-- you need to use Ada.Assertions
Type Integer_32_bit is -- ... see Ludovic's code
package INT_32_IO is new TEXT_IO.INTEGER_IO(Integer_32_bit);
>INT:=2#11111111100000000000000000000000#;
Unless you are better at counting zeroes than I am,
INT := 16#3f800000#; -- known 1.0 in P754 SP
and test this independently of your 16-bit to 32-bit translation
Disclaimer: I am new to Ada, but not to FP bit wrangling in the closely
related language VHDL.
- Brian
^ permalink raw reply [relevance 6%]
* Re: Ada 2005 core packages under GNAT-GPL-2007
2007-05-16 3:00 9% ` Randy Brukardt
2007-05-22 14:41 0% ` Anh Vo
@ 2007-05-22 14:50 0% ` Anh Vo
1 sibling, 0 replies; 67+ results
From: Anh Vo @ 2007-05-22 14:50 UTC (permalink / raw)
On May 15, 8:00 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> "Anh Vo" <anhvofrc...@gmail.com> wrote in message
>
> news:1179177085.116978.75190@w5g2000hsg.googlegroups.com...
> ...
>
> > > GNAT GPL 2007 doesn't include an implementation of this package but
> > > you can add one yourself.
> ...
> > According to Ada 2005 LRM, Ada.Assertions is a core package which is
> > implementation required.
>
> I agree. 11.4.2(11/2) says "The following language-defined package exists:"
> followed by the definition of Ada.Assertions. It doesn't say that it might
> exist if you compile it yourself...I think that's pretty much always true!
I reported it. Actually, the issue had been logged prior to my report
according to Robert.
AV
^ permalink raw reply [relevance 0%]
* Re: Ada 2005 core packages under GNAT-GPL-2007
2007-05-16 3:00 9% ` Randy Brukardt
@ 2007-05-22 14:41 0% ` Anh Vo
2007-05-22 14:50 0% ` Anh Vo
1 sibling, 0 replies; 67+ results
From: Anh Vo @ 2007-05-22 14:41 UTC (permalink / raw)
On May 15, 8:00 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> "Anh Vo" <anhvofrc...@gmail.com> wrote in message
>
> news:1179177085.116978.75190@w5g2000hsg.googlegroups.com...
> ...
>
> > > GNAT GPL 2007 doesn't include an implementation of this package but
> > > you can add one yourself.
> ...
> > According to Ada 2005 LRM, Ada.Assertions is a core package which is
> > implementation required.
>
> I agree. 11.4.2(11/2) says "The following language-defined package exists:"
> followed by the definition of Ada.Assertions. It doesn't say that it might
> exist if you compile it yourself...I think that's pretty much always true!
I reported it. Actually, the issue had been logged prior to my report
according to Robert.
AV
^ permalink raw reply [relevance 0%]
* Re: Ada 2005 core packages under GNAT-GPL-2007
2007-05-14 21:11 9% ` Anh Vo
@ 2007-05-16 3:00 9% ` Randy Brukardt
2007-05-22 14:41 0% ` Anh Vo
2007-05-22 14:50 0% ` Anh Vo
0 siblings, 2 replies; 67+ results
From: Randy Brukardt @ 2007-05-16 3:00 UTC (permalink / raw)
"Anh Vo" <anhvofrcaus@gmail.com> wrote in message
news:1179177085.116978.75190@w5g2000hsg.googlegroups.com...
...
> > GNAT GPL 2007 doesn't include an implementation of this package but
> > you can add one yourself.
...
> According to Ada 2005 LRM, Ada.Assertions is a core package which is
> implementation required.
I agree. 11.4.2(11/2) says "The following language-defined package exists:"
followed by the definition of Ada.Assertions. It doesn't say that it might
exist if you compile it yourself...I think that's pretty much always true!
;-)
Randy.
^ permalink raw reply [relevance 9%]
* Re: Ada 2005 core packages under GNAT-GPL-2007
2007-05-14 20:20 14% ` Martin Dowie
@ 2007-05-14 21:11 9% ` Anh Vo
2007-05-16 3:00 9% ` Randy Brukardt
0 siblings, 1 reply; 67+ results
From: Anh Vo @ 2007-05-14 21:11 UTC (permalink / raw)
On May 14, 1:20 pm, Martin Dowie <martin.do...@btopenworld.com> wrote:
> On 14 May, 18:57, Anh Vo <anhvofrc...@gmail.com> wrote:
>
> > Ada.Assertions package (AI-286 implemented by Martin Dowie) is part of
> > Ada 2005 core packages as indicated by 14.4.2(12/2). However, when
> > compiling codes having "with Ada.Assertions" in the with clause, GNAT
> > displays ..."Ada.Assertions" is not a predefined library unit. GNAT
> > does not seem to recognize it. Should a bug report be in order?
>
> GNAT GPL 2007 doesn't include an implementation of this package but
> you can add one yourself.
Martin,
Thank you very much for your work. I will do just that for now while
learning if this package is required or optional.
According to Ada 2005 LRM, Ada.Assertions is a core package which is
implementation required.
AV
^ permalink raw reply [relevance 9%]
* Re: Ada 2005 core packages under GNAT-GPL-2007
2007-05-14 17:57 13% Ada 2005 core packages under GNAT-GPL-2007 Anh Vo
2007-05-14 20:14 9% ` Ludovic Brenta
@ 2007-05-14 20:20 14% ` Martin Dowie
2007-05-14 21:11 9% ` Anh Vo
1 sibling, 1 reply; 67+ results
From: Martin Dowie @ 2007-05-14 20:20 UTC (permalink / raw)
On 14 May, 18:57, Anh Vo <anhvofrc...@gmail.com> wrote:
> Ada.Assertions package (AI-286 implemented by Martin Dowie) is part of
> Ada 2005 core packages as indicated by 14.4.2(12/2). However, when
> compiling codes having "with Ada.Assertions" in the with clause, GNAT
> displays ..."Ada.Assertions" is not a predefined library unit. GNAT
> does not seem to recognize it. Should a bug report be in order?
GNAT GPL 2007 doesn't include an implementation of this package but
you can add one yourself.
The original one on my web page was provided to allow Ada95 compilers
to provide something as close as possible to Ada2005 as possible. For
instance, Ada.Assertions could not be "Pure" as it had to rely on
Ada.Exceptions for the implementation.
This isn't true now we have an Ada2005 compiler! So here's a version
you can compile up yourself. Again once compiled you can move the
source/.ali/.o files into the appropriate locations. You may wish to
change the compilation options too. NB: the file a-assert.adb needs to
suppress the GNAT RM-style checks.
File a-assert.ads
-- (c) 2007 Martin Dowie
pragma License (Unrestricted);
package Ada.Assertions is
pragma Pure (Ada.Assertions);
Assertion_Error : exception;
procedure Assert (Check : in Boolean);
procedure Assert (Check : in Boolean;
Message : in String);
end Ada.Assertions;
File a-assert.adb
-- (c) 2007 Martin Dowie
package body Ada.Assertions is
procedure Assert (Check : in Boolean) is
begin
if not Check then
raise Assertion_Error;
end if;
end Assert;
procedure Assert (Check : in Boolean;
Message : in String) is
begin
if not Check then
raise Assertion_Error with Message;
end if;
end Assert;
end Ada.Assertions;
GPS project file (test_assertion.gpr):
project Test_Assertion is
for Object_Dir use "lib";
for Source_Dirs use ("src");
for Main use ("test_assertion.adb");
package Linker is
for Default_Switches ("ada") use ("-g");
end Linker;
package Binder is
for Default_Switches ("ada") use ("-E");
end Binder;
package Compiler is
for Default_Switches ("ada") use ("-gnato", "-fstack-check", "-
gnatE", "-g", "-gnata", "-gnat05");
for Switches ("a-assert.adb") use ("-gnato", "-fstack-check", "-
gnatE", "-g", "-gnata", "-gnat05", "-gnatyN");
end Compiler;
package Builder is
for Default_Switches ("ada") use ("-s", "-g", "-a", "-x");
end Builder;
end Test_Assertion;
File test_assertion.adb
with Ada.Assertions;
procedure Test_Assertion is
begin
Ada.Assertions.Assert (True);
Ada.Assertions.Assert (False);
end Test_Assertion;
The folder structure used was:
C:\Ada\test_assertion - test_assertion.gpr
C:\Ada\test_assertion\src - a-assert.ads a-assert.adb
test_assertion.adb
C:\Ada\test_assertion\lib - build files
Cheers
-- Martin
^ permalink raw reply [relevance 14%]
* Re: Ada 2005 core packages under GNAT-GPL-2007
2007-05-14 17:57 13% Ada 2005 core packages under GNAT-GPL-2007 Anh Vo
@ 2007-05-14 20:14 9% ` Ludovic Brenta
2007-05-14 20:20 14% ` Martin Dowie
1 sibling, 0 replies; 67+ results
From: Ludovic Brenta @ 2007-05-14 20:14 UTC (permalink / raw)
Anh Vo writes:
> Ada.Assertions package (AI-286 implemented by Martin Dowie) is part of
> Ada 2005 core packages as indicated by 14.4.2(12/2). However, when
> compiling codes having "with Ada.Assertions" in the with clause, GNAT
> displays ..."Ada.Assertions" is not a predefined library unit. GNAT
> does not seem to recognize it. Should a bug report be in order?
> Thanks.
Yes, I suppose so. AdaCore claim that GNAT GPL 2007 "includes all the
core features of the Ada 2005 language revision", and I was wondering
what was the difference between a "core feature" and a "feature". It
could be that Ada.Assertions is in the latter category :)
--
Ludovic Brenta.
^ permalink raw reply [relevance 9%]
* Ada 2005 core packages under GNAT-GPL-2007
@ 2007-05-14 17:57 13% Anh Vo
2007-05-14 20:14 9% ` Ludovic Brenta
2007-05-14 20:20 14% ` Martin Dowie
0 siblings, 2 replies; 67+ results
From: Anh Vo @ 2007-05-14 17:57 UTC (permalink / raw)
Ada.Assertions package (AI-286 implemented by Martin Dowie) is part of
Ada 2005 core packages as indicated by 14.4.2(12/2). However, when
compiling codes having "with Ada.Assertions" in the with clause, GNAT
displays ..."Ada.Assertions" is not a predefined library unit. GNAT
does not seem to recognize it. Should a bug report be in order?
Thanks.
AV
^ permalink raw reply [relevance 13%]
* Re: [Ann] More Ada0Y packages for Ada95!
2004-07-31 17:08 11% ` Martin Dowie
@ 2004-08-02 16:31 0% ` Anh_Vo
0 siblings, 0 replies; 67+ results
From: Anh_Vo @ 2004-08-02 16:31 UTC (permalink / raw)
"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message >
>
> > I would like to make a suggestion regarding exception handler. It
> > would be better to use Raise_Exception (E => Exception_Name'Identity,
> > "useful message") than raise Exception_Name. In fact, it is extremely
> > useful in debugging quickly where the problem comes from.
>
> Do you mean the Ada.Assertions package? Or all the packages? If you mean the
> Ada.Assertions package then they give you exactly what the AI requires. If
> you
> want a message then use the overloaded subprogram that has the "Message"
> parameter.
>
> For Ada.Directories.* I did add quite a few with messages and hopefully they
> are helpful. I think the rest are pretty bare in the exception message
> department
> but I've got time(!) I'll go back and add some where I can.
>
I meant any packages that did not have exception handlers like
Ada.Directories.* had.
^ permalink raw reply [relevance 0%]
* Re: [Ann] More Ada0Y packages for Ada95!
2004-07-30 19:50 0% ` Anh_Vo
@ 2004-07-31 17:08 11% ` Martin Dowie
2004-08-02 16:31 0% ` Anh_Vo
0 siblings, 1 reply; 67+ results
From: Martin Dowie @ 2004-07-31 17:08 UTC (permalink / raw)
"Anh_Vo" <anh_vo@udlp.com> wrote in message
news:5a59d6a9.0407301150.348121a8@posting.google.com...
> "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:<ce8pjj$7an$1@titan.btinternet.com>...
> > Martin Dowie wrote:
> > >> I've updated my web page to include the following implementations:
> > >
> > > An address mught have been handy! :-)
> > >
> > > http://www.martin.dowie.btinternet.co.uk/
> >
> > Just added AI-286 Ada.Assertions
>
> It is a great effort you are putting in.
You more than welcome - Matt has just fixed the Ada.Containers.Ordered_Sets,
so look out for an update of that real soon. :-)
> I would like to make a suggestion regarding exception handler. It
> would be better to use Raise_Exception (E => Exception_Name'Identity,
> "useful message") than raise Exception_Name. In fact, it is extremely
> useful in debugging quickly where the problem comes from.
Do you mean the Ada.Assertions package? Or all the packages? If you mean the
Ada.Assertions package then they give you exactly what the AI requires. If
you
want a message then use the overloaded subprogram that has the "Message"
parameter.
For Ada.Directories.* I did add quite a few with messages and hopefully they
are helpful. I think the rest are pretty bare in the exception message
department
but I've got time(!) I'll go back and add some where I can.
Cheers
-- Martin
^ permalink raw reply [relevance 11%]
* Re: [Ann] More Ada0Y packages for Ada95!
2004-07-28 18:00 9% ` Martin Dowie
@ 2004-07-30 19:50 0% ` Anh_Vo
2004-07-31 17:08 11% ` Martin Dowie
0 siblings, 1 reply; 67+ results
From: Anh_Vo @ 2004-07-30 19:50 UTC (permalink / raw)
"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:<ce8pjj$7an$1@titan.btinternet.com>...
> Martin Dowie wrote:
> >> I've updated my web page to include the following implementations:
> >
> > An address mught have been handy! :-)
> >
> > http://www.martin.dowie.btinternet.co.uk/
>
> Just added AI-286 Ada.Assertions
>
> Cheers
>
> -- Martin
It is a great effort you are putting in.
I would like to make a suggestion regarding exception handler. It
would be better to use Raise_Exception (E => Exception_Name'Identity,
"useful message") than raise Exception_Name. In fact, it is extremely
useful in debugging quickly where the problem comes from.
AV
^ permalink raw reply [relevance 0%]
* Re: [Ann] More Ada0Y packages for Ada95!
@ 2004-07-28 18:00 9% ` Martin Dowie
2004-07-30 19:50 0% ` Anh_Vo
0 siblings, 1 reply; 67+ results
From: Martin Dowie @ 2004-07-28 18:00 UTC (permalink / raw)
Martin Dowie wrote:
>> I've updated my web page to include the following implementations:
>
> An address mught have been handy! :-)
>
> http://www.martin.dowie.btinternet.co.uk/
Just added AI-286 Ada.Assertions
Cheers
-- Martin
^ permalink raw reply [relevance 9%]
* Re: Assertions
@ 1999-05-13 0:00 11% ` Nick Roberts
0 siblings, 0 replies; 67+ results
From: Nick Roberts @ 1999-05-13 0:00 UTC (permalink / raw)
I would suggest that a pragma Assert expands to something like the
following:
if not boolean_expression then
Ada.Exceptions.Raise_Exception(
Ada.Assertions.Assert_Failure'Identity,
"Test expression evaluated to False in a pragma Assert." & NL &
"Page: " & Page & "Line: " & Line & NL &
"File: " & Source_File_Name & NL &
[""|string_expression]);
end if;
where NL is the implementation's code for a line break. Then there should be
a package:
package Ada.Assertions is
Assert_Failure: exception [renames lower_level_exception];
end;
I think it's also got to be made explicit that if a pragma Assert in the
place of a declaration---in the declarative region of a certain
block---raises an exception, that exception must be immediately propagated
out of the block (and can never be handled inside the block). I would also
suggest the following points.
1. There's no reason why the compiler should not be able to assume that any
assertion's condition holds true, regardless of whether assertion checking
is turned on or off. This would obviously be highly desirable, since, in
many cases, it would allow optimising compilers to make optimisations they
otherwise could not. The situation is analogous to other checks: if a check
is turned off, and consequently an exception fails to be raised, the
program's behaviour is undefined, and possibly highly erratic; if
Assertion_Check is on (the default) the failure of an assertion's condition
will always raise an exception (so the condition will certainly always hold
as a post condition).
2. I don't see why assertions should not be allowed to have side-effects.
Whether it would be wise, in practice, for an assertion to have side effects
is another matter (to be left to the 'wisdom' of the programmer ;-).
3. If Assertion_Check is turned off, but the compiler can nevertheless
detect (at compile time) that an assertion's condition will always fail (be
False), it should still be entitled to raise an exception. Again, this is
analogous to the other checks. In theory, the compiler should be entitled to
continue checking any assertions it fancies.
4. A pragma Assert must not be evaluated by the elaboration of a
preelaborated library unit.
-------------------------------------
Nick Roberts
-------------------------------------
^ permalink raw reply [relevance 11%]
* Re: The Red Language
[not found] <340E2DC5.25D7@worldnet.att.net>
@ 1997-09-12 0:00 4% ` Robert A Duff
0 siblings, 0 replies; 67+ results
From: Robert A Duff @ 1997-09-12 0:00 UTC (permalink / raw)
In article <340E2DC5.25D7@worldnet.att.net>,
Michael & Amy Hartsough <Hartsough@worldnet.att.net> wrote:
>What about the "Red" language?
It's interesting, for historical reasons if nothing else.
>I recall reading somewhere (was it an Ada Letters article
>by JP Barnes? Or was it in the "History" chapter of Booch's
>Brown book?) something along the lines of, "The Red language
>contained the seed of a potentially superior language, but
>was deemed beyond the capabilities of then current compiler
>technology."
I think that's bogus. Red had some nasty holes which made it impossible
to implement, but then so did Green (and so did Ada 83, and so does Ada
95). If you read the manual assuming anything unimplementable is just
ridiculous, so they couldn't have meant that, and assuming that Red had
undergone all the language bug-fixing that Green did, I think you will
find that Red is no harder to implement than Green.
>Of course, since I'm going by rather old memory, the quote may
>have mentioned either the Blue or the Yellow language, but my
>memory does say, "Red".
I know nothing of Blue or Yellow. I've read the Red and Green manuals,
as well as various follow-ons of Green, including of course Ada 83 and
Ada 95.
>So. Would the Red language be "doable" with today's compiler
>technology?
Yes, given certain bug fixes.
>... Would it (might it) be superior to present-day
>languages?
In some ways, perhaps, but not overall, IMHO. Ada has gone a long ways
since those days. So have lots of other languages.
>Or do we already HAVE the Red language in our midst?
>(Red = Intermetrics = STT = Ada95) ;^)
The Ada 9X team did not pay a whole lot of attention to Red. I had read
the Red manual. Probably Tucker had, too, but Tucker started working at
Intermetrics after Green was chosen to be Ada. Lots and lots of
languages had some influence on Ada 95.
>From where can I obtain a draft of the Red language?
Beats me. Maybe Ben Brosgol knows. I have a paper copy...
In most ways, Red and Ada are similar, which is not surprising, since
they both came out of the same Steelman requirements, and they were both
(very roughly) based on Pascal.
Interesting things about Red:
Its modules are called "capsules" (not "packages"). Capsules are given
in one piece, not spec-vs-body. (Note recent
mountains-out-of-mole-hills thread about Eiffel classes vs Ada
packages.)
Capsules can be "invoked" as either "old" or "new". "Old" is sort of
like an Ada with_clause. "New" is sort of like an Eiffel class, in that
it creates a new copy of that capsule (but not like an Eiffel class in
many other ways, of course.)
No underscores in numeric literals. I really like Ada's ability to say
1_000_000, rather than 1000000, and I don't understand why many people
on't use it. Red doesn't allow it.
Enumeration literals are syntactically distinguished (preceding quote).
Every enum type is essentially a character type.
You can declare variables locally within any sequence of statements
without introducing a declare block.
Forward references are allowed to procedures and capsules and so forth,
but not to variables and constants and so forth. (Again, check out the
recent arguments re: Eiffel vs Ada.)
Assertions (similar in semantics to GNAT's pragma Assert).
Imports clauses -- you have so say what you import, as well as what you
export. This applies to nested things like procedures, unlike Ada.
Parameter passing semantics is nailed down. (E.g. the programmer
chooses whether pass-by-ref-read-only vs. pass-by-copy-read-only is
used.)
Strings always start at 1.
You can redefine "=" and "<", and then "/=", ">", "<=", ">=" follow.
Ada does this for "/=", but not the others. In Red, redefining the
latter four is illegal.
if <statically-false-expression> then
<something-illegal>
end if;
is a warning, not an error. Similarly for case statements. I guess
this is their take on conditional compilation.
Weaker overload resolution rules (than Ada). Eg no top-down resolution,
except in limited cases. Function result types not considered for
resolution. But enum lits can be overloaded (and there's no pretense
that they're functions).
More user-defineable stuff. Like literal notation, array indexing and
slicing notation, dot-selection notation, etc. One can redefine the
meaning of case statements and for loops, for a given type.
Case statements are more general than in Ada. The when's don't need to
be static. So you can say something like:
case True is
when Foo(...) => ...;
when Bar(...) => ...;
end case;
where Foo and/or Bar might return True. If more than one alternative
matches, then the choice is arbitrary!
Function return of caller-unknown-size values is not allowed in Red.
No named-notation parameters.
User-defined finalization.
User-defined assignment.
Generics: Capsules and subprograms can be generic, but so can types.
Generic instantiation is implicit. (See recent thread arguing about the
readability of such a feature. The examples in the Red manual look
pretty readable to me, in this regard.)
Tasking uses lower-level primitives (than Ada). Eg mailboxes.
Delay-until statement.
User-defined scheduling.
Garbage collection seems to be expected. Unchecked_Deallocation raises
an exception on error, but this can be suppressed.
Uninitialized variables detected at run time.
One suppresses *exceptions* (not checks). The predefined exceptions are
at a finer granularity than in Ada (which conflates many things under
Constraint_Error, for example). Green was like Red in this respect
(i.e. Green had one exception for each "check" defined in 11.7, more or
less).
And lots of other stuff.
It's hard for me to judge Red, since I tend to compare it to Ada as it
is today, rather than Green as it was then, which is rather unfair.
Some of it seems better than Ada, some of it seems worse. I would
particularly miss named-notation parameters, for example.
- Bob
^ permalink raw reply [relevance 4%]
* Re: Safety-critical development in Ada and Eiffel
1997-07-12 0:00 14% ` Ken Garlington
@ 1997-07-15 0:00 13% ` Don Harrison
1997-07-15 0:00 0% ` Ken Garlington
0 siblings, 1 reply; 67+ results
From: Don Harrison @ 1997-07-15 0:00 UTC (permalink / raw)
Ken Garlington wrote:
:Don Harrison wrote:
:>
:> If even this small overhead is unacceptable, you can force static binding
:> where necessary by freezing routines.
:> Although you forgo the flexibility of
:> polymorphism, you can still take advantage of inheritance by virtue of Eiffel
:> synonyms - these allow you to declare a routine under different names.
:
:But I can do this in Ada, as well, so I don't see the benefit.
I'm not saying there is any extra benefit - merely that you don't have to
wear the overhead of dynamic binding if you're desperate to maximise efficiency.
Tucker mentioned that overhead. I'm saying it isn't an issue.
BTW, how do call a procedure under different names in Ada?
: :Does this "pre-allocated memory pool" mean that you will know exactly
:> :what address
:> :each object's data will reside at, or merely that you dynamically
:> :allocate memory
:> :at initialization and do not dynamically allocate after initialization
:> :is complete?
:>
:> The latter. You don't actually need to know *where* objects are allocated,
:> merely that there is sufficient memory to allocate them.
:
:Actually, in my systems, I do need to know where they are allocated, so
:that
:I can examine them from the hideously crude display in the cockpit
:during
:troubleshooting.
That *is* hideously crude (and brings back some bad memories). Depending on how
crude you mean, maybe a primitive tool could give you a map of where objects get
put in memory. If you mean incredibly crude, use non-reference (expanded in
Eiffel) types and use a linker-generated memory map.
:> Maybe general assertions are more common than you imagine. However, I agree
:> that range constraints are roughly covered by Ada subtypes. I use them liberally
:> for just that purpose.
:
:Maybe, but again, I would like to see how these complex assertions are
:used.
You would use them anywhere that a piece of code makes assumptions. For example,
to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
you apply Ariane 5 dynamics to it.
:Again, the code I've seen to date doesn't seem to use them that much.
If you're looking in Ada code, you're looking in the wrong place because few
Ada developers recognise there are additional benefits from using them in
addition to static typing and the predefined contracts already in Ada
(the conditions under which predefined exceptions - eg. Constraint_Error -
are raised).
Static typing gives you static contract checking. Assertions (predefined and
user-defined give you dynamic contract checking *during development*. What
most Ada software engineers miss out on is the user-defined variety which
bring a non-trivial benefit to reliability and reuse.
:> Correct me I misunderstand you.. Are you wondering whether contracting
:> helps you to identify more bugs? I can offer my own experience which has
:> firmly convinced me of this.
:
:Contracting definitely identifies more bugs. However, my concern with
:Eiffel
:assertions (and Ada assertions, for that matter) is that, once raised,
:it's
:not always clear what to do about them.
They are only turned on during development, so what you do is fix the underlying
problem which is usually not difficult to find if you've used them systematically.
Even if you haven't (I was the only one of a team of 5 using them in our recent
development cycle), they still tell you more than you would otherwise be told.
Good design complemented by static typing and Design by Contract is unbeatable,
IME.
:In a safety-critical system such
:as
:we build, you can't just generate a core dump, or ask the user what to
:do next.
:You have to generate a correct response to the assertion failure, and
:you have
:to do it very quickly.
Right. However, only an incorrect program will raise assertion violations at
runtime. As you systematically identify and fix the errors causing them during
development, you can turn assertions off with confidence when the system
goes live. Then, any errors you may have missed will be handled by exception
handlers in the usual way.
:Static assertion checks, of course, can be
:detected and
:corrected during development, which is why I like Ada's strong static
:type checking.
I agree completely. Static typing is great but it isn't the *whole* story.
:There is a school of thought that says to add in assertions, test the
:system, and
:then remove/suppress the exceptions. I have seen too many cases of code
:that works
:with the assertions active, and then breaks (due to timing differences,
Yes, timing *is* something to be concerned about when applied to realtime
systems. That's why I suggested not using assertions in the hard realtime
threads of a process. BTW, software designed using DBC may actually run *faster*
than code without it because you get to strip out all the defensive validity
checks. You have already ascertained during development that operations are
called in valid contexts so you don't have to check the context.
:or more
:likely code generation errors) to have much confidence in this approach.
If that's a problem, you need to get your vendor to clean their act up.
:Another consequence of using assertions is that you have to develop and
:test the
:assertions.
Correct. My initial reaction when I started using them was "Gee, I've got to
do this extra work on top of writing the "real" code! However, I found I was
spending about a third of the time integrating compared with my colleagues
which meant I was saving time overall and producing more reliable code to boot.
:As a result, you need confidence that the benefits of the
:assertions
:outweigh the dilution of your test effort.
IME, they do.
:One of the advantages of
:Ada's simpler
:approach (at least, it seems simpler to me) to simple
:pre/post-conditions (range
:checks in particular) is that the cost of adding them is somewhat
:reduced.
I disagree. It takes me about the same amount of time to specify an Ada
subtype as it does to specify a more general assertion. Even if the general
assertion is a function, I would more than likely need to write it anyway so
would have expended the effort anyway.
:However,
:in both languages, overuse of assertions may be just as bad as underuse.
It is possible to overuse them but 99% of developers err on the othger side. :)
:(As you can tell, I'm somewhat of an assertions heretic.
That's fine but have a go at using them where appropriate. I'm sure you'll
become convinced.
:However, I will
:say that
:for non-real-time, non-safety-critical systems, they are outstanding. My
:tool code
:is lousy with them.)
:
:> Consequently, when we (a team of 5) recently
:> reached the end of a 5 month long development effort of incremental coding
:> and integration testing, the parts of the system that used contracting work
:> flawlessly apart from problems resulting from misinterpretation of requirements.
:
:Most of the problems we see in formal testing are from misinterpretation
:of
:requirements - which is another issue I have with assertions as a magic
:safety wand.
No use of assertions will stop you misinterpreting requirements. They're not
a magic wand but they *will* help you remove a class of errors you would
otherwise miss.
:Of course, Bertand Meyer's Eiffel website insists that even
:misinterpretation of
:requirements (Ariane V) will be a problem no longer when Eiffel is used!
Come on. He's not saying that.
Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison donh@syd.csa.com.au
^ permalink raw reply [relevance 13%]
* Re: Safety-critical development in Ada and Eiffel
1997-07-15 0:00 13% ` Don Harrison
@ 1997-07-15 0:00 0% ` Ken Garlington
0 siblings, 0 replies; 67+ results
From: Ken Garlington @ 1997-07-15 0:00 UTC (permalink / raw)
Don Harrison wrote:
>
> Ken Garlington wrote:
>
> :Don Harrison wrote:
> :>
> :> If even this small overhead is unacceptable, you can force static binding
> :> where necessary by freezing routines.
> :> Although you forgo the flexibility of
> :> polymorphism, you can still take advantage of inheritance by virtue of Eiffel
> :> synonyms - these allow you to declare a routine under different names.
> :
> :But I can do this in Ada, as well, so I don't see the benefit.
>
> I'm not saying there is any extra benefit - merely that you don't have to
> wear the overhead of dynamic binding if you're desperate to maximise efficiency.
> Tucker mentioned that overhead. I'm saying it isn't an issue.
But you also said that it was required to use that part of Eiffel
inheritance not
available in Ada. In this statement, you seem to be saying that if I
want an
efficient safety-critical system (which I always do), I have to give us
some of
that extra inheritance. Do I need the full Eiffel inheritance model, or
don't I?
>
> BTW, how do call a procedure under different names in Ada?
Via the "rename" statement.
>
> : :Does this "pre-allocated memory pool" mean that you will know exactly
> :> :what address
> :> :each object's data will reside at, or merely that you dynamically
> :> :allocate memory
> :> :at initialization and do not dynamically allocate after initialization
> :> :is complete?
> :>
> :> The latter. You don't actually need to know *where* objects are allocated,
> :> merely that there is sufficient memory to allocate them.
> :
> :Actually, in my systems, I do need to know where they are allocated, so
> :that
> :I can examine them from the hideously crude display in the cockpit
> :during
> :troubleshooting.
>
> That *is* hideously crude (and brings back some bad memories). Depending on how
> crude you mean, maybe a primitive tool could give you a map of where objects get
> put in memory. If you mean incredibly crude, use non-reference (expanded in
> Eiffel) types and use a linker-generated memory map.
Both approaches require that the memory address be known before
execution time,
however, so I still care where objects are located. I also care for
other reasons,
such as memory-mapped I/O, of course.
>
> :> Maybe general assertions are more common than you imagine. However, I agree
> :> that range constraints are roughly covered by Ada subtypes. I use them liberally
> :> for just that purpose.
> :
> :Maybe, but again, I would like to see how these complex assertions are
> :used.
>
> You would use them anywhere that a piece of code makes assumptions. For example,
> to help avoid the Ariane fiasco, include contracts in the INS(?) that specify
> Ariane 4 dynamics. Then, in testing, you will get an assertion violation when
> you apply Ariane 5 dynamics to it.
This is why my blood pressure goes up!
The _Ada_ implementation did generate an assertion violation the very
first time
Ariane 5 dynamics were applied to it. Unfortunately, the very first time
Ariane 5
dynamics were applied to it was at LANUCH!
They were not applied earlier, because the contractor assumed that the
Ariane 5
dynamics were the same as the Ariane 4, so why spend the money testing
to the same
conditions already tested earlier? (They were wrong, of course, but they
didn't know
that at the time).
The other part of the problem was that the _response_ to the assertion
violation was
wrong. The designer assumed the assertion would occur due to a hardware
failure, not
a software requirements failure, and so the handler shut down the
"offending" hardware,
rather than attempting some other action (e.g. replacing the
out-of-range value with
a "safe" value). Frankly, I don't know that I would have written the
handler differently
myself.
This is all clearly documented in the final report, available on the
Web.
According to Meyer, et. al. Eiffel programmers would have written the
handler
differently, and also they would have known to do the testing
differently (even though
the requirements specification said that the tests need not change).
However, their
explanation as to why this is true is far from convincing (basically,
that "Eiffel
programmers believe in quality" or some such nonsense). Their "analysis"
is also
on the Web. I've asked them to post my rebuttal to their paper, but I
don't know
if they ever did.
This is why I dislike people with no background in safety-critical
flight systems discussing
such issues. They believe that "software is software." and apply the
expertise in their
domain to mine. They usually do about as good a job as when I try to
discuss compiler
design :)
>
> :Again, the code I've seen to date doesn't seem to use them that much.
>
> If you're looking in Ada code, you're looking in the wrong place because few
> Ada developers recognise there are additional benefits from using them in
> addition to static typing and the predefined contracts already in Ada
> (the conditions under which predefined exceptions - eg. Constraint_Error -
> are raised).
No - I'm looking at Eiffel code. (Why would I look at Ada code to
determine how
Eiffel is used?)
> Static typing gives you static contract checking. Assertions (predefined and
> user-defined give you dynamic contract checking *during development*. What
> most Ada software engineers miss out on is the user-defined variety which
> bring a non-trivial benefit to reliability and reuse.
Not this Ada engineer! I have dynamic assertions all over the place in
my
tools!
My problem, again, is in the fundamental nature of dynamic assertions
for safety-critical
embedded systems, which have some unique risks, whether you (a) leave
them in after
development, or (b) take them out after developmental testing, but
before usage.
>
> :> Correct me I misunderstand you.. Are you wondering whether contracting
> :> helps you to identify more bugs? I can offer my own experience which has
> :> firmly convinced me of this.
> :
> :Contracting definitely identifies more bugs. However, my concern with
> :Eiffel
> :assertions (and Ada assertions, for that matter) is that, once raised,
> :it's
> :not always clear what to do about them.
>
> They are only turned on during development, so what you do is fix the underlying
> problem which is usually not difficult to find if you've used them systematically.
> Even if you haven't (I was the only one of a team of 5 using them in our recent
> development cycle), they still tell you more than you would otherwise be told.
I am aware of at least one project developing an embedded missile
controller,
that did exactly what you describe (in Ada). Here's what happened:
1. Their timings changed, which introduced some subtle differences in
the
relationships between tasks and external interrupts. Some of these
subtle
differences invalidated their original testing.
2. Their object code changed (obviously), which required reanalysis of
their
object-code branch coverage.
3. At least one compiler bug was introduced, which was definitely
unsettling.
What safety-critical system did you develop where you turned off
assertions
afer development? What standard (DO-178?) did you use for certification?
The other prong of this is that, while assertions are keen for catching
design problems, I haven't seen much evidence that they catch high-level
requirements problems (not surprising, since the code was presumably
written
to match the requirements). In 13 years of developing safety-critical
embedded systems, our process tends to handle design problems fairly
early.
It's those high-level requirements problems where we need the most help.
>
> Good design complemented by static typing and Design by Contract is unbeatable,
> IME.
>
> :In a safety-critical system such
> :as
> :we build, you can't just generate a core dump, or ask the user what to
> :do next.
> :You have to generate a correct response to the assertion failure, and
> :you have
> :to do it very quickly.
>
> Right. However, only an incorrect program will raise assertion violations at
> runtime. As you systematically identify and fix the errors causing them during
> development, you can turn assertions off with confidence when the system
> goes live. Then, any errors you may have missed will be handled by exception
> handlers in the usual way.
>
> :Static assertion checks, of course, can be
> :detected and
> :corrected during development, which is why I like Ada's strong static
> :type checking.
>
> I agree completely. Static typing is great but it isn't the *whole* story.
>
> :There is a school of thought that says to add in assertions, test the
> :system, and
> :then remove/suppress the exceptions. I have seen too many cases of code
> :that works
> :with the assertions active, and then breaks (due to timing differences,
>
> Yes, timing *is* something to be concerned about when applied to realtime
> systems. That's why I suggested not using assertions in the hard realtime
> threads of a process. BTW, software designed using DBC may actually run *faster*
> than code without it because you get to strip out all the defensive validity
> checks. You have already ascertained during development that operations are
> called in valid contexts so you don't have to check the context.
But almost all of our safety-critical threads are hard realtime threads!
That's a HUGE limitation for our systems!
>
> :or more
> :likely code generation errors) to have much confidence in this approach.
>
> If that's a problem, you need to get your vendor to clean their act up.
Easier said than done! :)
What is the process to certify Eiffel compilers as being acceptably
mature
(code generation-wise) for safety-critical systems? Is all testing
performed
with assertions on and assertions off in all test cases?
>
> :Another consequence of using assertions is that you have to develop and
> :test the
> :assertions.
>
> Correct. My initial reaction when I started using them was "Gee, I've got to
> do this extra work on top of writing the "real" code! However, I found I was
> spending about a third of the time integrating compared with my colleagues
> which meant I was saving time overall and producing more reliable code to boot.
>
> :As a result, you need confidence that the benefits of the
> :assertions
> :outweigh the dilution of your test effort.
>
> IME, they do.
However, it sounds like you're talking about a non-safety-critical
system, and
certainly not a hard real-time embedded safety-critical systems. In that
case,
I agree. For tools, simulations, etc. I would use all of the assertions
I could.
However, what about the topic of this thread (safety-critical systems)?
It sounds
like there's a lot of limitations as to using (and inheriting)
assertions for
this environment.
>
> :One of the advantages of
> :Ada's simpler
> :approach (at least, it seems simpler to me) to simple
> :pre/post-conditions (range
> :checks in particular) is that the cost of adding them is somewhat
> :reduced.
>
> I disagree. It takes me about the same amount of time to specify an Ada
> subtype as it does to specify a more general assertion. Even if the general
> assertion is a function, I would more than likely need to write it anyway so
> would have expended the effort anyway.
>
> :However,
> :in both languages, overuse of assertions may be just as bad as underuse.
>
> It is possible to overuse them but 99% of developers err on the othger side. :)
>
> :(As you can tell, I'm somewhat of an assertions heretic.
>
> That's fine but have a go at using them where appropriate. I'm sure you'll
> become convinced.
>
> :However, I will
> :say that
> :for non-real-time, non-safety-critical systems, they are outstanding. My
> :tool code
> :is lousy with them.)
> :
> :> Consequently, when we (a team of 5) recently
> :> reached the end of a 5 month long development effort of incremental coding
> :> and integration testing, the parts of the system that used contracting work
> :> flawlessly apart from problems resulting from misinterpretation of requirements.
> :
> :Most of the problems we see in formal testing are from misinterpretation
> :of
> :requirements - which is another issue I have with assertions as a magic
> :safety wand.
>
> No use of assertions will stop you misinterpreting requirements. They're not
> a magic wand but they *will* help you remove a class of errors you would
> otherwise miss.
>
> :Of course, Bertand Meyer's Eiffel website insists that even
> :misinterpretation of
> :requirements (Ariane V) will be a problem no longer when Eiffel is used!
>
> Come on. He's not saying that.
Read his analysis of Ariane V. He says _exactly_ that, and has defended
saying that in multiple newsgroups. A smart person, but not someone
who knows my domain particularly well.
>
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison donh@syd.csa.com.au
^ permalink raw reply [relevance 0%]
* Re: Safety-critical development in Ada and Eiffel
@ 1997-07-12 0:00 14% ` Ken Garlington
1997-07-15 0:00 13% ` Don Harrison
0 siblings, 1 reply; 67+ results
From: Ken Garlington @ 1997-07-12 0:00 UTC (permalink / raw)
Don Harrison wrote:
>
> If even this small overhead is unacceptable, you can force static binding
> where necessary by freezing routines.
> Although you forgo the flexibility of
> polymorphism, you can still take advantage of inheritance by virtue of Eiffel
> synonyms - these allow you to declare a routine under different names.
But I can do this in Ada, as well, so I don't see the benefit.
:Does this "pre-allocated memory pool" mean that you will know exactly
> :what address
> :each object's data will reside at, or merely that you dynamically
> :allocate memory
> :at initialization and do not dynamically allocate after initialization
> :is complete?
>
> The latter. You don't actually need to know *where* objects are allocated,
> merely that there is sufficient memory to allocate them.
Actually, in my systems, I do need to know where they are allocated, so
that
I can examine them from the hideously crude display in the cockpit
during
troubleshooting.
> Maybe general assertions are more common than you imagine. However, I agree
> that range constraints are roughly covered by Ada subtypes. I use them liberally
> for just that purpose.
Maybe, but again, I would like to see how these complex assertions are
used. Again,
the code I've seen to date doesn't seem to use them that much.
> Correct me I misunderstand you.. Are you wondering whether contracting
> helps you to identify more bugs? I can offer my own experience which has
> firmly convinced me of this.
Contracting definitely identifies more bugs. However, my concern with
Eiffel
assertions (and Ada assertions, for that matter) is that, once raised,
it's
not always clear what to do about them. In a safety-critical system such
as
we build, you can't just generate a core dump, or ask the user what to
do next.
You have to generate a correct response to the assertion failure, and
you have
to do it very quickly. Static assertion checks, of course, can be
detected and
corrected during development, which is why I like Ada's strong static
type checking.
There is a school of thought that says to add in assertions, test the
system, and
then remove/suppress the exceptions. I have seen too many cases of code
that works
with the assertions active, and then breaks (due to timing differences,
or more
likely code generation errors) to have much confidence in this approach.
Another consequence of using assertions is that you have to develop and
test the
assertions. As a result, you need confidence that the benefits of the
assertions
outweigh the dilution of your test effort. One of the advantages of
Ada's simpler
approach (at least, it seems simpler to me) to simple
pre/post-conditions (range
checks in particular) is that the cost of adding them is somewhat
reduced. However,
in both languages, overuse of assertions may be just as bad as underuse.
(As you can tell, I'm somewhat of an assertions heretic. However, I will
say that
for non-real-time, non-safety-critical systems, they are outstanding. My
tool code
is lousy with them.)
> Consequently, when we (a team of 5) recently
> reached the end of a 5 month long development effort of incremental coding
> and integration testing, the parts of the system that used contracting work
> flawlessly apart from problems resulting from misinterpretation of requirements.
Most of the problems we see in formal testing are from misinterpretation
of
requirements - which is another issue I have with assertions as a magic
safety wand.
Of course, Bertand Meyer's Eiffel website insists that even
misinterpretation of
requirements (Ariane V) will be a problem no longer when Eiffel is used!
:)
^ permalink raw reply [relevance 14%]
* Re: Papers on the Ariane-5 crash and Design by Contract
@ 1997-03-25 0:00 9% ` Ken Garlington
0 siblings, 0 replies; 67+ results
From: Ken Garlington @ 1997-03-25 0:00 UTC (permalink / raw)
Bertrand Meyer wrote:
>
> which anyone can see is significantly different ("language and method",
> and "probably yes", with caveats about the risk of inferences, and a
> careful point-by-point discussion to examine the reasons for the
> assumption).
So, for those of us who have posted a detailed rebuttal on your
"language
and method" (both presumably being required, based on the word "and")
being
able to "probably" solve the Ariane 5 problem, what are you saying? You
disagree, for the reasons cited in your paper? Or do you care to address
the rebuttals?
Like ships passing in the night :)
> >>> (read it, and if you think they say "this wouldn't
> >>> have happened if they'd used Eiffel", read it again ;-)
>
> I think the last two lines are good advice...
Having done this, I have come to the following conclusions:
The paper indicates that Eiffel, when used with Design by Contract,
would "probably" have prevented the Ariane 5 disaster.
a. As a result, it is incorrect to claim that Design by Contract
alone would solve the problem.
b. Furthermore, the reasoning that the combination of Design by
Contract
and Eiffel would have prevented the Ariane 5 disaster is
unconvincing.
It fails to address (and is some cases contradicted by) the final
report, and is unconvincing to those with experience in this type
of
system. See my previous posts for more information.
c. The paper also contains some material that is extraneous to the
issue
of the Ariane 5 accident. Although not by itself a fatal flaw, it's
annoying. (I haven't really commented on this previously, but it is
strange for example that the paper admits Ada assertions were
adequate for
the Ariane 5 issue, but goes on to explain how much more powerful
Eiffel assertions can be. What's the point, other than selling
Eiffel?)
>
> [In the quotations I have reinstituted the spelling of my name,
> of Jean-Marc Jezequel's, and of Ariane.]
> --
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
> ftp://ftp.eiffel.com
> Visit our Web page: http://www.eiffel.com
> (including instructions to download Eiffel 4 for Windows)
--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com
^ permalink raw reply [relevance 9%]
* Re: Papers on the Ariane-5 crash and Design by Contract
1997-03-20 0:00 0% ` Jean-Marc Jezequel
@ 1997-03-24 0:00 11% ` Ken Garlington
0 siblings, 0 replies; 67+ results
From: Ken Garlington @ 1997-03-24 0:00 UTC (permalink / raw)
Jean-Marc Jezequel wrote:
>
> Yes, that's true for pre- and post that actually correspond to range
> constraints. But remember that Eiffel pre- and post can be much more general
> than that, including any arbitrary function call.
> Also, how do you check/inherit your class invariants in Ada?
> (this is a real question, I really don't know whether it is possible)
Does any of this have anything to do with the Ariane 5 crash? Your own
paper
says that Ada assertions were adequate in this case.
> In general, this may be true. But in this particular Ariane 501 crash, I maintain
> that such "stuff" would have been enough, for a team fully embrassing design by contract,
> to specify this particular assumption.
*Specifically* for the Ariane 501 crash, I disagree (as do others). I
even went so
far as to quote sections of the Ariane 501 final report that dispute
your
belief, rather than just relying on my own experience in building
similar systems.
Do you wish to respond?
> I know that humans can fail, but I'm confident that, given enough ressources (and
> avoiding a 500M$ crash gives you some leeway) it could have been succesful.
> You may disagree on this point, and we can stop this discussion by agreeing to disagree.
Apparently, you do not wish to respond. It would be interesting to see
this
subject addressed in a referreed paper, rather than only in Mr. Meyer's
opinion
column and on a web page. Too bad there's not a way to post permanent
responses
to a web page... given the presence of Mr. Meyer's name, I'm sure it
will be
quoted as an "authoritative" source on how assertions would have
prevented this crash.
It's times like this that I really hate software engineering. To think
that such
gibberish could ever see the light of day in a respected software
engineering magazine!
>
> In the light of their very constructive posts and mails, I concede to Ken Garlington and
> Paul Dietz that re-testing of the SRI in the context of the Ariane5 trajectory would
> not have been as hard as I have thought initialy. But in any case, the solution they propose
> would have broken the idea of a black-box (integrating all the inertial hardware and software)
> reuse, since you have to enter the black box to "feed simulated accelerometer signals into the
> rest of the system".
This is a routine test for such systems. I have no idea what your issue
is here. I
assume your main problem is that it would have detected the error either
with or
without assertions, thus making it difficult to say that Design by
Contract (i.e.,
Eiffel) would have been a better choice.
> OK, I admit this is a bit of dialectics, but it still illustrates one of the
> main point of the paper: beware of black-box reuse (aka component reuse), when the specification
> is limited to routine signatures (a la CORBA).
I would go further: beware of black-box reuse REGARDLESS of the richness
of the
specification, particularly for critical systems.
>
> --
> Jean-Marc Jezequel Tel : +33 2 99847192
> IRISA/CNRS Fax : +33 2 99847171
> Campus de Beaulieu e-mail : jezequel@irisa.fr
> F-35042 RENNES (FRANCE) http://www.irisa.fr/pampa/PROF/jmj.html
--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com
^ permalink raw reply [relevance 11%]
* Re: Papers on the Ariane-5 crash and Design by Contract
1997-03-19 0:00 0% ` Jon S Anthony
@ 1997-03-20 0:00 0% ` Paul Johnson
1997-03-20 0:00 0% ` Jean-Marc Jezequel
1 sibling, 0 replies; 67+ results
From: Paul Johnson @ 1997-03-20 0:00 UTC (permalink / raw)
jsa@alexandria (Jon S Anthony) wrote:
>In article <5gp3hd$i0l@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>> The major difference between C/C++/Ada assertions and Eiffel style
>> design-by-contract is that in the latter, the assertions are part of
>> the interface, not just embedded in the implementation.
>Well, in this particular sort of case, your claim here is not correct
>for Ada:
>subtype Bias_Constraint is Integer range Min_Bias..Max_Bias;
>
>function Convert ( High_Bias : Bias_Constraint ) return Integer;
>
>
>The asserstion is part of the interface, NOT the implementation.
Yes, but this doesn't help. Sure, the range limit is in the interface
to the conversion routine, but there is no way (other than comments)
to propogate that limit into the interfaces of its callers, and no
methodological rule that says you should.
The point about Eiffel is not merely that it has the syntax to express
these limits, but that it also has the rules and "programmer culture"
that causes these mechanisms to be used routinely. This might well
have caused the limit in question to documented at a high enough level
to have been noticed by whoever it was that decided to re-use the Ariane
4 inertial guidance system. Its not certain, but its a lot more likely.
The report said that the limits *were* documented (commented I think)
in the code, but this was essentially invisible to any kind of management
oversight. Had the limitation been propogated to a high level interface
then its more likely that someone would have noticed.
Having said that, I must admit that this exception was caused by a high
horizontal speed sensed by the unit, rather than external data which
violated preconditions. Hence the restriction would not have appeared
at the API level for the sensor.
Paul.
--
Paul Johnson | GEC-Marconi Ltd is not responsible for my
opinions. |
+44 1245 242244
+-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com> | You are lost in a twisty maze of
little
Home: <Paul@treetop.demon.co.uk> | standards, all different.
^ permalink raw reply [relevance 0%]
* Re: Papers on the Ariane-5 crash and Design by Contract
1997-03-19 0:00 0% ` Jon S Anthony
1997-03-20 0:00 0% ` Paul Johnson
@ 1997-03-20 0:00 0% ` Jean-Marc Jezequel
1997-03-24 0:00 11% ` Ken Garlington
1 sibling, 1 reply; 67+ results
From: Jean-Marc Jezequel @ 1997-03-20 0:00 UTC (permalink / raw)
In article <JSA.97Mar19144933@alexandria>, jsa@alexandria (Jon S Anthony) writes:
>In article <5gp3hd$i0l@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>> >Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>> >using #include <assert.h> for years? Software engineers have been using
>> >assert macros to verify program limits are not exceeded.
>> The major difference between C/C++/Ada assertions and Eiffel style
>> design-by-contract is that in the latter, the assertions are part of
>> the interface, not just embedded in the implementation.
>Well, in this particular sort of case, your claim here is not correct
>for Ada:
>subtype Bias_Constraint is Integer range Min_Bias..Max_Bias;
>
>function Convert ( High_Bias : Bias_Constraint ) return Integer;
>The asserstion is part of the interface, NOT the implementation.
>Further, to answer a point of Jean's, it will be inherited in any
>appropriate derivation case. And certainly we could do the same for
>the post condition (the return subtype).
Yes, that's true for pre- and post that actually correspond to range
constraints. But remember that Eiffel pre- and post can be much more general
than that, including any arbitrary function call.
Also, how do you check/inherit your class invariants in Ada?
(this is a real question, I really don't know whether it is possible)
>Now, as John McCabe, Ken Garlington, myself and others have pointed
>out, none of this was (or is in any sense likely to be) sufficient to
>prevent the type of error exhibited by this example. The required
>semantic context (scope of use, intended behavior, presumed
>environment, etc) is far to rich and complex to be dealt with by such
>rudimentary simple minded stuff as pre and post conditions on
In general, this may be true. But in this particular Ariane 501 crash, I maintain
that such "stuff" would have been enough, for a team fully embrassing design by contract,
to specify this particular assumption. By the mere definition of design by contract,
they should have done this. Then, with the process explained in another of my posts,
the constraint (along with many, many others) would have propagated to the boundaries of
the SRI module, as a constraint on the environment where the module could be reuse.
I would expect that you could agree with me on that, because it is just a bare bone application
of design by contract. What I concede you (Jon), is that the set of assertions
emerging at the SRI module level could have been so complex that it would have made
verification in the context of Ariane5 very costly in human ressources.
I know that humans can fail, but I'm confident that, given enough ressources (and
avoiding a 500M$ crash gives you some leeway) it could have been succesful.
You may disagree on this point, and we can stop this discussion by agreeing to disagree.
In the light of their very constructive posts and mails, I concede to Ken Garlington and
Paul Dietz that re-testing of the SRI in the context of the Ariane5 trajectory would
not have been as hard as I have thought initialy. But in any case, the solution they propose
would have broken the idea of a black-box (integrating all the inertial hardware and software)
reuse, since you have to enter the black box to "feed simulated accelerometer signals into the
rest of the system". OK, I admit this is a bit of dialectics, but it still illustrates one of the
main point of the paper: beware of black-box reuse (aka component reuse), when the specification
is limited to routine signatures (a la CORBA).
>signatures. *THE* most alarming aspect of this entire discussion is
>that many, including folks the caliber of Meyer and Jezequel, don't
Thanks for putting me on the same level as B. Meyer. I'm feeling flattered;-)
--
Jean-Marc Jezequel Tel : +33 2 99847192
IRISA/CNRS Fax : +33 2 99847171
Campus de Beaulieu e-mail : jezequel@irisa.fr
F-35042 RENNES (FRANCE) http://www.irisa.fr/pampa/PROF/jmj.html
^ permalink raw reply [relevance 0%]
* Re: Papers on the Ariane-5 crash and Design by Contract
@ 1997-03-19 0:00 11% ` Fergus Henderson
0 siblings, 0 replies; 67+ results
From: Fergus Henderson @ 1997-03-19 0:00 UTC (permalink / raw)
rkaiser@dimensional.com (Richard Kaiser) writes:
>Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>using #include <assert.h> for years? Software engineers have been using
>assert macros to verify program limits are not exceeded.
The major difference between C/C++/Ada assertions and Eiffel style
design-by-contract is that in the latter, the assertions are part of
the interface, not just embedded in the implementation.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [relevance 11%]
* Re: INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
@ 1997-03-19 0:00 0% Tokoro, David
0 siblings, 0 replies; 67+ results
From: Tokoro, David @ 1997-03-19 0:00 UTC (permalink / raw)
Please REMOVE me from this mailing list.
Thanks,
David M.Tokoro
***************************************
Business Systems Branch N318
Phone: (619) 553-2707
E-mail: tokoro@nosc.mil
***************************************
>----------
>From: Automatic digest processor[SMTP:LISTSERV@LISTSERV.NODAK.EDU]
>Sent: Wednesday, March 19, 1997 1:47 PM
>To: Recipients of INFO-ADA digests
>Subject: INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>
>There are 26 messages totalling 1002 lines in this issue.
>
>Topics in this special issue:
>
> 1. Tasking In Ada 83 "Question"
> 2. Do I Really Need A Supervisor? (2)
> 3. Access to primitive operations of tagged types
> 4. Papers on the Ariane-5 crash and Design by Contract (6)
> 5. CRC in Ada? (5)
> 6. Static variables?
> 7. UNIX Texteditor for GNAT Ada95 3.07
> 8. floating point problem (2)
> 9. Ada Sockets
> 10. Gnat 3.04a for 95 wierdness
> 11. Random Numbers
> 12. Please do not start a language war (was Re: Papers on the Ariane-5 crash
> and Design by Contract
> 13. Ariane-5: can you clarify? (Re: Please do not start a language war)
> 14. need free compiler
> 15. numerical libraries
>
>----------------------------------------------------------------------
>
>Date: Tue, 18 Mar 1997 19:50:19 -0600
>From: "James A. Squire" <m193884@CSEHP1.MDC.COM>
>Subject: Re: Tasking In Ada 83 "Question"
>
>In article <332F3050.74B8@mccabe.com>,
>Michael Ibarra <ibarra@mccabe.com> wrote:
>>I have a task, and I want to perform some action when I know that my
>>task has terminated. I can't tell when it has terminated. My task
>>looks something like:
>>
>>Task Body timer is
>>begin
>>loop
>> select
>> accept receive_call do
>> null;
>> end receive_call;
>> or
>> terminate;
>> end select;
>>end loop;
>>end timer;
>>
>>My problem is that in order to check the terminated attribute of the
>>task, I need to with the package that is parent/master to the task,
>>therefore preventing it from becoming terminated.
>
>I don't quite understand this statement. If the task is pretty much
>like you have it there, withing it's parent seems to have absolutely
>nothing to do with preventing it from becoming terminated. Or else
>I don't have enough information here.
>
>It seems to me that what prevents this task from terminating is the
>mere fact that the program is still running, since the only way it
>terminates (apart from some other task aborting it or an exception
>being raised from within) is when all other tasks including the main
>task are finished - hence when the program is finished. There is no
>stop entry, and the loop is endless. The terminate statement only
>ensures that the program won't be left hanging if every other task
>is finished.
>
>>This is NEVER true. Is there any way that I can konw when this task
>>has terminated. I wanted to perform some jobs ONLY after this task
>>is terminated.
>
>If you want to do anything after such a task terminates, then you'll
>have to pick some other way for the task to terminate, it seems to
>me. The options I'm aware of are: (1) adding a Stop entry, (2) adding
>some condition that exits the loop, (3) abort the task. It looks like
>(2) is closest to what you are looking for since you are treating
>termination of this task as if it is non-deterministic to the other tasks
>in your program.
>
>Either that or you need to give us more info.
>--
>James Squire mailto:m193884 no junk mail allowed@csehp1.mdc.com
>MDA Avionics Tools & Processes
>McDonnell Douglas Aerospace http://www.mdc.com/
>Opinions expressed here are my own and NOT my company's
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 14:22:59 -0500
>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>Subject: Re: Do I Really Need A Supervisor?
>
><<Obviously people have some complaints here. You've only
>responded with a remark aimed (obviously) to intimidate.>>
>
>Well I understand that some people regard the idea of strong management
>as intimidating, and that's fine, different people work in different ways.
>All I am saying is that as far as I am concerned strong management is
>essential to software quality. Even in such a minor aspect as coding
>standards, if you have a bunch of "I don't need no stinkin' supervisor"
>hackers, you will have trouble solving even this trivial problem (of
>requiring consistent surface syntax).
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 23:34:25 GMT
>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>Subject: Re: Access to primitive operations of tagged types
>
>In article <hkbmg5.2h2.ln@localhost> njt@sv1pc161.cs.york.ac.uk (Nigel J.
>Tracey) writes:
>
>> My problem is however that I cannot pass an access to the callback
>> functions when installing the callback routine in X. The Ada RM
>> states that a dereference of an access-to-subprogram value is never
>> a dispatching call.
>
>Make the "access" registered functions non dispatching, make them
>private (or better yet in a body), and have them _call_ their
>appropriate dispatchable operation.
>
>/Jon
>--
>Jon Anthony
>Organon Motives, Inc.
>Belmont, MA 02178
>617.484.3383
>jsa@organon.com
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 20:57:14 GMT
>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>In article <5gll90$2qu$1@news.irisa.fr> jezequel@irisa.fr (Jean-Marc
>Jezequel)
>writes:
>
>> To answer Jon S Anthony, yes, all that could have been done in Ada using:
>> function Convert ( Horizontal_Bias: Integer ) return Integer is
>> subtype Bias_Constraint is Integer range 0..Maximum_Bias;
>> Require : Bias_Constraint := Horizontal_Bias;
>>
>> Ada's subtype declarations are a kind of contract, that could be
>> documented as such. Design by contract is not specific to
>> Eiffel. You can do it with any language, just because it is a way of
>> designing! Eiffel is, however, one of the few languages that provide
>> built-in support for it.
>
>You miss my point. Which is that this stuff is NOT sufficient to have
>prevented this error. And further, the evidence supports this
>position because the language used in fact _does_ have this capability
>but it was _not_ used. While design by contract is a good first step,
>it _too_ is simply insufficient as currently realized. It in no way
>captures any of the semantic context that scopes the usage scenarios
>that are assumed in the design and implementaion of "components".
>
>
>> Let's finally sum up what I perceive as the most important claims in
>> this paper:
>> - reusing a component without checking its full
>> specification is dangerous, which means that simple minded
>> CORBA-like approaches at building components for mission-critical
>> software are doomed.
>
>Agreed, but this too is simply way too simplistic. If "full
>specification" simply means signatures and their pre and post
>condition requirements, it does not capture the "full" scope of the
>problem. If it does include the various semantic aspects associated
>with "components", it is not and, what is more, _cannot_ be captured
>in signatures and assertions.
>
>
>> - using design by contract is an interesting
>> way to specify the behavior of a component
>
>Yes, but _only_ a rather _limited_ aspect. It is clearly better than
>nothing, but alone it could not prevent the sort of problem being
>discussed.
>
>
>> - at least in the case of
>> Ariane 501, simple assertions (a la Eiffel and other languages)
>> would have been expressive enough to specify the fatal hidden
>> assumption.
>
>This I simply don't believe. And the evidence does not support it
>either.
>
>
>/Jon
>--
>Jon Anthony
>Organon Motives, Inc.
>Belmont, MA 02178
>617.484.3383
>jsa@organon.com
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 21:26:00 -0600
>From: Michael & Amy Hartsough <Hartsough@WORLDNET.ATT.NET>
>Subject: Re: CRC in Ada?
>
>Robert Dewar wrote:
>> Michael said
>> <<I instantiated Sequential I/O with an unsigned 8-bit type>>
>>
>> OUCH! Sequential_IO is intended to be used for logical record I/O.
>> I can see that one might be tempted to write non-portable code that
>> (mis)used Sequential_IO in this manner in Ada 83 if you felt compelled
>> to use the Ada 83 IO packages, instead of the more obvious choice of
>> using C packages for a case like this (Ada 83 really lacked stream io,
>> and in a case like this, which is obviously a case for stream io, the
>> proper response in my view is to interface to C, rather than misuse
>> the Ada packages).
>
>I had been directed to implement CRC32 in Ada 83, and test its output against
>the output of a C++ version of the algorithm. As soon as testing was
>completed
>the CRC32 code (sans file I/O) was lifted out of the test program and
>inserted
>into an existing embedded application that reads data from a PCMCIA card.
>
>So yes, I DID feel compelled to use an Ada 83 I/O package. I don't think my
>employer would have much appreciated my spending half a day chasing down
>some C file I/O routines to improve the throughput of my test program.
>
>> It is not at all surprising
>> that you would see the peformance difference, and it says nothing
>> about Ada-vs-C performance.
>
>Certainly not Ada versus C, but definitely one compiler versus another
>compiler.
>Pick your I/O package and your language, and 18 minutes versus 27 seconds to
>read
>the same file certainly tells you something. HIS compiler (which happens to
>be
>C++) has buffered file I/O. MY compiler (which happens to be Ada 83) does not
>buffer file I/O.
>
> Michael
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 21:57:05 -0600
>From: Ray McVay <bmcvay@ARLINGTON.NET>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>John McCabe wrote:
>>
>> Bertrand Meyer <bertrand@eiffel.com> wrote:
>>
>> >The real problem was that the assertion was not part of the software.
>>
>> No - the real problem was that the developers were _not_ provided with
>> Ariane 5 trajectory information which should have been used in the
>> analysis.
>>
>> Best Regards
>> John McCabe <john@assen.demon.co.uk>
>
>Finally! Thank you, sir. It was obvious from reading the report that
>was pointed out several months ago by a post in this newsgroup that this
>was a wonderful example of a failure WAY early in the lifecycle. It had
>nothing to do with design or construction and everything to do with a
>bogus specification. They were in effect designing a control system for
>a completely different rocket than the one in which the system was used!
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 19:49:37 -0800
>From: nasser@APLDBIO.COM
>Subject: Re: Do I Really Need A Supervisor?
>
>In article <332E163F.5EFD@earthlink.net>, antialias@earthlink.net says...
>>
>>Oh, heck, maybe it didn't belong on comp.lang.ada, but this
>>IS the kind of software engineering environment that Ada
>>software is developed in...
>
>it is unfortunate to the Ada language that it happened to be
>mostly used in environments where zillion levels of managements
>and entrenched beaucracy (sp?) is the norm, this environment is a
>turn off for many programmers who would love otherwise to program
>in Ada but are wary of the surrounding working climate where Ada
>is used.
>
>Nasser
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 22:25:11 -0800
>From: nasser@APLDBIO.COM
>Subject: Re: Static variables?
>
>as Dr Dewar mentioned, package variables retain their values
>from the time the package becomes avaliable to the time the
>package life ends (usually the end of the program , but not
>always the case, example, if the package is declared inside
>a block or procedure), may be a picture will help:
>
>
>
> package A interface
> +---------------------+
> | i: integer; -----------> retain its value also
>client <=======> | procedure foo; |
> | ....... |
> +---------------------+
>
> .............................................
>
> package A body
> +---------------------+
> |j: integer; --------------> these variables retain
> | | their values
> | procedure foo is |
> | n: integer; ------------> variables here are auto
> | begin | variables, new copies are
> | .... | created each time foo is
>called
> | end foo; |
> | |
> | begin |
> | .... ----------------> this code execute once when
> | end A; | package is first elaborated.
> | | use this code to init package
> +---------------------+ variables.
>
>
>you can think of variables declared in the package interface as static puplic
>in C++ class terminolgy, and variables declared in the body of the package
>but outside the functions and procedure of the package body as static
>private in C++.
>
>offcourse it is a good idea to try to avoid using variables in the interface
>part of the package.
>
>nasser
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 10:49:11 +0100
>From: Paul Chardon <paul.chardon@AVIONS.AEROSPATIALE.FR>
>Subject: Re: UNIX Texteditor for GNAT Ada95 3.07
>
>Hello William,
>
> I have been using Emacs or Xemacs with Ada-mode for a few months and
>if ind it very good. You've got syntactycal coloring, you've got some
>options to program faster, and then if you're good in lisp (because
>Emacs uses lisp functions), you can increase the customization offered
>by emacs, as I have done. You can also compile, execute and eventually
>debug within Emacs. A lisp file for Emacs Ada-Mode Emacs is normally
>available with the Gnat.
>
> Bye, Paul.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 00:00:30 -0500
>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>Subject: Re: floating point problem
>
>Larry asks
>
><<So can anyone give an example for the Intel-challenged regarding how
>one would easily detect this float-challenged hardware at runtime in
>order to issue a nastygram ?>>
>
>The proper code is a little delicate, but is documented in the relevant
>Intel microprocessor manuals. Note that all DX chips, and of course all
>Pentiums have built-in floating-point, so this is really only a concern
>with ancient machines that you cannot purchase any longer.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 00:05:41 -0500
>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>Subject: Re: CRC in Ada?
>
>Graham says
>
><<>Sure you can read character by character, but you are paying a
>considerable
>>price, even in C, for doing so!
>
>Actually: virtually none.>>
>
>Well words like considerable and virtually are not very quantitative.
>There definitely is a price in going character by character (even Balter
>thinks this extra price might be dominant in something like "cat").
>
>Every system where I have measured the effect (e.g. the difference in
>a compiler that reads large blocks, or does character by character reads,
>I have seen enough difference to be worth the effort of doing IO in blocks.
>This is especially true if you can put a sentinel at the end of the block
>that will naturally be detected by your processing, e.g. an end-of-file
>mark of some kind in the compiler case, so that you can then process
>character by character with out a test for buffer exhaustion (once you
>commit to using getchar, you do of course have a test on each character
>read for buffer exhuastion, because at that level it is not under
>your control).
>
>GNAT actually works exactly this way, it reads the entire source with
>a single read, and then puts an end of file sentinel at the end of the
>source. This provides noticable speed up over character by character
>processing.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 12:26:09 +0000
>From: NP GOODGAME <goodganp@ASTON.AC.UK>
>Subject: Ada Sockets
>
>Is there a way to program a socket server completely in Ada 95. I'm
>using gnat as my compiler on a Sun Solaris UNIX workstation.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 05:27:55 -0800
>From: Jim Balter <jqb@NETCOM.COM>
>Subject: Re: CRC in Ada?
>
>Robert Dewar wrote:
>>
>> Jim said
>>
>> <<> If you want something equivalent to the macroized get_char, that is
>> > trivially easily programmed in C on top of stream_IO, perhaps it is
>> > a good idea for a standard package
>>
>> Since that was the original point, this whole discussion has been
>> much ado about nothing.
>> >>
>>
>> Actually I mistyped here, what I meant to say was "easily programmed
>> in Ada on top of [Ada] Stream_IO", and that is what would be a good idea
>> for a standard package.
>
>That's what I took you to mean (i.e., I misread you and thereby
>read you properly).
>
>--
><J Q B>
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 05:32:54 GMT
>From: Richard Kaiser <rkaiser@DIMENSIONAL.COM>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>In article <332E8D5D.400F@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk>
>wrote:
>>Richard Kaiser wrote:
>>
>>> The first mistake was to not put the time limit in some human readable
>>> documentation, or if the time limit was documenting then it was not read.
>>> Writing code so it documents itself reduces or eliminates the code
>>> documentation, but this can be done in Ada, EIffel, C, C++ and even
>>> assembly language and FORTRAN. These limits are part of the design
>>> and belong in a Software Requirements/Requirements Verification document
>>> and in the Version Description Document. And these documents must be
>>> reviewed prior to reuse.
>>
>>The difference between writting comments that document code, and
>>writting assertions is simple. The assertions will get tested, your
>>comments will not. I prefer to trust the latter
>
>But this software was Never tested. No end-to-end test with the hardware,
>nor
>even a software only simulation. If the testing is not performed assertions
>will not be executed to detect a problem. With proper testing the simulated
>flight would have failed with or without the assertions.
>
>>> >2) Design. Writting assertions makes design easier. This is a personal
>>> >observation and harder to justify. I find being clear about what
>>> >something does helps clear up what I am doing. Having complex
>>> >preconditions is not a good idea, again you probably don't have the
>>> >right structure.
>>>
>>> The code is going to say "I am not in my original application and may or
>>> will fail?" Assertions are only going to catch problems if there is:
>>>
>>
>>No, the code does what it is contracted to do. If you break the
>>contract, it raises an exception.
>
>But software testing "never re-read the contract".
>
>Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>using #include <assert.h> for years? Software engineers have been using
>assert macros to verify program limits are not exceeded.
>
>Richard Kaiser
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 06:03:15 -0800
>From: Jim Balter <jqb@NETCOM.COM>
>Subject: Re: CRC in Ada?
>
>Robert Dewar wrote:
>>
>> Jim said
>>
>> <<It take an unusual degree of intellectual dishonesty to misrepresent
>> one's own point. No more talk here of extra system calls,
>> buffering not being mandated, or the need to go out and empirically
>> check 6 implementations.>>
>>
>> No, sorry, you are confused, go back and check the thread, I never said
>> that there were extra system calls, that was someone else with whom I
>> disagreed!
>
>I have already quoted you as saying that a single I/O call per block
>by the *C library* (not a comment about ADA) is not guaranteed.
>
>> As for buffering being mandated, I am not quite sure what you are talking
>> about here.
>
>Sorry to here that you are having so much trouble following the thread.
>
>--
><J Q B>
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 12:54:29 GMT
>From: Larry Kilgallen <kilgallen@EISNER.DECUS.ORG>
>Subject: Re: Gnat 3.04a for 95 wierdness
>
>In article <33259a7a.22085949@news.demon.co.uk>, smoore@chowgar.demon.co.uk
>(Simon Moore) writes:
>
>> p.s. Would it be worthwhile for me to download 3.09 or are the updates
>> minimal?
>
>Ignoring Robert Dewar's specific technical response...
>
>...Any software developer will love you more if problem reports
>are from their latest offering.
>
>Even in cases where a product (not just Ada compilers) has two
>supported versions due to known glitches in the latest version,
>it is that latest version which the developer will be moving on
>to future levels, and for which they want the feedback.
>
>An exception, of course, should be made for cases where the
>defect you find has already been acknowledged by the developer
>and anything stronger than "this affects me too" might be noise.
>
>Again, this is a political rather than a technical tactic.
>You make their life easier and they will have more time to
>make your life easier. There are situations where you may
>prefer to pay a developer large amounts of money to support
>old versions, but those are rare.
>
>Larry Kilgallen
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 15:13:36 GMT
>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>Subject: Re: CRC in Ada?
>
>In article <dewar.858095506@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
>writes:
>
> > That's a pretty marginal optimization. Maybe Geert makes subtypes
> > Positive_Float, but of all the code we ever had submitted to us,
> > no one ever bothered to do this, they just used Float.
>
> > Still it can go on the list, it's way down there in priority though,
> > there are MANY more important optimizations ahead of it!
>
> Let me put an optimization way ahead of it on the list and see if
>anyone is interested...
>
> The easiest way of dealing with the A.5.1(37-42) requirements in a
>portable manner is the one currently taken by GNAT--explicit code.
>However, most of these requirements will be met by any IEEE conforming
>implementation. So it should be possible to have two versions of the
>elementary functions packages, one which assumes good underlying math
>libraries, and one which does not.
>
> Note that the hard work here can be done completely separately from
>other compiler maintenance and enhancement activities. It involves
>writing some test code and running it on a lot of different
>platforms. (The way I envision this is a set of alternate bodies, and
>a test program which validates the elisions. Of course, the ultimate
>would be a test program that generated a tailored version of the
>bodies which matched the particular hardware.)
>
>
>--
>
> Robert I. Eachus
>
>with Standard_Disclaimer;
>use Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 16:00:14 GMT
>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>Subject: Re: Random Numbers
>
>In article <dewar.858098083@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
>writes:
>
> > Don't worry, Robert Eachus is a fanatic here (he wrote the random number
> > generator) :-)
>
> A fanatic? A FANATIC? You dare to call ME a FANATIC on the subject?
>
> Well, maybe. ;-)
>
> > The orignal question came from a student writing a simple card playing
> > program, and I think you will find that the random number routines
> > are quite fine for this purpose!
>
> Oh, they are probably fine for this purpose, even if not used
>correctly. But I would hope that a student would think about the
>issues involved, even if the final decision was to ignore them.
>Learning software engineering involves both learning to recognize the
>issues, and learning to decide which potential problems can be ignored
>in the case at hand.
>
> For example, my daughter had a similar assignment involving robots
>moving one of eight directions in a limited field. Her action if the
>random next move was outside the field was to make a recursive call if
>the direction chosen would take the robot out of the field. Nice
>properties from a bias point of view, but... Her answer to the worst
>case scenario was to put in a comment indicating that the risk of
>stack overflow had been considered and deemed acceptable in this
>environment.
>
> If I was the instructor who handed out either problem, I'd care
>whether students were aware of the issues, not whether they wrote
>perfect code for dealing with all the possibilities. (The card
>dealing problem is easy to handle, especially if the game is poker or
>blackjack. In the robot problem, there is a nasty tradeoff between
>required stack size and bias. You set one value and it determines the
>other. Having three generators is a different approach, but now you
>have to insure that they are truly independent.)
>
> More than you probably wanted to know, but as Robert said, I am
>somewhat of a fanatic on the subject. I've never personally gotten
>burned by a bad PRNG, or misuse of one, but I know several people who
>have. Withdrawing published papers is no fun, as happened to a friend
>of mine who used RANDU. Even worse was one case where the engineer
>involved had to go to the NRC and say the nuclear reactor wasn't as
>safe as they thought. (In fact I don't think the Diablo Canyon
>reactor was ever operated. By the time they fixed the problems that
>the wrong simulation had missed, new earthquake faults were found
>running directly under the reactor.)
>
>--
>
> Robert I. Eachus
>
>with Standard_Disclaimer;
>use Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 10:02:30 -0800
>From: Ken Garlington <GarlingtonKE@LMTAS.LMCO.COM>
>Subject: Re: Please do not start a language war (was Re: Papers on the
>Ariane-5
> crash and Design by Contract
>
>Jean-Marc Jezequel wrote:
>>
>> In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington
><GarlingtonKE@lmtas.lmco.com> writes:
>>
>> > 2. No one ran a full integration test with realistic flight data,
>> >which would have
>> > alerted them to the mistake made in #1. Particularly for a
>> >distributed mission-
>> > critical system, this should be considered an absolute
>> >requirement.
>>
>> Yes, this is true. But you have to understand that the mere design of the
>>SRI
>> made it very difficult to test it in an other way that performing a launch.
>> This is because of the tight integration of hard-to-fool hardware with
>software
>> in a black box functional unit.
>
>We have exactly the same coupling of inertials to flight controls on a
>current project, and
>we are able to test the coupled system in a black box environment in our
>labs, with pilots in the loop, performing the same flight profiles we
>expect to see in operation.
>
>Interestingly enough, the IRS for the this project is also "reused" from
>a different platform, and there was a proposal to minimize testing of
>the system because it had already
>been "proven." We were able to quash that "cost-savings" measure before
>it gained much
>support. However, in an environment with Cost As an Independent Variable
>(CAIV), I can
>certainly see how easy it would be to adopt such ideas.
>
>> What can be your test strategy for a black box
>> containing an inertial central? If the software had been designed with less
>coupling
>> on this particular hardware, you could have test the software vs. a
>simulation of the
>> hardware and its environment. Here, the launch was the test.
>
>Is this what Aerospatiale told you?
>
>>
>> >Although I like some of Mr. Meyer's columns, I found this particular
>> >column not only wrong,
>> >but dangerous, since it continues the trend of denigrating sound test
>> >strategy and common
>> >sense system engineering in favor of a software-centric approach.
>>
>> I don't see where it denigrates sound testing. IMHO, sound testing *is*
>needed.
>> And testing is effective only if you have a sound test strategy.
>> Even more when you use programming by contract. In the paper,
>> we just recall that you cannot rely on tests only.
>
>Then why in your message on comp.lang.ada, did you say that to a "lesser
>extent"
>this was an integration test problem? Not doing this testing was a
>*critical*
>part of the problem!
>
>Although I think programming by contract is worthwhile, I still contend
>that there
>is no compelling reason to believe it would have avoided *this
>particular problem*, for
>two reasons:
>
>1. There is strong evidence to believe that the Ariane IV SRI team did
>not see this
> as a particularly important assertion to make (otherwise, they would
>not have
> suppressed the check). In the context of what they knew (the Ariane
>IV flight
> profile), their opinion was at least understandable if not
>justifiable.
>
>2. There is some evidence to indicate that the Ariane V team would not
>have considered
> themselves in violation of the assertion, even if it had been
>explictly coded. Apparently,
> they did not challenge the decision of the Ariane IV team to suppress
>the exception
> checks for the unit. Based on my experience in similar situations, it
>is sometimes
> difficult to translate such high-level information as a flight
>profile to the specific
> range of parameters to be passed to a particular unit. Additionally,
>there is no
> evidence that the software team, reading the source code, had
>sufficient systems
> knowledge and experience to detect the violation of the assertion
>strictly from reading
> the code.
>
>Based on my experience with aerospace systems, and in particular
>integrated inertial and
>flight control systems (from the flight controls side), I see this
>scenario as entirely
>possible. In this case, no amount of documentation at the code level
>would have solved
>the problem, and no amount of embedded run-time checks would solve the
>problem in the
>absence of realistic testing.
>>
>> --
>> Jean-Marc Jezequel Tel : +33 2 99847192
>> IRISA/CNRS Fax : +33 2 99847171
>> Campus de Beaulieu e-mail : jezequel@irisa.fr
>> F-35042 RENNES (FRANCE) http://www.irisa.fr/pampa/PROF/jmj.html
>
>--
>LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
>For job listings, other info: http://www.lmtas.com or
>http://www.lmco.com
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 16:16:45 GMT
>From: Fergus Henderson <fjh@MURLIBOBO.CS.MU.OZ.AU>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>rkaiser@dimensional.com (Richard Kaiser) writes:
>
>>Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>>using #include <assert.h> for years? Software engineers have been using
>>assert macros to verify program limits are not exceeded.
>
>The major difference between C/C++/Ada assertions and Eiffel style
>design-by-contract is that in the latter, the assertions are part of
>the interface, not just embedded in the implementation.
>
>--
>Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
>WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
>PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 14:53:35 GMT
>From: Larry Kilgallen <kilgallen@EISNER.DECUS.ORG>
>Subject: Re: floating point problem
>
>In article <dewar.858142750@merv>, dewar@merv.cs.nyu.edu (Robert Dewar)
>writes:
>> Larry asks
>>
>> <<So can anyone give an example for the Intel-challenged regarding how
>> one would easily detect this float-challenged hardware at runtime in
>> order to issue a nastygram ?>>
>>
>> The proper code is a little delicate, but is documented in the relevant
>> Intel microprocessor manuals. Note that all DX chips, and of course all
>> Pentiums have built-in floating-point, so this is really only a concern
>> with ancient machines that you cannot purchase any longer.
>
>So I would gather one cannot do this test from Ada.
>
>As to machine models affected, my concern is that when my program is
>put onto the wrong machine (regardless of any documentation I might
>provide) an unambiguous message regarding the nature of the problem
>is issued to the naive user. Support calls cost money.
>
>Larry Kilgallen
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 21:16:55 GMT
>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>Subject: Re: Ariane-5: can you clarify? (Re: Please do not start a language
>war)
>
>In article <01bc3389$46204f70$b280400a@gavinspc> "Gavin Collings"
><gcollings@sperry-sun.com> writes:
>
>> (2) To treat the software as intrinsically more reliable than the
>> hardware seems to go against all experience and indeed against
>> common sense.
>
>Truer words have never been spoken or written in software circles.
>This should be framed and required to be hung on the wall in all such
>circles.
>
>
>/Jon
>--
>Jon Anthony
>Organon Motives, Inc.
>Belmont, MA 02178
>617.484.3383
>jsa@organon.com
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 12:41:01 +0000
>From: Nick Leaton <nickle@CALFP.CO.UK>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>Richard Kaiser wrote:
>
>> The first mistake was to not put the time limit in some human readable
>> documentation, or if the time limit was documenting then it was not read.
>> Writing code so it documents itself reduces or eliminates the code
>> documentation, but this can be done in Ada, EIffel, C, C++ and even
>> assembly language and FORTRAN. These limits are part of the design
>> and belong in a Software Requirements/Requirements Verification document
>> and in the Version Description Document. And these documents must be
>> reviewed prior to reuse.
>
>The difference between writting comments that document code, and
>writting assertions is simple. The assertions will get tested, your
>comments will not. I prefer to trust the latter
>
>> >2) Design. Writting assertions makes design easier. This is a personal
>> >observation and harder to justify. I find being clear about what
>> >something does helps clear up what I am doing. Having complex
>> >preconditions is not a good idea, again you probably don't have the
>> >right structure.
>>
>> The code is going to say "I am not in my original application and may or
>> will fail?" Assertions are only going to catch problems if there is:
>>
>
>No, the code does what it is contracted to do. If you break the
>contract, it raises an exception.
>
>--
>
>Nick
>
>------------------------------
>
>Date: Fri, 14 Mar 1997 14:03:57 -0700
>From: Akihito Tanaka <tanaka@CS.BUY.EDU>
>Subject: need free compiler
>
>I am college student and looking for free ada compiler on the web. My
>prof told me to research on ada language and write a code in ada. If
>you know the sites please tell me.
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 10:15:57 -0800
>From: Ken Garlington <GarlingtonKE@LMTAS.LMCO.COM>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>Thomas wrote:
>>
>> Well, what if a lot more money had been budgeted for hardware? Could
>> the space agency have paid the processor manufacturers to come out
>> with a version that was 30% faster (that should have been sufficient
>> to use runtime checks everywhere without changing the design)?
>
>Some problems with doing that:
>
>1. New designs add risk, since there's not a history of use.
>2. Faster usually means more power/cooling required, which reduces
>payload.
>3. Processor manufacturers charge more for small production runs, which
> cuts into the profit margin. Remember that hardware is a recurring
> cost; software (in the absence of maintenance) isn't.
>
>> Another option could have been to add more individual processors and
>> use them in parallel (almost certainly harder than it sounds, but
>> still a possibility).
>
>1. Adds weight, power and cooling requirements (reducing payload).
>2. Costs more (more parts)
>3. Adds complexity to the design, and thus risk.
>
>> Or what about choosing a less ambitious flight
>> trajectory and maybe lower payload so that control required less
>> computation?
>
>Would have made the Ariane V less competitive, and possibly non-viable.
>
>> Of course, none of those would have been easy choices to make. Design
>> by contract and other methodologies are useful, but I still think
>> without a solid foundation of runtime checks in the production code
>> and multiple exception handlers and recovery blocks, no methodology
>> alone is going to give sufficient protection from failure. In fact,
>> Eiffel itself, which has been mentioned here because of its assertion
>> system, is built on a foundation of runtime safety.
>
>However, runtime safety doesn't do much good if either/or (a) you test
>on the ground to see what exceptions are raised; (b) you know how to
>correct from the exception (in some cases, there IS no good response
>to certain exceptions).
>
>
>--
>LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
>For job listings, other info: http://www.lmtas.com or
>http://www.lmco.com
>
>------------------------------
>
>Date: Wed, 12 Mar 1997 11:04:14 -0600
>From: Robert Oeckl <oeckl@PHENO.PHYSICS.WISC.EDU>
>Subject: numerical libraries
>
>I am looking for an Ada95 (or Ada83 if no compatiblity problems arise)
>numerics library and am specifically interested in the following
>capabilities:
>
>- special functions: specifically the Exponential Integral function and
> related functions
>
>- high accuracy floating point types: I am looking for accuracies of
> let's say 20 or 25 decimal digits. Best would be (almost) arbitrary
> accuracy
>
>- routines to calculate definite integrals
>
>I would greatly appreciate any help.
>
>Thanks in advance,
>Robert
>
>------------------------------------
>
>Robert Oeckl, graduate student
>University of Wisconsin
>Department of Physics
>1150 University Avenue
>Madison WI 53706-1390, USA
>
>phone: +1 (608) 262-8947
>e-mail: oeckl@pheno.physics.wisc.edu
>
>------------------------------
>
>End of INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>*******************************************************************
>
^ permalink raw reply [relevance 0%]
* Re: INFO-ADA Digest - 19 Mar 1997 - Special issue
@ 1997-03-19 0:00 0% Tokoro, David
0 siblings, 0 replies; 67+ results
From: Tokoro, David @ 1997-03-19 0:00 UTC (permalink / raw)
Please REMOVE me from this mailing list.
Thanks,
David M.Tokoro
***************************************
Business Systems Branch N318
Phone: (619) 553-2707
E-mail: tokoro@nosc.mil
***************************************
>----------
>From: Automatic digest processor[SMTP:LISTSERV@LISTSERV.NODAK.EDU]
>Sent: Wednesday, March 19, 1997 2:03 PM
>To: Recipients of INFO-ADA digests
>Subject: INFO-ADA Digest - 19 Mar 1997 - Special issue
>
>There are 3 messages totalling 1100 lines in this issue.
>
>Topics in this special issue:
>
> 1. Random Numbers
> 2. Papers on the Ariane-5 crash and Design by Contract
> 3. INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>
>----------------------------------------------------------------------
>
>Date: Wed, 12 Mar 1997 17:06:48 GMT
>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>Subject: Re: Random Numbers
>
>In article <5g56sj$tqq$1@krusty.irvine.com> adam@irvine.com (Adam Beneschan)
>writes:
>
> > Is this algorithm correct? I'm suspicious. The above code generates
> > a random number between 1 and 52 fifty-two times, meaning that number
> > of different possibile sequences of random numbers generated is
> > 52**52. However, the number of possible orderings of a deck is 52!.
> > This indicates to me that the above code does not generate the
> > possible deck orderings uniformly (although the discrepancy may be
> > slight).
>
> Actually, the number of different deck orderings generated will
>depend on the period of the underlying PRNG. In other words, the
>maximum number of different deck orders generated will depend on the
>possible different states at the start of the shuffle. Usually this
>will be the number of different possible PRNG states which will be
>much, much smaller than 52!.
>
> You can fix this by using more than one INDEPENDENTLY SEEDED
>random number generator. You can either choose successive values from
>different generators, or shuffle with one generator as above then
>shuffle again with the second, etc.
>
> In practice for any card games involving human players, the
>number of different possibilities from one generator is enough. If
>you are planning to write a program and run it unattended for weeks to
>compare two different playing strategies for say, blackjack, you
>probably should use multiple generators. (Incidently, there are
>computer games with junk generators where I find that the ability to
>predict the sequence gives me an enormous edge over the computer
>player.)
>
>--
>
> Robert I. Eachus
>
>with Standard_Disclaimer;
>use Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>
>------------------------------
>
>Date: Tue, 18 Mar 1997 19:56:21 GMT
>From: John McCabe <john@ASSEN.DEMON.CO.UK>
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
>Bertrand Meyer <bertrand@eiffel.com> wrote:
>
>>The real problem was that the assertion was not part of the software.
>
>No - the real problem was that the developers were _not_ provided with
>Ariane 5 trajectory information which should have been used in the
>analysis.
>
>
>Best Regards
>John McCabe <john@assen.demon.co.uk>
>
>------------------------------
>
>Date: Wed, 19 Mar 1997 13:52:44 -0800
>From: "Tokoro, David" <tokoro@NOSC.MIL>
>Subject: Re: INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>
>Please REMOVE me from this mailing list.
>
>Thanks,
>
>David M.Tokoro
>***************************************
>Business Systems Branch N318
>Phone: (619) 553-2707
>E-mail: tokoro@nosc.mil
>***************************************
>
>>----------
>>From: Automatic digest processor[SMTP:LISTSERV@LISTSERV.NODAK.EDU]
>>Sent: Wednesday, March 19, 1997 1:47 PM
>>To: Recipients of INFO-ADA digests
>>Subject: INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>>
>>There are 26 messages totalling 1002 lines in this issue.
>>
>>Topics in this special issue:
>>
>> 1. Tasking In Ada 83 "Question"
>> 2. Do I Really Need A Supervisor? (2)
>> 3. Access to primitive operations of tagged types
>> 4. Papers on the Ariane-5 crash and Design by Contract (6)
>> 5. CRC in Ada? (5)
>> 6. Static variables?
>> 7. UNIX Texteditor for GNAT Ada95 3.07
>> 8. floating point problem (2)
>> 9. Ada Sockets
>> 10. Gnat 3.04a for 95 wierdness
>> 11. Random Numbers
>> 12. Please do not start a language war (was Re: Papers on the Ariane-5
>>crash
>> and Design by Contract
>> 13. Ariane-5: can you clarify? (Re: Please do not start a language war)
>> 14. need free compiler
>> 15. numerical libraries
>>
>>----------------------------------------------------------------------
>>
>>Date: Tue, 18 Mar 1997 19:50:19 -0600
>>From: "James A. Squire" <m193884@CSEHP1.MDC.COM>
>>Subject: Re: Tasking In Ada 83 "Question"
>>
>>In article <332F3050.74B8@mccabe.com>,
>>Michael Ibarra <ibarra@mccabe.com> wrote:
>>>I have a task, and I want to perform some action when I know that my
>>>task has terminated. I can't tell when it has terminated. My task
>>>looks something like:
>>>
>>>Task Body timer is
>>>begin
>>>loop
>>> select
>>> accept receive_call do
>>> null;
>>> end receive_call;
>>> or
>>> terminate;
>>> end select;
>>>end loop;
>>>end timer;
>>>
>>>My problem is that in order to check the terminated attribute of the
>>>task, I need to with the package that is parent/master to the task,
>>>therefore preventing it from becoming terminated.
>>
>>I don't quite understand this statement. If the task is pretty much
>>like you have it there, withing it's parent seems to have absolutely
>>nothing to do with preventing it from becoming terminated. Or else
>>I don't have enough information here.
>>
>>It seems to me that what prevents this task from terminating is the
>>mere fact that the program is still running, since the only way it
>>terminates (apart from some other task aborting it or an exception
>>being raised from within) is when all other tasks including the main
>>task are finished - hence when the program is finished. There is no
>>stop entry, and the loop is endless. The terminate statement only
>>ensures that the program won't be left hanging if every other task
>>is finished.
>>
>>>This is NEVER true. Is there any way that I can konw when this task
>>>has terminated. I wanted to perform some jobs ONLY after this task
>>>is terminated.
>>
>>If you want to do anything after such a task terminates, then you'll
>>have to pick some other way for the task to terminate, it seems to
>>me. The options I'm aware of are: (1) adding a Stop entry, (2) adding
>>some condition that exits the loop, (3) abort the task. It looks like
>>(2) is closest to what you are looking for since you are treating
>>termination of this task as if it is non-deterministic to the other tasks
>>in your program.
>>
>>Either that or you need to give us more info.
>>--
>>James Squire mailto:m193884 no junk mail allowed@csehp1.mdc.com
>>MDA Avionics Tools & Processes
>>McDonnell Douglas Aerospace http://www.mdc.com/
>>Opinions expressed here are my own and NOT my company's
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 14:22:59 -0500
>>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>>Subject: Re: Do I Really Need A Supervisor?
>>
>><<Obviously people have some complaints here. You've only
>>responded with a remark aimed (obviously) to intimidate.>>
>>
>>Well I understand that some people regard the idea of strong management
>>as intimidating, and that's fine, different people work in different ways.
>>All I am saying is that as far as I am concerned strong management is
>>essential to software quality. Even in such a minor aspect as coding
>>standards, if you have a bunch of "I don't need no stinkin' supervisor"
>>hackers, you will have trouble solving even this trivial problem (of
>>requiring consistent surface syntax).
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 23:34:25 GMT
>>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>>Subject: Re: Access to primitive operations of tagged types
>>
>>In article <hkbmg5.2h2.ln@localhost> njt@sv1pc161.cs.york.ac.uk (Nigel J.
>>Tracey) writes:
>>
>>> My problem is however that I cannot pass an access to the callback
>>> functions when installing the callback routine in X. The Ada RM
>>> states that a dereference of an access-to-subprogram value is never
>>> a dispatching call.
>>
>>Make the "access" registered functions non dispatching, make them
>>private (or better yet in a body), and have them _call_ their
>>appropriate dispatchable operation.
>>
>>/Jon
>>--
>>Jon Anthony
>>Organon Motives, Inc.
>>Belmont, MA 02178
>>617.484.3383
>>jsa@organon.com
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 20:57:14 GMT
>>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>In article <5gll90$2qu$1@news.irisa.fr> jezequel@irisa.fr (Jean-Marc
>>Jezequel)
>>writes:
>>
>>> To answer Jon S Anthony, yes, all that could have been done in Ada
>>>using:
>>> function Convert ( Horizontal_Bias: Integer ) return Integer is
>>> subtype Bias_Constraint is Integer range 0..Maximum_Bias;
>>> Require : Bias_Constraint := Horizontal_Bias;
>>>
>>> Ada's subtype declarations are a kind of contract, that could be
>>> documented as such. Design by contract is not specific to
>>> Eiffel. You can do it with any language, just because it is a way of
>>> designing! Eiffel is, however, one of the few languages that provide
>>> built-in support for it.
>>
>>You miss my point. Which is that this stuff is NOT sufficient to have
>>prevented this error. And further, the evidence supports this
>>position because the language used in fact _does_ have this capability
>>but it was _not_ used. While design by contract is a good first step,
>>it _too_ is simply insufficient as currently realized. It in no way
>>captures any of the semantic context that scopes the usage scenarios
>>that are assumed in the design and implementaion of "components".
>>
>>
>>> Let's finally sum up what I perceive as the most important claims in
>>> this paper:
>>> - reusing a component without checking its full
>>> specification is dangerous, which means that simple minded
>>> CORBA-like approaches at building components for mission-critical
>>> software are doomed.
>>
>>Agreed, but this too is simply way too simplistic. If "full
>>specification" simply means signatures and their pre and post
>>condition requirements, it does not capture the "full" scope of the
>>problem. If it does include the various semantic aspects associated
>>with "components", it is not and, what is more, _cannot_ be captured
>>in signatures and assertions.
>>
>>
>>> - using design by contract is an interesting
>>> way to specify the behavior of a component
>>
>>Yes, but _only_ a rather _limited_ aspect. It is clearly better than
>>nothing, but alone it could not prevent the sort of problem being
>>discussed.
>>
>>
>>> - at least in the case of
>>> Ariane 501, simple assertions (a la Eiffel and other languages)
>>> would have been expressive enough to specify the fatal hidden
>>> assumption.
>>
>>This I simply don't believe. And the evidence does not support it
>>either.
>>
>>
>>/Jon
>>--
>>Jon Anthony
>>Organon Motives, Inc.
>>Belmont, MA 02178
>>617.484.3383
>>jsa@organon.com
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 21:26:00 -0600
>>From: Michael & Amy Hartsough <Hartsough@WORLDNET.ATT.NET>
>>Subject: Re: CRC in Ada?
>>
>>Robert Dewar wrote:
>>> Michael said
>>> <<I instantiated Sequential I/O with an unsigned 8-bit type>>
>>>
>>> OUCH! Sequential_IO is intended to be used for logical record I/O.
>>> I can see that one might be tempted to write non-portable code that
>>> (mis)used Sequential_IO in this manner in Ada 83 if you felt compelled
>>> to use the Ada 83 IO packages, instead of the more obvious choice of
>>> using C packages for a case like this (Ada 83 really lacked stream io,
>>> and in a case like this, which is obviously a case for stream io, the
>>> proper response in my view is to interface to C, rather than misuse
>>> the Ada packages).
>>
>>I had been directed to implement CRC32 in Ada 83, and test its output
>>against
>>the output of a C++ version of the algorithm. As soon as testing was
>>completed
>>the CRC32 code (sans file I/O) was lifted out of the test program and
>>inserted
>>into an existing embedded application that reads data from a PCMCIA card.
>>
>>So yes, I DID feel compelled to use an Ada 83 I/O package. I don't think my
>>employer would have much appreciated my spending half a day chasing down
>>some C file I/O routines to improve the throughput of my test program.
>>
>>> It is not at all surprising
>>> that you would see the peformance difference, and it says nothing
>>> about Ada-vs-C performance.
>>
>>Certainly not Ada versus C, but definitely one compiler versus another
>>compiler.
>>Pick your I/O package and your language, and 18 minutes versus 27 seconds to
>>read
>>the same file certainly tells you something. HIS compiler (which happens to
>>be
>>C++) has buffered file I/O. MY compiler (which happens to be Ada 83) does
>>not
>>buffer file I/O.
>>
>> Michael
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 21:57:05 -0600
>>From: Ray McVay <bmcvay@ARLINGTON.NET>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>John McCabe wrote:
>>>
>>> Bertrand Meyer <bertrand@eiffel.com> wrote:
>>>
>>> >The real problem was that the assertion was not part of the software.
>>>
>>> No - the real problem was that the developers were _not_ provided with
>>> Ariane 5 trajectory information which should have been used in the
>>> analysis.
>>>
>>> Best Regards
>>> John McCabe <john@assen.demon.co.uk>
>>
>>Finally! Thank you, sir. It was obvious from reading the report that
>>was pointed out several months ago by a post in this newsgroup that this
>>was a wonderful example of a failure WAY early in the lifecycle. It had
>>nothing to do with design or construction and everything to do with a
>>bogus specification. They were in effect designing a control system for
>>a completely different rocket than the one in which the system was used!
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 19:49:37 -0800
>>From: nasser@APLDBIO.COM
>>Subject: Re: Do I Really Need A Supervisor?
>>
>>In article <332E163F.5EFD@earthlink.net>, antialias@earthlink.net says...
>>>
>>>Oh, heck, maybe it didn't belong on comp.lang.ada, but this
>>>IS the kind of software engineering environment that Ada
>>>software is developed in...
>>
>>it is unfortunate to the Ada language that it happened to be
>>mostly used in environments where zillion levels of managements
>>and entrenched beaucracy (sp?) is the norm, this environment is a
>>turn off for many programmers who would love otherwise to program
>>in Ada but are wary of the surrounding working climate where Ada
>>is used.
>>
>>Nasser
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 22:25:11 -0800
>>From: nasser@APLDBIO.COM
>>Subject: Re: Static variables?
>>
>>as Dr Dewar mentioned, package variables retain their values
>>from the time the package becomes avaliable to the time the
>>package life ends (usually the end of the program , but not
>>always the case, example, if the package is declared inside
>>a block or procedure), may be a picture will help:
>>
>>
>>
>> package A interface
>> +---------------------+
>> | i: integer; -----------> retain its value also
>>client <=======> | procedure foo; |
>> | ....... |
>> +---------------------+
>>
>> .............................................
>>
>> package A body
>> +---------------------+
>> |j: integer; --------------> these variables retain
>> | | their values
>> | procedure foo is |
>> | n: integer; ------------> variables here are auto
>> | begin | variables, new copies are
>> | .... | created each time foo is
>>called
>> | end foo; |
>> | |
>> | begin |
>> | .... ----------------> this code execute once when
>> | end A; | package is first elaborated.
>> | | use this code to init package
>> +---------------------+ variables.
>>
>>
>>you can think of variables declared in the package interface as static
>>puplic
>>in C++ class terminolgy, and variables declared in the body of the package
>>but outside the functions and procedure of the package body as static
>>private in C++.
>>
>>offcourse it is a good idea to try to avoid using variables in the interface
>>part of the package.
>>
>>nasser
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 10:49:11 +0100
>>From: Paul Chardon <paul.chardon@AVIONS.AEROSPATIALE.FR>
>>Subject: Re: UNIX Texteditor for GNAT Ada95 3.07
>>
>>Hello William,
>>
>> I have been using Emacs or Xemacs with Ada-mode for a few months
>>and
>>if ind it very good. You've got syntactycal coloring, you've got some
>>options to program faster, and then if you're good in lisp (because
>>Emacs uses lisp functions), you can increase the customization offered
>>by emacs, as I have done. You can also compile, execute and eventually
>>debug within Emacs. A lisp file for Emacs Ada-Mode Emacs is normally
>>available with the Gnat.
>>
>> Bye, Paul.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 00:00:30 -0500
>>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>>Subject: Re: floating point problem
>>
>>Larry asks
>>
>><<So can anyone give an example for the Intel-challenged regarding how
>>one would easily detect this float-challenged hardware at runtime in
>>order to issue a nastygram ?>>
>>
>>The proper code is a little delicate, but is documented in the relevant
>>Intel microprocessor manuals. Note that all DX chips, and of course all
>>Pentiums have built-in floating-point, so this is really only a concern
>>with ancient machines that you cannot purchase any longer.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 00:05:41 -0500
>>From: Robert Dewar <dewar@MERV.CS.NYU.EDU>
>>Subject: Re: CRC in Ada?
>>
>>Graham says
>>
>><<>Sure you can read character by character, but you are paying a
>>considerable
>>>price, even in C, for doing so!
>>
>>Actually: virtually none.>>
>>
>>Well words like considerable and virtually are not very quantitative.
>>There definitely is a price in going character by character (even Balter
>>thinks this extra price might be dominant in something like "cat").
>>
>>Every system where I have measured the effect (e.g. the difference in
>>a compiler that reads large blocks, or does character by character reads,
>>I have seen enough difference to be worth the effort of doing IO in blocks.
>>This is especially true if you can put a sentinel at the end of the block
>>that will naturally be detected by your processing, e.g. an end-of-file
>>mark of some kind in the compiler case, so that you can then process
>>character by character with out a test for buffer exhaustion (once you
>>commit to using getchar, you do of course have a test on each character
>>read for buffer exhuastion, because at that level it is not under
>>your control).
>>
>>GNAT actually works exactly this way, it reads the entire source with
>>a single read, and then puts an end of file sentinel at the end of the
>>source. This provides noticable speed up over character by character
>>processing.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 12:26:09 +0000
>>From: NP GOODGAME <goodganp@ASTON.AC.UK>
>>Subject: Ada Sockets
>>
>>Is there a way to program a socket server completely in Ada 95. I'm
>>using gnat as my compiler on a Sun Solaris UNIX workstation.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 05:27:55 -0800
>>From: Jim Balter <jqb@NETCOM.COM>
>>Subject: Re: CRC in Ada?
>>
>>Robert Dewar wrote:
>>>
>>> Jim said
>>>
>>> <<> If you want something equivalent to the macroized get_char, that is
>>> > trivially easily programmed in C on top of stream_IO, perhaps it is
>>> > a good idea for a standard package
>>>
>>> Since that was the original point, this whole discussion has been
>>> much ado about nothing.
>>> >>
>>>
>>> Actually I mistyped here, what I meant to say was "easily programmed
>>> in Ada on top of [Ada] Stream_IO", and that is what would be a good idea
>>> for a standard package.
>>
>>That's what I took you to mean (i.e., I misread you and thereby
>>read you properly).
>>
>>--
>><J Q B>
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 05:32:54 GMT
>>From: Richard Kaiser <rkaiser@DIMENSIONAL.COM>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>In article <332E8D5D.400F@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk>
>>wrote:
>>>Richard Kaiser wrote:
>>>
>>>> The first mistake was to not put the time limit in some human readable
>>>> documentation, or if the time limit was documenting then it was not read.
>>>> Writing code so it documents itself reduces or eliminates the code
>>>> documentation, but this can be done in Ada, EIffel, C, C++ and even
>>>> assembly language and FORTRAN. These limits are part of the design
>>>> and belong in a Software Requirements/Requirements Verification document
>>>> and in the Version Description Document. And these documents must be
>>>> reviewed prior to reuse.
>>>
>>>The difference between writting comments that document code, and
>>>writting assertions is simple. The assertions will get tested, your
>>>comments will not. I prefer to trust the latter
>>
>>But this software was Never tested. No end-to-end test with the hardware,
>>nor
>>even a software only simulation. If the testing is not performed assertions
>>will not be executed to detect a problem. With proper testing the simulated
>>flight would have failed with or without the assertions.
>>
>>>> >2) Design. Writting assertions makes design easier. This is a personal
>>>> >observation and harder to justify. I find being clear about what
>>>> >something does helps clear up what I am doing. Having complex
>>>> >preconditions is not a good idea, again you probably don't have the
>>>> >right structure.
>>>>
>>>> The code is going to say "I am not in my original application and may or
>>>> will fail?" Assertions are only going to catch problems if there is:
>>>>
>>>
>>>No, the code does what it is contracted to do. If you break the
>>>contract, it raises an exception.
>>
>>But software testing "never re-read the contract".
>>
>>Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>>using #include <assert.h> for years? Software engineers have been using
>>assert macros to verify program limits are not exceeded.
>>
>>Richard Kaiser
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 06:03:15 -0800
>>From: Jim Balter <jqb@NETCOM.COM>
>>Subject: Re: CRC in Ada?
>>
>>Robert Dewar wrote:
>>>
>>> Jim said
>>>
>>> <<It take an unusual degree of intellectual dishonesty to misrepresent
>>> one's own point. No more talk here of extra system calls,
>>> buffering not being mandated, or the need to go out and empirically
>>> check 6 implementations.>>
>>>
>>> No, sorry, you are confused, go back and check the thread, I never said
>>> that there were extra system calls, that was someone else with whom I
>>> disagreed!
>>
>>I have already quoted you as saying that a single I/O call per block
>>by the *C library* (not a comment about ADA) is not guaranteed.
>>
>>> As for buffering being mandated, I am not quite sure what you are talking
>>> about here.
>>
>>Sorry to here that you are having so much trouble following the thread.
>>
>>--
>><J Q B>
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 12:54:29 GMT
>>From: Larry Kilgallen <kilgallen@EISNER.DECUS.ORG>
>>Subject: Re: Gnat 3.04a for 95 wierdness
>>
>>In article <33259a7a.22085949@news.demon.co.uk>, smoore@chowgar.demon.co.uk
>>(Simon Moore) writes:
>>
>>> p.s. Would it be worthwhile for me to download 3.09 or are the updates
>>> minimal?
>>
>>Ignoring Robert Dewar's specific technical response...
>>
>>...Any software developer will love you more if problem reports
>>are from their latest offering.
>>
>>Even in cases where a product (not just Ada compilers) has two
>>supported versions due to known glitches in the latest version,
>>it is that latest version which the developer will be moving on
>>to future levels, and for which they want the feedback.
>>
>>An exception, of course, should be made for cases where the
>>defect you find has already been acknowledged by the developer
>>and anything stronger than "this affects me too" might be noise.
>>
>>Again, this is a political rather than a technical tactic.
>>You make their life easier and they will have more time to
>>make your life easier. There are situations where you may
>>prefer to pay a developer large amounts of money to support
>>old versions, but those are rare.
>>
>>Larry Kilgallen
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 15:13:36 GMT
>>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>>Subject: Re: CRC in Ada?
>>
>>In article <dewar.858095506@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
>>writes:
>>
>> > That's a pretty marginal optimization. Maybe Geert makes subtypes
>> > Positive_Float, but of all the code we ever had submitted to us,
>> > no one ever bothered to do this, they just used Float.
>>
>> > Still it can go on the list, it's way down there in priority though,
>> > there are MANY more important optimizations ahead of it!
>>
>> Let me put an optimization way ahead of it on the list and see if
>>anyone is interested...
>>
>> The easiest way of dealing with the A.5.1(37-42) requirements in a
>>portable manner is the one currently taken by GNAT--explicit code.
>>However, most of these requirements will be met by any IEEE conforming
>>implementation. So it should be possible to have two versions of the
>>elementary functions packages, one which assumes good underlying math
>>libraries, and one which does not.
>>
>> Note that the hard work here can be done completely separately from
>>other compiler maintenance and enhancement activities. It involves
>>writing some test code and running it on a lot of different
>>platforms. (The way I envision this is a set of alternate bodies, and
>>a test program which validates the elisions. Of course, the ultimate
>>would be a test program that generated a tailored version of the
>>bodies which matched the particular hardware.)
>>
>>
>>--
>>
>> Robert I. Eachus
>>
>>with Standard_Disclaimer;
>>use Standard_Disclaimer;
>>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 16:00:14 GMT
>>From: "Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG>
>>Subject: Re: Random Numbers
>>
>>In article <dewar.858098083@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
>>writes:
>>
>> > Don't worry, Robert Eachus is a fanatic here (he wrote the random number
>> > generator) :-)
>>
>> A fanatic? A FANATIC? You dare to call ME a FANATIC on the subject?
>>
>> Well, maybe. ;-)
>>
>> > The orignal question came from a student writing a simple card playing
>> > program, and I think you will find that the random number routines
>> > are quite fine for this purpose!
>>
>> Oh, they are probably fine for this purpose, even if not used
>>correctly. But I would hope that a student would think about the
>>issues involved, even if the final decision was to ignore them.
>>Learning software engineering involves both learning to recognize the
>>issues, and learning to decide which potential problems can be ignored
>>in the case at hand.
>>
>> For example, my daughter had a similar assignment involving robots
>>moving one of eight directions in a limited field. Her action if the
>>random next move was outside the field was to make a recursive call if
>>the direction chosen would take the robot out of the field. Nice
>>properties from a bias point of view, but... Her answer to the worst
>>case scenario was to put in a comment indicating that the risk of
>>stack overflow had been considered and deemed acceptable in this
>>environment.
>>
>> If I was the instructor who handed out either problem, I'd care
>>whether students were aware of the issues, not whether they wrote
>>perfect code for dealing with all the possibilities. (The card
>>dealing problem is easy to handle, especially if the game is poker or
>>blackjack. In the robot problem, there is a nasty tradeoff between
>>required stack size and bias. You set one value and it determines the
>>other. Having three generators is a different approach, but now you
>>have to insure that they are truly independent.)
>>
>> More than you probably wanted to know, but as Robert said, I am
>>somewhat of a fanatic on the subject. I've never personally gotten
>>burned by a bad PRNG, or misuse of one, but I know several people who
>>have. Withdrawing published papers is no fun, as happened to a friend
>>of mine who used RANDU. Even worse was one case where the engineer
>>involved had to go to the NRC and say the nuclear reactor wasn't as
>>safe as they thought. (In fact I don't think the Diablo Canyon
>>reactor was ever operated. By the time they fixed the problems that
>>the wrong simulation had missed, new earthquake faults were found
>>running directly under the reactor.)
>>
>>--
>>
>> Robert I. Eachus
>>
>>with Standard_Disclaimer;
>>use Standard_Disclaimer;
>>function Message (Text: in Clever_Ideas) return Better_Ideas is...
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 10:02:30 -0800
>>From: Ken Garlington <GarlingtonKE@LMTAS.LMCO.COM>
>>Subject: Re: Please do not start a language war (was Re: Papers on the
>>Ariane-5
>> crash and Design by Contract
>>
>>Jean-Marc Jezequel wrote:
>>>
>>> In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington
>><GarlingtonKE@lmtas.lmco.com> writes:
>>>
>>> > 2. No one ran a full integration test with realistic flight data,
>>> >which would have
>>> > alerted them to the mistake made in #1. Particularly for a
>>> >distributed mission-
>>> > critical system, this should be considered an absolute
>>> >requirement.
>>>
>>> Yes, this is true. But you have to understand that the mere design of the
>>>SRI
>>> made it very difficult to test it in an other way that performing a
>>>launch.
>>> This is because of the tight integration of hard-to-fool hardware with
>>software
>>> in a black box functional unit.
>>
>>We have exactly the same coupling of inertials to flight controls on a
>>current project, and
>>we are able to test the coupled system in a black box environment in our
>>labs, with pilots in the loop, performing the same flight profiles we
>>expect to see in operation.
>>
>>Interestingly enough, the IRS for the this project is also "reused" from
>>a different platform, and there was a proposal to minimize testing of
>>the system because it had already
>>been "proven." We were able to quash that "cost-savings" measure before
>>it gained much
>>support. However, in an environment with Cost As an Independent Variable
>>(CAIV), I can
>>certainly see how easy it would be to adopt such ideas.
>>
>>> What can be your test strategy for a black box
>>> containing an inertial central? If the software had been designed with
>>>less
>>coupling
>>> on this particular hardware, you could have test the software vs. a
>>simulation of the
>>> hardware and its environment. Here, the launch was the test.
>>
>>Is this what Aerospatiale told you?
>>
>>>
>>> >Although I like some of Mr. Meyer's columns, I found this particular
>>> >column not only wrong,
>>> >but dangerous, since it continues the trend of denigrating sound test
>>> >strategy and common
>>> >sense system engineering in favor of a software-centric approach.
>>>
>>> I don't see where it denigrates sound testing. IMHO, sound testing *is*
>>needed.
>>> And testing is effective only if you have a sound test strategy.
>>> Even more when you use programming by contract. In the paper,
>>> we just recall that you cannot rely on tests only.
>>
>>Then why in your message on comp.lang.ada, did you say that to a "lesser
>>extent"
>>this was an integration test problem? Not doing this testing was a
>>*critical*
>>part of the problem!
>>
>>Although I think programming by contract is worthwhile, I still contend
>>that there
>>is no compelling reason to believe it would have avoided *this
>>particular problem*, for
>>two reasons:
>>
>>1. There is strong evidence to believe that the Ariane IV SRI team did
>>not see this
>> as a particularly important assertion to make (otherwise, they would
>>not have
>> suppressed the check). In the context of what they knew (the Ariane
>>IV flight
>> profile), their opinion was at least understandable if not
>>justifiable.
>>
>>2. There is some evidence to indicate that the Ariane V team would not
>>have considered
>> themselves in violation of the assertion, even if it had been
>>explictly coded. Apparently,
>> they did not challenge the decision of the Ariane IV team to suppress
>>the exception
>> checks for the unit. Based on my experience in similar situations, it
>>is sometimes
>> difficult to translate such high-level information as a flight
>>profile to the specific
>> range of parameters to be passed to a particular unit. Additionally,
>>there is no
>> evidence that the software team, reading the source code, had
>>sufficient systems
>> knowledge and experience to detect the violation of the assertion
>>strictly from reading
>> the code.
>>
>>Based on my experience with aerospace systems, and in particular
>>integrated inertial and
>>flight control systems (from the flight controls side), I see this
>>scenario as entirely
>>possible. In this case, no amount of documentation at the code level
>>would have solved
>>the problem, and no amount of embedded run-time checks would solve the
>>problem in the
>>absence of realistic testing.
>>>
>>> --
>>> Jean-Marc Jezequel Tel : +33 2 99847192
>>> IRISA/CNRS Fax : +33 2 99847171
>>> Campus de Beaulieu e-mail : jezequel@irisa.fr
>>> F-35042 RENNES (FRANCE) http://www.irisa.fr/pampa/PROF/jmj.html
>>
>>--
>>LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
>>For job listings, other info: http://www.lmtas.com or
>>http://www.lmco.com
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 16:16:45 GMT
>>From: Fergus Henderson <fjh@MURLIBOBO.CS.MU.OZ.AU>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>rkaiser@dimensional.com (Richard Kaiser) writes:
>>
>>>Why is Eiffel saying assertions are a new tool? C (and now C++) have been
>>>using #include <assert.h> for years? Software engineers have been using
>>>assert macros to verify program limits are not exceeded.
>>
>>The major difference between C/C++/Ada assertions and Eiffel style
>>design-by-contract is that in the latter, the assertions are part of
>>the interface, not just embedded in the implementation.
>>
>>--
>>Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the
>>pursuit
>>WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
>>PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 14:53:35 GMT
>>From: Larry Kilgallen <kilgallen@EISNER.DECUS.ORG>
>>Subject: Re: floating point problem
>>
>>In article <dewar.858142750@merv>, dewar@merv.cs.nyu.edu (Robert Dewar)
>>writes:
>>> Larry asks
>>>
>>> <<So can anyone give an example for the Intel-challenged regarding how
>>> one would easily detect this float-challenged hardware at runtime in
>>> order to issue a nastygram ?>>
>>>
>>> The proper code is a little delicate, but is documented in the relevant
>>> Intel microprocessor manuals. Note that all DX chips, and of course all
>>> Pentiums have built-in floating-point, so this is really only a concern
>>> with ancient machines that you cannot purchase any longer.
>>
>>So I would gather one cannot do this test from Ada.
>>
>>As to machine models affected, my concern is that when my program is
>>put onto the wrong machine (regardless of any documentation I might
>>provide) an unambiguous message regarding the nature of the problem
>>is issued to the naive user. Support calls cost money.
>>
>>Larry Kilgallen
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 21:16:55 GMT
>>From: Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>
>>Subject: Re: Ariane-5: can you clarify? (Re: Please do not start a language
>>war)
>>
>>In article <01bc3389$46204f70$b280400a@gavinspc> "Gavin Collings"
>><gcollings@sperry-sun.com> writes:
>>
>>> (2) To treat the software as intrinsically more reliable than the
>>> hardware seems to go against all experience and indeed against
>>> common sense.
>>
>>Truer words have never been spoken or written in software circles.
>>This should be framed and required to be hung on the wall in all such
>>circles.
>>
>>
>>/Jon
>>--
>>Jon Anthony
>>Organon Motives, Inc.
>>Belmont, MA 02178
>>617.484.3383
>>jsa@organon.com
>>
>>------------------------------
>>
>>Date: Tue, 18 Mar 1997 12:41:01 +0000
>>From: Nick Leaton <nickle@CALFP.CO.UK>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>Richard Kaiser wrote:
>>
>>> The first mistake was to not put the time limit in some human readable
>>> documentation, or if the time limit was documenting then it was not read.
>>> Writing code so it documents itself reduces or eliminates the code
>>> documentation, but this can be done in Ada, EIffel, C, C++ and even
>>> assembly language and FORTRAN. These limits are part of the design
>>> and belong in a Software Requirements/Requirements Verification document
>>> and in the Version Description Document. And these documents must be
>>> reviewed prior to reuse.
>>
>>The difference between writting comments that document code, and
>>writting assertions is simple. The assertions will get tested, your
>>comments will not. I prefer to trust the latter
>>
>>> >2) Design. Writting assertions makes design easier. This is a personal
>>> >observation and harder to justify. I find being clear about what
>>> >something does helps clear up what I am doing. Having complex
>>> >preconditions is not a good idea, again you probably don't have the
>>> >right structure.
>>>
>>> The code is going to say "I am not in my original application and may or
>>> will fail?" Assertions are only going to catch problems if there is:
>>>
>>
>>No, the code does what it is contracted to do. If you break the
>>contract, it raises an exception.
>>
>>--
>>
>>Nick
>>
>>------------------------------
>>
>>Date: Fri, 14 Mar 1997 14:03:57 -0700
>>From: Akihito Tanaka <tanaka@CS.BUY.EDU>
>>Subject: need free compiler
>>
>>I am college student and looking for free ada compiler on the web. My
>>prof told me to research on ada language and write a code in ada. If
>>you know the sites please tell me.
>>
>>------------------------------
>>
>>Date: Wed, 19 Mar 1997 10:15:57 -0800
>>From: Ken Garlington <GarlingtonKE@LMTAS.LMCO.COM>
>>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>>
>>Thomas wrote:
>>>
>>> Well, what if a lot more money had been budgeted for hardware? Could
>>> the space agency have paid the processor manufacturers to come out
>>> with a version that was 30% faster (that should have been sufficient
>>> to use runtime checks everywhere without changing the design)?
>>
>>Some problems with doing that:
>>
>>1. New designs add risk, since there's not a history of use.
>>2. Faster usually means more power/cooling required, which reduces
>>payload.
>>3. Processor manufacturers charge more for small production runs, which
>> cuts into the profit margin. Remember that hardware is a recurring
>> cost; software (in the absence of maintenance) isn't.
>>
>>> Another option could have been to add more individual processors and
>>> use them in parallel (almost certainly harder than it sounds, but
>>> still a possibility).
>>
>>1. Adds weight, power and cooling requirements (reducing payload).
>>2. Costs more (more parts)
>>3. Adds complexity to the design, and thus risk.
>>
>>> Or what about choosing a less ambitious flight
>>> trajectory and maybe lower payload so that control required less
>>> computation?
>>
>>Would have made the Ariane V less competitive, and possibly non-viable.
>>
>>> Of course, none of those would have been easy choices to make. Design
>>> by contract and other methodologies are useful, but I still think
>>> without a solid foundation of runtime checks in the production code
>>> and multiple exception handlers and recovery blocks, no methodology
>>> alone is going to give sufficient protection from failure. In fact,
>>> Eiffel itself, which has been mentioned here because of its assertion
>>> system, is built on a foundation of runtime safety.
>>
>>However, runtime safety doesn't do much good if either/or (a) you test
>>on the ground to see what exceptions are raised; (b) you know how to
>>correct from the exception (in some cases, there IS no good response
>>to certain exceptions).
>>
>>
>>--
>>LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
>>For job listings, other info: http://www.lmtas.com or
>>http://www.lmco.com
>>
>>------------------------------
>>
>>Date: Wed, 12 Mar 1997 11:04:14 -0600
>>From: Robert Oeckl <oeckl@PHENO.PHYSICS.WISC.EDU>
>>Subject: numerical libraries
>>
>>I am looking for an Ada95 (or Ada83 if no compatiblity problems arise)
>>numerics library and am specifically interested in the following
>>capabilities:
>>
>>- special functions: specifically the Exponential Integral function and
>> related functions
>>
>>- high accuracy floating point types: I am looking for accuracies of
>> let's say 20 or 25 decimal digits. Best would be (almost) arbitrary
>> accuracy
>>
>>- routines to calculate definite integrals
>>
>>I would greatly appreciate any help.
>>
>>Thanks in advance,
>>Robert
>>
>>------------------------------------
>>
>>Robert Oeckl, graduate student
>>University of Wisconsin
>>Department of Physics
>>1150 University Avenue
>>Madison WI 53706-1390, USA
>>
>>phone: +1 (608) 262-8947
>>e-mail: oeckl@pheno.physics.wisc.edu
>>
>>------------------------------
>>
>>End of INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue
>>*******************************************************************
>>
>
>------------------------------
>
>End of INFO-ADA Digest - 19 Mar 1997 - Special issue
>****************************************************
>
^ permalink raw reply [relevance 0%]
* Re: Papers on the Ariane-5 crash and Design by Contract
[not found] ` <tz8ohcjv7cc.fsf@aimnet.com>
1997-03-17 0:00 0% ` Nick Leaton
1997-03-17 0:00 11% ` Paul Johnson
@ 1997-03-19 0:00 0% ` Jon S Anthony
1997-03-20 0:00 0% ` Paul Johnson
1997-03-20 0:00 0% ` Jean-Marc Jezequel
2 siblings, 2 replies; 67+ results
From: Jon S Anthony @ 1997-03-19 0:00 UTC (permalink / raw)
In article <5gp3hd$i0l@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
> rkaiser@dimensional.com (Richard Kaiser) writes:
>
> >Why is Eiffel saying assertions are a new tool? C (and now C++) have been
> >using #include <assert.h> for years? Software engineers have been using
> >assert macros to verify program limits are not exceeded.
>
> The major difference between C/C++/Ada assertions and Eiffel style
> design-by-contract is that in the latter, the assertions are part of
> the interface, not just embedded in the implementation.
Well, in this particular sort of case, your claim here is not correct
for Ada:
subtype Bias_Constraint is Integer range Min_Bias..Max_Bias;
function Convert ( High_Bias : Bias_Constraint ) return Integer;
The asserstion is part of the interface, NOT the implementation.
Further, to answer a point of Jean's, it will be inherited in any
appropriate derivation case. And certainly we could do the same for
the post condition (the return subtype).
Now, as John McCabe, Ken Garlington, myself and others have pointed
out, none of this was (or is in any sense likely to be) sufficient to
prevent the type of error exhibited by this example. The required
semantic context (scope of use, intended behavior, presumed
environment, etc) is far to rich and complex to be dealt with by such
rudimentary simple minded stuff as pre and post conditions on
signatures. *THE* most alarming aspect of this entire discussion is
that many, including folks the caliber of Meyer and Jezequel, don't
seem to understand this. Now that is damn _scary_.
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [relevance 0%]
* Re: Papers on the Ariane-5 crash and Design by Contract
1997-03-17 0:00 0% ` Nick Leaton
@ 1997-03-18 0:00 0% ` Richard Kaiser
[not found] ` <tz8g1xtzx9y.fsf@aimnet.com>
1 sibling, 1 reply; 67+ results
From: Richard Kaiser @ 1997-03-18 0:00 UTC (permalink / raw)
In article <332D113B.4A64@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk>
wrote:
>Path:
> dimensional.com!visi.com!news.maxwell.syr.edu!dispatch.news.demon.net!demon!ca
>lfp.demon.co.uk!not-for-mail
>From: Nick Leaton <nickle@calfp.co.uk>
>Newsgroups:
> comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.l
>ang.ada,comp.lang.java.tech
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>Date: Mon, 17 Mar 1997 09:39:07 +0000
>Message-ID: <332D113B.4A64@calfp.co.uk>
>References: <332B5495.167EB0E7@eiffel.com> <tz8ohcjv7cc.fsf@aimnet.com>
>NNTP-Posting-Host: calfp.demon.co.uk
>X-NNTP-Posting-Host: calfp.demon.co.uk
>X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m)
>MIME-Version: 1.0
>To: Thomas <nouser@nohost.nodomain>
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>Lines: 81
>Xref: dimensional.com comp.lang.eiffel:7803 comp.object:23425
> comp.software-eng:17269 comp.programming.threads:4199 comp.lang.ada:23371
> comp.lang.java.tech:8859
>Status: N
>
>Thomas wrote:
>
>> convert (horizontal_bias: INTEGER): INTEGER is
>> require
>> horizontal_bias <= Maximum_bias
>> do
>> ...
>>
>> ensure
>> ...
>>
>> end
>>
>> What was required here was a simple check that a function argument was
>> within a certain range. That check could have been expressed as an
>> Ada type declaration and checked by the compiler at compile time, or
>> as a runtime assertion/check. The design team apparently decided that
>> either approach was too costly in terms of design or speed and instead
>> opted for leaving the code unsafe and documenting the conditions under
>> which the function could be used safely. Also, they apparently did
>> not have a practice of annotating their code with assertion statements
>> for testing, and you suggest that they didn't have a standard
>> practice for documenting unchecked preconditions.
>>
>> I don't see how the different notation that Eiffel uses for the same
>> purpose helps. Eiffel's conditions are also enforced either at
>> compile time or at runtime, and exactly the same tradeoffs apply as
>> they do in the Ada program: you incur costs for type conversions and
>> range checks. And if the programmer culture on a project is such that
>> they don't use Ada assertions, why would they use Eiffel
>> preconditions?
>>
>
>Eiffel does type checking at compile time. You can check type at runtime
>but the need to do this is such that you should query if you write code
>that uses this feature.
>
> x ?= y
>
>x will be Void if y does not conform to they type of x.
>
>The point about culture and assertions is an interesting one. I have
>moved to a company that uses Eiffel. Initially I was very sceptical
>about assertions, for the same reason you are, that I don't see people
>using them, or that they remove them when the release the code.
>
>In practice though, you write them because as part of developing
>software they make a huge difference to development. This has an effect
>in various areas.
>
>1) Documentation. You need less of this. Documentation which say 'This
>feature expects this and does that' is no longer need. Documentation
>that is needed is the 'intent' of the routine, and high level intent or
>overviews. There are tools that can produce what is called the short
>form, the code without the implementation built into most compilers.
>These will also produce HTML and other outputs.
The first mistake was to not put the time limit in some human readable
documentation, or if the time limit was documenting then it was not read.
Writing code so it documents itself reduces or eliminates the code
documentation, but this can be done in Ada, EIffel, C, C++ and even
assembly language and FORTRAN. These limits are part of the design
and belong in a Software Requirements/Requirements Verification document
and in the Version Description Document. And these documents must be
reviewed prior to reuse.
>2) Design. Writting assertions makes design easier. This is a personal
>observation and harder to justify. I find being clear about what
>something does helps clear up what I am doing. Having complex
>preconditions is not a good idea, again you probably don't have the
>right structure.
The code is going to say "I am not in my original application and may or
will fail?" Assertions are only going to catch problems if there is:
>3) Debugging / Testing. Running with assertions enabled detects bugs
>earlier. This is the real saver in time and costs.
This is the
>4) Reviews. If you review code, then having the assertions in place
>is very useful. A large part of reviewing C++ is working out what
>assertions have been assumed, and checking code against them. Having
>them written into the code makes this easier.
>
>There are other more complex parts to Eiffels assertion system, in
>relation to inheritance, and soon in relation to parallel processing.
>
>But in conclusion, my experience is that people write assertions in
>their code, because it is effective.
>
>
^ permalink raw reply [relevance 0%]
* Re: Papers on the Ariane-5 crash and Design by Contract
[not found] ` <tz8ohcjv7cc.fsf@aimnet.com>
1997-03-17 0:00 0% ` Nick Leaton
@ 1997-03-17 0:00 11% ` Paul Johnson
1997-03-19 0:00 0% ` Jon S Anthony
2 siblings, 0 replies; 67+ results
From: Paul Johnson @ 1997-03-17 0:00 UTC (permalink / raw)
In article <tz8ohcjv7cc.fsf@aimnet.com>, nouser@nohost.nodomain says...
>What was required here was a simple check that a function argument was
>within a certain range. That check could have been expressed as an
>Ada type declaration and checked by the compiler at compile time, or
>as a runtime assertion/check.
The whole point of Eiffel is that the assertions are more than just a
run-time check. In fact the run-time checking is the least important
aspect of Eiffel assertions. Far more important are the self-documenting
aspects. This is where Ada misses out: the fatal exception occured
because the limitations were not properly documented.
>The design team apparently decided that
>either approach was too costly in terms of design or speed and instead
>opted for leaving the code unsafe and documenting the conditions under
>which the function could be used safely.
They did this by commenting the code, rather than writing it into the
documentation. Furthermore the exception occured (as I understand it)
because the compiler included explicit range checks in the compiled code,
and the programmers had opted not to include manual range checking and
limiting because of CPU limits. In other words they had a choice between
checking it once or twice (redundantly), and the single check option had
catastrophic consequences. The important thing is that neither of these
checks were actually very useful at run-time. The real cause of the
Arianne 5 failure was the policy that any exception be treated as fatal
while identical software was used on both inertial guidence units. Hence
any bug that caused an exception would inevitably lead to self-destruction.
In practice, due to the time at which the exception occured it would have
been better to continue processing because the results in question were not
actually being used. However if they had been in use then its difficult
to see how any kind of run-time checking could have helped: range limiting
only ensures that the wrong results are produced, and this would have been
as fatal as the exception.
[On annotation and documentation]
>And if the programmer culture on a project is such that
>they don't use Ada assertions, why would they use Eiffel
>preconditions?
Because Ada assertions don't form part of the documentation. Eiffel
assertions do. So by writing one piece of code you get both benefits.
Furthermore the "Eiffel culture" is very different to the "Ada culture".
In Eiffel the external assertions are seen as a key component of the
software, while in Ada they are just an optional extra.
> The exception was due to a floating-point error: a conversion from a
> 64-bit integer to a 16-bit unsigned integer, which should only have
> been applied to a number less than 2^16, was erroneously applied to a
> greater number, representing the "horizontal bias" of the flight.
> There was no explicit exception handler to catch the exception, so it
> followed the usual fate of uncaught exceptions and crashed the entire
> software, hence the on-board computers, hence the mission.
>I don't understand these statements at all.
Bertrand is accurately paraphrasing the published report, except for one
point: there was a high-level policy in the Arianne programme that any
exception should cause the shutdown of whatever unit of hardware it
occured in. The assumption seems to have been that the software was
perfect, and so any exception must indicate a hardware flaw. Therefore
the correct thing to do with an exception is to shut down and let the
backup unit take over. Unfortunately the backup in this case was running
exactly the same software and was receiving basically the same data.
Hence they crashed within a fraction of a second of each other.
There was no exception handler: the exception error message was actually
dumped onto the system bus and interpreted by the guidance mechanism as
real data. This would have probably destroyed the rocket anyway, but
the fact that both inertial sensors went permanently down made it
inevitable.
Paul.
--
Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244 +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com> | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk> | standards, all different.
^ permalink raw reply [relevance 11%]
* Re: Papers on the Ariane-5 crash and Design by Contract
[not found] ` <tz8ohcjv7cc.fsf@aimnet.com>
@ 1997-03-17 0:00 0% ` Nick Leaton
1997-03-18 0:00 0% ` Richard Kaiser
[not found] ` <tz8g1xtzx9y.fsf@aimnet.com>
1997-03-17 0:00 11% ` Paul Johnson
1997-03-19 0:00 0% ` Jon S Anthony
2 siblings, 2 replies; 67+ results
From: Nick Leaton @ 1997-03-17 0:00 UTC (permalink / raw)
To: Thomas
Thomas wrote:
> convert (horizontal_bias: INTEGER): INTEGER is
> require
> horizontal_bias <= Maximum_bias
> do
> ...
>
> ensure
> ...
>
> end
>
> What was required here was a simple check that a function argument was
> within a certain range. That check could have been expressed as an
> Ada type declaration and checked by the compiler at compile time, or
> as a runtime assertion/check. The design team apparently decided that
> either approach was too costly in terms of design or speed and instead
> opted for leaving the code unsafe and documenting the conditions under
> which the function could be used safely. Also, they apparently did
> not have a practice of annotating their code with assertion statements
> for testing, and you suggest that they didn't have a standard
> practice for documenting unchecked preconditions.
>
> I don't see how the different notation that Eiffel uses for the same
> purpose helps. Eiffel's conditions are also enforced either at
> compile time or at runtime, and exactly the same tradeoffs apply as
> they do in the Ada program: you incur costs for type conversions and
> range checks. And if the programmer culture on a project is such that
> they don't use Ada assertions, why would they use Eiffel
> preconditions?
>
Eiffel does type checking at compile time. You can check type at runtime
but the need to do this is such that you should query if you write code
that uses this feature.
x ?= y
x will be Void if y does not conform to they type of x.
The point about culture and assertions is an interesting one. I have
moved to a company that uses Eiffel. Initially I was very sceptical
about assertions, for the same reason you are, that I don't see people
using them, or that they remove them when the release the code.
In practice though, you write them because as part of developing
software they make a huge difference to development. This has an effect
in various areas.
1) Documentation. You need less of this. Documentation which say 'This
feature expects this and does that' is no longer need. Documentation
that is needed is the 'intent' of the routine, and high level intent or
overviews. There are tools that can produce what is called the short
form, the code without the implementation built into most compilers.
These will also produce HTML and other outputs.
2) Design. Writting assertions makes design easier. This is a personal
observation and harder to justify. I find being clear about what
something does helps clear up what I am doing. Having complex
preconditions is not a good idea, again you probably don't have the
right structure.
3) Debugging / Testing. Running with assertions enabled detects bugs
earlier. This is the real saver in time and costs.
4) Reviews. If you review code, then having the assertions in place
is very useful. A large part of reviewing C++ is working out what
assertions have been assumed, and checking code against them. Having
them written into the code makes this easier.
There are other more complex parts to Eiffels assertion system, in
relation to inheritance, and soon in relation to parallel processing.
But in conclusion, my experience is that people write assertions in
their code, because it is effective.
--
Nick
^ permalink raw reply [relevance 0%]
* Paige's How To Get An Automatic Ada Waiver memo
@ 1994-10-28 14:22 3% Gregory Aharonian
0 siblings, 0 replies; 67+ results
From: Gregory Aharonian @ 1994-10-28 14:22 UTC (permalink / raw)
Sometime ago DoD Secretary Perry issued a policy memo encouraging the
use of COTS products in defense systems (as opposed to MIL-SPEC equipment).
As Ada is a MIL-SPEC, the few in the DoD who actually pay attention to the
Ada Mandate questioned whether Perry's memo would undermine the Ada Mandate.
To qualify this issue, Ass. Sec. Paige and Und. Sec. Longuemare issued
another memo attempting to clarify this issue and try to show that Perry's
memo is not in conflict with the Ada Mandate. Strangely, their joint memo
of August 26 not only does not clarify the issue, but provides a perfect
mechanism for getting an automatic waiver for the Ada Mandate. Their memo
does reflect how out of touch senior Defense officials are with what is going
on in the software world.
In their memo, Paige and Longuemare write:
"It is DoD policy to use commercial off the shelf (COTS) software
whenever it meets our requirements. However, when COTS software is
not available to satisfy requirements and the DoD must develop
unique software to meet its needs, that software must be written
in Ada in accordance with 3405.1 and 5000.2"
This is a meaningless sentence because no where is software COTS defined,
opening up a loophole wide enough to float an aircraft carrier group through.
Most likely, when these guys think of COTS, they are thinking about packages
like 1-2-3, Wordperfect, DBASE, etc, the very narrow definition of COTS.
However, think of the average Defense application, which will have software
requirements for user interfaces, graphics, database, communications,
networking, signal/image processing, and real time control. For all of
these requirements, there are ample numbers of COTS source code/object code
libraries available in C/C++ and Visual Basic. So if one defines COTS software
in a wider sense as to include COTS source code libraries, then the effect of
Paige and Longuemare's memo is to encourage the use of these non-Ada COTS
source code libraries as a substantial part of Defense programming project.
But at least these types of COTS libraries are fairly well documented and
tested. Not so if one interprets their memo in the loosest sense. There
are a few CDROM publishers who scoop up tons of source code from the Internet
and make it available cheaply (Prime Time Freeware for example, which sells
an Ada CDROM). In a loose sense, a CDROM is COTS software, since it is
commercially available off the shelf and shrinkwrapped. But even I would
argue that this type of stuff doesn't belong anywhere near DoD systems.
But because Paige and Longuemare don't define COTS, DoD programmers and
contractors are free to choose whatever definition they want without any fear
for retribution. This paragraph then does nothing to clarify Perry's memo.
In fact, I could start a business where contractors could write code for
whatever they want and send it to me. I would add some marginal value, shrink
wrap some diskettes, put it on my shelf, and sell it back to the contractor,
who could then validly argue that the software is COTS.
However, all of these non-Ada COTS libraries still need "glue", which for
the most part has to be newly written code that you would expect to fall under
3405.1 and 5000.2 and be in Ada. However, another part of their memo provides
another loophole wide enough to push the Pentagon building through. I quote:
"Use of other programming languages can be considered if proposed
by a contractor as part of his best practices since waivers to the
use of Ada can be granted, where cost-effective, in accordance with
procedures established in the policy referenced above. However,
such proposals require strong justification to prove that the overall
life-cycle cost will be less than the use of Ada will provide".
Again, another meaningless requirement, in this case, because of the lack of
a definition for proving cost-effectiveness. Given the almost non-existent
number of independently verified measures of Ada's cost-effectiveness (as
opposed to scores of ancedotal reports), one could justify the waiver on the
same grounds by citing ancedotal evidence supporting their language choice.
But for most contractors, that is too risky of an argument.
Instead, contractors can turn to the leading Ada vendor for a court-proof
valid justification. Remember that contractors need this justification to
get out of writing the "glue" software in Ada. However, given the large
size of the COTS libraries they will be "gluing", the amount of "glue" code
will not be large, usually under 100,000 lines of code, if that. But thanks
to the language-schizo folks at Rational, a ready waiver justification is
on hand. For if you read Rational's literature and technical reports, they
repeatedly argue that with Rational's tools that you can program as cost
effectively over the life cycle in C++ as you can in Ada (especially if you
supplement Rational's C++ tools with Alsys/Telesoft's C++ GUI tool, Tartan's
C++ signal/image processing libraries, and Intermetrics C/C++ realtime tools).
Thus all you have to do is cite this collective tool set to argue for your
waiver. Since the DoD would publicly have to dispute the non-Ada assertions
of its leading Ada suppliers (extremely unlikely since only unkind words are
said about Greg), then this waiver argument will fly through unopposed. At
that point, you can then argue the equivalence of CASE tools to not use the
above companies' products and use whatever tools are on hand. As a butress
for this argument, you can include TRW's comment from the Ada/C++ Business
yes-man study that by the mid-1990's, C++ would be as cost effective as Ada.
And if that fails, call in whatever favors you have at ARPA, and ask them to
explain to your contractor officer why Ada is a lousy language.
Even better is that some companies like TI(IEF) and Oracle(CDE) have graphical
environments where you "paint" much of the glue code, structured diagrams that
their tools either execute or convert to code. One could argue in the broad
sense that these "paintings" aren't source code and therefore not subject to
3405.1 and 5000.2.
In summary, because Paige's and Longuemare's memo do not explicitly define
"COTS" and "cost-effective", they provide loopholes that make it extremely
easy to get an Ada waiver, for those who bother to worry about doing so.
Mostly likely these two senior officials are unaware of much of what is
happening in the software industry (especially if the only trade shows they
go to are Tri-Ada), and don't realize that the lack of definitions for these
two terms makes their memo a blueprint for obtaining automatic Ada waivers.
So the issue of Perry's memo is still unresolved, providing no guidance
to those who care about Ada, and providing yet another negotiating tools for
those who don't care about Ada. As long as the DoD refuses to encourage open
critical discussion about these issues, this confusion will continue to
undermine Ada acceptance in the DoD. As taxpayers, we should all demand
better memos from such senior officials.
In a related example of senior confusion, in the October 1994 Crosstalk
(where Paige and Longuemare's memo was published), there is another rah-rah
Ada article from AF Dep.Ass.Sec Mosemann on how great Ada is, where he once
again pledges his undying love for Ada. Unfortunately, it conflicts with
his earlier memo on Air Force use of AI where he didn't mention Ada once, it
conflicts with his refusal to comment on why the Air Force's KBSA project is
allowed to continue being mostly non-Ada, and most ironic, in this very same
issue of Crosstalk there is an article from Air Force people at Rome Lab
(home of KBSA) on Rapid Prototyping in which the example used in the article,
a program for space debris, is written in C. I guess the DoD has two Air
Forces. Don't any of you guys talk to each other?
But hey, have fun singing songs at Tri-Ada.
Greg Aharonian
^ permalink raw reply [relevance 3%]
Results 1-67 of 67 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1994-10-28 14:22 3% Paige's How To Get An Automatic Ada Waiver memo Gregory Aharonian
1997-03-15 0:00 Papers on the Ariane-5 crash and Design by Contract Bertrand Meyer
[not found] ` <tz8ohcjv7cc.fsf@aimnet.com>
1997-03-17 0:00 0% ` Nick Leaton
1997-03-18 0:00 0% ` Richard Kaiser
1997-03-18 0:00 ` Nick Leaton
1997-03-19 0:00 ` Richard Kaiser
1997-03-19 0:00 11% ` Fergus Henderson
[not found] ` <tz8g1xtzx9y.fsf@aimnet.com>
1997-03-18 0:00 ` Anders Pytte
1997-03-18 0:00 ` Jean-Marc Jezequel
1997-03-21 0:00 ` Ken Garlington
1997-03-21 0:00 ` Bertrand Meyer
1997-03-23 0:00 ` Anders Pytte
[not found] ` <3335BC24.13728473@eiffel.com>
1997-03-23 0:00 ` Bertrand Meyer
1997-03-25 0:00 9% ` Ken Garlington
1997-03-17 0:00 11% ` Paul Johnson
1997-03-19 0:00 0% ` Jon S Anthony
1997-03-20 0:00 0% ` Paul Johnson
1997-03-20 0:00 0% ` Jean-Marc Jezequel
1997-03-24 0:00 11% ` Ken Garlington
1997-03-19 0:00 0% INFO-ADA Digest - 18 Mar 1997 to 19 Mar 1997 - Special issue Tokoro, David
1997-03-19 0:00 0% INFO-ADA Digest - " Tokoro, David
1997-07-10 0:00 Safety-critical development in Ada and Eiffel Don Harrison
1997-07-11 0:00 ` Don Harrison
1997-07-12 0:00 14% ` Ken Garlington
1997-07-15 0:00 13% ` Don Harrison
1997-07-15 0:00 0% ` Ken Garlington
[not found] <340E2DC5.25D7@worldnet.att.net>
1997-09-12 0:00 4% ` The Red Language Robert A Duff
1999-05-10 0:00 Assertions J & A Richardson
1999-05-10 0:00 ` Assertions Marin David Condic
1999-05-11 0:00 ` Assertions Robert Dewar
1999-05-12 0:00 ` Assertions Tucker Taft
1999-05-12 0:00 ` Assertions Larry Kilgallen
1999-05-13 0:00 11% ` Assertions Nick Roberts
2004-07-26 21:44 [Ann] More Ada0Y packages for Ada95! Martin Dowie
2004-07-27 5:59 ` Martin Dowie
2004-07-28 18:00 9% ` Martin Dowie
2004-07-30 19:50 0% ` Anh_Vo
2004-07-31 17:08 11% ` Martin Dowie
2004-08-02 16:31 0% ` Anh_Vo
2007-05-14 17:57 13% Ada 2005 core packages under GNAT-GPL-2007 Anh Vo
2007-05-14 20:14 9% ` Ludovic Brenta
2007-05-14 20:20 14% ` Martin Dowie
2007-05-14 21:11 9% ` Anh Vo
2007-05-16 3:00 9% ` Randy Brukardt
2007-05-22 14:41 0% ` Anh Vo
2007-05-22 14:50 0% ` Anh Vo
[not found] <407ae64d-3cb3-4310-b59e-f1bbae9910a5@t39g2000prh.googlegroups.com>
2009-01-14 1:33 ` How to put 200 into an integer sub-type of 16 bits (code included) Brian Drummond
[not found] ` <3d3719f4-355c-4094-9902-495d612d46fe@n33g2000pri.googlegroups.com>
2009-01-14 12:47 6% ` Brian Drummond
2009-01-14 12:53 6% ` Brian Drummond
2009-05-24 8:39 Ada vs Eiffel - Ada programmer approach Tomek Walkuski
2009-05-24 16:31 ` Pascal Obry
2009-05-26 13:37 ` Ludovic Brenta
2009-06-04 7:30 ` Hibou57 (Yannick Duchêne)
2009-06-04 7:55 13% ` Ludovic Brenta
2009-06-04 8:45 0% ` Georg Bauhaus
2009-06-04 9:03 0% ` Ludovic Brenta
2009-06-04 13:25 0% ` Robert A Duff
2009-06-04 13:39 0% ` Martin
2011-07-20 10:34 Should representation clauses be complete for each bit? okellogg
2011-07-20 14:51 10% ` Robert A Duff
2011-07-21 7:36 0% ` Martin
2011-07-22 23:50 11% ` Randy Brukardt
2011-07-23 15:12 0% ` Robert A Duff
2011-07-26 21:10 0% ` Randy Brukardt
2011-07-27 16:29 10% Aspect programming Anh Vo
2012-01-13 9:35 How many Ada compiler bugs are here? AdaMagica
2012-01-13 10:00 ` Dmitry A. Kazakov
2012-01-13 10:38 ` georg bauhaus
2012-01-13 11:39 ` Dmitry A. Kazakov
2012-01-13 12:43 11% ` Georg Bauhaus
2012-01-13 13:06 0% ` AdaMagica
2012-06-20 13:39 about the new Ada 2012 pre/post conditions Nasser M. Abbasi
2012-06-20 14:13 ` Dmitry A. Kazakov
2012-06-20 14:24 ` Nasser M. Abbasi
2012-06-20 14:37 ` Dmitry A. Kazakov
2012-06-21 20:32 ` Randy Brukardt
2012-06-22 7:23 ` Dmitry A. Kazakov
2012-06-22 19:41 ` Randy Brukardt
2012-06-22 23:08 ` Dmitry A. Kazakov
2012-06-23 10:46 ` Georg Bauhaus
2012-06-23 11:01 ` Dmitry A. Kazakov
2012-06-24 14:59 ` Georg Bauhaus
2012-06-24 16:06 ` Dmitry A. Kazakov
2012-06-24 19:51 ` Georg Bauhaus
2012-06-25 8:08 ` Dmitry A. Kazakov
2012-06-25 10:17 ` Georg Bauhaus
2012-06-25 11:54 ` Dmitry A. Kazakov
2012-06-25 14:08 ` stefan-lucks
2012-06-25 14:36 ` Dmitry A. Kazakov
2012-06-25 16:26 11% ` stefan-lucks
2012-06-25 19:42 0% ` Dmitry A. Kazakov
2014-05-13 11:22 10% Dynamic_Predicate failure -> Assertion_Error? Jacob Sparre Andersen
2014-05-13 21:26 10% ` Randy Brukardt
2017-08-03 5:45 Community Input for the Maintenance and Revision of the Ada Programming Language Randy Brukardt
2017-08-28 23:49 ` faryumg
2017-09-02 10:49 ` Vincent DIEMUNSCH
2017-09-02 11:21 9% ` Johan Söderlind Åström
2017-09-02 15:22 0% ` Vincent DIEMUNSCH
2017-09-02 17:19 0% ` Jeffrey R. Carter
2017-09-04 20:52 0% ` Johan Söderlind Åström
2017-09-03 1:30 0% ` Randy Brukardt
2017-09-06 15:02 0% ` Johan Söderlind Åström
2017-09-06 21:21 0% ` Randy Brukardt
2017-09-03 1:35 0% ` Randy Brukardt
2017-09-03 10:32 0% ` Alejandro R. Mosteo
2017-08-29 20:28 win32 interfacing check (SetClipboardData) Xavier Petit
2017-08-30 16:04 ` Dmitry A. Kazakov
2017-08-30 18:41 8% ` Xavier Petit
2017-08-30 21:17 0% ` Dmitry A. Kazakov
2017-09-01 12:51 0% ` Xavier Petit
2018-08-10 10:29 11% GNAT bug with assertions AdaMagica
2018-08-10 14:23 0% ` Anh Vo
2020-04-19 9:28 11% GNAT CE 2019 bug: Predicate check not performed AdaMagica
2020-04-19 22:31 0% ` Anh Vo
2020-04-19 22:32 0% ` Anh Vo
2021-01-05 11:04 Lower bounds of Strings Stephen Davies
2021-01-06 3:08 ` Randy Brukardt
2021-01-06 9:13 ` Dmitry A. Kazakov
2021-01-07 0:17 6% ` Randy Brukardt
2021-06-01 20:18 5% ANN: SweetAda 0.7 released Gabriele Galeotti
2022-11-10 19:25 Running Python code from GPRBuild (Calling from GNAT Studio) Rego, P.
2022-11-10 21:57 ` Dmitry A. Kazakov
2022-11-11 10:25 ` Rego, P.
2022-11-11 11:04 ` Dmitry A. Kazakov
2022-11-11 11:28 ` Rego, P.
2022-11-11 13:30 ` Dmitry A. Kazakov
2022-11-11 13:40 ` Dmitry A. Kazakov
2022-11-11 18:12 8% ` Rego, P.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox