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,30a9bb3017fa58dd X-Google-Attributes: gid103376,public X-Google-Thread: 1025b4,959627a08fbc77c5 X-Google-Attributes: gid1025b4,public From: Robert Dewar Subject: Re: GNAT versions ( was :Ada compiler for PC?) Date: 1999/04/25 Message-ID: <7fud3l$hqi$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 470589679 References: <7fndu7$im4$1@nnrp1.dejanews.com> <7fqld6$htu$1@nnrp1.dej <1999Apr23.172908.1@eisner> <7frqmj$bg6$1@mulga.cs.mu.oz.au> <7ftfj4$vln$1@Jupiter.mcs.net> X-Http-Proxy: 1.0 x17.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sun Apr 25 06:35:32 1999 GMT Newsgroups: comp.lang.ada,gnu.misc.discuss X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-04-25T00:00:00+00:00 List-Id: In article <7ftfj4$vln$1@Jupiter.mcs.net>, les@MCS.COM (Leslie Mikesell) wrote: > Yes, and wouldn't you expect everyone with the previous > public release to have that same 'specific problem'? And > for them, the only way to get the fix is to become a > commercial customer at which time they magically become > capable of dealing with the other potential problems of > the wavefront releases... Well in fact it would NOT be good enough for them to become a customer. We don't make wavefronts generally available to our customers. Why not? Because in general it would not be helpful. Yes, a development wavefront may fix some problems, but until really adequate testing has been done, which is generally not possible for wavefronts, it may well introduce new problems, and new features that have been added may intefere with your existing programs. For example, if you have (unwisely but it happens) done a WITH of one of the GNAT internal system implementation units, then a wavefront may change that interface without warning. Now this is something that you will have to deal with in the major release cycle, but you probably do not want to mess with this just on the possibility that the wavefront may fix some problems you are not aware of. A customer getting a wavefront is in the following situation: 1. They are fixing something that they know is broken in their code, and there is no other way to fix it. Most often we can find a work around, and in that case we do NOT provide a wavefront. But if there is no other way, then it becomes worth the risk of moving to a new version of the compiler without waiting for a new release. 2. When a customer gets a wavefront, they have direct support from us, which means that if they do run into problems, we can help them out. I would *never* advise anyone to move to a wavefront unless they were forced to. It seems a very bad idea to me to be constantly switching compiler versions. Obviously it would be possible to mitigate the risks of wavefronts if we had the resources to develop two versions simultaneously, the development version with all the new features, and the old version with minimal bug fixes. Indeed this is somewhat what Cygnus does with EGCS. Obviously EGCS does not have the new development stuff that Cygnus has internally (which is very closely held until it is released), but they do spend significant resources coordinating bug fixes with EGCS. Perhaps in the future ACT will have more resources to do this kind of dual development. It may happen at least to some extent with the work of the GNAT/Linux group, at least that is what we hope can be worked out. But it is not a zero-cost proposition by any means. Note for example that GDB has nothing analogous to the EGCS process at the moment. Right now, Cygnus feels that they are doing most of the GDB work anyway, so it does not make sense. As time goes on and more people contribute directly to GDB as seems likely to happen in the future, it will make more sense to create a more open process for GDB. Obviously if there were more players than ACT contributing directly to the GNAT work, then the value of such coordination would increase. This seems to be beginning to happen with the GNAT/Linux work, one useful patch recently propagated from the GNAT/Linux team to ACT, and we have prepared a couple of critical Linux patches to go in the opposite direction. One problem of course is that only ACT has access to the ACT regression suite. This is fundamental, it is mostly proprietary code, that we promise to guard very closely. Similarly, the DEC test suite is proprietary code to which we have access, but most certainly not distribution rights. Of course the ACVC suite exists publicly, and this is at least a first level test of externally developed patches and fixes. Anyway we will see, The 3.12p release will provide a more stable starting point for such interaction. Why more stable? Because each release so far of GNAT, with rare exceptions is more stable than the prior one. Why? Because we work hard to make it so. Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own