ANNOUNCEMENT - GNAT 3.13p availability

ANNOUNCEMENT - GNAT 3.13p availability

[Bernard Banner]

           Announcing GNAT version 3.13p

Ada Core Technologies announces the availability of version
3.13p of GNAT. This version of GNAT is derived from GNAT
Professional version 3.13a1, and like previous public
versions of GNAT is made freely available with the specific
intention of supporting student use and academic research
use of the Ada 95 language.

The public version of 3.13p is available for the following
targets in binary form:

    Sparc Solaris
    x86 Linux
    Windows 95/98/NT/2000

These versions may be obtained from the usual download
sites for public GNAT releases. Check cs.nyu.edu ftp
directories pub/gnat for details.

The following are new features in version 3.13p

  The package GNAT.Regpat has been enhanced to provide an almost full support
  for Perl-like regular expressions, including several new constructs.

  On unix systems, it is now possible to install GNAT at any location
  without setting any environment variable.

  A warning is issued for the use of Import/Export_Valued_Procedure if
  the default Ada convention is used, since it makes no sense to use
  convention Ada for such a procedure, the only point of the feature
  is to interface with foreign convention procedures. This prevents
  hard to find errors resulting in incorrect behavior at run time.

  A new style switch -gnatyn (STANDARD_CASING in the VMS version) checks
  that all entities from package Standard are cased in a manner consistent
  with the way this package is presented in the Ada Reference Manual.

  A simple way of interfacing with C++ is now documented in the user's
  guide and has been added to the examples directory.

  A new gnatmake switch (-s) causes recompilation of a file if its
  compilation options (e.g. optimization level) have changed.

  A new gnatdll switch (-k) removed Stdcall @nn suffix from the
  import library's exported names.

  A new GNAT library package (GNAT.Float_Control in file g-flocon.ads)
  provides an interface for resetting the floating-point processor into
  the required mode.

  A new GNAT library package (GNAT.Exceptions in file g-except.ads)
  provides a mechanism for raising predefined exceptions with messages
  from Pure units.

  A new pragma, Suppress_Debug_Info, provides for suppressing debugging
  information for selected entities.

  Additional optimization circuits in aggregate handling result in many
  more aggregate assignments being handled in place, instead of generating
  an extra temporary.

  The GNAT Reference manual now contains summary documentation of the GNAT
  library routines. The primary documentation is still in the specs of the
  relevant packages, but the document summarizes what facilities are
  available.

  The package Ada.Strings.Unbounded.Text_IO is now documented in the
  GNAT reference manual.

  A new package Ada.Strings.Wide_Unbounded.Wide_Text_IO has been added
  to provide Wide_Text_IO facilities for Unbounded_Wide_String.

  The -mlongcall switch as well as the __shortcall__ attribute is now provided
  on all powerpc ports. See the GCC documentation for more details.

  The Linker_Options pragma can now take multiple options, which are
  guaranteed to apear in the sequence given in the pragma.

  The gnatbind -E option (stack tracebacks) is now supported under
  Windows NT.

  New switches -gnatwa and -gnatwA are available to turn all
  optional warnings on/off respectively.

  The syntax for the -gnatw warning switch now allows a string of
  options after the w. For example -gnatwaLe turns on all optional
  warnings except elaboration warnings and considers warnings to be
  errors.

  The generated code for many slice assignments has been improved, resulting
  in considerably improved execution time on most targets.

  The generated code for multi-dimensional arrays has been improved,
  significantly improving performance in many situations.

  The compiler now does a much more effective job of suppressing checks
  in array references in loops where the arrays involved are parameters
  that are unconstrained array types, or pointers to unconstrained arrays.

  On VxWorks cross-compilers, a new package called Interfaces.VxWorks provides
  provides a limited binding to the VxWorks API. In particular, it interfaces
  with the VxWorks hardware interrupt facilities.

  The package GNAT.Regexp no longer has any size limitation, and can handle
  complex regular expressions.

  A new warning switch -gnatwc turns on warnings for relational and
  membership operators appearing in statements (e.g. if statements)
  whose results are known at compile time to be always true or
  always false.

  A new pragma Style_Checks allows selection of style checks in a manner
  similar to the existing compiler switch, and also allows the style
  checks to be temporarily turned off and then turned back on again.

  The binary releases now contain the necessary headers to compile the
  C files in the runtime without having to do a full build of GNAT from
  sources.

  Makefile.adalib now also recompiles the C part of the GNAT run time,
  providing the ability to rebuild completely the GNAT libraries with the
  binary distribution.

  Makefile.adalib is now available for cross compilers, as well as the
  native versions of GNAT

  The -gnatwu switch now also provides warnings about possible access to
  uninitialized out parameters.

  The -gnatyk switch (check identifier casing) error messages now contain
  a source location reference to the definition of the relevant identifier.

  It is now permissible to specify the non-default Bit_Order for record
  subtypes. Component clauses for such types must either specify an
  integral number of bytes, or the component must lie entirely within
  one byte. Note that, in accordance with the RM, no reordering of bytes
  is done, the only effect is to renumber bits. This feature is therefore
  only of limited use in dealing with big/little-endian interfacing.

  Default_Bit_Order is now static. This is strictly a violation of the RM
  requirement that it be non-static, but everyone agrees this was a mistake,
  and an AI is expected to "fix" this mistake. Other Ada 95 compilers are
  already consistent with this modified interpreation of the RM.

  Florist has been ported to Solaris 7 and HP-UX 11.00

  GNAT now fully supports HP-UX 11.00, including a dual tasking run time
  that provides access to the DCE run time for compatibility with HP-UX 10.20,
  and to the POSIX pthread run time.

  Interrupt handling on HP-UX has been rewritten to provide a more powerful
  and less restrictive signal handling. In particular, the signals SIGIO and
  SIGPIPE can now be handled via Ada.Interrupts.

  The listing generated by the -gnatR switch now includes alignment values
  for array and record types.

  The NT version of GNAT now generates object files that are fully compatible
  with the standard Microsoft linker, so this linker can be used instead of
  the GNU ld program to build NT executables.

  The default stack size on NT for tasking program has been reduced to 8Mb
  (instead of 32Mb). This increase the default maximum number of tasks
  from approximately 60 to a value around 250.

  The gnathtml tool can now read the list of files to convert from a file,
  eliminating the command line length problem on some systems.

  The parent type of derived types is now recorded in the cross-reference
  section of the ali files. The new ali format is backward compatible with
  the previous one.

  The gnatfind and gnatxref tools have been extended to display the parent
  type of derived types. Furthermore gnatfind is now able to display the full
  type derivation informations for a specific type.

  Shared libraries are now provided as an option (via the -shared gnatbind
  switch) on four additional targets: Solaris x86, Solaris sparc, Linux and
  SCO UnixWare.

  New restrictions No_Implicit_Conditionals and No_Implicit_Loops have
  been added for greater control over generated code. This is particularly
  useful in a safety-critical/certification environment using GNORT (GNAT
  with no run time)

  The performance of the elementary trigononmetric functions has been
  substantially improved.

  A new section has been added to the GNAT Reference Manual providing
  a complete description of the set of representation pragmas and
  pragmas that are accepted by GNAT, and their effect.

  The implementation of the ASIS Data Decomposition Annex is now complete,
  with all queries fully supported.

  More static checking is now done for pragma Restrictions (No_Recursion),
  and most common cases are now detected and flagged as illegalities.

  A new package GNAT.Calendar is provided. It deals with Hour, Minute,
  Seconds, Day_Of_Week, Day_In_Year, Week_In_Year. There is also two
  functions to do conversions between Duration and C timeval struct.

  A new package GNAT.Calendar.Time_IO is provided. This package implements
  formatted output of Ada.Calendar.Time. The format string uses a format
  similar to the one used by the date UNIX command.

  The gnatdll tool now accepts the -I switch to search source and
  object files in specified directories.

  The optimization of checks has been significantly improved, and many
  unnecessary checks, particularly in connection with type conversions and
  the use of the pos operator, have been removed.

  The traceback stored in the exception occurrence (using the gnatbind -E
  switch) now gives accurate values in the case of a reraise.

  The structure used to hold task data has been split to allow restricted
  tasking implementations to use less storage for each task created.

  Enumeration representation clauses for types derived from Boolean
  are now fully supported.

  Variable shift instructions are now generated for multiplications or
  divisions by powers of 2 (e.g. x * 2 ** y, where y is Natural).

  External symbol names and debugging symbols are now more fully qualified.
  This avoids some peculiar naming conflicts for example in the case where
  there is a child package and nested package with the same name, and also
  improves the behavior of gdb when fully qualified names are given.

  An extended form of the Source_File_Name pragma permits handling the
  unusual case where a subunit and child unit have identical qualified
  names. This is unusual, but is allowed by the rules of the language,
  although both versions cannot appear in a single partition.

  The OpenVMS version of GNAT now fully supports the use of mixed-case
  external names. This solves a number of compatibility problems in
  this area, which could show up as unexpected duplicate names.

  A new pragma External_Name_Casing is provided for controlling the
  casing of external names. This is primarily for use in OpenVMS systems,
  but is available in all implementations.

  A new pragma Extensions_Allowed (ON | OFF) is provided for local control
  of whether language extensions are allowed. This pragma may also be used
  as a configuration pragma (e.g. in the gnat.adc file) to control the use
  of extensions for a series of compilations.

  The -gnatwu flag now separately checks specs to make sure that a with in
  a spec is now actually used in the spec. If the with is used only in the
  body, the warning suggests moving it to the body.

  The renaming of a constant was implemented as the declaration of a local
  variable whose initial value was the constant being renamed. This avoids
  an indirection, but is inefficient if the constant being renamed is large.
  This optimization is now restricted to objects that fit in registers.

Claw & Re: ANNOUNCEMENT - GNAT 3.13p availability

[tmoran]

Gnat 3.13p has difficulty when a public primitive is overridden in
a private part.  From the Claw mailing list:

>The recently released GNAT 3.13p contains an inheritance bug which prevents
>the successful compilation of Claw (all versions). The problem has been
>reported to the maintainers of GNAT. The problem will cause various
>compilation errors when compiling Claw and programs using Claw. Generally,
>the bug manifests itself by reporting a legal call as if it was a call to an
>undefined subprogram, or a call with an incorrect parameter list.
>
>We are working to create workarounds for the bug (we think we can do so
>without making the workaround version incompatible with the regular version)
>for both the demo and release versions of Claw. In the mean time, we
>recommend avoiding GNAT 3.13p -- continue to use GNAT 3.12p.
>
>We regret any inconvenience.
>
>                        Randy Brukardt
>                        R.R. Software, Inc.
Tom Moran

Re: Claw & Re: ANNOUNCEMENT - GNAT 3.13p availability

[Ted Dennison]

In article <ZPFk5.94902$i5.1405866@news1.frmt1.sfba.home.com>,
  tmoran@bix.com wrote:
> Gnat 3.13p has difficulty when a public primitive is overridden in
> a private part.  From the Claw mailing list:
>
> >The recently released GNAT 3.13p contains an inheritance bug which
> >prevents the successful compilation of Claw (all versions). The

It turns out that OpenToken 2.0 and earlier suffer from this same
problem. I'm curious if it really is a gnat bug though. I could see
someone making a case that since the caller's view of the routine in
question is still abstract, only dynamicly dispatching calls are legal.

Of course the latest version of Gnat is the only compiler that has
*ever* complained about this. But that doesn't nessecarily mean that it
is wrong.

I'd be interested in a Language Laywer ruling on this. Or failing that,
I'd like to know if ACT does consider this a bug. I've put a bit of a
hack work-around in the new version of OpenToken. But if its not a
compiler bug, I should probably put in a real fix.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Claw & Re: ANNOUNCEMENT - GNAT 3.13p availability

[Simon Wright]

Ted Dennison <dennison@telepath.com> writes:

> In article <ZPFk5.94902$i5.1405866@news1.frmt1.sfba.home.com>,
>   tmoran@bix.com wrote:
> > Gnat 3.13p has difficulty when a public primitive is overridden in
> > a private part.  From the Claw mailing list:
> >
> > >The recently released GNAT 3.13p contains an inheritance bug which
> > >prevents the successful compilation of Claw (all versions). The
> 
> It turns out that OpenToken 2.0 and earlier suffer from this same
> problem. I'm curious if it really is a gnat bug though. I could see
> someone making a case that since the caller's view of the routine in
> question is still abstract, only dynamicly dispatching calls are legal.

I wonder whether my article <x7v4s5af41m.fsf@pogner.demon.co.uk>
refers to the same problem? Seems to be in the same ballpark, but that
covers a lot of ground ..

> I'd be interested in a Language Laywer ruling on this. Or failing that,
> I'd like to know if ACT does consider this a bug. I've put a bit of a
> hack work-around in the new version of OpenToken. But if its not a
> compiler bug, I should probably put in a real fix.

I think the LL's are all on vacation. Hope you're having fun, guys!

Re: Claw & Re: ANNOUNCEMENT - GNAT 3.13p availability

[Ted Dennison]

In article <x7vem3rwssz.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> Ted Dennison <dennison@telepath.com> writes:
>
> > In article <ZPFk5.94902$i5.1405866@news1.frmt1.sfba.home.com>,
> >   tmoran@bix.com wrote:
> > > Gnat 3.13p has difficulty when a public primitive is overridden in
> > > a private part.  From the Claw mailing list:
> > >
> > > >The recently released GNAT 3.13p contains an inheritance bug
which
> > > >prevents the successful compilation of Claw (all versions). The
> >
> > It turns out that OpenToken 2.0 and earlier suffer from this same
> > problem. I'm curious if it really is a gnat bug though. I could see
> > someone making a case that since the caller's view of the routine in
> > question is still abstract, only dynamicly dispatching calls are
legal.
>
> I wonder whether my article <x7v4s5af41m.fsf@pogner.demon.co.uk>
> refers to the same problem? Seems to be in the same ballpark, but that
> covers a lot of ground ..

Do you mean the message titled "Delegating operations to parent (generic
formal type)" Dated 07/13/2000?

That apppears to be nearly the opposite problem. There Gnat (3.12 and
3.13) is accepting code other compilers aren't. I can't help with
Apex. But given my experience the last couple of years getting another
intermetrics-driven compiler to accept the Booch components, I
definitely wouldn't trust that ancient version of ObjectAda.

Thanks, btw. Whenever I think I've made the inter-relationships between
my types and packages in OpenToken too complex, I can always count on a
jaunt through Booch to cheer me up. :-)


--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Claw & Re: ANNOUNCEMENT - GNAT 3.13p availability

[Simon Wright]

Ted Dennison <dennison@telepath.com> writes:

> Thanks, btw. Whenever I think I've made the inter-relationships
> between my types and packages in OpenToken too complex, I can always
> count on a jaunt through Booch to cheer me up. :-)

Curses, my master plan has been detected!

Re: Claw & Re: ANNOUNCEMENT - GNAT 3.13p availability

[Simon Wright]

Ed Falis <efalis@pop.ne.mediaone.net> writes:

> Ted Dennison <dennison@telepath.com> writes:
> > Thanks, btw. Whenever I think I've made the inter-relationships
> > between my types and packages in OpenToken too complex, I can always
> > count on a jaunt through Booch to cheer me up. :-)
> 
> Simon Wright <simon.j.wright@amsjv.com> wrote:
> > Curses, my master plan has been detected!
> 
> Indeed. Whenever I really feel like twisting my brain up, I visit
> them, and some of the interesting ways I've seen them put to use ;-)

I'm aware of several places where people have used the BCs in projects
(ie, I've had bug reports). Perhaps you know more (including what the
projects actually _do_!) Do you think people have trouble because of
the lack of documentation, or is it just inventiveness?

> On a more serious level, I guess it raises some interesting
> questions about the price of generality.

I don't think I can properly appreciate the point you and Ted are
making here? On the whole there is one (public) type per package, so
if there was a new Container type Drawer I would expect to generate

  BC.Containers.Drawers             abstract Drawer
  BC.Containers.Drawers.Bounded     concrete Bounded_Drawer
  BC.Containers.Drawers.Dynamic     concrete Dynamic_Drawer
  BC.Containers.Drawers.Unbounded   concrete Unbounded_Drawer

and possibly either

  BC.Containers.Drawers.Bounded.Guarded        concrete Guarded_Bounded_Drawer
  BC.Containers.Drawers.Bounded.Synchronized   ...
  BC.Containers.Drawers.Dynamic.Guarded
  BC.Containers.Drawers.Dynamic.Synchronized
  BC.Containers.Drawers.Unbounded.Guarded
  BC.Containers.Drawers.Unbounded.Synchronized

(I'm working on just having new generics

  BC.Containers.Drawers.Guarded
  BC.Containers.Drawers.Synchronized

to be instantiated with a concrete Drawer form, but the compilers are
giving me grief).

I do agree that this is untidy, you would have thought some mixin
techniques would do the trick, but that wasn't really the brief.


If there's a topic worthy of discussion here, maybe we should retitle
the thread!

-S

Booch Component Complexity (was: Claw & Re: ANNOUNCEMENT - GNAT 3.13p availability)

[Ted Dennison]

In article <x7vaeed68kt.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> Ed Falis <efalis@pop.ne.mediaone.net> writes:
> > On a more serious level, I guess it raises some interesting
> > questions about the price of generality.
>
> I don't think I can properly appreciate the point you and Ted are
> making here? On the whole there is one (public) type per package, so

I don't think anyone's making a complaint exactly. Its not like the
components are more complex than they need to be. They are just not for
beginners.

For instance, I didn't have much trouble using them here at work. It
took an afternoon of spelunking to figure out what I needed to do, which
was really time well-spent because I learned a *lot* about Ada95 looking
through that code.

But I've been writing Ada code for over 10 years. Most of the rest of my
co-workers are afraid of them.

Another thing I should mention is that I've found OpenToken + Booch
Compoents to be a very powerful combination. For instance, we've got a
package that reads configuration item defintions (string or integer)
from a config file at startup, loads them into a dictionary, then passes
their valule back to clients when requested. I wrote it quite quickly in
about 130 lines of code (22 of which were "with" statements!).


--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Claw & Re: ANNOUNCEMENT - GNAT 3.13p availability

[Ed Falis]

Ted Dennison <dennison@telepath.com> writes:
> Thanks, btw. Whenever I think I've made the inter-relationships
> between my types and packages in OpenToken too complex, I can always
> count on a jaunt through Booch to cheer me up. :-)

Simon Wright <simon.j.wright@amsjv.com> wrote:
> Curses, my master plan has been detected!

Indeed. Whenever I really feel like twisting my brain up, I visit them,
and some of the interesting ways I've seen them put to use ;-)

On a more serious level, I guess it raises some interesting questions
about the price of generality.

- Ed

Re: Claw & Re: ANNOUNCEMENT - GNAT 3.13p availability

[tmoran]

>It turns out that OpenToken 2.0 and earlier suffer from this same
>problem. I'm curious if it really is a gnat bug though. I could see
>someone making a case that since the caller's view of the routine in
>question is still abstract, only dynamicly dispatching calls are legal.
  I reported the problem to ACT some months ago and have been assured
that they have a fix, which I understand will be in the next Gnat release.