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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:b95d:: with SMTP id k29-v6mr17476887iti.6.1526398158252; Tue, 15 May 2018 08:29:18 -0700 (PDT) X-Received: by 2002:a9d:5191:: with SMTP id y17-v6mr1137732otg.12.1526398157812; Tue, 15 May 2018 08:29:17 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!v8-v6no227236itc.0!news-out.google.com!b185-v6ni4882itb.0!nntp.google.com!u74-v6no229532itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 15 May 2018 08:29:17 -0700 (PDT) In-Reply-To: <87vabqs7qc.fsf@jacob-sparre.dk> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <87vabqs7qc.fsf@jacob-sparre.dk> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <25c01889-1d29-48ea-9e52-c4c3ceacf093@googlegroups.com> Subject: Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance From: "Dan'l Miller" Injection-Date: Tue, 15 May 2018 15:29:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52357 Date: 2018-05-15T08:29:17-07:00 List-Id: On Monday, May 14, 2018 at 8:10:53 AM UTC-5, Jacob Sparre Andersen wrote: > Dan'l Miller wrote: >=20 > > 1) AdaCore's GNAT Pro > > - Ada2012 plus (some?) emerging Ada2020 > > - very actively maintained >=20 > You could say so. >=20 > > 2) FSF GNAT in GCC > > - Ada2012 > > - sporadically maintained (i.e., bleeding-edge combination of > > current-wavefront GCC backend with effectively retrofitted AdaCore > > GNAT front-end from an older release of GCC) >=20 > Nope. Changes are continously - except when GCC has a code freeze - > ported from the internal GNAT Pro development branch to the public GCC > development branch. (My understanding. I'm neither working for FSF nor > for AdaCore.) TL;DR; this self-contained single paragraph is an alternate wording of the = crescendo of logic in the subsequent multiple paragraphs below: Does AdaCore fix =E2=80=A2=E2=80=A2in the exact same minor-dot-release of F= SF GCC=E2=80=A2=E2=80=A2 (e.g., 8.0) the bugs that were introduced by the m= erge from GNAT-Pro development branch to current wavefront of FSF developme= nt on the public GCC branch? Let alone minor; in recent years, does the fi= x always arrive in the same major (e.g., 8.X for any X) release of FSF GCC = as when the merge introduced the bug into FSF GNAT's current wavefront of n= ew development? Do the bugs introduced by the merge from GNAT-Pro developm= ent branch into, say, GCC 8.0 sit there unfixed until (after a round-trip o= f adopting GCC 8.X into the GNAT-Pro development branch, itself merged with= bug fixes back to FSF weeks or months or a year later), AdaCore releases f= ixes for, say, a hypothetical GCC 8.3 release, which again leaves, say, GCC= 9.0 buggy for a while (e.g., until AdaCore maintains the 9.X release by th= e time of, say, a hypothetical 9.3? If such a multi-minor-release-spanning= (or worse, multi-major-release-spanning) window of FSF GNAT bugginess exis= ts due to release-number difference between GNAT Pro and FSF, wouldn't that= be =E2=80=A2sporadic=E2=80=A2 (as some minor releases of FSF GNAT get a ye= p-FSF-GNAT-is-reliable checkmark and others don't for months-long or year-l= ong durations)? The longer version of crescendo: I am not merely focusing solely on mechanical merges of source code that = merely minimally compile. (What =E2=80=A2precisely=E2=80=A2 is the criteri= on or criteria for success that AdaCore utilizes to =E2=80=9Cport[] from GN= AT Pro development branch to the public GCC development branch=E2=80=9D tha= t discerns A) a rejected change to the public GCC development branch that n= eeds more grinding before being released publicly from B) an accepted chang= e to the public GCC development branch that is good to go? Is it merely su= ccessful compile & link? Is it passing all of ACATS or some other rigorous= regression test suite?) I utilize the term =E2=80=9Cmaintenance=E2=80=9D of software, whereas you u= tilize the term =E2=80=9Cporting=E2=80=9D. What is the difference? https://en.wikipedia.org/wiki/Software_maintenance Porting focuses on the mechanical-esque adaptation of some origin source co= de into some different destination larger body of source code or some diffe= rent larger system. Not only does software maintenance subsume porting, a = key part of maintenance of software includes (from that Wikipedia article a= nd decades of wisdom from Lehman et al) =E2=80=9C4. The process acceptance = of the modification, by confirming the modified work with the individual [e= .g., FSF and the public] who submitted the request in order to make sure th= e modification provided a solution.=E2=80=9D That criterion #4 is what I a= m focusing on in the =E2=80=9Csporadically=E2=80=9D term. After =E2=80=A2=E2=80=A2every single merge=E2=80=A2=E2=80=A2 of a unit of w= ork (e.g., bug fix; new feature) from AdaCore's GNAT Pro development branch= to the public GCC development branch, does AdaCore run a hard-hitting batt= ery of regression tests =E2=80=A2=E2=80=A2=E2=80=A2on the resulting FSF bra= nch=E2=80=A2=E2=80=A2=E2=80=A2 to assure that no bugs were introduced (e.g.= , due to mismatch with the different release of GCC)? Or is that finding o= f fresh bugs (i.e., the ones that were introduced sympathetically by the me= rger itself that were not present in FSF GNAT prior to the merge from GNAT = Pro) the job of the so-called =E2=80=98community=E2=80=99 outside of AdaCor= e? In so far as this non-AdaCore FSF GNAT community is voluntary, wouldn't= that be =E2=80=A2sporadic=E2=80=A2 since voluntary labor is a finite resou= rce smaller than the demand (of mismatches due to different Pro-to-FSF-mism= atched GCC versions)? Yes, I have no doubt that the merge and minimal does= -it-compile-&-link check is performed very frequently. But is the regression test suite performed equally as frequently on =E2=80= =A2FSF GNAT=E2=80=A2 during/immediately-after a merge from GNAT Pro? Preci= sely where can I see daily or weekly exhaustive regression-test pass/fail r= esults (especially showing near-100% success rate) regarding the GNAT-Pro-t= o-FSF merges? When a fresh bug is introduced to FSF GNAT due to a merge fr= om GNAT Pro, who =E2=80=98gets right on that right away=E2=80=99 to fix tha= t bug just introduced in FSF GNAT by the public merge from GNAT Pro: 1) AdaCore (directly) who just performed the Pro-to-FSF merge hours or days= ago or 2) the so-called =E2=80=98community=E2=80=99 (i.e., non-AdaCore) or 3) AdaCore (indirectly) as they eventually adopt that later GCC release int= o the GNAT Pro development branch weeks or months or a year later? Wouldn'= t the weeks or months or year of this option #3 be =E2=80=A2not=E2=80=A2 pu= blicly =E2=80=98getting right on that freshly-introduced bug right away=E2= =80=99? Wouldn't the lack of bug fix right away along that public FSF GCC = branch in the same GCC minor release number be =E2=80=A2sporadic=E2=80=A2 m= aintenance of such a buggy merge, if one ever exists? If community #2 there, then wouldn't that be =E2=80=A2sporadic=E2=80=A2 as = volunteers eventually find time to volunteer their time? If AdaCore #3 the= re via eventual adoption of that different later version of GCC into the GN= AT Pro development over a period of weeks or months or even a year, then wo= uldn't that be =E2=80=A2sporadic=E2=80=A2 by the time that that cycle of de= velopment makes a not-immediate round-trip back to FSF GNAT? Does AdaCore continuously adopt into the GNAT Pro development each incremen= tal continuous-integration evolution to the GCC wavefront of new developmen= t or does AdaCore adopt a different later release of GCC as a convulsion in= one big gulp? If one big gulp, then wouldn't that be =E2=80=A2sporadic=E2= =80=A2 as fixes for bugs introduced into FSF GNAT via merge from the (older= -GCC-release) GNAT Pro development branch into the (later-GCC-release) curr= ent-wavefront of new GCC development branch often(?) wait for the adoption = of a later-release GCC on the GNAT Pro development branch weeks or months o= r even a year later? Aren't we just exploring here how the dictionary definition of the word spo= radic plays out meticulously ramification-by-ramification within what we pe= rceive externally are the GNAT-Pro-to-FSF release process is and later-GCC-= release-to-GNAT-Pro adoption process? What better word than sporadic exist= s in the dictionary for this back-&-forth round-trip-of-later-GCC-release-t= o-GNAT-Pro-then-AdaCore-development-then-eventual-merge-to-a-still(!)-later= -release-of-GCC state of affairs? Pendulum (with a periodicity of months = or year)? > > 5) Tartan Ada (DDC-I) > > - Ada1983 (Ada1995 work by Tartan didn't survive acquisitions?) > > - legacy only(?) for DSPs & TI processors >=20 > I don't know about Tartan Ada, but DDC-I sells Ada 95 compilers for a > number of targets: https://www.ddci.com/products_score/ >From Texas Instruments, on various (but not all) processors, DDC-I purchase= d the rights to the Tartan Ada compiler written by the company that (the) = Dr. William Wulf's and wife founded, based on their pioneering work on the = BLISS optimizing compiler, one of the first compilers with an optimizer pha= se. You know, the William Wulf who is one who in 1971 added fuel to the MI= MD and hypervisor fire via c.mmp and Hydra which were precursors, respectiv= ely, of a) modern MIMD in SPARC UMA crossbar and the crucial need for the c= ache-coherent part of ccNUMA processor confederations (e.g., AMD HyperTrans= port & Intel QPI instead of the crossbar) and b) all the modern hypervisors= (e.g., VMware, Hyper-V). You know, the one who first popularized/advanced= /industrialized the idea for an =E2=80=A2optimizing=E2=80=A2 stage within c= ompiler backends. That William Wulf. Btw, Tartan was where Guy Steele wor= ked as a young man prior to co-designing Java almost 2 decades later. > > 6) PTC's ApexAda (formerly IBM Rational Ada) > > - Ada2005 > > - actively maintained > > 7) PTC's ObjectAda (formerly Aonix's ObjectAda) > > - Ada1995(?) > > - actively maintained >=20 > PTC has three Ada compilers they are selling. Two of them are > supposedly in active development, but I can't remember which. >=20 > > 8) HPE's Ada (formerly DEC's Ada) > > - Ada1995(?) > > - legacy only on OpenVMS >=20 > Not something I've heard of. >=20 > > Are there any others still extant? >=20 > Green Hills Software still sells the Green Hills Ada (95) compiler. >=20 > XGC Technology sells four variants of their Ada 95 compiler. >=20 > > Is it true that absolutely no Ada compiler vendor other than the 3 > > variants of GNAT (counting the LLVM one as a limping-along 3rd > > variant) have achieved the bulk of the Ada2012 feature-set in > > approximately six years? >=20 > You would have to check with PTC and RR Software, to hear if they have > implemented "the bulk" of Ada 2012 yet. PTC are implementing Ada 2012 > features prioritised according to the needs of their customers (whatever > that means). >=20 > > What disruptors are foreseeable to change any of this significantly? > > - fresh new Ada compiler (e.g., Byron) > > - drastically-divergent fork of GNAT > > - faster Ada-compiler development at RR Software or PTC so that they > > support Ada2012 and Ada2020 by, say, 2023? > > - resurrection of effectively dormant source code bases at HPE or > > Tartan/DDC-I? >=20 > The third option seems most likely. RR Software has already implemented > some Ada 2012 support, and they clearly intend to expand it. >=20 > I think it is unlikely that somebody can get sufficient funding to > create a new Ada compiler from scratch. >=20 > I can't see the point in forking GNAT, and DDC-I & co. seem quite happy > milking their existing customers, so don't expect anything from them. > And given what you pay for a PTC Object Ada license, I can't see how > they can get enough customers to fund any serious development. And it > doesn't seem like their management is interested in making an investment > (unlike RR Software). >=20 > Greetings, >=20 > Jacob > --=20 > xsnow | xshovel > /dev/null