Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Robert Dewar]

Thomas Koenig says

<<The main problem of porting GNAT to egcs is the lack of a good test
suite.  Anybody care to donate one? :-)>>

What a totally bizarre question ... the answer of course is to use the
publicly available ACVC suite. What is surprising is that the people 
working on this, who presumably should know *something* about Ada,
are unaware of this suite!

GNAT 3.07 MsDos/DJGPP bug report to whom?

[Steve Whalen]

I've found a bug in the Ada95 GNAT 3.07 MsDos / DJGPP implementation.

The bug and it's cause are tacked on to the end of this message.

Short summary: You can't compile *any* program that calls
Ada.Calendar.Clock with -gnata AND -gnatn enabled.

I know ACT no longer supports MsDos versions of GNAT.

I know GNAT 3.07 is an old version with many bugs squashed in versions
since then.

I use GNAT 3.07 only because that's the latest one available for
MsDos. I use GNAT 3.10 on OS/2 and Linux and other platforms.

I'm trying to figure out who to report this bug to because it's kind
of a pain (it's not unusual for me to use the clock, and I almost
always enable assertions while developing / debugging).

Because of the bug's location in the system primitives, I suspect it
might survive an attempt at an upgrade to an MsDos version of GNAT
3.10 unless the "porter" were aware of it (assuming that someone even
attempts to port GNAT 3.10 to MsDos)

Does anyone have any suggestions as to who I should report it to?
ACT's officially out of the MsDos business.  I haven't heard if
Mike/GW are planning on porting GNAT 3.10 to MsDos.  I don't think the
DJGPP people care (my compliments to the DJGPP people, I'm impressed
with how much they've been able to make sloppy old MsDos do!).

I understand that ACT's paying customers probably don't have MsDos as
a high priority target, but GNAT for MsDos is sure handy to have
around.  I hope GW or someone continues to package an MsDos version of
GNAT for new releases.

I'd like to make a point I haven't seen elsewhere in the debate over
the value of an MsDos version of GNAT.  While I agree that Win32 and
UNIX and other platforms are the commercially viable targets of
choice, I believe MsDos has much value as a lowest common denominator
*executable* format, especially for portability.

I have a number of utilities that I need to be able to run on
different platforms.  With GNAT for MsDos available, it's easy: Once
I've completed my development using OS/2 or Linux or whatever, all I
have to do is substitute one small operating system dependency package
and run "make" on each platform.

It works great even for MsDos with GNAT 3.07 except for the occasional
bug I run into (like this one).  Bottom line: when I run into such a
bug it means I can't have a copy of that utility that will run in
MsDos.

If I *have* an MsDos version of a program, I can execute it on most
any platform (Linux using DosEmu, OS/2 and Windows 95 in their MsDos
box, etc.), so I try to take MsDos versions everywhere with me.  I got
tired of being at a customer's site and finding out I had diskettes
with every executable format EXCEPT the one I needed to run on the
borrowed system...

Now I try to keep an MsDos version handy even though I don't use it
much on my own machine.

I really want Ada95 / GNAT to be the language I use for my primary
utilities whenever possible. Lack of ability to produce an MsDos
executable from GNAT will make that more and more difficult over
time...


...  HERE's the BUG in GNAT 3.07 for MsDos / DJGPP ...

D:\GNAT\GNAT307S\EXAMPLES>gnatmake diners -gnata -gnatn
gcc -c -gnata -gnatn diners.adb
gcc -c -gnata -gnatn room.adb
s-timope.adb:64:29: operator for type "Interfaces.C.int" is 
                    not directly visible

s-timope.adb:64:29: use clause would make operation legal
s-timope.adb:65:09: incompatible types in short-circuit expression
d:/gnat/bin/gnatmake.exe: "room.adb" compilation error

... caused by:

s-timope.adb from GNAT 3.07 for MsDos in ez2load files

... snip ... 

--  This is a DOS (FSU THREAD) version of this package.

with System.Error_Reporting;
--  used for Shutdown

with System.OS_Interface;

with Interfaces.C;

package body System.Time_Operations is

   use System.Error_Reporting;
   use System.OS_Interface;
--   use Interfaces.C;           <---   makes the "=" operator in pragma
                                        Assert below invisible when 
                                        -gnata AND -gnatn enabled...

   -----------
   -- Clock --
   -----------

   function Clock return Duration is
      TS     : aliased timespec;
      Result : Interfaces.C.int;

   begin
      Result := clock_gettime (CLOCK_REALTIME, TS'Unchecked_Access);
      pragma Assert (Result = 0
        or else Shutdown ("GNULLI failure---clock_gettime"));
      return To_Duration (TS);
   exception
   when others =>
      pragma Assert (Shutdown ("exception in Clock"));
      return 0.0;
   end Clock;

... snip ...


-- 
{===----------------------------------------------------------------------===}
                    Steve Whalen     swhalen@netcom.com
{===----------------------------------------------------------------------===}

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Robert Dewar]

Peter said

<<R o b e r t ,

y o u  w i l l  n o t  g e t  r i d  o f  t h i s    :-)   :-)   :-)>>


I realize the smileys are here. But just to be clear. Ada Core Technologies
has dropped support for the DOS port of GNAT, and will no longer be providing
ports of the GNAT technology to the DOS system.

If some volunteer wishes to pick up the pieces and do a later port than
3.07, that's certainly welcome. There are a number of unsupported volunteer
ports for obsolete operating systems, where obsolete = still in use by a
band of enthusiasts (e.g. Amiga), and there is no reason why the DOS port
should not join these if someone is willing to put in the work.

Robert Dewar
Ada Core Technologies

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Thomas Koenig]

In comp.lang.ada, swhalen@netcom.com (Steve Whalen) wrote:

>(assuming that someone even attempts to port GNAT 3.10 to MsDos)

One group which might take up that task is the egcs group
(http://www.cygnus.com/egcs/).  I don't know wether anybody is working
on an MS-DOS version of egcs, and there's only been some very prelimiary
work of integrating GNAT 3.10.  Still, it won't hurt to ask.

The main problem of porting GNAT to egcs is the lack of a good test
suite.  Anybody care to donate one? :-)
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
Harrassing E-Mail may be posted.  If you don't like to see that, don't
send me E-Mail.

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Robert Dewar]

Thomas Koenig said

<<<<The main problem of porting GNAT to egcs is the lack of a good test
suite.  Anybody care to donate one? :-)>>>>

Porting GNAT to egcs should be a trivially easy excercise for anyone
with some familiarity with GNAT (the current GNAT works fine with many
different versions of GCC -- providing EGCS is reasonably current with
respect to the FSF snapshots, there should be no problem (all the
necessary changes for GNAT show up in the GCC snapshots essentially
immediately).

As for the test suite, a most bizarre question -- the answer is of course
that you should use the publicly available ACVC suite -- what is puzzling
is that anyone working with Ada 95 would ask this question!

The only barrier to getting a port of GNAT to DOS is having a sound
DJGPP/GCC combination to build on. We got stuck because of a bug in
DJGPP signal handling that never seemed to have got fixed (apparently
it affected only Ada). Of course building a non-tasking version for
DOS is again a trivial excercise if you have any familiarity with GNAT.

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Gautier]

I agree with your preoccupations!

I see 3 other advantages for a DOS version:

- speed
- the system takes a small and fixed amount of RAM - win 95 takes more than
  the half of RAM, at least with 32 MB!
- direct access to video devices

(I'm using GNAT for scientific and graphical applications...)

-- 
Gautier

--------
Homepage: http://www.unine.ch/math/Personnel/Assistants/Gautier/Montmollin.html
Software: http://www.unine.ch/math/Personnel/Assistants/Gautier/Gaut_FTP.htm

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Peter Hermann]

Gautier (Gautier.DeMontmollin@maths.unine.ch) wrote:
> I agree with your preoccupations!

> I see 3 other advantages for a DOS version:

> - speed
> - the system takes a small and fixed amount of RAM - win 95 takes more than
>   the half of RAM, at least with 32 MB!
> - direct access to video devices

> (I'm using GNAT for scientific and graphical applications...)

R o b e r t ,

y o u  w i l l  n o t  g e t  r i d  o f  t h i s    :-)   :-)   :-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Larry Kilgallen]

In article <dewar.877607416@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> perhaps that is true in some countries. In the US, over 90% of PC's are
> now running Windows 95 according to some reports.

Even without Robert's background in math, I detect a conflict with
printed reports that a majority of Corporate PCs running Windows
are running Windows 3.1.  Surely home users do not account for
80% of PC usage !

Larry Kilgallen

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Robert Dewar]

<<Even without Robert's background in math, I detect a conflict with
printed reports that a majority of Corporate PCs running Windows
are running Windows 3.1.  Surely home users do not account for
80% of PC usage !>>

The figure seemed high to me, but was widely quoted in connection with
the recent anti-trust dealings involving microsoft. I have not investigated
to see if the quoted figure of 90% comes from the justice department, and
it is always possible that it is distorted. I must say that my experience
is that although these uncited "printed reports" saying that a majority
of corporate PC's are running Windows 3.1 may have been right 12 months
ago, these days, most corporate environments I interact with are running
either NT or Win95.

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Richard Kenner]

In article <62lnnk$gv2@fg70.rz.uni-karlsruhe.de> Thomas.Koenig@ciw.uni-karlsruhe.de writes:
>In comp.lang.ada, swhalen@netcom.com (Steve Whalen) wrote:
>
>>(assuming that someone even attempts to port GNAT 3.10 to MsDos)
>
>One group which might take up that task is the egcs group
>(http://www.cygnus.com/egcs/).  I don't know wether anybody is working
>on an MS-DOS version of egcs, and there's only been some very prelimiary
>work of integrating GNAT 3.10.  Still, it won't hurt to ask.

It won't hurt to ask, but I think it would be very bad if they said
"yes"!

The egcs project started out with a very valid and well-defined
purpose: to provide a framework where very experimental patches to GCC
can be developed and debugged without slowing down mainstream GCC
development (which is normally fast paced).  That's a very worthwhile
goal and something that is very achievable.

However, over time, it seems like egcs has become a "kitchen sink"
project.  For example, a lot of the g77 work has moved there.  And
yes, they are also fiddling with GNAT somewhat.

The more this trend continues, the more egcs will have lost its focus.
It will become harder and harder to manage this project in a way that
will produce anything of value to anybody other than the fiddlers who
are working with the compilers.

Moving into working on a language-specific run-time library for what
is essentially an obsolete system seems a very large distraction for
that project.

>The main problem of porting GNAT to egcs is the lack of a good test
>suite.  Anybody care to donate one? :-)

Well, there's ACVC.  That's a reasonably good test of tasking, but is a
poor test of an Ada backend.

Re: GNAT 3.07 MsDos/DJGPP bug report to whom?

[Jerry van Dijk]

In article <dewar.877638631@merv> dewar@merv.cs.nyu.edu writes:

>I must say that my experience
>is that although these uncited "printed reports" saying that a majority
>of corporate PC's are running Windows 3.1 may have been right 12 months
>ago, these days, most corporate environments I interact with are running
>either NT or Win95.

Experiences differ.

The 10 largest financial global corporations over here are for 90%
still at 3.11. Reason: a reasonably sized corporation would have to
invest a couple of hundred million dollar in the upgrade to Win95,
without a matching functionality or productivity gain.

--

-- Jerry van Dijk | Leiden, Holland
-- Consultant     | Team Ada
-- Ordina Finance | jdijk@acm.org