What is the best license to use for open source software?

[Hubert]

Hi,
I am working on a tool program that I want to make available as open
source. Since I am using Gnat GPL, I am not sure if I have to make my
source GPL too or can I change the license? I don't really want to
impose any restrictions on the user, so I dont want to force anybody to
make their code open source because they use my code, but since it's
based on Gnat, I don't know if that's possible.

What do others here do with their open source code? Is there a template
license that I can just copy into my source files?

Thanks

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

[Jeffrey Carter]

On 01/04/2015 12:43 PM, Hubert wrote:
> Hi,
> I am working on a tool program that I want to make available as open source.
> Since I am using Gnat GPL, I am not sure if I have to make my source GPL too or
> can I change the license? I don't really want to impose any restrictions on the
> user, so I dont want to force anybody to make their code open source because
> they use my code, but since it's based on Gnat, I don't know if that's possible.

It depends on what you're releasing.

If you only release the source code, then you can give it any license you like.
It doesn't matter what compiler you use to compile it for your personal use.

If you release a binary compiled with GNAT GPL, then the binary and so the
source must be released under the GPL.

I don't know of any compiler other that GNAT GPL that imposes the GPL on
programs compiled with it, so if you release a binary compiled with another
compiler you should be able to use any license you like.

> What do others here do with their open source code? Is there a template license
> that I can just copy into my source files?

I release open-source programs under the GPL. I release source-only libraries
under the GMGPL.

--
Jeff Carter
"Clear? Why, a 4-yr-old child could understand this
report. Run out and find me a 4-yr-old child. I can't
make head or tail out of it."
Duck Soup
94

[David Botton]

You can put any license on your code but if compiled with shareware GNAT it will be virused into GPL (if compatible) or be in violation of the GPL, but that is only once compiled, some one else compiling your source code on an open gcc/ada compiler your license would apply as intended.

Unless writing a tool that you would want under the full GPL, I recommend BSD/MIT or GMGPL. You can copy the GMGPLv3 from the Gnoga files if you like. Or do a search for BSD or MIT license, etc.

David Botton

[Ludovic Brenta]

David Botton writes:
> You can put any license on your code but if compiled with shareware

Please use correct words; you are creating confusion. No version of
GNAT is shareware.

> GNAT it will be virused into GPL (if compatible) or be in violation of
> the GPL, but that is only once compiled, some one else compiling your
> source code on an open gcc/ada compiler your license would apply as
> intended.
>
> Unless writing a tool that you would want under the full GPL, I
> recommend BSD/MIT or GMGPL. You can copy the GMGPLv3 from the Gnoga
> files if you like. Or do a search for BSD or MIT license, etc.

The GMGPL has been superseded by GPL version 3 with run-time library
exception.

--
Ludovic Brenta.

[David Botton]

> Please use correct words; you are creating confusion. No version of
> GNAT is shareware.

GNAT GPL is shareware, a try before you buy product for GNAT PRO. I see no issue with calling it was it is and stopping the clear confusion that it has created that it is the "standard" gcc/ada GNAT tool chain available to the community. Clarity doesn't come from making "believe" a GPL run-time designed to prevent commercial use is not shareware. They have the right to do it, we have the right to call it what it is. There is no shame in creating and promoting a shareware / trialware product. It ain't cool, but they have the right.

It is important that others not create confusion by trying to imply otherwise and continue to point people in the direction of a shareware product instead of a product that advocates Ada at the expense of promoting a specific product.

I am happy to state to any one from experience about the fantastic "Gnat PRO product" a cutting edge build of gcc/ada build with maintenance contract.

Those of use not in the AdaCore "niche" should be using, testing and contributing to distro's like your very own Debian one.

> The GMGPL has been superseded by GPL version 3 with run-time library
> exception.

It does seem that way, however I've noticed that many GPLv3 with run-time exception products include the "modified" text of the old GMGPL. Do you know if that is by design? I've left the "modified" text in Gnoga which is GPLv3 since it seems to be in most AdaCore products. If you tell me is an oversight by others I'll remove it from Gnoga as well.

Thanks!
David Botton

[Ludovic Brenta]

David Botton writes:
>> Please use correct words; you are creating confusion. No version of
>> GNAT is shareware.
>
> GNAT GPL is shareware, a try before you buy product for GNAT PRO. I
> see no issue with calling it was it is and stopping the clear
> confusion that it has created that it is the "standard" gcc/ada GNAT
> tool chain available to the community. Clarity doesn't come from
> making "believe" a GPL run-time designed to prevent commercial use is
> not shareware. They have the right to do it, we have the right to call
> it what it is. There is no shame in creating and promoting a shareware
> / trialware product. It ain't cool, but they have the right.

No. GPL software is *not* shareware and does *not* prevent commercial
use, except in your opinion. Do not present your opinion as truth; this
is confusing.

>> The GMGPL has been superseded by GPL version 3 with run-time library
>> exception.
>
> It does seem that way, however I've noticed that many GPLv3 with
> run-time exception products include the "modified" text of the old
> GMGPL. Do you know if that is by design? I've left the "modified" text
> in Gnoga which is GPLv3 since it seems to be in most AdaCore
> products. If you tell me is an oversight by others I'll remove it from
> Gnoga as well.

Yes, it is a mistake to mix GPLv3 with runtime library exception with
GMGPL wording. Use one or the other, not a mix of the two.

--
Ludovic Brenta.

[David Botton]

> No. GPL software is *not* shareware and does *not* prevent commercial
> use, except in your opinion. Do not present your opinion as truth; this
> is confusing.

GPL is a license. Shareware is a sales model. You are trying to compare apples and oranges. There is no confusion on my part or in my statements only making something crystal clear, even if painful for some to face.

In this case the company openly and intentionally publishes the run-time using the GPL license to "prevent and restrict" freedom of use in proprietary software and to discourage commercial use to _promote_ their commercial product. That is called shareware, (restricted right product to encourage purchase of less restrictive right product) you may not like it it being called out for what it is, but clarity is important.

Promoting a shareware compiler as a community option is harmful to general Ada advocacy.

There are strong viable gcc/ada distros that are not shareware and it is important to support and build on them to advocate Ada as a long term viable language for general purpose computing not just niche computing for deep pocket systems software. It is important that new users understand that if they are using GNAT GPL they are using a "shareware product" and there are other _professional options_ whatever their budget ranges for Ada use including proprietary software which is frequently needed in every domain.

We all want AdaCore to not just "survive" but to "thrive" because of what they send upstream to the FSF as GPL with run-time exceptions. (Disclaimer, others may have other reasons to like AdaCore, they do much good, even if they are harming the community in this area. Add the run time extension and a become bit more humble and they would be the Arch Angels of Ada :)

I am happy that many of my past projects are still being used by their customers and I am happy that Gnoga will be used by their customers (I know of some exploring its use now). That's a happy thought for me. Ada wins - they win and the community wins. You maintain gcc/ada on Debian. It encourages use of Ada and some of those users go on to need AdaCore services or feel the comfort level that Ada is not some niche language because of it, etc. Ada wins, they win and the community wins. The many others that write Ada code with unrestrictive licenses do the same, win win.

GPL runtimes on the compiler (or for that matter not on any "interface" library) are not Ada "win win" solutions, not even RMS, the FSF and the Free software movement (that I consider my self a strong advocate of and have the sloc to prove it).

> Yes, it is a mistake to mix GPLv3 with runtime library exception with
> GMGPL wording. Use one or the other, not a mix of the two.

Thank you, I'll make the changes this week to the Gnoga headers and I'd encourage then others to inspect their headers as well. I recall seeing similar language in many AdaCore files and parts of AWS.

David Botton

[Ludovic Brenta]

David Botton writes:
>> No. GPL software is *not* shareware and does *not* prevent commercial
>> use, except in your opinion. Do not present your opinion as truth; this
>> is confusing.
>
> GPL is a license. Shareware is a sales model. You are trying to
> compare apples and oranges. There is no confusion on my part or in my
> statements only making something crystal clear, even if painful for
> some to face.

Stop it.

Quoting Wikipedia: "The term shareware is used in contrast to
open-source software, in which the source code is available for anyone
to inspect and alter, and freeware, which is software distributed at no
cost to the user but without source code being made available."

https://en.wikipedia.org/wiki/Shareware

And the inventors of the GPL coined the term "free software" with the
specific goal of distinguishing it from "shareware".

https://www.gnu.org/philosophy/categories.html

--
Ludovic Brenta.

[David Botton]

> Stop it.

No, without debating if wikipedia is even definitive, my definition is supported by that article. The idea that software has to be "proprietary" to be shareware is simply not true. It is just the most common form. Just like the statement in the FSF article says that it "usually doesn't include source" but certainly does sometimes.

GNAT GPL could be called shareware, trialware, demoware, etc. everyone is valid.

It is what it is. A demo of tech that uses the GPL to license virus its output to encourage purchase of a commercial product. It is of questionable benefit to the company, it is harmful to the Ada community and it is not helpful at all to the GPL community (ok, maybe for bootstrap purposes....)

What is important and the only reason for beating this horse that won't die (no offense to horses intended) is that it is imperative that as a community everyone show a consistent message that the fsf gcc/ada versions are the primary Ada compiler and if you are so inclined that there are other great options for those needing high end support and "critical" compilers at AdaCore, i.e. go back to the original ACT approach, even if they want to continue to "scare" or GPL run-time bully away those with out the funds for their commercial product.

To make sure newbie understand they are just using the "shareware" version and that there is a real libre version that has no hidden agenda or license virus just like all the other gcc compilers.

David Botton

[Hubert]

OK, I have seen the BSD license before, I will take a closer look at it.
Seems that is a better option than these GPL versions, I don't really
know where that is now with all the versions and derivations.

[Dirk Heinrichs]

David Botton wrote:

> It is what it is. A demo of tech...

No, it's not. It's not a demo, it's a fully featured product. If you don't
like the license, don't use it. Use FSF Gnat instead.

HTH...

Dirk
--
Dirk Heinrichs <dirk.he...@altum.de>
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key CB614542 | Jabber: dirk.he...@altum.de
Tox: he...@toxme.se
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

[David Botton]

Demos are usually fully featured and the issue is the impression others will have of the availability of Ada. If the impressionion is Ada is available only for open source or high end niche that leaves most of the world in the middle. That is not Ada advocacy that is harmful.

David Botton

[Mark Carroll]

David Botton <da...@botton.com> writes:

> Demos are usually fully featured and the issue is the impression others will have of the availability of Ada. If the impressionion is Ada is available only for open source or high end niche that leaves most of the world in the middle. That is not Ada advocacy that is harmful.

Out of curiosity, am I correct in understanding that we have the GPL one
available at all only because of contractual requirements negotiated by
the DoD? If so, does it actually satisfy their intent? I wondered if
there is some other niche for it that they had in mind.

-- Mark

[David Botton]

> Out of curiosity, am I correct in understanding that we have the GPL one
> available at all only because of contractual requirements negotiated by
> the DoD?

We are not really discussing the availability of gnat as GPL but a specific build of gnat that is released by Ada core called "GNAT-GPL" and the importance of making sure the community _not_ imply that this is a "community edition" or otherwise allow people to get scare off from Ada as being unusable for proprietary and commercial projects if they are not deep pocket systems projects.

> If so, does it actually satisfy their intent? I wondered if
> there is some other niche for it that they had in mind.

My understanding is they wanted to promote Ada 95 its use and prevent stumbling blocks for wider acceptance.

AdaCore is not in violation of anything and are with in their rights to "convert" the run-time to full GPL to benefit their corporate interests even if at the expense of the Ada advocacy beyond their niche.

As a community interested in Ada advocacy there is no idea here about "stopping" AdaCore or even "changing" their minds, there is though the need to fill in the massive gap left between the shareware/demo/trial/viral GPL edition and the commercial PRO support package. A need for a "PRO Community" edition = the FSF distros.

So what there needs to be is an effort to:

1. Insure that the viral GPL edition is not misrepresented as a community edition.
2. That we improve the image, packaging and tools around the community edition.

GetAdaNow.com is a start in pushing the available community editions. This year time to start making the community edition look sharp and flashy and attractive to pro users.

My invitation to advertise and market AdaCore as part of that Ada advocacy effort in exchange for regular publishing a public version that is not viral still stands if they ever change their minds in the future. (I was never "asking" AdaCore for something, I was and am offering something ;)

My interests are constructive and I am happy that AdaCore will still gain customers even if not directly marketed by a strong community edition.

David Botton

[G.B.]

On 04.01.15 23:13, David Botton wrote:
> Clarity doesn't come from making "believe" a GPL run-time designed to prevent commercial use is not shareware.

Clarity would be good, indeed. Implied universal quantifiers
about licensing variables are the source of many misunderstandings
here, I think. Granted, these are a requisite of software politics.

"Shareware" and its diverse associations in one's mind
seems an unrelated issue to me, and, moreover, the notion
has the potential of creating confusion whilst there could
be a chance to point out, once again after many years, the
problem of Ada 2005 pricing in general.

As an example of commercial GPL software, our company depends
on some GPLed source commercially in products
that we sell to a customer; however, the contract between
the customer and us requires that we always deliver
the sources, anyway. This commercial GPL situation may be
particular, but it exists.

It is politics to confuse "commercial" and "GPL" in general
propositions. This confusion doesn't help with deciding whether
or not FSF GCC is a viable option if one need to learn about
the implications of the linking exception.

It is clear from the GPL that *if* the commercial use of
the GPLed software should evolve into a *closed* *source*
distribution of derivative works, *then* the latter use is
illegal. The GPL virus prevents these illicit dealings in
software, in this particular case. The mataphor invoking
"virus" becomes increasingly inadequate, paradoxical actually,
but I understand the political intent.

But is it so hard to admit a preference for a business model that
eventually is, yes, *closed* *source*? I.e., no matter how free
the compiler is or how open source the libraries are, the final
products should be copy protected! The GPL's copyleft openly
prevents some kinds of copy protection. The linking exception
removes that in many cases.

Clarity? I'd find the licensing issues and business issues
much more clearly expressed if arguments would stop
using the big words and the free floating comparatives.

For example, are these facts?

- AdaCore support pricing, which entails the GPL linking
exception, is incompatible with most small businesses.

- If all Ada 2005 pricing is incompatible with small
business, then small business and Ada 2005 are incompatible.


Now imagine RR Software's compiler being updated and
targeting the LLVM.

What would your preferences be, then, WRT licensing and pricing?

[G.B.]

On 05.01.15 12:38, David Botton wrote:
> Demos are usually fully featured and the issue is the impression others will have of the availability of Ada. If the impressionion is Ada is available only for open source or high end niche that leaves most of the world in the middle. That is not Ada advocacy that is harmful.

2nd WRT impression management.

Dragging in more notions, though, seem counterproductive
to me if clarifying takes adducing their definition as well.
Recursively.

[Brad Moore]

On 15-01-05 04:38 AM, David Botton wrote:
> If the impressionion is Ada is available only for open source or high end niche that leaves most of the world in the middle. That is not Ada advocacy that is harmful.
>
> David Botton
>

But Ada is not GNAT, and the fact that there is also a free version of
GNAT available should provide coverage for those in the middle who want
something for free. In addition, there are also other compilers
available that have other pricing models.

If the impression is that Ada is available only for open source or high
end niche, that is a false impression. Changing licenses of GNAT-GPL to
address a false impression doesn't make sense to me. It would make more
sense to do a better job of propagating a better impression based on fact.

Are there websites propagating this false impression that need to be
corrected?

If I search for "Ada Programming Language" the top search result I get
back is this....

http://en.wikipedia.org/wiki/Ada_%28programming_language%29

On this page, it mentions GNAT, but does not mention other compiler
vendors, nor does it mention the various flavors of GNAT, except under
the section on history with this sentence.

"A number of commercial companies began offering Ada compilers and
associated development tools, including Alsys, Telesoft, DDC-I, Advanced
Computer Techniques, Tartan Laboratories, TLD Systems, and others."


I think it would be helpful if this page also had a section or a link to
a more comprehensive list of the various versions of Ada compilers that
are currently available.

If I follow the hyperlink to GNAT, I end up at a page that describes the
licensing with the following;

"The compiler is licensed under the terms of the GNU General Public
License. The "GNAT GPL Edition" of the runtime is licensed under the GNU
General Public License while the "GNAT Pro Edition" is under the GNAT
Modified General Public License. All versions leading up to and
including 3.15p are licensed under the GMGPL. GNAT-FSF is included
within the GNU Compiler Collection with the GMGPL license governing the
runtime, it corresponds to the GNAT-GPL version of the previous year
(about 9 months apart). At version 4.4, the runtime was relicensed under
the GPL version 3 with the GCC Runtime Library Exception.[2] GNAT-FSF is
part of most major GNU/Linux or BSD distributions.

The GMGPL license in either GNAT Pro runtime or GNAT-FSF runtime permits
software that is licensed under a license that is incompatible with the
GPL to be linked with the output of Ada standard generic libraries that
are supplied with GNAT without breaching the license agreement.
Conversely, the GPL license of either GNAT GPL runtime or GNAT GAP
runtime requires software that is linked with the standard libraries to
be a GPL-compatible license to avoid being in breach of the license
agreement."

It seems pretty clear to me how the variants of licensing work, but
perhaps this could be improved upon to provide better clarity.

For instance, I think the first sentence gives the impression that GNAT
is GPL. It's not until you read further where you learn about other
variants. So I think the first sentence should be changed.

Brad

[G.B.]

On 05.01.15 14:59, Brad Moore wrote:
> If I follow the hyperlink to GNAT, I end up at a page that describes the
> licensing with the following;

https://en.wikipedia.org/wiki/GNAT#License

has been edited accordingly.

[David Botton]

> For example, are these facts?
>
> - AdaCore support pricing, which entails the GPL linking
> exception, is incompatible with most small businesses.

Correct

> - If all Ada 2005 pricing is incompatible with small
> business, then small business and Ada 2005 are incompatible.

No, since there are FSF gcc/ada editions (priced in range, in this case 0 but didn't have to be) that small businesses can use. AdaCore has pointed that out themselves.

> Now imagine RR Software's compiler being updated and
> targeting the LLVM.
>
> What would your preferences be, then, WRT licensing and pricing?

While I am a strong proponent of "libre" software it matters to me only if they made it available under a "free" license and since a compiler (or interface to system service) I also would hope with a runtime exception.

If they had a free license (and non-viral runtime), regardless if they had pricing in range for small business or not, I'd be pumping them all the time.

David botton

[David Botton]

> But Ada is not GNAT, and the fact that there is also a free version of
> GNAT available should provide coverage for those in the middle who want
> something for free. In addition, there are also other compilers
> available that have other pricing models.

If that free version is not viral yes, and there is one FSF GNAT and this discussion is about community marketing of the FSF GNAT version over the viral shareware one to make sure the very fact you are talking about is known to all.

> If the impression is that Ada is available only for open source or high
> end niche, that is a false impression.

Correct and why marketing in public forums the versions that advocate Ada across a broader spectrum (including mention when beneficial of other options) is important.

> Changing licenses of GNAT-GPL to
> address a false impression doesn't make sense to me.

I agree with you. There is no reason AdaCore should not "showcase" their product and if they want a shareware model that is their business.

What is needed is for the community to "showcase" a GNAT-Community edition that clearly shows Ada is viable for all potential markets.

My business proposal was for an AdaCore business edition to fill in the middle market. If they felt that made no business sense to them that is acceptable to me.

However for good Ada advocacy there needs to be something to fill in the gaps, there is as AdaCore pointed out FSF GNAT.

So I am going to go with AdaCore's own advice to me. That FSF GNAT fulfills that position.

I as an Ada advocate then am pushing for the community to start "showcasing" that "Community" edition and to make sure that a viral edition is never mistaken as being "what is available for that middle position".

> It would make more
> sense to do a better job of propagating a better impression based on fact.

That is exactly what I am advocating we do and already working on. GetAdaNow.com is the first step, i.e. making peoples first encounter with Ada compilers _not_ a viral edition. Next step is making that encounter a super positive one.

> Are there websites propagating this false impression that need to be
> corrected?

"False statements" /= "False impressions", "False impressions" /= "False statements"

Impressions are almost always based on careful choice of truths that are marketed.

I've pointed out in previous post "scare tactic" statements from the libre site and other posts and sites.

So, I hope you have some projects for this year to promote Ada, I'll start that thread asap. Be nice for people to start posting what there "Ada Advocacy for 2015" will be.



David Botton

[Maciej Sobczak]

> OK, I have seen the BSD license before, I will take a closer look at it.

I have read the GPL flame with great interest (as usual, because it seems to be a periodic phenomenon), but I think the discussion would not be complete if you are left with only two choices.
Some time ago the C++ community (yes, the guys everybody hates here and which happened to do lots of things just right ;-) ) came up with the Boost license, which was explicitly intended to support both open- and closed-source software. The community that relies on this license is now very large, which also means that its legal meaning is well established. For detailed wording see here:

http://opensource.org/licenses/bsl1.0.html

--
Maciej Sobczak * http://www.inspirel.com

[Tero Koskinen]

There are also other permissive open source licenses which supports open
and closed source software.

Ruby and JavaScript projects many times use MIT license.
For example, see Ruby on Rails (http://rubyonrails.org/) or JQuery
(https://jquery.org/license/).

Java and JVM -based projects often use Eclipse License.
Examples: Eclipse IDE itself, Clojure (http://clojure.org/license).

Personally, I prefer ISC license (basically simplified BSD), which comes
from Internet Software Consortium (home for BIND & stuff).
Example: OpenBSD; Ahven, my unit testing library for Ada
http://www.ahven-framework.org/LICENSE.txt

There are some wording differences between these licenses (Boost, MIT,
Eclipse, ISC), but generally they are compatible with each other and you
can include the code to closed source software without needing to
release the source code. (Of course, there might be some exceptions;
check the licenses first before combining code with different licenses.)

Yours,
Tero

[David Botton]

On Monday, January 5, 2015 10:56:19 AM UTC-5, Maciej Sobczak wrote:
> > OK, I have seen the BSD license before, I will take a closer look at it.
>
> I have read the GPL flame

No one is flaming the GPL. Most of us (but not all) use it and are happy with it.

> Some time ago the C++ community (yes, the guys everybody hates here and which happened to do lots of things just right ;-) )

Now that is flamebait if I've ever heard it ;)

> came up with the Boost license, which was explicitly intended to support both open- and closed-source software. The community that relies on this license is now very large, which also means that its legal meaning is well established. For detailed wording see here:
>
> http://opensource.org/licenses/bsl1.0.html

I will take a look, but I've generally been happy with GPL or GMGPL and it carries my intent. But yes the muddy waters in recent times may mean fresh looks at other options in order.

David Botton

[Jeffrey Carter]

On 01/05/2015 05:02 AM, Mark Carroll wrote:
>
> Out of curiosity, am I correct in understanding that we have the GPL one
> available at all only because of contractual requirements negotiated by
> the DoD? If so, does it actually satisfy their intent? I wondered if
> there is some other niche for it that they had in mind.

As I understand things, you are not correct.

The AJPO contracted with New York University to produce an Ada-95 compiler that
would fulfill a number of objectives. One was that the source code of the
compiler be freely available so that others could study the way the compiler was
written; this source had to have a GPL-like restriction so that any who used the
source as the basis for another compiler also had to make their source code
available. Another was that programs compiled with the compiler could be closed
source. Another was that NYU provide copies of the compiler for "free" [which
could include a charge for the actual cost of providing the copy, such as the
medium on which it was provided (often a CD in 1996), making the copy, and
sending it via snail mail].

Since some of the source code (standard generics) that had to have the GPL could
be compiled and included in the resulting executable (because of GNAT's
macro-expansion processing of generics), something not dealt with at the time by
any other gcc compiler, a modified license different from the GPL or the LGPL
was needed; the result was the GMGPL.

Later GNAT was transferred from NYU to Ada Core Technologies, with AdaCore
required to abide by the terms of the AJPO contract.

That contract was for an Ada-95 compiler. As the definition of Ada 0X
progressed, AdaCore included many of its features in GNAT. Eventually GNAT
became a full ISO/IEC 8652:2007 compiler, and only functioned as an Ada-95
compiler with a special compiler switch. At this point the compiler no longer
fell under the requirements of the contract. Since the source for this compiler
was derived from the GPL source of the earlier compiler, it continued to be GPL,
but there were no longer the requirements that programs compiled with the
compiler could be closed source or that AdaCore provide the compiler for free.
So the existence of GNAT GPL is not because of the contract; AdaCore must have
another reason for releasing it.

(In fact, early versions of GNAT GPL were Ada-95 compilers by default, and only
acted as ISO/IEC 8652:2007 compilers with a special switch. One could, and some
did, argue that these were Ada-95 compilers and so were covered by the contract
and were in violation of it. Since the DoD never objected, the point is moot.)

--
Jeff Carter
"Blessed is just about anyone with a vested interest in the status quo."
Monty Python's Life of Brian
73

[Jeffrey Carter]

On 01/05/2015 04:24 AM, Dirk Heinrichs wrote:
> David Botton wrote:
>
>> It is what it is. A demo of tech...
>
> No, it's not. It's not a demo, it's a fully featured product. If you don't
> like the license, don't use it. Use FSF Gnat instead.

In my experience, "shareware" has been used for full-featured software released
at no cost with a request that those who find the S/W useful send some money to
the developer(s). There is also the term "crippleware" for S/W released at no
cost but lacking some feature(s) that can be obtained by paying for the
full-featured version.

GNAT GPL does not match this definition of "shareware".

Some might claim that GNAT GPL does match this definition of "crippleware". As
an example of crippleware, see http://www.wolframalpha.com/. Some offered
features result in an exhortation to "Subscribe to Pro", and this is a
characteristic of most crippleware that is not present in GNAT GPL.

It would be easier to think of GNAT GPL as crippleware if every invocation of
the compiler resulted in an encouragement to buy GNAT Pro that required action
by the user before the compilation proceeded.

The GNAT Pro/GNAT GPL dichotomy seems unique: two products with essentially
identical features, differing only in the run-time license. Perhaps we should
dub GNAT GPL "RTL-ware".

[Michael B.]

On 01/05/15 03:28, David Botton wrote:
> It is what it is. A demo of tech that uses the GPL to license virus its output to encourage purchase of a commercial product.

But GNAT GPL is be used commercially. If you do in-house maintenance of
applications that are not sold/distributed, the GPL virus can't bite you.

[David Botton]

> But GNAT GPL is be used commercially. If you do in-house maintenance of
> applications that are not sold/distributed, the GPL virus can't bite you.

Lots of demo software can be useful in some situations, but that doesn't make it something good for Ada advocacy (or even Free software advocacy in a case of unencumbered run times).

Example, GPL would work for software I write for my medical clinics, however if I decided to sell or give away binaries of software I wrote for my clinics then likely it would not work. However.. If I decide to integrate the software I write with any of the other software, drivers or equipment in my office I _will_ be in violation of the GPL even if I don't distribute the binaries. If they are not "GPL" compatible.

David Botton

[sbelm...@gmail.com]

On Monday, January 5, 2015 3:45:48 PM UTC-5, David Botton wrote:
>
> If I decide to integrate the software I write with any of the other software, drivers or equipment in my office I _will_ be in violation of the GPL even if I don't distribute the binaries. If they are not "GPL" compatible.
>

A license is an agreement between two parties: you and the person you distribute the software to. If you don't distribute the program, then no license exists, and certainly no violations thereof. License 'incompatibilities' only refer to how it can be RE-licensed, not used (well, normally. A license can say absolutely anything at all).

[Hubert]

> I'd be happy with a low-cost non-support non-encumbered ACT release...
> Say $100-200 to get a version without the GPL passthrough to built
> applications, but with no rights to pester them about perceived bugs.

I agree. All these arguments here really sound like nitpicking that
serve no one.
I think the future of Ada would be better served if there was a low cost
version of Gnat that can be used in small scale commercial projects.
Other companies do that a lot, I see that especially in the gaming tool
industry where there are offers like "Free to use if you make less than
so much money per year, above that a paid version is required. Could be
in one or two price levels.

[David Botton]

Can either of you tell me why the FSF gcc/ada doesn't serve that purpose now and at a zero price point?

For windows TDM-GCC (4.9.2) seems to be working well for me. See GetAdaNow.com
Granted the lack of gprtools is annoying, gnatmake still works for my purposes on Windows.

David Botton

[Hubert]

On 1/5/2015 16:54 PM, David Botton wrote:
> Can either of you tell me why the FSF gcc/ada doesn't serve that purpose now and at a zero price point?

Well for wone, I like an IDE with the compiler. I guess it could be
possible to use the FSF compiler with Adacore's GPS but I am neitehr a
Linux nor an Ada crack so I prefer a out of the box solution.

My main point however is this: You can not expect everybody to work for
free and Gnat is basically the only solution out there if you want Linux
and Windows Ada 2012 features. So as Eliza Dolitte's father would say:

I'm willing to pay them! I'm wanting to pay them! I'm waiting to pay them!

Just not 10,000$

I would be happy to pay something in the field of 300$ for that system
as it is now, without tech support, if it allowed me to write small
closed suorce software.

[Stefan...@uni-weimar.de]

On Mon, 5 Jan 2015, Hubert wrote:

>> Can either of you tell me why the FSF gcc/ada doesn't serve that purpose
>> now and at a zero price point?
>
> Well for wone, I like an IDE with the compiler.

You could develop your software with AdaCore's IDE and compiler, and then
compile the final executables with the free FSF compiler. I tried this
some time ago (out of curiosity, not for license reasons).

The FSF and AdaCore-GPL compilers seem to be compatible, though I tried to
avoid gnat-specifics, anyway. Bug fixes and new features for FSF may be a
bit behind. But if you avoid the most recently added feature and don't
run into some exotic bug, your program should compile and run the same.

> I would be happy to pay something in the field of 300$ for that system as it
> is now, without tech support, if it allowed me to write small closed suorce
> software.

Agreed. The existence of such a compiler (by AdaCore or someone else)
would be good for the Ada community.

Stefan

------ I love the taste of Cryptanalysis in the morning! ------
<http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

[J-P. Rosen]

Le 06/01/2015 14:26, Stefan...@uni-weimar.de a écrit :
>> I would be happy to pay something in the field of 300$ for that system
>> as it is now, without tech support, if it allowed me to write small
>> closed suorce software.
>
> Agreed. The existence of such a compiler (by AdaCore or someone else)
> would be good for the Ada community.

Unfortunately, I fear that nobody from Atego is reading this
newsgroup... (Yes, they (Alsys at that time) used to have a "personal"
version of the compiler).

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

[David Botton]

> Agreed. The existence of such a compiler (by AdaCore or someone else)
> would be good for the Ada community.

I'll have the Gnoga IDE ready before end of year and packaged dev environments with it.

While certainly someone could package gps and fsf together, I don't think that is a positive approach to things, I'm only in to win win for all. They have willingly contributed back the compiler to the FSF and it itself is a derivative work, so I have no issue building on it on using the same GPL for the community advantage, but they have every right to showcase their version and their tools like GPS and have all the benefit from doing so and I have no interest in taking that away form them.

Even more when simply installing GNAT-GPL and putting the FSF compiler on the command line before it makes it all work anyways.

David Botton

[David Botton]

> Unfortunately, I fear that nobody from Atego is reading this
> newsgroup... (Yes, they (Alsys at that time) used to have a "personal"
> version of the compiler).

It really wouldn't matter, there is no big profit in the small sales in their minds.

Most of these vendors have the same small minded thinking of only looking at direct sales instead of expanding the user base through mass marketing efforts through free or cheap compiler options.

If Ada doesn't grow in general use and to a larger general user base it is only a matter of time for the niche market to dry up or Ada displaced in those markets.

David Botton

[Björn Lundin]

On 2015-01-06 14:26, Stefan...@uni-weimar.de wrote:
> On Mon, 5 Jan 2015, Hubert wrote:
>
>>> Can either of you tell me why the FSF gcc/ada doesn't serve that
>>> purpose now and at a zero price point?
>>
>> Well for wone, I like an IDE with the compiler.
>
> You could develop your software with AdaCore's IDE and compiler, and
> then compile the final executables with the free FSF compiler. I tried
> this some time ago (out of curiosity, not for license reasons).
>
> The FSF and AdaCore-GPL compilers seem to be compatible,

Wait until you build a library with one, and try to link it
with the other. Won't work - at least I can't make it work.

If I build say AWS with Gnat-GPL, I can use the library
if I use Gnat-GPL.
However, If I change path, to use Gnat-FSF,
It won't work, complaining on different Gnat versions.

The solution is to change path first,
and build AWS with Gnat-FSF.
GPS will pick up gnat tools first in path.


--
Björn

[G.B.]

On 06.01.15 15:45, J-P. Rosen wrote:
> Le 06/01/2015 14:26, Stefan...@uni-weimar.de a écrit :
>>> I would be happy to pay something in the field of 300$ for that system
>>> as it is now, without tech support, if it allowed me to write small
>>> closed suorce software.
>>
>> Agreed. The existence of such a compiler (by AdaCore or someone else)
>> would be good for the Ada community.
>
> Unfortunately, I fear that nobody from Atego is reading this
> newsgroup... (Yes, they (Alsys at that time) used to have a "personal"
> version of the compiler).
>

Aonix used to sell a Windows compiler for $$$, up to
v7.6 or v8.2, I believe. Atego has been acquired (7/2014)
into the PTC staffing optimization enterprise(*),
together with IBM Ada (then Atego Ada (then Rational Ada)).
So, PTC has two Ada compilers, one rather complete
(Ada 2005), the other using the AdaMagic frontend, which
used to be sold by SofCheck (now AdaCore).

Maybe making available a no-support compiler would
be an addition that is tiny enough to not affect an enterprise's
accounting efforts. (Compare it to keeping track of gift acquisition
and other business expenses of the sales department.)
But, OTOH, bigger enterprises need some incentive to make
smaller products. What would that be?

So, in the end, a reasonably simple Ada compiler for the
non-enterprise Ada market would best be produced and maintained
by ____. Fill in the blanks ;-)

__
(*) http://atego.com/pressreleases/pressitem/ptc-to-acquire-atego
http://de.ptc.com/about/news-room/press-releases/2014/07/ptc-completes-acquisition-of-atego

[David Botton]

Blank = the community

FSF compiler packeged with community support Dev environment etc.

Coming soon to a comp.lang near you.

David Botton

[Björn Lundin]

On 2015-01-06 17:44, Shark8 wrote:

> On 06-Jan-15 08:09, Björn Lundin wrote:

I did reply to cla, not only to me.

>> The solution is to change path first,
>> and build AWS with Gnat-FSF.
>> GPS will pick up gnat tools first in path.
>

> That's a disgusting solution.
> Not because it works, but because there's any path-manipulation at all.

So? Welcome to the real world.
PATH is an environment _variable_
that is ok to add stuff to.

Having at least 4 version of gnat installed, its dead easy to
switch between.


> The more I see dependencies like this the more convinced I am that the
> general-idea of the APSE (and SCID, in general) is the proper way to do
> things.

bull

-- This is to say, modern IDEs *don't go far enough*, let's get
> version-control and the build system in there too so there's no
> [variable] external dependencies like the PATH.

Yes, let us remove the freedom to simple config changes,
and put stuff like that in some hidden config file,
so complex that you need a special tool to change it.
And rip out any transparency, so you can get rid of files
and put them in a database.

Lets us kill all text-editors and
only use _your_ soon-to-come-any-decade fantastic
super duper editor


--
Björn

[Björn Lundin]

> On 2015-01-06 17:44, Shark8 wrote:
>
>> On 06-Jan-15 08:09, Björn Lundin wrote:
>
> I did reply to cla, not only to me.
>
>
>>> The solution is to change path first,
>>> and build AWS with Gnat-FSF.
>>> GPS will pick up gnat tools first in path.
>>
>> That's a disgusting solution.
>> Not because it works, but because there's any path-manipulation at all.

>> -- This is to say, modern IDEs *don't go far enough*, let's get
>> version-control and the build system in there too so there's no
>> [variable] external dependencies like the PATH.
>

Which of course makes me wonder where YOU install
compilers? Somewhere in the system path?
THAT is disgusting.

Quoting wikipedia :
<http://en.wikipedia.org/wiki/PATH_%28variable%29>

second last sentence:

"The PATH variable makes it easy to run commonly used programs located
in their own folders."




--
Björn

[Ludovic Brenta]

David Botton writes:
> Demos are usually fully featured and the issue is the impression
> others will have of the availability of Ada. If the impressionion is
> Ada is available only for open source or high end niche that leaves
> most of the world in the middle. That is not Ada advocacy that is
> harmful.

80% of all software in the world is never released to anyone, much less
to the public, and is therefore not impacted by the GPL "virus". If
"most of the world" means the proprietary software sold by vendors then
"most of the world" means maybe 10% of the world, the remaining 10%
being free software.

--
Ludovic Brenta.

[Ludovic Brenta]

Hubert writes on comp.lang.ada:

> On 1/5/2015 16:54 PM, David Botton wrote:
>> Can either of you tell me why the FSF gcc/ada doesn't serve that
>> purpose now and at a zero price point?
>
> Well for wone, I like an IDE with the compiler. I guess it could be
> possible to use the FSF compiler with Adacore's GPS but I am neitehr a
> Linux nor an Ada crack so I prefer a out of the box solution.

aptitude install gnat gnat-gps

and you get both the FSF compiler (with runtime library exception) and
GPS IDE.

--
Ludovic Brenta.

[David Botton]

> and is therefore not impacted by the GPL "virus"

I am looking to confirm that in fact linking and using software with incompatible licenses is legal, but if that is true then perhaps more are "covered" for their needs as you say than I would think. I don't believe that statement 100% factual in most corporate environments.

Either way my issue is about the impression and the reality of how people look a language where the "community" compiler is virused. I for one would never ever have written a single line of Ada code had it been this way when I started and almost all my code was written with the then restriction free environment in mind. I invested my time and skills with the idea everyone wins, me the community, AdaCore, customers, etc. (note, post creating it I was paid for one project by Act to support it for their customers, again win win)

We all know of many others that either walked away or won't consider Ada for their projects because of _their_ impressions, reality of FSF gnat or not. I came back only because of work like yours on Debian and in particular Simon on Mac, and I am a GPL software author. My belief this time around, my personal challenge, is that I can put together a package of tools that no corporation can uses licenses as weapons against. (I make my living as a physician now and supplement with code so I may not _need_ this anymore, but I complete what I start out to do, and that is how I got to Ada in the first place).

You go trying to sell a company on the idea you will be writing their software but it will be under the GPL... good laugh and no deal. (there are exceptions of course.. but few and far between)

Ada doesn't need barriers to entry like this. It is an embarrassment to all that have created open source code in Ada over the years. Time to correct it and the _impression_ Ada makes on new developers.

Someone should try Ada and say, wow this is cool! I'll try this on my next project or for my next customer.

It shouldn't be, wow this is cool, uh oh, I can't this, I can't that, I can't this, oh my oh my that much to use for my sisters cake decorating business... oh common this is ridiculous that I should even need to justify how important it is to start pushing a non-viral compiler option to all newbies and keep them away from GPL virused versions unless they are potential customers for AdaCore who I would even encourage to go get it.

For _students_, newbies, hobbyists, and authors of non-safety critical systems a solid dev environment with out "restrictions" is a must. It is a lose lose for everyone even AdaCore (even if they can't see beyond immediate direct dollar sales and are too blind to see it is their lack of creative innovation and R&D for new ways to keep customers that is the real issue not customers feeling they don't need AdaCore if they can use the "free" compilers).

So let it be, if they think that every Ada advocate is some "leach" using "their tech" and their needs irrelevant and the community not worth their time participating in actively, time for us "leaches" to start thinking... Ada advocates need something to advocate to the 99% of the software development world that is not a potential customer of AdaCore or toss out Ada. I'm giving it one more try, we will see where it goes, I gave my self a 2 year trial period (I'm sure that makes some happy ;) to succeed or fail, I'm now 5 months in to that. Gnoga has been a nice start, now an IDE, some tools and beautiful easy to use packages. We will see.

David Botton

[Randy Brukardt]

"David Botton" <da...@botton.com> wrote in message
news:72ede803-e2e9-4e21...@googlegroups.com...

>
>> Unfortunately, I fear that nobody from Atego is reading this
>> newsgroup... (Yes, they (Alsys at that time) used to have a "personal"
>> version of the compiler).
>
> It really wouldn't matter, there is no big profit in the small sales in
> their minds.
>
> Most of these vendors have the same small minded thinking of only looking
> at direct sales
>instead of expanding the user base through mass marketing efforts through
>free or cheap
>compiler options.

That's not really fair. Both Atego (with ObjectAda) and RRS (with Janus/Ada)
tried to market low-cost compilers for the mass market, but neither made
money.

Our experience was that the more money and effort that we put into it, the
more money that we lost (sales were about the same either way).

I've heard that the personal version of ObjectAda had essentially the same
results -- Atego put a lot of money into it and didn't even break-even. (And
it doesn't make sense to lose money on every unit one sells.)

There may be a model out there which works for a low-end Ada compiler, but I
would expect that it would require low effort in order to be profitable.
Which makes it problematical, as some sort of support is required (at a
minimum, packaging and fixing of packaging, which can take an amazing amount
of time).

Randy.

[Ludovic Brenta]

David Botton <da...@botton.com> writes:
>> and is therefore not impacted by the GPL "virus"
>
> I am looking to confirm that in fact linking and using software with
> incompatible licenses is legal, but if that is true then perhaps more
> are "covered" for their needs as you say than I would think. I don't
> believe that statement 100% factual in most corporate environments.

Then read up about copyright law. Copyright says nothing about
"linking" or "using". The author of a copyrighted work has the right to
control *copy* and *distribution* of their work, nothing more and
nothing less.

--
Ludovic Brenta.

[Shark8]

On 06-Jan-15 10:37, Björn Lundin wrote:
>
> On 2015-01-06 17:44, Shark8 wrote:
>
>> On 06-Jan-15 08:09, Björn Lundin wrote:
>
> I did reply to cla, not only to me.
>
>
>>> The solution is to change path first,
>>> and build AWS with Gnat-FSF.
>>> GPS will pick up gnat tools first in path.
>>
>> That's a disgusting solution.
>> Not because it works, but because there's any path-manipulation at all.
>
> So? Welcome to the real world.
> PATH is an environment _variable_
> that is ok to add stuff to.

I'm not saying it's not ok to add stuff to it; I'm saying making your
system dependent upon it is, in a word, stupid.

> Having at least 4 version of gnat installed, its dead easy to
> switch between.
>
>
>> The more I see dependencies like this the more convinced I am that the
>> general-idea of the APSE (and SCID, in general) is the proper way to do
>> things.
>
> bull

Really?
What has file-centric and "distributed among tools" setups brought about
(a) in terms of configuration complexity? (b) In terms of organization
complexity/dependence? And (c) in terms of consistency complexity?

(A) How many different "small tools" have their own configuration which
directly impacts another tool and that other tool doesn't know about the
first?
(B) Consider how many libraries need to be installed in a certain place
to get them to work right/easily.
(C) Have you /EVER/ linked to the wrong object because it became out of
date?

> -- This is to say, modern IDEs *don't go far enough*, let's get
>> version-control and the build system in there too so there's no
>> [variable] external dependencies like the PATH.
>
> Yes, let us remove the freedom to simple config changes,
> and put stuff like that in some hidden config file,
> so complex that you need a special tool to change it.
> And rip out any transparency, so you can get rid of files
> and put them in a database.

At what cost?
If things are in a database you can get consistency-checking essentially
for free! You can design the system so that you *NEVER* compiler
"against the wrong object". You can make it so that you *NEVER* pull an
'oopsie' with a simple textual search-and-replace rename.

Moreover, if stored in a database things like version-control can be
made more useful by storing only the semantically meaningful changes.
Things like "formatting style" become absolutely meaningless because,
guess what, the textual-representation gets reconstructed and
redisplayed as-needed... and that can be fully customizable to the
particular user w/o impacting anyone else.

Seriously, that "the industry" remains fixated on _text_ as the de facto
medium for storing/maintaining/manipulating programs is disgusting! --
It's like a firearm manufacturer that refuses to use firearms in favor
of bows because "it's simpler".

Hell, if *"because it's simpler"* is a valid reason to embrace
something, might I suggest you look into PHP, after all its
implementation (and usage) is "much simpler" than Ada or most any
compiled language.

> Lets us kill all text-editors and
> only use _your_ soon-to-come-any-decade fantastic
> super duper editor

Who said anything about killing text editors?
Of course it'd need a way to display/manipulate the program, and of
course it'd need to be able to import/export plain-text.

But the fact still remains: the text-based/file-based model is
inherently worse because it pushes automatable and verifiable checking
directly into the user's lap.

[David Botton]

> That's not really fair. Both Atego (with ObjectAda) and RRS (with Janus/Ada)
> tried to market low-cost compilers for the mass market, but neither made
> money.

You missed my point, which was fair. There is _no_ low-cost compiler market. That bottomed out already before OA and RRS started to market their products to a non-existing market. That market is not going to materialize again ever either.

In fact there is no _compiler_ market at all, there is a slightly synthetic market still in the Ada world, but that is just about gone and why shareware license games is a pathetic answer to trying to make believe it is still there (btw it is just about gone for every language I know of).

There is a small enterprise compiler support market for Ada and likely that will remain for some time but not likely to grow much.

There are huge markets and lots of money to be made in many areas, but all things change and the old markets and ways of doing business were already dying as Ada 95 was emerging.

> Our experience was that the more money and effort that we put into it, the
> more money that we lost (sales were about the same either way).

Of course it did. My point is that vendors that want enterprise business need to expand at any cost including free the other markets for a trickle up affect.

> I've heard that the personal version of ObjectAda had essentially the same
> results -- Atego put a lot of money into it and didn't even break-even. (And it doesn't make sense to lose money on every unit one sells.)

Sure it does if you see it as marketing dollars not sales figures. Also their personal price point was off, so not so personal.

AdaCore understands this a bit, and so their GAP program, etc. Not enough, but at least shows they are not completely inept at business, just not great at it.

> There may be a model out there which works for a low-end Ada compiler

That market died. Although possible to make a few dollars for a mom and pop in training and high level support.

> Which makes it problematical, as some sort of support is required (at a
> minimum, packaging and fixing of packaging, which can take an amazing amount
> of time).

A long time ago, people realized that open source changed where the dollars are in software.

The vendors that can't see beyond compiler sales haven't survived (per se) and those in large support contracts are floating, but not swimming if that is their only real product.

David Botton

[Björn Lundin]

On 2015-01-06 21:52, Shark8 wrote:

>> So? Welcome to the real world.
>> PATH is an environment _variable_
>> that is ok to add stuff to.
>
> I'm not saying it's not ok to add stuff to it; I'm saying making your
> system dependent upon it is, in a word, stupid.

becasue ?

>
> Really?
> What has file-centric and "distributed among tools" setups brought about
> (a) in terms of configuration complexity?

I do not know
And I do not see the relevance

>(b) In terms of organization complexity/dependence?

I do not know
And I do not see the relevance

And (c) in terms of consistency complexity?

I do not know
And I do not see the relevance

> (A) How many different "small tools" have their own configuration which
> directly impacts another tool and that other tool doesn't know about the
> first?

I do not know
And I do not see the relevance here either.

> (B) Consider how many libraries need to be installed in a certain place
> to get them to work right/easily.
> (C) Have you /EVER/ linked to the wrong object because it became out of
> date?

No. Unheard of. Did not think it was possible.

>
> At what cost?
> If things are in a database you can get consistency-checking essentially
> for free! You can design the system so that you *NEVER* compiler
> "against the wrong object".

How do you do for accomplish linking out-of-date objects ?
You seem really hung up on this, so I interpret it as it happens often.
Does it?

>You can make it so that you *NEVER* pull an
> 'oopsie' with a simple textual search-and-replace rename.

So why would a db-based ide be better on this thatn a file based?

> Moreover, if stored in a database things like version-control can be
> made more useful by storing only the semantically meaningful changes.
> Things like "formatting style" become absolutely meaningless because,
> guess what, the textual-representation gets reconstructed and
> redisplayed as-needed... and that can be fully customizable to the
> particular user w/o impacting anyone else.

And that would make you be the most impopular man,
if our company set the standard for that.
People get _really_ upset if you tamper with a 15-year old comment.
Or changeing case on variables.
Automatic re-writes is a nono. (a bit conservative. I know)

> Seriously, that "the industry" remains fixated on _text_ as the de facto
> medium for storing/maintaining/manipulating programs is disgusting! --

Very much seems disgusting to you...

> It's like a firearm manufacturer that refuses to use firearms in favor
> of bows because "it's simpler".

It would be simpler to deny weapons at all ...

>
> Hell, if *"because it's simpler"* is a valid reason to embrace
> something, might I suggest you look into PHP, after all its
> implementation (and usage) is "much simpler" than Ada or most any
> compiled language.

No. I like thing s to be simple AND safe. PHP does not match safe.
I also like the KISS principle. Less errors because of
overly complex configuration. I like it simple so I do not need to
explain stuff for my colleagues. I compile stuff with -O0 and -g
to get good stack-traces when needed. To catch errors, and understand
them as soon as possible, so a fix can be provided.

Yes, i like simple stuff, because they break more seldom.
But don't confuse simple with bad.


And I also like to auto-generate objects from xml-files that wraps
access to database-tables. Output is Ada-files.
Print to standard_output and redirect to file.
Simple. Works. Not needed to fiddle with API to access your IDE-DB
or whatever you can provide. If you provide other input means than your IDE.

>> Lets us kill all text-editors and
>> only use _your_ soon-to-come-any-decade fantastic
>> super duper editor
>
> Who said anything about killing text editors?
> Of course it'd need a way to display/manipulate the program, and of
> course it'd need to be able to import/export plain-text.

ok - rephrase to 'lets kill all editors that saves to file'

>
> But the fact still remains: the text-based/file-based model is
> inherently worse because it pushes automatable and verifiable checking
> directly into the user's lap.
>

Things your coming IDE can catch by saving to DB, it could also catch
when save to file.
Consider the file system your db.


--
Björn

[Shark8]

On 06-Jan-15 14:15, Björn Lundin wrote:
> Consider the file system your db.

But *this* is the problem -- a DB is more than just a storage unit, it
can enforce consistency!

> Things your coming IDE can catch by saving to DB, it could also catch
> when save to file.

And things the file-system *can't* catch could be caught by a db.

Ex:
Example.Parent.Child.adb is in your file-system (along with its
ancestors), it exists in your project and is used therein.

Now "del Example.Parent.ad?" removes the ancestor "parent", is your
project still valid?

No, because it still contains [and relies upon] "Example.Parent.Child"
which has had its own dependencies removed.

> How do you do for accomplish linking out-of-date objects ?
> You seem really hung up on this, so I interpret it as it happens often.
> Does it?

I've only had it happen a couple times.
That it can happen at all, when it is preventable, is the issue.

>> Moreover, if stored in a database things like version-control can be
>> made more useful by storing only the semantically meaningful changes.
>> Things like "formatting style" become absolutely meaningless because,
>> guess what, the textual-representation gets reconstructed and
>> redisplayed as-needed... and that can be fully customizable to the
>> particular user w/o impacting anyone else.
>
> And that would make you be the most impopular man,
> if our company set the standard for that.
> People get _really_ upset if you tamper with a 15-year old comment.
> Or changeing case on variables.
> Automatic re-writes is a nono. (a bit conservative. I know)

*sigh* -- You completely miss the point. You're storing it [the program]
not as text, but as a meaningful structure (think AST w/ extra info
[like, say, static-analysis]). When you re-constitute the "program text"
for editing the display-unit/editor can [easily] put it together in the
"company set standard" (or the user's preferred standard)... IOW, the
textual formatting simply doesn't matter anymore.

To illustrate, consider the following:
Type X is (
Apple,
Orange,
Grape
);
For X'Size use 8;
Is this semantically different from the following:
Type X is (Apple,Orange,Grape) with Size => 8;

If there is no semantic difference, then does it matter which text is
displayed, other than personal preference?

I don't see why it should; why do you?

[Hubert]

I should maybe say that I am one of these people who are looking into
Ada. The reason is that I realize that the language has much more to
offer than C++ and it seems programs are more stable due to the lack of
pointer juggling.
However, I am reluctant to commit more than some spare time to it and
writing more than some stand alone tools because from my point it has an
uncertain future.
Should Adacore ever break down then there would be no more development
that's worth mentioning. Of course there is still a big userbase in
Aviation and Space industry but I read that there are movements away
from Ada so that is not encouraging either.

And I guess many people in my situation feel the same. They look at Ada
and say, well it looks good in theory but what are the long term chances
for it. Realistically, as a programmer, you have to focus on one
language. It is hard enough for me to stay ontop of C++ and I can't say
that I know more than 75% of the language, even though I make a living
working with it.
Today's languages are horribly complex. Which is a reason that I decided
for my Ada experiment that I would stay away from OOP because when I
read questions about Ada that just make my head smoke and think: how can
any human being understand that problem really, then it is always about
OOP. OOP is an abomination in my mind, but that's an entirely different
subject.

I am afraid, unless there is an Ada solution that would make small
companies feel secure when they commit a significant amount of time and
money, they will never do that. Simply because it's an either or
situation with Adacore.

And yes, you can use the FSF version, but like I said earlier, if
everybody did that, how would Adacore make money and continue to support
the compiler? If I use a compiler, I want to make sure the company I buy
it from will be there in 10 years and in my mind I do that by paying
them money.

Unless more people try out Ada, there will be no growth in the userbase.
But it's an emotional thing as well, like I said. I want to feel secure
about the company who's tools I use.

I really wish Adacore would offer a license for small businesses that
was more affordable. I think that would lure more people in than a
completely free version.

[Georg Bauhaus]

On 06.01.15 22:15, Björn Lundin wrote:
>> (A) How many different "small tools" have their own configuration which
>> >directly impacts another tool and that other tool doesn't know about the
>> >first?
> I do not know
> And I do not see the relevance here either.
>

Assume there is a standard way of describing the graph
of dependence of a software product to be.

Then, no matter which compiler you choose, no matter which
operating system you use for development, the standards based
development environment is going to do the right
thing when selecting units and dependencies.

Because the compiler performs the selections in terms of the
standard description.

There is no standard description of the net of dependence
for Ada programs. Whether that standard would rely on text or
on a database or whatever for its implementation is a secondary
concern, I think.

I'd expect vendors to tell tales about APSE failure, about flexibility,
about operating systems, about licensing, about the HALTing problem etc.
So each finds a reason to provide their own configuration language…

What's the situation with other languages?

Eiffel has a configuration language as part of the
language definition. Other languages have developed highly
specialized solutions. They are complex to configure, although fairly
easy to "run" after some initial training. In fact, in the labor market,
job descriptions will typically mention these tools as a qualification.

The qualifications such as knowing Maven, knowing bower,
knowing VS 9, knowing DevOps topics, knowing Eclipse (not Netbeans),
known the umpteenth framework, typically is of no lasting
value for most programmers, because "The Market" makes
most of these specializations in software configuration worthless.
They are replaced every now and then with something different.
Maintenance jobs are fewer.

Learning programming languages is relatively easy in comparison to
memorizing yet another configuration language … a "necessary" evil,
like also memorizing yet another markup language is … another "necessary"
evil.

Industry does not value standards for configuration and frameworks,
since vendors, consultants, and publishers have successfully done a lot
to lure industry into standards avoidance there.

[Pascal Obry]

Le mardi 06 janvier 2015 à 17:59 -0800, Hubert a écrit :
> I should maybe say that I am one of these people who are looking into
> Ada. The reason is that I realize that the language has much more to
> offer than C++ and it seems programs are more stable due to the lack of
> pointer juggling.
> However, I am reluctant to commit more than some spare time to it and
> writing more than some stand alone tools because from my point it has an
> uncertain future.

This is just plain wrong. How can Ada have an uncertain future where all
the most challenged projects in the world are using it more and more and
there is two Open Source compilers, one GPL from AdaCore and non GPL
from FSF integrated into the GCC project.

--
Pascal Obry / Magny Les Hameaux (78)

The best way to travel is by means of imagination

http://v2p.fr.eu.org
http://www.obry.net

gpg --keyserver keys.gnupg.net --recv-key F949BD3B

[Mark Carroll]

Pascal Obry <pas...@obry.net> writes:

> Le mardi 06 janvier 2015 à 17:59 -0800, Hubert a écrit :
>> I should maybe say that I am one of these people who are looking into
>> Ada. The reason is that I realize that the language has much more to
>> offer than C++ and it seems programs are more stable due to the lack of
>> pointer juggling.
>> However, I am reluctant to commit more than some spare time to it and
>> writing more than some stand alone tools because from my point it has an
>> uncertain future.
>
> This is just plain wrong. How can Ada have an uncertain future where all
> the most challenged projects in the world are using it more and more and
> there is two Open Source compilers, one GPL from AdaCore and non GPL
> from FSF integrated into the GCC project.

I suppose it depends to what extent AdaCore is a single point of
failure. Does the FSF version get much active development that isn't
hand-me-downs of AdaCore's paid work? I don't mind relying on a free
compiler if there's an associated development community already working
on it directly, as with other languages like Haskell where commercial
companies still have the option of privately contracting with
consultants who otherwise work on the free compiler anyway.

-- Mark

[Pascal Obry]

Le mercredi 07 janvier 2015 à 10:17 +0000, Mark Carroll a écrit :
> I suppose it depends to what extent AdaCore is a single point of
> failure. Does the FSF version get much active development that isn't
> hand-me-downs of AdaCore's paid work? I don't mind relying on a free
> compiler

It's not free it is Open Source. This is for me far better than just
free as in freeware for example where from a day to another the product
can disappear because the company as decided so.

Of course nothing is there forever. But to me an Open Source piece of
software has far more chance to live longer.

> if there's an associated development community already working
> on it directly,

I bet that if a strong needs if felt the community will be there to work
on this.

[Björn Lundin]

On 2015-01-06 22:46, Shark8 wrote:
> On 06-Jan-15 14:15, Björn Lundin wrote:
>> Consider the file system your db.
>
> But *this* is the problem -- a DB is more than just a storage unit, it
> can enforce consistency!
>
>> Things your coming IDE can catch by saving to DB, it could also catch
>> when save to file.
>
> And things the file-system *can't* catch could be caught by a db.
>
> Ex:
> Example.Parent.Child.adb is in your file-system (along with its
> ancestors), it exists in your project and is used therein.
>
> Now "del Example.Parent.ad?" removes the ancestor "parent", is your
> project still valid?
>
> No, because it still contains [and relies upon] "Example.Parent.Child"
> which has had its own dependencies removed.

So ? How would a db solution stop that?

"delete from sources where name like 'Example.Parent%'"
would have the same effect.

however, in a filesystem (with say svn) I could

svn stat - to see that Example.Parent.ad? is missing
svn revert Example.Parent.ad?

and I would have restored it.

>
>> How do you do for accomplish linking out-of-date objects ?
>> You seem really hung up on this, so I interpret it as it happens often.
>> Does it?
>
> I've only had it happen a couple times.
> That it can happen at all, when it is preventable, is the issue.

and exactly _how_ is this more preventable with a db solution?

>
> *sigh* -- You completely miss the point. You're storing it [the program]
> not as text, but as a meaningful structure (think AST w/ extra info
> [like, say, static-analysis]).

I do get your point, but I do not find it so fantastic a you do.

> IOW, the
> textual formatting simply doesn't matter anymore.

For the source code - yes. for the user - no.
Modification date of a file tells me stuff.
like when was it last fiddled with. In an EASY way.

>
> To illustrate, consider the following:
> Type X is (
> Apple,
> Orange,
> Grape
> );
> For X'Size use 8;
> Is this semantically different from the following:
> Type X is (Apple,Orange,Grape) with Size => 8;
>
> If there is no semantic difference, then does it matter which text is
> displayed, other than personal preference?

no, but YOU don't get the point.
Files are more that holder of text. They carry some
meta-info. Sure the kind and amount could be better.


And I still do not see why changing PATH to point to different
compiler installations are considered DISGUSTING


--
--
Björn

[sbelm...@gmail.com]

On Wednesday, January 7, 2015 6:00:48 AM UTC-5, björn lundin wrote:
>
> And I still do not see why changing PATH to point to different
> compiler installations are considered DISGUSTING

Because you can't version control an environment variable. A major part of change management is to ensure that the same product is built the same way, with the same compiler, each and every time, e.g. if your development plan says you are going to use GNAT-FSF, then you should be unable (or at least have it be extraordinary hard) to compile it with GNAT-GPL (or any other compiler). With the PATH option, Joe might get a different executable than Bob. Or even more dire, if Steve the admin installs a new compiler version or changes the directory structure, suddenly Joe and Bob silently start using a different compiler and nobody notices until it's too late. Now add in that Joe and Bob might each be working on multiple projects that require different versions of different compilers, and you'll never contain the mess. Solutions like gprbuild (i.e. the .cgpr file, that you can check into the tree) offer much more consistency.

-sb

[David Botton]

> Of course nothing is there forever. But to me an Open Source piece of
> software has far more chance to live longer.

I agree 100% end of the day a 1 company approach is irrelevant when the product is available as open source. Many companies "invest" in AdaCore for new development work to the compiler or have maintenance contracts because is is open source and their support and maintenance dollars are protected long term by it being libre software.

> I bet that if a strong needs if felt the community will be there to work
> on this.

I also agree, the quality of AdaCore's work and frequency of it has generally not made it a "need". However there is already much work in the community on the compiler, but most has just been on creating FSF gcc/ada executables since that has been where any "need" has lied.

David Botton

[Björn Lundin]

On 2015-01-07 13:23, sbelm...@gmail.com wrote:
> On Wednesday, January 7, 2015 6:00:48 AM UTC-5, björn lundin wrote:
>>
>> And I still do not see why changing PATH to point to different
>> compiler installations are considered DISGUSTING
>
> Because you can't version control an environment variable.

You must be joking ?
I maintain a somewhat largish system.
The Standard R&D version is checked out as a working copy.
So is 12 other projects tailor made for different customers based on
different version of the standard mentioned above.
Within each system, a file exists that sets different environ variables
PATH included. Each system points to the compiler the customers
has at site.

to start work, pick your project from a menu (generated from this file)
and all vital environ variables including PATH are set.

And that file, as the rest of the system is version controlled.

Don't project your ignorance on everybody else.

>A major part of change management

Do you really think that Change Management was something
the OP had in mind?
He tried to get another gnat to works with gps. That is it.

>is to ensure that the same product is built the same way,
>with the same compiler, each and every time, e.g. if your development plan
>says you are going to use GNAT-FSF, then you should be unable
>(or at least have it be extraordinary hard) to compile it with GNAT-GPL
>(or any other compiler). With the PATH option, Joe might get a
different executable than Bob.
>Or even more dire, if Steve the admin installs a new compiler version or
>changes the directory structure, suddenly Joe and Bob silently

Not very silently. each compiler will recompile the stuff it did not
compile itself. It will also state its version with EACH re-compiled
file. If you do not notice that, well then it is strange.

>start using a
>different compiler and nobody notices until it's too late.

get real.

>Now add in that Joe and Bob might each be working on multiple projects
>that require different versions of different compilers,
>and you'll never contain the mess.

Yes you will. See above

And we are not just Sandy, Bob and Joe.

We are 50+ people in four different countries using this.
Commercially. Successfully.

> Solutions like gprbuild (i.e. the .cgpr file, that you can check into the tree) offer much more consistency.

Yeah, I forget .cgpr is the ONLY file type that can be version handled...

--
Björn

[Thomas Løcke]

On 01/07/2015 01:23 PM, sbelm...@gmail.com wrote:
> Because you can't version control an environment variable.

You can easily version control environment variables, if you just keep
them local to your makefile / commands.

You don't have to change your PATH systemwide to do a simple build.

PATH=/path/to/special/gnat gnatmake stuff

Put that in your makefile, and you now have a version controlled PATH.

If you're worried about compiler versions, simply check for that in the
makefile and break out if there's a version mismatch. This is exactly
what proper build scripts are for. If Bob screws up then he will be
notified and it's then up to him to fix his own system. Create a
makefile.conf and have something like GNATMAKE_VERSION=4.8.2 and check
for that.

And just to be clear: I'm not advocating against gprbuild or gpr files,
I'm merely pointing out that a well-written makefile would solve Joe
and Bob's PATH/compiler woes. :o)

--
Thomas Løcke

[sbelm...@gmail.com]

All that's true, but in those cases you are no longer just "relying on the PATH variable" anymore; you are relying on a big, consistent, safe and verified build system that performs all the requisite checks to ensure the PATH variable is correct. At that point, you've essentially just engineered yourself a home-brew gprbuild tool, which is as effective as any other. The problem is when people merely expect to type "gnatmake -P project.gpr" and expect consistent results based on whatever happens to be in the PATH at the time.

-sb

[Björn Lundin]

On 2015-01-07 14:46, sbelm...@gmail.com wrote:
>
> All that's true, but in those cases you are no longer just "relying on the PATH variable" anymore;
> you are relying on a big, consistent, safe and verified build system that
>performs all the requisite checks to ensure the PATH variable is correct.
>At that point, you've essentially just engineered yourself a home-brew gprbuild tool,

Yes, this has a 10 year+ history - before gprbuild.

>which is as effective as any other. The problem is when people merely expect to type
>"gnatmake -P project.gpr" and expect consistent results based on whatever
> happens to be in the PATH at the time.
>

Still, I do not see why the change of PATH is DISGUSTING.
Especially not for the case of the OP.

And as Thomas Löcke pointed out, it does not
have to be a 'big, consistent, safe and verified build system'
It is enough that set the path locally in a make file.

I do not see that as DISGUSTING either.


Enough time wasted for me here.

--
Björn

[Dirk Heinrichs]

Pascal Obry wrote:

> It's not free it is Open Source.

That depends on the definition of "free". For the FSF, free always means
free as in "freedom" or in "free speech", NOT as in "free beer" (free of
charge).

For software to be free software, in the FSF sense, it MUST also be Open
Source, while the opposite might not always be true.

See also: http://www.gnu.org/philosophy/free-sw.en.html

> This is for me far better than just
> free as in freeware for example where from a day to another the product
> can disappear because the company as decided so.

ACK. Seen to much good pieces of software disappear just because some
company was un(able|willing) to continue its development.

> Of course nothing is there forever. But to me an Open Source piece of
> software has far more chance to live longer.

ACK (with s/Open Source/Free Software/).

Bye...

Dirk
--
Dirk Heinrichs <dirk.he...@altum.de>
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key CB614542 | Jabber: dirk.he...@altum.de
Tox: he...@toxme.se
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

[Shark8]

On 07-Jan-15 04:00, Björn Lundin wrote:
> On 2015-01-06 22:46, Shark8 wrote:
>>
>> No, because it still contains [and relies upon] "Example.Parent.Child"
>> which has had its own dependencies removed.
>
> So ? How would a db solution stop that?
>
> "delete from sources where name like 'Example.Parent%'"
> would have the same effect.

Why would you have the fully-qualified name stored as text?
It makes far more sense to break the name into an actual structure
itself, in order to show its "lineage"; and once you do that your
example simply doesn't work.

Again, you're showing that you're thinking of everything in terms of
text, not in terms of meaningful structure.

> however, in a filesystem (with say svn) I could
>
> svn stat - to see that Example.Parent.ad? is missing
> svn revert Example.Parent.ad?
>
> and I would have restored it.

Showing that you could easily recover from accidentally entering an
inconsistent state is *not* the same as preventing the state-change to
inconsistency in the first place. -- Here is an example of early
development using databases as a form of both version-control and
project-management:
https://drive.google.com/file/d/0BwQVNNshW39cTXVOdWxQaVJ5WjA/edit

>>> How do you do for accomplish linking out-of-date objects ?
>>> You seem really hung up on this, so I interpret it as it happens often.
>>> Does it?
>>
>> I've only had it happen a couple times.
>> That it can happen at all, when it is preventable, is the issue.
>
> and exactly _how_ is this more preventable with a db solution?

Because with a DB-system you can guarantee that the "system" is not
inconsistent or out-of date; and you can associate generated objects
with exactly the state that generates them.

>> *sigh* -- You completely miss the point. You're storing it [the program]
>> not as text, but as a meaningful structure (think AST w/ extra info
>> [like, say, static-analysis]).
>
> I do get your point, but I do not find it so fantastic a you do.

Your example of treating the name of the compilation unit as if it were
only text proves a counter-example to your claim of understanding my point.

>> IOW, the
>> textual formatting simply doesn't matter anymore.
>
> For the source code - yes. for the user - no.
> Modification date of a file tells me stuff.
> like when was it last fiddled with. In an EASY way.

*shrug* -- I'm not saying that every conceivable operation could [or
even should] be as easy in a DB-based system. I see no reason, though,
why such "last modified on"/"last modified by" meta-data could not be
stored in a database... and, indeed, several do have a system like this,
generating an audit-trail automatically.

>> To illustrate, consider the following:
>> Type X is (
>> Apple,
>> Orange,
>> Grape
>> );
>> For X'Size use 8;
>> Is this semantically different from the following:
>> Type X is (Apple,Orange,Grape) with Size => 8;
>>
>> If there is no semantic difference, then does it matter which text is
>> displayed, other than personal preference?
>
> no, but YOU don't get the point.
> Files are more that holder of text. They carry some
> meta-info. Sure the kind and amount could be better.

And more, better meta-info can be held in a database-system.

> And I still do not see why changing PATH to point to different
> compiler installations are considered DISGUSTING

Because it is changing a fundamental behavior in a completely
invisible-to-the-build-system manner; as someone pointed out you can use
make-files to set the path but this is a work-around -- instead of
"making it a variable of the function" it's "depending on a global
variable" -- instead of making the build-system analogous to a "pure
unit", it depends on state.

[Björn Lundin]

Ok, I need to reply to this rubbish

On 2015-01-07 17:32, Shark8 wrote:
> On 07-Jan-15 04:00, Björn Lundin wrote:
>> On 2015-01-06 22:46, Shark8 wrote:
>>>
>>> No, because it still contains [and relies upon] "Example.Parent.Child"
>>> which has had its own dependencies removed.
>>
>> So ? How would a db solution stop that?
>>
>> "delete from sources where name like 'Example.Parent%'"
>> would have the same effect.
>
> Why would you have the fully-qualified name stored as text?
> It makes far more sense to break the name into an actual structure
> itself, in order to show its "lineage"; and once you do that your
> example simply doesn't work.

It does not matter HOW you represent it.
A db can be manipulated, get corrupt, just as a file system.

> Again, you're showing that you're thinking of everything in terms of
> text, not in terms of meaningful structure.

No, but since I don't know your model, I
visualized with something simple.

>> however, in a filesystem (with say svn) I could
>>
>> svn stat - to see that Example.Parent.ad? is missing
>> svn revert Example.Parent.ad?
>>
>> and I would have restored it.
>
> Showing that you could easily recover from accidentally entering an
> inconsistent state is *not* the same as preventing the state-change to
> inconsistency in the first place. -- Here is an example of early
> development using databases as a form of both version-control and
> project-management:
> https://drive.google.com/file/d/0BwQVNNshW39cTXVOdWxQaVJ5WjA/edit

I see nothing in there to _prove_ that a code-base cannot be
inconsistent in a db - regardless of the db model. That is your claim.

>>>> How do you do for accomplish linking out-of-date objects ?
>>>> You seem really hung up on this, so I interpret it as it happens often.
>>>> Does it?
>>> I've only had it happen a couple times.
>>> That it can happen at all, when it is preventable, is the issue.

I guess this did not happen with Gnat. See below

>> and exactly _how_ is this more preventable with a db solution?
> Because with a DB-system you can guarantee that the "system" is not
> inconsistent or out-of date; and you can associate generated objects
> with exactly the state that generates them.

Gnat calls that state ali-files...

<http://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn_7.html#SEC84>
That is gnat user guide , chapter 6.5
§4

"The ability of GNAT to compile in any order is critical in allowing an
order of compilation to be chosen that guarantees that gnatmake will
recompute a correct set of new dependencies if necessary. "

Seems to me that ACT already can guarantee this with files.
Yes, they use the word guarantee.

And using gnat since 2002 at work,
I've never even heard of this happening with gnat.

However, I do recall something with ObjectAda 7.2
If changing source files belonging both to a certain
ada-lib AND its parent lib, the source belonging to the parent lib was
not recompiled.
However, this was 10+ years ago, and I only remember i vaguely,
so it might have been something completely different.

>> And I still do not see why changing PATH to point to different
>> compiler installations are considered DISGUSTING
>
> Because it is changing a fundamental behavior in a completely
> invisible-to-the-build-system manner;

Yes, fully transparent.
Easy to deploy, easy to reconfigure, easy to understand.
All three reasons are good for maintenance.

> as someone pointed out you can use
> make-files to set the path but this is a work-around -- instead of
> "making it a variable of the function" it's "depending on a global
> variable" -- instead of making the build-system analogous to a "pure
> unit", it depends on state.

So ? The state is controlled.
You are building vapor-ware.

--
Björn

[Björn Lundin]

On 2015-01-07 17:32, Shark8 wrote:
>>

>> and exactly _how_ is this more preventable with a db solution?
>
> Because with a DB-system you can guarantee that the "system" is not
> inconsistent or out-of date; and you can associate generated objects
> with exactly the state that generates them.
>

see also gnatbind
<http://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn_5.html#SEC63>


"
The gnatbind program performs four separate functions:

Checks that a program is consistent, in accordance with the rules in
Chapter 10 of the Ada Reference Manual. In particular, error messages
are generated if a program uses inconsistent versions of a given unit.

"

--
Björn

[Björn Lundin]

reading further, we get to the section 4.1
<http://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn_5.html#SEC64>

that states

<quote>
The effect of this consistency checking, which includes source files, is
that the binder ensures that the program is consistent with the latest
version of the source files that can be located at bind time. Editing a
source file without compiling files that depend on the source file cause
error messages to be generated by the binder.

For example, suppose you have a main program `hello.adb' and a package
P, from file `p.ads' and you perform the following steps:

Enter gcc -c hello.adb to compile the main program.

Enter gcc -c p.ads to compile package P.

Edit file `p.ads'.

Enter gnatbind hello.

At this point, the file `p.ali' contains an out-of-date time stamp
because the file `p.ads' has been edited. The attempt at binding fails,
and the binder generates the following error messages:



error: "hello.adb" must be recompiled ("p.ads" has been modified)
error: "p.ads" has been modified and must be recompiled

Now both files must be recompiled as indicated, and then the bind can
succeed, generating a main program.
</quote>


As I said, never heard of linking the wrong object file with gnat

--
Björn

[Shark8]

>> Why would you have the fully-qualified name stored as text?
>> It makes far more sense to break the name into an actual structure
>> itself, in order to show its "lineage"; and once you do that your
>> example simply doesn't work.
>
> It does not matter HOW you represent it.
> A db can be manipulated, get corrupt, just as a file system.

I never said that a database couldn't "go bad" -- but how easy is it to
back up a single [proper] DB? Unless it's got its own FS, it's just as
easy as SVN on the source directory, or zipping the dir-structure, or
whatever your backup of text-files is.

>> Again, you're showing that you're thinking of everything in terms of
>> text, not in terms of meaningful structure.
>
> No, but since I don't know your model, I
> visualized with something simple.

If we're talking about storing a structured meaningful program as a
meaningful structure, what sense would it make to store the
fully-qualified name (something rife with meaningful structure) without
regard to that structure?

>> Showing that you could easily recover from accidentally entering an
>> inconsistent state is *not* the same as preventing the state-change to
>> inconsistency in the first place. -- Here is an example of early
>> development using databases as a form of both version-control and
>> project-management:
>> https://drive.google.com/file/d/0BwQVNNshW39cTXVOdWxQaVJ5WjA/edit
>
> I see nothing in there to _prove_ that a code-base cannot be
> inconsistent in a db - regardless of the db model. That is your claim.

I never said it would be independent of the DB model. Proper modeling of
the structure would obviously be required -- there's almost zero
advantage of a DB whose schema is (ID, compilation_unit_name,
compilation_unit_text)... the only advantage there is that by using the
DB you create the possibility of using less physical-space on-disk than
you would using the FS. *Especially* if the block-size for files is much
larger than the modulo-X size of the source.

> I guess this did not happen with Gnat. See below

No, it was with either a GCC or G++ that I had to use at the time.
(Remember; we're talking about handling programming in-general -- not
Ada specifically and not GNAT in particular.)

>>> and exactly _how_ is this more preventable with a db solution?
>> Because with a DB-system you can guarantee that the "system" is not
>> inconsistent or out-of date; and you can associate generated objects
>> with exactly the state that generates them.
>
> Gnat calls that state ali-files...
>
> <http://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn_7.html#SEC84>
> That is gnat user guide , chapter 6.5
> §4
>
> "The ability of GNAT to compile in any order is critical in allowing an
> order of compilation to be chosen that guarantees that gnatmake will
> recompute a correct set of new dependencies if necessary. "
>
> Seems to me that ACT already can guarantee this with files.
> Yes, they use the word guarantee.

Because they're essentially augmenting the file-structure with a
database. -- IOW they're adding more complex work-arounds while
presenting to you the same "environment" that you've always known
(text-files)... instead of tailoring the environment to the actual
problems, they're tailoring their tools to the existing workflow. --
This would be like when they were developing the electric train, instead
of training the engineers on electric-trains making the UI the same as
the Steam locomotive. (Imperfect analogy/word-picture, but I think it
conveys the meaning.)

Actually, no... it would be more like retrofitting a steam-engine so
that the boilers were electric.

[Shark8]

On 07-Jan-15 10:28, Björn Lundin wrote:
> You are building vapor-ware.

You know... it's actually been done before.

R1000 Wikipeda entry
-- http://en.wikipedia.org/wiki/R1000
R1000 page of a danish museum
-- http://datamuseum.dk/wiki/Rational/R1000s400
Evaluation of the Rational Environment
-- http://www.sei.cmu.edu/library/abstracts/reports/88tr015.cfm
"Reminiscing about an old computer system"
--
http://www.somethinkodd.com/oddthinking/category/geek/software-development/rat1000/

So given that there's actual hardware, software, and that there were
actual apparently-professional users I think that "vapor-ware" is an
ill-fitting name.

[Björn Lundin]

On 2015-01-07 20:24, Shark8 wrote:
> On 07-Jan-15 10:28, Björn Lundin wrote:
>> You are building vapor-ware.
>
> You know... it's actually been done before.

I meant that YOU are building vapor-ware.
Not that it has not been done before.

You set out to build
* an IDE
* an Ada2012 compiler
* a ticket/issue system (like Redmine/Bugzilla)

and what not in Freepascal and Delphi.

This has been discussed before here on CLA
where compiler writers says it _very_ hard to write a compiler.
Top that with a 'state-of-the-art' IDE AND a ticket system.

Others has stated the
the Pascal/Delphi people will be not too interested in writing
an Ada compiler (wonder why), and Ada people here will
be fairly doubtful in using Pascal.

You will be fairly lonely.

You won't finish it. Or if you do, Ada2035 will be out.

THAT is vapor-ware.


--
Björn

[Randy Brukardt]

"Björn Lundin" <b.f.l...@gmail.com> wrote in message
news:m8jar2$ceu$1...@dont-email.me...

> On 2015-01-07 13:23, sbelm...@gmail.com wrote:

...

>>start using a
>>different compiler and nobody notices until it's too late.
>
> get real.

Right. I can't speak for GNAT, but for Janus/Ada, incompatible compiler
versions simply can't work together. All of the intermediate files have
version checks, so you get an instant version mismatch error. That happens
to me all of the time, because I forgot to run the environment setting batch
before running a compile or (more likely make). Big whoop.

And your solution to this "just barely a problem" is to create a massive
whiz-bang program that has no chance of being customizable to the extent
that I can do with just a few batch files or shell scripts. That's not
likely to fly; after all GNAT's "source model" of compilation was a reaction
to the much fancier (and complicated) library management techniques that
almost all Ada 83 compilers used. I don't think people suddenly want to go
back and revisit all of that. There is almost no evidence that a
semantics-based editor would be more usable than text, and it's not like
people have tried. (There were lots of such systems in the 1980s; I've used
several and quite honestly, text source is better.)

Randy.

[Randy Brukardt]

"Shark8" <OneWing...@gmail.com> wrote in message
news:qcdrw.1246475$Y4.2...@fx24.iad...

> On 07-Jan-15 04:00, Björn Lundin wrote:

...

Because with a DB-system you can guarantee that the "system" is not
> inconsistent or out-of date; and you can associate generated objects with
> exactly the state that generates them.

I have yet to use *anything* that used a DB that could not have been done
better without the DB. DBs primary claim to fame is the ability to handle
lots of independent transactions. That's pretty much irrelevant for
compiler/IDE tasks (the number of transactions is very low: on the order of
a handful per minute).

For all other purposes, DBs are overkill or worse. They just lock one into a
very heavyweight tool when something much lighter weight would do. And worse
still, a single version of that tool.

...

>> And I still do not see why changing PATH to point to different
>> compiler installations are considered DISGUSTING
>
> Because it is changing a fundamental behavior in a completely
> invisible-to-the-build-system manner; as someone pointed out you can use
> make-files to set the path but this is a work-around -- instead of "making
> it a variable of the function" it's "depending on a global variable" --
> instead of making the build-system analogous to a "pure unit", it depends
> on state.

So you want to change it to use some whizbang tool dependent on a complex
DB? Sounds great, you won't have the path problem because there won't be any
way at all to run more than one version of the build system. (Every system
I've ever dealt with "upgrades" files when used with newer versions, they're
no longer compatible with the older version afterwards. And any other choice
would be a maintenance nightmare, so I wouldn't even consider a system that
tried to do otherwise.)

So of course it's a non-problem in your ideal world. But in the real world,
you've just made it worse.

Randy.

[Randy Brukardt]

"Shark8" <OneWing...@gmail.com> wrote in message

news:1rfrw.561039$ZT5.1...@fx07.iad...
...

>> I guess this did not happen with Gnat. See below
>
> No, it was with either a GCC or G++ that I had to use at the time.
> (Remember; we're talking about handling programming in-general -- not Ada
> specifically and not GNAT in particular.)

But we *are* only talking about Ada (or a very small set of languages). The
odds of being able to build the thing you describe for all programming
languages is non-existent, even for an amazingly deep-pocketed company.
You'd have to build the equivalent of a (simple) compiler for each language
in order to extract semantic information. That could only happen for the
most popular languages -- it could never be very general.

Moreover, if you are talking about getting people to use a whiz-bang unified
tool instead of whatever they do now -- no chance. Remember that Ada already
does the sorts of version checks that you are worrying about. So one could
argue that such a whiz-bang system already exists. And we know how well
getting people to use that has been.

You might say "it's not practical for everyone to program only in Ada".
Perhaps, but you'll quickly find that the same holds true for *any* system
that is supposed to do everything. No system can do everything, and the
problem occurs when you have to go outside of it. So that suggests to me
that it would be most practical to just get people to do more in Ada -- and
that already exists.

Randy.

[Björn Lundin]

On 2015-01-07 23:47, Randy Brukardt wrote:
> "Shark8" <OneWing...@gmail.com> wrote in message
> news:qcdrw.1246475$Y4.2...@fx24.iad...
>> On 07-Jan-15 04:00, Björn Lundin wrote:

Just for the record. I did NOT write this.
Shark8 did.

> ...
> Because with a DB-system you can guarantee that the "system" is not
>> inconsistent or out-of date; and you can associate generated objects with
>> exactly the state that generates them.
>

--
Björn

[Randy Brukardt]

"David Botton" <da...@botton.com> wrote in message
news:1337ca4c-a19e-468e...@googlegroups.com...
>> That's not really fair. Both Atego (with ObjectAda) and RRS (with
>> Janus/Ada)
>> tried to market low-cost compilers for the mass market, but neither made
>> money.
>
>You missed my point, which was fair. There is _no_ low-cost compiler
>market. That bottomed
>out already before OA and RRS started to market their products to a
>non-existing market.
>That market is not going to materialize again ever either.

RRS started low-cost compilers in 1984, long before GNAT existed. But
whatever.

But if there is no market, then there is no point in making a compiler at
all, because giving it away will not pay the bills.

Outreach in the form of demos, GPL versions, etc is cool, but not if it
cannablizes your main revenue stream (whatever that is).

So I'm not quite sure what your point was. Which is probably why I missed
it. :-)

...
>> Which makes it problematical, as some sort of support is required (at a
>> minimum, packaging and fixing of packaging, which can take an amazing
>> amount
>> of time).
>
>A long time ago, people realized that open source changed where the dollars
>are in software.

No, open source eliminated all of the dollars from software. There are
dollars in support of various sorts, some dollars from people who don't know
better, and some dollars from mega-corps building dedicated systems, and
that's about it. And all of those things require people skills that many
software developers don't have and can't realistically acquire (I suspect
that many developers are borderline autistic).

But people that have those sorts of skills have many opportunities better
than software. So it's hard to imagine who will be filling these jobs. And
the people who traditionally have built software are unemployed or
underemployed. (Of course, most jobs will be automated in the coming years,
so that is going to be a growing problem for society to deal with.)

> The vendors that can't see beyond compiler sales haven't survived (per se)
> and those
> in large support contracts are floating, but not swimming if that is their
> only real product.

There's little of value beyond software sales (and I don't consider
"maintenance contracts" a-la AdaCore any different than sales). Most
remaining jobs are glorified marketing jobs that society would be better off
without. Even cloud-based stuff is just a vessel for marketers, criminals,
and governments to invade your privacy and steal your money (I'll let you
figure out which are doing what ;-).

I'm sure it's possible to make money from software, because it's possible
for con men to make money from nothing, but whether its possible to make
money and retain one's ethics is highly dubious.

Randy.

[Randy Brukardt]

"Hubert" <herrd...@fumanchu.com> wrote in message
news:pq0rw.976861$JH1.1...@fx08.iad...
...

> I really wish Adacore would offer a license for small businesses that was
> more affordable. I think that would lure more people in than a completely
> free version.

People have been asking AdaCore that since the beginning of GNAT, and they
have said that it doesn't make econonmic sense. The experience of
Aonix/ObjectAda and RRS/Janus/Ada also suggest that. Plus, there was such a
version of GNAT in the late 1990s (I think) created by a third-party
company, and it didn't work, either.

I have to agree with David that there is no low-cost compiler market
anymore. The only market (apparently) is for high-quality support, and that
by its nature is very expensive (because its manpower-dependent).

Even a small business license would need some sort of support and guarantees
(else why pay for it?), and it's hard to make that come out. RRS has always
lost money on its support contracts (they really should cost 5 times as much
as they do). But are small businesses going to fork over $2000 per year?

Randy.

[Randy Brukardt]

"Björn Lundin" <b.f.l...@gmail.com> wrote in message

news:m8kdu9$a9k$1...@dont-email.me...

Sorry. I lost track of who said what, especially when I got a bit worked up
about it... :-)

Randy.

[David Botton]

> RRS started low-cost compilers in 1984, long before GNAT existed. But
> whatever.

And then the entire small compiler market for Ada was tiny, and microscopic compared to markets for Turbo Pascal or Turbo C++, in fact Turbo Prolog (I liked that) was probably larger a 1000 fold.

Many companies did excellent in the low-cost compiler market in those days. None of those companies exists per se now. (Borland for example, whose catalog is still dragged along for old customers even with some enhancements)

> But if there is no market, then there is no point in making a compiler at
> all, because giving it away will not pay the bills.

Correct. That has been the case now for a long time.

Like most things these days you need alternative models for monetizing your creative ideas since the old ones are used up, that is part of progress.

> Outreach in the form of demos, GPL versions, etc is cool, but not if it
> cannablizes your main revenue stream (whatever that is).

In a world of libre software if giving it away would cannibalizes your business then you have no real business model, fools will do things to slow the bleeding like shareware... smart companies understand the code today is not the product and can not be the product, it is just a means to the end.

Support is one revenue stream but there are many others one can tap in to in any market. In general every market today needs to be creative to generate revenues.

Examples beyond compilers:

Evernote - 30% of its monthly sales was in _physical goods_ in Dec 2013, 3 months after launch. I don't have recent numbers but I suspect far more now.

I make a large part of my medical clinic revenue from alternative revenue streams. 40% of the people that come to me for medical assistance can not afford it or if their insurance not paying for the services there is a mental barrier to out of pocket for care even when needed. So I discount or offer my medical services for free and make up overall with other services and products they are willing to pay for and/or can afford. (Another example of my win win approach to business and proof it always works, and closer to the idea of OpenSource)

I built a school over the last few years, also using creative funding methods (All win win situations, those that can't afford have schooling options, etc. etc.) and a few other projects and business all succeeding using creative funding methods. (Each again with win win scenarios for everyone)

There are many ways anyone can succeed when they have the humility to find them and if they try a win win way of doing it are usually blessed with much success.

If even a pompous guy with a blown up head like me can find avenues to success, any one can :)

> So I'm not quite sure what your point was. Which is probably why I missed
> it. :-)

<< Most of these vendors have the same small minded thinking of only looking at direct sales instead of expanding the user base through mass marketing efforts through free or cheap compiler options.>>

Point was:

There is only doom to vendors that think their products are the compilers.

That it is counter productive to place any stumbling block in the way of Ada use for any purpose since the compiler is not the source of revenue and the larger the base of Ada users in all markets the larger the pool of those that will influence a potential customer to buy the real products vendors offer or could offer.

Here is a recent example of small minded thinking:

https://www.mail-archive.com/gcc-p...@gcc.gnu.org/msg100382.html

Unless the tools needed to build with gpr file are up streamed to the FSF the barrier to a working toolset out of the box got even larger. [I will gladly eat my words and even apologize openly if gprtools and its dependencies xmlada and gnatcoll are up-streamed to the FSF and become part of the regular build of the toolchain] - ya ya someone will write download from libre.. start a new thread if you want to argue about why I am wrong to say it has to be through the FSF, don't hijack this one.

GPL as a weapon rule #2 - You don't have to deliver source that works easily, just something that could work if you knew how.

Rule #1 we all know - infect the outputs with GPL virus to encumber your victim

GPL is a gun (letters spell gnu... hmm) used correctly it brings security to all - everyone can see what's inside, improve on it, etc, in the wrong hands a gun to cripple innovation through "technically correct" uses of the GPL.

> And all of those things require people skills that many
> software developers don't have and can't realistically acquire (I suspect
> that many developers are borderline autistic).

And so the rule that the key to success of a business is the team's diversity of skills. The places I do have partners they are rarely like me in any way, but share my passion for whatever the goal of that organization is or has been. I choose my employees, partners, etc. based on their passion for the goal, _before_ even their skills. (Heck you all get to decode my poor grammar and spelling from banging out a post barely proofing it first, and most just accept me for my passion for Ada and forgive it :)

> But people that have those sorts of skills have many opportunities better
> than software. So it's hard to imagine who will be filling these jobs

If they have people and software skills they tend to do both or bring together teams of people on both sides. If they don't have software skills but just people skills they bring together software teams for common goals.

My experience is that sometimes we don't evaluate where we fit in to things and do not team with the right diversity but instead pick people just like ourselves that will not rock the boat and be "yup" men.

> And the people who traditionally have built software are unemployed or
> underemployed.

Those that didn't continue expanding their skill sets usually. There are only so many jobs for people that no the ins and the outs of Wangs :) (But I do know someone making a living there too... I wonder what happens when that job is gone for him)

> (Of course, most jobs will be automated in the coming years,
> so that is going to be a growing problem for society to deal with.)

And those that expand the skill sets in to the new areas that come with it will succeed.

During the Cultural Revolution in China they stupidly killed off most of their greatest treasures, their culture and past to replace it with the new "western" knowledge. Main land China almost completely destroyed their medical knowledge base in the zeal for it. If it wasn't for post revolution efforts to take the remnants and force them to work together to record their knowledge even more would have been lost than already was. They then took the old knowledge applied western and innovations abound.

The past offers gems for the future, so I write "expand" not replace or even add. The idea behind Gnoga for example is to expand Ada to current tech outside the safety critical niche. With that Ada gets more life and those that know it can expand with it. One hand on the past (Ada just like Chinese medicine of the past is just as much also the present) and one hand on the future.

As is I am using borrowed time for Ada, but I wish I had more time. Such a rich past deserves a rich future. I hope others will find some passion this year for some new way to use Ada or new interface to modern tech, etc.

(BTW, having been many times on the hiring boards for large companies or startups, we always grabbed up people with innovative public projects before anyone else, even with tons of degrees, etc., it showed they have initiative, drive, passion, and skill)

> There's little of value beyond software sales

I can assure you there is or the companies making google plex amounts of money giving software away for free wouldn't be making it ;)

> (and I don't consider
> "maintenance contracts" a-la AdaCore any different than sales).

They are sales, just not direct software sales, but service sales.

Confusion what the product really is, is why things are stagnant beyond the niche and bleeding around it.

> Most remaining jobs are glorified marketing jobs that society would be better off without.

South Florida is flat, no valleys and no mountains (highest point in my county is a small hill at a botanical garden I like to bring the family to), yet there are many jobs available for the right skill sets.

I am hoping that Gnoga will allow Ada programmers the ability to write and sell products for small businesses, the old software pioneering. (Yes is direct sales, but if they are innovative far more ;) I get calls every week asking if I know someone that can write for their company a program that does X, etc. They don't care how just that it is done quick and reasonably priced. So at least for "our guys" there is a win win to come.

> I'm sure it's possible to make money from software, because it's possible
> for con men to make money from nothing, but whether its possible to make
> money and retain one's ethics is highly dubious.

There is a beautiful world out there. Most of it is far away from government related projects though :)

In summary of all that hot air:

Expanded_skill_sets + humility + passion + win_win = Success.

David Botton

[Hubert]

It's a concern when selling the result. Frankly I can't remember the
last time I was using a Microsoft compiler I paid for. I guess that was
some years ago when I was still working for a company, I guess they
bought their licenses. I don't even know what VisualStudio cost these
days, but I think it's in the range 500-2000$ depending on the version.
I havent' looked at it closely but I believe they offer their latest
version for free even? And it is something you can make an applicaiton
with and sell it.

Now if I would depend on selling software I make that way, I would pay
2000$ for a compiler, but just once, meaning if there were multiple
people working on the project, I would use the free version and then pay
for one license to compile the final result that goes to the customer.

It also depends on the type of service I guess. For instance I am
working on a tool that I write in Ada now. I will release it as Open
Source when I'm done so their pro version doesn't concern me. However, I
was making a change in the package structure yesterday or today that
made the compiler crash with an invalid access error. Now I suppose if I
was working on some major project that would be bad and you could pester
them for a solution, but I changed the program to make the error go
away, that worked for me. I didn't bother trying to contact them because
I know they don't provide support for the free version, however there's
a bug in the compiler and that bug is probably with their paying
customers as well, so it would have been in their interest to at least
provide some sort of bug report facility that someone like me could use
even if there's no help provided.

But yes, I suppose if that's the way it is today, either expensive
compilers or nothing, than I guess they know best what makes sense for
them and perhaps for the little guys it means using the FSF version if
you want to release a closed source program.

It makes no big difference for me, since I am working on a client server
game. The client will always be in C++ due to the connectin to a 3rd
party graphics library, which will be the new Unreal SDK once I get rid
of the crappy engine I'm using now, and which btw sells for 15$ / month
plus 5% of your gross income if you sell your product. Now that is an
offer you can't refuse as small developer and it is a more than
reasonable offer, which is why tons of people are jumping on the new
engine. Considering that Epic Games is multimillion dollar company who's
engine is used in AAA titles by the biggest companies in the world, I
think they outshine Adacore by several factors. If they think there must
be money in a business model like this, I am sure there is.

But then, maybe Adacore is just too secure with companies like Boeing,
Airbus, Raytheon on their customer list.


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

[Hubert]

> I am hoping that Gnoga will allow Ada programmers the ability to write and sell products for small businesses, the old software pioneering. (Yes is direct sales, but if they are innovative far more ;) I get calls every week asking if I know someone that can write for their company a program that does X, etc. They don't care how just that it is done quick and reasonably priced. So at least for "our guys" there is a win win to come.

Actually, isn't Gnoga providing a platform just like what big companies
like Microsoft are trying to sell? "Cloudbased computing"? Which is
really just a euphemism for old fashioned client server development just
on a massive scale?

If so, this would enable a lot of people to provide their software on a
server as a service for rent, which is what MS want's to do more and
more because they recognized that it's better to make 20$/month than
100$ from a one time sale.

[David Botton]

> Actually, isn't Gnoga providing a platform just like what big companies
> like Microsoft are trying to sell?

Best way to see the Gnoga framework is as a UI toolkit, that if desired the UI can be run remote like a thin client.

David Botton

[Dmitry A. Kazakov]

On Wed, 7 Jan 2015 16:47:25 -0600, Randy Brukardt wrote:

> I have yet to use *anything* that used a DB that could not have been done
> better without the DB.

True.

What about parallels between evolution of languages:

untyped -> weakly typed -> strongly typed -> OO

and persistent storage:

files -> DB -> nothing -> nothing

Of course neither has any relation to the problem of versioning and
interoperability Shark8 seem to believe in. Except that each new step makes
things greatly more difficult. E.g. interfacing C vs. interfacing C++.

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

[Simon Wright]

David Botton <da...@botton.com> writes:

> Here is a recent example of small minded thinking:
>
> https://www.mail-archive.com/gcc-p...@gcc.gnu.org/msg100382.html
>
> Unless the tools needed to build with gpr file are up streamed to the
> FSF the barrier to a working toolset out of the box got even larger

The reasoning is that gprbuild is much more capable than gnatmake, and
keeping gnatmake up to speed would be hard.

gprbuild is (C) FSF, gnatcoll & xmlada are (C) Adacore. All are GPLv3
with the runtime library exception excised.

It is of course possible to use the GPL gprbuild to invoke an FSF
compiler via a GPR file (I just did!) but that hardly counts as 'out of
the box'.

I will continue to provide gprbuild (somehow!) with my Mac binaries.

Not sure whether the Debian gnat package includes gprbuild?

[Simon Wright]

Hubert <herrd...@fumanchu.com> writes:

> I didn't bother trying to contact them because I know they don't
> provide support for the free version, however there's a bug in the
> compiler and that bug is probably with their paying customers as well,
> so it would have been in their interest to at least provide some sort
> of bug report facility that someone like me could use even if there's
> no help provided.

Mail rep...@adacore.com with GNAT: at the beginning of the subject
line. Sometimes you get a response; sometimes, even, help.

[G.B.]

On 08.01.15 09:14, Dmitry A. Kazakov wrote:
> On Wed, 7 Jan 2015 16:47:25 -0600, Randy Brukardt wrote:
>
>> I have yet to use *anything* that used a DB that could not have been done
>> better without the DB.
>
> True.

False, in general:

As soon as you start talking truly relational, you'll either
use Prolog-ish programs, which are DB programs.

Or, in Ada, you'll use pointers or cursors, or symbols in
anything else, and start reinventing everything that the full
relational model provides for free.

Using the GNAT repertoire in the compiler sources,
this question is typical of thinking "relational":

"List all Ada identifiers that are public in packages
that are children of P0, provided that they are not of
a pointer type."

A standard RDBMS solution, while obvious, is perhaps
inadequate for reasons of performance, specialization,
Ada fanatism, etc. But it takes a political argument
to deny that compilers do actually include those data
structures and algorithms that the relational model
has as built-ins.

For a worldly, commercial case,
Google's non-SQL hash table based "database" is a major
failure for programs using more than indexed lists, as is
demonstrated by the hugely successful addition of an RDB
option that Google added to the same App Engine.

And yes, SQL isn't perfect, and the type system of the
relational model is much underused. And no, I do not now
think that "relation" necessarily needs any more
representationin the type system than maybe "if".

Thanks to GNAT not being closed source shareware,
we are able to consider the relational question above ;-)

[G.B.]

On 08.01.15 05:09, Hubert wrote:
> I havent' looked at it closely but I believe they offer their latest
> version for free even? And it is something you can make an applicaiton
> with and sell it.

This is misleading, as Microsoft's cost-free versions
of their software would not allow selling some Microsoft
style applications made using them. "Non-enterprise" and
"individual developer" are terms Microsoft uses in their
licensing white paper.

The existence of a white paper about licensing should
be a hint in itself.

[Ludovic Brenta]

Simon Wright writes:
> Not sure whether the Debian gnat package includes gprbuild?

No; gprbuild is packaged separately from gnat in Debian but both are
available. gnatcoll and xmlada are also packaged separately.

Still I'm sad at the prospect of being forced to use gprbuild where
gnatmake now works. As some people noted, this move makes it that much
more difficult to provide, install, maintain etc. a complete toolchain.

Note that even though gprbuild is pure GPL, it can produce proprietary
software. The only thing that might possibly affect the licensing of
the software you compile with any toolchain is the license of the
*libraries* that you link or copy (via generic instantiation) into your
executable, and gprbuild is not a library.

--
Ludovic Brenta.

[Dmitry A. Kazakov]

On Thu, 08 Jan 2015 11:55:09 +0100, G.B. wrote:

> On 08.01.15 09:14, Dmitry A. Kazakov wrote:
>> On Wed, 7 Jan 2015 16:47:25 -0600, Randy Brukardt wrote:
>>
>>> I have yet to use *anything* that used a DB that could not have been done
>>> better without the DB.
>>
>> True.
>
> False, in general:
>
> As soon as you start talking truly relational, you'll either
> use Prolog-ish programs, which are DB programs.

Prolog has nothing to do with DB, except that, Randy's statement fully
apply to Prolog: anything done in Prolog that could have been done better
without Prolog.

> Or, in Ada, you'll use pointers or cursors, or symbols in
> anything else, and start reinventing everything that the full
> relational model provides for free.

Relational algebra (RA) can be implemented in Ada. No problem, except
issues with generics.

You cannot easily do:

generic
type Tuple_Element_Array is (Positive range <>) of private;
package Relational is

with

Tuple_Element_Array'Element_Type (N)

to denote N'th type.

> Using the GNAT repertoire in the compiler sources,
> this question is typical of thinking "relational":
>
> "List all Ada identifiers that are public in packages
> that are children of P0, provided that they are not of
> a pointer type."

This is not relational. Relational algebra does not deploy universally
qualified expression. You need a set (table) to search though.

Once you have it, it is a big question whether relational operations would
be useful or could be implemented at all. There are quite few things which
are good mapped onto relations and the corresponding data structures
backing them, e.g. B-trees.

A simple counterexample is spatial neighbour search (kD-tree).

> A standard RDBMS solution, while obvious, is perhaps
> inadequate for reasons of performance, specialization,
> Ada fanatism, etc. But it takes a political argument
> to deny that compilers do actually include those data
> structures and algorithms that the relational model
> has as built-ins.

There are many bad-to-destructive technologies used everywhere. E.g.
AdaCore's GNAT uses XML, Python. At least RA could have some application
areas. XML and Python have none.

[G.B.]

On 08.01.15 13:30, Dmitry A. Kazakov wrote:
> On Thu, 08 Jan 2015 11:55:09 +0100, G.B. wrote:
>
>> On 08.01.15 09:14, Dmitry A. Kazakov wrote:
>>> On Wed, 7 Jan 2015 16:47:25 -0600, Randy Brukardt wrote:
>>>
>>>> I have yet to use *anything* that used a DB that could not have been done
>>>> better without the DB.
>>>
>>> True.
>>
>> False, in general:
>>
>> As soon as you start talking truly relational, you'll either
>> use Prolog-ish programs, which are DB programs.
>
> Prolog has nothing to do with DB,

Really? Prolog always has been about databases as long as it
has existed, TTBOMK. It is even using that word meaningfully
at its very basis.
Or are you referring to a different meaning of "DB"?
Prolog:

% the database (base universe):
apple(green, 59).
apple(red_and_green, 49).

orange(sweet, 27).
orange(sour, 20).

% cross product
apples_x_oranges(A1, A2, O1, O2) :-
apple(A1, A2),
orange(O1, O2).

% selection from cross product
fruit_salad(A, PA, O, PO) :- % pricey
apples_x_oranges(A, PA, O, PO), PA > 50, PO > 20.

?- fruit_salad(X, Y, Z, W).
X = green,
Y = 59,
Z = sour,
W = 27 ;
false.

The same setup could be used for a database of Ada identifiers
and possible relations among them, since each of the identifiers,
as the word "identifier" says, denotes identically one element of
the universe of named things that an Ada source establishes.

> Relational algebra (RA) can be implemented in Ada. No problem,

You *are* naming the problem:

It is: "reinventing wheels", as I said. The point is that relational
problems can be solved easily whenever a language defines the means
of directly expressing relational items. Such a language does *not*
require that modes of expression be implemented first. OTOH, if that's
difficult to do in Ada, then a reusable implementation seems preferable
to compilers' idiosyncrasies except for the reasons listed.

>> Using the GNAT repertoire in the compiler sources,
>> this question is typical of thinking "relational":
>>
>> "List all Ada identifiers that are public in packages
>> that are children of P0, provided that they are not of
>> a pointer type."
>
> This is not relational.

Aha...

> Relational algebra does not deploy universally
> qualified expression.

Every selection is from the next universe, all of it. What definition
of the RA equivalent of FROM are you denying? I don't understand.

> A simple counterexample is spatial neighbour search (kD-tree).

A counterexample is usually a technique for invalidating
a general statement, but there is no general statement
about Relational being Whatever in *every* situation.
Relations are just being used in compilers, and in ASIS tools.

[Dmitry A. Kazakov]

On Thu, 08 Jan 2015 15:17:15 +0100, G.B. wrote:

> The same setup could be used for a database of Ada identifiers
> and possible relations among them, since each of the identifiers,
> as the word "identifier" says, denotes identically one element of
> the universe of named things that an Ada source establishes.

This is obviously wrong, since units can be instantiated, recursively used,
objects have scopes and life time.

Which "Universe" you mean for an identifier X declared in a body of a task
type?

>> Relational algebra (RA) can be implemented in Ada. No problem,
>
> You *are* naming the problem:
>
> It is: "reinventing wheels", as I said.

No more than other container types are. Relational table is a container.
There is nothing special about it. There exist both more complex and more
useful container types.

RA, to build a programming paradigm upon, is known to be unusable. Which is
the rationale behind Randy's empirical conclusion about databases.

> The point is that relational
> problems can be solved easily whenever a language defines the means
> of directly expressing relational items.

Another point is that relational problems are not domain space problems. RA
requires bending original problems into a very narrow framework of
techniques, inefficient and counterintuitive.

> OTOH, if that's
> difficult to do in Ada, then a reusable implementation seems preferable
> to compilers' idiosyncrasies except for the reasons listed.

DB models have practically zero reuse and are extremely unmaintainable as
compared to other software.

That is because DB design focus on raw data, rather than on higher level
entities.

>> Relational algebra does not deploy universally qualified expression.
>
> Every selection is from the next universe, all of it. What definition
> of the RA equivalent of FROM are you denying? I don't understand.

What is FROM for Ada identifiers?

>> A simple counterexample is spatial neighbour search (kD-tree).
>
> A counterexample is usually a technique for invalidating
> a general statement, but there is no general statement
> about Relational being Whatever in *every* situation.
> Relations are just being used in compilers, and in ASIS tools.

Relations are used everywhere because they are in the foundations of
mathematics.

RA as a computational model is a totally different issue. Its
implementation in RDBMS is yet another.

[Shark8]

On 08-Jan-15 03:55, G.B. wrote:
> And yes, SQL isn't perfect, and the type system of the
> relational model is much underused.

The biggest problem with SQL is that the standard makes *so much*
optional that there's essentially zero portability between
implementations. (Just try writing a few non-trivial CREATE TABLE
statements and inputting them across MySQL, Postgres, FireBird, MSSQL, etc.)

[Björn Lundin]

Yes, for DDL statments,
but DML statements are often quite similar, if
the vendor confesses to one of the standards.

We have about 700 hand-written statements in our WMS system,
+ a wealth (~3000) of table centric ones - auto generated -
and there is only 1 case where we differ the statements between the
vendors (Oracle, MS-sql-server and postgresql) and that
statement contains 'Substring', which in Oracle sql is 'substr'.

All other insert,select,delete,update are the same.
while some of them are trivial, other are more complicated like

SQL.PREPARE(SELECT_IPLOADS_TO_BLOCK,
"select IPLOAD.*, IPAEXPI " &
"from IPLOAD, IPART " &
"where IPLSTA < :RESERVED " &
"and IPLRES = 0 " &
"and IPLQUA > 0 " &
"and IPLSDAT < :SYSTEM_DATE " &
"and IPART.IPARTID = IPLOAD.IPARTID " &
"and IPAEXPI > 0 " &
"and not exists (select 'X' from IPLBLOC " &
"where IPLBLOC.IPLOAID = IPLOAD.IPLOAID " &
"and IPLBLOC.IBLOCAUS = :EXPIRED) " &
"and not exists (select 'X' from IBOMLOA " &
"where IBOMLOA.ILDID = IPLOAD.ILDID)");


--
Björn

[Randy Brukardt]

"David Botton" <da...@botton.com> wrote in message

news:17ad25fe-e04f-4d79...@googlegroups.com...

>> RRS started low-cost compilers in 1984, long before GNAT existed. But
>> whatever.

>And then the entire small compiler market for Ada was tiny, and microscopic
>compared
>to markets for Turbo Pascal or Turbo C++, in fact Turbo Prolog (I liked
>that) was
>probably larger a 1000 fold.

You grossly underestimate the power of Ada back in its glory days. For your
statement to be true, Turbo Prolog would have had to sell well beyond
5,000,000 copies. That seems unlikely. I might believe it for Turbo Pascal,
but that's it.

>Many companies did excellent in the low-cost compiler market in those days.
>None
>of those companies exists per se now. (Borland for example, whose catalog
>is still
>dragged along for old customers even with some enhancements)

True enough. But I don't know why we're talking about this, because almost
everyone here realizes that there is no profit in a low-cost compiler (for
any language). If Microsoft feels it necessary to give awy their compilers
(and they do), that's probably true for everyone else too.

The problem, of course, is that software development systems (which are far
more than a compiler, of course) can't be built by volunteers. Stuff like
program correctness is just too hard to be built by few people in their
spare time.

But if there is no market for them, we'll continue to get more of the same.
Indeed, it's pretty clear that the trend; a major "feature" of the cloud is
that software can be replaced quickly, so there is much less incentive to
get it right in the first place. Which means of course that it never will be
right (and that contributes a lot to the ease of criminals breaking into
systems).

>> But if there is no market, then there is no point in making a compiler at
>> all, because giving it away will not pay the bills.
>
>Correct. That has been the case now for a long time.
>
>Like most things these days you need alternative models for monetizing your
>creative
>ideas since the old ones are used up, that is part of progress.

Since the ideas are ways to make software development better, there is
nothing else to monitize. I'm not remotely interested in developing software
for people that aren't already computer experts -- it's hard enough to
please people that understand you and with which you have something in
common.

>> Outreach in the form of demos, GPL versions, etc is cool, but not if it
>> cannablizes your main revenue stream (whatever that is).
>
>In a world of libre software if giving it away would cannibalizes your
>business
>then you have no real business model,

You're probably right. As far as I can tell, there is no remaining business
model for anything that I am competent at or care about.

Anything that one could do will be copied or even stolen before it could be
brought to market.

Indeed, I don't understand why you think Gnoga will be good for Ada beyond
an improvement for the existing believers. After all, if the model is so
good, someone will copy it for C++ or Java, and they'll get the trade press
for it, and [almost] everyone will think that the people who copied it
invented it. (Consider the STL, for example, which started in Ada.) There
isn't much that can be done in Ada that can't be done in those other
languages (not quite as well, of course, but no one will care about that).
Of course, if the model doesn't pan out, then it'll be just another failed
technology.

I haven't wanted to discourage you in any way from developing Gnoga, which
is mainly why I haven't brought this up sooner. But from the moment I read
about it, I thought that it doesn't have much chance to be a game-changer,
because anything one guy can do in a man-year can be copied by another guy
in half that time (the tough work is done, after all). Hope I'm wrong.

>> And the people who traditionally have built software are unemployed or
>> underemployed.
>
>Those that didn't continue expanding their skill sets usually. There are
>only so many
>jobs for people that no the ins and the outs of Wangs :) (But I do know
>someone
>making a living there too... I wonder what happens when that job is gone
>for him)

Sadly, that's how I've treated Ada for the last 10+ years. Hope that it
lasts until I reach retirement.

There is very little in what passes for computing these days that I can
stand to look at. Most of what would be required to "expand ones skill set"
would require checking my brain at the door and making unmaintainable
mash-ups of stuff that will stop working in a week (not the 20 years I want
to run a program).

I suppose that makes me a dinosaur, because I still care about doing things
right.

...

>> (Of course, most jobs will be automated in the coming years,
>> so that is going to be a growing problem for society to deal with.)
>
>And those that expand the skill sets in to the new areas that come with it
>will succeed.

Well, if you mean learning to be a Wal-Mart greeter, perhaps you're right.
Otherwise, I don't see it, because the vast majority of these machines will
be self-repairing and eventually even self-constructing. There's little room
for humans in that equation (and that's discounting the Terminator-style
outcomes). I'm actually surprised that it hasn't happened already, but as
with many things, the pace of progress is slower.

...

>There is a beautiful world out there. Most of it is far away from
>government related projects though :)

Yup. However, it only beautiful when people have left their grubby hands off
of it. And unfortunately, there is no market for hermits. :-)

>In summary of all that hot air:
>
>Expanded_skill_sets + humility + passion + win_win = Success.

As far as I can tell, I've never possessed any of these things except for
passion
(I'd put the equation at:
Ignorance + ego + previous experience with small business + passion +
luck = Success)
...and the passion and luck were squeezed out years ago by Open Source and
the takeover of the computer business by massive corps -- essentially
catching the real innovators in a vice.

Not that I expect anyone to feel sorry for me. There are no real second
chances, and a lot of people never even get a first chance.

Randy.

[Randy Brukardt]

"G.B." <bau...@futureapps.invalid> wrote in message
news:m8lnlg$eat$1...@dont-email.me...

> On 08.01.15 09:14, Dmitry A. Kazakov wrote:
>> On Wed, 7 Jan 2015 16:47:25 -0600, Randy Brukardt wrote:
>>
>>> I have yet to use *anything* that used a DB that could not have been
>>> done
>>> better without the DB.
>>
>> True.
>
> False, in general:
>
> As soon as you start talking truly relational, you'll either
> use Prolog-ish programs, which are DB programs.

Anyone who's talking "truly relational" needs their head examined.

> Or, in Ada, you'll use pointers or cursors, or symbols in
> anything else, and start reinventing everything that the full
> relational model provides for free.

But using the "relational model" is nowhere near free. One has to import
some giant bloatware that changes without warning, most likely has to employ
an expert in said bloatware in order to get anything done, you have to force
your software into an almost always inappropriate transactional model, and
so on. The performance hit is fantastic.

There of course are problems for which DBs are well suited, but there are
far fewer of them out there than are generally supposed. That's because the
makers of the bloatware (you know who they are) strongly promoted the
DB-everywhere model, mainly so they could sell more bloatware. Unless your
problem is very close to the strengths of a DB, just say no.

> Using the GNAT repertoire in the compiler sources,
> this question is typical of thinking "relational":
>
> "List all Ada identifiers that are public in packages
> that are children of P0, provided that they are not of
> a pointer type."

No one asks questions like that, because the answer is in the hundreds for
many common identifiers. And if not, simple text search gets you the answer.
Besides, visibility information can't sensibly be represented in a database,
it depends on both the location of the declaration and the location of use.

> A standard RDBMS solution, while obvious, is perhaps
> inadequate for reasons of performance, specialization,
> Ada fanatism, etc. But it takes a political argument
> to deny that compilers do actually include those data
> structures and algorithms that the relational model
> has as built-ins.

This stuff is so basic that any program would have it (entity lookup, for
instance). If a DB didn't have it, it would be completely useless. So that
proves nothing whatsoever.

> For a worldly, commercial case,
> Google's non-SQL hash table based "database" is a major
> failure for programs using more than indexed lists, as is
> demonstrated by the hugely successful addition of an RDB
> option that Google added to the same App Engine.

Which just shows that most so-called developers today could not program
their way out of a paper bag. They depend on having everything pre-built for
them, and then they make fragile mashups that depend on things that they
have no control over at all (meaning that there code will break frequently).
Microsoft and others got the world so used to that that no one expects more
anymore.

DB. Bah-humbug. :-)

Randy.

[Randy Brukardt]

"G.B." <bau...@futureapps.invalid> wrote in message

news:m8m3ge$sg3$1...@dont-email.me...
...

> It is: "reinventing wheels", as I said.

In most cases, I'd rather reinvent a wheel rather than depend on someone
else's wheel of indeterminate quality which will change at unpredicable
intervals. The only time reuse (of any kind) makes sense is when it will
save a lot of effort for very little cost. (I'm not going to invent an HTML
browser to show help in my next program, the effort would be much higher
than the benefit, especially as it is not a critical part of the program.)

Using a DB has a high cost (in getting the interface to work, figuring out
queries and schemas, etc.) and it adds a level of fragility (because of the
frequent updates, any one of which could break one's system; additionally,
someone outside of your code can easily access the data files using the DB
and make them inconsistent). The benefit would have to be very high, and
given the simplicity of what it provides, that requires a very specific type
of application (one for a which a transactional model makes sense).

Randy.

[Paul Rubin]

"Randy Brukardt" <ra...@rrsoftware.com> writes:
> There is very little in what passes for computing these days that I can
> stand to look at. Most of what would be required to "expand ones skill set"
> would require checking my brain at the door and making unmaintainable
> mash-ups of stuff that will stop working in a week (not the 20 years I want
> to run a program).

Give Haskell a try, http://haskell.org . It is the most mind-expanding
thing that I've ever done as a programmer. And its type system makes
Ada's look weak and primitive.

[David Botton]

> 5,000,000 copies.

How many were non-DoD, they don't count, they had to us it.

> Stuff like
> program correctness is just too hard to be built by few people in their
> spare time.

And so the DoD, Apple and others invested/invest and for their own motives require their efforts end in a way to benefit the masses to create trickle up.

> Since the ideas are ways to make software development better, there is
> nothing else to monitize. I'm not remotely interested in developing software for people that aren't already computer experts -- it's hard enough to please people that understand you and with which you have something in common.

The "secret" to a great product is to only produce what you yourself want to use and have passion for. The only things I've regretted in my life are the few times I worked for the money and not for the passion of the product itself and those times _hurt_ me.

May you be lucky enough in life to never have to and may we always share with you the things you do for their own sake :) Since the RM is fantastic (I learned Ada from it and use it constantly, I can't say that about any other language and most of my life's coding has not been in Ada) I can only assume you enjoy working on it and the other projects of yours we enjoy.

> You're probably right. As far as I can tell, there is no remaining business
> model for anything that I am competent at or care about.

No, you just need to partner with someone that can share your passion, but perhaps not your skills, and has the skills to monitize it.

Build your passion first, monitize later.

> Anything that one could do will be copied or even stolen before it could be brought to market.

If what you did was with passion and for its own sake, then it will work anyways. Almost every major startup that has succeeded never hid what it was doing before it was done.

In the current market of libre software, since your code is not the product anyways it really doesn't matter at all if some one copied or "stole" it.

> Indeed, I don't understand why you think Gnoga will be good for Ada beyond
> an improvement for the existing believers. After all, if the model is so
> good, someone will copy it for C++ or Java, and they'll get the trade press
> for it, and [almost] everyone will think that the people who copied it
> invented it.

If I was thinking about "money" I would have written Gnoga in Python. (I wouldn't respect myself in the morning though...)

I wrote gnoga in Ada because I enjoy coding in Ada.
I wrote Gnoga because I want Gnoga and need it for me.
I publish Gnoga as Open Source because I want others to enjoy the music.
I publish in GMGPL because that will benefit Ada and other developers

If the business models (I've only shared a bit here and there with anyone) work out then my investment pays with cash too and for everyone (win win) and if it doesn't I sang my music even if only I enjoyed it and did what I could to help Ada _and_ the Ada community beyond the niche (win win).

> Of course, if the model doesn't pan out, then it'll be just another failed
> technology.

What's wrong with failed tech, some parts of the song will be sung again (if OpenSource), perhaps in a remix :)

If Gem (~1985) was OpenSource we would never have had to suffer with Windows now...

> I haven't wanted to discourage you in any way from developing Gnoga, which
> is mainly why I haven't brought this up sooner.

No worries, it wouldn't discourage me. I only count a friend someone that will tell me I'm wrong (or try to :)

> But from the moment I read
> about it, I thought that it doesn't have much chance to be a game-changer,
> because anything one guy can do in a man-year can be copied by another guy
> in half that time (the tough work is done, after all). Hope I'm wrong.

I'll be happy to meet that guy if he has Botton sized passion :) We'd make a good team or epic adversaries and then eventually probably a team anyways unless he was e.v.i.l.

And if someone just steals my code? You can't steal libre code (you can abuse its license....). The opposite I want it to grow and happy if others add their water or re-plant it. I think better as a team, but if they have enough passion to do it. maybe I'll use their expanded version over my own :)

> Sadly, that's how I've treated Ada for the last 10+ years. Hope that it
> lasts until I reach retirement.

If I can help it, Ada will :)

(I don't even care how pompous that sounds, if I can't believe I will make a difference for Ada (and that has happened before...) I wouldn't bother with it.)

> There is very little in what passes for computing these days that I can
> stand to look at. Most of what would be required to "expand ones skill set"
> would require checking my brain at the door and making unmaintainable
> mash-ups of stuff that will stop working in a week (not the 20 years I want
> to run a program).

You have the talent, do it for you!

> Well, if you mean learning to be a Wal-Mart greeter, perhaps you're right.
> Otherwise, I don't see it, because the vast majority of these machines will
> be self-repairing and eventually even self-constructing.

So perhaps you should start writing the code to make that happen as your expansion :)

> Yup. However, it only beautiful when people have left their grubby hands off
> of it. And unfortunately, there is no market for hermits. :-)

Not true at all. You would be surprised how many of them are doing very well :)

> As far as I can tell, I've never possessed any of these things except for
> passion
> (I'd put the equation at:
> Ignorance + ego + previous experience with small business + passion +
> luck = Success)
> ...and the passion and luck were squeezed out years ago by Open Source and
> the takeover of the computer business by massive corps -- essentially
> catching the real innovators in a vice.

When your formula isn't succeeding it is a sign that it has bugs. Try mine it doesn't have aspects and fancy stuff like that, but its been debugged and run enough years to be considered proven stable.

> Not that I expect anyone to feel sorry for me. There are no real second
> chances, and a lot of people never even get a first chance.

I respect you too much to ever consider feeling sorry for you. I like you enough to maybe even to give you a kick if I see you in person again :)

When I treat a patient, sometimes the next time I see them they say the pain moved from place X to place Y. I'm thrilled. Because as long as there is change, they are already getting better.

On thing leads to another in life, so even if the next Open Source Ada project _you_ do isn't the one that brings the fame and fortune, where it leads you next will and at the least you've enjoyed making (in your case one more) difference for Ada.

David Botton

[David Botton]

> Give ____ a try, http://_ohnoyoudon't.org_ . It is the most mind-expanding

> thing that I've ever done as a programmer. And its type system makes
> Ada's look weak and primitive.

Begone troll! Off with ye head!

[Paul Rubin]

David Botton <da...@botton.com> writes:
>> Give ____ a try, http://_ohnoyoudon't.org_ .

> Begone troll! Off with ye head!

Heh, I'm not trying to troll, Ada is just designed to work in the
intersection of a bunch of different niches (highly correct code,
realtime code, code that runs in constrained environments) and that's
why there's not that many programmers involved in it. If you're mostly
interested in writing solid, correct code but can look outside the
embedded and realtime niches, there's plenty going on.

Take a look at http://compcert.inria.fr which is about a formally
verified C compiler (who knows, maybe it might compile Ada sometime too)
written in Coq generating Ocaml. Ada isn't really the right vehicle for
it since it's not realtime and it runs on big computers, so it can use
garbage collection and simpler verification techniques than Ada uses.
But it's IMHO still of extreme interest to people wanting to write code
with high-end correctness assurance. The ohnoyoudon't link I gave can
be seen as a stepping-stone to those methods.