Re: DEC Ada V3.3

Re: DEC Ada V3.3

[Rob Kirkbride]

This is the sort of email that worries me. We have just upgraded to 3.3
in fact. We do have bits of code that interface with C and pass strings
back and forth. On todays evidence, that stuff still seems to work. We
have identified one problem that DEC have initially said was a feature.
It concerns the use of Text_Io.Put, it does not seem to flush these
until the program has finished running - even if a Text_Io.Get_Line is
done! Has anyone else spotted this - how did you fix it?

We get library corruption problems every couple of weeks generally when
we have obsoleted some base types files several times. Anyone get
similar results?


In article <321C3BC6.1897@dial.eunet.ch>, Alan Paterson
<paterson@dial.eunet.ch> writes
>Has anyone else experienced problems with the DEC-Ada compiler 
>when exporting and importing subprograms with STRING parameters?
>
>(We use these pragmas in order to construct and reference 
>shareable images on VMS)
>
>With Version 3.2 it worked perfectly. Now that we have installed 
>V3.3 we get nothing but access violation errors!
>
>We are currently trying to prove to Digital that an error is in 
>fact present (I'm sure that many of you will know that this is a 
>non-trivial task :-) but if anyone out there has had similar 
>experiences, perhaps we could get together?
>

-- 
Rob Kirkbride

DEC Ada V3.3

[Alan Paterson]

Has anyone else experienced problems with the DEC-Ada compiler 
when exporting and importing subprograms with STRING parameters?

(We use these pragmas in order to construct and reference 
shareable images on VMS)

With Version 3.2 it worked perfectly. Now that we have installed 
V3.3 we get nothing but access violation errors!

We are currently trying to prove to Digital that an error is in 
fact present (I'm sure that many of you will know that this is a 
non-trivial task :-) but if anyone out there has had similar 
experiences, perhaps we could get together?

-- 
Alan Paterson
Berne, Switzerland

Re: DEC Ada V3.3

[Mats Weber]

We also have problems with DEC Ada V3.3 (unexplained Contraint_Errors,
unpredictable behavior, duplicate symbols on link of optimized code,
access violations, etc.) and we are seriously considering going back to
3.2.

3.2 also has its problems for us: some of our components won't compile
with /optimize.

--Mats

Re: DEC Ada V3.3

[Ted Dennison]

Rob Kirkbride wrote:
> 
> It concerns the use of Text_Io.Put, it does not seem to flush these
> until the program has finished running - even if a Text_Io.Get_Line is
> done! Has anyone else spotted this - how did you fix it?

Have you tried a Text_IO.Put_Line ?

Also, Its been a while, but I believe there is a "FORM =>" parameter
you can give Text_IO if you are opening or creating a file to specify
no buffering. In fact, I seem to remember that you can do anything RMS 
can do with the right "FORM =>" parameter.

> We get library corruption problems every couple of weeks generally when
> we have obsoleted some base types files several times. Anyone get
> similar results?

That sounds like the dreaded dependancy problem. You can avoid it by
making sure that in your compilation there are no situations where a 
package in a "child" library depends on a package in a "parent" library 
which in turn depends on a package in a child library. This often happens 
when a commonly "withed" package is brought down to a lower library for
maintanence. 

If I remember correctly, DEC Ada detects this situation and enters links
in your lower-level libraries so that no unit in your compilation depends
on a unit in one of your child libraries. When the maintanence is done
and the unit is moved back up to the correct parent library, you may be
clever enough to remove the unit itself from your library, but the links
that DEC Ada created must be removed as well.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: DEC Ada V3.3

[Klaus Wyss]

Alan Paterson wrote:
> 
> Has anyone else experienced problems with the DEC-Ada compiler
> when exporting and importing subprograms with STRING parameters?
> 
> (We use these pragmas in order to construct and reference
> shareable images on VMS)
> 
> With Version 3.2 it worked perfectly. Now that we have installed
> V3.3 we get nothing but access violation errors!
> 
> --
> Alan Paterson
> Berne, Switzerland
Hello

We tested DEC Ada 3.3 but we also ran into Problems.
We are passing AST_ENTRY's to non ADA functions. With the old compiler
(V3.0.7) it worked fine. With the new one we get a zero value in the
call. I try to reproduce the with a small test program, but as usuall it
worked there.
An other department also tried the new compiler and decided to stay at
the old one (I don't know the exact reason).

I heard some rumors, tha the main Ada people left DEC.

Klaus Wyss
Union Bank of Switzerland

Re: DEC Ada V3.3

[Steve Lionel]

In article <321D6756.3AA2@ubs.com>, Klaus Wyss <klaus.wyss@ubs.com> writes:

|>I heard some rumors, tha the main Ada people left DEC.

Not true.   In fact, most of the people who have worked on DEC Ada
in the past twelve years are still here (not all of them still work on
Ada, of course, like me.) 

The DEC Ada group has seen these postings and will respond soon.
-- 

Steve Lionel                      mailto:lionel@quark.zko.dec.com
Fortran Development               http://www.digital.com/info/slionel.html
Digital Equipment Corporation     
110 Spit Brook Road, ZKO2-3/N30    
Nashua, NH 03062-2698             "Free advice is worth every cent"

For information on Digital Fortran, see http://www.digital.com/info/hpc/fortran/

Re: DEC Ada V3.3

[Steve Lionel]

In article <321C3BC6.1897@dial.eunet.ch>, Alan Paterson <paterson@dial.eunet.ch> 
writes:
|>Has anyone else experienced problems with the DEC-Ada compiler 
|>when exporting and importing subprograms with STRING parameters?
|>
|>(We use these pragmas in order to construct and reference 
|>shareable images on VMS)
|>
|>With Version 3.2 it worked perfectly. Now that we have installed 
|>V3.3 we get nothing but access violation errors!

Could the following information, extracted from the release notes, be
relevant?  It's been many years since I've been involved with DEC Ada,
but I have passed on your message to the developers.

                                Issues Addressed by DEC Ada Version 3.3
 ...
              o  Problem with passing mechanism for exported programs

                 DEC Ada was incorrectly using a dope vector instead
                 of an VAX descriptor for the string parameter in the
                 program being exported. Since a DEC Ada program is
                 exported to be used in a mixed-language environment, a
                 VAX descriptor should have been used. This problem has
                 been corrected.

-- 

Steve Lionel                      mailto:lionel@quark.zko.dec.com
Fortran Development               http://www.digital.com/info/slionel.html
Digital Equipment Corporation     
110 Spit Brook Road, ZKO2-3/N30    
Nashua, NH 03062-2698             "Free advice is worth every cent"

For information on Digital Fortran, see http://www.digital.com/info/hpc/fortran/

Re: DEC Ada V3.3

[Charlie McCutcheon]

>AST_ENTRY issue

The only example I can think of would be on Alpha VMS V7.0, where
you must use pragma AST_ENTRY, due to DECthreads changes.  (You didn't
use to need the pragma).  This issue is in OpenVMS release notes.

Otherwise, I haven't seen this problem before.  If you can't reproduce
it with a small example, then we probably can't either without an example.

If you have a DEC Ada support contract, please work through there with
a reproducing program, since this sounds like a potential bug.

Charlie
\x1a

Re: DEC Ada V3.3

[Charlie McCutcheon]

Hmm.  I don't get on the internet enough.  I didn't expect the AST issue
to show up in this forum, only in VMS...  ;-)

>export/import issues

DEC Ada is preparing an answer for you.  Our release notes for V3.3 
mention a change where we went back to the way Ada V3.0 behaved.
(Ie, V3.2 had a bug).

Charlie

Re: DEC Ada V3.3

[Darel Cullen]

In article <321C3BC6.1897@dial.eunet.ch>, Alan Paterson
<paterson@dial.eunet.ch> spoke thus :-
>Has anyone else experienced problems with the DEC-Ada compiler 
>when exporting and importing subprograms with STRING parameters?
>

there is also another error in 3.3 weve discovered.. or atleast 
differing behaviour than 3.2, in that Text_io.Put does not immediately
flush to the screen , whereas it once used to..

hence

Text_Io.Put("Blah");
Text_Io.Get_Line(Blah,Blah_L);

you dont get the Blah output to the screen until after the get_line.
put_line flushes as normal.

try it :)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Darel J. Cullen                    Software Engineer
Email: Darel@djcull.demon.co.uk                      
Url: http://www.djcull.demon.co.uk/                 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: DEC Ada V3.3

[Robert Dewar]

Darel says

"Text_Io.Put("Blah");
Text_Io.Get_Line(Blah,Blah_L);

you dont get the Blah output to the screen until after the get_line.
put_line flushes as normal.
"

There is nothing in the definition of Ada that suggests that this must
work, so your code is at best highly non-portable.

Re: DEC Ada V3.3

[Bevin R. Brett]

In article <321D6756.3AA2@ubs.com>, Klaus Wyss <klaus.wyss@ubs.com> writes:

>I heard some rumors, tha the main Ada people left DEC.

My movements over the last couple of years may have helped fuel this
rumour.  Digital allowed me to move back to New Zealand to live near
my parents for a while - something I hadn't been able to do since
leaving home at 17.  While there, I was a contractor rather than an
employee, for various admin/legal/financial/tax reasons.

Two weeks ago, my family and I returned to New Hampshire, and
last week I rejoined Digital as an employee.  While I don't work
full time on the DEC Ada product anymore, I do consult for the
team.

/Bevin

Re: DEC Ada V3.3

[Larry Kilgallen]

In article <4vl39k$k1p@nntpd.lkg.dec.com>, lionel@quark.zko.dec.com (Steve Lionel) writes:
> 
> In article <321D6756.3AA2@ubs.com>, Klaus Wyss <klaus.wyss@ubs.com> writes:
> 
> |>I heard some rumors, tha the main Ada people left DEC.
> 
> Not true.   In fact, most of the people who have worked on DEC Ada
> in the past twelve years are still here (not all of them still work on
> Ada, of course, like me.) 

The posted problem, having to do with inter-language calls,
seems to be one whose solution would not primarily require
Ada skills anyway.  Compiler maintenance skills yes, but
it would seem resolution would happen regardless of whether
the original developer did it.

It has been my observation that keeping software stable
sometimes requires a different mindset than creating it
in the first place, so wishing for the original coder to
fix your problem might not be wise.

Larry Kilgallen

Re: DEC Ada V3.3

[Charlie McCutcheon]

>We also have problems with DEC Ada V3.3 (unexplained Contraint_Errors,
>unpredictable behavior, duplicate symbols on link of optimized code,
>access violations, etc.) and we are seriously considering going back to
>3.2.

I have not seen this sorts of problems reported with Ada V3.3.

If you have a Digital support contract, please report them, with instructions
for reproducing them.  We have customers running V3.3, and they appear to
be relatively happy...  ;-)

Charlie
DEC Ada

Re: DEC Ada V3.3

[Charlie McCutcheon]

>Has anyone else experienced problems with the DEC-Ada compiler
>when exporting and importing subprograms with STRING parameters?
>...
>We are currently trying to prove to Digital that an error is in
>fact present (I'm sure that many of you will know that this is a
>non-trivial task :-) but if anyone out there has had similar
>experiences, perhaps we could get together?

We have finally seen this issue through customer support, and are
working through them with a reproducing example.  For a few days
your posting had more information than our contact through them.

Expect some questions back to you soon.

Charlie
DEC Ada

Re: DEC Ada V3.3

[Mats Weber]

>>We also have problems with DEC Ada V3.3 (unexplained Contraint_Errors,
>>unpredictable behavior, duplicate symbols on link of optimized code,
>>access violations, etc.) and we are seriously considering going back to
>>3.2.
>
>I have not seen this sorts of problems reported with Ada V3.3.
>
>If you have a Digital support contract, please report them, with instructions
>for reproducing them.  We have customers running V3.3, and they appear to
>be relatively happy...  ;-)

The symptoms of our problem are the following:

We have a program approx. 100'000 lines of code that, when compiled with
DEC Ada 3.3, behaves in a strange way, with both /optimize and
/nooptimize:
- raises Constraint_Error in a non reproducible way
- some tasks block for 10 secs to 10 minutes without any apparent reason
- when compiled with /optimize, we get the following message at link time:
  "%W, symbol ADA$ADD_ALL$V multiply defined
        in module ADD_ALL file
        USER2:[PTT_APZV.ADA_OPT.EASYFILE]EZF_US-XX319A799C48DA.OBJ;1"

The above symptoms dissapear when we compile the exact same code with
version 3.2 (But we cannot generate an optimized version with 3.2 because
of an internal compiler error).

It is quite hard to isolate the problem to a few packages because the
problems are not easy to reproduce. We haven't been able to reproduce the
problems on our machine: we need to run the program on our customer's
machine to see the problems happen.

Do you think it is worth for us to submit the problem to DEC ?

Re: DEC Ada V3.3

[Larry Kilgallen]

In article <Mats.Weber-0309961227080001@mlma27.elca-matrix.ch>, Mats.Weber@elca-matrix.ch (Mats Weber) writes:

> We have a program approx. 100'000 lines of code that, when compiled with
> DEC Ada 3.3, behaves in a strange way, with both /optimize and
> /nooptimize:
> - raises Constraint_Error in a non reproducible way
> - some tasks block for 10 secs to 10 minutes without any apparent reason
> - when compiled with /optimize, we get the following message at link time:
>   "%W, symbol ADA$ADD_ALL$V multiply defined
>         in module ADD_ALL file
>         USER2:[PTT_APZV.ADA_OPT.EASYFILE]EZF_US-XX319A799C48DA.OBJ;1"

> Do you think it is worth for us to submit the problem to DEC ?

Of course!  That way it will be fixed before the rest of us run into it.
A good reproducer is required, however, in order to speed the resolution.

Admittedly the first two are hard to "submit",
but the third should reproduce on any machine, right ?

DEC fixes bugs in their Ada compiler,
but typically only those they have heard about.

Larry Kilgallen

Re: DEC Ada V3.3

[Charlie McCutcheon]

>Do you think it is worth for us to submit the problem to DEC ?

Yes.  We can't fix problems we don't get submitted.  We do want to fix
customer problems.

A reproducable problem is rather important however.  Even if it
fails 1 out of n times.  Otherwise, we'd be force to guess and possibly
not address the issue you're seeing.

Charlie
DEC Ada

Re: DEC Ada V3.3

[Sandy McPherson]

Mats Weber wrote:

> It is quite hard to isolate the problem to a few packages because the
> problems are not easy to reproduce. We haven't been able to reproduce the
> problems on our machine: we need to run the program on our customer's
> machine to see the problems happen.

Make sure that the ADA RTL shareable image on your customer's machine is
compatible with v3.3. I saw a similar problem a few years ago. When we
used a new compiler version the executables we delivered did not work,
even though we both had the same o/s version. The problem was that the
customer still had an old RTL image

> 
> Do you think it is worth for us to submit the problem to DEC ?

If the suggestion doesn't work, there is nothing else you can do...
-- 
Sandy McPherson	MBCS CEng.	tel: 	+31 71 565 4288 (w)
ESTEC/WAS
P.O. Box 299
NL-2200AG Noordwijk

Re: DEC Ada V3.3

[Mats Weber]

How do I know if the ADARTL that is installed on a system is compatible
with DEC Ada 3.3 ? I haven't seen anything on the subject in the Ada 3.3
release notes.