Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[deadlyhead]

I'm glad that AdaCore has been there making sure that we have a free
software Ada compiler of the highest quality.  I'm also glad that GNAT
is part of GCC and all that entails.  What's frustrating me, though,
is the gap between the AdaCore releases of GNAT and the frontend
distributed from the GCC project.

I have no doubt that my desires are pretty unique: I want to target
the JVM, but develop entirely on GNU/Linux.  My commitment to free
software in general, and my disdain for windows in particular, prevent
me from just doing what's expected and using the binaries released by
AdaCore.  So, instead, I want to compile JGNAT from the AJIS sources
that AdaCore provides.

First attempt: try and compile JGNAT directly from the GCC-4.5.2
sources from which I built my running version of GNAT.  What?  I need
libaddr2line.a?  Well, crap.  It's no longer part of binutils, and I'm
not going to recompile AdaCore's binutils just for shits and giggles,
so I patch my own sources à la Ludovic Brenta for Debian GNAT.  This
works well, actually, and gets me past the libaddr2line.a once I've
recompiled, but then I have to deal with some "cannot find
Adabkend.ads" errors.  I'd never seen this in the sources before.
WTF?

Turns out that AdaCore only uses this file in their own GNAT
distribution, they don't push it down to GCC with everything else,
just like they maintain their own copy of binutils.  Now, for your
everyday GNAT usage this isn't a big deal since the only backend being
used is GCC, so they just leave out this functionality.  Whee.  But if
you try to build JGNAT, whoa! you have another backend!  The code for
this other backend isn't included with the JGNAT sources, though, it's
included only with the GNAT sources released from AdaCore!

So, I go get the GNAT sources (just the gcc/ada directory, not the
entire GCC suite they post, too) and try to simply add in the files
"missing" from my source tree.  Of course, this doesn't work.  So, I
go whole-hog, replacing the ada components in my GCC-4.5.2 source tree
with those from AdaCore, and apply the gcc-45.dif patch as instructed
(which doesn't patch cleanly, so hand-tweaking is required).  BAM!  An
obstacle course of errors arise, mostly syntax errors for the first
dozen or so.  I fix these with little problem, but once the syntax
errors are out of the way, more onerous problems arise.  After half a
day of banging my head against this, I throw in the towel, and go
download the entire GNAT sources from AdaCore.

I compile all of the prereqs: gmp, mpc, binutils, etc.  Then I patch
the GCC provided with the GNAT sources provided.  Okay, at least that
works.  Start to compile... BAM!  Fail!  I forgot, you can't compile
an old version of GNAT with a more recent version.  So back I go to
get the GNAT binary.

So, now with AdaCore's binary as my working compiler, I try again...
BAM! Fail?  Yeah, turns out that the --disable-libada option must be
passed in AdaCore's gcc sources; gnattools and gnatlib must be
compiled separately.  Wasn't this fixed in the GCC trunk with GCC 4.1?

So, again, this time with separate compilation for the GNAT stuff....
success!  It compiled!  w00t!  So, because I'm careful, I run `make -k
check`, just to be sure... and lo! there are many errors.  Now, C and C
++ errors I'm used to, but this is pretty major.  And I've never
before built GNAT with any errors in ACATS or the gnat tests
themselves.  ACATS passes, but with a bunch of warnings, but the gnat
tests themselves have an almost 20% failure rate.  WTF!?!  Running
tests of my 4.5.2 build showed GNAT working perfectly...

So this is about three days attempting to build JGNAT on GNU/Linux
with no success.  Supposedly I have a working compiler to build
against, but not one that I actually trust.  (BTW, why would I believe
that the binary compiler is any better than the one I built if I
compiled it from what I assume are the same sources?)  I've been
through the process of fitting AdaCore's tools with GCC-GNAT (I've
successfully built both AUnit and ASIS against GCC-4.5.2 GNAT, but
these took no small amount of tinkering), but I'm definitely hitting a
wall here and I'm growing increasingly frustrated.

Does anybody have any insight as to why AdaCore seems to keep so
segregated from the rest of the free software world?  I'm talking
about more than just JGNAT here: GNAT for Mindstorms and their AVR
compilers are both projects that I have a lot of use for, but they
only release binaries for windows users, and I have serious doubts
about being able to build them from source anyway if my experiences
here are any indication.  They maintain no public code repositories
for any of these projects as far as I've seen, so there's no way to
contribute in a meaningful way, either.

Sometimes I think it would be easier if I didn't enjoy Ada so much...

--deadlyhead

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Ludovic Brenta]

<long and interesting rant deleted>

I agree with your frustration with the fact that AdaCore keeps some of
their source repositories, notably GNAT and ASIS, secret. This is
especially frustrating when you try to build GPS from the trunk, which
usually requires a recent (but secret) version of GNAT.

This frustration is harmful for AdaCore, too, since it has already
discouraged valuable input and contributions (e.g. bug reports from
Dmitry); in fact it has already caused some people to dismiss GNAT as
a "closed" compiler altogether[1].

[1] http://www.libroscope.org/Benchmark-23-logiciels-libres

I too wish AdaCore would maintain the GNAT sources in a branch of the
FSF-GCC repository, merging these sources into the trunk during Stage
1 of the GCC development process. If they were to do that then I'd
probably contribute more; I have a whole suite of tests I could commit
but I'm just not motivated enough to do that (the FSF copyright
assignment letter has been waiting on my desk for several months now).

But I fear only a large paying customer could persuade AdaCore to
publish their sources more frequently and no large paying customer is
interested in that.

Having said that, I think it should be possible to move forward
nevertheless. I would like it if Debian could ship a JGNAT package for
example :)

--
Ludovic Brenta.

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Yannick Duchêne (Hibou57)]

Le Thu, 20 Jan 2011 14:37:01 +0100, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:

Ludovic, forgive me, I guess you will not enjoy this reply.

> <long and interesting rant deleted>
>
> I agree with your frustration with the fact that AdaCore keeps some of
> their source repositories, notably GNAT and ASIS, secret. This is
> especially frustrating when you try to build GPS from the trunk, which
> usually requires a recent (but secret) version of GNAT.
There are two GNAT, you are talking like there was only one.

> This frustration is harmful for AdaCore, too, since it has already
> discouraged valuable input and contributions (e.g. bug reports from
> Dmitry); in fact it has already caused some people to dismiss GNAT as
> a "closed" compiler altogether[1].
Dismissed ? And they switched to what ? They build there own compiler ? Or  
what else ?

> [1] http://www.libroscope.org/Benchmark-23-logiciels-libres
This page is french ;) Any way, the topic: it says : “GNAT Pro : 0% libre”  
and seems to complain about it.
GNAT Pro ? What a joke, where did they see GNAT Pro was ever promoted as  
libre ? Is GNAT Pro provided on libre.adacore.com ? The answer is No. On  
libre.adacore.com, you get GNAT GPL, GNAT Pro was never promoted as libre,  
is another product which is available on another area of the site.

(I leaved this page right after I've seen this line, because it appears it  
is not honest)

> But I fear only a large paying customer could persuade AdaCore to
> publish their sources more frequently and no large paying customer is
> interested in that.

Just like the baker… he more enjoy to give his products to paying clients  
(or else how the whole economy works is to be updated; but no-body care…  
especially if they just want get “this” and “that” for nothing).

And why not promote some funding from other users ? Let say 1200 users of  
the GPL version, each funding $10 e year (relatively accessible), this  
will reach the level of pricing for GNAT Pro on Windows. Try to negotiate  
with AdaCore for a special kind of contract on this basis. Is that an  
valid option ? This would not offer a full-support GNAT obviously, but  
this may help to get more (very probably).

> Having said that, I think it should be possible to move forward
> nevertheless. I would like it if Debian could ship a JGNAT package for
> example :)
>
> --
> Ludovic Brenta.

Above all, remember what you do yourself is always 100% libre for yourself  
(kidding)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[J-P. Rosen]

Le 20/01/2011 15:50, Yannick Duchêne (Hibou57) a écrit :
> GNAT Pro ? What a joke, where did they see GNAT Pro was ever promoted as
> libre ? 
GNAT Pro is distributed under the GMGPL license. Nothing would prevent
anybody to redistribute GNAT Pro. But no Gnat PRO user is interested in
doing that. (TBH, there is some FUD from AdaCore that discourage people
from doing it).

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a déménagé / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Yannick Duchêne (Hibou57)]

Le Thu, 20 Jan 2011 18:47:34 +0100, J-P. Rosen <rosen@adalog.fr> a écrit:

> Le 20/01/2011 15:50, Yannick Duchêne (Hibou57) a écrit :
>> GNAT Pro ? What a joke, where did they see GNAT Pro was ever promoted as
>> libre ?
> GNAT Pro is distributed under the GMGPL license. Nothing would prevent
> anybody to redistribute GNAT Pro. But no Gnat PRO user is interested in
> doing that. (TBH, there is some FUD from AdaCore that discourage people
> from doing it).
But there is a libre.adacore.com, so this drove me to suppose some kind of  
distinction is made. May be you know the exact licensing terms, and  
clients know these, for sure, and this may be part of this license, OK.  
However as a “public” user, I've never seen any claim from AdaCore about  
GNAT Pro being libre. That was the reason why I reacted this way.

If really clients are allowed to re-distribute, this is indeed surprising,  
I could never believe this could be really possible: users/clients allowed  
to redistribute and none doing so. May be they feel that's better to not  
brake AdaCore business (I am talking about earnings) so that they are  
assured of a regular and good job done at maintaining the compiler ? (I  
would not expect it from the “crowd”, but they must be some kind of  
special users I believe).

That said, do you think they could be some provision for the suggestion  
made, that is, some funding from GNAT GPL users to fix some bugs in the  
compiler (I would be very happy to see the one about synchronized  
interface fixed). Some room for a special contract ? Obviously, AdaCore  
could not receive all individual request from each; but we could make some  
collectively after some collegiate decisions.


P.S. This must not be easy for AdaCore too I believe (I see no way to  
easily handle commercial + GPL). May be these FUD are the only way they  
could figure to protect it… just hope these FUD are not too much  
disturbing/nasty for their clients (ouch).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> If really clients are allowed to re-distribute, this is indeed
> surprising, I could never believe this could be really possible:
> users/clients allowed to redistribute and none doing so. May be they
> feel that's better to not brake AdaCore business (I am talking about
> earnings) so that they are assured of a regular and good job done at
> maintaining the compiler ? (I would not expect it from the “crowd”,
> but they must be some kind of special users I believe).

We don't in general pay AdaCore to get the latest and greatest; we pay
to get support when we have problems, or need advice, and very good it
is too.

The project I'm (still, just) working on is stuck with a really old
compiler, for various reasons I don't think I need trouble you with. The
general tendency is to start a project with the latest compiler,
upgrading until some formal customer-visible release point, then freeze;
only moving up to a new release after that when there's a really good
reason to do so. AdaCore are still prepared (a bit grumpily, maybe,
sometimes) to help; but really most of the time it's our understanding
that's the issue.

As to why we don't copy the latest GNAT Pro to the world -- well, it's
not I who has the contract, it's my employer, and I don't think I'd get
very far trying to persuade the boss to permit the copying.

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[deadlyhead]

On Jan 20, 1:03 pm, Simon Wright <si...@pushface.org> wrote:
> "Yannick Duchêne (Hibou57)" <yannick_duch...@yahoo.fr> writes:
>
> We don't in general pay AdaCore to get the latest and greatest; we pay
> to get support when we have problems, or need advice, and very good it
> is too.
>
> The project I'm (still, just) working on is stuck with a really old
> compiler, for various reasons I don't think I need trouble you with. The
> general tendency is to start a project with the latest compiler,
> upgrading until some formal customer-visible release point, then freeze;
> only moving up to a new release after that when there's a really good
> reason to do so. AdaCore are still prepared (a bit grumpily, maybe,
> sometimes) to help; but really most of the time it's our understanding
> that's the issue.
>
> As to why we don't copy the latest GNAT Pro to the world -- well, it's
> not I who has the contract, it's my employer, and I don't think I'd get
> very far trying to persuade the boss to permit the copying.

I have no problem, per se, with AdaCore releasing two "versions" of
their compiler... in fact, I have no reason top believe that GNAT Pro
is any different from GNAT GPL, except for the fact that more _binary_
versions of GNAT Pro are released.  It can take a lot of work to
create a binary that will work on many systems (thinking of the GNU/
Linux world, the differences between, say, Debian and Redhat (or
Ubuntu, for that matter!) are not insignificant), and I understand if
AdaCore does not wish to release their "VxWorks hosted on Linux"
binary for any and all to use, just to be inundated with emails from
hobbyists asking why it's not working for them on GoosebumpLinux-
CrazyUnstable.

But then again, this is free software.  There's absolutely no reason
that they should not release buildable _sources_ for said hobbyists to
use.  We know that there is a community of volunteers out there
willing to step up and build on even the most obscure systems (I'm
thinking of the GnuAda project, among others) and release their
knowledge for the benefit of all.  If I could get JGNAT to build, you
_bet_ I'd tell everyone how I did it, probably right here on Usenet
first.  And, if I felt that AdaCore could/would make use of my
findings, I would send it to them specifically, in hopes that the next
release of sources would include the information, maybe even with
their contributions, too.

I'm with Ludovic as far as wishing AdaCore would do their development
in a public branch of GCC, then merge in Stage 1.  I'd love to test
and give feedback as development progresses.  We'd also be able to
test their other technologies at the same time, i.e. pull the latest
revision of the gnat-gcc branch to build against the latest revision
of GPS, fix any incompatibilities, and submit the patch back to GPS.
Less work for AdaCore, better software for the world!

I actually can't see any downside to AdaCore developing on a GCC
branch.  They could release wavefront releases for their paying
customers, just as they currently do, but they'd get the benefit of a
rapid release cycle with full community input just like the rest of
GCC.  They could integrate the Debian-style fix for libaddr2line, etc,
and stop maintaining their own custom binutils, too, and maintain
public sync for all their technologies.  How many more people might
use Ada if the GNAT technologies were as accessible as the rest of
GCC?

As for my activities that prompted my original rant, I'll keep working
on JGNAT for GNU/Linux, probably attempting to build against GCC-trunk
from here on out.  If I can get that working, I'll make sure the
entire world knows.  Also, since I use Debian as my base OS these
days, I'd also like to see if I can backport the build to the Debian
GNAT sources, in which case I'd approach Ludovic specifically.

BTW, I can't stand Java, it makes me feel dirty just to read it, but I
am compelled to develop Android apps, hence trying to build JGNAT.  I
may try binding to the Android NDK at some point, too, but that
requires GNAT-ARM crosstools.  One project at a time...

-- deadlyhead

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[qunying]

My personal experience with  GNAT GPL 2010 itself (Under Slackware
13.1) is actually not very smooth.  The official release actually does
not build out of the box for some packages (I used the binary
distribution to compile the rest).  When compiled the polyorb package,
I got error on some of the asis package needs to be recompiled (the
gnat part). If I remove those parts from my install tree (source and
ali), it could continue and success on the build. But then asis is
broken. ... then i need to recompile asis ....

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Stephen Leake]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> And why not promote some funding from other users ? Let say 1200 users
> of the GPL version, each funding $10 e year (relatively accessible),
> this  will reach the level of pricing for GNAT Pro on Windows. Try to
> negotiate  with AdaCore for a special kind of contract on this basis.
> Is that an  valid option ? This would not offer a full-support GNAT
> obviously, but  this may help to get more (very probably).

Ada core is in the business of selling support for Ada tools.

Trying to support 1200 users on $10 each is simply not possible (as you
say).

If Ada core is to start maintaining their sources in a more open way,
that will cost them time, and thus money. This would be an on-going
cost, not a one-time expenditure. SO there has to be an on-going income
stream to support that. 1200 users at $10 each, guaranteed for the next
10 years, might work. But no one will believe that 10 year commitment.

-- 
-- Stephe

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Stephen Leake]

deadlyhead <deadlyhead@gmail.com> writes:

> I actually can't see any downside to AdaCore developing on a GCC
> branch.  

It would take them more time than they currently spend developing Ada.
Somebody has to pay for that time.

It would also invite more requests for support, which would take more
time. 

> They could release wavefront releases for their paying customers, just
> as they currently do, but they'd get the benefit of a rapid release
> cycle with full community input just like the rest of GCC. 

GNAT Pro has significantly higher quality at release time than FSF Gnu
C++. That's what AdaCore customers pay for. Opening up the developement
process to community input would detract from that quality, or require
significantly more effort to bring the community input up to the
expected quality.

> They could integrate the Debian-style fix for libaddr2line, etc, and
> stop maintaining their own custom binutils, too, and maintain public
> sync for all their technologies. 

They are intelligent people; they know this. I don't know their reasons
for not doing so. Some of it may just be inertia, but I trust they are
making good business decisions.

> How many more people might use Ada if the GNAT technologies were as
> accessible as the rest of GCC?

I don't know. I suspect the AdaCore marketing department has a much
better answer to that than anyone else. Although it's probably slanted
to "how many people will pay for support of ...".

> As for my activities that prompted my original rant, I'll keep working
> on JGNAT for GNU/Linux, probably attempting to build against GCC-trunk
> from here on out.  If I can get that working, I'll make sure the
> entire world knows.  Also, since I use Debian as my base OS these
> days, I'd also like to see if I can backport the build to the Debian
> GNAT sources, in which case I'd approach Ludovic specifically.
>
> BTW, I can't stand Java, it makes me feel dirty just to read it, but I
> am compelled to develop Android apps, hence trying to build JGNAT.  I
> may try binding to the Android NDK at some point, too, but that
> requires GNAT-ARM crosstools.  One project at a time...

Ah, I was (vaguely) hoping to write Ada for Android (I'm frustrated with
some of the apps on my current aging Palm). I didn't realize that meant
compiling for the JVM.

Thanks for your efforts!

-- 
-- Stephe

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Shark8]

On Jan 20, 9:33 pm, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
>
> If Ada core is to start maintaining their sources in a more open way,
> that will cost them time, and thus money. This would be an on-going
> cost, not a one-time expenditure. SO there has to be an on-going income
> stream to support that. 1200 users at $10 each, guaranteed for the next
> 10 years, might work. But no one will believe that 10 year commitment.
>
> --
> -- Stephe

Well, they could give people the option to 'prepay' a certain number
of years.
If that was the case the hobbyist might well think, "hey I got a few
$10 bills laying around, I could support a couple of years of GNAT's
Ada."

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Thomas Løcke]

On 2011-01-21 06:00, Shark8 wrote:
> Well, they could give people the option to 'prepay' a certain number
> of years.
> If that was the case the hobbyist might well think, "hey I got a few
> $10 bills laying around, I could support a couple of years of GNAT's
> Ada."


I'd jump on that. Heck, I'd probably even jump on it if it were a lot
more.

-- 
Thomas L�cke

Email: tl at ada-dk.org
Web: http//:ada-dk.org
http://identi.ca/thomaslocke

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[J-P. Rosen]

Le 20/01/2011 19:46, Yannick Duchêne (Hibou57) a écrit :
> If really clients are allowed to re-distribute, this is indeed
> surprising, I could never believe this could be really possible:
> users/clients allowed to redistribute and none doing so. May be they
> feel that's better to not brake AdaCore business (I am talking about
> earnings) so that they are assured of a regular and good job done at
> maintaining the compiler ? (I would not expect it from the “crowd”, but
> they must be some kind of special users I believe).
Paying customers are typically big companies, and they are busy enough
to not care. Anyway, they are not used to distributing /anything/

> That said, do you think they could be some provision for the suggestion
> made, that is, some funding from GNAT GPL users to fix some bugs in the
> compiler (I would be very happy to see the one about synchronized
> interface fixed). Some room for a special contract ? Obviously, AdaCore
> could not receive all individual request from each; but we could make
> some collectively after some collegiate decisions.
People have been telling this to AdaCore for years; they said they were
not intersted.

> P.S. This must not be easy for AdaCore too I believe (I see no way to
> easily handle commercial + GPL). May be these FUD are the only way they
> could figure to protect it… just hope these FUD are not too much
> disturbing/nasty for their clients (ouch).
> 
It's in part sin by omission. The license explains that, since Gnat is
free software, the client is allowed to install the compiler on as many
machines as they want /within the company/ (they get support only for
the number of seats they paid for, though). The license forgets to tell
that the same is true /outside the company/ ...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a déménagé / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[J-P. Rosen]

Le 20/01/2011 22:56, deadlyhead a �crit :
> I actually can't see any downside to AdaCore developing on a GCC
> branch.  
> 
The difficulty AdaCore has to face is that the public version of Gnat is
a damn good compiler. Even if a new version appears only once a year,
it's still better than some other proprietary compilers.

Too many industrial users (not those who make rockets, but smaller
industries) simply use the public version, and it's hard to make them
pay when the public version is OK for their needs.

Up to 3.15, there was only a single line of products, AdaCore was simply
selling support for the compiler. Apparently, they had to change that
business model for reasons.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Dmitry A. Kazakov]

On Fri, 21 Jan 2011 08:19:25 +0100, J-P. Rosen wrote:

> Le 20/01/2011 22:56, deadlyhead a �crit :
>> I actually can't see any downside to AdaCore developing on a GCC
>> branch.  
>> 
> The difficulty AdaCore has to face is that the public version of Gnat is
> a damn good compiler. Even if a new version appears only once a year,
> it's still better than some other proprietary compilers.
>
> Too many industrial users (not those who make rockets, but smaller
> industries) simply use the public version, and it's hard to make them
> pay when the public version is OK for their needs.
>
> Up to 3.15, there was only a single line of products, AdaCore was simply
> selling support for the compiler. Apparently, they had to change that
> business model for reasons.

I think that AdaCore should probably modify their business model in order
to have something between the FSF for 0 and Pro for 15K. Many small
businesses and private persons would promptly buy Linux or Windows GNAT for
$100-500 without support +, say, $25-50 per upgrade. This would not compete
with GNAT Pro, because, my guess, Pro targets rather embedded and R-T
solutions, e.g. VxWorks and standalone, or impose no additional costs.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Yannick Duchêne (Hibou57)]

Le Fri, 21 Jan 2011 10:29:58 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> Too many industrial users (not those who make rockets, but smaller
>> industries) simply use the public version, and it's hard to make them
>> pay when the public version is OK for their needs.
>>
>> […]
>
> I think that AdaCore should probably modify their business model in order
> to have something between the FSF for 0 and Pro for 15K. Many small
> businesses and private persons would promptly buy Linux or Windows GNAT  
> for
> $100-500 without support +, say, $25-50 per upgrade. This would not  
> compete
> with GNAT Pro, because, my guess, Pro targets rather embedded and R-T
> solutions, e.g. VxWorks and standalone, or impose no additional costs.

Not only AdaCore could do that, also many others applications too  
(whisper: unfortunately, the GPL and its assumptions does not help to go  
this way). For GNAT $500 would be far too much for me. $100 would an  
higher limit… while… well, with some effort, this could be feasible. I  
would just require a single condition: the “synchronized interface” bug  
fixed :D (I really hate this bug, as you guessed).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Yannick Duchêne (Hibou57)]

Le Fri, 21 Jan 2011 07:26:00 +0100, Thomas Løcke <tl@ada-dk.org> a écrit:

> On 2011-01-21 06:00, Shark8 wrote:
>> Well, they could give people the option to 'prepay' a certain number
>> of years.
>> If that was the case the hobbyist might well think, "hey I got a few
>> $10 bills laying around, I could support a couple of years of GNAT's
>> Ada."
>
>
> I'd jump on that. Heck, I'd probably even jump on it if it were a lot
> more.

AdaCore potentially have really supporting users in the public area ;)


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[J-P. Rosen]

Le 21/01/2011 10:29, Dmitry A. Kazakov a �crit :

> I think that AdaCore should probably modify their business model in order
> to have something between the FSF for 0 and Pro for 15K. Many small
> businesses and private persons would promptly buy Linux or Windows GNAT for
> $100-500 without support +, say, $25-50 per upgrade. This would not compete
> with GNAT Pro, because, my guess, Pro targets rather embedded and R-T
> solutions, e.g. VxWorks and standalone, or impose no additional costs.
> 
I discussed that in the past with Robert Dewar. His answer was:
"We are not in the cheap compiler business".

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Fritz Wuehler]

> I think that AdaCore should probably modify their business model in order
> to have something between the FSF for 0 and Pro for 15K. Many small
> businesses and private persons would promptly buy Linux or Windows GNAT
> for $100-500 without support +, say, $25-50 per upgrade. This would not
> compete with GNAT Pro, because, my guess, Pro targets rather embedded and
> R-T solutions, e.g. VxWorks and standalone, or impose no additional
> costs. 

I would certainly be willing to pay this for an unencumbered copy. That is,
I get the use of the product and runtime with no additional charges, and one
copy of bound, hardcopy doc (which I hope is better than the regular gcc
doc btw). Even better if GPL is nowhere in the equation. I don't need the
source to the compiler, I just want the executables for 32 and 64 bit and
whatever libraries I need for the runtime. They can license their runtime
however they want, as far as I am concerned it belongs to them. I mean a
proprietary license would be fine. At least this is what would appeal to me.

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Oliver Kellogg]

On Fri, 21 Jan 2011 07:26:00 +0100, Thomas Løcke wrote:

> On 2011-01-21 06:00, Shark8 wrote:
>> Well, they could give people the option to 'prepay' a certain number of
>> years.
>> If that was the case the hobbyist might well think, "hey I got a few
>> $10 bills laying around, I could support a couple of years of GNAT's
>> Ada."
> 
> 
> I'd jump on that. Heck, I'd probably even jump on it if it were a lot
> more.

I'll put my +1 on that, too.
Or, if AdaCore is "not in the cheap compiler business", how about just 
plain donations in the SourceForge style of "donate to project". I've 
seen that it's possible to donate to FSF - but I'm not sure an FSF 
donation could be redirected specifically to AdaCore stuff.

Oliver (speaking only as a private person, of course)

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Yannick Duchêne (Hibou57)]

Le Fri, 21 Jan 2011 20:11:17 +0100, Oliver Kellogg  
<okellogg@users.sourceforge.net> a écrit:
> I'll put my +1 on that, too.
> Or, if AdaCore is "not in the cheap compiler business", how about just
> plain donations in the SourceForge style of "donate to project". I've
> seen that it's possible to donate to FSF - but I'm not sure an FSF
> donation could be redirected specifically to AdaCore stuff.
>
> Oliver (speaking only as a private person, of course)

The matter here would be one like Fritz Wuehler pointed in another reply  
to this thread: licensing. I am not sure every one would enjoy to pay for  
a GPLed application they could not really use for their own purpose.  
Funding the FSF would be paying for something you could not use freely.  
That is far less attractive.

He exactly say “Even better if GPL is nowhere in the equation.”… and I  
personally insist on that too (I would not buy a GPL licensed application  
whose license states you are not the owner of things you created with  
that… the runtime and standard library matters here).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Yannick Duchêne (Hibou57)]

Le Fri, 21 Jan 2011 16:26:22 +0100, Fritz Wuehler  
<fritz@spamexpire-201101.rodent.frell.theremailer.net> a écrit:
> Even better if GPL is nowhere in the equation.
Thanks to have raised the point. This was so much obvious to me that I did  
not thought to mention it explicitly: the runtime and standard library  
should not be GPL licensed (what ever is the compiler, I don't bother).

> I don't need the
> source to the compiler, I just want the executables for 32 and 64 bit and
> whatever libraries I need for the runtime.
That's a point indeed, although “Open Source” is sold as a must have, as a  
Holy Grail every one should seek for, while many people just want a  
working binary (few people look at the source).

However, source may be required to build cross compilers, and I personally  
(not every one, yes) would require that to be available.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> The matter here would be one like Fritz Wuehler pointed in another
> reply to this thread: licensing. I am not sure every one would enjoy
> to pay for a GPLed application they could not really use for their own
> purpose.  Funding the FSF would be paying for something you could not
> use freely.  That is far less attractive.

That is just so not true.

The FSF compiler runtimes (well, I only really know about the Ada one;
but see [1], [2]) in general contain text such as this in s-oslib.ads
from GCC 4.5.0:

-- As a special exception under Section 7 of GPL version 3, you are
-- granted additional permissions described in the GCC Runtime Library
-- Exception, version 3.1, as published by the Free Software Foundation.

which is explicitly designed to allow you to use GCC to develop non-free
programs.

GNAT Pro runtimes contain older wording with the same intent (they may
have been updated; haven't looked recently).

GNAT GPL runtimes have this wording removed by an automated process
during the release process (I say this because you can see the blank
lines where it used to be!) and therefore can not be used to develop
non-free programs.

[1] http://www.gnu.org/licenses/gpl-faq.html#LibGCCException
[2] http://www.gnu.org/licenses/gcc-exception-faq.html

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Yannick Duchêne (Hibou57)]

Le Fri, 21 Jan 2011 21:41:00 +0100, Simon Wright <simon@pushface.org> a  
écrit:
> GNAT GPL runtimes have this wording removed by an automated process
> during the release process (I say this because you can see the blank
> lines where it used to be!) and therefore can not be used to develop
> non-free programs.
Yes, I know these blank-lines and I care about it.

I did not know the FSF version of GNAT does not come with these  
blank-lines, I always believed only MinGW was.
Thanks for the tip.

Note: if I'm not wrong the ASIS library is a case apart (just wanted to  
tell, so people care if they have too).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Randy Brukardt]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:82k4hyq328.fsf@stephe-leake.org...
> deadlyhead <deadlyhead@gmail.com> writes:
>
>> I actually can't see any downside to AdaCore developing on a GCC
>> branch.
>
> It would take them more time than they currently spend developing Ada.
> Somebody has to pay for that time.

I second this suggestion. Indeed, I find it amazing that anyone can build 
large software like a compiler even when they have all of the source.

Case in point, I recently recompiled Janus/Ada with the current Janus/Ada 
compiler (rather than the older baseline compiler). That ended up taking 
parts of 8 days! And that was with nothing expecting needing change in 
either the building setup or compiler source.

But all manner of bugs showed up, both in the current Janus/Ada compiler 
(which is amazing to me, given that I've been using that version for all of 
my work other than the compiler for 7 or so years) and in the compiler 
itself (due to improved checking of Ada rules in the latest compiler). Plus 
a number of mysterious problems, one of which appeared only once and hasn't 
reappeared since, and another which turned out to be caused by mistakenly 
running the wrong compiler in the testing directory (there was some missing 
version checking [now fixed], and apparently the files are getting laid out 
differently, so the older compiler scrambled the project files).

Anyway, I'd consider it a miracle if anyone could compile something as large 
as the GNAT sources with anything other than the exact setup they were 
originally created with. There is just too much chance of running across 
some obscure bug otherwise.

The less stable the development environment, the harder it would be to work 
on the compiler. And that costs time, which of course costs money (at least 
for a commercial company like AdaCore).

                                       Randy.

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Yannick Duchêne (Hibou57)]

Le Sat, 22 Jan 2011 06:09:25 +0100, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> Case in point, I recently recompiled Janus/Ada with the current Janus/Ada
> compiler (rather than the older baseline compiler). That ended up taking
> parts of 8 days! And that was with nothing expecting needing change in
> either the building setup or compiler source.
> […]
> Anyway, I'd consider it a miracle if anyone could compile something as  
> large
> as the GNAT sources with anything other than the exact setup they were
> originally created with. There is just too much chance of running across
> some obscure bug otherwise.
I am not sure to understand. I could already built some GNAT binaries  
without so much trouble, even with some modified setup (I even modified  
some tiny things in some minor parts of the compiler itself at that time).

What do you mean by “the exact same setup” here ? Can you explain with an  
example ?

What would be amazing, would be valid sources not compiling (and most of  
GNAT is written in Ada). That sound mysterious.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Lucretia]

On Jan 20, 10:58 am, deadlyhead <deadlyh...@gmail.com> wrote:
> I have no doubt that my desires are pretty unique: I want to target
> the JVM, but develop entirely on GNU/Linux.  My commitment to free
> software in general, and my disdain for windows in particular, prevent
> me from just doing what's expected and using the binaries released by
> AdaCore.  So, instead, I want to compile JGNAT from the AJIS sources
> that AdaCore provides.

I didn't think the AJIS archives contained the jgnat backend, the last
time I looked at the readme it only mentioned tools to interface Ada
native code with within Java, not compiling Ada -> JVM bytecode.

Luke.

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Lucretia]

On Jan 20, 9:56 pm, deadlyhead <deadlyh...@gmail.com> wrote:

> BTW, I can't stand Java, it makes me feel dirty just to read it, but I
> am compelled to develop Android apps, hence trying to build JGNAT.  I
> may try binding to the Android NDK at some point, too, but that
> requires GNAT-ARM crosstools.  One project at a time...

I have actually started ZCX support for ARM, I have modified the
sources, didn't know about impunit, so need to patch that and I'm
almost there, just need to work out what needs to go in to get it to
actually use the exception block - that's the hard part :D

Luke.

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2856 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.vpo4zvvaule2fv@garhos...
>Le Sat, 22 Jan 2011 06:09:25 +0100, Randy Brukardt <randy@rrsoftware.com> 
>a �crit:
>> Case in point, I recently recompiled Janus/Ada with the current Janus/Ada
>> compiler (rather than the older baseline compiler). That ended up taking
>> parts of 8 days! And that was with nothing expecting needing change in
>> either the building setup or compiler source.
>> [.]
>> Anyway, I'd consider it a miracle if anyone could compile something as 
>> large
>> as the GNAT sources with anything other than the exact setup they were
>> originally created with. There is just too much chance of running across
>> some obscure bug otherwise.
>I am not sure to understand. I could already built some GNAT binaries 
>without so much trouble, even with some modified setup (I even modified 
>some tiny things in some minor parts of the compiler itself at that time).
>
>What do you mean by "the exact same setup" here ? Can you explain with an 
>example ?

I meant the same compiler, runtime libraries, tools, etc.

>What would be amazing, would be valid sources not compiling (and most of 
>GNAT is written in Ada). That sound mysterious.

"Ada" is an abstract notion. No compiler implements Ada exactly right, and 
I'm dubious that is even possible. There are literally billions on 
combinations possible, and of course most of those combinations are 
harmless. But there always are some that are not.

Beyond that, the source code isn't really "Ada", its some close relative. 
One of the problems I had with the Janus/Ada (which is also all in Ada, and 
almost all in Ada 83) was that there was some error checking that previous 
Janus/Ada compilers had missed, but now was being detected. The code was 
obviously "non-Ada" in this sense, and there was no intent that such code be 
"non-Ada", but it happened anyway. It is trivally easy to depend on a bug in 
a compiler; almost all large programs do. (That's why large projects usually 
"freeze" their compilers at some point.)

Moreover, bugs can extend beyond the source code. The problem I had with the 
Janus/Ada optimizer occurred because the code being optimized was too 
simple! The code was so simple that the optimizer actually was making it 
bigger and that caused the buffer to overflow (since it doesn't know how to 
grow - it's not needed). This isn't the sort of effect that you could notice 
from normal testing -- you actually would have to try to compile packages 
with that sort of code (no test programs were large enough to expose the 
problem).

I'm sure GNAT has somewhat fewer of these issues, as their compiler has more 
users than Janus/Ada does, but that isn't likely to make it free of such 
issues, just a bit less likely to show them.

                          Randy. 

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[deadlyhead]

On Jan 22, 7:28 am, Lucretia <Lucretia9...@yahoo.co.uk> wrote:
> On Jan 20, 10:58 am, deadlyhead <deadlyh...@gmail.com> wrote:
>
> > I have no doubt that my desires are pretty unique: I want to target
> > the JVM, but develop entirely on GNU/Linux.  My commitment to free
> > software in general, and my disdain for windows in particular, prevent
> > me from just doing what's expected and using the binaries released by
> > AdaCore.  So, instead, I want to compile JGNAT from the AJIS sources
> > that AdaCore provides.
>
> I didn't think the AJIS archives contained the jgnat backend, the last
> time I looked at the readme it only mentioned tools to interface Ada
> native code with within Java, not compiling Ada -> JVM bytecode.
>
> Luke.

Actually, I was pleasantly surprised (even though I've still had no
luck building JGNAT).  The AJIS archive that can be downloaded from
libre.adacore.com actually contains the entire JGNAT sources that can
be downloaded if you select jvm-windows as your download target, plus
all of the AJIS code to boot.  I did a diff just to be sure, and they
are exactly the same.  *surprise!*

--deadlyhead

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Marco]

On Friday, January 21, 2011 2:29:58 AM UTC-7, Dmitry A. Kazakov wrote:


> I think that AdaCore should probably modify their business model in order
> to have something between the FSF for 0 and Pro for 15K. Many small
> businesses and private persons would promptly buy Linux or Windows GNAT for
> $100-500 without support +, say, $25-50 per upgrade. This would not compete
> with GNAT Pro, because, my guess, Pro targets rather embedded and R-T
> solutions, e.g. VxWorks and standalone, or impose no additional costs.

  For the embedded world high quality C/C++ compilers cost around $5K but have a larger customer base so charging a little more for Ada seems reasonable. The $15K seems high to me it should be closer to $10K. I think that is around the price of the Green Hills Ada 95 compiler.

  If a pure free GPL Ada compiler is needed many folks would need to become compiler maintainers and just fork off from GNAT. I seriously doubt this will happen.

  Can't we let the AdaCore people make a living I doubt anyone there is getting rich.

Re: Thoughts on AdaCore maintaining GCC-incompatible GNAT sources

[Yannick Duchêne (Hibou57)]

Le Tue, 25 Jan 2011 02:29:17 +0100, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
>> What do you mean by "the exact same setup" here ? Can you explain with  
>> an
>> example ?
>
> I meant the same compiler, runtime libraries, tools, etc.
>
>> What would be amazing, would be valid sources not compiling (and most of
>> GNAT is written in Ada). That sound mysterious.
>
> "Ada" is an abstract notion. No compiler implements Ada exactly right,  
> and
> I'm dubious that is even possible. There are literally billions on
> combinations possible, and of course most of those combinations are
> harmless. But there always are some that are not.
> [...]
> Moreover, bugs can extend beyond the source code. The problem I had with  
> the
> Janus/Ada optimizer occurred because the code being optimized was too
> simple! The code was so simple that the optimizer actually was making it
> bigger and that caused the buffer to overflow (since it doesn't know how  
> to
> grow - it's not needed). This isn't the sort of effect that you could  
> notice
> from normal testing -- you actually would have to try to compile packages
> with that sort of code (no test programs were large enough to expose the
> problem).
>
> I'm sure GNAT has somewhat fewer of these issues, as their compiler has  
> more
> users than Janus/Ada does, but that isn't likely to make it free of such
> issues, just a bit less likely to show them.
>
>                           Randy.

So you just increased the quality of your implementation. That's a good.

At least this kind of language or implementation topics are workable and  
stands for goods (this also advocate for the use of more than just a  
single unique compiler), while the troubles which come with different  
build process, environment, available libraries, etc, are less fun (these  
ones are real nightmare).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]