From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5752ba976f4dad11 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: GNAT 3.01 Source For OS/2 Date: 1996/04/27 Message-ID: #1/1 X-Deja-AN: 151738737 references: organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-04-27T00:00:00+00:00 List-Id: Jerry said " It's not my job to go out and find bugs for YOU. Ada Core Technology simply screwed up 3.03. Your 3.03 source on cs.nyu.edu WILL NOT WORK. If you want me to go as far as specifing the exact lines of code that are wrong I can do that !!!! Do you REALLY want me to PROVE to the open public that your 3.03 release is broken and CANNOT work ???? When I do that, the clear implication will be that ACT is NOT providing the Configuration Management and Version Control that one would expect from ANY Ada developer. I will be proving that the 3.03 source and executable on cs.nyu.edu DO NOT match." "specifying the exact lines of code" that you think are wrong would of course be helpful. Can you please send a copy of this to report@gnat.com, where it is most helpful since then it is sure to get to the right person. As for your claim that the 3.03 source and executables do not match. This is quite wrong. I have no idea what leads you to this incorrect conclusion, but all 3.03 versions are built EXACTLY from the 3.03 sources as distributed, and all compile their own libraries. If you are having trouble duplicating this build, most likely you are just not doing the build the same way we are. For instance, our stndard options for compiling the compiler are -gnatap (assertions on, range checking off). We turn range checking off because it is our experience that with assertions on, the range checking does not find additional real errors, but has been known to cause problems (as appears to be the case in your build). Of course the case you found should be fixed, but as you have undoubtedly found out, the issue here is one of choosing right subtypes, not a functoinality issue, i.e. the 3.03 compiler behaves fine as we build it in this respect. It is possible that some of your other problems with the build come from similar cases, or not. Hard to say without more details. The OS/2 compiler does get completely built at least once a day. The problem in getting releases out is packaging and testing. In the future, we are going to release the OS/2 directly from my working version, which should make it easier to get OS/2 releases out. Before we were rebuilding a referene version on another machine for the release, and this is teh step that was taking time, and not getting done due to its low priority. The disadvantage of this approach is that we are less likely to track changes in EMX, since there is no point for me to update EMX versions if my development version is working fine. Of course if some volunteer can help with putting things together with the latest EMX, we would be more than happy to work with them.