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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2e91a32061bde112 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: JAVA and ADA JGNAT Date: 2000/02/05 Message-ID: <87i6ec$k4e$1@nnrp1.deja.com> X-Deja-AN: 582028585 References: <862sv5$sug$1@pirates.Armstrong.EDU> <862t3o$9aa1@news.cis.okstate.edu> <86k8r6$alp$1@nnrp1.deja.com> <86kpbu$aik1@news.cis.okstate.edu> <86la8r$519$1@nnrp1.deja.com> <877lgxuquu.fsf@deneb.cygnus.argh.org> <86mqi6$6dd$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x30.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Sat Feb 05 21:58:37 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-02-05T00:00:00+00:00 List-Id: In article , Pascal Martin wrote: > No such thing seems to happen to GNAT. I suspect ACT is protecting its > business using FUD and obscurity: "if you try to build your compiler yourself, > be warned". GNAT is complicated to build, and when you are in trouble, > Dewar put the sales hat on. And it is not cheap: the GNAT trap. Look like > also they don't want anyone to compete with them. First, it is quite straightforward to build GNAT, lots of people do it, the makefiles and procedures are well documented, and anyone reasonably familiar with GCC can easily do these builds, and many, many people build GNAT from sources. We don't work on making this build "simpler", because it's simply not an issue, I am not quite sure why Pascal Martin has had trouble, but generally our experience has been that anyone with reasonable gcc experience has no trouble, so it is not something that is worth putting work into. Actually, a lot of the users of the public version of GNAT use versions not built by us, and that seems fine. We are happy to cooperate with anyone doing such builds. For example, ACT cooperates closely with the GNAT/Linux group that builds RPM's for popular versions of GNU/Linux. The policy of ACT is the same it has always been, all our work is placed in the public tree as soon as it is in releasable shape (we actually will go to more frequent releases in the next year, as a result of the new contract with SGI, which calls for quarterly releases -- we will try to syncrhonize the public releases with these more frequent GNAT Professional releases). No company that I know of works by having its internal development sources and development activity day by day open, I think that would be chaotic. In particular, it is quite right that not having access to the ACT test suite makes it risky to make changes. We certainly never allow even the most minor of changes to be made without running the test suite, and this avoids many false steps that would cause regressions. It would be nice if there were more activity in contributions to the public tree, but in practice that does not happen so much for complex beasts like compilers. If you look at the gcc changes, a great majority are made by Cygnus or full time development folks at other companies. And, despite "belief" sited earlier in this thread, I can promise you that Cygnus does not work in bazarre mode internally (anyone really seriously think that the new Itanium compiler was developed that way? -- you probably don't even know about it, even though the project has being going on for quite a while now under non-disclosure -- and that of course is the point). Similarly, there are major developments that have not seen the light of day yet from major Linux companies (and I think I will use Linux there and not GNU/Linux quite deliberately :-) Does this mean that these evil companies are secretly doing stuff that they should be doing openly? Not at all, it simply means that these projects are under development, by a well defined development team, using traditional high quality software development techniques, but they are not ready for any kind of distribution yet. As for public beta tests, I know that this is a common concept particularly from Microsoft, who even charges hundreds of thousands of people to be beta testers. But it's not the way we work for several reasons: 1. We think that beta testers need to be in close contact with the developers, so that useful input is obtained in a systematic way. Far too often "public beta" versions are just a way of getting pre-releases of software that is not really in good enough shape to release. Hobbyists, magazine reviewers, and enthusiasts enjoy being able to get their hands on these early versions, but they don't do much in terms of systematic input. 2. We think it is important that people experimenting with Ada not find a confusing mess of different versions, many of which are in some kind of beta stage, or otherwise not suitable for general release. 3. So far, for the public releases of GNAT, we have been able to make pretty frequent releases even without wide spread beta programs, because of the internal field testing procedures that we use. Finally, we don't mind at all if other companies get into the GNAT business. There are lots of gaps to fill in here, so most likely such companies won't choose to compete in exactly the same market as ACT, but that's up to them. For example, there is a company in England that provides support for safety- critical applications using the ERC32, an environment that ACT does not support currently. We are working with them to make sure that their business is successful. Similarly we worked with Labtek when they were marketing a low cost supported version of GNAT for NT. It's certainly much easier to compete with ACT given that you have our complete sources as a starting point than to compete with any of the other Ada vendors who continue to keep their sources highly proprietary! Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy.