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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,a0be06fbc0dd71f1
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!news.germany.com!news.belwue.de!LF.net!news.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: The future of Ada is at risk
Date: Sun, 30 Dec 2007 13:30:51 +0100
Message-ID: <87r6h474as.fsf@mid.deneb.enyo.de>
References: <20071229040639.f753f982.coolzone@it.dk>
	<1198927305.6843.35.camel@K72>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: idssi.enyo.de 1199017852 9041 212.9.189.177 (30 Dec 2007 12:30:52
 GMT)
X-Complaints-To: 
Cancel-Lock: sha1:MAthYJPWyGYOq5FR7XG8wDrua84=
Xref: g2news1.google.com comp.lang.ada:19080
Date: 2007-12-30T13:30:51+01:00
List-Id: <comp.lang.ada>

* Georg Bauhaus:

> The future of Ada on OpenBSD, FreeBSD, and NetBSD seems at risk.

Last year, I tried to port one of my Ada implementations to FreeBSD (I
think it was version 6) on the amd64 architecture.  Maybe I misread the
ports collection, but there didn't seem to be a port.  There seemed to
be some performance issue with the system malloc which causes very slow
compilation on FreeBSD 6 on i386, too.

To sum it up, the platform appeared to be rather untested.  On the other
hand, there was little porting involved as far the actual application
was concerned.  But the application was small (just 30 kSLOC), and used
very few interfaces specific to operation systems (mainly the modern,
IPv6-capable sockets API, for which two variants exist, and I had only
programmed to the Linux variant before).

What's worse, the application test suite shows that tasking is broken on
SMP machines on current GNU/Linux (both i386 and amd64, IIRC), not just
on FreeeBSD. 8-(

> Seriously, by the count of installations, isn't the future of
> *BSD at risk.

Unfortunately, one of our partner organizations is rather BSD-centric.

> Sadly, this might be one of the reasons why no one bothers to write a
> full GNAT runtime for BSD anymore.

The run-time library exists, it just needs to be maintained (same for
GNU/Linux, actually).  My impression that most commercial GNAT users do
not use tasking, or use it on freestanding implementations (that is, not
GNU/Linux).  Similar to no one using Ada.Strings.Unbounded (this has
changed recently, apparently), or finalization in performance-sensitive
code.