Development process in the Ada community

Development process in the Ada community

[Michael Erdmann]

Hallo all,

i am wondering how standards are eveloving in the Ada community.
In the Java Community there is a process called Java Community
Process (JCP, http://www.jcp.org/)

Is there something comparabel in the Ada communitiy? I gues
if there would be something like this there would be more
dynamic in the Ada 95 community.


Regards
   M.Erdmann

Re: Development process in the Ada community

[Randy Brukardt]

Michael Erdmann wrote in message <3CB46975.90408@snafu.de>...
>Hallo all,
>
>i am wondering how standards are eveloving in the Ada community.
>In the Java Community there is a process called Java Community
>Process (JCP, http://www.jcp.org/)
>
>Is there something comparabel in the Ada communitiy? I gues
>if there would be something like this there would be more
>dynamic in the Ada 95 community.

I'm not sure if this answers your question...

The standard for the Ada Programming Language (and a variety of related
standards) are managed by ISO/IEC JTC1 SC22 WG9
(http://wwwold.dkuug.dk/JTC1/SC22/WG9/). Because these are ISO
standards, WG9 has to follow the procedures for creating ISO standards.

Most of the actual work of fixing and improving the language standard
occurs in a subcommittee of WG9 known as the ARG (Ada Rappetour Group).
The ARG membership includes a wide variety of Ada vendors and users.
Pretty much all that is required to informally monitor the process is to
join the Ada-Comment mailing list (see
http://www.adaic.org/standards/articles/comment.html.) You can look into
the ARG's web site at http://www.ada-auth.org/ais.html (although that
site is designed to be functional, not to impress people with our
process).

                      Randy Brukardt
                      Editor, ISO/IEC JTC1 SC22 WG9 ARG

Re: Development process in the Ada community

[Michael Erdmann]

Randy Brukardt wrote:
> Michael Erdmann wrote in message <3CB46975.90408@snafu.de>...
> 
>>Hallo all,
>>
>>i am wondering how standards are eveloving in the Ada community.
>>In the Java Community there is a process called Java Community
>>Process (JCP, http://www.jcp.org/)
>>
>>Is there something comparabel in the Ada communitiy? I gues
>>if there would be something like this there would be more
>>dynamic in the Ada 95 community.
>>
> 
> I'm not sure if this answers your question...
> 
> The standard for the Ada Programming Language (and a variety of related
> standards) are managed by ISO/IEC JTC1 SC22 WG9
> (http://wwwold.dkuug.dk/JTC1/SC22/WG9/). Because these are ISO
> standards, WG9 has to follow the procedures for creating ISO standards.

> Most of the actual work of fixing and improving the language standard
> occurs in a subcommittee of WG9 known as the ARG (Ada Rappetour Group).
> The ARG membership includes a wide variety of Ada vendors and users.
> Pretty much all that is required to informally monitor the process is to
> join the Ada-Comment mailing list (see
> http://www.adaic.org/standards/articles/comment.html.) You can look into
> the ARG's web site at http://www.ada-auth.org/ais.html (although that
> site is designed to be functional, not to impress people with our
> process).

Thanks, yes this answers my question.

I personally think this way of working is fairly outdated since
it does not realy take the internet as a comminication media into
accout.
If you compare Ada 95 with Java, then the interesting points are
not the languages it self, but the quick development of supporting
components around it. If you take Ada 95 there is only a very
limited set of predefined libraries standarized and thats it,
nothing else. With JPC this is completly different!

What i like to say it that not the language Ada is the illness,
but the process around it which does not generate the dynamic
as i would expect it from a language which is a live.

Have there any attempts made to change the process towards a more
dynmaic way of working?

Regards
    M.Erdmann


> 
>                       Randy Brukardt
>                       Editor, ISO/IEC JTC1 SC22 WG9 ARG
> 
> 
> 
> 
> 

Re: Development process in the Ada community

[Petter Fryklund]

would you really have that dynamic or would you like proven stability in the
aircraft you're travelling with ;-)

Re: Development process in the Ada community

[Eric G. Miller]

In <3CB516E1.9030008@snafu.de>, Michael Erdmann wrote:

> I personally think this way of working is fairly outdated since
> it does not realy take the internet as a comminication media into
> accout.
> If you compare Ada 95 with Java, then the interesting points are
> not the languages it self, but the quick development of supporting
> components around it. If you take Ada 95 there is only a very
> limited set of predefined libraries standarized and thats it,
> nothing else. With JPC this is completly different!

How many changes in the Java language have occurred in the last ten
years?  How many are fully backwards compatible?  Java aims to be
a whole platform, but it's a moving target.  What about developers
who want their libraries and programs to be relevant for more than
a couple years?  IMHO, rapidly changing languages present a double 
edged sword.  

I think the goals of the two languages are somewhat orthogonal. I
don't think there will ever be a "one size fits all" language.  
The safety and security features of Ada are very important to
some folks, for instance. 

Oh, btw, this "outdated mode" of standardization is one thing that
drew me to start using Ada vs. something like Java [tm], which is
owned by Sun.

Re: Development process in the Ada community

[Martin Dowie]

> I personally think this way of working is fairly outdated since
> it does not realy take the internet as a comminication media into
> accout.
> If you compare Ada 95 with Java, then the interesting points are
> not the languages it self, but the quick development of supporting
> components around it. If you take Ada 95 there is only a very
> limited set of predefined libraries standarized and thats it,
> nothing else. With JPC this is completly different!
> 
> What i like to say it that not the language Ada is the illness,
> but the process around it which does not generate the dynamic
> as i would expect it from a language which is a live.
> 
> Have there any attempts made to change the process towards a more
> dynmaic way of working?

I work in avionics but not in any safety related work just now. In
our developments such things as standard Directory & Socket packages
(and a few others queues, lists etc) would be a great boon.

Has any progress/agreement been made on the work to generate a 'standard'
Directory package?

Standard "Interfaces.Java" & "Interfaces.CPP" would be _very_ usefull too.

Re: Development process in the Ada community

[Jim Rogers]

Michael Erdmann wrote:

> If you compare Ada 95 with Java, then the interesting points are
> not the languages it self, but the quick development of supporting
> components around it. If you take Ada 95 there is only a very
> limited set of predefined libraries standarized and thats it,
> nothing else. With JPC this is completly different!
> 
> What i like to say it that not the language Ada is the illness,
> but the process around it which does not generate the dynamic
> as i would expect it from a language which is a live.


Let's look at recent results of JPC efforts.

j2sdk1.4.0 contains a new package java.nio. This package
attempts to provide high performance I/O for Java. It provides
direct access to a unix-like select command, as well as
memory-mapped files, explicit buffers, and character
translation. The "n" in "nio" stands for "new". This is a
terrible name for a package. Beyond that quibble is the fact
that this package seriously violates one of the foundation
principles of the Java language. Java has always advertised the
concept of "write once, run anywhere". One consequence of this
goal is that Java could not support OS specific behavior, since
that behavior could not be implemented anywhere. The java.nio
package abandons that goal and implements I/O features not found
on all OS platforms. It also provides an I/O model which is
incompatible with the I/O defined in the java.io package.

This is an example of rapid change without regard to its effect on
the overall language principles. I do not want to see such rapid
development results applied to Ada.

Jim Rogers

Re: Development process in the Ada community

[Marin David Condic]

I would agree that there needs to be stability around what might be called
the "core" language. Certainly the 13 chapters of the ARM and possibly
around the appendices as well. (Although I think it might be a benefit to be
able to add to the appendices a little more easily to gain language
extension without undue instability for the compiler writers.)

But to look at Java and ask "what's good about what they are doing?" is
important as well. Having a large library of support code that works to
create a whole portable development environment might just be A Good Thing.
Perhaps if the Ada standard process found a way of talking about "standard"
libraries and incorporating them into the Ada language in some kind of
semi-official way (with undue burdens or delays) it might help Ada find
wider acceptance through the leverage it would offer to developers.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Eric G. Miller" <egm2@jps-nospam.net> wrote in message
news:pan.2002.04.11.01.38.30.887865.26212@jps-nospam.net...
>
> How many changes in the Java language have occurred in the last ten
> years?  How many are fully backwards compatible?  Java aims to be
> a whole platform, but it's a moving target.  What about developers
> who want their libraries and programs to be relevant for more than
> a couple years?  IMHO, rapidly changing languages present a double
> edged sword.
>
> I think the goals of the two languages are somewhat orthogonal. I
> don't think there will ever be a "one size fits all" language.
> The safety and security features of Ada are very important to
> some folks, for instance.
>
> Oh, btw, this "outdated mode" of standardization is one thing that
> drew me to start using Ada vs. something like Java [tm], which is
> owned by Sun.

Re: Development process in the Ada community

[Michael Erdmann]

Petter Fryklund wrote:
> would you really have that dynamic or would you like proven stability in the
> aircraft you're travelling with ;-)
>

I am not talking about the language, but more about the development
environment, e.g. POSIX Interface, Data Base Interfaces and other
components.  I feel all these things have been thought about along
time ago, there are some standards (Mainly MIL ..ISO) out there,
but they are old and outdated. This what i mean by mssing dynamic.

A more public process might lead to more publicity, more up to date
standards which are maintained not only by a advocatic community
like ANSI, ITU or what so ever! There for i find the idea of the
JCP quite interesting and something to think about in the
Ada community.

Regards
    M.Erdmann

Re: Development process in the Ada community

[Michael Erdmann]

Jim Rogers wrote:
> Michael Erdmann wrote:
> 
>> If you compare Ada 95 with Java, then the interesting points are
>> not the languages it self, but the quick development of supporting
>> components around it. If you take Ada 95 there is only a very
>> limited set of predefined libraries standarized and thats it,
>> nothing else. With JPC this is completly different!
>>
>> What i like to say it that not the language Ada is the illness,
>> but the process around it which does not generate the dynamic
>> as i would expect it from a language which is a live.
> 
> 
> 
> Let's look at recent results of JPC efforts.
> 
> j2sdk1.4.0 contains a new package java.nio. This package
> attempts to provide high performance I/O for Java. It provides
> direct access to a unix-like select command, as well as
> memory-mapped files, explicit buffers, and character
> translation. The "n" in "nio" stands for "new". This is a
> terrible name for a package. Beyond that quibble is the fact
> that this package seriously violates one of the foundation
> principles of the Java language. Java has always advertised the
> concept of "write once, run anywhere". One consequence of this
> goal is that Java could not support OS specific behavior, since
> that behavior could not be implemented anywhere. The java.nio
> package abandons that goal and implements I/O features not found
> on all OS platforms. It also provides an I/O model which is
> incompatible with the I/O defined in the java.io package.
> 
> This is an example of rapid change without regard to its effect on
> the overall language principles. I do not want to see such rapid
> development results applied to Ada.
> 
> Jim Rogers
> 
I agree on this, may be they are a litle bit to fast, but i think
Ada is i little bit to slow. Such things are happening in all kinds
of instituations. But what i like to emphesze here the fact, that
there IS A PROCESS (which might be missused as well) which is
more public then ISO or ANSI. I think this is  very important
since the Ada communitiy does not consist only of developers doing
brain surgery on atomic missiles but also on a lot of developers
in smaller project which are using Ada 95 as well. To get these
people in the process via the net would be a great achievement!

Regards
    M.Erdmann

Re: Development process in the Ada community

[Michael Erdmann]

Martin Dowie wrote:
>>I personally think this way of working is fairly outdated since
>>it does not realy take the internet as a comminication media into
>>accout.
>>If you compare Ada 95 with Java, then the interesting points are
>>not the languages it self, but the quick development of supporting
>>components around it. If you take Ada 95 there is only a very
>>limited set of predefined libraries standarized and thats it,
>>nothing else. With JPC this is completly different!
>>
>>What i like to say it that not the language Ada is the illness,
>>but the process around it which does not generate the dynamic
>>as i would expect it from a language which is a live.
>>
>>Have there any attempts made to change the process towards a more
>>dynmaic way of working?
>>
> 
> I work in avionics but not in any safety related work just now. In
> our developments such things as standard Directory & Socket packages
> (and a few others queues, lists etc) would be a great boon.
There is a POSIX based package available (florist) and adasockets
from S. Tardieu but they are not part of the Ada predefined packages.
It is a pitty.

> 
> Has any progress/agreement been made on the work to generate a 'standard'
> Directory package?
> 
> Standard "Interfaces.Java" & "Interfaces.CPP" would be _very_ usefull too.
> 

Re: Development process in the Ada community

[Michael Erdmann]

Eric G. Miller wrote:
> In <3CB516E1.9030008@snafu.de>, Michael Erdmann wrote:
> 
> 
>>I personally think this way of working is fairly outdated since
>>it does not realy take the internet as a comminication media into
>>accout.
>>If you compare Ada 95 with Java, then the interesting points are
>>not the languages it self, but the quick development of supporting
>>components around it. If you take Ada 95 there is only a very
>>limited set of predefined libraries standarized and thats it,
>>nothing else. With JPC this is completly different!
>>
> 
> How many changes in the Java language have occurred in the last ten
> years?  How many are fully backwards compatible?  Java aims to be
> a whole platform, but it's a moving target.  What about developers
> who want their libraries and programs to be relevant for more than
> a couple years?  IMHO, rapidly changing languages present a double 
> edged sword.  
> 
> I think the goals of the two languages are somewhat orthogonal. I
> don't think there will ever be a "one size fits all" language.  
> The safety and security features of Ada are very important to
> some folks, for instance. 
> 
> Oh, btw, this "outdated mode" of standardization is one thing that
> drew me to start using Ada vs. something like Java [tm], which is
> owned by Sun.
> 


I am not saying that the old style of standarization make no
sense any more. In the contrary, the core of a lagnuage should
alwys be done like this (i guess), but the situation was as i
remember that Ada development has been founded by gouvermental
organizations, which has changed in the last years.

My argument is not the language it self, but the environment
around it, it should take the fact into account, that there
is a strong open source movement which has to be chanelized
some how by providing a public process which leads to open source
standards.

Regards
    M.Erdmann

Re: Development process in the Ada community

[Ted Dennison]

Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3CB583D6.9000104@worldnet.att.net>...
> principles of the Java language. Java has always advertised the
> concept of "write once, run anywhere". One consequence of this
> goal is that Java could not support OS specific behavior, since
> that behavior could not be implemented anywhere. The java.nio
> package abandons that goal and implements I/O features not found
> on all OS platforms. It also provides an I/O model which is
> incompatible with the I/O defined in the java.io package.
> 
> This is an example of rapid change without regard to its effect on
> the overall language principles. I do not want to see such rapid
> development results applied to Ada.

Java's Swing is another good example of this. AWT was found inadaquate
as a GUI toolkit, so they just kept it and started over from scratch
with Swing. But lots of old code uses AWT, so it can't go away.
Instead you now have the new standard GUI and the old stardard GUI,
left in as a trap for the unwary.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Marin David Condic]

"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
news:3CB5BED1.3090702@snafu.de...
> There is a POSIX based package available (florist) and adasockets
> from S. Tardieu but they are not part of the Ada predefined packages.
> It is a pitty.
>

Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It
might even impose a layer on top that provided a whole Ada-ish look and feel
to the endeavor, rather than being just a thin binding.

A few things like this could go quite far in improving portable development
life by getting an OS-independent view of common services. (With the usual
stipulation that an implementation need not provide it at all, but if it
does, it will have this interface.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Development process in the Ada community

[Michael Erdmann]

Ted Dennison wrote:
> Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3CB583D6.9000104@worldnet.att.net>...
> 
>>principles of the Java language. Java has always advertised the
>>concept of "write once, run anywhere". One consequence of this
>>goal is that Java could not support OS specific behavior, since
>>that behavior could not be implemented anywhere. The java.nio
>>package abandons that goal and implements I/O features not found
>>on all OS platforms. It also provides an I/O model which is
>>incompatible with the I/O defined in the java.io package.
>>
>>This is an example of rapid change without regard to its effect on
>>the overall language principles. I do not want to see such rapid
>>development results applied to Ada.
>>
> 
> Java's Swing is another good example of this. AWT was found inadaquate
> as a GUI toolkit, so they just kept it and started over from scratch
> with Swing. But lots of old code uses AWT, so it can't go away.
> Instead you now have the new standard GUI and the old stardard GUI,
> left in as a trap for the unwary.
> 
> 
But is there any move in the Ada communitiy to standarize something
in the GUI domain?
Assume somebody would dare to try it, how could she/he
achieve this?

I never said that i like the stuff java is made of, but at least
they are trying and consequently they are also failing! This is
something i am missing in the Ada 95 comminuty.

If you look at comp.lang.ada, you can break up the post in three
categories:

- Help Queries, how to do put_line ,
- My language is bettern then yours
- Release note to the community

But there only a small number of attempts made to establish some
common understanding of a cetrain interface (which is a defacto
standard) and afterwards setting up a project implementing it.

You find the same behavior in the comp.lang.java groups,but
at least they have something like the JCP, and not to forget
SUN, to evelove (defacto) standards.
 From my perspective this is all missing in the Ada community.

Regards
    M.Erdmann

Re: Development process in the Ada community

[Randy Brukardt]

Martin Dowie wrote in message ...
>Has any progress/agreement been made on the work to generate a
'standard'
>Directory package?

See AI-248 http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00248.TXT I
keep hoping that the ARG will stop tinkering with it, but so far I've
been disappointed. But I think it is pretty stable now. But we need to
get compiler implementors to implement it...

(Since it is a child of Ada, you can't do it yourself without some help
from your compiler vendor -- compiling such a package is illegal by
A.2(4).)

               Randy.

Re: Development process in the Ada community

[Randy Brukardt]

Michael Erdmann wrote in message <3CB5D550.4000201@snafu.de>...
>But is there any move in the Ada communitiy to standarize something in
the GUI domain?
>Assume somebody would dare to try it, how could she/he achieve this?

That was the original idea behind Claw (in th 1996/7 timeframe). The
idea was to create a de-facto standard, make a subset freely available,
and eventually put the binding into the public domain to be a standard.

However, it didn't work, because hardly anyone wanted to use it,
preferring to roll their own. So we have a large number of such
bindings.

That is not necessarily a bad thing, but it does prevent any of them
reaching a critical mass.

Ada seems to have divided into a formally standardized part, and a
completely informal part. But that's always been the case (look at all
of the X bindings that were made for Ada 83 in the 1980s), and probably
is part of the nature of things.

> You find the same behavior in the comp.lang.java groups,but
> at least they have something like the JCP, and not to forget
> SUN, to evelove (defacto) standards.
> From my perspective this is all missing in the Ada community.

I can imagine an "ACP" would be useful, but the question is, who is
going to pay for it? My experience as editor of the ARG is that getting
the paper-pushing done by volunteers is like herding cats. When the
budget allows, I often just do it myself. But writing standards is NOT
fun, so I'm not surprised that people don't do it. In any case, an "ACP"
would need someone to coordinate and enforce standards on the standards,
and that pretty much requires paid personel.

I'd like to be able to set up an internet process for secondary
standards (the subject has been discussed in WG9), but it obviously
would take an additional budget, and we're short on money (for work on
the Amendment - "Ada 0y") as it is.

                Randy.

Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:

> i am wondering how standards are eveloving in the Ada community.
> In the Java Community there is a process called Java Community
> Process (JCP, http://www.jcp.org/)

> Is there something comparable in the Ada communitiy? I guess
> if there would be something like this there would be more
> dynamic in the Ada 95 community.

You have put your finger, probably, on the cause of the US Military's
collapse on the issue of an Ada Mandate in the face of programmer
intransigence to use Ada among the military community, in the answers
you have received.

The love of doing things one rigid way, with all decisions handed down
from above, ran square into the software development community, which is
used to speedy and flexible growth in its tools.

Probably Ada was doomed to be the Horse Cavelry of programming languages
the day its language standardization process was chosen, and I'm afraid
you are going to find no cure for what is basically an incurable
attitude problem of an entire, isolated programming community.

Like Steven Jay Gould's "allopatric demes", Ada, brought back to cross
fertilize with other programming languages and their newly invented
mechanisms, might have provided hybrid vigor and a new, more competitive
product.

Instead you see what you see:

"Why should we want a superior graphics interface to replace an inferior
one, while maintaining the old one so as not to break old code?"

"Why should the new developments become _part of the language_?"

"Who needs a standard OS calling interface _in the language_?"

"We don't need no stinking programming community inputs to the
language!"

"Procedure for change?  We want stability, stability, stability!"

[The Kaiser's army had stability; programming as a task by definition
does not.]

ad infinitum.

No wonder the military programming community dragged heels until DoD
caved.

I was _really_ excited when Ada came out -- Pascal readability, but with
power!

I am no longer thrilled.

Where are the parallel processing features _in the language_, the robust
and powerful string parsing features _in the language_, the "programming
by contract" features _in the language_, the standard higher level math
libraries _in the language_, knowledge representation _in the langauge_,
 the SEI CMM model turned directly into a _standard_IDE _in the
language_, the standard DoD and telecom community communication
protocols, all _in the language_?

When do the mind-bogglingly complex bogosities get ditched:
_decimal_ specification of sizes for _binary_ data containers!!!

Give me a break.

"Progress, keeping up with community standards, is for other people!"

Give me a break.

Sigh.  So much promise, so small a result.  Given a complete community
feedback loop and about a hundred times faster language change response
time, Ada could be everyone's programming language of choice today.

Java, alive for about 7 years, is due imminently for its fifth major
release.  That still doesn't guarantee its survival; Sun has an
incurable attitude problem toward making Java truly freeware, but it
does help.  Ada doesn't even have a sponsor any more outside the
compiler vendor community, and I don't even see any visible signs of
public debate and motion toward a second much needed major overhaul and
upgrade for twenty year old Ada, just a few well hidden notes on some
standards committee web sites.

That comp.lang.ada isn't comp.lang.ada.* is a symptom of the whole
mindset problem.  Unitary Usenet discussion groups are very
characteristic of exactly one thing: _minor_ programming languages.

xanthian.

At least when I yelled at the Fortran standards folks back in 1987 or
so, they responded, and arguably saved their language from the dust-bin
as a result.  Here, the outlook is not so rosy.


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Development process in the Ada community

[Ted Dennison]

Michael Erdmann wrote:

> Ted Dennison wrote:
> 
>> Java's Swing is another good example of this. AWT was found inadaquate
>> as a GUI toolkit, so they just kept it and started over from scratch
>> with Swing. But lots of old code uses AWT, so it can't go away.
> But is there any move in the Ada communitiy to standarize something
> in the GUI domain?


Well..er..the Swing/AWT thing is actually *also* my archtypeal example 
of why its silly to even try to make a "standard" GUI. The argument 
surrounding it usually has to do with it being impossible to do 
everything everyone (or even a majority of everyone) wants to do with a GUI.

Re: Rant! (was) Development process in the Ada community

[tony]

I was a student in 1987 when there was no ada open source.

Ada in the military is a waste of Ada. A mix of a clearly understandable
language with clearly understandable perverse human objectives.

Open source with Ada however is a mixing of both write once and use
around the world components.

The amount of ada software now being produced open source amongst a
community with no set objectives, no set one way of thinking, no hidden
agenda, no management I think is astounding.

Doomed to the horse calvalry is just a bad analogy I think because,
Ada is doing very well in the open source community (against all odds)
which is the true test. 

The true test of technology is in the open source community and not in
the temporary distraction of the US military which appears to define the
success of its technology in how many third world people you can murder
or subjugate by pressing or not pressing a button.

Re: Rant! (was) Development process in the Ada community

[Chad R. Meiners]

"tony" <tonygair@btinternet.com> wrote in message
news:3CB61A78.271280C1@btinternet.com...

> The true test of technology is in the open source community and not in
> the temporary distraction of the US military which appears to define the
> success of its technology in how many third world people you can murder
> or subjugate by pressing or not pressing a button.

Please refrain from supporting global ignorance by relying on rhetoric to
persuade people.  Just because you believe something doesn't make it true,
and just because you say something over and over, also, doesn't make it
true.  If you care about the truth, you must carefully determine the truth
with logically valid methods.  In particular, please refrain from
encouraging the irrational hatred of organizations such as the US military.

Re: Rant! (was) Development process in the Ada community

[Pat Rogers]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:a95bdc$f67$1@msunews.cl.msu.edu...
>
> "tony" <tonygair@btinternet.com> wrote in message
> news:3CB61A78.271280C1@btinternet.com...
>
> > The true test of technology is in the open source community and not in
> > the temporary distraction of the US military which appears to define the
> > success of its technology in how many third world people you can murder
> > or subjugate by pressing or not pressing a button.
>
> Please refrain from supporting global ignorance by relying on rhetoric to
> persuade people.  Just because you believe something doesn't make it true,
> and just because you say something over and over, also, doesn't make it
> true.  If you care about the truth, you must carefully determine the truth
> with logically valid methods.  In particular, please refrain from
> encouraging the irrational hatred of organizations such as the US military.

Well said.

Re: Development process in the Ada community

[tmoran]

> Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It
> might even impose a layer on top that provided a whole Ada-ish look and feel
> to the endeavor, rather than being just a thin binding.
  I will modestly propose the Claw Ada-ish thick binding to sockets.
(A cut down, but still eminently usable, version is available for $0 at
www.rrsoftware.com).  A web server and a spider demonstrating it are
available on www.adapower.com (Smplsrvr and Finder).

Re: Development process in the Ada community

[Ingo Marks]

Michael Erdmann wrote:

> But is there any move in the Ada communitiy to standarize something
> in the GUI domain?

What about GtkAda?

http://libre.act-europe.fr/GtkAda/
http://www.gtk.org 

GTK is supported on many platforms (Unix, Win32, BeOS and even MacOSX, see 
http://www.apple.com/scitech/unixports).

Re: Rant! (was) Development process in the Ada community

[Ingo Marks]

Kent Paul Dolan wrote:

> Sigh.  So much promise, so small a result.  Given a complete community
> feedback loop and about a hundred times faster language change response
> time, Ada could be everyone's programming language of choice today.
> ...
> That comp.lang.ada isn't comp.lang.ada.* is a symptom of the whole
> mindset problem.  Unitary Usenet discussion groups are very
> characteristic of exactly one thing: _minor_ programming languages.
 
IMHO the major problems with Ada in the community are

- Who continues Ada compiler support in the future? Now we have some kind 
companies who provide good Ada compilers (commercial and for free). But 
someday they could say: "There is no more demand for commercial Ada so we 
have decided to stop further Ada support." What then? It is not enough to 
have a good dynamic Ada standardization process. It is also important to 
have continuing Ada compiler support in the future!

- Java and C# are much easier to learn. They are less expressive than Ada 
and suitable for small to medium projects. You can write software easier, 
shorter and faster - but more reliable? People have to know that Ada is 
pretty hard to learn (and you have to write more code) but makes your life 
easier afterwars (IMHO it's the same with Linux compared to Windows ;-). In 
bigger projects readibility of (self-commenting) code becomes a serious 
issue to consider. Studies show that development in Ada costs about half 
the time of development in C++. This is a quality of Ada that would make 
software developing companies curious surely if there would be a living Ada 
community and enough developers they could hire. I know that there _are_ 
companies out there who want to hire Ada developers but cannot find anyone. 
But they can get many Java developers so they decide to use Java in favor 
of Ada.

- Ada was not popular because a) it has the image of a 
general-purpose-"military only"-language and b) most Ada compilers were way 
too be expensive to be affordable for the normal (hobby) programmer who 
wants to learn and play with Ada. Since there are free Ada compilers for 
everyone, the interest for Ada has raised and will continue to raise. Of 
course, addons like GNU Visual Debugger and AdaGIDE make Ada more 
attractive. Michael Erdmann and others are right when they say Ada needs a 
general purpose standardization process. Some people in comp.lang.ada are 
right when they say a very good incentive to make Ada attractive to newbies 
would be an IDE with the feeling and power of Visual Studio .NET.

Could Ada have the same history as Unix?

I remember earlier years when the press said that Unix would be on the way 
to die surely and it would merely be a matter of years when Unix will be 
replaced by Windows completely. Then Linux and the Open Source movement 
rised and suddenly Unix (its modern variants Linux, BSD, MacOSX) become 
more and more popular. One reason for this is that the hardware was getting 
better and better and suitable to have Unix for everyone. 

In "ancient" years we had Cobol, Fortran, C and C++. In earlier years 
Visual Basic, Perl and PHP were very popular languages, but now more and 
more people realize that these languages are not suitable for bigger 
projects. That's why Java became popular. It's a polished version of C and 
C++ and requires little learning for C++ converts. MS realized the success 
of Java and decided to copy the Java framework and make their own version, 
together with C#, a polished version of Java. So for the last years we can 
see a "downgrade" from pretty complex popular languages like C and C++ to 
lightweight languages like PHP, VB etc., recently followed by an "upgrade" 
trend to more powerful languages (Java and C#). Several people are still 
not happy with Java and C#. They try other languages (Python, Ruby, 
functional languages). Here I see a chance for Ada to become more popular. 
Software becomes more and more complex, and this raising complexity is the 
area where readibility becomes more important and which Ada fits well.

Linux gained its success because of its good word-of-mouth recommendation. 
I think Ada needs the same.

Re: Rant! (was) Development process in the Ada community

[Larry Kilgallen]

In article <a96bou$fb5$02$1@news.t-online.com>, Ingo Marks <adv@region-nord.de> writes:

> - Who continues Ada compiler support in the future? Now we have some kind 
> companies who provide good Ada compilers (commercial and for free). But 
> someday they could say: "There is no more demand for commercial Ada so we 
> have decided to stop further Ada support." What then? It is not enough to 
> have a good dynamic Ada standardization process. It is also important to 
> have continuing Ada compiler support in the future!

And Microsoft could say that .NET was the wave of the future,
replacing COM, which had replaced DCOM, which had replaced
something whose name I forget.  Or Apple could drop support
for AOCE when they thought it unpopular.

Frankly I trust small companies much more than larger ones.

Claw thick bindings to sockets (was: Development process in the Ada..)

[Larry Kilgallen]

In article <DBtt8.902$Tm5.613040241@newssvr21.news.prodigy.com>, tmoran@acm.org writes:
>> Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It
>> might even impose a layer on top that provided a whole Ada-ish look and feel
>> to the endeavor, rather than being just a thin binding.
>   I will modestly propose the Claw Ada-ish thick binding to sockets.
> (A cut down, but still eminently usable, version is available for $0 at
> www.rrsoftware.com).  A web server and a spider demonstrating it are
> available on www.adapower.com (Smplsrvr and Finder).

That concept is interesting to me for a non-Microsoft operating
system, but when I look at www.rrsoftware.com I realize I need
guidance to find this.  I see links for GUI bindings, but not
anything for Unix-style IP sockets.  Where should I be looking ?

Re: Development process in the Ada community

[Larry Kilgallen]

In article <a9430o$ee2$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> But to look at Java and ask "what's good about what they are doing?" is
> important as well. Having a large library of support code that works to
> create a whole portable development environment might just be A Good Thing.

How many implementations of those standard libraries exist aside
from the Java bytecode engine ?

Re: Development process in the Ada community

[Marin David Condic]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:Cszsj+N+tOUp@eisner.encompasserve.org...
> In article <a9430o$ee2$1@nh.pace.co.uk>, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> writes:
>
> > But to look at Java and ask "what's good about what they are doing?" is
> > important as well. Having a large library of support code that works to
> > create a whole portable development environment might just be A Good
Thing.
>
> How many implementations of those standard libraries exist aside
> from the Java bytecode engine ?

Isn't it more than what Ada has?

Java may not be producing really good standards with lots of conformant
implementations, but it does come with class libraries that do a lot of
things for the programmer. Ada (as a standard) comes with some math and
string stuff and some bindings to other things and what else? Specific
vendors may supply more stuff (and then you start approaching
copmpetitiveness with MFC - a vendor and platform specific library) but
wouldn't it be better to have some kind of pseudo-standard collection of
classes that go along with the language and do a bunch of work for the
developer?

All the arguments about Ada being "better" than one or more other languages
fall below the noise floor if it can't offer the developmental leverage you
get with some other language & its libraries.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Development process in the Ada community

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:3CB60E57.9090306@telepath.com...
>
> Well..er..the Swing/AWT thing is actually *also* my archtypeal example
> of why its silly to even try to make a "standard" GUI. The argument
> surrounding it usually has to do with it being impossible to do
> everything everyone (or even a majority of everyone) wants to do with a
GUI.
>
It always will be impossible so long as there exists two or more GUI
platforms that look & feel different. But that doesn't mean that something
couldn't be done anyway.

It could go a couple of ways. One would be to say "Here's a minimal
conforming set of classes that do GUI work in such a way as to be a
least-common-denominator across some reasonably wide set of platforms. That
part is 'Standard' and implementations are allowed to Embrace&Extend with
the programmer being warned about portability."

Another way to do it would be to just simply define an Ada-GUI that is its
own thing. With a graphics engine and a markup language based on XML and the
ability to interface to it, you're basically there.If the building blocks
are in place, it just becomes its own environment (like Windows or Motif or
whatever) and thats what you build your apps to. Not everyone will like it
but then not everyone likes HTML-ish/Java-ish stuff they use via Netscape or
IE. (Yet still, they use it!)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Development process in the Ada community

[Ted Dennison]

Ingo Marks <adv@region-nord.de> wrote in message news:<a9666p$euv$06$1@news.t-online.com>...
> Michael Erdmann wrote:
> 
> > But is there any move in the Ada communitiy to standarize something
> > in the GUI domain?
> 
> What about GtkAda?
> 
> http://libre.act-europe.fr/GtkAda/
> http://www.gtk.org 
> 
> GTK is supported on many platforms (Unix, Win32, BeOS and even MacOSX, see 
> http://www.apple.com/scitech/unixports).

A very good point. I'd go so far as to say that GtkAda is the closest
thing we have, and likely the closest thing we will ever have, to a
standard Ada GUI.

I use it for anything that isn't going to be OS-specific. But if you
are OS-specific you are going to want to use the OS's standard GUI, so
that everything looks and behaves the way the user expects. That's one
of the main reasons why you really can't make one "standard" GUI for
everyone.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Rant! (was) Development process in the Ada community

[Ted Dennison]

tony <tonygair@btinternet.com> wrote in message news:<3CB61A78.271280C1@btinternet.com>...
> I was a student in 1987 when there was no ada open source.
> 
> Open source with Ada however is a mixing of both write once and use
> around the world components.
> 
> The amount of ada software now being produced open source amongst a
> community with no set objectives, no set one way of thinking, no hidden
> agenda, no management I think is astounding.
> 
> Doomed to the horse calvalry is just a bad analogy I think because,
> Ada is doing very well in the open source community (against all odds)
> which is the true test. 

Hear, Hear!

> The true test of technology is in the open source community and not in
> the temporary distraction of the US military which appears to define the
> success of its technology in how many third world people you can murder
> or subjugate by pressing or not pressing a button.

(sits back down) Errr...no. This argument is the moral equivalent of
someone saying that all Palestinians are heartless murdering
terrorists or all Jews are .... (on second though, I don't even want
to go into this).

I'm not saying that if you had toned this statement back a bit, you
wouldn't have had half a point. But, there is way too much hatred,
half-truths, and willful ignorance in the world already. If we truly
care about peace, we need to be trying with all our might right now to
fight it, not spread more of it.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Georg Bauhaus]

Ted Dennison <dennison@telepath.com> wrote:
 
: I use it for anything that isn't going to be OS-specific. But if you
: are OS-specific you are going to want to use the OS's standard GUI, so
: that everything looks and behaves the way the user expects. That's one
: of the main reasons why you really can't make one "standard" GUI for
: everyone.

And not even on one OS one grand unified GUI makes sense in all
cases. Look at Photoshop's control windows, Framemaker has deviations
that I don't want to miss, and so on. I think it is really a pity
that supposedly standard "controls" are available at all, because
this essentially stops UI developement towards applications that are
really integrated into the OS. No need to build standard windows into
your aplications, instead leave that to the OS!
MS is doing a good job of
slowly leading Windows GUI users (and developers!) towards what is 
already there, but rarely used:
Ever noticed that you can use the container window that appears after
"select Menu, chose File Open" much the same way you can use a very similar 
window outside applications, employing drag&drop, creating resources, 
deleting files, ...?
Why on earth are there file open dialogs in a _G_UI?

- georg

Re: Rant! (was) Development process in the Ada community

[Georg Bauhaus]

Chad R. Meiners <crmeiners@hotmail.com> wrote:

: If you care about the truth, you must carefully determine the truth
: with logically valid methods.

With consideration, o.K., but uhm, logically valid methods, leading to the
truth...  isn't that one of the beliefs of the years before a 1936
publication? And determining worldly facts is perhaps at least
intractable, outside clerical reasoning. Still one might at least consider.

Re: Rant! (was) Development process in the Ada community

[Florian Weimer]

Ingo Marks <adv@region-nord.de> writes:

> - Who continues Ada compiler support in the future? Now we have some kind 
> companies who provide good Ada compilers (commercial and for free). But 
> someday they could say: "There is no more demand for commercial Ada so we 
> have decided to stop further Ada support."

If there is no commercial demand (and no demand in the Free Software
community either), then you are not using Ada.  What's the problem?

> I remember earlier years when the press said that Unix would be on the way 
> to die surely and it would merely be a matter of years when Unix will be 
> replaced by Windows completely.

A large problem in the UNIX community was (and still is) vendor
fragmentation.  There are at least three proprietary general-purpose
UNIX implementations which are used widely.  We have seen a lot of
convergence, but there are still problems.  I hope this is not the way
ahead of Ada!

> MS realized the success of Java

What "success of Java" are you talking about?  Hardly anybody is using
Java in areas it was originally marketed for.

> Here I see a chance for Ada to become more popular. 

Scripting languages like Perl and PHP encourage a development model
which is mostly incompatible with Ada.  I don't think many scripting
language enthusiasts can be converted to Ada.

Re: Claw thick bindings to sockets (was: Development process in the Ada..)

[tmoran]

> > > Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It
> > > might even impose a layer on top that provided a whole Ada-ish look and feel
> > > to the endeavor, rather than being just a thin binding.

> >   I will modestly propose the Claw Ada-ish thick binding to sockets.
> > (A cut down, but still eminently usable, version is available for $0 at
> > www.rrsoftware.com).  A web server and a spider demonstrating it are

> ... but when I look at www.rrsoftware.com I realize I need
> guidance to find this.  I see links for GUI bindings, but not
> anything for Unix-style IP sockets.  Where should I be looking ?
  Under "What's New" on the top right, click on "Claw Introductory Edition
Available", then "Download Claw Now", or, directly
www.rrsoftware.com/html/companyinf/news.html#clawintro
  Note that the spec is what I'm modestly proposing.  The body at that web
site runs on Windows.  I don't know of anything in the spec that would
make it less suitable for a Unix implementation.

RE: Rant! (was) Development process in the Ada community

[Mário Amado Alves]

"Scripting languages like Perl and PHP encourage a development model
which is mostly incompatible with Ada." (Florian)

Do you mean the "write once never read" attribute of PERL (and likely of
PHP as well) i.e.  maintainability, short vs. long lived applications?
How about when the requirements configure a short life span in the first
place (as it is often the case today)?

--MAA

Re: Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Florian Weimer" <fw@deneb.enyo.de> wrote:

> What "success of Java" are you talking about?  Hardly anybody is using
> Java in areas it was originally marketed for.

Umm, which is why MS tried so hard to sabotage it and create a version
locked to MS-Windows that it took a court order to break up their little
game?  I think your view of reality is flawed here.

> Scripting languages like Perl and PHP encourage a development model
> which is mostly incompatible with Ada.  I don't think many scripting
> language enthusiasts can be converted to Ada.

You must not use them much, then.  Scripting languages are "glue"
languages, used to put software written in other languages into
compatibly working clusters.  In particular, Larry Wall created PERL to
be a glue language.

http://www.salon.com/21st/feature/1998/10/cov_13feature.html

I cannot imagine the particular choice of programming language
determining the development model.  You can go SEI CMM level 5 in PERL,
Ada, Logo, or any other programming language; the development model is
pretty much an orthogonal issue to the choice of programming language.
I will grant that one can _also_ use PERL to "hack out a quick
solution", but then, that's what it's intended to be, a multi-pronged
tool for getting to the needed result with low pain and high speed.

I refused to learn PERL (line noise incarnate to the uninitiated) until
long after I learned Ada.  Then I finally used PERL, and regretted the
six years I had pushed it aside.

I'd just like to see Ada pick up some of the really nifty features of
PERL, but then I'd like to see all of my programming languages (all nine
or ten dozen, but I've forgotten most of them by now, luckily, or my
poor head would have exploded) do the same.  There isn't a programming
language alive that couldn't use  PERL's parsing power.

Somewhere off this thread with a broken references pointer is a remark
that PERL is a "write once, read never" language, or some such.  Not so.
Like C, like APL, PERL is a "takes time to learn" language.  Once you
get into it, its sheer beauty and economy of expression will amaze you;
it was, after all, designed by a guy with his undergraduate training in
linguistics.

PERL, whether you buy the "Practical Extraction and Report-writing
Language" which is the official version, or the creator's
"Pathologically Eclectic Rubbish Lister", is a tool any professional
programmer wants in his or her toolkit.

Meanwhile, getting back on topic, it is exactly this concept that Ada
has some sacred development model that seems to be paralyzing
improvements in Ada as a programming language, and impoverishing Ada as
a programming community.  Development models are not programming
languages, nor does improving a language damage a development model!

xanthian.


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

--off topic Re: Rant! (was) Development process in the Ada community

[tony]

"Chad R. Meiners" wrote:
> 
> Please refrain from supporting global ignorance by relying on rhetoric to
> persuade people. 

In my bit to reduce global ignorance, I have looked up the following big
words RELYING on the Oxford Dictionary, that you used.

Rhetoric :- Art of presenting words impressively

Thanks Chad. I didn't realise you were impressed.

Repeated :- occurred more than once. 

I did not repeat myself.

Ignorance :- lack of knowledge. 

For example not knowing the meaning of the words you write.



>> Just because you believe something doesn't make it true,
> and just because you say something over and over, also, doesn't make it
> true.

Gee thanks Grandma, can you tell me the truth now......

>>  If you care about the truth, you must carefully determine the truth
> with logically valid methods.

In your post you implied that I was ignorant and now you imply I am
lying. You are hereby strucken from my christmas card list.

>>  In particular, please refrain from
> encouraging the irrational hatred of organizations such as the US military.

Critiscism is not irrational hatred. What irrational Hatred am I
encouraging? Does critiscism make me a Terrorist. The use and supply of
weapons against civilians to further my ends in the world would be
irrational hatred and terrorist. 

Bombing, strafing and the murder of unarmed civilian crowds in Somalia
(The author of blackhawk down describes this in his book) is Irrational
hatred and more. Opposing the design and production of satanic devices
that make this possible is NOT irrational hatred, it is a logical valid
method to oppose people who betray Humanity.

Re: Rant! (was) Development process in the Ada community

[Wes Groleau]

> Where are the parallel processing features _in the language_, the robust
> and powerful string parsing features _in the language_, the "programming
> by contract" features _in the language_, the standard higher level math
> libraries _in the language_, knowledge representation _in the langauge_,
>  the SEI CMM model turned directly into a _standard_IDE _in the
> language_, the standard DoD and telecom community communication
> protocols, all _in the language_?

Many of your complaints have some merit.  This one however,
can be applied to any language today.  How many languages
have TWO of these features?  Ada at least has one and it
would have two if concurrency were added to the list.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Claw thick bindings to sockets (was: Development process in the Ada..)

[Larry Kilgallen]

In article <CJEt8.4033$p91.2051578013@newssvr14.news.prodigy.com>, tmoran@acm.org writes:
>> > > Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It
>> > > might even impose a layer on top that provided a whole Ada-ish look and feel
>> > > to the endeavor, rather than being just a thin binding.
> 
>> >   I will modestly propose the Claw Ada-ish thick binding to sockets.
>> > (A cut down, but still eminently usable, version is available for $0 at
>> > www.rrsoftware.com).  A web server and a spider demonstrating it are
> 
>> ... but when I look at www.rrsoftware.com I realize I need
>> guidance to find this.  I see links for GUI bindings, but not
>> anything for Unix-style IP sockets.  Where should I be looking ?
>   Under "What's New" on the top right, click on "Claw Introductory Edition
> Available", then "Download Claw Now", or, directly
> www.rrsoftware.com/html/companyinf/news.html#clawintro

Ok, that gives me prose, with some links to a page with choices based
on Windows compilers.  Is there any way to see just the specification ?

>   Note that the spec is what I'm modestly proposing.  The body at that web

Right now the licensing terms in the prose limit one to 30 days use.
Are there plans to ease that license for the IP socket specification ?

> site runs on Windows.  I don't know of anything in the spec that would
> make it less suitable for a Unix implementation.

I guess when I wrote "Unix-style IP sockets" I should have said
BSD-style IP sockets.  My interest is not for Unix, but I think
of that arcane interface used in C as being Unix-style.

Re: Rant! (was) Development process in the Ada community

[Chad R. Meiners]

With logically valid methods of reasoning, you must clearly distinguish that
which you must assume (such as your reasoning axioms and your 'facts') from
that which you prove.  It is true that the power of logical reasoning is
limited via Godel's proof, but this is never an excuse for allowing logical
fallacies into any argument.  Logic is still our best defense against the
exploitation of ignorance and false conclusions.  So even though we may not
be able to enumerate all the truths of the universe, we can and should use
logical reasoning; we simply must accept that there are some things that we
cannot know.


"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a9704r$6ql$1@a1-hrz.uni-duisburg.de...
> Chad R. Meiners <crmeiners@hotmail.com> wrote:
>
> : If you care about the truth, you must carefully determine the truth
> : with logically valid methods.
>
> With consideration, o.K., but uhm, logically valid methods, leading to the
> truth...  isn't that one of the beliefs of the years before a 1936
> publication? And determining worldly facts is perhaps at least
> intractable, outside clerical reasoning. Still one might at least
consider.

Re: Rant! (was) Development process in the Ada community

[tony]

You're right Ted, but my blood goes all curdled and I transform into a
troll when I hear Ada being bad mouthed, the rest (although heartfelt)
just poured from that.
I will have more tolerance in the future, and I will shut up about my
politics.

Re: Claw thick bindings to sockets (was: Development process in the Ada..)

[tmoran]

> on Windows compilers.  Is there any way to see just the specification ?
  Just download and unzip from any one of the versions.  The whole thing
is under 500K, IIRC, so that's not too onerous these days.  The file name
for the socket spec will be either claw-sockets.ads or claw_soc.ads,
depending on compiler and file naming convention.  That version of
Claw doesn't have the Help or HTML docs (about 10MB last I looked)
so I'm afraid you'll have to look at the source code.

> Right now the licensing terms in the prose limit one to 30 days use.
  For commercial use.  Unlimited for personal use.
> Are there plans to ease that license for the IP socket specification ?
  I certainly would have no problem and, given what he said here just
the other day, I really doubt Randy Brukardt would have any problem
with making it public domain or whatever.

> I guess when I wrote "Unix-style IP sockets" I should have said
> BSD-style IP sockets.  My interest is not for Unix, but I think
> of that arcane interface used in C as being Unix-style.
  Yes.

Re: Rant! (was) Development process in the Ada community

[tmoran]

> > - Who continues Ada compiler support in the future? Now we have some kind
> > companies who provide good Ada compilers (commercial and for free). But
> ...
> Frankly I trust small companies much more than larger ones.
  Once upon a time a lot of companies bought RCA mainframes instead of
IBM, sure in the knowledge that RCA wasn't going to go out of business.
Similarly that well known large PC maker, Texas Instruments.

Re: Development process in the Ada community

[tony]

Marin David Condic wrote:
> 
> Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It
> might even impose a layer on top that provided a whole Ada-ish look and feel
> to the endeavor, rather than being just a thin binding.
> 

There is the distributed annex which has been implemented in gnat-glade.

Re: Development process in the Ada community

[Michael Erdmann]

Marin David Condic wrote:
> "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
> news:3CB5BED1.3090702@snafu.de...
> 
>>There is a POSIX based package available (florist) and adasockets
>>from S. Tardieu but they are not part of the Ada predefined packages.
>>It is a pitty.
>>
>>
> 
> Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It
> might even impose a layer on top that provided a whole Ada-ish look and feel
> to the endeavor, rather than being just a thin binding.

I guess a more sbatract concept for interprocess communication on basis
of streams would be more apropriate. Personally i am always in favor of
complext services provided to the developen rather than doing low
level coding using a thin binding.

> 
> A few things like this could go quite far in improving portable development
> life by getting an OS-independent view of common services. (With the usual
> stipulation that an implementation need not provide it at all, but if it
> does, it will have this interface.)

Maybe the basic ideas of Java can be resued here?


Regards
    M.Erdmann

Re: --off topic Re: Rant! (was) Development process in the Ada community

[Chad R. Meiners]

Note that rhetoric does not deal with truth, but it does deal in impressing
ideas upon people.  Ergo, people that wish to persuade others without
relying on the truth resort to rhetoric.  As to repeating yourself, you
accused the US military of both having perverse objectives, and of being
murders.  That is two attacks; the second attack would be the repeated
attack.  As to ignorance you are clearly ignorant of logical reasoning.  As
to your supposed 'criticism', in order for criticism to be valid it must be
a well formed argument and be logically consistent.  Otherwise your
'criticism' is likely to actually be defamation.

So do you really care about truth or do you prefer to try to verbally
force(impress) people into your point of view with your numerous personal
attacks and abuses of the context and definition?  If you care about truth,
I would be more than happy to recommend some university courses on logic.
That way you could have the tools to properly reason about truth.
Otherwise, I suggest you look up one more word; this word is 'bigot'.  Note
that I am not calling you a bigot; I just think you should know what this
word really means.

As to your red herring about Somalia, you still cite no evidence; you only
state your confidence in a book author's words.  You also accuse the
ENTIRE US military of crimes!  Surely you cannot believe that everyone in
the US military is guilty or responable for these crimes, but this is what
you claim.  Do you really want to accuse every person in the US military of
murder?

Please don't respond with any more personal attacks; they don't work on me.
As long as you do not use logically valid means to present your arguments, I
will not accept them since you do not have the tools to show that your
arguments are valid.

"tony" <tonygair@btinternet.com> wrote in message
news:3CB74B83.D24F1835@btinternet.com...
> "Chad R. Meiners" wrote:
> >
> > Please refrain from supporting global ignorance by relying on rhetoric
to
> > persuade people.
>
> In my bit to reduce global ignorance, I have looked up the following big
> words RELYING on the Oxford Dictionary, that you used.
>
> Rhetoric :- Art of presenting words impressively
>
> Thanks Chad. I didn't realise you were impressed.
>
> Repeated :- occurred more than once.
>
> I did not repeat myself.
>
> Ignorance :- lack of knowledge.
>
> For example not knowing the meaning of the words you write.
>
>
>
> >> Just because you believe something doesn't make it true,
> > and just because you say something over and over, also, doesn't make it
> > true.
>
> Gee thanks Grandma, can you tell me the truth now......
>
> >>  If you care about the truth, you must carefully determine the truth
> > with logically valid methods.
>
> In your post you implied that I was ignorant and now you imply I am
> lying. You are hereby strucken from my christmas card list.
>
> >>  In particular, please refrain from
> > encouraging the irrational hatred of organizations such as the US
military.
>
> Critiscism is not irrational hatred. What irrational Hatred am I
> encouraging? Does critiscism make me a Terrorist. The use and supply of
> weapons against civilians to further my ends in the world would be
> irrational hatred and terrorist.
>
> Bombing, strafing and the murder of unarmed civilian crowds in Somalia
> (The author of blackhawk down describes this in his book) is Irrational
> hatred and more. Opposing the design and production of satanic devices
> that make this possible is NOT irrational hatred, it is a logical valid
> method to oppose people who betray Humanity.

Re: Development process in the Ada community

[Michael Erdmann]

Marin David Condic wrote:
> I would agree that there needs to be stability around what might be called
> the "core" language. Certainly the 13 chapters of the ARM and possibly
> around the appendices as well. (Although I think it might be a benefit to be
> able to add to the appendices a little more easily to gain language
> extension without undue instability for the compiler writers.)

I guess a public process imvoling the open source community as well
would help to achieve this.

> 
> But to look at Java and ask "what's good about what they are doing?" is
> important as well. Having a large library of support code that works to
> create a whole portable development environment might just be A Good Thing.
> Perhaps if the Ada standard process found a way of talking about "standard"
> libraries and incorporating them into the Ada language in some kind of
> semi-official way (with undue burdens or delays) it might help Ada find
> wider acceptance through the leverage it would offer to developers.

Again i like to say i dont like what java is!!!!!

The important point is that they have established a public process to
improve there development environment, which i think is missing in the 
Ada community!!!


Regards
    M.Erdmann

> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> 
> "Eric G. Miller" <egm2@jps-nospam.net> wrote in message
> news:pan.2002.04.11.01.38.30.887865.26212@jps-nospam.net...
> 
>>How many changes in the Java language have occurred in the last ten
>>years?  How many are fully backwards compatible?  Java aims to be
>>a whole platform, but it's a moving target.  What about developers
>>who want their libraries and programs to be relevant for more than
>>a couple years?  IMHO, rapidly changing languages present a double
>>edged sword.
>>
>>I think the goals of the two languages are somewhat orthogonal. I
>>don't think there will ever be a "one size fits all" language.
>>The safety and security features of Ada are very important to
>>some folks, for instance.
>>
>>Oh, btw, this "outdated mode" of standardization is one thing that
>>drew me to start using Ada vs. something like Java [tm], which is
>>owned by Sun.
>>
> 
> 

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Kent Paul Dolan wrote:
> "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:
> 
> 
>>i am wondering how standards are eveloving in the Ada community.
>>In the Java Community there is a process called Java Community
>>Process (JCP, http://www.jcp.org/)
>>
> 
>>Is there something comparable in the Ada communitiy? I guess
>>if there would be something like this there would be more
>>dynamic in the Ada 95 community.
>>
> 
> You have put your finger, probably, on the cause of the US Military's
> collapse on the issue of an Ada Mandate in the face of programmer
> intransigence to use Ada among the military community, in the answers
> you have received.
> 
> The love of doing things one rigid way, with all decisions handed down
> from above, ran square into the software development community, which is
> used to speedy and flexible growth in its tools.


This has nothing to do with the DoD. From my experiences this is a
consequence of larege orgnaisations, because it is not possible in
such organisations, that everybody is communicating with everybody
else to reach a common understanding.

> 
> Probably Ada was doomed to be the Horse Cavelry of programming languages
> the day its language standardization process was chosen, and I'm afraid
> you are going to find no cure for what is basically an incurable
> attitude problem of an entire, isolated programming community.
> 
> Like Steven Jay Gould's "allopatric demes", Ada, brought back to cross
> fertilize with other programming languages and their newly invented
> mechanisms, might have provided hybrid vigor and a new, more competitive
> product.
> 
> Instead you see what you see:
> 
> "Why should we want a superior graphics interface to replace an inferior
> one, while maintaining the old one so as not to break old code?"
> 
> "Why should the new developments become _part of the language_?"
> 
> "Who needs a standard OS calling interface _in the language_?"
> 
> "We don't need no stinking programming community inputs to the
> language!"
> 
> "Procedure for change?  We want stability, stability, stability!"
> 
> [The Kaiser's army had stability; programming as a task by definition
> does not.]
> 
I agree on this partially, i read this during the whole thread
very often.


> ad infinitum.
> 
> ..........................complex bogosities get ditched:
> _decimal_ specification of sizes for _binary_ data containers!!!
> 
> Give me a break.
> 
> "Progress, keeping up with community standards, is for other people!"
I dont like the attitude you are showing here. I have worked
on standarisation of telecomminucation protocols and i can assure
you that progress is possible with a defined development process,
It depends largely on the good will of the audience but it works!


> 
> Give me a break.
> 
> Sigh.  So much promise, so small a result.  Given a complete community
> feedback loop and about a hundred times faster language change response
> time, Ada could be everyone's programming language of choice today.
> 
> Java, alive for about 7 years, is due imminently for its fifth major
> release.  That still doesn't guarantee its survival; Sun has an
> incurable attitude problem toward making Java truly freeware, but it
> does help.  Ada doesn't even have a sponsor any more outside the
> compiler vendor community, and I don't even see any visible signs of
> public debate and motion toward a second much needed major overhaul and
> upgrade for twenty year old Ada, just a few well hidden notes on some
> standards committee web sites.
> 
> That comp.lang.ada isn't comp.lang.ada.* is a symptom of the whole
> mindset problem.  Unitary Usenet discussion groups are very
> characteristic of exactly one thing: _minor_ programming languages.
> 
> xanthian.
> 
> At least when I yelled at the Fortran standards folks back in 1987 or
> so, they responded, and arguably saved their language from the dust-bin
> as a result.  Here, the outlook is not so rosy.
> 
> 
Any how i cant seeing your point what should be done with Ada? Thrown
away because the DoD has has initiated it??!!!!

Regards
    M.Erdmann




> 

Re: Rant! (was) Development process in the Ada community

[Robert Dewar]

"Kent Paul Dolan" <xanthian@well.com> wrote in message news:<dfc3a9eb805c5538c8b1d19eb9c9aff3.48257@mygate.mailgate.org>...

> "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:
> "We don't need no stinking programming community inputs 
> to the language!"

Well I don't often visit these kinds of thread, but
occasionally it makes a good laugh, and any post from
KPD is sure to be an interesting case of rewriting
history :-) :-) :-)

"don't tell me no stinking facts about Ada or its history,
I prefer to make them up!"

Re: Rant! (was) Development process in the Ada community

[Robert Dewar]

Ingo Marks <adv@region-nord.de> wrote in message news:<a96bou$fb5$02$1@news.t-online.com>...

> Some people in comp.lang.ada are 
> right when they say a very good incentive to make Ada 
> attractive to newbies 
> would be an IDE with the feeling and power of Visual
> Studio .NET.

Stay tuned :-)

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Robert Dewar wrote:
> "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<dfc3a9eb805c5538c8b1d19eb9c9aff3.48257@mygate.mailgate.org>...
> 
> 
>>"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:
>>"We don't need no stinking programming community inputs 
>>to the language!"
>>
> 
> Well I don't often visit these kinds of thread, but
> occasionally it makes a good laugh, and any post from
> KPD is sure to be an interesting case of rewriting
> history :-) :-) :-)
> 
I am sorry, but i did not write this. I gues this might
be a cust&paste error!!!!

Michael Erdmann

Re: Development process in the Ada community

[Michael Erdmann]

Before the whole thread gets completly out of control,
i like to get your ideas how such a "fast" process could
be established?

Such a process could have the following key attributes:

- Public, all working results should be freely available
- Open to the open source community and companies if they
   comply to open source rules.

- Other key attributes ....?

Regards
    M.Erdmann




Michael Erdmann wrote:
> Hallo all,
> 
> i am wondering how standards are eveloving in the Ada community.
> In the Java Community there is a process called Java Community
> Process (JCP, http://www.jcp.org/)
> 
> Is there something comparabel in the Ada communitiy? I gues
> if there would be something like this there would be more
> dynamic in the Ada 95 community.
> 
> 
> Regards
>   M.Erdmann
> 

Re: Rant! (was) Development process in the Ada community

[martin.m.dowie]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0204121930.64733eeb@posting.google.com...
> Ingo Marks <adv@region-nord.de> wrote in message
news:<a96bou$fb5$02$1@news.t-online.com>...
>
> > Some people in comp.lang.ada are
> > right when they say a very good incentive to make Ada
> > attractive to newbies
> > would be an IDE with the feeling and power of Visual
> > Studio .NET.
>
> Stay tuned :-)

I nearly misread this as a hint of future support for ".NET" but a quick
look at the www.gnat.com front page and I think it is more of a hint that
there is a new post-GLIDE IDE coming (GPS).

Shame - could have been the most significant announcement on this
newsgroup for the last 5 years...

Re: Rant! (was) Development process in the Ada community

[Larry Kilgallen]

In article <5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com>, "martin.m.dowie" <martin.m.dowie@ntlworld.com> writes:

> I nearly misread this as a hint of future support for ".NET" but a quick
> look at the www.gnat.com front page and I think it is more of a hint that
> there is a new post-GLIDE IDE coming (GPS).
> 
> Shame - could have been the most significant announcement on this
> newsgroup for the last 5 years...

Or not.  That certainly is a matter of opinion.

Re: Development process in the Ada community

[Larry Kilgallen]

In article <3CB7E244.4090105@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> Before the whole thread gets completly out of control,
> i like to get your ideas how such a "fast" process could
> be established?
> 
> Such a process could have the following key attributes:
> 
> - Public, all working results should be freely available
> - Open to the open source community and companies if they
>    comply to open source rules.

If membership on the deliberative body is based on criteria
other than the contribution one might make to the effort,
such as the criterion of being some "open source" entity,
that would be a mistake.

Re: Rant! (was) Development process in the Ada community

[martin.m.dowie]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:2imowKjzt7uP@eisner.encompasserve.org...
> In article <5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com>,
"martin.m.dowie" <martin.m.dowie@ntlworld.com> writes:
>
> > I nearly misread this as a hint of future support for ".NET" but a quick
> > look at the www.gnat.com front page and I think it is more of a hint
that
> > there is a new post-GLIDE IDE coming (GPS).
> >
> > Shame - could have been the most significant announcement on this
> > newsgroup for the last 5 years...
>
> Or not.  That certainly is a matter of opinion.

True - but IMHO any Ada.NET support would be hugely welcome! :-)

Re: Rant! (was) Development process in the Ada community

[Gary Scott]

"martin.m.dowie" wrote:
> 
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:2imowKjzt7uP@eisner.encompasserve.org...
> > In article <5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com>,
> "martin.m.dowie" <martin.m.dowie@ntlworld.com> writes:
> >
> > > I nearly misread this as a hint of future support for ".NET" but a quick
> > > look at the www.gnat.com front page and I think it is more of a hint
> that
> > > there is a new post-GLIDE IDE coming (GPS).
> > >
> > > Shame - could have been the most significant announcement on this
> > > newsgroup for the last 5 years...
> >
> > Or not.  That certainly is a matter of opinion.
> 
> True - but IMHO any Ada.NET support would be hugely welcome! :-)

True and if a minor language like Fortran 95 has 4 or 5 .net commercial
products in development...  Heck, there's even COBOL.net for gosh
sakes.  No Ada.net would be a true embarrassment.

(ok, I'm just joshin')
-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Rant! (was) Development process in the Ada community

[Robert Dewar]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message news:<5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com

> Shame - could have been the most significant announcement
> on this newsgroup for the last 5 years...

We have no plans to do anything with .NET and GNAT so far, since there
has been absolutely zero significant interest in such a product
(postings on CLA I am sorry to say do not
register as significant interest). In fact the lack of interest is
surprising, we have not even had enquiries on
this topic.

Needless to say, our assessment of significance is somewhat different
from yours :-)

It's all a bit reminiscent of two things in the past.

Big chorus of people interested in GNAT for the Mac. But no
significant interest emerged. Yes, there is a volunteer effort to keep
GNAT alive on the Mac for the enthusiastic
few :-) which is great, and one of the respects in which the Free
Software approach is attractive.

Big chorus (backed up by DoD money) of people interested in
an Ada compiler generating code for the JVM. But only marginal
interest emerged, so that port is now on terminal
life support from us. Perhaps a significant volunteer effort will
arise there too, but so far no sign of it.

Now on the other hand interest in IDE's -- that's real indeed, and
that is where we are putting a lot of effort these days.

Perhaps .NET will emerge as significant, perhaps not. Hard to say. I
think those who imagine that Ada for .NET will somehow spark new
interest in Ada are indulging in wishful
thinking. For me, the most interesting avenue for getting
more people interested in Ada is to concentrate on things
that will appeal to this generation of CS students who are
working with Free Software extensively.

Hint: anything to do with Microsoft does NOT appeal to students these
days, who routinely refer to Microsoft as the "dark side", a
phenomenon that I think MS should be
paying far more attention too :-)

Many of my students are shocked to see me using Windows XP
these days. But of course there *is* significant interest in GNAT
running under XP, so that's a different matter entirely :-)

Re: Development process in the Ada community

[Michael Erdmann]

Larry Kilgallen wrote:
> In article <3CB7E244.4090105@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> 
>>Before the whole thread gets completly out of control,
>>i like to get your ideas how such a "fast" process could
>>be established?
>>
>>Such a process could have the following key attributes:
>>
>>- Public, all working results should be freely available
>>- Open to the open source community and companies if they
>>   comply to open source rules.
>>
> 
> If membership on the deliberative body is based on criteria
> other than the contribution one might make to the effort,
> such as the criterion of being some "open source" entity,
> that would be a mistake.

I am not sure if i am unerstanding correctly, but what i
like to ensure, that the standards, components etc are
available under open source licenses. I dont like to have
the situation that part of the output of such a group
is public and the other one not.

May be a better term would be:

- Open to everybody who accepts the fact that his working
   results will be put unter open source license.


Regards
    M.Erdmann

> 

Re: Rant! (was) Development process in the Ada community

[martin.m.dowie]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0204130620.114953ae@posting.google.com...
> "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:<5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com
>
> > Shame - could have been the most significant announcement
> > on this newsgroup for the last 5 years...
>
> We have no plans to do anything with .NET and GNAT so far, since there
> has been absolutely zero significant interest in such a product
> (postings on CLA I am sorry to say do not
> register as significant interest). In fact the lack of interest is
> surprising, we have not even had enquiries on
> this topic.
>
> Needless to say, our assessment of significance is somewhat different
> from yours :-)
[snip]

I totally respect your decisions on what to target new development
on - it is your business. I'm just sorry I can't bring the bucks to the
table to make it worth while for you (or anyone else) to do this :-(

It is a shame that COBOL has Fujitsu to develop COBOL.NET but
that Ada has no such large corporate to perform this sort of work.
Without such a sponsor it is hard to see how Ada gets out of the
catch22 of:
User:        "Why use Ada when it doesn't support feature X?"
Vendor:    "Why support feature X when there is no user demand?"

Perhaps there is some hope in the 'DotGNU' project. The item that
interested me in the FAQ for this is:

"1.17 Will C and C++ be supported in DotGNU?

  Code which is written in C or C++ can be used with DotGNU, *if* it
  is distributed with DotGNU or otherwise installed like you normally
  install software.  However you cannot use C or C++ to implement
  webservice programs that are meant to run in the Secure Execution
  Environment (SEE), like it will be possible with e.g. Java, Ada, C#
  and Perl - at least not until someone solves the difficult issues of
  compiling C to some kind of portable intermediate representation in
  such a way that the Secure Execution Environment can efficiently
  verify that the program is not trying to do something malicious."

Re: Development process in the Ada community

[Larry Kilgallen]

In article <3CB85658.5050406@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> Larry Kilgallen wrote:

>> If membership on the deliberative body is based on criteria
>> other than the contribution one might make to the effort,
>> such as the criterion of being some "open source" entity,
>> that would be a mistake.
> 
> I am not sure if i am unerstanding correctly, but what i
> like to ensure, that the standards, components etc are
> available under open source licenses. I dont like to have

Is it ISO document charges that you are complaining about ?

> the situation that part of the output of such a group
> is public and the other one not.

Aside from that, what output is not public ?

> May be a better term would be:
> 
> - Open to everybody who accepts the fact that his working
>    results will be put unter open source license.

So you would admit to the deliberative body anyone who
agreed to that, no matter how otherwise unqualified
they might be.  That seems quite wrong to me.

Re: Development process in the Ada community

[Michael Erdmann]

Larry Kilgallen wrote:
> In article <3CB85658.5050406@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> 
>>Larry Kilgallen wrote:
>>
> 
>>>If membership on the deliberative body is based on criteria
>>>other than the contribution one might make to the effort,
>>>such as the criterion of being some "open source" entity,
>>>that would be a mistake.
>>>
>>I am not sure if i am unerstanding correctly, but what i
>>like to ensure, that the standards, components etc are
>>available under open source licenses. I dont like to have
>>
> 
> Is it ISO document charges that you are complaining about ?

Yes, this is one face of the problem.

> 
> 
>>the situation that part of the output of such a group
>>is public and the other one not.
>>
> 
> Aside from that, what output is not public ?

When is is not available on the net in a server from where
you can download the information you need.

Additionaly the term public does not cover only the
availability but also the licensing.

> 
> 
>>May be a better term would be:
>>
>>- Open to everybody who accepts the fact that his working
>>   results will be put unter open source license.
>>
> 
> So you would admit to the deliberative body anyone who
> agreed to that, no matter how otherwise unqualified
> they might be.  That seems quite wrong to me.
> 
What means unqualified? This is the problem i have with
the JPC. There an executive board selects experts. The
experts will be choosen based in the priorities of the
executive board which is founded by SUN (i think).

But from my experiences if you start serious work
unqualified members are droping out of the group
quite fast because they are not able to follow any
more and they are loosing there interest.

But you are right, i dont have any universal answer
for this issue.

Anyhow something like this is already exisiting

http://www.ada-auth.org

Maybe this orginisation could be reshaped slightly
to create a larger momentum on the Ada 95 community.

What do you think??


Regards
    M.Erdmann

Re: Development process in the Ada community

[Larry Kilgallen]

In article <3CB880AF.5080407@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> Larry Kilgallen wrote:

>> Is it ISO document charges that you are complaining about ?
> 
> Yes, this is one face of the problem.

Personally I am happy to pay ISO document charges,
but that is not required for the Ada Reference Manual.

>>>the situation that part of the output of such a group
>>>is public and the other one not.
>>>
>> 
>> Aside from that, what output is not public ?
> 
> When is is not available on the net in a server from where
> you can download the information you need.

Although that definition is not universally agreed,
how do you feel the Ada specification does not match
that definition ?  Have you looked at http://www.adapower.com ?

> Additionaly the term public does not cover only the
> availability but also the licensing.

What aspect of the Ada documentation involves licensing ?

>>>May be a better term would be:
>>>
>>>- Open to everybody who accepts the fact that his working
>>>   results will be put unter open source license.
>>>
>> 
>> So you would admit to the deliberative body anyone who
>> agreed to that, no matter how otherwise unqualified
>> they might be.  That seems quite wrong to me.
>> 
> What means unqualified? This is the problem i have with
> the JPC. There an executive board selects experts. The
> experts will be choosen based in the priorities of the
> executive board which is founded by SUN (i think).

I have not heard of such a problem with Ada.

> Anyhow something like this is already exisiting
> 
> http://www.ada-auth.org
> 
> Maybe this orginisation could be reshaped slightly
> to create a larger momentum on the Ada 95 community.
> 
> What do you think??

I don't think there are any changes that can be made in
that area to create a larger momentum in the Ada community.

Re: Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:
> Kent Paul Dolan wrote:

> > The love of doing things one rigid way, with all decisions handed down
> > from above, ran square into the software development community, which is
> > used to speedy and flexible growth in its tools.

> This has nothing to do with the DoD.

To the contrary, rigid, top down command structure with limited upwards
feedback is quintessentially a military organization model.  No business
could long survive with a similarly rigid hierarchy.


> > "Progress, keeping up with community standards, is for other people!"

> I dont like the attitude you are showing here. I have worked
> on standarisation of telecomminucation protocols and i can assure
> you that progress is possible with a defined development process,
> It depends largely on the good will of the audience but it works!

How well I know; there are three ANSI X3H3 standards (GKS, CGM, VDI)
containing my 4.5 years of contributions. I know what is possible, I
don't see the Ada community following ANSI's most important guideline:
standards shall incorporate current best practice.  This isn't a
standards process problem, this is explicitly an Ada community problem.

> > At least when I yelled at the Fortran standards folks back in 1987 or
> > so, they responded, and arguably saved their language from the dust-bin
> > as a result.  Here, the outlook is not so rosy.

> Any how i cant seeing your point what should be done with Ada?

It should follow the Fortran standards choice (for Fortran 90) of
continuing to incorporate programming community best practice, rather
than crawling off in a corner and becoming a programming language no new
graduate wants to touch because none of the new stuff to make
programming easier learned in school exists in the language.

> Thrown away because the DoD has has initiated it??!!!!

No, I sign my name "LCDR, Retired" when I care to bother; I don't have
any particular bone to pick with the military.  DoD has abandoned Ada,
that is the problem.  The head has been cut off, the body continues to
twitch.  Ada needs a new mandate, some sense of direction so it doesn't
just continue to march in place, and I don't see it happening.

xanthian.




-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Development process in the Ada community

[Kent Paul Dolan]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:

> Is it ISO document charges that you are complaining about ?

They are certainly worth a complaint.  The daunting cost of paper
standards, and the standards process funding mechanism that prevents
most of the standards from becoming freely downloadable softcopy,
arguably are active deterents to widespread use, or even awareness, of
standards.

xanthian.

Contrast with the Java API standards/docs from Sun, the W3C Cascading
Style sheets standards, and the W3C HTML4.1standards, all of which spin
on my laptop and are in daily use by me, just because I could afford
them and download them.  These are _immensely_ successful standards.  I
helped _write_ three other, high-cost, hardcopy-only standards, yet
cannot afford, either by price or by carrying capacity, to own, use, or
evangelize any of them.



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Development process in the Ada community

[Larry Kilgallen]

In article <ee2c9a2989167c1c5ce5b90239a3d41a.48257@mygate.mailgate.org>, "Kent Paul Dolan" <xanthian@well.com> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:
> 
>> Is it ISO document charges that you are complaining about ?
> 
> They are certainly worth a complaint.  The daunting cost of paper
> standards, and the standards process funding mechanism that prevents
> most of the standards from becoming freely downloadable softcopy,
> arguably are active deterents to widespread use, or even awareness, of
> standards.

Again, I ask, what does this have to do with Ada95 ?

Re: Development process in the Ada community

[Gary Scott]

Kent Paul Dolan wrote:
> 
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:
> 
> > Is it ISO document charges that you are complaining about ?
> 
> They are certainly worth a complaint.  The daunting cost of paper
> standards, and the standards process funding mechanism that prevents
> most of the standards from becoming freely downloadable softcopy,
> arguably are active deterents to widespread use, or even awareness, of
> standards.
> 
> xanthian.
> 
> Contrast with the Java API standards/docs from Sun, the W3C Cascading
> Style sheets standards, and the W3C HTML4.1standards, all of which spin
> on my laptop and are in daily use by me, just because I could afford
> them and download them.  These are _immensely_ successful standards.  I
> helped _write_ three other, high-cost, hardcopy-only standards, yet
> cannot afford, either by price or by carrying capacity, to own, use, or
> evangelize any of them.

I wish someone would resurrect GKS/CGM.  I love those.  It needs to be
modernized a little, but I like the clear clean terminology and design. 
There are only a few things that I prefer about IBM's GDDM over GKS.

> 
> --
> Posted via Mailgate.ORG Server - http://www.Mailgate.ORG


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Kent Paul Dolan wrote:
> "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:
> 
>>Kent Paul Dolan wrote:
>>
> 
>>>The love of doing things one rigid way, with all decisions handed down
>>>from above, ran square into the software development community, which is
>>>used to speedy and flexible growth in its tools.
>>>
> 
>>This has nothing to do with the DoD.
>>
> 
> To the contrary, rigid, top down command structure with limited upwards
> feedback is quintessentially a military organization model.  No business
> could long survive with a similarly rigid hierarchy.
> 
I am not so mutch experienced with the DoD, but to me it sounds
like what you can often encounter in large companies and they are
still dominating the market without alwys beeing always the technical
leader in there domain.

>>>"Progress, keeping up with community standards, is for other people!"
>>>
> 
>>I dont like the attitude you are showing here. I have worked
>>on standarisation of telecomminucation protocols and i can assure
>>you that progress is possible with a defined development process,
>>It depends largely on the good will of the audience but it works!
>>
> 
> How well I know; there are three ANSI X3H3 standards (GKS, CGM, VDI)
> containing my 4.5 years of contributions. I know what is possible, I
> don't see the Ada community following ANSI's most important guideline:
> standards shall incorporate current best practice.  This isn't a
> standards process problem, this is explicitly an Ada community problem.
> 
> 
>>>At least when I yelled at the Fortran standards folks back in 1987 or
>>>so, they responded, and arguably saved their language from the dust-bin
>>>as a result.  Here, the outlook is not so rosy.
>>>
> 
>>Any how i cant seeing your point what should be done with Ada?
>>
> 
> It should follow the Fortran standards choice (for Fortran 90) of
> continuing to incorporate programming community best practice, rather
> than crawling off in a corner and becoming a programming language no new
> graduate wants to touch because none of the new stuff to make
> programming easier learned in school exists in the language.


This is where i completly agree, specially the predefined packages have
to updated dramatically. The langauge is still better then most of the
currently commonly used languages.

>>Thrown away because the DoD has has initiated it??!!!!
>>
> 
> No, I sign my name "LCDR, Retired" when I care to bother; I don't have
> any particular bone to pick with the military.  DoD has abandoned Ada,
> that is the problem.  The head has been cut off, the body continues to
> twitch.  Ada needs a new mandate, some sense of direction so it doesn't
> just continue to march in place, and I don't see it happening.

This is exaclty the impression i have my self. So i was wondering
if Ada could take a new direction, when the open source communitiy is
more directly involved by establishing a public process in order
to enhance the predefined libraries, and may be later, to make an
attempt to get these things into ISO etc..

I am realy wondering if good place to start would be the AIC?


Regards
    M.Erdmann

Re: Development process in the Ada community

[Michael Erdmann]

Larry Kilgallen wrote:
> In article <3CB880AF.5080407@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> 
>>Larry Kilgallen wrote:
>>
> 
>>>Is it ISO document charges that you are complaining about ?
>>>
>>Yes, this is one face of the problem.
>>
> 
> Personally I am happy to pay ISO document charges,
> but that is not required for the Ada Reference Manual.
Who is sponsering this, US Goverment?

>>>>the situation that part of the output of such a group
>>>>is public and the other one not.
>>>>
>>>>
>>>Aside from that, what output is not public ?
>>>
>>When is is not available on the net in a server from where
>>you can download the information you need.
>>
> 
> Although that definition is not universally agreed,
> how do you feel the Ada specification does not match
> that definition ?  Have you looked at http://www.adapower.com ?


I am not talking about the currently available Ada RM
which i realy like. But for example what interface is
Ada providing for data base access?


All MS-Languages: ADO
Java            : JDBC, JDO
Ada ?

Ada is providing nothing, therefor i am forced to
reuse design concepts from ADO or JDBC in order
to limit the development effort, which already
brings me into licensing problem (specially ADO)
because these "defacto standards" are owned by
companies (at least as far as i know).

These are the Situations i am afraid of, with the
consequence every result of such an organization
should be clearly liecensed as open source. I have
to admid i am not the specialist in licensing but
i hope you got my idea!

> 
> 
>>Additionaly the term public does not cover only the
>>availability but also the licensing.
>>
> 
> What aspect of the Ada documentation involves licensing ?
> 


> 
>>>>May be a better term would be:
>>>>
>>>>- Open to everybody who accepts the fact that his working
>>>>  results will be put unter open source license.
>>>>
>>>>
>>>So you would admit to the deliberative body anyone who
>>>agreed to that, no matter how otherwise unqualified
>>>they might be.  That seems quite wrong to me.
>>>
>>>
>>What means unqualified? This is the problem i have with
>>the JPC. There an executive board selects experts. The
>>experts will be choosen based in the priorities of the
>>executive board which is founded by SUN (i think).
>>
> 
> I have not heard of such a problem with Ada.

But who is paying the peoples in the ISO Working
groups? I guess these are the interested companies.
 From my past experiences with ETSI and ITU,
you get only progress if the involved parties
are interested to launch something new within a
given time frame.
After this has been achieved, the behaviour in the
working groups changes drasticaly from supporting
progress towards the attitude of protecting what
has been achived. The motto then is

   "...everything which does not hurt my
       product is ok, but i will put no additional
       effort to change it unless my market
       requires it...".

So i am not so sure if you don't have this problem
already. I have read one of your discussions about
the debug pragma, which reminded me imediatly about
my earlier times with ETSI.


>>Anyhow something like this is already exisiting
>>
>>http://www.ada-auth.org
>>
>>Maybe this orginisation could be reshaped slightly
>>to create a larger momentum on the Ada 95 community.
>>
>>What do you think??
>>
> 
> I don't think there are any changes that can be made in
> that area to create a larger momentum in the Ada community.
> 
I think, they could promote ther interface towards
the public (Ada 95 community) by asking proactivly
the Ada 95 community  for comments on the topics
which are of high interest. This would at least
ensure that there activities are more in line with
the market requirements are.
An if they would be able to add additional Annexes
to the RM relating to these hot Topics this would
make the difference!

Maybe i will try to contact the WG9 ARG chairman
(i have not found out yet who it is) regarding
this issue. Because the current situation in the
Ada commmunity is like in the COBOL community
some years a go (realy rediculess), but at least C
OBOL was realy needed because of its large code
base.

Regards
     M.Erdmann

Re: Development process in the Ada community

[Michael Erdmann]

Michael Erdmann wrote:
> Hallo all,
> 
> i am wondering how standards are eveloving in the Ada community.
> In the Java Community there is a process called Java Community
> Process (JCP, http://www.jcp.org/)
> 
> Is there something comparabel in the Ada communitiy? I gues
> if there would be something like this there would be more
> dynamic in the Ada 95 community.
> 

During the Thread my main line of reasoning has got
completly out of scope.

You will find in the Ada 95 communit a lot of open
source software solutions covering the following topics:

GUI   -> GtkAda, Claw etc.
Networking -> adasockets
http -> AWS
....XML,SOAP + 1 Million implemantions of lists and container
(including mine).

These components have been implemented because they are
needed.
Since they are not standarized the consequence that you
will find a lot of derivates of these packages in the
net (specially lists and containers are a nice
example) because everybody reinvents the stuff.

And i am wondering if there could be a processed
established which brings these things back into the
standard in order to avoid the reinvention of
state of the art components.


Regards
    M.Erdmann

Re: Development process in the Ada community

[Georg Bauhaus]

Michael Erdmann <Michael.Erdmann@snafu.de> wrote:

: And i am wondering if there could be a processed
: established which brings these things back into the
: standard in order to avoid the reinvention of
: state of the art components.

Monoism isn't compatible with reality I think, starting
at two sexes. If you have two well founded container libraries,
with apparently significant theoretical knowledge visible
in their design and accompanying talk, they may still
have their relative merits. One uses inheritance, the other
doesn't, how do you add (passive) persistency to the other?
One is small and easy to use, the other is big and offers
more containers and algorithms. However, why should the
one not steal (or refuse) ideas from the other? This is
not reinventing.

If program users want different GUIs, this creates
an opportunity to have more people work on the different
implementations, and have users hand out the rewards,
that is payment. They have a right to require this to be
done.

There were times when there were people using very different
computers on their desktops, and it worked at the time, I'm
sure you know. Now most PC users have one type of processor
built into essentially one type of computer. Good or bad?
(Incidentally, one type of compiler (Visual *), together
with one great library/components on one VM
might bring us one type of fpt precision, which is not
the one lurking in most processors. (This is a guess.))

Java is presented to show how to do it, but:
There is no way to have a method indicate
success or failure other than boolean return or an exception.
That is, the famous Java library offers no simple value
wrapper with a set method, except the one in java.text
to store parse positions. No in/out mechanism in that library.

Georg Bauhaus,
 currently creating views of data for different
 media, using diffenrent libraries, because people want that.
 They also pay us.
 It's as entertainging as knowing there are fish, birds,
 wooly animals, snakes, dogs, ...

Re: Rant! (was) Development process in the Ada community

[Ingo Marks]

Michael Erdmann wrote:

> Kent Paul Dolan wrote:
>>
>> No, I sign my name "LCDR, Retired" when I care to bother; I don't have
>> any particular bone to pick with the military.  DoD has abandoned Ada,
>> that is the problem.  The head has been cut off, the body continues to
>> twitch.  Ada needs a new mandate, some sense of direction so it doesn't
>> just continue to march in place, and I don't see it happening.
> 
> This is exaclty the impression i have my self. So i was wondering
> if Ada could take a new direction, when the open source communitiy is
> more directly involved by establishing a public process in order
> to enhance the predefined libraries, and may be later, to make an
> attempt to get these things into ISO etc..

Who "owns" Ada? The DoD has decided to quit Ada so they don't seem to have 
any more interest. 

A new standardization project needs a central place to start. CAD is a good 
starting point to discuss but the many messages are scattered all over the 
group and it becomes difficult for me to collect the essence of all ideas. 
You complained that the focus of this thread is already out of control.

I would like to suggest to create a new website where you list all your 
intentions and considerations. People will read them and make comments 
there and/or here. People will make source code contributions and the whole 
thing will grow step by step.

Do you want open source library standards for the current Ada 95 standard 
or do you want to have the language "polished up", too? 

Ada is impressive but my first impressions were that some (few) things are 
unnecessarily complicated which have a deterring effect to newbies. For 
example string handling. The distinction between fixed and unbounded 
strings confused me at first (and my compiler produced at lot of error 
messages ;-) Somewhere I read that the Ada 95 standard would support string 
handling with garbage collections already (but no compiler has implemented 
this yet). It would be fine if this could be done in an open source 
standardization project.

Ingo

Re: Rant! (was) Development process in the Ada community

[Ingo Marks]

Ingo Marks wrote:

> A new standardization project needs a central place to start. CAD is a

sorry: I meant CLA (comp.lang.ada)

Re: Development process in the Ada community

[Ingo Marks]

Georg Bauhaus wrote:

> Michael Erdmann <Michael.Erdmann@snafu.de> wrote:
> 
> : And i am wondering if there could be a processed
> : established which brings these things back into the
> : standard in order to avoid the reinvention of
> : state of the art components.
> 
> Monoism isn't compatible with reality I think, starting
> ...
> If program users want different GUIs, this creates
> an opportunity to have more people work on the different
> implementations, and have users hand out the rewards,
> that is payment. They have a right to require this to be
> done.
> ...

Michael didn't say the he wants to have universal monolithic libraries and 
throw all other developments away.

I agree with Michael that it's better for the Ada community to work 
together to develop good universal solutions which fit the needs of many. 
That doesn't mean that these developments fit the needs of everyone and 
every application.

See Mono (and DotGNU): They develop a new library standard for GTK/Gnome 
and don't pay much attention if these standards are compatible with .NET in 
the future (due to possible patent restrictions). They just see the power 
of standard libraries which help them to develop new applications with less 
effort in much shorter time than before. That doesn't mean that you cannot 
continue to write GTK/Gnome applications with the old libraries.

Re: --off topic Re: Rant! (was) Development process in the Ada community

[Georg Bauhaus]

Chad R. Meiners <crmeiners@hotmail.com>
wrote about tony's comments:
: Note that rhetoric does not deal with truth, but it does deal in impressing
: ideas upon people.

That's a relatively recent (and narrowed) meaning of the word, afaik.
Until few centuries ago, rhetoric counted as number two of the arts,
close to logic, grammar, dialegein (not to be confused with the
simple concept of yes/no/together again), and, in roman days, courts.
Thus of course in those days it had to do with truth, in several ways.


: As
: to your supposed 'criticism', in order for criticism to be valid it must be
: a well formed argument

O.K.

: and be logically consistent.

That again is a modern axiom held by many scientists. By a
mechanism known as group pressure it has become a dominant
view in several scientific discussions, despite it's known
difficulties. I'm not opposing that view entirely, but there
are other views and they were described by scientists that
were/are not actually nuts. (I'll try to find some interesting
references next week, I hope.)

: As to your red herring about Somalia, you still cite no evidence; you only
: state your confidence in a book author's words.

What will count as evidence?

: "tony" <tonygair@btinternet.com> wrote in message

:> Critiscism is not irrational hatred.

(a claim, with an implicit all quantifier)

:> Bombing, strafing and the murder of unarmed civilian crowds in Somalia
:> (The author of blackhawk down describes this in his book) is Irrational
:> hatred and more.

Read as, "as described in the book", and given a truth universally
aknowledged that there is hardly any war not somehow involving
hatred as a motive of acts before/in wars, tony's sentence (this
one) can, I think, indeed be read as a logically valid sentence,
namely an impicit conclusion. (This doesn't say something about
the validity of the premise (the book). However, if I say, "I'm
confident that P /= NP, and based on that ..." this might be no
evidence about P vs NP, but it certainly leeds to sound reasoning
in current cirumstances, doesn't it.  (P vs NP is not something
I know a great deal about but if you allow me to use it for the
sake of the argument...)

:> Opposing the design and production of satanic devices
:> that make this possible is NOT irrational hatred, it is a logical valid
:> method to oppose people who betray Humanity.

I see your point (I think), having read the article about a
clever new weapon in IEEE Software, near Ada pride. However, within
a scenario that involves satan, I can also see that these days
people are not likely to agree that logic starts here.

After all, famous betrayals with murderous consequence have 
been carried out with weapons not originally designed for
murder, but for defence (...) and decoration, viz. daggers.

As a final logical play,
- measured by the number of guns etc. sold, shooting weapons are much
  more popular in the USA than in Europe.
- timelessly popular devices reliably go with efforts to improve them,
  sell more
- a programming language seen in connection with popular things
  will, by the principle of association (like in behaviourism),
  profit from the popularity of the things.
-------------------
  conclusion: ... :-)

regards,
  Georg Bauhaus

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Ingo Marks wrote:
> Michael Erdmann wrote:
> 
> 
>>Kent Paul Dolan wrote:
>>
>>>No, I sign my name "LCDR, Retired" when I care to bother; I don't have
>>>any particular bone to pick with the military.  DoD has abandoned Ada,
>>>that is the problem.  The head has been cut off, the body continues to
>>>twitch.  Ada needs a new mandate, some sense of direction so it doesn't
>>>just continue to march in place, and I don't see it happening.
>>>
>>This is exaclty the impression i have my self. So i was wondering
>>if Ada could take a new direction, when the open source communitiy is
>>more directly involved by establishing a public process in order
>>to enhance the predefined libraries, and may be later, to make an
>>attempt to get these things into ISO etc..
>>
> 
> Who "owns" Ada? The DoD has decided to quit Ada so they don't seem to have 
> any more interest. 
> 
> A new standardization project needs a central place to start. CAD is a good 
> starting point to discuss but the many messages are scattered all over the 
> group and it becomes difficult for me to collect the essence of all ideas. 
> You complained that the focus of this thread is already out of control.
> 
> I would like to suggest to create a new website where you list all your 
> intentions and considerations. People will read them and make comments 
> there and/or here. People will make source code contributions and the whole 
> thing will grow step by step.

May be www.adapower.com is a good place to start?

> 
> Do you want open source library standards for the current Ada 95 standard 
> or do you want to have the language "polished up", too? 

Just the libraries. I would not dare to touch the language.

> 
> Ada is impressive but my first impressions were that some (few) things are 
> unnecessarily complicated which have a deterring effect to newbies. For 
> example string handling. The distinction between fixed and unbounded 
> strings confused me at first (and my compiler produced at lot of error 
> messages ;-) Somewhere I read that the Ada 95 standard would support string 
> handling with garbage collections already (but no compiler has implemented 
> this yet). It would be fine if this could be done in an open source 
> standardization project.
> 
Are there any examples for "..open source standardization projects..."?


> Ingo
> 
> 

Re: Development process in the Ada community

[Michael Erdmann]

Georg Bauhaus wrote:
> Michael Erdmann <Michael.Erdmann@snafu.de> wrote:
> 
> : And i am wondering if there could be a processed
> : established which brings these things back into the
> : standard in order to avoid the reinvention of
> : state of the art components.
> 
> Monoism isn't compatible with reality I think, starting

You are right, but i think you have to admind, that the
discussion about the best linked list implementation is
simply not state of the art any more. There should be
a standard list and container concept available for
Ada. Thinking about such components is a wate of time
because as you say theory and implementation are
exisiting. It should find its into the Ada 95 standard.

I think this applies also to other more or less stable
areas like sockets, http protocol etc.

I have to admid GUI's are a bad example because they
are extremly dependant on the perception of a
community. For example compare Windows/Gtk and
the GUI of squeck. They are complelty different
and everybody is happy with it.

What i am targeting for is to get some of the established
technologies into the Ada standard and at the same
time to establish a process which ensures that in the
future other stable interfaces will be added to the
standard.

Regards
    M.Erdmann

Re: Rant! (was) Development process in the Ada community

[Ingo Marks]

Michael Erdmann wrote:

>> I would like to suggest to create a new website where you list all your
>> intentions and considerations. People will read them and make comments
>> there and/or here. People will make source code contributions and the
>> whole thing will grow step by step.
> 
> May be www.adapower.com is a good place to start?

You should ask the maintainer (David Botton) not me.
 
> Are there any examples for "..open source standardization projects..."?

Your project. (Open source standardization project for Ada libraries ;-)

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Ingo Marks wrote:
> Michael Erdmann wrote:
> 
> 
>>>I would like to suggest to create a new website where you list all your
>>>intentions and considerations. People will read them and make comments
>>>there and/or here. People will make source code contributions and the
>>>whole thing will grow step by step.
>>>
>>May be www.adapower.com is a good place to start?
>>
> 
> You should ask the maintainer (David Botton) not me.
I will do this. I think it would be a good idea to keep the
people from http://www.ada-auth.org also in the loop.

> 
>>Are there any examples for "..open source standardization projects..."?
>>
> 
> Your project. (Open source standardization project for Ada libraries ;-)
> 
>
Nice to know, but this is a chance! I guess there where a lot of
attempts in the past, or at least what i have seen in comp.lang.ada.

At least i will contact Mr. Button or at least setup a small
page on my homepage regarding this issue!

Re: Rant! (was) Development process in the Ada community

[Gary Scott]

Michael Erdmann wrote:
> 
> Kent Paul Dolan wrote:
> > "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:
> >
> >>Kent Paul Dolan wrote:
> >>
> >
> >>>The love of doing things one rigid way, with all decisions handed down
> >>>from above, ran square into the software development community, which is
> >>>used to speedy and flexible growth in its tools.
> >>>
> >
> >>This has nothing to do with the DoD.
> >>
> >
> > To the contrary, rigid, top down command structure with limited upwards
> > feedback is quintessentially a military organization model.  No business
> > could long survive with a similarly rigid hierarchy.
> >
> I am not so mutch experienced with the DoD, but to me it sounds
> like what you can often encounter in large companies and they are
> still dominating the market without alwys beeing always the technical
> leader in there domain.

But leadership in the software world so often involves fads, reinvention
of the wheel and calling it by another name, etc.  It's hard to sort
through sometimes as to what's truly a technical advance and what's
merely a regurgitation of something that was available in the 1970's on
an IBM mainframe (html-like text markup).

-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Gary Scott wrote:
> Michael Erdmann wrote:
> 
>>Kent Paul Dolan wrote:
>>
>>>"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:
>>>
>>>
>>>>Kent Paul Dolan wrote:
>>>>
>>>>
>>>>>The love of doing things one rigid way, with all decisions handed down
>>>>>
>>>>>from above, ran square into the software development community, which is
>>>>
>>>>>used to speedy and flexible growth in its tools.
>>>>>
>>>>>
>>>>This has nothing to do with the DoD.
>>>>
>>>>
>>>To the contrary, rigid, top down command structure with limited upwards
>>>feedback is quintessentially a military organization model.  No business
>>>could long survive with a similarly rigid hierarchy.
>>>
>>>
>>I am not so mutch experienced with the DoD, but to me it sounds
>>like what you can often encounter in large companies and they are
>>still dominating the market without alwys beeing always the technical
>>leader in there domain.
>>
> 
> But leadership in the software world so often involves fads, reinvention
> of the wheel and calling it by another name, etc.  It's hard to sort
> through sometimes as to what's truly a technical advance and what's
> merely a regurgitation of something that was available in the 1970's on
> an IBM mainframe (html-like text markup).

I agree completly on what you are saying, the same thing in the context
of different technologies has completly different impact (sgml/xml is
a good example is think) But Ada 95 should support some of the common
practices (like networking, dynamic lists...) through it's standard,
avoiding us from reinventing the same common things in the same
technical context (in this case Ada 95) all over again. For example
with Ada you dont have to think about communication between tasks
any more because the language supports it, before this you had
the burden of implementing of selecting a tasking system.

Regards
    M.Erdmann



> 
> 

Re: Rant! (was) Development process in the Ada community

[Larry Kilgallen]

In article <3CB9375F.8040904@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:

> This is exaclty the impression i have my self. So i was wondering
> if Ada could take a new direction, when the open source communitiy is
> more directly involved by establishing a public process in order
> to enhance the predefined libraries, and may be later, to make an
> attempt to get these things into ISO etc..

Don't worry about getting it into the ISO standards, just get people
using a common set of packages and the rest will follow.  There were
recent efforts here in this newsgroup in the area of containers; you
are free to choose a different venue.

There is _nothing_ about the ISO process that is holding you back,
and libraries/packages have little to do with core language changes.

Re: Development process in the Ada community

[Larry Kilgallen]

In article <3CB93DAD.3030007@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> Larry Kilgallen wrote:
>> In article <3CB880AF.5080407@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
>> 
>>>Larry Kilgallen wrote:
>>>
>> 
>>>>Is it ISO document charges that you are complaining about ?
>>>>
>>>Yes, this is one face of the problem.
>>>
>> 
>> Personally I am happy to pay ISO document charges,
>> but that is not required for the Ada Reference Manual.
> Who is sponsering this, US Goverment?

Who is sponsoring what ?

You can find the Ada Reference Manual at http://www.adapower.com .

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Larry Kilgallen wrote:
> In article <3CB9375F.8040904@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> 
> 
>>This is exaclty the impression i have my self. So i was wondering
>>if Ada could take a new direction, when the open source communitiy is
>>more directly involved by establishing a public process in order
>>to enhance the predefined libraries, and may be later, to make an
>>attempt to get these things into ISO etc..
>>
> 
> Don't worry about getting it into the ISO standards, just get people
> using a common set of packages and the rest will follow.  There were
> recent efforts here in this newsgroup in the area of containers; you
> are free to choose a different venue.

Did they manage to get this into an Appendix of the Ada 95 RM, or
did they succeed with there container packages?

> 
> There is _nothing_ about the ISO process that is holding you back,
> and libraries/packages have little to do with core language changes.
> 
The problem is now to find the correct platform (organisation) to
develope the process. Is there already something in the community
or has something new to be setup?
My idea is to use the ISO ARC WG9 as a start platform.

Regards
    M.Erdmann

Re: Development process in the Ada community

[tmoran]

> You will find in the Ada 95 communit a lot of open
> source software solutions covering the following topics:
> ....XML,SOAP + 1 Million implemantions of lists and container

  Why is it that the available solutions are a mile wide but an inch deep?
Everybody wants to build an alternative to X, but nobody wants to build on
top of X.  What are the rewards/difficulties of building a new alternative
to X?  What are the rewards/difficulties of building something more complex
that -uses- X?  Apparently the latter is worse.

  As Randy Brukardt noted the other day, the original idea for Claw "was to
create a de facto standard, make a subset freely available, and eventually
put the binding into the public domain to be a standard."  But it didn't
happen.  Recently someone complained that Claw didn't currently support
several features he needs.  Nobody, to my knowledge, has added support for
X to Claw, but multiple people have created alternative Windows bindings,
none of which has become a standard, and none of which supports the
features that writer needed.  So he plans to use C++.  The same for
"a lot of open source software solutions covering ..."

  Given all the time in the world, it's a fine thing to "let 100 flowers
bloom" and explore all the alternative ways of doing X.  That does not get
you beyond X, however.

Re: Rant! (was) Development process in the Ada community

[Larry Kilgallen]

In article <3CB9AF3C.8030301@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> Larry Kilgallen wrote:
>> In article <3CB9375F.8040904@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes:
>> 
>> 
>>>This is exaclty the impression i have my self. So i was wondering
>>>if Ada could take a new direction, when the open source communitiy is
>>>more directly involved by establishing a public process in order
>>>to enhance the predefined libraries, and may be later, to make an
>>>attempt to get these things into ISO etc..
>>>
>> 
>> Don't worry about getting it into the ISO standards, just get people
>> using a common set of packages and the rest will follow.  There were
>> recent efforts here in this newsgroup in the area of containers; you
>> are free to choose a different venue.
> 
> Did they manage to get this into an Appendix of the Ada 95 RM, or
> did they succeed with there container packages?

To the best of my knowledge, they have not yet achieved consensus
and multiple implementations among those who are most anxious to
see such capability.  That is the first step.  Even for language
core features, the GNAT implementation of Ada is ready-made for
local experimentation prior to proposal for standardization.

>> There is _nothing_ about the ISO process that is holding you back,
>> and libraries/packages have little to do with core language changes.
>> 
> The problem is now to find the correct platform (organisation) to
> develope the process. Is there already something in the community
> or has something new to be setup?

The problem is to create a useful detailed proposal, with multiple
worked examples.  To the best of my knowledge, the ARG will consider
such an example when presented.

Check the Lists discussions on this newsgroup within the past few
months for a good example.  There was a lot of discussion about
features that are needed, and nobody was worried about how to get
it standardized.

Re: --off topic Re: Rant! (was) Development process in the Ada community

[Chad R. Meiners]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a9bnbb$1bk$1@a1-hrz.uni-duisburg.de...
> Chad R. Meiners <crmeiners@hotmail.com>
> wrote about tony's comments:
> : Note that rhetoric does not deal with truth, but it does deal in
impressing
> : ideas upon people.
>
> That's a relatively recent (and narrowed) meaning of the word, afaik.
> Until few centuries ago, rhetoric counted as number two of the arts,
> close to logic, grammar, dialegein (not to be confused with the
> simple concept of yes/no/together again), and, in roman days, courts.
> Thus of course in those days it had to do with truth, in several ways.

I am aware of this.  Of course since we are in the here and now and the
modern definition works, I didn't try to use the old definition in this
case.
>
> : As
> : to your supposed 'criticism', in order for criticism to be valid it must
be
> : a well formed argument
>
> O.K.
>
> : and be logically consistent.
>
> That again is a modern axiom held by many scientists. By a
> mechanism known as group pressure it has become a dominant
> view in several scientific discussions, despite it's known
> difficulties. I'm not opposing that view entirely, but there
> are other views and they were described by scientists that
> were/are not actually nuts. (I'll try to find some interesting
> references next week, I hope.)

I am sure your are well aware that you can prove anything from a logically
inconsistent statement.  E-mail me the references; I'll be glad to look at
them.  As I mention before, logic is our best defense against improper
conclusions, not our only defense.

> : As to your red herring about Somalia, you still cite no evidence; you
only
> : state your confidence in a book author's words.
>
> What will count as evidence?

It depends, but paraphrasing a book is a little weak for the type of
accusations.  If I actually wanted to argue about what the US military did
or did not do, I would be more than willing to reason with Tony's or was is
and is not valid axioms and facts.  I really just want to persuade people to
argue better.

> : "tony" <tonygair@btinternet.com> wrote in message
>
> :> Critiscism is not irrational hatred.
>
> (a claim, with an implicit all quantifier)
>
> :> Bombing, strafing and the murder of unarmed civilian crowds in Somalia
> :> (The author of blackhawk down describes this in his book) is Irrational
> :> hatred and more.
>
> Read as, "as described in the book", and given a truth universally
> aknowledged that there is hardly any war not somehow involving
> hatred as a motive of acts before/in wars, tony's sentence (this
> one) can, I think, indeed be read as a logically valid sentence,
> namely an impicit conclusion. (This doesn't say something about
> the validity of the premise (the book). However, if I say, "I'm
> confident that P /= NP, and based on that ..." this might be no
> evidence about P vs NP, but it certainly leeds to sound reasoning
> in current cirumstances, doesn't it.  (P vs NP is not something
> I know a great deal about but if you allow me to use it for the
> sake of the argument...)

I think you misunderstood to what I was referring.  I have always been
referring the Tony's original 'criticism' which was not a valid argument.
When I was referring to the red herring I was trying to point out the
overgeneralization as a example of what happens when you are not careful
when you form your arguments.  I really should just label red herring's and
leave them be.  Good example with the P /= NP.

> :> Opposing the design and production of satanic devices
> :> that make this possible is NOT irrational hatred, it is a logical valid
> :> method to oppose people who betray Humanity.
>
> I see your point (I think), having read the article about a
> clever new weapon in IEEE Software, near Ada pride. However, within
> a scenario that involves satan, I can also see that these days
> people are not likely to agree that logic starts here.
>
> After all, famous betrayals with murderous consequence have
> been carried out with weapons not originally designed for
> murder, but for defence (...) and decoration, viz. daggers.

Of course most weapons were designed to hunt ;) (barring heavy weaponry)

> As a final logical play,
> - measured by the number of guns etc. sold, shooting weapons are much
>   more popular in the USA than in Europe.
> - timelessly popular devices reliably go with efforts to improve them,
>   sell more
> - a programming language seen in connection with popular things
>   will, by the principle of association (like in behaviourism),
>   profit from the popularity of the things.
> -------------------
>   conclusion: ... :-)

Are you trying to imply that since a programming language associated with
something cool becomes cool itself and that guns are cool in the USA, Ada's
reputation should be cool in the USA since it is used to make reliable
weapons?   Of course you still need to show all the assumed implications are
valid, but we really shouldn't need to go there.

> regards,
>   Georg Bauhaus

-CRM

Re: Development process in the Ada community

[Kent Paul Dolan]

"Gary Scott" <scottg@flash.net> wrote:

> I wish someone would resurrect GKS/CGM.  I love those.  It needs to be
> modernized a little, but I like the clear clean terminology and design. 
> There are only a few things that I prefer about IBM's GDDM over GKS.

Why bless your heart!

There was a half-hearted GKS implementation or binding, I'm not sure
which, for Ada 83, I believe in AdaSAGE; if it had been completed to
handle all the interactive issues, GKS would probably be one of a
working set of graphics packages highly used by the Ada community.

I cannot really blame the implementors, though, when MS-Windows is the
dominant platform and is infamous (at least with me, from harsh
experience writing shrink-wrap software some time ago) for having few or
no device interface standards.  Doing a full up GKS when there is
nothing standard to which it can interface is really tough.  That is
what the VDI (virtual device interface) was supposed to accomplish, but
for all of me, that standard seems to have disappeared without a trace.

The closest thing that exists today to a virtualized device interface is
embedded in the Java Virtual Machine, and I'm too new to Java to know
whether it really caters for all the nastiness of printing and all the
various pointing and clicking devices.

xanthian.

On the bright side, a _lot_ of the interface devices that were popular
back in the GKS days seem to have become deprecated by time; I don't see
many analog to digital devices for real valued input in my limited
viewport to the world, though there are a few 3D mice floating about of
which I'm vbaguely aware.

As to an upgraded GKS, the standards committee is always open to new
membership.

This little tidbit will prove interesting:

Binding Status: The Ada binding to GKS (GKS/Ada) is an ANSI/ISO
standard.

Documentation: The ANSI GKS/Ada Binding is published by ANSI as document
#X3.124.3.  The International Standard is published as ISO 8651-3.  To
inquire about availability of either standard, contact: ANSI, 1430
Broadway, New York,
NY 10018; tel (sales): 212/354-3300; general: 212/354-3300

For more information, contact: Richard F. Puk, Chairman, X3H3.4, Puk
Consulting Services, 7644 Cortina Court, Carlsbad, CA 92009-8206; tel:
619/753-9027; fax: same as phone; e-mail: rpuk@ajpo.sei.cmu.edu.

Found here:

http://archive.adaic.com/tools/bindings/GKS/GKS-bindings.txt

I have no idea whether Dick Puk is still X3H3 Chairman, and I was
baffled by the ANSI main site that it doesn't seem to index its
technical committees.

[ I once implemented full bells-and-whistles 3D graphics on a
stroke-drawn machine from a SIGGRAPH article by Dick Puk; he and I go
back a couple of decades. Neither would recognize the other by now. ]



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Development process in the Ada community

[Kent Paul Dolan]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:

> Again, I ask, what does this have to do with Ada95 ?

Nothing, I was replying only to the one line of yours which I quoted.

xanthian.


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Development process in the Ada community

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a96mhq$li6$1@nh.pace.co.uk>...
> It always will be impossible so long as there exists two or more GUI
> platforms that look & feel different. But that doesn't mean that something
> couldn't be done anyway.

Well of course *something* could be done. However, I don't believe
anything particularly *useful* can be done. As far as anything useful
can be done, the GtkAda folks have already done it.


> It could go a couple of ways. One would be to say "Here's a minimal
> conforming set of classes that do GUI work in such a way as to be a
> least-common-denominator across some reasonably wide set of platforms. That

That was the AWT approach. The result was that the Java community
abandoned it and started over from scratch. As we don't have the
resources they do, I propose that we cut out the middle-man. :-)

> Another way to do it would be to just simply define an Ada-GUI that is its
> own thing. With a graphics engine and a markup language based on XML and the

Since that's essentially what Gtk is, what precisely would be the
advantage of doing it ourselves rather than leveraging off of the Gtk
work like the GtkAda folk have done?


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Marin David Condic]

Yeah, I like that idea, but I could still see some point in a lower level
binding. On the one hand, it would be nice to have an interface that
sent/received data to/from one or more partners that is based purely on
streams & hides the underlying mechanisms. On the other hand, there are
going to be lots of occasions where what you need is basically a one-to-one
connection to Sockets that just looks Ada-ish instead of C-ish. (It could
still use streams, obviously).

Since the lower level binding is likely to be needed for producing any
higher level communication abstraction, I'd say that it constituted A Good
Start if it could become an Ada "convention". A higher level abstraction
starts becoming problematic since there are so many possible ways of
designing inter-process communication. Would it be one-to-one or
one-to-many? Would it be some sort of message-registration and mailboxes? Or
would you just have some general message queue that sees everything and the
app discards what it doesn't want? See what I mean? It would be hard to come
up with a model that would keep everyone happy. Better to get a lower level
binding out there as a start and continue to think about a higher level
abstraction for a later date.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
news:3CB77331.2030005@snafu.de...
>
> I guess a more sbatract concept for interprocess communication on basis
> of streams would be more apropriate. Personally i am always in favor of
> complext services provided to the developen rather than doing low
> level coding using a thin binding.
>

Re: Development process in the Ada community

[Ted Dennison]

tmoran@acm.org wrote in message news:<zPlu8.90$2a2.158913722@newssvr13.news.prodigy.com>...
>   As Randy Brukardt noted the other day, the original idea for Claw "was to
> create a de facto standard, make a subset freely available, and eventually
> put the binding into the public domain to be a standard."  But it didn't
> happen.  Recently someone complained that Claw didn't currently support
> several features he needs.  Nobody, to my knowledge, has added support for
> X to Claw, but multiple people have created alternative Windows bindings,
> none of which has become a standard, and none of which supports the

I would submit that this is because the "release it to the public
domain" step was never followed through on. If they had done that
first, instead of planning on doing it last, things might have been
different.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:pHYt8.15029$sL6.2187840@news11-gui.server.ntli.net...
>
> It is a shame that COBOL has Fujitsu to develop COBOL.NET but
> that Ada has no such large corporate to perform this sort of work.
> Without such a sponsor it is hard to see how Ada gets out of the
> catch22 of:
> User:        "Why use Ada when it doesn't support feature X?"
> Vendor:    "Why support feature X when there is no user demand?"
>
Maybe its worth looking for a big corporate sponsor? A corporation that is
looking to distinguish itself as something "different" from the rest of the
pack? The Ada vendors have the problem that they lack the resources to sink
into tools/targets "on spec" that something will emerge. But for a large
corporation that may have the need for such products (internally or
externally), the development cost might look like a spit in the bucket.
Maybe finding some "strategic partners" creates advantages for Ada as well
as advantages for the parties involved.

Of course there are always those sticky cliche's about "riding on the back
of the tiger" or "getting into bed with an elephant" and such to serve as a
reality check. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:qnlsMmlYZCr9@eisner.encompasserve.org...
> In article <3CB9375F.8040904@snafu.de>, Michael Erdmann
<Michael.Erdmann@snafu.de> writes:
>
> > This is exaclty the impression i have my self. So i was wondering
> > if Ada could take a new direction, when the open source communitiy is
> > more directly involved by establishing a public process in order
> > to enhance the predefined libraries, and may be later, to make an
> > attempt to get these things into ISO etc..
>
> Don't worry about getting it into the ISO standards, just get people
> using a common set of packages and the rest will follow.  There were
> recent efforts here in this newsgroup in the area of containers; you
> are free to choose a different venue.
>
> There is _nothing_ about the ISO process that is holding you back,
> and libraries/packages have little to do with core language changes.

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:qnlsMmlYZCr9@eisner.encompasserve.org...
>
> Don't worry about getting it into the ISO standards, just get people
> using a common set of packages and the rest will follow.  There were
> recent efforts here in this newsgroup in the area of containers; you
> are free to choose a different venue.
>
> There is _nothing_ about the ISO process that is holding you back,
> and libraries/packages have little to do with core language changes.

This is true. What matters with respect to libraries is not so much that
they have some rigid, formally defined, validated, ISO standard as it is
that at least most of the vendors provide pretty much the same thing. You
probably want a good deal of flexibility for libraries (at least in their
early lives) so they can be changed as experience dictates. Maybe at some
point when a given library has become very widespread and stable you could
get it declared part of the ISO standard - but you may never really want
that. Yopu may want to maintain the flexibility of being able to easily
change out the library for something else.

If we had some community concensus that one or more libraries was what we
wanted for doing job X, all you'd have to do is persuade the vendors to
distribute it with their compilers and it instantly becomes part of Ada even
if it isn't part of the "standard".

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
news:3CB9AF3C.8030301@snafu.de...
>
> Did they manage to get this into an Appendix of the Ada 95 RM, or
> did they succeed with there container packages?
>
Getting any sufficiently complex library into an appendix of the ARM would
be very difficult and problematic. You would need to formally specify the
behavior and then come up with a formal validation process. Any package or
set of packages that might have hundreds of interface details would become a
major problem to incorporate into something as formal as the ARM.

What needs to happen is to have some kind of second tier of "standard" that
doesn't require all that formality. If a thing could be reasonably well
described so that an understanding emerged as to what it should be/do and
the vendors were willing to include it in an identical way (same interface
specs, at least, or reference implementation) in all their implementations,
then you've got your "standard" without needing a ***STANDARD*** :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Development process in the Ada community

[Kent Paul Dolan]

"Ted Dennison" <dennison@telepath.com> wrote:

> I would submit that this is because the "release it to the public
> domain" step was never followed through on. If they had done that
> first, instead of planning on doing it last, things might have been
> different.

Indeed.  The open source concept is built on trust, of which there isn't
all that much around, and stuff needs to be "irrevocably" open source
from the beginning for that trust to be given.  I suppose that is one
point in favor of the Gnu Public License.

xanthian.



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Development process in the Ada community

[Michael Erdmann]

Michael Erdmann wrote:
> Hallo all,
> 
> i am wondering how standards are eveloving in the Ada community.
> In the Java Community there is a process called Java Community
> Process (JCP, http://www.jcp.org/)
> 
> Is there something comparabel in the Ada communitiy? I gues
> if there would be something like this there would be more
> dynamic in the Ada 95 community.
> 

What i got out of this discussion
=================================

Below you find the major topics of this thread with some
subjective statements:

- There is no well establsihed process in the Ada community
   which leads to standarized components.

   There is ISO, but it is a relativly slow an quiet process
   without a large backup from comp.lang.ada communitiy.

- There is a common understanding that standarization would
   be a nice thing, but there are a lot of examples that
   standarization creates nothing usefull.

   But what is the problem with it, if you are never fixing
   you positionthen you will be able to choose next time
   a better direction. So if you find a standard not suitable
   any more, make a new one! This means no dmonating monolits,
   diversification is an issue.

- The questions was raised if there is a community
   problem which originates from the old DoD days.

   May be this is true for old established organisations
   but i dont believe this is the problem of the open
   source communitiy in comp.lang.ada, or at least i cant
   find any evidence for such an assumption.

- What needs to be standarized?

   This was interesting, only a view reactions related to
   what is missing. I thinks this point contains the
   key to the unserstanding of the relativly static
   Ada community. Maybe there is not so mutch to do?

   Personally i am interested not so mutch in the lagnuage
   but in extending the predefined lanaguage environment.


What will i am going to make out of this:
=========================================

Since i still believe there are some things missing
in the predefined language environment i dont like
to drop the issue without having made an attempt to
test where the actual problems are.

I believe that i have to go through the following
natural process

- Having a problem
- Raising interest for my solution within comp.lang.ada.
- Following the old bazar guidleling, release early and
   often
- Include new ideas of the interested people
- Include the ARG WG 9 informative in the process.
- Loop thrught the last three steps until it is
   stable.
- Propose the solution to the ARG WG for inclusion
   in the Ada RM predefined language environment.

I this process works once, maybe the experiences gained
there might lead to an established procedure in the
communitiy, or simply does not work!

So stay tuned, i will setup today a page in my private
webspace:

http://www.snafu.de/~boavista/napc.html

Everybody is invited to participate the program to
make the Ada 95 community a little bit more
dynmaic.


Regards
    M.Erdmann

Re: Development process in the Ada community

[Marin David Condic]

I certainly wouldn't mind at all adopting an existing solution as the
starting point for a standard. The problem is quite often that everybody has
a different idea about what they want and short of having a solution
unilaterally imposed on them, agreement isn't likely. If Claw could evolve
into a generic interface for GUI building (rather than be Windows specific)
then I have no objection to it. It might even be fair to say "Here's the
'official' Ada interface to Windows..." and see if it could migrate
elsewhere at a later point.

But if it were to stand a chance of success, the best way I can think of it
getting accepted would be if it were shipped with most of the Ada compilers
out there so that the developer's thinking would have to be: "Well, I may
not like it, but its here and certainly a lot easier to take advantage of
than to roll my own or go looking for an alternative..."

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


<tmoran@acm.org> wrote in message
news:zPlu8.90$2a2.158913722@newssvr13.news.prodigy.com...
>
>   Why is it that the available solutions are a mile wide but an inch deep?
> Everybody wants to build an alternative to X, but nobody wants to build on
> top of X.  What are the rewards/difficulties of building a new alternative
> to X?  What are the rewards/difficulties of building something more
complex
> that -uses- X?  Apparently the latter is worse.
>
>   As Randy Brukardt noted the other day, the original idea for Claw "was
to
> create a de facto standard, make a subset freely available, and eventually
> put the binding into the public domain to be a standard."  But it didn't
> happen.  Recently someone complained that Claw didn't currently support
> several features he needs.  Nobody, to my knowledge, has added support for
> X to Claw, but multiple people have created alternative Windows bindings,
> none of which has become a standard, and none of which supports the
> features that writer needed.  So he plans to use C++.  The same for
> "a lot of open source software solutions covering ..."
>
>   Given all the time in the world, it's a fine thing to "let 100 flowers
> bloom" and explore all the alternative ways of doing X.  That does not get
> you beyond X, however.

Re: Development process in the Ada community

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0204150628.548b23e8@posting.google.com...
>
> Since that's essentially what Gtk is, what precisely would be the
> advantage of doing it ourselves rather than leveraging off of the Gtk
> work like the GtkAda folk have done?
>
I wouldn't be opposed to declaring GtkAda the annointed answer - with some
eye toward extending its capabilities to be more useful while remaining
portable. What are the odds we'd get the vendors to agree that this was The
Moving Forward Plan?

I think I had something else in mind - GtkAda does store the description of
a GUI in XML, but ultimately it generates code that is compiled/linked for a
given platform. What if there was an engine that interpreted an XML
description of a GUI and you blipped XML text back and forth between the
engine and the Ada program by some convention? Interpreting the XML at
runtime has a lot of advantages and if the connection between the engine and
your Ada program was over TCP/IP, your apps automatically work over the net.

Its not as if you can't do this now by rolling-your-own & working with some
existing things, but why couldn't there be a "conventional answer"?

Something akin to this might make a better answer for a number of reasons.
One of which is that an XML based solution would reduce to a relatively
simple interface for the program that would mean a vendor could be
"compliant" with it without having to do a lot of work. The other is that on
the engine side of it, vendors can distinguish themselves with entirely
different looks-and-feels if this seems desirable. In a sense, it would let
the Ada developer develop as if there were a standard GUI, without actually
needing there to *be* one.

IIRC, Mozilla or someone out there was working on a "standard" XML markup
for GUI descriptions. (Maybe someone can post a link? I seem to have lost
track of it) Starting from here and defining a communication mechanism and a
DOM and you're just about there. Then all you have is the hard part of
generating the XML GUI engine that isn't a gross resource hog. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Development process in the Ada community

[Randy Brukardt]

Ted Dennison wrote in message
<4519e058.0204150645.62003096@posting.google.com>...
>tmoran@acm.org wrote in message
news:<zPlu8.90$2a2.158913722@newssvr13.news.prodigy.com>...
>>   As Randy Brukardt noted the other day, the original idea for Claw
"was to
>> create a de facto standard, make a subset freely available, and
eventually
>> put the binding into the public domain to be a standard."  But it
didn't
>> happen.  Recently someone complained that Claw didn't currently
support
>> several features he needs.  Nobody, to my knowledge, has added
support for
>> X to Claw, but multiple people have created alternative Windows
bindings,
>> none of which has become a standard, and none of which supports the
>
>I would submit that this is because the "release it to the public
>domain" step was never followed through on. If they had done that
>first, instead of planning on doing it last, things might have been
>different.


Couldn't have done that, because it would have left us nothing to
sell -- and thus we'd have been out of business in a hurry. (The ATIP-P
seed money also required a product to sell back to the government to
"recover" the investiment -- which couldn't have been done if there was
no product). We needed the GUI builder to be reasonable before we could
let go of the bindings.

If we hadn't held onto it for the first couple of year, it would never
have gotten to the stability point that it is now. However, it could
have been released a couple of years ago, but by then it was fairly
clear that there was little interest in that.

              Randy.

Re: Development process in the Ada community

[tmoran]

> > X to Claw, but multiple people have created alternative Windows bindings,
> > none of which has become a standard, and none of which supports the
> > features that writer needed.
>I would submit that this is because the "release it to the public
>domain" step was never followed through on. If they had done that
>first, instead of planning on doing it last, things might have been
>different.
  And why then have people created, but not built on, multiple
alternative "Open Source" Windows bindings, none of which has become a
standard, and none of which supports the features that writer needed?

Re: Rant! (was) Development process in the Ada community

[Richard Riehle]

Robert Dewar wrote:

> Hint: anything to do with Microsoft does NOT appeal to students these
> days, who routinely refer to Microsoft as the "dark side", a
> phenomenon that I think MS should be
> paying far more attention too :-)

I can confirm this.   More and more of my students puchase
laptops and immediately install Linux.  They refuse to use
the computers in the official lab because they all run Microsoft
products.

Microsoft, for these students, is characterized by is monopolistic
path into the blue screen of death.   Linux, right or wrong,
represents freedom from unjust restraint.

Richard Riehle

Re: Development process in the Ada community

[Gary Scott]

Kent Paul Dolan wrote:
> 
> "Gary Scott" <scottg@flash.net> wrote:
> 
<snip>

> As to an upgraded GKS, the standards committee is always open to new
> membership.

If I were actually qualified to join one, I'd probably join J3.  But
since I'm not, I'll just stand on the sidelines and criticize.

> 
> This little tidbit will prove interesting:
> 
> Binding Status: The Ada binding to GKS (GKS/Ada) is an ANSI/ISO
> standard.
> 
> Documentation: The ANSI GKS/Ada Binding is published by ANSI as document
> #X3.124.3.  The International Standard is published as ISO 8651-3.  To
> inquire about availability of either standard, contact: ANSI, 1430
> Broadway, New York,
> NY 10018; tel (sales): 212/354-3300; general: 212/354-3300

I have copies of everything except VDI (didn't know about it).  At one
time, I was thinking of writing a binding subset for windows that was
compliant, for my own use.  The only product I was aware of at the time
was by Ematek (bought a product called GSS I think) but it was way too
expensive.  I don't think they offer it any more.  Anyway, I do tend to
pattern most of the libraries I design somewhat on the general design of
GKS and GDDM.  I try to design them more or less language independent as
well, but at least such that it is trivial to create bindings to other
languages.  GDDM does that by using a generic binary RPC-like interface.


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Development process in the Ada community

[Georg Bauhaus]

tmoran@acm.org wrote:

:   Nobody, to my knowledge, has added support for
: X to Claw, but multiple people have created alternative Windows bindings,
: none of which has become a standard, and none of which supports the
: features that writer needed. 

some wild guesses:
Is it too well done, triggering the expectation of a lot of
learning to do for serious use?

Popularity problem in Free Software days?
(i.e., not politically correct :-) :-) :-)

Is there no way of asking business clients to pay you for your
work even if the license doesn't require them (or others) to do
so? I, for one, have no problem of paying craftspeople if I need
their service, and I think I'm not alone.

Georg Bauhaus

Re: Rant! (was) Development process in the Ada community

[Frank]

Hi!

I have seen that Oracle's PLSQL is inspired by the Ada standard. I wonder if
there are
some historical material related to PLSQL vs Ada (?), but I don't know the
history (born too late :-).
To me it looks like Ada had a golden oportunitue to "ride on the back of a
tiger" when the PLSQL
were initiated. Were there some discussion related to this "once upon a
time"?-) Oracle probably
choose their own way due to market analyzis.

Of course this is looking into the past.

Frank

Re: Development process in the Ada community

[Martin Dowie]

> - What needs to be standarized?
> 
>    This was interesting, only a view reactions related to
>    what is missing. I thinks this point contains the
>    key to the unserstanding of the relativly static
>    Ada community. Maybe there is not so mutch to do?
> 
>    Personally i am interested not so mutch in the lagnuage
>    but in extending the predefined lanaguage environment.

An interesting quote from Bjarne Stroustrup on his web page on
what he thinks C++0X should be, is:

"My personal view is that the key principles should be

 no major changes to the language itself 
 major extensions to the standard library"

We are not alone... :-)

Re: Development process in the Ada community

[Marin David Condic]

Lots of models have been tried with mixed success. How exactly do you say
"Here, you can have this product free of charge, but if you feel like it you
can give me some money..." and get that to generate the kind of revenue
needed to continue to support & enhance the product? For something like
Gnat, the model is "You can have the product free of charge, but enough
people will want support to pay for it and that keeps the project afloat."
It apparently works for a compiler reasonably well, but lots of products
have little to zero demand for support. Others have tried "You can have the
source code free of charge, but if you'd like pre-compiled versions with
documentation, we can do that for a price..." That works for other things
like Linux or RTEMS. Crippled versions of things at no charge with
full-features available at a price has sometimes worked - but that doesn't
work well if you are of the One True Religion of "Open Source" :-)

At the end of the day, products need people to develop/enhance/support them
and those people need to do things like eat and pay rent, so *somebody* is
going to have to pay the freight. Even the "free" software out there is paid
for via the developer(s) generosity with their time or their employer's
subsidizing the effort in some manner. I'm of the belief that if Ada
developers find a way to make Ada development pay, it will create more Ada
developers - and that's a good thing for all of us. (How many times do we
see posts with some version of "Ada may be cool, but why should I waste my
time learning it if I can't get a job doing it....?" :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a9gnce$9td$2@a1-hrz.uni-duisburg.de...
>
> Is there no way of asking business clients to pay you for your
> work even if the license doesn't require them (or others) to do
> so? I, for one, have no problem of paying craftspeople if I need
> their service, and I think I'm not alone.
>

Re: Development process in the Ada community

[Marin David Condic]

At some point a language is descriptive enough to express all the things
anyone knows how to say in a sufficiently large number of ways of saying it.
I'd think that until some whole new programming paradigm comes along, both
Ada and C++ have sufficient expressive capabilities. (Maybe filing off some
burrs is in order, but that's about all that can be constructively done.) So
what else is left except adding to predefined libraries to extend the
language capabilities? IDEs and other tools aren't really a language issue
while libraries and execution environments might be. So data structure,
math, GUI, communication, OS and other libraries all sound like good
candidates to me.

It seems like the thing to do at this stage in Ada's life...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Martin Dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:8a63570b.0204160328.de7bf8d@posting.google.com...
>
> An interesting quote from Bjarne Stroustrup on his web page on
> what he thinks C++0X should be, is:
>
> "My personal view is that the key principles should be
>
>  no major changes to the language itself
>  major extensions to the standard library"
>
> We are not alone... :-)

Re: Rant! (was) Development process in the Ada community

[martin.m.dowie]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a9eq3h$7e4$1@nh.pace.co.uk...
> "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
> news:pHYt8.15029$sL6.2187840@news11-gui.server.ntli.net...
> >
> > It is a shame that COBOL has Fujitsu to develop COBOL.NET but
> > that Ada has no such large corporate to perform this sort of work.
> > Without such a sponsor it is hard to see how Ada gets out of the
> > catch22 of:
> > User:        "Why use Ada when it doesn't support feature X?"
> > Vendor:    "Why support feature X when there is no user demand?"
> >
> Maybe its worth looking for a big corporate sponsor? A corporation that is
> looking to distinguish itself as something "different" from the rest of
the
> pack? The Ada vendors have the problem that they lack the resources to
sink
> into tools/targets "on spec" that something will emerge. But for a large
> corporation that may have the need for such products (internally or
> externally), the development cost might look like a spit in the bucket.
> Maybe finding some "strategic partners" creates advantages for Ada as well
> as advantages for the parties involved.
>
> Of course there are always those sticky cliche's about "riding on the back
> of the tiger" or "getting into bed with an elephant" and such to serve as
a
> reality check. :-)

Nice idea, but who?

Boeing are an obvious candidate given their history of Ada use - but is that
still true? And even it it was, it just reinforces the preconception that
Ada is
only any use in the avionics field (which I think we can all appriciate is
not
true).

Reuters news agency I understand use it but not throughout.

CANAL+ could be a better bet - are you out there Pascal?

Anyone else any better ideas?..

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Marin David Condic wrote:
> "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
> news:3CB9AF3C.8030301@snafu.de...
> 
>>Did they manage to get this into an Appendix of the Ada 95 RM, or
>>did they succeed with there container packages?
>>
>>
> Getting any sufficiently complex library into an appendix of the ARM would
> be very difficult and problematic. You would need to formally specify the
> behavior and then come up with a formal validation process. Any package or
> set of packages that might have hundreds of interface details would become a
> major problem to incorporate into something as formal as the ARM.

Interesing, i did not know this. Is there any information about this
in the net? May be this formality is why most of the people in the
community are not taking part in the standarization process.

> 
> What needs to happen is to have some kind of second tier of "standard" that
> doesn't require all that formality. If a thing could be reasonably well
> described so that an understanding emerged as to what it should be/do and
> the vendors were willing to include it in an identical way (same interface
> specs, at least, or reference implementation) in all their implementations,
> then you've got your "standard" without needing a ***STANDARD*** :-)

This is what is normally called a defacto standard. Raising initial 
interest for a certain sloution and setting up alliences to enforce
the solution normally creates such standards. But if these alliences
breaking up, such standards start to dissolve and lot of derivates
of the original solution are back on the market gain. I like to
avoid this.

But your second tier idea may be the right point! This second tier
could become some kind of public entry process for the ISO WG which
is in the first stage (input) less formal and at the output as formal
as ISO requieres.
Establishing such a second tier interface to the public would be
an interesting project for the open source community, and may
be some ideas of the JPC may be taken over for this purpose.

I am realy wondering if there are comparable projects in the
net exisiting?!


Regards
    M.Erdmann

> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> 
> 

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Marin David Condic wrote:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:qnlsMmlYZCr9@eisner.encompasserve.org...
> 
>>Don't worry about getting it into the ISO standards, just get people
>>using a common set of packages and the rest will follow.  There were
>>recent efforts here in this newsgroup in the area of containers; you
>>are free to choose a different venue.
>>
>>There is _nothing_ about the ISO process that is holding you back,
>>and libraries/packages have little to do with core language changes.
>>
> 
> This is true. What matters with respect to libraries is not so much that
> they have some rigid, formally defined, validated, ISO standard as it is
> that at least most of the vendors provide pretty much the same thing. You
> probably want a good deal of flexibility for libraries (at least in their
> early lives) so they can be changed as experience dictates. Maybe at some
> point when a given library has become very widespread and stable you could
> get it declared part of the ISO standard - but you may never really want
> that. Yopu may want to maintain the flexibility of being able to easily
> change out the library for something else.

Yes you may always want to change something, but using standard
components means reliability by beening conservative even if
you are loosing elegance.

> If we had some community concensus that one or more libraries was what we
> wanted for doing job X, all you'd have to do is persuade the vendors to
> distribute it with their compilers and it instantly becomes part of Ada even
> if it isn't part of the "standard".

I dont think that we need the vendors this mutch, most of the popular
open source software is distributed without them (thanks to sites
as sourceforge etc..),

In my mind the idea of a public ada process is showing up:

- There is a job to be done and i have some solution for it. Propose
   the solution to the community (who is this, i gues comp.lang.ada?)

- If sufficient interest has been raised, form a working group
   for this topic and provide an implemenation for public use.

- Proceed until wide acceptance

- Propose to ISO

But this is nothing new, this is the typical open source process as
we know it, the only difference is the last step. I think this is
your second tier idea. May be it is possible to setup a new way of
communication between the public and the ISO WG making the entry
more easier for us. Or maybe it would be a good idea if ISO acts
more proactive by asking the comminity  for entires on certain issues
(e.g. containers etc..)!

Regards
    M.Erdmann







> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> 
> 

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:fFXu8.31411$tZ1.7228185@news2-win.server.ntlworld.com...
>
> Nice idea, but who?
>
Good question. Defer for a moment, but think along the lines of "Big Into
Computers..."


> Boeing are an obvious candidate given their history of Ada use - but is
that
> still true? And even it it was, it just reinforces the preconception that
> Ada is
> only any use in the avionics field (which I think we can all appriciate is
> not
> true).
>
From rumors I've heard Boeing is drifting away from Ada for a lot of the
same reasons as other aerospace firms - the programmers want to work in
something more marketable.

Besides, Boeing is an airframer and not a computer company, so they have
limited influence on what other computer companies would do. Unless maybe
you just want to sell them on the idea of building a development environment
for various systems and have them pay the freight of doing the development
cost. But then they've got an ownership interest which they'd have to be
stupid to ignore - and you're in bed with the elephant.

> Reuters news agency I understand use it but not throughout.
>
Probably not big enough and certainly not in the "technology" business to
want to finance some computer project.


> CANAL+ could be a better bet - are you out there Pascal?
>
Maybe - but are they big enough and interested enough to finance some sort
of Ada endeavor?


> Anyone else any better ideas?..
>
Some of this depends on what you think you want to do as far as "A Thing
Financed By A Deep Pockets Contributor That Has A Side Effect Of Promoting
Ada..."

Say the objective is to build the world's spiffiest IDE for/with Ada. Ada's
advantages are reliability and portability. Suppose you had someone like
Compaq who thought it might be attractive to the market to provide
OS-agnosticism: "Yeah, we'll give you a computer with Windows or Linux or
Both!" (It would distinguish them from Sun, and other PC makers maybe?) But
now they've got to encourage development that compliments their strategy.
Suppose they could offer developers a kit that would let them use gcc-based
compilers to target both OS's? We say: Sure! No sweat! We can build an IDE &
some libraries and what have you that lets an app builder develop for one
direction and recompile to go the other way. We can fix it so that any of
the gcc based compilers could be your choice for development
(language-agnostic) but we implemented in Ada, so it will just be more
natural and easy to use Ada...

Or suppose that IBM figures that its time to produce the next generation of
personal computer and try to regain the market share it once had? We say:
Sure! We can help! We'll go build you a new state-of-the-art OS programmed
in Ada that will distinguish your product with higher reliability and
security...

Or much nearer and dearer to my heart: What about the Digital TV set-top box
business? If we were proposing to build an OS/Development package that
targeted this sort of device and offered higher reliability with faster time
to market, etc. as a consequence of including Ada software, you've got
access to a whole burgeoning market that is likely to attract lots of new
developers.

Where I'm going with this is somewhere along the lines of dreaming up a
whole product that has Ada as a significant component and selling the idea
to some big guy in that market. Get them thinking along the lines of
incorporating Ada as a key piece of their product. You'd have to think of
something that leaves them to some extent "language neutral" since they
won't want to jump into Ada with both feet and not have alternatives. The
strategy there is to dream something up that says "You can use any language
you want - it will just be easier with Ada because that's where it all comes
from..." (That's one of the reasons C got to be big, right?)

Think about it......

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
news:3CBC5281.1040202@snafu.de...
>
> Interesing, i did not know this. Is there any information about this
> in the net? May be this formality is why most of the people in the
> community are not taking part in the standarization process.
>
Well think about some of the packages that are in the appendices right now.
Things like Ada.Strings.Fixed. There is a quite detailed description of the
behavior of each subprogram in there and I'd suspect you need some part of
the validation suite aimed at testing compliance with that specification.
Furthermore, all they provide is a spec and that means the vendors have to
go out and build the bodies - which for a string package may not be that big
a deal, but for something like - say - a GUI would be *waaayy* much bigger
and would hence meet resistance from the vendors. (Do you really think
they're just chomping at the bit to rush out and spend millions just to get
themselves compliant with the next Ada standard? ;-)


>
> This is what is normally called a defacto standard. Raising initial
> interest for a certain sloution and setting up alliences to enforce
> the solution normally creates such standards. But if these alliences
> breaking up, such standards start to dissolve and lot of derivates
> of the original solution are back on the market gain. I like to
> avoid this.
>
Trying to do anything real formal to avoid divergence is just going to get
too costly and difficult. What might work better is some version of
"Standardization By Inertia" If you got some committee of vendors and users
to agree on some libraries as the de facto standard and there was a
reference implementation the vendors all adopted, chances are it would just
stay the way it is because nobody is going to want to spend their own money
to change it without a compelling reason.

Think, for example, if all the vendors agreed to just ship the Booch
Compoinents with their compilers and make it the de facto standard. People w
ould be using them based on what they knew of the reference implementation
and they'd expect their vendor to give them a conforming copy. If extensions
were desired, there'd be a strong incentive to get them into the reference
copy so long as doing so wasn't unnecessarily difficult. (The users and the
vendors don't want to go updating everything in the world if BC v2.0 comes
out with differences from their divergent paths.)


> But your second tier idea may be the right point! This second tier
> could become some kind of public entry process for the ISO WG which
> is in the first stage (input) less formal and at the output as formal
> as ISO requieres.
> Establishing such a second tier interface to the public would be
> an interesting project for the open source community, and may
> be some ideas of the JPC may be taken over for this purpose.
>
I really think that once you stick the initials "ISO" on it you're asking
for a rigid, validatable, *sloooooow* process to be put in place. It would
be better to form something up under some less formal structure. It might
work better to do something under the auspices of SIGAda - that's how ASIS
got done, IIRC. You need the input and guidance of the vendors because if
they won't sign up to include/implement whatever you come up with, the whole
game is over. If the vendors said "We'd be interested in libraries that
cover the following subjects...." and your working group could come up with
an answer they'd be willing to adopt, *and* you could come up with the
necessary resources to build a reference implementation, you might see a
fairly quick and agile process evolve that probably wouldn't see a lot of
divergence from the "standard".

I really doubt that lobbying for *anything* to happen under ISO is going to
result in any sort of process that meets the objectives you seem to be
supporting. The less formal it is, the more likely it will be to move
quickly and be willing to listen to what you have to say. If you got
something that was adopted as a de facto standard, it would likely be a lot
easier to get it included into the ISO standard after that point - if that
seems at all important if/when that happens.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Development process in the Ada community

[tmoran]

> :   Nobody, to my knowledge, has added support for
> : X to Claw, but multiple people have created alternative Windows bindings,
  Sorry, I didn't mean that nobody has added anything to Claw since its
birth, I meant nobody has recently become a new Claw developer.  People
could post additional Claw modules in the public domain or with a
license of their choosing, either to work with full ($>0) Claw, or to
work with the $=0 version, or they could make an arrangement with RR
Software.  Claw is pretty straightforwardly structured (see the original
TriAda article at www.rrsoftware.com) so it wouldn't be all that hard.
Maybe people have been bombarding Randy Brukardt with offers to do this,
but I doubt it.  A previous writer asked for interfaces to midi, data
entry widgets with popup calculator, etc.  etc.  so there is demand.
But multiple people have spent a lot of time creating alternative
Windows bindings.  Not that those aren't good, especially when, as in
JEWL, they address a special audience, but it does mean that someone who
wants a midi interface does not find it on the shelf, and goes looking
instead to C++.  (Presumably after checking out gnatcom)

Re: Rant! (was) Development process in the Ada community

[Ingo Marks]

Michael Erdmann wrote:

> In my mind the idea of a public ada process is showing up:
> 
> - If sufficient interest has been raised, form a working group
>    for this topic and provide an implemenation for public use.

I would like to recommend to ask as many Ada website maintainers (like 
www.adapower.net) as possible to include a link to your project page 
together with some short description. Maybe developers visiting these sites 
could be made curious.

Regards
Ingo

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
news:3CBC56F0.9050300@snafu.de...
>
> Yes you may always want to change something, but using standard
> components means reliability by beening conservative even if
> you are loosing elegance.
>
I'm not arguing against standards. I'm arguing in favor of a process that
might mean a fresh release once a quarter that incorporates the latest and
greatest ideas and extensions. You'd want to keep your interfaces as stable
as possible, but allow for a process that would allow fixes, improvements
and new things to enter into it (and be included in vendor distributions)
without waiting for a ten-year language-revision-cycle to happen.


>
> I dont think that we need the vendors this mutch, most of the popular
> open source software is distributed without them (thanks to sites
> as sourceforge etc..),
>
Sure. You can always go put yet another container library out on the net
somewhere and probably find a fair number of takers who will "standardize"
on your particular library for their own development. (How many are out
there as we speak?) The trick is to get one of the many fine container
libraries that exist or may one day exist to be the one that everybody uses.
If the vendors aren't in on it and don't include it along with their
compiler distribution such that everyone knows they could either use what is
there or go their own way and not be portable, then you've got the situation
we have now: Lots of fine container libraries available and none of them The
Standard. (I use container libraries just as an example. The same applies to
any other collection of components/tools one might care to discuss.)

That's why I think the vendors have to be behind it. If the same thing comes
with (almost) every compiler, then it *is* the standard regardless of it
being in the ARM or not. (I can always come up with Marin.Strings.Fixed and
it might be fine for my needs, but would people use it if they new all they
had to do was go: "with Ada.Strings.Fixed;" and have something everyone knew
about and understood?)

>
> - Propose to ISO
>
Maybe. One day. But I still think that's asking for a lot of cost and time
that would likely kill something in the process.


> But this is nothing new, this is the typical open source process as
> we know it, the only difference is the last step. I think this is
> your second tier idea. May be it is possible to setup a new way of
> communication between the public and the ISO WG making the entry
> more easier for us. Or maybe it would be a good idea if ISO acts
> more proactive by asking the comminity  for entires on certain issues
> (e.g. containers etc..)!
>
My second tier idea is simply some process for producing an agreed-upon
language extension (library, not syntax/semantics) that gets acceptance by
the vendors and the community at large. Its hard enough to get an agreement
in an informal setting (we've tried here before, right? :-) that I think
anything that starts moving towards "Let's go get ISO to accept it..." is
going to guarantee failure.

I'm suggesting that we'd be far better off setting the goals to something a
little more achievable and see where it goes. If one day, it makes it back
into ISO, fine. But I think just getting it into common usage is enough of a
windmill to tilt at. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

[OT] MS vs Linux vs who in the student heart? (still mostly): Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Richard Riehle" <richard@adaworks.com> wrote:

> Robert Dewar wrote:

> > Hint: anything to do with Microsoft does NOT appeal to students these
> > days, who routinely refer to Microsoft as the "dark side", a
> > phenomenon that I think MS should be
> > paying far more attention too :-)

Yep, it's still a fact, in our virtual universe, that reputation is the
only solid asset, and Microsoft seems to have spent theirs dry.

> I can confirm this.   More and more of my students puchase
> laptops and immediately install Linux.  They refuse to use
> the computers in the official lab because they all run Microsoft
> products.

What pleasant news!  By the time I am 80, this generation will be in
charge of technology buying, and Microsoft products won't even be
considered.  Life is going to be much, much better.  I wonder who the
bad guys will be by then?

> Microsoft, for these students, is characterized by is monopolistic
> path into the blue screen of death.

It's probably too late for Microsoft already, but about a dozen *free*
OS upgrade releases with no new features, just bug-fixes, with all their
software talent focused on wringing out bugs, would go a long way toward
salvaging their ruined reputation.  My experience ends with NT, but at
least up to there, application programs can still crash the OS, not an
acceptable situation, and part of the reason the 24x7 online community
is so disgusted with NT.

> Linux, right or wrong,
> represents freedom from unjust restraint.

We'll see; another evil empire of old bought into the Linux world
big-time, and has, from my personal experience as an insider, still not
learned from past rejection of monopolistic tactics any new ethics of
corporate culture to prevent its trying to steamroll its way to success
in the face of absolute resistance from the customer / user community to
such tactics.  I'm fearful Linux is going to end up wholly captive and
ground under the same boot-heels.

xanthian.



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: [OT] MS vs Linux vs who in the student heart? (still mostly): Rant! (was) Development process in the Ada community

[Adrian Hoe]

Kent Paul Dolan wrote:
> 
> "Richard Riehle" <richard@adaworks.com> wrote:
> 
> > Robert Dewar wrote:
> 
> > > Hint: anything to do with Microsoft does NOT appeal to students these
> > > days, who routinely refer to Microsoft as the "dark side", a
> > > phenomenon that I think MS should be
> > > paying far more attention too :-)
> 
> Yep, it's still a fact, in our virtual universe, that reputation is the
> only solid asset, and Microsoft seems to have spent theirs dry.
> 
> > I can confirm this.   More and more of my students puchase
> > laptops and immediately install Linux.  They refuse to use
> > the computers in the official lab because they all run Microsoft
> > products.
> 
> What pleasant news!  By the time I am 80, this generation will be in
> charge of technology buying, and Microsoft products won't even be
> considered.  Life is going to be much, much better.  I wonder who the
> bad guys will be by then?
> 
> > Microsoft, for these students, is characterized by is monopolistic
> > path into the blue screen of death.
> 
> It's probably too late for Microsoft already, but about a dozen *free*
> OS upgrade releases with no new features, just bug-fixes, with all their
> software talent focused on wringing out bugs, would go a long way toward
> salvaging their ruined reputation.  My experience ends with NT, but at
> least up to there, application programs can still crash the OS, not an
> acceptable situation, and part of the reason the 24x7 online community
> is so disgusted with NT.
> 
> > Linux, right or wrong,
> > represents freedom from unjust restraint.
> 
> We'll see; another evil empire of old bought into the Linux world
> big-time, and has, from my personal experience as an insider, still not
> learned from past rejection of monopolistic tactics any new ethics of
> corporate culture to prevent its trying to steamroll its way to success
> in the face of absolute resistance from the customer / user community to
> such tactics.  I'm fearful Linux is going to end up wholly captive and
> ground under the same boot-heels.
> 
> xanthian.
> 
> --
> Posted via Mailgate.ORG Server - http://www.Mailgate.ORG



I broke Windows and breathed free air many years back. But I think the
glass is still around at least it will stay for some time in Asia
regions. The trend is very obvious. Hardware giant like Dell, Compaq and
HP are reluctant to bundle Linux with their machines for Asian markets.
Why? The people here have been stupefied by advertisement and TV tech
programs. That's why the Windows still refrain the market in this
region. Nevertheless, Linux is getting popular here, at least slowly.

It is the same to Ada in this region. Only a few "rebels" who seek
different direction make the shift.
-- 
Remove *nospam* to email.              -- Adrian Hoe
                                       -- http://adrianhoe.com

Re: Rant! (was) Development process in the Ada community

[Richard Riehle]

Ingo Marks wrote:

> Who "owns" Ada? The DoD has decided to quit Ada so they don't seem to have
> any more interest.

OK, let's get this straight.    The DoD has not decided to quit Ada.   I still
correspond with former Assistant Secretary of Defense Emmett Paige
from time to time and I gather that one of his disappointments is the
misinterpretation of his memo abrogating the Ada mandate.   If I may
take the liberty of defending his original intent, he expected Ada to be
a language among others, still used, when appropriate for DoD software
systems.   His memo says a Software Engineering Review Process (SEPR)
should be determining factor for choosing a programming language.   Very
few DoD contractors are paying attention to this order any more than they
did the original Ada mandate.

Ada is still being chosen for DoD software projects, even though it is not
being chosen as often as it was before Secretary Paige's memo.  Some
developers, having evaluated C++ and discovered just how error-prone
it is, have decided to stick with Ada.  Others, unable to admit their
monumental stupidity, have dug in and pushed ahead with C++.  They
will, of course, rue the day they decided to use C++ instead of Ada, but
that will never become public knowledge.   Already, many of them have
decided to use Java instead of C++ instead of admitting they would have
been better off with Ada.

Those who have chosen to stick with Ada are doing well with it.

As for the DoD deciding to abandon Ada.  There are certainly program
managers, employed by the Dod, who have misunderstood Secretary
Paige's memo.   There are program managers who have been hoodwinked
into a misunderstanding by DoD software developers.    However, there
are still program managers who specify Ada as a first choice because
they understand its merits.   I have a little contact with some of these
managers and have taken the time to educate those willing to listen
regarding the advantages and disadvantages of competing choices
among languages.   Those who understand will continue to make the
right choice.  Those who don't will continue to be led into bad
decisions by the media and the contractors.

Richard Riehle

Re: Development process in the Ada community

[Richard Riehle]

Ted Dennison wrote:

> tmoran@acm.org wrote in message news:<zPlu8.90$2a2.158913722@newssvr13.news.prodigy.com>...
> >   As Randy Brukardt noted the other day, the original idea for Claw "was to
> > create a de facto standard, make a subset freely available, and eventually
> > put the binding into the public domain to be a standard."  But it didn't
> > happen.  Recently someone complained that Claw didn't currently support
> > several features he needs.  Nobody, to my knowledge, has added support for
> > X to Claw, but multiple people have created alternative Windows bindings,
> > none of which has become a standard, and none of which supports the
>
> I would submit that this is because the "release it to the public
> domain" step was never followed through on. If they had done that
> first, instead of planning on doing it last, things might have been
> different.

And who was going to pay Randy and RR Software for their effort in
developing CLAW?    It is all well and good to want free software,
but someone, somewhere needs to pay for it.    One reason we don't
see more bindings to more environments for Ada is the widespread
reluctance of people to commit resources when there is no financial
benefit.   Even GNAT will disappear if ACT discovers there is
no financial reward in supporting it.

Tom Moran is right when he complains that so many have spent so
much energy creating partial implementations that discourage the
use of CLAW instead of getting on board and adding to its already
powerful set of capabilities.   I suspect Randy would not turn down
any offer of help in developing additional packages to extend the
CLAW software.

Richard Riehle

Re: Development process in the Ada community

[Richard Riehle]

tmoran@acm.org wrote:

> But multiple people have spent a lot of time creating alternative
> Windows bindings.  Not that those aren't good, especially when, as in
> JEWL, they address a special audience, but it does mean that someone who
> wants a midi interface does not find it on the shelf, and goes looking
> instead to C++.  (Presumably after checking out gnatcom)

Actually, the mention of JEWL is appropriate.   John English is to be
commended for designing a package specification that is wonderfully
accessible to the novice Windows programmer using Ada.  However,
John would probably be the first to agree that JEWL is not intended
for the kind of robust applications one can create with CLAW.  He
never intended it to compete with CLAW, if I understand him correctly.

I wonder whether someone might take the JEWL and JEWL.Windows
package specifications and implement them with CLAW.   The
benefit would be that one would have the simplicity of the JEWL
specification for beginner programmers along with the full
power of CLAW when one needed to do more than JEWL offers.  .

Richard Riehle

Open Source: in conflict with the development process in the Ada community?

[Kent Paul Dolan]

"Richard Riehle" <richard@adaworks.com> wrote:

> Ted Dennison wrote:

> > I would submit that this is because the "release it to the public
> > domain" step was never followed through on. If they had done that
> > first, instead of planning on doing it last, things might have been
> > different.

> And who was going to pay Randy and RR Software for their effort in
> developing CLAW?    It is all well and good to want free software,
> but someone, somewhere needs to pay for it.    One reason we don't
> see more bindings to more environments for Ada is the widespread
> reluctance of people to commit resources when there is no financial
> benefit.   Even GNAT will disappear if ACT discovers there is
> no financial reward in supporting it.

But since in point of fact Dr. Dewar and company seem to be making a
quite comfortable living, perhaps the problem instead is that the
expectation of being paid for software up front, rather than being paid
for enhancements happy customers want to that software once it is in
widespread use, is no longer the best model.

It is tough as heck to take that first step, and the low return on
investment of shareware distributors is certainly off-putting, but if
the distribution step comes early, then there is a fairly low investment
before the software developer learns if what has been created is going
to be a viable "maintain-ware" product, while if the distribution is
left until late, "giving it away for nothing" is simply too painful to
contemplate.

I'm guessing, since I haven't enough entrepenurial skills to fill a
thimble (my brother got them all in our family), but I think Ted has the
right of it.

xanthian.


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Rant! (was) Development process in the Ada community

[martin.m.dowie]

> > CANAL+ could be a better bet - are you out there Pascal?
> >
> Maybe - but are they big enough and interested enough to finance some sort
> of Ada endeavor?

Big enough - I think so I think it is Universal Studios they own amongst
others.
They do (most of the?) set top boxes for terrestrial digital TV in Europe.

Interest enough - probably not :-(

Re: Rant! (was) Development process in the Ada community

[Ingo Marks]

Marin David Condic wrote:

> From rumors I've heard Boeing is drifting away from Ada for a lot of the
> same reasons as other aerospace firms - the programmers want to work in
> something more marketable.

What do they use instead of Ada?

Regards,
Ingo

Re: Open Source: in conflict with the development process in the Ada community?

[Hyman Rosen]

Kent Paul Dolan wrote:
> But since in point of fact Dr. Dewar and company seem to be making a
> quite comfortable living, perhaps the problem instead is that the
> expectation of being paid for software up front, rather than being paid
> for enhancements happy customers want to that software once it is in
> widespread use, is no longer the best model.

But Dewar, et al. were paid to develop GNAT!

Re: Rant! (was) Development process in the Ada community

[Gary Scott]

Ingo Marks wrote:
> 
> Marin David Condic wrote:
> 
> > From rumors I've heard Boeing is drifting away from Ada for a lot of the
> > same reasons as other aerospace firms - the programmers want to work in
> > something more marketable.
> 
> What do they use instead of Ada?

C++, just like Lockheed Martin.

> 
> Regards,
> Ingo


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Development process in the Ada community

[John English]

Richard Riehle wrote:
> 
> tmoran@acm.org wrote:
> 
> > But multiple people have spent a lot of time creating alternative
> > Windows bindings.  Not that those aren't good, especially when, as in
> > JEWL, they address a special audience, but it does mean that someone who
> > wants a midi interface does not find it on the shelf, and goes looking
> > instead to C++.  (Presumably after checking out gnatcom)
> 
> Actually, the mention of JEWL is appropriate.   John English is to be
> commended for designing a package specification that is wonderfully
> accessible to the novice Windows programmer using Ada.  However,
> John would probably be the first to agree that JEWL is not intended
> for the kind of robust applications one can create with CLAW.  He
> never intended it to compete with CLAW, if I understand him correctly.

You are exactly correct -- I wanted something simple enough for
total beginners to use, which made it justifiable (IMHO) to
sacrifice completeness and flexibility in favour of simplicity.

> I wonder whether someone might take the JEWL and JEWL.Windows
> package specifications and implement them with CLAW.   The
> benefit would be that one would have the simplicity of the JEWL
> specification for beginner programmers along with the full
> power of CLAW when one needed to do more than JEWL offers.  .

That would be nice -- any takers? :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:Ar8v8.41325$C21.7794767@news6-win.server.ntlworld.com...
> > > CANAL+ could be a better bet - are you out there Pascal?
> > >
> > Maybe - but are they big enough and interested enough to finance some
sort
> > of Ada endeavor?
>
> Big enough - I think so I think it is Universal Studios they own amongst
> others.
> They do (most of the?) set top boxes for terrestrial digital TV in Europe.
>
> Interest enough - probably not :-(
>

Well since the Set-Top Box business doesn't (yet) have a dominant OS or
resident application or a definitive set of third-party apps, it is still
wide open for new technologies to emerge. Its not like the home PC market
where basically its some version of Windows and Office apps that define the
environment. Finding a way for Ada to play in that arena could be a big
boost.

I think to interest a company in some sort of funding of an Ada endeavor in
this area is possible. It has to be dreampt up along the lines of creating
some kind of competitive advantage for them and sold to them. Being in the
set-top box business, I can see how hard it is driven by cost and time to
market. Its really hard to get people in the company to focus on an R&D kind
of thing when the rush is always on to hurry up and get the next thing out
the door. But that doesn't mean that its totally impossible to get someone
to listen to a good idea.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3CBCE84E.811EA1C3@adaworks.com...
>
> OK, let's get this straight.    The DoD has not decided to quit Ada.   I
still
> correspond with former Assistant Secretary of Defense Emmett Paige
> from time to time and I gather that one of his disappointments is the
> misinterpretation of his memo abrogating the Ada mandate.   If I may

I think the problem was a huge misjudgement of how his memo would be
interpreted. Maybe Secretary Paige didn't intend for the memo to be
interpreted as the DoD abandoning Ada, but that sure was the net effect.
Perhaps part of it was willfull misinterpretation on the part of some who
hated Ada and The Mandate so they could use it as an excuse to rush off and
do what they wanted to in the first place. Perhaps there was a kind of a
logical inference on the part of others that this is what it meant: "You
used to insist that Ada was the right answer and now you're saying 'go forth
and select whatever makes sense' so I can reasonably guess that this amounts
to 'Ada was a mistake'..."

Sometimes perception *is* reality. Especially when we're dealing in a
political & social realm. Once The Mandate was instituted, any attempt to
back off from it was going to be perceived as weakness and lack of resolve.
Once that chink showed up in the armor, the Ada Haters of America charged in
to exploit it with gusto and the more ambivalent ones in the crowd stuck
their fingers into the air to find which way the wind was blowing and
decided it wasn't towards Ada.

Maybe The Mandate was a mistake to begin with. Maybe it should have been
abandoned. But if abandonment of The Mandate had to be done and there wasn't
a desire to simultaneously abandon Ada, then perhaps the DoD could have done
more to show it still thought Ada was a good idea and that it supported it.
(DoD could have allocated significant money to build development tools,
etc., that might have made Ada a more attractive choice, for example.)
Instead, they effectively said "you're on your own - sink or swim..." which
clearly added to the perception that DoD was "abandoning" Ada.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Open Source: in conflict with the development process in the Ada community?

[Robert Dewar]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3CBD4B3E.6030501@mail.com>...

> But Dewar, et al. were paid to develop GNAT!

That's a bit misleading. The government contract provided somewhat under
$3 million to NYU. The total development cost of GNAT and its tool set so
far has been something like $15 million, and the development continues at
a rapid pace. And that does not include the huge past and present
investment in GCC and the GNU tools infrastructure.

Yes, the DoD contract helped get things going, no doubt about it. But
once ACT was formed as a company we have many development projects that
are entirely internally funded. For example, the current development of
our new integrated development environment (GPS - GNAT Programming System)
is int his category.

By the way, please don't misuse the term public domain. No ACT software
is in the public domain. Ada Core Technologies provides supported licensed
copyrighted software, as do other software companies. The only difference
is that we use a much less restrictive license that allows users more freedom
than licenses from many other companies.

Robert Dewar
Ada Core Technologies

Re: Rant! (was) Development process in the Ada community

[Robert Dewar]

> Marin David Condic wrote:
> 
> > From rumors I've heard Boeing is drifting away from Ada for a lot of the
> > same reasons as other aerospace firms - the programmers want to work in
> > something more marketable.

A common but highly irresponsible behavior on the web and usenet is to
post rumours when you really don't know any facts. So often, these rumours
quickly get taken as fact, and it is often the case that they have no
grounding in fact at all.

In fact the situation at Boeing is that some programs are using Ada and
some are not. Some new developments are using Ada, some are not. I doubt
anyone has meaningful overall figures that would support a conclusion
of whether overall use is increasing at Boeing or not. Most certainly from
ACT's point of view, we see an increase in use of Ada at Boeing, but that's
only one point of view :-)

The use of Ada is of course subject to competition. We will lose some and
win some. When you lose, you try to learn, but it is singularly unhelpful
to draw broad conclusions.

I can certainly say that ACT is a company that is essentially 100% devoted
to Ada based products, and we see our business expanding steadily. I can't
speak for other Ada companies, but I can certainly be confident that neither
Ada nor ACT are about to disappear in the forseeable future.

I suggest people spend less time in uninformed discussions on the future of
Ada use, and more time in contributing to the technical base :-)

Robert Dewar
Ada Core Technologies

Re: Rant! (was) Development process in the Ada community

[Robert Dewar]

> Marin David Condic wrote:
> 
> > From rumors I've heard Boeing is drifting away from Ada for a lot of the
> > same reasons as other aerospace firms - the programmers want to work in
> > something more marketable.

A common but highly irresponsible behavior on the web and usenet is to
post rumours when you really don't know any facts. So often, these rumours
quickly get taken as fact, and it is often the case that they have no
grounding in fact at all.

In fact the situation at Boeing is that some programs are using Ada and
some are not. Some new developments are using Ada, some are not. I doubt
anyone has meaningful overall figures that would support a conclusion
of whether overall use is increasing at Boeing or not. Most certainly from
ACT's point of view, we see an increase in use of Ada at Boeing, but that's
only one point of view :-)

The use of Ada is of course subject to competition. We will lose some and
win some. When you lose, you try to learn, but it is singularly unhelpful
to draw broad conclusions.

I can certainly say that ACT is a company that is essentially 100% devoted
to Ada based products, and we see our business expanding steadily. I can't
speak for other Ada companies, but I can certainly be confident that neither
Ada nor ACT are about to disappear in the forseeable future.

I suggest people spend less time in uninformed discussions on the future of
Ada use, and more time in contributing to the technical base :-)

Robert Dewar
Ada Core Technologies

Re: Development process in the Ada community

[Marin David Condic]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3CBCEB15.E104D1F5@adaworks.com...
>
> And who was going to pay Randy and RR Software for their effort in
> developing CLAW?    It is all well and good to want free software,
> but someone, somewhere needs to pay for it.    One reason we don't
> see more bindings to more environments for Ada is the widespread
> reluctance of people to commit resources when there is no financial
> benefit.   Even GNAT will disappear if ACT discovers there is
> no financial reward in supporting it.
>
Unfortunately, there sometimes seems to be a perception that because some
software can be downloaded and used free of charge, that it must be possible
for *all* software to be downloaded and used free of charge. It really
stands in violation of some gas law I used to know back in high school - the
one about there being no free lunch? :-)

To some extent, I think this gets fostered by the FSF having a slight bias
against business & capitalism. What gets lost in the rhetoric is that most
of us don't go into work every day and write software for the companies we
work for and then refuse to accept a paycheck at the end of the week.
Software costs money to develop, enhance and maintain. Who should pay for
that? It seems fair that it ought to be the people getting the benefit of
using it. Giving it away "free" is really just a strategy to get payment in
some other manner - like "Free Beer" might be a strategy to sell hot dogs.
Any way you slice it, *someone* has to pay.

GNAT isn't "free" - its just subsidized by the companies that buy support
from ACT. We get it at no cost because someone else pays for its development
& maintenance. But not every product can subsist on that model and even GNAT
could eventually fall on the wayside if there were insufficient numbers of
companies willing to buy support.


> Tom Moran is right when he complains that so many have spent so
> much energy creating partial implementations that discourage the
> use of CLAW instead of getting on board and adding to its already
> powerful set of capabilities.   I suspect Randy would not turn down
> any offer of help in developing additional packages to extend the
> CLAW software.
>

Perhaps enhancing CLAW and making it the de facto "standard" for OS
interfacing (at least on Windows - could it ever become more general?) might
be a really good idea. As you observed before, RR Software can't be expected
to do that without some kind of remuneration either from direct sales or
some other mechanism. The problem is one of incentivizing people to add to
the product. Will people jump up and beg for the chance to help develop a
product in their spare time so that someone else can sell it? If it were
"free software" would they be more eager to do so? But then we just get back
to that problem of who is going to pay the freight, right?

So maybe RR Software could find a way of partnering with the spare-time
developers & get a bigger, better product as a result? Dare I suggest the
Ada Developer's Cooperative License as a mechanism to do that? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Open Source: in conflict with the development process in the Ada community?

[Marin David Condic]

Not every software product can exist on the ACT model. It requires something
of sufficient complexity and size and criticality to a project that enough
people will want to buy support. Do people regularly go shopping to buy
support contracts for word processors or computer games? Not usually,
because they do what they do & their bug-free functioning is not critical to
a project. Even GNAT could arrive at a point where customers say "It works
well enough for me to do my job and I don't need any add-on, custom
features, so thanks for your support, but we'll be terminating our contract
now..." (Even Microsoft is up against that sort of problem - why do you
think they want to invent some kind of software leasing scheme?)

If a product doesn't offer much promise of back-end payment by way of
support/enhancement/consulting contracts and you don't charge anything for
it up front, how do people get paid to develop it?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:35c5c360dfe83cb34ea9648445bd0e95.48257@mygate.mailgate.org...
>
> But since in point of fact Dr. Dewar and company seem to be making a
> quite comfortable living, perhaps the problem instead is that the
> expectation of being paid for software up front, rather than being paid
> for enhancements happy customers want to that software once it is in
> widespread use, is no longer the best model.
>

Re: Development process in the Ada community

[Ted Dennison]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<ubmbe6r24ii522@corp.supernews.com>...
> Ted Dennison wrote in message
> >I would submit that this is because the "release it to the public
> >domain" step was never followed through on. If they had done that
> >first, instead of planning on doing it last, things might have been
> >different.
> 
> Couldn't have done that, because it would have left us nothing to
> sell -- and thus we'd have been out of business in a hurry. (The ATIP-P
> seed money also required a product to sell back to the government to
> "recover" the investiment -- which couldn't have been done if there was
> no product). We needed the GUI builder to be reasonable before we could
> let go of the bindings.

Fair enough. You folks certianly know way more about staying afloat as
an Ada vendor than I can pretend to. However, I think its fair to say
that no Windows bindings can have any hope of becomming the "standard"
Ada Windows bindings so long as they are kept proprietary to one
vendor, no matter how wonderful they (bindings and/or vendor) may be.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Ted Dennison]

tmoran@acm.org wrote in message news:<G5Iu8.3882$GN4.1981086988@newssvr21.news.prodigy.com>...
> > > X to Claw, but multiple people have created alternative Windows bindings,
> > > none of which has become a standard, and none of which supports the
> > > features that writer needed.
> >I would submit that this is because the "release it to the public
> >domain" step was never followed through on. If they had done that
> >first, instead of planning on doing it last, things might have been
> >different.
>   And why then have people created, but not built on, multiple
> alternative "Open Source" Windows bindings, none of which has become a
> standard, and none of which supports the features that writer needed?

I'm not too sure what you are referring to here. The ones I'm aware of
are:

o  Claw     - Nicely high-level, and compiler portable, but
proprietary.
o  Win32Ada - Free, Comes with every Windows Ada95 compiler I've seen,
very low-level (think C in Ada).
o  GWindows - Free, high-Level, only works with Gnat, only realy
supports GUI operations, not all of Win32.
o  Jewl     - GPL (usable only in GPL-ed programs or ones that won't
be distributed), *Too* High-level, Probably(?) only works with Gnat.

I think the issues here are pretty obvious. The ideal would be
something a bit like Claw, but free. Alternatively it would be a bit
like GWindows, but with complete Win32 support and compiler-agnostic.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Marin David Condic wrote:
> "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
> news:3CBC5281.1040202@snafu.de...
> 
>>Interesing, i did not know this. Is there any information about this
>>in the net? May be this formality is why most of the people in the
>>community are not taking part in the standarization process.
>>
>>
> Well think about some of the packages that are in the appendices right now.
> Things like Ada.Strings.Fixed. There is a quite detailed description of the
> behavior of each subprogram in there and I'd suspect you need some part of
> the validation suite aimed at testing compliance with that specification.
> Furthermore, all they provide is a spec and that means the vendors have to
> go out and build the bodies - which for a string package may not be that big
> a deal,
Mean while started to contact them using the ada-comments mail list. The
answer was that i should just send a proposal & rational. Maybe i will
do this asap for a basic container. Just to see what happens.


> but for something like - say - a GUI would be *waaayy* much bigger
> and would hence meet resistance from the vendors. (Do you really think
> they're just chomping at the bit to rush out and spend millions just to get
> themselves compliant with the next Ada standard? ;-)

I gues GUI's was not a good idea, only resonable small building
blocks should be standarized. I think nobody would attempt to
stndarize a complete car!

>>This is what is normally called a defacto standard. Raising initial
>>interest for a certain sloution and setting up alliences to enforce
>>the solution normally creates such standards. But if these alliences
>>breaking up, such standards start to dissolve and lot of derivates
>>of the original solution are back on the market gain. I like to
>>avoid this.
>>
>>
> Trying to do anything real formal to avoid divergence is just going to get
> too costly and difficult. What might work better is some version of
> "Standardization By Inertia" If you got some committee of vendors and users
> to agree on some libraries as the de facto standard and there was a
> reference implementation the vendors all adopted, chances are it would just
> stay the way it is because nobody is going to want to spend their own money
> to change it without a compelling reason.
I agree on this also. I think the way of establishing first a defacto
standard will be the best process. This could be done in the following
steps (i guess):

  - Raise interest
  - Setup a group producing some result for the community
  - Distribute the software as wide as possible
  - Run several itterations (event incompatebil ones)
  - After you reached stability either propose to ISO or seek alliences
    with vendors.
  - Propose to ISO to stabilize the package

I think the first 4 steps are typlical for open source software which
is developed in the net.
The two steps following have to be established by some means.May be
it is in the interest of the vendors to standarize packages of this
process in order to avoid the some body is chaging them via the
same process after they have reached stability (> step 4).
So the trick is to develope in the net in a distributed manner software
till end of step 4.

> 
>>But your second tier idea may be the right point! This second tier
>>could become some kind of public entry process for the ISO WG which
>>is in the first stage (input) less formal and at the output as formal
>>as ISO requieres.
>>Establishing such a second tier interface to the public would be
>>an interesting project for the open source community, and may
>>be some ideas of the JPC may be taken over for this purpose.
>>
>>
> I really think that once you stick the initials "ISO" on it you're asking
> for a rigid, validatable, *sloooooow* process to be put in place. It would
> be better to form something up under some less formal structure. It might
> work better to do something under the auspices of SIGAda - that's how ASIS
> got done, IIRC. You need the input and guidance of the vendors because if
> they won't sign up to include/implement whatever you come up with, the whole
> game is over. If the vendors said "We'd be interested in libraries that
> cover the following subjects...." and your working group could come up with
> an answer they'd be willing to adopt, *and* you could come up with the
> necessary resources to build a reference implementation, you might see a
> fairly quick and agile process evolve that probably wouldn't see a lot of
> divergence from the "standard".
> 
I will check out ACM!


> I really doubt that lobbying for *anything* to happen under ISO is going to
> result in any sort of process that meets the objectives you seem to be
> supporting. The less formal it is, the more likely it will be to move
> quickly and be willing to listen to what you have to say. If you got
> something that was adopted as a de facto standard, it would likely be a lot
> easier to get it included into the ISO standard after that point - if that
> seems at all important if/when that happens.

There i do agree completley, ISO will not be the driving part of
development. ISO will be the finalization of the development.

> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> 
> 
> 

Re: Development process in the Ada community

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> 
> I'm not too sure what you are referring to here. The ones I'm aware of
> are:
> 
> o  Claw     - Nicely high-level, and compiler portable, but
> proprietary.
> o  Win32Ada - Free, Comes with every Windows Ada95 compiler I've seen,
> very low-level (think C in Ada).
> o  GWindows - Free, high-Level, only works with Gnat, only realy
> supports GUI operations, not all of Win32.
> o  Jewl     - GPL (usable only in GPL-ed programs or ones that won't
> be distributed), *Too* High-level, Probably(?) only works with Gnat.

Windex : Open Source, unsupported, works with GNAT and maybe
ObjectAda, reasonable subset of Win32.

GtkAda : Open Source, supported by ACT, full GUI interface, portable
to other windowing/operating system

Windex "competes" directly with Claw and GWindows. I wrote it because
Claw was not open source, and GWindows was not available. I'm not
clear why David Botton wrote GWindows instead of extending Windex.
They do have different designs under the hood.

GtkAda also competes, but since it's strictly a GUI binding, not an OS
binding, and it is platform independent, it's in a different class.

Jewl could probably be written on top of any of these.

-- 
-- Stephe

Re: Development process in the Ada community

[Ted Dennison]

Richard Riehle <richard@adaworks.com> wrote in message news:<3CBCEB15.E104D1F5@adaworks.com>...
> Ted Dennison wrote:
>
> > I would submit that this is because the "release it to the public
> > domain" step was never followed through on. If they had done that
> > first, instead of planning on doing it last, things might have been
> > different.
> 
> And who was going to pay Randy and RR Software for their effort in
> developing CLAW?    It is all well and good to want free software,

That's not the issue. Its *an* issue of course, but not the one being
discussed. The issue is how something can become "standard". I can
only see two ways:

1) It is distributed with every appropriate compiler (either by fiat
or agreement). Examples of this are the standard Ada libraries, and
the Win32Ada bindings. Let us not forget that the Win32Ada bindings
are indeed the *standard* low-level Win32 bindings. No one's been
talking about them because low-level bindings are so yucky that no one
really wants to use them. Let us also not forget that the Win32Ada
bindings were created by Intermetrics, a company that, like RR, is in
the business of selling licenses to proprietary software (or at least
was at the time).

2) It is released freely, and is so wonderful compared to the
alternatives that everyone who wants to do that kind of thing goes out
and downloads it.

Now perhaps you are saying that creating a standard is incompatable
with making a profit. I'm not really qualified to answer that, but I
somehow doubt that's the case.

> benefit.   Even GNAT will disappear if ACT discovers there is
> no financial reward in supporting it.

That is wrong. ACT does not own Gnat. Its source copyrights are held
by the FSF, and it is now part of the gcc baseline. As long as gcc is
around, Gnat will be around.


> powerful set of capabilities.   I suspect Randy would not turn down
> any offer of help in developing additional packages to extend the
> CLAW software.

I'm sure he wouldn't. What I'm missing here is what's in it for *me*.
I have no interest in helping to improve some company's proprietary
product, unless I am paid to do so. (and frankly I have plenty of
paying work on my plate at the moment already. I'm not interested in
taking on any more.) I certianly do some volunteer work that involves
using, and perhaps improving, Windows bindings. However, I do that for
the good of the community, not any one party's private good (that's
why its called "volunteer" work).

I've dealt with RR before, and they seemed like a great company, and
great guys. If there were true justice in the universe I'm sure they'd
be swimming in cash by now. But I just can't convince myself that
their stockholders are a worthy enough cause to become the primary
benificiary of my volunteer efforts. I'd rather donate time on
something that everyone in the (Ada) community can use, not just the
select few to whom some company deigns to grant a license.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Marin David Condic]

Lets see.. that's (onetwothreefour...) *six* different bindings to Windows -
each with different features/capabilities, but probably a good deal of
overlap. (Will we hear of more? Consider that a "binding to Windows"
could/should include things like sockets and similar stuff, so maybe we've
got to start rounding up the packages that do this as well...???) Sounds
like a Department of Redundancy Department effort to me. :-) Kind of makes
Tom's point, too.

Probably, you really need to have Win32Ada (or similar) no matter what. This
thin binding is needed just to keep up with whatever Microsoft comes out
with next as the OS API, so that if it didn't get included in the more
abstract API, the programmer still has access to it. (It was originally
auto-generated, right? So if a new C interface comes out, it can easily be
re-auto-generated? Sounds important to me...)

But could CLAW be made to incorporate (in an abstract sense - not
necessarily with an identical realization) whatever capabilities the others
offer and provide a common platform for development? Probably, the hard part
would be to define some sort of "portable" subset so it could work on
Linux/Unix as well & cover features done by GtkAda. (Although it might be
possible to map GtkAda's XML description of the GUI to a CLAW-equivalent
implementation?) If you don't insist on portability, you've at least got A
Good Start at a common Windows interface, right? Probably parts of it would
constitute A Good Start at a common Ada utility library if the portable
parts were identified.

I think this is an indication of how we may tout Ada's reusability and
portability, but we're not very good at exploiting it - because it wasn't
invented here? Or because it costs money? Why?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ud6wydz64.fsf@gsfc.nasa.gov...
> dennison@telepath.com (Ted Dennison) writes:
>
> >
> > I'm not too sure what you are referring to here. The ones I'm aware of
> > are:
> >
> > o  Claw     - Nicely high-level, and compiler portable, but
> > proprietary.
> > o  Win32Ada - Free, Comes with every Windows Ada95 compiler I've seen,
> > very low-level (think C in Ada).
> > o  GWindows - Free, high-Level, only works with Gnat, only realy
> > supports GUI operations, not all of Win32.
> > o  Jewl     - GPL (usable only in GPL-ed programs or ones that won't
> > be distributed), *Too* High-level, Probably(?) only works with Gnat.
>
> Windex : Open Source, unsupported, works with GNAT and maybe
> ObjectAda, reasonable subset of Win32.
>
> GtkAda : Open Source, supported by ACT, full GUI interface, portable
> to other windowing/operating system
>
> Windex "competes" directly with Claw and GWindows. I wrote it because
> Claw was not open source, and GWindows was not available. I'm not
> clear why David Botton wrote GWindows instead of extending Windex.
> They do have different designs under the hood.
>
> GtkAda also competes, but since it's strictly a GUI binding, not an OS
> binding, and it is platform independent, it's in a different class.
>
> Jewl could probably be written on top of any of these.
>
> --
> -- Stephe

Outside view (still): Development process in the Ada community

[Kent Paul Dolan]

"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:

> i am wondering how standards are eveloving in the Ada community.
> In the Java Community there is a process called Java Community
> Process (JCP, http://www.jcp.org/)

> Is there something comparabel in the Ada communitiy? I gues
> if there would be something like this there would be more
> dynamic in the Ada 95 community.

I thought this snippet of an email from the Ratio Group made an
interesting commentary along the same lines; the problem of "too brittle
... too rigid" in a dynamic world seems to be generic, not limited to
the Ada language capabilities development process.

xanthian, not that this is going to be a huge surprise to any long-time
software practitioner.

(B) Extended Call for Position Papers: "Feyerabend Redefining Computing
Workshop" at ECOOP 2002.

The goal of this workshop is to bring together everyone who is
interested in the  redefinition of computing and/or in the use of
alternative metaphors/languages/ ideas for entering the Next Era of
computer science. The major problem with the current flow of ideas is
that current approaches merely enable the construction of software that
is too brittle and too rigid in order to survive and operate in our real
world which is dynamic and constantly subject to change.

For more information, visit
http://www.dreamsongs.com/Feyerabend/ECOOP02/


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Development process in the Ada community

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9f22c$av7$1@nh.pace.co.uk>...
> I certainly wouldn't mind at all adopting an existing solution as the
> starting point for a standard. The problem is quite often that everybody has
> a different idea about what they want and short of having a solution
> unilaterally imposed on them, agreement isn't likely. If Claw could evolve
> into a generic interface for GUI building (rather than be Windows specific)
> then I have no objection to it. It might even be fair to say "Here's the
> 'official' Ada interface to Windows..." and see if it could migrate
> elsewhere at a later point.

I doubt that. There's just too many different systems out there for
there to ever be only one. No matter what you do, there are going to
be people who want their OS's standard OS look and feel, or who want
to use stuff like DirectX or OpenGL.

> But if it were to stand a chance of success, the best way I can think of it
> getting accepted would be if it were shipped with most of the Ada compilers
> out there so that the developer's thinking would have to be: "Well, I may
> not like it, but its here and certainly a lot easier to take advantage of
> than to roll my own or go looking for an alternative..."

...which is precisely what was done with Win32Ada. Exactly. In another
post I called this something like "standardization path 1". Path 2
(release it publicly and hope everyone uses it) is probably a distant
second, and nothing else is even in the ballpark.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Ted Dennison]

Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CBAFFEE.2080708@snafu.de>...
> Since i still believe there are some things missing
> in the predefined language environment i dont like
...
> 
> I believe that i have to go through the following
> natural process

What you have probably missed is that we have already gone through
this process a bit, starting on the subject of a new standard
component library in general, and a list package in particular. Many
people had the vision of slowly increasing this library's scope to
include much more than just components. The process is currently
stalled a bit, and I have to take pretty much full blame for that. But
you and anyone else interested may want to keep an eye on this site:
http://savannah.gnu.org/projects/grace/ 

Which is the home I'm trying to set up for the project. There's
nothing up there right now but 2 mailing lists, but I'm pretty close
to posting the main webpage and the list package should follow
closely. Once I get the basics set up, I can add administrators other
than myself, and one person will no longer be the bottleneck (which
will be a good thing, as I also have a new baby due in less than a
week).

From what I see on the website you posted, are goals are almost
entirely in agreement. But I've been known to misread things. :-) I'm
particularly in agreement with your "release early, release often"
point. There was a trememdous amount of interest in this project a few
months ago when we were making freqeunt source proposals and revisions
for the list package, and I'd like to see us get back to that as soon
as possible.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Rant! (was) Development process in the Ada community

[Ted Dennison]

dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0204170529.beaf045@posting.google.com>...
> I suggest people spend less time in uninformed discussions on the future of
> Ada use, and more time in contributing to the technical base :-)

Damn straight.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Outside view (still): Development process in the Ada community

[Michael Erdmann]

Kent Paul Dolan wrote:
> "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:
> 
> 
>>i am wondering how standards are eveloving in the Ada community.
>>In the Java Community there is a process called Java Community
>>Process (JCP, http://www.jcp.org/)
>>
> 
>>Is there something comparabel in the Ada communitiy? I gues
>>if there would be something like this there would be more
>>dynamic in the Ada 95 community.
>>
> 
> I thought this snippet of an email from the Ratio Group made an
> interesting commentary along the same lines; the problem of "too brittle
> ... too rigid" in a dynamic world seems to be generic, not limited to
> the Ada language capabilities development process.
> 
> xanthian, not that this is going to be a huge surprise to any long-time
> software practitioner.
> 
> (B) Extended Call for Position Papers: "Feyerabend Redefining Computing
> Workshop" at ECOOP 2002.

This is a nice title. In german language this sounds like

       "Feierabend..."

This gives me some association which are translated back into
english:

       "lets call it a day,  ...and go for a drink" ...

any how it is an interesting thing i am going to watch....:-)


> The goal of this workshop is to bring together everyone who is
> interested in the  redefinition of computing and/or in the use of
> alternative metaphors/languages/ ideas for entering the Next Era of
> computer science. 


> The major problem with the current flow of ideas is
> that current approaches merely enable the construction of software that
> is too brittle and too rigid in order to survive and operate in our real
> world which is dynamic and constantly subject to change.
I am not so sure. I guess we three different aspects:

Technically:
    Ada is missing some things we need every day..........

Social Wise
    There is no real homogenious community which is trying to
    achive the same thing (simply to survive). Newgroups are
    to informal to setup a real community. What community?
    There are a lot different members types in this community:

     - 100% Ada professional who are trying to make a living
       out of it.
     - Students which are trying solve there problems
     - Students which are persuing there ideas, diploma works
       etc....
     - Peoples like my self, which are involved in software
       development in there professional time but using Ada
       in there spare time outside there professinal life
       persuing there personal ideas of differnet software.
     - Simply wise guys ......

     .... and lots more....

Process Wise

     All these peoples are producing important software in Ada
     but most of the stuff goes down the drain, either
     because the software is not known, not stable or just because
     i am a wise guy which thinks i am doing every thing better
     then some body else. Simply there is no established process
     to make components a defact standard. :-(


I know, real world is not this simple, each of these topics are
related to each other, but my original idea was to do improve
the "world" at least process wise by finding a development
process which starts with a loose collection of ideas in the
net and ends up in the ISO documentents, so that every body
can rely on it!

Regards
    M.Erdmann


> 
> For more information, visit
> http://www.dreamsongs.com/Feyerabend/ECOOP02/
> 


> 
> 

Re: Rant! (was) Development process in the Ada community

[Chad R. Meiners]

Here are some interesting facts.  Boeing out of St. Louis actively recruits
Truman State University's students.  Two of the reasons that they give to
students on why they recruit at Truman are 1) Truman graduates are well
educated and 2) Truman teaches Ada as a first language.  If there are
companies that worry about the supply of Ada programmers, you can also point
them to Truman as a small but steady source of quality computer scientists
that know (and in most cases appreciate) Ada.

-CRM
Truman Alumni ;)

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0204170529.6338a5f9@posting.google.com...
> > Marin David Condic wrote:
> >
> > > From rumors I've heard Boeing is drifting away from Ada for a lot of
the
> > > same reasons as other aerospace firms - the programmers want to work
in
> > > something more marketable.
>
> A common but highly irresponsible behavior on the web and usenet is to
> post rumours when you really don't know any facts. So often, these rumours
> quickly get taken as fact, and it is often the case that they have no
> grounding in fact at all.
>
> In fact the situation at Boeing is that some programs are using Ada and
> some are not. Some new developments are using Ada, some are not. I doubt
> anyone has meaningful overall figures that would support a conclusion
> of whether overall use is increasing at Boeing or not. Most certainly from
> ACT's point of view, we see an increase in use of Ada at Boeing, but
that's
> only one point of view :-)
>
> The use of Ada is of course subject to competition. We will lose some and
> win some. When you lose, you try to learn, but it is singularly unhelpful
> to draw broad conclusions.
>
> I can certainly say that ACT is a company that is essentially 100% devoted
> to Ada based products, and we see our business expanding steadily. I can't
> speak for other Ada companies, but I can certainly be confident that
neither
> Ada nor ACT are about to disappear in the forseeable future.
>
> I suggest people spend less time in uninformed discussions on the future
of
> Ada use, and more time in contributing to the technical base :-)
>
> Robert Dewar
> Ada Core Technologies

Re: Development process in the Ada community

[Michael Erdmann]

Ted Dennison wrote:
> Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CBAFFEE.2080708@snafu.de>...
> 
>>Since i still believe there are some things missing
>>in the predefined language environment i dont like
>>
> ...
> 
>>I believe that i have to go through the following
>>natural process
>>
> 
> What you have probably missed is that we have already gone through
> this process a bit, starting on the subject of a new standard
> component library in general, and a list package in particular. Many
> people had the vision of slowly increasing this library's scope to
> include much more than just components. The process is currently
> stalled a bit, and I have to take pretty much full blame for that. But
> you and anyone else interested may want to keep an eye on this site:
> http://savannah.gnu.org/projects/grace/ 
I cannot access this page?!!!


> 
> Which is the home I'm trying to set up for the project. There's
> nothing up there right now but 2 mailing lists, but I'm pretty close
> to posting the main webpage and the list package should follow
> closely. Once I get the basics set up, I can add administrators other
> than myself, and one person will no longer be the bottleneck (which
> will be a good thing, as I also have a new baby due in less than a
> week).
> 
> From what I see on the website you posted, are goals are almost
> entirely in agreement. But I've been known to misread things. :-) I'm
> particularly in agreement with your "release early, release often"
> point. There was a trememdous amount of interest in this project a few
> months ago when we were making freqeunt source proposals and revisions
> for the list package, and I'd like to see us get back to that as soon
> as possible.
What is wirtten there is quite general, not yet any technical
things. This will change this week. I will public my idea of basic
container package.


Just look at this, on the next ada conference in vienna they will
have a talk about this as well.

http://www.auto.tuwien.ac.at/AE2002/problems.html


> 
> 

Re: Development process in the Ada community

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> Richard Riehle <richard@adaworks.com> wrote in message
> news:<3CBCEB15.E104D1F5@adaworks.com>...

> > Even GNAT will disappear if ACT discovers there is
> > no financial reward in supporting it.
> 
> That is wrong. ACT does not own Gnat. Its source copyrights are held
> by the FSF, and it is now part of the gcc baseline. As long as gcc is
> around, Gnat will be around.

Not quite true. Parts of gcc and binutils are dropped from the gcc
baseline when they are no longer maintained. Old processors are the
most common parts dropped.

If ACT stops maintaining GNAT, and nobody else picks it up, it will
eventually be dropped from gcc.

-- 
-- Stephe

Re: Development process in the Ada community

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0204171009.30336212@posting.google.com...
>
> ...which is precisely what was done with Win32Ada. Exactly. In another
> post I called this something like "standardization path 1". Path 2
> (release it publicly and hope everyone uses it) is probably a distant
> second, and nothing else is even in the ballpark.
>
>
I agree and Win32Ada is an excellent example of how some packages/libraries
can become a lower-case "standard" just because the vendors make it come
along for the ride. Win32Ada may be "icky", but people use it just because
they can count on it being there.

So IMHO, the same sort of thing could be done with data structures, math
libraries, etc., to the benefit of Ada. It might even be possible to have it
done for more complex things like a GUI - a platform-specific standard but
the one that all vendors deliver if they target that platform. Evidence
indicates that the technique will work, but the hard part is the process for
getting "Library X" into everyone's distribution.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Development process in the Ada community

[Marin David Condic]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u4riadpq3.fsf@gsfc.nasa.gov...
>
> If ACT stops maintaining GNAT, and nobody else picks it up, it will
> eventually be dropped from gcc.
>
The important observation is that unless there is some reasonably large body
of people willing to pay money to get support from someone, GNAT would
remain largely static. You might have a few hobyists who would tinker with
it and put changes back into the tree, but would you see any really serious
work done on it? What if a new language revision came out? What if new
target hardware comes about?

On the one hand, sure, GNAT is around so long as there is a source tree
somewhere that folks can download from. On the other hand, lack of paying
customers looking for support means - if not "death" - at least a
"vegitative state" as a project.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote:

> Marin David Condic wrote:

> > but for something like - say - a GUI would be *waaayy* much bigger
> > and would hence meet resistance from the vendors. (Do you really think
> > they're just chomping at the bit to rush out and spend millions just to get
> > themselves compliant with the next Ada standard? ;-)

> I gues GUI's was not a good idea, only resonable small building
> blocks should be standarized. I think nobody would attempt to
> stndarize a complete car!

Ummm, but arguably Java's fairly instant success was exactly due to
coming with the GUI built in, so that GUIed applets started popping up
all over the Web, evangelizing Java without extra effort by Sun.

I suspect that a standard GUI is high on the list of what is needed to
make Ada more popular, and luckily, Ada to Java compilation provides
that pretty much for free already.  Is it being used?

xanthian.


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Rant! (was) Development process in the Ada community

[Darren New]

Kent Paul Dolan wrote:
> Ummm, but arguably Java's fairly instant success was exactly due to
> coming with the GUI built in, so that GUIed applets started popping up
> all over the Web, evangelizing Java without extra effort by Sun.

Well, that and Sun getting it built into several popular web browsers by
default.

> I suspect that a standard GUI is high on the list of what is needed to
> make Ada more popular, and luckily, Ada to Java compilation provides
> that pretty much for free already.  Is it being used?

How about a binding to Tk (of Tcl fame)? I thought GNAT already supports
that, yes?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Outside view (still): Development process in the Ada community

[Robert Dewar]

"Kent Paul Dolan" <xanthian@well.com> wrote in message news:<cc3099f93a91d1e9c18e88d1a6381f6f.48257@mygate.mailgate.org>...

> I thought this snippet of an email from the Ratio Group made an
> interesting commentary along the same lines; the problem of "too brittle
> ... too rigid" in a dynamic world seems to be generic, not limited to
> the Ada language capabilities development process.

Well that's certainly a reach!

The quote is about software being too brittle and too rigid. From the
point of view of the Ada community we would argue that Ada is all about
avoiding such problems.

The idea that the Ada language is itself brittle and rigid is unrelated
(and also not supportable in my view).

What makes languages brittle is when they accumulate ill thought out
junk that does not work well and cannot be easily modified.

Re: Development process in the Ada community

[Randy Brukardt]

Ted Dennison wrote in message
<4519e058.0204170958.22f797c4@posting.google.com>...
>Richard Riehle <richard@adaworks.com> wrote in message
news:<3CBCEB15.E104D1F5@adaworks.com>...
>> Ted Dennison wrote:
>The issue is how something can become "standard". I can
>only see two ways:
>
>1) It is distributed with every appropriate compiler (either by fiat
>or agreement). Examples of this are the standard Ada libraries, and
>the Win32Ada bindings. Let us not forget that the Win32Ada bindings
>are indeed the *standard* low-level Win32 bindings. No one's been
>talking about them because low-level bindings are so yucky that no one
>really wants to use them. Let us also not forget that the Win32Ada
>bindings were created by Intermetrics, a company that, like RR, is in
>the business of selling licenses to proprietary software (or at least
>was at the time).


Win32Ada was created under a contract which required Intemetrics to make
it available free. So, of course they did so. Moreover, what they
created is NOT pure, portable, Ada, and in fact is NOT available with
"every appropriate compiler" (in so much as it is not included with
Janus/Ada, and in fact doesn't compile with Janus/Ada, either. We of
course provide a Win32 binding based on our 16-bit Win 3.1 binding, but
it isn't much like the Intermetrics one. That's no real issue, as no one
ought to use Win32Ada anyway: for GUI, use Claw or something else; for
the occassional thread or file system API, bind it in place.)


>> powerful set of capabilities.   I suspect Randy would not turn down
>> any offer of help in developing additional packages to extend the
>> CLAW software.
>
>I'm sure he wouldn't. What I'm missing here is what's in it for *me*.
>I have no interest in helping to improve some company's proprietary
>product, unless I am paid to do so. (and frankly I have plenty of
>paying work on my plate at the moment already. I'm not interested in
>taking on any more.) I certianly do some volunteer work that involves
>using, and perhaps improving, Windows bindings. However, I do that for
>the good of the community, not any one party's private good (that's
>why its called "volunteer" work).
>
>I've dealt with RR before, and they seemed like a great company, and
>great guys. If there were true justice in the universe I'm sure they'd
>be swimming in cash by now. But I just can't convince myself that
>their stockholders are a worthy enough cause to become the primary
>benificiary of my volunteer efforts. I'd rather donate time on
>something that everyone in the (Ada) community can use, not just the
>select few to whom some company deigns to grant a license.


Of course, you can always put any such work out under any license that
you prefer (including the GMGPL), which would certainly have the effect
of prevent us from including it in the Claw package and making any money
off of it. And certainly, the Claw Introductory version is available
under a "free for non-commercial use" license. So that hardly qualifies
as a "select few". (Indeed, that always has been true for the Claw
Introductory version, although we didn't originally spell it out clearly
on our website.) You may even be able to talk me to widening that more;
the primary reason for the "non-commercial" restriction is to prevent
people from selling the Introductory version itself (or enhancements of
it), not to prevent people from using it in a commercial environment. We
could find any words that covered the one that didn't cover the other,
or get so complicated as to be impossible to understand. Finally we
decided to use a variation on Aonix's ObjectAda license.

            Randy Brukardt.

Re: Development process in the Ada community

[Randy Brukardt]

Ted Dennison wrote in message
<4519e058.0204170829.23915c65@posting.google.com>...
>Fair enough. You folks certianly know way more about staying afloat as
>an Ada vendor than I can pretend to. However, I think its fair to say
>that no Windows bindings can have any hope of becomming the "standard"
>Ada Windows bindings so long as they are kept proprietary to one
>vendor, no matter how wonderful they (bindings and/or vendor) may be.

Not really true. Remember something you said yesterday:

> 1) It is distributed with every appropriate compiler (either by fiat
or agreement).

We did everything we could to make that happen. Indeed, the Claw
Introductory version is distributed with Rational Apex for Windows, and
Dave Wood was planning to do so with ObjectAda as well (but he left
Aonix before it actually happened). It isn't really possible to include
it with GNAT, unfortunately (we would have to GMGPL the Intro. version,
which I won't do; I'd be more likely to use a FreeBSD license if we're
going to give it up anyway).

We negotiated with several vendors to include the full version, but we
couldn't agree on a maintenance (support) price -- it had to be enough
to be able to fix bugs and continue development, given no further
license sales. (If we had succeeded with that, no one would need to buy
it individually, because they would have it with the compiler. Thus, the
support fees would be the only revenue, and that meant that they had to
be fairly high. So it never made economic sense, I fear.)

                       Randy Brukardt.

Re: Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Darren New" <dnew@san.rr.com> wrote:.

> How about a binding to Tk (of Tcl fame)? I thought GNAT already supports
> that, yes?

Reasonable, I presume you mean GtkAda, which I haven't seen (amazing how
much of the universe of discourse you can't explore when your pillow is
the pavement).

Since there is already a Perl binding to Tk (which (PerlTk) I have
used),  the more languages that add in a Tk binding, the better chance
you have of making it the de facto standard; I'm not enough of a
theorist to compare it to either the Java GUI or to the various
international standard graphics APIs for superiority, though.

xanthian.


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Outside view (still): Development process in the Ada community

[Kent Paul Dolan]

"Robert Dewar" <dewar@gnat.com> wrote:

> What makes languages brittle is when they accumulate ill thought out
> junk that does not work well and cannot be easily modified.

And what makes languages rigid is that they fail to incorporate good
ideas that do work out well and have been widely praised.

[Or was your earlier denial that Ada ignores inputs from the programming
community a hint that you'd somehow managed to sneak in programming by
contract, high power text parsing capabilities, et al., to the Ada
language standard as long ago promoted here by dozens to hundreds of
correspondents, and me not noticed?]

xanthian.

[Robert and I will never get along, the rest of you please do your best
to ignore us.]



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Rant! (was) Development process in the Ada community

[Darren New]

Kent Paul Dolan wrote:
> 
> "Darren New" <dnew@san.rr.com> wrote:.
> 
> > How about a binding to Tk (of Tcl fame)? I thought GNAT already supports
> > that, yes?
> 
> Reasonable, I presume you mean GtkAda,

I haven't looked at GtkAda. I would have assumed that had Ada used Tk,
it would be called Ada/Tk, just like it's Perl/Tk, Python/Tk, and
Tcl/Tk. If GtkAda is actually Ada with Tck's Tk, then cool, let's make
that the standard. ;-)

> Since there is already a Perl binding to Tk (which (PerlTk) I have
> used),  the more languages that add in a Tk binding, the better chance
> you have of making it the de facto standard;

That's what I thought, yah. And it's already portable amongst a wide
variety of desktop systems. And capable of supporting a variety of
programming interface styles.

> I'm not enough of a
> theorist to compare it to either the Java GUI or to the various
> international standard graphics APIs for superiority, though.

It's very simple to learn, too. Way easier than either Java GUI, and
relatively high-level, but relatively limited due to being high-level
and portable. You don't get 3D, or round windows, or dancing menus with
talking paperclips.... wait a minute... that could be a benefit too!

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Development process in the Ada community

[martin.m.dowie]

> will be a good thing, as I also have a new baby due in less than a
> week).

I trust there will be a suitable c.l.a. announcement? ;-)

"Break a leg" to your other half.

Re: Outside view (still): Development process in the Ada community

[Pat Rogers]

"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:99c4aee4a9ea33ca8fbe1e634b3b4f14.48257@mygate.mailgate.org...
> "Robert Dewar" <dewar@gnat.com> wrote:
>
> > What makes languages brittle is when they accumulate ill thought out
> > junk that does not work well and cannot be easily modified.
>
> And what makes languages rigid is that they fail to incorporate good
> ideas that do work out well and have been widely praised.
>
> [Or was your earlier denial that Ada ignores inputs from the programming
> community a hint that you'd somehow managed to sneak in programming by
> contract, high power text parsing capabilities, et al., to the Ada
> language standard as long ago promoted here by dozens to hundreds of
> correspondents, and me not noticed?]

And why would I want high-powered text parsing in my hard real-time embedded
application?

Re: Outside view (still): Development process in the Ada community

[Larry Kilgallen]

In article <99c4aee4a9ea33ca8fbe1e634b3b4f14.48257@mygate.mailgate.org>, "Kent Paul Dolan" <xanthian@well.com> writes:
> "Robert Dewar" <dewar@gnat.com> wrote:
> 
>> What makes languages brittle is when they accumulate ill thought out
>> junk that does not work well and cannot be easily modified.
> 
> And what makes languages rigid is that they fail to incorporate good
> ideas that do work out well and have been widely praised.

ACT has experimented with several pragmas and attributes outside
the standard.  What other ideas have been worked out and proven
in an Ada environment ?

Re: Outside view (still): Development process in the Ada community

[Richard Riehle]

Kent Paul Dolan wrote:

> "Robert Dewar" <dewar@gnat.com> wrote:
>
> > What makes languages brittle is when they accumulate ill thought out
> > junk that does not work well and cannot be easily modified.
>
> And what makes languages rigid is that they fail to incorporate good
> ideas that do work out well and have been widely praised.

In my view, it is more a problem of deciding what to include in the
language and what to include in the libraries written in the language.
Ada, C++, Java, C#, and Ruby, to name a few, are designed so
one can extend the core functionality with libaries.   The very idea
of extensible types/classes, enables us to build powerful functionality
such as CLAW, GtkAda, JEWL, CAMP, and many other software
frameworks.   These frameworks, in turn, let us build applications.

Earlier languages such as COBOL, PL/I, and Fortran were less extensible
and certainly characterized by a kind of brittleness.  Perhaps I should say,

earlier versions of these languages since all three have gone through
considerable revision.   Someone at IBM even mentioned that there
would be an OOP version of PL/I someday.  That was four years ago
and we still have not seen it published.

Dr. Dewar is correct in his view that the designers of Ada have taken
great pains to avoid including language features that could be better
implemented as library modules.   The question is whether these
libraries should be part of the standard Annexes.   Should be expand
the Annexes to include generalize GUI specifications,  Database
specifications, etc?   The answer is not so simple.   When one realizes
that the vast majority of desktop software is written for the monopolisic
operating system from one company,  it is all too easy to capitulate and
agree to facilitating that monopoly even further.    Some of us would
hope that such a thing would not happen to Ada, even at the risk of
limiting Ada's popularity.

From other postings in this thread, it is clear that capitulation is not
necessary.   There are bindings in Ada that support the operating
system from the "dark side" as well as bindings for those operating
systems one might classify as "open."     All this has happened
without adding features to the language that are platform-specific.

I'd say that, despite its failure to become popular, Ada is evolving
as it should as a language.   We do need more tools, development
environments,  GUI builders, and debugging environments, but those
are not a concern of the language designers.   Rather, they are the
concern of people who use the language as it is designed.

Richard Riehle

Re: Rant! (was) Development process in the Ada community

[Eric G. Miller]

In <3CBE0457.6E7B82A8@san.rr.com>, Darren New wrote:

> Kent Paul Dolan wrote:
>> 
>> "Darren New" <dnew@san.rr.com> wrote:.
>> 
>> > How about a binding to Tk (of Tcl fame)? I thought GNAT already supports
>> > that, yes?
>> 
>> Reasonable, I presume you mean GtkAda,
> 
> I haven't looked at GtkAda. I would have assumed that had Ada used Tk,
> it would be called Ada/Tk, just like it's Perl/Tk, Python/Tk, and
> Tcl/Tk. If GtkAda is actually Ada with Tck's Tk, then cool, let's make
> that the standard. ;-)

There is no connection between Tk and Gtk, though both have similar
goals (gui abstraction layer and toolkit).  AFAIK, both are written
in C.
 
>> Since there is already a Perl binding to Tk (which (PerlTk) I have
>> used),  the more languages that add in a Tk binding, the better chance
>> you have of making it the de facto standard;
> 
> That's what I thought, yah. And it's already portable amongst a wide
> variety of desktop systems. And capable of supporting a variety of
> programming interface styles.

That is one benefit of Tk.  It's been around longer, and has been
ported to more systems than Gtk.  But my impression is that Gtk2
smokes Tk in widget functionality, and certainly the Gtk1.x look and
"feel" is better than most Tk programs I've used.  I suspect in a
year or so, Tk's advantage in portability will be less than today.

Re: Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Darren New" <dnew@san.rr.com> wrote:

> It's very simple to learn, too. Way easier than either Java GUI, and
> relatively high-level, but relatively limited due to being high-level
> and portable. You don't get 3D, or round windows, or dancing menus with
> talking paperclips.... wait a minute... that could be a benefit too!

Ummm.  Actually then, that could be a problem, since a fraction of Ada
use (I have no idea how much) goes into stuff like flight simulators and
combat theater simulators.  I don't think limited functionality graphics
would fly as a standard Ada GUI (though I'm talking way past my
knowledge base at this point, so it is time for me to choose this leaf
as a point at which to bow out of this bough of this discussion tree, I
suspect).

xanthian.



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Outside view (still): Development process in the Ada community

[Kent Paul Dolan]

"Pat Rogers" <rogers@gnat.com> wrote:

> And why would I want high-powered text parsing in my hard real-time embedded
> application?

1) Don't make the common error of assuming that the whole world is a
clone of the view seen from your desk; Ada does lots more than "hard,
real time embedded" apps.  The future health of Ada depends on it
providing a balanced set of capabilities to do them all well.

2) Especially for exactly such apps, turning strings of bytes (whether
originally text or not) into reports (even if only old fashioned text
debugging messages) is much less unpleasant with decent tools; I know
for creating embedded SNMP agent summary reports, being able to parse
bales of haystack to find needles of useful information was always an
issue.  I would certainly anticipate similar needs in a battlefield
evaluation tool; often the human at the receiving end needs to see the
answer as text.

3) That the language contains the capability doesn't at all imply that
your code image downloaded into your embedded app would show any trace
of that ability in the language.  There is rarely indeed overhead for
unused capabilities in code emitted from any decent compiler, certainly
the compiler writers' goal is that that overhead be zero.

Just to give you the first three of probably several hundred available
reasons that happened to pop into my head.

xanthian.



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Outside view (still): Development process in the Ada community

[Kent Paul Dolan]

"Richard Riehle" <richard@adaworks.com> wrote:

[...]

> I'd say that, despite its failure to become popular, Ada is evolving
> as it should as a language.   We do need more tools, development
> environments,  GUI builders, and debugging environments, but those
> are not a concern of the language designers.   Rather, they are the
> concern of people who use the language as it is designed.

A useful set of words, but not responsive to a posting in which the
things mentioned (better parsing capabilities, programming by contract)
were explicitly things that very much need to be part of the language,
not some library capability.

xanthian.


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Outside view (still): Development process in the Ada community

[Kent Paul Dolan]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:..

> ACT has experimented with several pragmas and attributes outside
> the standard.  What other ideas have been worked out and proven
> in an Ada environment ?


Sorry, but read your own words. Don't they scream "inbred" to you?

xanthian, who would mildly suggest that ideas that have been worked out
and proven in other programming language environments are at this point
_much_ more important to Ada's future as a viable programming language,
than merely rechurning stuff already known to work here.

Again, if you don't provide in Ada the modern functionalities the
students learn to value in school, they will turn away to the tools that
do.





-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Development process in the Ada community

[Eric G. Miller]

In <ud6wydz64.fsf@gsfc.nasa.gov>, Stephen Leake wrote:

> GtkAda also competes, but since it's strictly a GUI binding, not an OS
> binding, and it is platform independent, it's in a different class.

Curious. What OS bindings do most people need/want? Gtk2 is certainly a
bit more than just a GUI binding via GLIB (library of utility functions
and data types), ATK (Accessibility Toolkit, think ADA), Pango 
(bi-directional text and font handling), and GdkPixBuf (image handling).
Since GTK2.0 depends on all those libraries, if GtkAda provides bindings
to them you'd get all the functionality "for free".  Granted, I doubt
most of these things have been well tested on other than *nix like
environments (and I understand, not all functionality has been ported
to Windows environs yet -- like it's IO channels [files, sockets, other?]).

All of it licensed under GNU Library General Public License, so using
it for proprietary software is okay.

Re: Outside view (still): Development process in the Ada community

[Simon Wright]

"Pat Rogers" <rogers@gnat.com> writes:

> And why would I want high-powered text parsing in my hard real-time
> embedded application?

Because you want to read the systems's controlling parameter set (in
our case, a few hundred options) fron an XML-format file (in Flash,
perhaps)?

OK, not likely for a digital watch, but I'm not making this one up!

Re: Outside view (still): Development process in the Ada community

[Dmitry A. Kazakov]

On Thu, 18 Apr 2002 01:19:27 GMT, "Pat Rogers" <rogers@gnat.com>
wrote:

>"Kent Paul Dolan" <xanthian@well.com> wrote in message
>news:99c4aee4a9ea33ca8fbe1e634b3b4f14.48257@mygate.mailgate.org...
>> "Robert Dewar" <dewar@gnat.com> wrote:
>>
>> > What makes languages brittle is when they accumulate ill thought out
>> > junk that does not work well and cannot be easily modified.
>>
>> And what makes languages rigid is that they fail to incorporate good
>> ideas that do work out well and have been widely praised.
>>
>> [Or was your earlier denial that Ada ignores inputs from the programming
>> community a hint that you'd somehow managed to sneak in programming by
>> contract, high power text parsing capabilities, et al., to the Ada
>> language standard as long ago promoted here by dozens to hundreds of
>> correspondents, and me not noticed?]
>
>And why would I want high-powered text parsing in my hard real-time embedded
>application?

I could be well possible. An example is a real project of autopilot I
am involved in. It is an embedded soft real-time application. By the
nature of autopilot, it should have some AI gears. Here you are.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Outside view (still): Development process in the Ada community

[Larry Kilgallen]

In article <1a976f56c5a59e7ee74d2030a5702737.48257@mygate.mailgate.org>, "Kent Paul Dolan" <xanthian@well.com> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:..
> 
>> ACT has experimented with several pragmas and attributes outside
>> the standard.  What other ideas have been worked out and proven
>> in an Ada environment ?
> 
> 
> Sorry, but read your own words. Don't they scream "inbred" to you?

No, think of it as an entrance examination.

If you think something is useful, prove that it is useful in Ada.
By that, you will prove to us all that it is worth doing in Ada.
If even an advocate will not go to the effort to provide a worked
example, the idea cannot be presumed worthwhile.

> xanthian, who would mildly suggest that ideas that have been worked out
> and proven in other programming language environments are at this point
> _much_ more important to Ada's future as a viable programming language,
> than merely rechurning stuff already known to work here.
> 
> Again, if you don't provide in Ada the modern functionalities the
> students learn to value in school, they will turn away to the tools that
> do.

The fact that something is taught in school does not automatically
make it worthwhile.  The fact that it is attractive to students is
even less compelling.  I am much more interested in Ada's effectiveness
than I am in its popularity.

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

GtkAda as a "standard" would be more than what we have now - which is pretty
close to "nothing" last time I checked. Lack of sophisticated 3-D graphics
for flight simulators wouldn't be a hindrence in my mind. If that's what you
want to build you'll probably want some package that is specialized to the
platform and problem domain anyway - which you could still do. Not to
mention that should there be some sense of GtkAda being the "standard" then
there would be incentives to build upon it & extend its capabilities.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:75e7bccb730eda7db554601b66ba9814.48257@mygate.mailgate.org...
>
> Ummm.  Actually then, that could be a problem, since a fraction of Ada
> use (I have no idea how much) goes into stuff like flight simulators and
> combat theater simulators.  I don't think limited functionality graphics
> would fly as a standard Ada GUI (though I'm talking way past my
> knowledge base at this point, so it is time for me to choose this leaf
> as a point at which to bow out of this bough of this discussion tree, I
> suspect).
>

Re: Development process in the Ada community

[Marin David Condic]

"Eric G. Miller" <egm2@jps-nospam.net> wrote in message
news:pan.2002.04.17.22.13.12.183692.16266@jps-nospam.net...
>
> to them you'd get all the functionality "for free".  Granted, I doubt
> most of these things have been well tested on other than *nix like
> environments (and I understand, not all functionality has been ported
> to Windows environs yet -- like it's IO channels [files, sockets,
other?]).
>
So essentially you can port it to any system you like as long as that system
is Unix? :-) If a toolset were to be included in Ada in some manner that was
intended to interface to the OS, I would think it needs to be defined in
such a way that it could be readily used with at minimum Unix, Windows, and
Mac. If at all possible, you would want it to present an abstraction that
could be implemented on any OS that supported the concepts.

The "Least Common Denominator" criticism could be employed here, but I think
it isn't entirely reasonable. One could say "For the standard interface, we
support blah blah blah. If you need something more detailed and OS specific,
you have a way to bind to the OS, but of course, you won't be portable..."

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Outside view (still): Development process in the Ada community

[Marin David Condic]

Well, there's a danger for Ada to attempt to be all things to all
programmers. Just because a feature worked out nicely in some other language
doesn't mean it fits well with the design goals of Ada (which is already
criticized for trying to do too much.) To the extent that some capability
could be provided by an add-on library, it might be a good idea to add it to
the language - with all sorts of cautions about doing it informally at
first, etc. etc. etc. If it starts requiring some syntactic/semantic changes
to the language itself, I'd consider the Fools Rush In principle to be an
important one to keep in mind.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:1a976f56c5a59e7ee74d2030a5702737.48257@mygate.mailgate.org...
>
> xanthian, who would mildly suggest that ideas that have been worked out
> and proven in other programming language environments are at this point
> _much_ more important to Ada's future as a viable programming language,
> than merely rechurning stuff already known to work here.
>
> Again, if you don't provide in Ada the modern functionalities the
> students learn to value in school, they will turn away to the tools that
> do.
>

Re: Rant! (was) Development process in the Ada community

[Ted Dennison]

"Kent Paul Dolan" <xanthian@well.com> wrote in message news:<75e7bccb730eda7db554601b66ba9814.48257@mygate.mailgate.org>...
> "Darren New" <dnew@san.rr.com> wrote:
> 
> > It's very simple to learn, too. Way easier than either Java GUI, and
> > relatively high-level, but relatively limited due to being high-level
> > and portable. You don't get 3D, or round windows, or dancing menus with
> > talking paperclips.... wait a minute... that could be a benefit too!
> 
> Ummm.  Actually then, that could be a problem, since a fraction of Ada
> use (I have no idea how much) goes into stuff like flight simulators and
> combat theater simulators.  I don't think limited functionality graphics
> would fly as a standard Ada GUI (though I'm talking way past my
> knowledge base at this point, so it is time for me to choose this leaf
> as a point at which to bow out of this bough of this discussion tree, I
> suspect).

For the flight simulators I've worked on, generally you have several
systems, including at a minimum a dedicated operator station for the
instructors (which can be non-realtime and contains nice GUI's), a
host machine (hard real time, no GUI), and an IG (Image Generator, a
dedicated real-time 3D graphics generator). The host gets the most
benifit from Ada. For the IOS, you really need to build everything
with a GUI builder. If any Ada is there, it will only be glue code (or
in some cases, generated by the GUI builder). The IG's we usually get
off the shelf from an IG vendor (eg: Vitals from FlightSafety or
Compu-Scenes from Lockheed Martin), and they are very expensive. I
don't know if any of them use Ada, but I doubt it.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Rant! (was) Development process in the Ada community

[Bill Tate]

Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message 
> > If we had some community concensus that one or more libraries was what we
[snip]
> > wanted for doing job X, all you'd have to do is persuade the vendors to
> > distribute it with their compilers and it instantly becomes part of Ada even
> > if it isn't part of the "standard".
> 
> I dont think that we need the vendors this mutch, most of the popular
> open source software is distributed without them (thanks to sites
> as sourceforge etc..),
> 
> In my mind the idea of a public ada process is showing up:
> 
> - There is a job to be done and i have some solution for it. Propose
>    the solution to the community (who is this, i gues comp.lang.ada?)
> 
> - If sufficient interest has been raised, form a working group
>    for this topic and provide an implemenation for public use.
> 
> - Proceed until wide acceptance
> 
> - Propose to ISO
> 
Michael,
I would like to echo some of your points from an outsider's
perspective.  As someone who spends most of his time on
comp.lang.python, Python suffers from some of the same "kinds" of
perceptions (erroneous or otherwise) as Ada does, e.g., degree of
acceptance, availability of developers, etc.  However, Python does
have considerable "traction" and "energy" in terms of its direction
and the process for moving new features into its standard "core." 
While ISO adoption isn't part of the python agenda, the Python
Evaluation Process (PEP) seems to fill the bill that your comments
suggest.  A specific PEP garners no shortage of posts from the
devoted.  Wide-spread use including version updates most often lead to
incorporation into the standard distribution.  Its the latter that
seems to be the threshold that needs to be achieved for widespread
community acceptance.  WRT Ada and the ISO process, this would seem to
be, at least, one logical jumping off point since many of the
"important" battles would likely have already been fought and
resolved.  Information on the PEP process is available from
www.python.org.  Hopefully you wouldn't need to reinvent the wheel
(too much) in order to adopt a process that would work for your
community instead of the other way around - like the python language
itself, this is something that borders on religious dogma in the
python community. Hopefully this is of some use.
cheers,
Bill

Re: Outside view (still): Development process in the Ada community

[Marin David Condic]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3CBE49C4.99CFA22D@adaworks.com...
>
> Dr. Dewar is correct in his view that the designers of Ada have taken
> great pains to avoid including language features that could be better
> implemented as library modules.   The question is whether these
> libraries should be part of the standard Annexes.   Should be expand
> the Annexes to include generalize GUI specifications,  Database
> specifications, etc?   The answer is not so simple.   When one realizes

O.K., but here's a fair question: If the language is designed to be extended
with libraries, why do we seem to have such difficulty in incorporating
libraries in some kind of "standard" way? There's extension of the language
by my personal definition of libraries in my own development environment and
that's fine. I realize there are all sorts of sticky issues in terms of
actually updating the ARM annexes with additional libraries that would
probably be useful to everyone, so I can see the reluctance to do so. But
shouldn't we have some means of less formally extending the language via
libraries that might be viewed more as "convention" than "standard"?
Something formal enough that everybody understands what the libraries are
about and they become "The Answer" for the problem domain in question (as
opposed to "An Answer") but not so formal as to make it difficult to get
things into or out of it?

I think the W3C has a kind of interesting approach. They sort of look over a
problem and put up a web page that says "Here's a standard that addresses
the problem. Do you like it?" They might even put out two or three competing
or overlapping standards to see which ones seem to begin to fly. The
standards keep going through revisions as comments come in and sooner or
later they declare victory and say "O.K. This standard is considered stable,
so we promise no more changes to it." If better ideas and enhancements come
along, they start a "Level 2" for the standard.

Wouldn't something similar work for adding libraries to Ada? Some sort of
consortium of vendors and users to develop library specs & possibly bodies
that go through iterations until everyone is happy or at least too tired to
keep arguing about it? Then declare some version of "By Convention, Ada
Compilers Will Include This..." as a non-binding "standard" for adoption by
members.

Just an idea....

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Rant! (was) Development process in the Ada community

[Ted Dennison]

"Eric G. Miller" <egm2@jps-nospam.net> wrote in message news:<pan.2002.04.17.21.35.54.963686.16266@jps-nospam.net>...
> There is no connection between Tk and Gtk, though both have similar
> goals (gui abstraction layer and toolkit).  AFAIK, both are written
> in C.

Just to be complete it should be mentioned that there are good Ada
bindings available for both.

> That is one benefit of Tk.  It's been around longer, and has been
> ported to more systems than Gtk.  But my impression is that Gtk2
> smokes Tk in widget functionality, and certainly the Gtk1.x look and
> "feel" is better than most Tk programs I've used.  I suspect in a

I switched from Tk to Gtk as my default Ada gui about 2 years ago for
precisely that reason. The only sore spot with Gtk is that it isn't
yet supported on Macs. I suspect that will change soon, at least for
OSX.

For those looking for a defacto Ada GUI standard, I would say that it
is already here with GtkAda, as much as we will ever have a standard.
Perhaps it would help everyone to realise its "standard" status if we
distributed it with future Gnat builds? :-)

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Rant! (was) Development process in the Ada community

[Ted Dennison]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message news:<pHYt8.15029$sL6.2187840@news11-gui.server.ntli.net>...
> I totally respect your decisions on what to target new development
> on - it is your business. I'm just sorry I can't bring the bucks to the
> table to make it worth while for you (or anyone else) to do this :-(
> 
> It is a shame that COBOL has Fujitsu to develop COBOL.NET but
> that Ada has no such large corporate to perform this sort of work.

My understanding is that Microsoft is at least partially bankrolling a
lot of those compiler ports. So the real issue is why Microsoft didn't
think Ada worth worrying about, not why ACT doesn't find .NET worth
worrying about.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Outside view (still): Development process in the Ada community

[Gary Scott]

Larry Kilgallen wrote:
> 
> In article <1a976f56c5a59e7ee74d2030a5702737.48257@mygate.mailgate.org>, "Kent Paul Dolan" <xanthian@well.com> writes:
> > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:..
> >
> >> ACT has experimented with several pragmas and attributes outside
> >> the standard.  What other ideas have been worked out and proven
> >> in an Ada environment ?
> >
> >
> > Sorry, but read your own words. Don't they scream "inbred" to you?
> 
> No, think of it as an entrance examination.
> 
> If you think something is useful, prove that it is useful in Ada.
> By that, you will prove to us all that it is worth doing in Ada.
> If even an advocate will not go to the effort to provide a worked
> example, the idea cannot be presumed worthwhile.
> 
> > xanthian, who would mildly suggest that ideas that have been worked out
> > and proven in other programming language environments are at this point
> > _much_ more important to Ada's future as a viable programming language,
> > than merely rechurning stuff already known to work here.
> >
> > Again, if you don't provide in Ada the modern functionalities the
> > students learn to value in school, they will turn away to the tools that
> > do.
> 
> The fact that something is taught in school does not automatically
> make it worthwhile.  The fact that it is attractive to students is
> even less compelling.  I am much more interested in Ada's effectiveness
> than I am in its popularity.

Certainly by far the most important, but if the language dies because of
lack of responsiveness to market pressures, then who cares.


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

new Ada language features needed?

[Stephen Leake]

"Kent Paul Dolan" <xanthian@well.com> writes:

> "Richard Riehle" <richard@adaworks.com> wrote:
> 
> [...]
> 
> > I'd say that, despite its failure to become popular, Ada is evolving
> > as it should as a language.   We do need more tools, development
> > environments,  GUI builders, and debugging environments, but those
> > are not a concern of the language designers.   Rather, they are the
> > concern of people who use the language as it is designed.
> 
> A useful set of words, but not responsive to a posting in which the
> things mentioned (better parsing capabilities, 

What's wrong with the parsing capabilities in the GNAT Spitbol and
regexp packages? Or the GNAT front end, or OpenToken? What, exactly,
needs to be added to the language to better support parsing?

> programming by contract)

In some forms, this does need more language support than Ada currently
provides. However, I have yet to see convincing proof that it is worth
it. I've seen simple examples where the effort needed to write and
compute the contract is comparable to the effort needed to write and
compute the code; that's a marginal gain. For real-life, complex code,
thorough unit testing is a far more efficient use of my time and the
CPU's time, and the current Ada features that allow defining and
enforcing interfaces to software subsystems are just fine.

> were explicitly things that very much need to be part of the
> language, not some library capability.

-- 
-- Stephe

Re: Rant! (was) Development process in the Ada community

[Gary Scott]

Bill Tate wrote:
> 
> Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message
> > > If we had some community concensus that one or more libraries was what we
> [snip]
> > > wanted for doing job X, all you'd have to do is persuade the vendors to
> > > distribute it with their compilers and it instantly becomes part of Ada even
> > > if it isn't part of the "standard".
> >
> > I dont think that we need the vendors this mutch, most of the popular
> > open source software is distributed without them (thanks to sites
> > as sourceforge etc..),
> >
> > In my mind the idea of a public ada process is showing up:
> >
> > - There is a job to be done and i have some solution for it. Propose
> >    the solution to the community (who is this, i gues comp.lang.ada?)
> >
> > - If sufficient interest has been raised, form a working group
> >    for this topic and provide an implemenation for public use.
> >
> > - Proceed until wide acceptance
> >
> > - Propose to ISO
> >
> Michael,
> I would like to echo some of your points from an outsider's
> perspective.  As someone who spends most of his time on
> comp.lang.python, Python suffers from some of the same "kinds" of
> perceptions (erroneous or otherwise) as Ada does, e.g., degree of
> acceptance, availability of developers, etc.  

At least python has gobs (a technical term) of books available in the
local book store and seems to be getting plenty of attention from the
media and academia.  Then consider Fortran 95.  There are virtually no
advertisements, no magazine articles (maybe one / year in Dr Dobbs), no
books stocked in your local book store, etc. yet there are still
somewhere between 5 and 10 commercial developers for x86 plugging away
successfully.  There are at least 4 fortran.net products in development
for x86.  Virtually every hardware vendor provides a Fortran compiler
(Intel just bought Visual Fortran and is now merging with its own
compiler (more or less)).  It is still a niche language but has
dramatically improved its general purpose utility and isn't likely to
die anytime soon.  It does this largely following the slow, cumbersome
ANSI/ISO standard development process.  I only wish REXX would get on
the ball.

> However, Python does
> have considerable "traction" and "energy" in terms of its direction
> and the process for moving new features into its standard "core."
> While ISO adoption isn't part of the python agenda, the Python
> Evaluation Process (PEP) seems to fill the bill that your comments
> suggest.  A specific PEP garners no shortage of posts from the
> devoted.  Wide-spread use including version updates most often lead to
> incorporation into the standard distribution.  Its the latter that
> seems to be the threshold that needs to be achieved for widespread
> community acceptance.  WRT Ada and the ISO process, this would seem to
> be, at least, one logical jumping off point since many of the
> "important" battles would likely have already been fought and
> resolved.  Information on the PEP process is available from
> www.python.org.  Hopefully you wouldn't need to reinvent the wheel
> (too much) in order to adopt a process that would work for your
> community instead of the other way around - like the python language
> itself, this is something that borders on religious dogma in the
> python community. Hopefully this is of some use.
> cheers,
> Bill


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Development process in the Ada community

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> <snip>
> GNAT isn't "free" - its just subsidized by the companies that buy support
> from ACT. We get it at no cost because someone else pays for its development
> & maintenance. But not every product can subsist on that model and even GNAT
> could eventually fall on the wayside if there were insufficient numbers of
> companies willing to buy support.

And ACT is now extending this model to GtkAda, which is a
cross-platform GUI tool. It will be interesting to see if that fares
better than CLAW (or Windex :).

-- 
-- Stephe

Re: Rant! (was) Development process in the Ada community

[Ted Dennison]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0204171040.33abd3c3@posting.google.com>...
> dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0204170529.beaf045@posting.google.com>...
> > I suggest people spend less time in uninformed discussions on the future of
> > Ada use, and more time in contributing to the technical base :-)
> 
> Damn straight.
(misc.misc trimmed)

I felt I should do more than just a "me too" on this. I've been
hanging out in c.l.a. for about 8 years now, and I got sick of the
"Ada is dying" doom-and-gloom talk after about the 3rd Greg Ahnorian
post I read. After 8 years of supposedly declining usage, there would
be no one using it today but 3 kids and a monkey if those folks were
all right. Instead it seems the Ada community is more healthy than
ever before. No one is still being "forced" to use it and there's no
DoD sugar-daddy around bankrolling projects any more, yet there are
all sorts of wonderful new projects and initiatives comming out on
what seems like a daily basis, from both companies and volunteers.

Every language has its detractors that love to believe, no matter what
the truth of the matter is, that it is just about to shrivel up and
die. For whatever reason, Ada has always had more than its share of
such people. I think that Ada's doom has been mindlessly predicted so
much for so long that lots of otherwise sensible people have started
to believe it. Its high time we quit listening.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

The "Is it dying or is it growning" debate can't really ever be settled
anyway since there's no hard data on which most people would agree that
would indicate anything meaningful about the direction. (I'd suggest that if
it *really* grew in a large, substantial way, it would be so obvious nobody
would ask the question.) So basically, anybody expressing an opinion on the
subject either way is equally uninformed - there is no data so all you've
got is opinions based on perceptions.

I don't think its a waste of time though to discuss what would possibly make
Ada more popular with the masses. That's the kind of "market research" that
helps a product satisfy the needs of more people. For example, the
discussion here about libraries seems to be identifying some common
collections of desired utilities, from which maybe something emerges. The
discussion about having some kind of standard GUI/tools seems to be
clarifying a need and possibly seeing consensus getting built on which of
several possibilities ought to be contenders. Any discussion of what people
want out of a language can be helpful in setting future directions.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0204180702.3f703c23@posting.google.com...
> dennison@telepath.com (Ted Dennison) wrote in message
news:<4519e058.0204171040.33abd3c3@posting.google.com>...
>
> I felt I should do more than just a "me too" on this. I've been
> hanging out in c.l.a. for about 8 years now, and I got sick of the
> "Ada is dying" doom-and-gloom talk after about the 3rd Greg Ahnorian
> post I read. After 8 years of supposedly declining usage, there would
> be no one using it today but 3 kids and a monkey if those folks were
> all right. Instead it seems the Ada community is more healthy than
> ever before. No one is still being "forced" to use it and there's no
> DoD sugar-daddy around bankrolling projects any more, yet there are
> all sorts of wonderful new projects and initiatives comming out on
> what seems like a daily basis, from both companies and volunteers.
>
> Every language has its detractors that love to believe, no matter what
> the truth of the matter is, that it is just about to shrivel up and
> die. For whatever reason, Ada has always had more than its share of
> such people. I think that Ada's doom has been mindlessly predicted so
> much for so long that lots of otherwise sensible people have started
> to believe it. Its high time we quit listening.
>
> --
> T.E.D.
> Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
> Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Ted Dennison]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<ubrt5mbbdrtk10@corp.supernews.com>...
> Win32Ada was created under a contract which required Intemetrics to make
> it available free. So, of course they did so. Moreover, what they
> created is NOT pure, portable, Ada, and in fact is NOT available with
I had actually noticed that. I figured that either vendors change the
appropriate data types and import conventions to fit their compiler,
or they all just happened to use the same ones.

> "every appropriate compiler" (in so much as it is not included with
> Janus/Ada, and in fact doesn't compile with Janus/Ada, either. We of

Ahhh, I stand corrected then. Janus is one I haven't ever had a chance
to use (my loss, I'm sure).

> it isn't much like the Intermetrics one. That's no real issue, as no one
> ought to use Win32Ada anyway: for GUI, use Claw or something else; for
> the occassional thread or file system API, bind it in place.)

I actually agree completely with this. Low-level bindings are just
plain ugly to use, and I see no reason why anyone willing to pay for
your compiler shouldn't be willing to shell out the extra dough for
Claw.

I don't really use Win32Ada myself either, for just that reason. At
best, I use it as a guide for developing proper bindings to Win32
myself. :-)

> on our website.) You may even be able to talk me to widening that more;
> the primary reason for the "non-commercial" restriction is to prevent
> people from selling the Introductory version itself (or enhancements of
> it), not to prevent people from using it in a commercial environment. We
> could find any words that covered the one that didn't cover the other,
> or get so complicated as to be impossible to understand. Finally we
> decided to use a variation on Aonix's ObjectAda license.

I guess it depends on exactly what kind of behavior you want to
prevent.

If you were to use the GMGPL, then anyone who tried to resell Claw
(Introductory) would have to compete with thier customer's ability to
download it for free from you or someone else, and they could not
prohibit further redistribution. They can't change the license. Given
that, it would be tough to justify charging significantly more than
media costs. It could be argued that such people would be actually
doing you guys a favor by helping to expose your introductory version
to more users, without you having to go through the expense of making
hard copies and mailing them yourself. The worst I can see happening
from your perspective is that its use might take off, and development
might outstrip that of your full version.

If you were to use the GPL (but license the full version however you
want, you can do that since its your copyright), then anyone who uses
the introductory version would have to GPL their program. This would
still allow for "non-commercial use" like the current license does,
but it would also allow for commercial use in GPL programs, and more
importantly use in GPL programs themselves. Again, people could
redistribute and charge for it, but it would have to be under the GPL.
You could even release the *full* version this way, and make a
non-GPL-infecting license one of the things that you are selling (in
addition to support) to customers. The worst that I could see happen
here is that some folks might ignore the license and use the GPL CLAW
in non-GPL programs, which would require lawyers to get involved.

From my perspective, I'd prefer to see you folks take the first tack.
(I'd actually prefer to see you release the full Claw as GMGPL, with
paid versions from RR getting media and support, but we've been over
that already). But its your perspective that matters. What precisely
worries you about doing either of these?

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Marin David Condic]

That's one of the standard-issue strategies companies adopt with products.
Especially software products. You produce something initially which might
become your "cash cow", but you know eventually the market for it is going
to dry up. Hence you have to start developing new products to take its
place. Sooner or later, the GNAT compiler will reach a point where nobody
will want to buy suport for it. That's just life. In the mean time, if you
want to be in business after that happens, you've got to develop new
products like GtkAda to take its place. Is GtkAda a big enough deal to
generate enough paying support? Possibly, but it never hurts to have some
additional irons in the fire.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ud6wxvz69.fsf@gsfc.nasa.gov...
>
> And ACT is now extending this model to GtkAda, which is a
> cross-platform GUI tool. It will be interesting to see if that fares
> better than CLAW (or Windex :).
>

Re: Development process in the Ada community

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9kne6$3qc$1@nh.pace.co.uk>...
> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:u4riadpq3.fsf@gsfc.nasa.gov...
> >
> > If ACT stops maintaining GNAT, and nobody else picks it up, it will
> > eventually be dropped from gcc.
> >
> The important observation is that unless there is some reasonably large body
> of people willing to pay money to get support from someone, GNAT would
> remain largely static. You might have a few hobyists who would tinker with

Considering that there are actually 2 Mac ports being supported solely
by users (one under very active development), I highly doubt that the
main compiler itself would suddenly loose all support w/o ACT. Its
just that with ACT around there are better things for volunteers to
spend their time on.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Ted Dennison]

Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CBDD795.4060706@snafu.de>...
> > you and anyone else interested may want to keep an eye on this site:
> > http://savannah.gnu.org/projects/grace/ 
> I cannot access this page?!!!

Odd. I can get to it fine from both my work and home machines (while
not logged in to savannah). Perhaps it was down when you tried?

> Just look at this, on the next ada conference in vienna they will
> have a talk about this as well.
> 
> http://www.auto.tuwien.ac.at/AE2002/problems.html

Yes, one of the organizers invited me to attend, based on my leading
of our List work. Unfortunately, a trip overseas to Vienna doesn't
exactly fit into my vacation schedule or personal budget this year.

Since we mostly have a package worked out (at great pains) for lists,
hopefully they will concentrate on defining what other containers are
needed and how best to extend what we have. If there are any really
nasty flaws or fatal problems with the current package, that would be
an important issue too though.

Since you are interested in this, I highly suggest you look over the
"strawman" threads in Google to bring yourself up to speed before
comming up with anything. It was a very extensive process and I'm not
really keen on going back over what has alredy been done yet again.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Rant! (was) Development process in the Ada community

[Pascal Obry]

"Kent Paul Dolan" <xanthian@well.com> writes:

> "Darren New" <dnew@san.rr.com> wrote:.
> 
> > How about a binding to Tk (of Tcl fame)? I thought GNAT already supports
> > that, yes?
> 
> Reasonable, I presume you mean GtkAda, which I haven't seen (amazing how
> much of the universe of discourse you can't explore when your pillow is
> the pavement).

GtkAda is a binding on top of the Gtk toolkit.
TASH is an Ada to Tcl/Tk binding.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Development process in the Ada community

[Hyman Rosen]

Ted Dennison wrote:
> Since we mostly have a package worked out (at great pains) for lists,
> hopefully they will concentrate on defining what other containers are
> needed and how best to extend what we have.

I was just reading somewhere (exactly where escapes me) of a recent
survey done on C++ programmers who have started using the STL. There
was some surprise to discover that the most used container was map.
Apparently what happens is that once programmers have map available,
they begin using it all over the place, replacing little local ad-hoc
lookup structures such as linear searches through arrays.

Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

When the whole discussion of what eventually began to emerge as Grace got
started, there seemed to be a consensus that if you had lists and maps, most
of the other sorts of containers just wouldn't be that big a deal. Lists and
Maps just cover the bulk of what you need to do in most practical
programming situations. I wouldn't be surprised that C++ programmers have
had similar experience. At some point you go: "Maybe there's a more
efficient structure for this data, but I'm not doing realtime and here's a
solution already put together for me, so lets just go with it for looking up
information..."

IIRC, there was general agreement to concentrate on Lists as a start and
then, when the structure of it was settled, a similar spec would be
discussed for Maps.

If the Lists specification is considered done, perhaps its time to look at
it with an eye towards proposing a Map specification?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3CBF0341.8020406@mail.com...
>
> I was just reading somewhere (exactly where escapes me) of a recent
> survey done on C++ programmers who have started using the STL. There
> was some surprise to discover that the most used container was map.
> Apparently what happens is that once programmers have map available,
> they begin using it all over the place, replacing little local ad-hoc
> lookup structures such as linear searches through arrays.
>

Re: Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Ted Dennison" <dennison@telepath.com> wrote:

> "Kent Paul Dolan" <xanthian@well.com> wrote:

> >  (though I'm talking way past my
> > knowledge base at this point, so it is time for me to choose this leaf
> > as a point at which to bow out of this bough of this discussion tree, I
> > suspect).

Sigh. Or maybe not.

>  For the IOS, you really need to build everything
> with a GUI builder. If any Ada is there, it will only be glue code (or
> in some cases, generated by the GUI builder).

Doesn't this become a self fulfilling prophesy?  "Ada doesn't do
graphics well (yet) so we don't do the graphics in Ada (ever). Nobody is
doing graphic in Ada (yet), so it isn't important for Ada to have strong
graphics capabilities (ever)."

xanthian.


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Rant! (was) Development process in the Ada community

[Al Reynolds]

GtkAda has been ported to MacOS X.  We needed to build GVD, which uses GtkAda, to provide a user-friendly interface to 
our Ada-aware version of GDB so that we can more readily debug our Ada binding to Apple's Carbon API :)

Of course, by "ported" what I meant is we compiled it and the demo ran fine (thanks to Ada).  I'm guessing that most of 
the effort went into porting Gtk+ (thanks to C) ;)

I don't know if a GUI standard is required for Ada or for any other language.  From my own experience it wasn't that C++ 
was standard (because it wasn't) but the STL (which also wasn't a standard) made it possible to hack at twice the speed 
which is what appealed to me.  The same goes for Perl (also not a standard) which has mega-functionality attached to 
short character sequences and libraries that cover most application domains.  Whenever I need to do something *just 
once* I can reach out and use the language or environment, standard or not, which provides the greatest support for the 
problem at hand.  What appeals to me about Ada is that I have to be disciplined enough to get my code past the damn 
compiler! After that it's doing what I enjoy so much with the other languages: debugging :)

<RANT>
So, if we really want to make Ada popular what we have to do is make it possible to hack in Ada quickly.  That's what 
GUI support is all about. That's what IDE's are all about.  That's what libraries for containers, math, parsing, 
networking, etc, are all about.  We want Ada to become a strongly-typed, scripting language.
</RANT>

Have fun,
Al

Ted Dennison wrote:
> "Eric G. Miller" <egm2@jps-nospam.net> wrote in message news:<pan.2002.04.17.21.35.54.963686.16266@jps-nospam.net>...
> 
>>There is no connection between Tk and Gtk, though both have similar
>>goals (gui abstraction layer and toolkit).  AFAIK, both are written
>>in C.
> 
> 
> Just to be complete it should be mentioned that there are good Ada
> bindings available for both.
> 
> 
>>That is one benefit of Tk.  It's been around longer, and has been
>>ported to more systems than Gtk.  But my impression is that Gtk2
>>smokes Tk in widget functionality, and certainly the Gtk1.x look and
>>"feel" is better than most Tk programs I've used.  I suspect in a
> 
> 
> I switched from Tk to Gtk as my default Ada gui about 2 years ago for
> precisely that reason. The only sore spot with Gtk is that it isn't
> yet supported on Macs. I suspect that will change soon, at least for
> OSX.
> 
> For those looking for a defacto Ada GUI standard, I would say that it
> is already here with GtkAda, as much as we will ever have a standard.
> Perhaps it would help everyone to realise its "standard" status if we
> distributed it with future Gnat builds? :-)
> 

Paranoia about .NET (still): Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Ted Dennison" <dennison@telepath.com> wrote:

> My understanding is that Microsoft is at least partially bankrolling a
> lot of those compiler ports. So the real issue is why Microsoft didn't
> think Ada worth worrying about, not why ACT doesn't find .NET worth
> worrying about.

That, at least, is a no-brainer.  What made Microsoft attack Java so
strongly that it took a lawsuit to slap them down?  Java is by design OS
independent, contributing to breaking the stranglehold of MS-Windows on
the market of "things needed to run applications".  Microsoft as a
corporate entity and an untrammeled monopoly feels very _threatened_ by
the very _concept_ of OS independent programming languages; that's why
there's a big compiler creating effort inside Microsoft.

OS independent programming language _by design_.  Can you think of some
other language that meets that description, and so would meet with that
reaction at Microsoft?

xanthian.



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

[OT] Focusing on tools you know in programming libraries. (was): Development process in the Ada community

[Kent Paul Dolan]

"Hyman Rosen" <hyrosen@mail.com> wrote:

> I was just reading somewhere (exactly where escapes me) of a recent
> survey done on C++ programmers who have started using the STL. There
> was some surprise to discover that the most used container was map.
> Apparently what happens is that once programmers have map available,
> they begin using it all over the place, replacing little local ad-hoc
> lookup structures such as linear searches through arrays.

That corresponds to my recent experience when someone introduced me a
few days ago (by mentioning it in a posting) to Java's TreeSet, which is
probably similar in part to Map, from your description.  It turned a big
nasty programming chore (implementing a Tabu Search from scratch) I'd
been avoiding, into something I was able to toss off in five hours.

Like the STL, the Java API is rather overwhelming, so I'll probably use
TreeSet a lot where other classes unknown to me might really be a better
fit, like the STL newbies seem to focus on Map.

xanthian.


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Data!, was Re: Development process in the Ada community

[tmoran]

> I was just reading somewhere (exactly where escapes me) of a recent
> survey done on C++ programmers who have started using the STL. There
> was some surprise to discover ...
  If you can possibly remember where that was, please post it.  Actual
information on what makes programmers more productive is extremely rare.

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:5b41d17f3dcf632de26b5ef06daf0650.48257@mygate.mailgate.org...
>
> Doesn't this become a self fulfilling prophesy?  "Ada doesn't do
> graphics well (yet) so we don't do the graphics in Ada (ever). Nobody is
> doing graphic in Ada (yet), so it isn't important for Ada to have strong
> graphics capabilities (ever)."
>
True, but its not as if there are lots of languages out there that have
large-scale, standardized, built-in graphics capabilities of the sort that
one might use to build flight simulators. C/C++ doesn't really have graphics
as a "standard". They just get it because things like Windows and Motif are
all written in C/C++, so it sort of gets viewed as just part of the
environment. Lots of add-on, sophisticated graphics packages are similarly
C/C++ so people tend to view it as spitting into the wind to use any other
language.

I'm definitely not against the proposition that Ada could/should include
some kind of graphics support as some sort of convention/standard, but we
have to admit that this is the kind of thing that is difficult to make
portable across a wide number of platforms. As a result, we might just have
to settle for some minimal level of support (a "graphics microkernel"?), and
look to build on top of that. In time, the set of things that can be
supported across a wide set of platforms might just expand and get more
sophisticated, but if we want a language extension that isn't platform
specific, that's probably the way it will have to be.

The alternative is to define a whole execution environment for Ada programs
(ala Java) with its own windowing/graphics scheme. That's not necessarily a
bad idea, but its going to have its own set of problems and issues. I'd
settle for a lesser solution that got the ball rolling.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Rant! (was) Development process in the Ada community

[Marin David Condic]

I'd agree except for the "hack" part and "scripting language" part. I think
the real issue is *almost* what you describe but with a subtle difference.
It is "Time To Market" and "Leverage" rather than "hack in Ada quickly" or
"scripting language" that is missing. If we had the things you describe
(containers, math, parsing, networking, GUI, IDE, etc.) they would all work
to create leverage and reduce time to market. You could still cater to
Software Engineering, high reliability, life-cycle, etc., rather than cater
to the script-kiddies and hackers, and still be successful being what Ada is
at its roots.

If an Ada environment could get you to market 50% faster than MSVC++ or some
other popular development environment, it would be hard for business
enterprises to argue against it.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Al Reynolds" <alan1@bellatlantic.net> wrote in message
news:3CBF11BE.3090007@bellatlantic.net...
>
> <RANT>
> So, if we really want to make Ada popular what we have to do is make it
possible to hack in Ada quickly.  That's what
> GUI support is all about. That's what IDE's are all about.  That's what
libraries for containers, math, parsing,
> networking, etc, are all about.  We want Ada to become a strongly-typed,
scripting language.
> </RANT>
>

Re: Development process in the Ada community

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Probably, you really need to have Win32Ada (or similar) no matter what. 

I don't think so. Certainly Windex is _not_ built on top of Win32Ada;
I started to, but it was just too weird and C-like. I just imported
the Win32 functions as needed, using Ada types for parameters directly
when possible.

> This thin binding is needed just to keep up with whatever Microsoft
> comes out with next as the OS API, so that if it didn't get included
> in the more abstract API, the programmer still has access to it. (It
> was originally auto-generated, right? So if a new C interface comes
> out, it can easily be re-auto-generated? Sounds important to me...)

I don't think it is being updated; are there Win2000 and XP versions?

> But could CLAW be made to incorporate (in an abstract sense - not
> necessarily with an identical realization) whatever capabilities the
> others offer and provide a common platform for development?

With enough money for programmer time, it could. 

Except the main thing Windex offers over CLAW is the GMGPL license.

Hmm. GWindows makes a start towards a "subscriber" model of event
handling (but only a start). That is significantly different from
Windex and CLAW, which use an "override" model. I don't think one
windowing system can have both. Hmm; maybe it could; call the
subscribers, then dispatch. 

GtkAda uses a "subscriber" model. Since it is not based on a langauge
that supports dispatching and overriding, it probably can't do both.
Although I could provide a subscribed handler that then dispatched.
All kinds of weirdness is possible :).

> Probably, the hard part would be to define some sort of "portable"
> subset so it could work on Linux/Unix as well & cover features done
> by GtkAda. 

I see no reason not to just use GtkAda. It needs some work, and it
needs some tutorials (as you have pointed out before) but it easily 
does everything I need it to do, in many cases better than Windex does
(which is why I'm switching to it). ACT is supporting it.

The only thing I don't like about GtkAda at the moment is that it is
possible to compile an incorrect program; you get run-time errors like
"this handler has the wrong profile for this signal". Errors like that
are caught at compile time in Windex. This is partly because of the
subscriber model, but also because Gtk uses strings (rather than
enumerals or tagged types) to identify signals. I think this can be
fixed with an ASIS tool.

-- 
-- Stephe

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Ted Dennison wrote:
> "Eric G. Miller" <egm2@jps-nospam.net> wrote in message news:<pan.2002.04.17.21.35.54.963686.16266@jps-nospam.net>...
> 

> For those looking for a defacto Ada GUI standard, I would say that it
> is already here with GtkAda, as much as we will ever have a standard.
> Perhaps it would help everyone to realise its "standard" status if we
> distributed it with future Gnat builds? :-)

Yes would guess so!

> 
> 

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Bill Tate wrote:
> Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message 
> 
>>>If we had some community concensus that one or more libraries was what we
>>>
> [snip]
> 
>>>wanted for doing job X, all you'd have to do is persuade the vendors to
>>>distribute it with their compilers and it instantly becomes part of Ada even
>>>if it isn't part of the "standard".
>>>
>>I dont think that we need the vendors this mutch, most of the popular
>>open source software is distributed without them (thanks to sites
>>as sourceforge etc..),
>>
>>In my mind the idea of a public ada process is showing up:
>>
>>- There is a job to be done and i have some solution for it. Propose
>>   the solution to the community (who is this, i gues comp.lang.ada?)
>>
>>- If sufficient interest has been raised, form a working group
>>   for this topic and provide an implemenation for public use.
>>
>>- Proceed until wide acceptance
>>
>>- Propose to ISO
>>
>>
> Michael,
> I would like to echo some of your points from an outsider's
> perspective.  As someone who spends most of his time on
> comp.lang.python, Python suffers from some of the same "kinds" of
> perceptions (erroneous or otherwise) as Ada does, e.g., degree of
> acceptance, availability of developers, etc.  However, Python does
> have considerable "traction" and "energy" in terms of its direction
> and the process for moving new features into its standard "core." 
> While ISO adoption isn't part of the python agenda, the Python
> Evaluation Process (PEP) seems to fill the bill that your comments
> suggest.  A specific PEP garners no shortage of posts from the
> devoted.  Wide-spread use including version updates most often lead to
> incorporation into the standard distribution.  Its the latter that
> seems to be the threshold that needs to be achieved for widespread
> community acceptance.  WRT Ada and the ISO process, this would seem to
> be, at least, one logical jumping off point since many of the
> "important" battles would likely have already been fought and
> resolved.  Information on the PEP process is available from
> www.python.org.  Hopefully you wouldn't need to reinvent the wheel
> (too much) in order to adopt a process that would work for your
> community instead of the other way around - like the python language
> itself, this is something that borders on religious dogma in the
> python community. Hopefully this is of some use.
> cheers,
> Bill

Thanks i like to documentation of the PEP process. Maybe we can
reused some of it!

Michael



> 

Re: Rant! (was) Development process in the Ada community

[Michael Erdmann]

Gary Scott wrote:
> Bill Tate wrote:
> 
>>Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message
>>
>>>>If we had some community concensus that one or more libraries was what we
>>>>
>>[snip]
>>
>>>>wanted for doing job X, all you'd have to do is persuade the vendors to
>>>>distribute it with their compilers and it instantly becomes part of Ada even
>>>>if it isn't part of the "standard".
>>>>
>>>I dont think that we need the vendors this mutch, most of the popular
>>>open source software is distributed without them (thanks to sites
>>>as sourceforge etc..),
>>>
>>>In my mind the idea of a public ada process is showing up:
>>>
>>>- There is a job to be done and i have some solution for it. Propose
>>>   the solution to the community (who is this, i gues comp.lang.ada?)
>>>
>>>- If sufficient interest has been raised, form a working group
>>>   for this topic and provide an implemenation for public use.
>>>
>>>- Proceed until wide acceptance
>>>
>>>- Propose to ISO
>>>
>>>
>>Michael,
>>I would like to echo some of your points from an outsider's
>>perspective.  As someone who spends most of his time on
>>comp.lang.python, Python suffers from some of the same "kinds" of
>>perceptions (erroneous or otherwise) as Ada does, e.g., degree of
>>acceptance, availability of developers, etc.  
>>
> 
> At least python has gobs (a technical term) of books available in the
> local book store and seems to be getting plenty of attention from the
> media and academia.  Then consider Fortran 95.  
Just write an Article how wunderfull Ada is, how easy to use etc...
I know it is difficult to publish this but without try no
failure!

Re: Development process in the Ada community

[Michael Erdmann]

> 
>>Just look at this, on the next ada conference in vienna they will
>>have a talk about this as well.
>>
>>http://www.auto.tuwien.ac.at/AE2002/problems.html
>>
> 
> Yes, one of the organizers invited me to attend, based on my leading
> of our List work. Unfortunately, a trip overseas to Vienna doesn't
> exactly fit into my vacation schedule or personal budget this year.
> 
> Since we mostly have a package worked out (at great pains) for lists,
> hopefully they will concentrate on defining what other containers are
> needed and how best to extend what we have. If there are any really
> nasty flaws or fatal problems with the current package, that would be
> an important issue too though.
> 
> Since you are interested in this, I highly suggest you look over the
> "strawman" threads in Google to bring yourself up to speed before
> comming up with anything. It was a very extensive process and I'm not
> really keen on going back over what has alredy been done yet again.
> 
Please can you direct me a little more detailed?

Michael.



> 
> 

Re: Rant! (was) Development process in the Ada community

[Ingo Marks]

Ted Dennison wrote:

> I switched from Tk to Gtk as my default Ada gui about 2 years ago for
> precisely that reason. The only sore spot with Gtk is that it isn't
> yet supported on Macs. I suspect that will change soon, at least for
> OSX.

At least Gtk is supported in OSX:

http://www.apple.com/scitech/unixports/

Re: Development process in the Ada community

[Ted Dennison]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3CBF0341.8020406@mail.com>...
> Ted Dennison wrote:
> > Since we mostly have a package worked out (at great pains) for lists,
> > hopefully they will concentrate on defining what other containers are
> > needed and how best to extend what we have.
> 
> I was just reading somewhere (exactly where escapes me) of a recent
> survey done on C++ programmers who have started using the STL. There
> was some surprise to discover that the most used container was map.
> Apparently what happens is that once programmers have map available,
> they begin using it all over the place, replacing little local ad-hoc
> lookup structures such as linear searches through arrays.

Maps would certianly be my prime candidate. My last project
incorporated the Booch Components just for the map support. It also
seemed to be the most talked about other component during the strawman
list discussions (although admittedly I was doing a lot of that
talking).

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Gary Scott]

Ted Dennison wrote:
> 
> Hyman Rosen <hyrosen@mail.com> wrote in message news:<3CBF0341.8020406@mail.com>...
> > Ted Dennison wrote:
> > > Since we mostly have a package worked out (at great pains) for lists,
> > > hopefully they will concentrate on defining what other containers are
> > > needed and how best to extend what we have.
> >
> > I was just reading somewhere (exactly where escapes me) of a recent
> > survey done on C++ programmers who have started using the STL. There
> > was some surprise to discover that the most used container was map.
> > Apparently what happens is that once programmers have map available,
> > they begin using it all over the place, replacing little local ad-hoc
> > lookup structures such as linear searches through arrays.
> 
> Maps would certianly be my prime candidate. My last project
> incorporated the Booch Components just for the map support. It also
> seemed to be the most talked about other component during the strawman
> list discussions (although admittedly I was doing a lot of that
> talking).

Could someone please define a MAP.  The only one I'm familiar with is
the Fortran STRUCTURE/UNION/MAP storage association.

> 
> --
> T.E.D.
> Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
> Homepage -  http://www.telepath.com/dennison/Ted/TED.html


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Rant! (was) Development process in the Ada community

[Ted Dennison]

"Kent Paul Dolan" <xanthian@well.com> wrote in message news:<5b41d17f3dcf632de26b5ef06daf0650.48257@mygate.mailgate.org>...
> "Ted Dennison" <dennison@telepath.com> wrote:
> >  For the IOS, you really need to build everything
> > with a GUI builder. If any Ada is there, it will only be glue code (or
> > in some cases, generated by the GUI builder).
> 
> Doesn't this become a self fulfilling prophesy?  "Ada doesn't do
> graphics well (yet) so we don't do the graphics in Ada (ever). Nobody is
> doing graphic in Ada (yet), so it isn't important for Ada to have strong
> graphics capabilities (ever)."

The issue with IOS's has nothing to do with Ada or any other
programming language. The issue is that IOS's are so complicated
(often hundreds of different screens of controls), that you *have* to
develop the graphics with a GUI builder. You need the instant visual
feedback for what you are creating. Trying to draw controls and adjust
stuff like button sizing and placement numericly with a compile in the
middle of every viewing would just be insane.

As for GUI's in general, I don't think we are in nearly as bad a
situation as we used to be in. Ada's always been easy to integrate
with UIL, which opens up the world of UIL (Motif) GUI builders for
easy Ada use.  GTKAda is quite complete, and can do about anything a
GUI author needs as long as long as they can accept its look&feel.
Better Win32 GUI support might be nice, but that wouldn't help
non-Windows Ada users much.

It might be nice in an abstract sense to have a standard Ada GUI that
isn't quite as industrial-strength as GTK+. But I think defining the
ideal standard GUI with total agreement from the Ada community would
be incredibly difficult; much moreso than a component library.

In my book an ideal GUI would be its own separate language with its
own compiler anyway. Motif had such a thing (UIL), and its compiler
would regularly catch GUI definition errors that would have gone
undetected in Ada code. That kind of thing is why we like Ada for
non-GUI code, right?

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community

[Ted Dennison]

"Kent Paul Dolan" <xanthian@well.com> wrote in message news:<357f0f4aab2ac8ef39234c96f0ab6311.48257@mygate.mailgate.org>...
> the market of "things needed to run applications".  Microsoft as a
> corporate entity and an untrammeled monopoly feels very _threatened_ by
> the very _concept_ of OS independent programming languages; that's why
> there's a big compiler creating effort inside Microsoft.
...unless they own that language-independant platform too. :-)

Re: Development process in the Ada community

[Pascal Obry]

Gary Scott <scottg@flash.net> writes:

> Could someone please define a MAP.  

I think we are talking about associative arrays here.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Development process in the Ada community

[Jeffrey Carter]

Ted Dennison wrote:
> 
> > I was just reading somewhere (exactly where escapes me) of a recent
> > survey done on C++ programmers who have started using the STL. There
> > was some surprise to discover that the most used container was map.
> > Apparently what happens is that once programmers have map available,
> > they begin using it all over the place, replacing little local ad-hoc
> > lookup structures such as linear searches through arrays.
> 
> Maps would certianly be my prime candidate. My last project
> incorporated the Booch Components just for the map support. It also
> seemed to be the most talked about other component during the strawman
> list discussions (although admittedly I was doing a lot of that
> talking).

I've never used a map, but I do use skip lists frequently, probably for
the same sort of thing.

-- 
Jeffrey Carter

Re: Development process in the Ada community

[Darren New]

> > Could someone please define a MAP.
> I think we are talking about associative arrays here.

A MAP is a function that, given a key, returns a value. An
implementation in an imperitive language obviously has the ability to
change the function, adding keys and values, deleting keys, etc. I
believe the STL version allows you to iterate thru in order of sorted
keys.

In other words, a "map" is the API to a hash table or a search tree or
etc. You can implement them with trees, hash tables, linear lists,
whatever.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Development process in the Ada community

[Eric G. Miller]

In <a9mhr1$sb1$1@nh.pace.co.uk>, Marin David Condic wrote:

> "Eric G. Miller" <egm2@jps-nospam.net> wrote in message
> news:pan.2002.04.17.22.13.12.183692.16266@jps-nospam.net...
>>
>> to them you'd get all the functionality "for free".  Granted, I doubt
>> most of these things have been well tested on other than *nix like
>> environments (and I understand, not all functionality has been ported
>> to Windows environs yet -- like it's IO channels [files, sockets,
> other?]).
>>
> So essentially you can port it to any system you like as long as that system
> is Unix? :-) If a toolset were to be included in Ada in some manner that was
> intended to interface to the OS, I would think it needs to be defined in
> such a way that it could be readily used with at minimum Unix, Windows, and
> Mac. If at all possible, you would want it to present an abstraction that
> could be implemented on any OS that supported the concepts.

Most of the development is done on Linux systems.  And since gtk2.0 is only
recently stable, folks probably just haven't spent much time on the Windows
port(s).  There's no question the focus of gtk and related libraries is
for *nix/X, but there's enough interest in Windows ports that it will probably
be reality in the not too distant future (don't think anyone's attemping or
wants to port to pre-MacOS X).  I'm no authority on where GTK is at in its
portability attempts, but it's clear from the API interfaces that they intend
to port it as widely as possible (otherwise, why wouldn't they just use the
POSIX interfaces for many of the functions?).

Re: Development process in the Ada community

[Randy Brukardt]

Ted Dennison wrote in message
<4519e058.0204180739.4cbea611@posting.google.com>...
>"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:<ubrt5mbbdrtk10@corp.supernews.com>...

>> You may even be able to talk me to widening that more;
>> the primary reason for the "non-commercial" restriction is to prevent
>> people from selling the Introductory version itself (or enhancements
of
>> it), not to prevent people from using it in a commercial environment.
We
>> could find any words that covered the one that didn't cover the
other,
>> or get so complicated as to be impossible to understand. Finally we
>> decided to use a variation on Aonix's ObjectAda license.
>
>I guess it depends on exactly what kind of behavior you want to
>prevent.

The most important concern is having people sell versions of Claw which
really are just the Introductory version. People often get confused
between the Introductory version and the Full version. That was a
significant problem for us with the Demo compilers that we sold for $30
(media and shipping costs) back in the early days (mid-80s). People
complained that they were a toy. Duh! But that "toy" reputation was hard
to shake. We need to avoid a repeat.

A secondary concern is someone using the Introductory Claw to compete
with us (presumably by implementing some of the missing classes). But
that probably isn't a real problem; the Introductory Claw contains about
1/3 of the SLOC of the Full Claw (I have been keeping this as an
invariant, so each new Introductory Claw is enhanced). So, to truely
compete with us, someone would have to (at least) do 30% of the work put
in on Claw -- which would be a pretty big job.

>If you were to use the GMGPL, then anyone who tried to resell Claw
>(Introductory) would have to compete with thier customer's ability to
>download it for free from you or someone else, and they could not
>prohibit further redistribution. They can't change the license. Given
>that, it would be tough to justify charging significantly more than
>media costs. It could be argued that such people would be actually
>doing you guys a favor by helping to expose your introductory version
>to more users, without you having to go through the expense of making
>hard copies and mailing them yourself. The worst I can see happening
>from your perspective is that its use might take off, and development
>might outstrip that of your full version.


Right, that might work.

>If you were to use the GPL (but license the full version however you
>want, you can do that since its your copyright), then anyone who uses
>the introductory version would have to GPL their program. This would
>still allow for "non-commercial use" like the current license does,
>but it would also allow for commercial use in GPL programs, and more
>importantly use in GPL programs themselves. Again, people could
>redistribute and charge for it, but it would have to be under the GPL.
>You could even release the *full* version this way, and make a
>non-GPL-infecting license one of the things that you are selling (in
>addition to support) to customers. The worst that I could see happen
>here is that some folks might ignore the license and use the GPL CLAW
>in non-GPL programs, which would require lawyers to get involved.


That is also an interesting idea.

>From my perspective, I'd prefer to see you folks take the first tack.
>(I'd actually prefer to see you release the full Claw as GMGPL, with
>paid versions from RR getting media and support, but we've been over
>that already). But its your perspective that matters. What precisely
>worries you about doing either of these?


Well, I have a philosophical objection to the GPL (or, more accurately,
Open Source). I believe programmers have an ethical obligation to stand
behind their programming. There are exceptions, of course (if the
software was stolen, used in a dangerous or illegal way, the software is
for obsolete or unobtainable equipment, or the owner of the software
fired the programmer), but in general, software should be fixed if
practical in a timely fashion. The problem is that the only Open Source
business model that works requires charging for fixes. To make that
work, it is necessary to provide (much) better service to paid
customers, often meaning delaying the availability of public fixes. And
I find that mildy distrubing.

OTOH, I'm plenty aware that the world has changed. Charging for support
has been an important part of RR's business for years. The main problem
(personally) is that I have a hard time delaying the support for
unsupported customers. I've actually tried to figure out how to delay
seeing messages on the Claw mailing list for a couple of days, simply to
facilitate that. (This is the same reason I rarely buy a newspaper --
because I feel compelled to read it all -- a time investment I can't
make.)

So, I'll seriously consider your suggestions. Either may work
sufficiently well to adopt.

                    Randy Brukardt.

Re: Development process in the Ada community

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

>        Sooner or later, the GNAT compiler will reach a point where nobody
> will want to buy suport for it.

There's still a market for support in how to _use_ a product.

Re: Development process in the Ada community

[Georg Bauhaus]

Jeffrey Carter <jeffrey.carter@boeing.com> wrote:

: I've never used a map, but I do use skip lists frequently, probably for
: the same sort of thing.

Are you sure? From the Booch components:

generic
   type Key is private;
   with function "=" (L, R : Key) return Boolean is <>;
package BC.Containers.Maps is

   -- ...

   --  A map denotes a collection forming a dictionary of domain/range
   --  pairs.

   --  The parameter Key denotes the universe from which the map draws
   --  its doamin; the parameter Item denotes the universe from which
   --  the map draws its range. The parameters Key and Item typically
   --  represent different types, although they may may represent the
   --  same types. Either may be a primitive type or user-defined.

   -- ...

end BC.Containers.Maps;

Re: Development process in the Ada community

[Georg Bauhaus]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
: Jeffrey Carter <jeffrey.carter@boeing.com> wrote:
: 
: : I've never used a map, but I do use skip lists frequently, probably for
: : the same sort of thing.
: 
: Are you sure?
ah probably yes. Darn. I've missed the lookup part. sorry.

Re: Development process in the Ada community

[John English]

Hyman Rosen wrote:
> 
> I was just reading somewhere (exactly where escapes me) of a recent
> survey done on C++ programmers who have started using the STL. There
> was some surprise to discover that the most used container was map.
> Apparently what happens is that once programmers have map available,
> they begin using it all over the place, replacing little local ad-hoc
> lookup structures such as linear searches through arrays.

This figures. Java's Hashtable class (and more recent replacements
HashMap and TreeMap) takes a similar pounding; and hashes in Perl
are an absolute godsend. Amazing how much programmer time & effort
can be wasted in languages that don't have something like these.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community

[Robert Dewar]

"Kent Paul Dolan" <xanthian@well.com> wrote in message news:<357f0f4aab2ac8ef39234c96f0ab6311.48257@mygate.mailgate.org>...
> "Ted Dennison" <dennison@telepath.com> wrote:
> 
> > My understanding is that Microsoft is at least partially bankrolling a
> > lot of those compiler ports. So the real issue is why Microsoft didn't
> > think Ada worth worrying about, not why ACT doesn't find .NET worth
> > worrying about.
> 
> That, at least, is a no-brainer.  What made Microsoft attack Java so
> strongly that it took a lawsuit to slap them down?  Java is by design OS
> independent, contributing to breaking the stranglehold of MS-Windows on
> the market of "things needed to run applications".  Microsoft as a
> corporate entity and an untrammeled monopoly feels very _threatened_ by
> the very _concept_ of OS independent programming languages; that's why
> there's a big compiler creating effort inside Microsoft.
> 
> OS independent programming language _by design_.  Can you think of some
> other language that meets that description, and so would meet with that
> reaction at Microsoft?
> 
> xanthian.

Well no doubt it satisfies some need to imagine that Microsoft is
plotting
and scheming against Ada, but I am afraid it is absurd. The reason
that Microsoft is not paying attention to Ada is that they don't hear
from any
serious potential customer base requesting this capability. The reason
that
ACT is not paying attention to .NET is that they don't hear from any
serious
potential customer base requestion this capability.

ACT tunes its activities to what people want. This is not simply a
matter of
corporate good sense (you can't succeed selling people what they don't
want),
but also of contributing most effectively to the Ada community -- much
better
to spend our limited resources on things that people want and need!

Robert Dewar
Ada Core Technologies

Re: Outside view (still): Development process in the Ada community

[Ted Dennison]

Simon Wright <simon@pushface.org> wrote in message news:<x7vu1q9fttc.fsf@smaug.pushface.org>...
> "Pat Rogers" <rogers@gnat.com> writes:
> 
> > And why would I want high-powered text parsing in my hard real-time
> > embedded application?
> 
> Because you want to read the systems's controlling parameter set (in
> our case, a few hundred options) fron an XML-format file (in Flash,
> perhaps)?

I have to chime in here that OpenToken was originally developed as a
configuration file parse tool for a real-time flight simulation.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Marin David Condic]

"Darren New" <dnew@san.rr.com> wrote in message
news:3CBF5244.93CD9323@san.rr.com...
>
> In other words, a "map" is the API to a hash table or a search tree or
> etc. You can implement them with trees, hash tables, linear lists,
> whatever.
>

Don't forget ISAM files. :-) The concept of looking up something from a key
value has been with us for a long time and maybe that's one of the reasons
why maps get beat to death in programming once they're present. My
experience is that if you've got arrays, lists and maps, you don't really
need much else for most applications. Especially once you can easily load
and store them from/to files.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9n0tk$6fs$1@nh.pace.co.uk>...
> When the whole discussion of what eventually began to emerge as Grace got
> started, there seemed to be a consensus that if you had lists and maps, most
> of the other sorts of containers just wouldn't be that big a deal. Lists and
> Maps just cover the bulk of what you need to do in most practical
> programming situations. I wouldn't be surprised that C++ programmers have
> had similar experience. At some point you go: "Maybe there's a more
> efficient structure for this data, but I'm not doing realtime and here's a
> solution already put together for me, so lets just go with it for looking up
> information..."

I've actually been thinking along similar lines. What I'm wondering is
if we should keep the list package as "Lists.Unbounded", or if we
should just bag the whole bounded/unbounded issue and make it "Lists".


> IIRC, there was general agreement to concentrate on Lists as a start and
> then, when the structure of it was settled, a similar spec would be
> discussed for Maps.
> 
> If the Lists specification is considered done, perhaps its time to look at
> it with an eye towards proposing a Map specification?

Indeed. I still don't have the website up unfortunately (I've never
used ssl before, which is required to upload things, so I'm having
"issues".) But the last published proposal spec is still available at
http://www.telepath.com/dennison/Ted/Containers-Lists-Unbounded.ads.html
to refresh everyone's memory.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Open Source: in conflict with the development process in the Ada community?

[Robert Dewar]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9jvhq$lbg$1@nh.pace.co.uk>...

> Even GNAT could arrive at a point where customers say "It works
> well enough for me to do my job and I don't need any add-on, custom
> features, so thanks for your support, but we'll be terminating our contract
> now..." 

Well I don't remember if Marin was ever a customer or not, I think
not, but
in fact this misunderstands the support we provide. It goes far beyond
fixing
bugs, and providing custom features. What we provide most importantly
is consulting and help on the use of Ada, both at the language and
applications
level, and at the level of dealing with problems of interactions with
operating
systems, and other software components.

So Microsoft may have a problem in its long term marketing, but that's
not
comparable at all, since by our standards Microsoft does not provide
support
(and that's not surprising because they don't charge for it -- having
top qualified engineers available for immediate assistance is not
inexpensive)

Certainly part of our support services involves fixing bugs, but
that's a
declining part of the total support traffic, and that's fine with us.
At
the same time, our total customer base for support services is growing
steadily.

Why? Not hard to see. We are in an industry where a days delay for one
engineer
costs something like $1000, *NOT* counting the collateral costs of
delays. It's
pretty easy for us to save a company money once you take this into
account.

As to the question of whether other products can be marketed in this
manner.
I see no reason why not. For example, for a word processor, I am
certainly
NOT about to mess around and build from sources if I can buy a
prebuilt and
pretested executable in a convenient distribution. If in addition, the
product
comes with real support, I am definitely willing to pay more.

I agree that a word processor probably requires less support, and in
particular
that it does not require top engineering experts to provide this
support, so
I would expect such support to be less expensive than GNAT.

People just assume that using a license that is favorable to users
means that
it is imnpossible to make money. But most of this assumption comes
from gut
feeling, tuned by years of exposure to alternative models, rather than
hard
facts.

My viewpoint is that you make money by providing customers with
something
they need. One of the needs is for licenses that are less restrictive
and
do not get in the way of people doing what they need to do. We are in
the
business of responding to this need. We guess that others could
succeed by
being attentive to their users in a similar manner.

Think about the whole discussion of COTS products. What are the two
main
concerns about COTS:

  1. Support being tied to a single company
  2. Long term availability of this support
  3. Ability to customize if needed

The open source free software model responds effectively to all these
concerns. At the same time, people who are interested in the economies
of
scale that come from the use of COTS products are definitely NOT
interested
in using unsupported software.

I think there is a perfect synergy between producer and consumer here,
and
I think it could be applied to many other software products
successfully.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0204190529.559a47ae@posting.google.com...
>
> I've actually been thinking along similar lines. What I'm wondering is
> if we should keep the list package as "Lists.Unbounded", or if we
> should just bag the whole bounded/unbounded issue and make it "Lists".
>
>
O.K. Let's cash in our reality checks and see if they bounce. Would it be
fair to say that *most* Ada developers and applications are some flavor of
Windows/Unix with no realtime requirement beyond "Don't run so slow as to
annoy the user..."? If that's the case, then we're looking at virtual memory
machines that probably run very fast and hence, having fixed or bounded
lists doesn't seem like it would be very important.

If we put out a Grace.Lists and a Grace.Maps, that would certainly be a
really good start. If at a later point in time there was some kind of
groundswell indicating that there really was a need for bounded versions,
why couldn't we go with Grace.Lists.Bounded as an extension? The only reason
I can think of is that it isn't consistent with Ada.Strings.

An interesting observation: When I write most apps for a PC in Ada, I tend
to use the standard, fixed strings only at the points where Ada defined
functions require them. (Stuff like Text_IO) The rest of the time, I just go
to Unbounded because from a programming perspective, its just so much more
convenient. In most instances, whatever performance penalties might exist
for it are so far below the noise floor that they are invisible. Is this
experience unique to me or would most Ada programmers report similar
experience? If Ada were to totally abandon fixed and bounded strings (in the
sense that they were never there - not from any sort of compatibility
perspective), would you notice or care most of the time? (Presuming you
could get them via some add-on package of your own creation if you ever
really needed them?)

My inclination would be to make Grace.Lists and Grace.Maps and add children
at a later date if we thought we needed special cases. I'd again make an
appeal for some version of "Grace.Containers.Lists" and
"Grace.Containers.Maps" (or some variant thereof) so that there might also
be easy extensions like: "Grace.Linear_A", "Grace.Statistics", "Grace.XML",
"Grace.Whatever_Else_Seems_Like_A_Good_Idea"... The names aren't real
important to me but thinking along the line of problem domains & dividing
things up under a subheading is something I think would be beneficial in the
long run.



> >
> > If the Lists specification is considered done, perhaps its time to look
at
> > it with an eye towards proposing a Map specification?
>
> Indeed. I still don't have the website up unfortunately (I've never
> used ssl before, which is required to upload things, so I'm having
> "issues".) But the last published proposal spec is still available at
> http://www.telepath.com/dennison/Ted/Containers-Lists-Unbounded.ads.html
> to refresh everyone's memory.
>
I've still got the link bookmarked and could possibly spend some time
developing some test code, etc., if you think that's of value. (Do you have
a body in some preliminary state I could work to?)

I don't think you need to have the full-blown project setup done in order to
discuss an interface to Maps. What would you suggest as a means of getting
that ball rolling? Would you like someone to take the Lists spec and turn it
into a strawman for Maps? (I hear you're a little preoccupied at the
moment... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Open Source: in conflict with the development process in the Ada community?

[Marin David Condic]

My point was that all products go through a cycle and as GNAT (being a
product) matures in its cycle, new things have to step in to take its place.
That's just conventional business wisdom.

To the extent that you sell services (educational, training, consulting,
whatever) you've got a different kind of value added that is not exactly
tied to the product. Even that goes through its own kind of "product cycle"
wherein it has to change over time or it dries up. At one time there were
lots of companies selling buggy whips. Presumably, there might have been a
whole market for maintaining, repairing and educating users of buggy whips.
But if those companies didn't move on to maintaining, repairing and
educating users of - say - automobile tires, they're consigned to the
dustbin of history.

Product & service cycles are always going to require something new be
developed.

As for a business model that gives the product away to produce a market
needing the services? I'm not against that, but I think it has yet to be
demonstrated that it works for any and all kinds of software. Word
processors being the current example, I've worked for a number of companies
that have used a number of different word processors in a variety of
settings and I don't recall ever once being asked to go find a small team of
experts to contract with for some sort of ongoing support. Maybe we bought
training courses - but that hardly required an open source model. There
might even have been a need for a certain amount of "help desk" support, but
again that didn't require an open source model. One company could sell you
the software and another provide training and question-answering and so
forth.

Does that mean I'm against "Open Source" software? Certainly not. Am I
against giving away the razors in order to later sell the blades? Not if it
works. Can any and all software projects survive and prosper with an open
source, "give the software away to sell the services" model? Maybe. But I
don't think that has yet been demonstrated and I'll bet we could probably go
find examples of business's that have failed using this model.

Hence I wouldn't begrudge any businessman saying "I won't put my software
out on the net under GPL (or similar) because I don't think I can make a
profit doing so."

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0204190620.1902ede@posting.google.com...
>
> Well I don't remember if Marin was ever a customer or not, I think
> not, but
> in fact this misunderstands the support we provide. It goes far beyond
> fixing
> bugs, and providing custom features. What we provide most importantly
> is consulting and help on the use of Ada, both at the language and
> applications
> level, and at the level of dealing with problems of interactions with
> operating
> systems, and other software components.
>
> So Microsoft may have a problem in its long term marketing, but that's
> not
> comparable at all, since by our standards Microsoft does not provide
> support
> (and that's not surprising because they don't charge for it -- having
> top qualified engineers available for immediate assistance is not
> inexpensive)
>
> Certainly part of our support services involves fixing bugs, but
> that's a
> declining part of the total support traffic, and that's fine with us.
> At
> the same time, our total customer base for support services is growing
> steadily.
>
> Why? Not hard to see. We are in an industry where a days delay for one
> engineer
> costs something like $1000, *NOT* counting the collateral costs of
> delays. It's
> pretty easy for us to save a company money once you take this into
> account.
>
> As to the question of whether other products can be marketed in this
> manner.
> I see no reason why not. For example, for a word processor, I am
> certainly
> NOT about to mess around and build from sources if I can buy a
> prebuilt and
> pretested executable in a convenient distribution. If in addition, the
> product
> comes with real support, I am definitely willing to pay more.
>
> I agree that a word processor probably requires less support, and in
> particular
> that it does not require top engineering experts to provide this
> support, so
> I would expect such support to be less expensive than GNAT.
>
> People just assume that using a license that is favorable to users
> means that
> it is imnpossible to make money. But most of this assumption comes
> from gut
> feeling, tuned by years of exposure to alternative models, rather than
> hard
> facts.
>
> My viewpoint is that you make money by providing customers with
> something
> they need. One of the needs is for licenses that are less restrictive
> and
> do not get in the way of people doing what they need to do. We are in
> the
> business of responding to this need. We guess that others could
> succeed by
> being attentive to their users in a similar manner.
>
> Think about the whole discussion of COTS products. What are the two
> main
> concerns about COTS:
>
>   1. Support being tied to a single company
>   2. Long term availability of this support
>   3. Ability to customize if needed
>
> The open source free software model responds effectively to all these
> concerns. At the same time, people who are interested in the economies
> of
> scale that come from the use of COTS products are definitely NOT
> interested
> in using unsupported software.
>
> I think there is a perfect synergy between producer and consumer here,
> and
> I think it could be applied to many other software products
> successfully.

Re: Development process in the Ada community

[Ingo Marks]

John English wrote:

> Hyman Rosen wrote:
>
> This figures. Java's Hashtable class (and more recent replacements
> HashMap and TreeMap) takes a similar pounding; and hashes in Perl
> are an absolute godsend. Amazing how much programmer time & effort
> can be wasted in languages that don't have something like these.

Perl has several nice features which makes it easy to write applications in 
short time with small effort. But I tell you from experience, it doesn't 
make it easy to maintain them! IMHO Perl (like APL) is a pretty 
"write-only" language ;-) When code reaches a "critical mass" of size then 
readibility and helpful features like range constrained data types (which 
AFAIK Perl and Java don't have) become much more important than the nice 
builtin-language features of Perl. Hence to clone these features in Ada is 
no wasted effort at all. On the contrary, it makes us able to used the so 
appreciated Perl and Java features in Ada too, in its much cleaner syntax.

Regards,
Ingo

Re: Outside view (still): Development process in the Ada community

[Michael Erdmann]

Marin David Condic wrote:
> "Richard Riehle" <richard@adaworks.com> wrote in message
> news:3CBE49C4.99CFA22D@adaworks.com...
> 

> 
> I think the W3C has a kind of interesting approach. They sort of look over a
> problem and put up a web page that says "Here's a standard that addresses
> the problem. Do you like it?" They might even put out two or three competing
> or overlapping standards to see which ones seem to begin to fly. The
> standards keep going through revisions as comments come in and sooner or
> later they declare victory and say "O.K. This standard is considered stable,
> so we promise no more changes to it." If better ideas and enhancements come
> along, they start a "Level 2" for the standard.

I agree on this. The process which leads to a standard always has to
considder the evolution process for standards by establishing procedures
for refinement and reworking. I guess ISO/ITU/ETSI just name it do
have such procedures. The problem is a different one,
If you invested a lot effort in implementing a standard, then
you are  not automatically interested in revising it unless is
simply does not work. I think this is the reason why new
standards go along with social changes in the respective
community.

> 
> Wouldn't something similar work for adding libraries to Ada? Some sort of
> consortium of vendors and users to develop library specs & possibly bodies
> that go through iterations until everyone is happy or at least too tired to
> keep arguing about it? Then declare some version of "By Convention, Ada
> Compilers Will Include This..." as a non-binding "standard" for adoption by
> members.
> 
For example if you look at the python enhancement process you will find
that it works like this. This is not a standarization but it is an
improvement process (pep - http://www.python.org/pep/pep-0001.html).

May be we can adopt this some how to establish an ada enhancment
process?





> Just an idea....
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> 
> 

Re: Outside view (still): Development process in the Ada community

[Marin David Condic]

Other than issues of time and money, I don't see why it *can't* work. Here's
the thing: I could put up a web page and declare myself the Informal Ada
Conventions Consortium and declare "Henceforth, the following packages are
considered to be Official IACC standards and all Ada implementations need to
include them in order to be  conformant!" What weight does it carry?

That's why it would need some kind of committee of concerned citizens under
the aegis of SIGAda (or some other organization) with some pretty strong
willingness on the part of vendors to buy into it. The process needs to be
agile and probably needs to yield reference implementations rather than just
specifications, or it isn't likely to effectively get anything into various
compiler distributions.You'd like to think that perhaps it could produce
some sort of new extension to the library, say, every 6 months? That might
do a lot to make it reactive to the needs of the community & move Ada closer
to the capabilities of its competitors.

Of course, getting any of this off bottom-dead-center is a difficult thing.
It would require some corporate and institutional support, both for the
concept and by way of some finances. Is that likely to happen?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
news:3CC05650.5060908@snafu.de...
>
> May be we can adopt this some how to establish an ada enhancment
> process?
>
>

Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community

[rc211v]

On Thu, 18 Apr 2002 18:35:28 +0000 (UTC), "Kent Paul Dolan"
<xanthian@well.com> wrote:


>Java is by design OS
>independent, contributing to breaking the stranglehold of MS-Windows on
>the market of "things needed to run applications". 

Java is _by_design_ a marketing product in search of a real problem to
solve.

I've recently discovered a very nice portable graphics library, FOX.

The goal of it's designer is: "Write Once, Compile Anywhere" ... 

For those who want to take a look go to http://fox-toolkit.org . Just
download the calculator demo. You will be impressed. 

Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community

[Kent Paul Dolan]

"Robert Dewar" <dewar@gnat.com> wrote:

> Well no doubt it satisfies some need to imagine that Microsoft is
> plotting and scheming against Ada, but I am afraid it is absurd.

I don't think that should be read as the intent of my remarks.

Microsoft _is_ plotting and scheming against (at least some) anything(s)
that make(s) application programming OS independent (and the court
transcripts and judgements exist to prove that) and thereby free people
to make an OS choice based on quality instead of market share.

Whether Microsoft even knows Ada exists is sort of equally irrelevant as
whether the steamroller operator knows the earthworm on the pavement
ahead of him exists.

If the goal is to flatten all obstacles to worldwide domination of a
single dappy operating system, the incidental kills will probably be
numerous, just as when the shrimp seine kills tenfold as many pounds of
fish as it catches pounds of shrimp, and the dead fish are simply thrown
back overboard.

xanthian.



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community?

[Kent Paul Dolan]

Thanks extremely much for that economics lesson, Robert.  I
was about to frame as a query a completely wrongheaded guess
at how open source folks get paid a living wage, to promote
discussion, and you have not only saved readers in c.l.a the
grief, but provided something deeply needed in the community
_considering_ open source, a discussion from within a
successful operation of how it works.

I have taken the liberty of reformatting what you wrote
(your text producer is too wide for your posting tool's
wrapper length), and crossposting to another venue where
similar discussions are underway.

Robert Dewar wrote in comp.lang.ada:

: "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote

:> Even GNAT could arrive at a point where customers say "It
:> works well enough for me to do my job and I don't need any
:> add-on, custom features, so thanks for your support, but
:> we'll be terminating our contract now..." 

=> Well I don't remember if Marin was ever a customer or not, I
=> think not, but in fact this misunderstands the support we
=> provide. It goes far beyond fixing bugs, and providing
=> custom features. What we provide most importantly is
=> consulting and help on the use of Ada, both at the language
=> and applications level, and at the level of dealing with
=> problems of interactions with operating systems, and other
=> software components.

=> So Microsoft may have a problem in its long term marketing,
=> but that's not comparable at all, since by our standards
=> Microsoft does not provide support (and that's not
=> surprising because they don't charge for it -- having top
=> qualified engineers available for immediate assistance is
=> not inexpensive)

=> Certainly part of our support services involves fixing bugs,
=> but that's a declining part of the total support traffic,
=> and that's fine with us.  At the same time, our total
=> customer base for support services is growing steadily.

=> Why? Not hard to see. We are in an industry where a days
=> delay for one engineer costs something like $1000, *NOT*
=> counting the collateral costs of delays. It's pretty easy
=> for us to save a company money once you take this into
=> account.

=> As to the question of whether other products can be marketed
=> in this manner.  I see no reason why not. For example, for a
=> word processor, I am certainly NOT about to mess around and
=> build from sources if I can buy a prebuilt and pretested
=> executable in a convenient distribution. If in addition, the
=> product comes with real support, I am definitely willing to
=> pay more.

=> I agree that a word processor probably requires less
=> support, and in particular that it does not require top
=> engineering experts to provide this support, so I would
=> expect such support to be less expensive than GNAT.

=> People just assume that using a license that is favorable to
=> users means that it is imnpossible to make money. But most
=> of this assumption comes from gut feeling, tuned by years of
=> exposure to alternative models, rather than hard facts.

=> My viewpoint is that you make money by providing customers
=> with something they need. One of the needs is for licenses
=> that are less restrictive and do not get in the way of
=> people doing what they need to do. We are in the business of
=> responding to this need. We guess that others could succeed
=> by being attentive to their users in a similar manner.

=> Think about the whole discussion of COTS products. What are
=> the two main concerns about COTS:

=>   1. Support being tied to a single company
=>   2. Long term availability of this support
=>   3. Ability to customize if needed

=> The open source free software model responds effectively to
=> all these concerns. At the same time, people who are
=> interested in the economies of scale that come from the use
=> of COTS products are definitely NOT interested in using
=> unsupported software.

=> I think there is a perfect synergy between producer and
=> consumer here, and I think it could be applied to many other
=> software products successfully.



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Grace and Maps (was Re: Development process in the Ada community)

[David Bolen]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> When the whole discussion of what eventually began to emerge as Grace got
> started, there seemed to be a consensus that if you had lists and maps, most
> of the other sorts of containers just wouldn't be that big a deal. Lists and
> Maps just cover the bulk of what you need to do in most practical
> programming situations. I wouldn't be surprised that C++ programmers have
> had similar experience.  (...)

And from another language perspective, in Python, the fundamental
built-in data structure types (aside from numerics) are sequences
(lists/tuples) and mappings (dictionaries) and certainly in my
experience they cover the vast majority of practical situations quite
capably.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community

[Larry Kilgallen]

In article <i661cuklbc689igifq22srkt101847die8@4ax.com>, rc211v <rc211v@attglobal.net> writes:
> On Thu, 18 Apr 2002 18:35:28 +0000 (UTC), "Kent Paul Dolan"
> <xanthian@well.com> wrote:
> 
> 
>>Java is by design OS
>>independent, contributing to breaking the stranglehold of MS-Windows on
>>the market of "things needed to run applications". 
> 
> Java is _by_design_ a marketing product in search of a real problem to
> solve.

Java is _by_design_ a programming language intended to be safer
than C.  Two years ago Sun's Chief Technology Officer spoke at
the RSA Conference and pointed out that the bytecode engine and
web stuff was not the original reason Sun was interested in Java.

The write-once, debug-everywhere approach stems only from that
latter use of Java, having not much to do with native compiled
Java.

Re: Development process in the Ada community

[Larry Kilgallen]

In article <a9p63b$71q$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> "Darren New" <dnew@san.rr.com> wrote in message
> news:3CBF5244.93CD9323@san.rr.com...
>>
>> In other words, a "map" is the API to a hash table or a search tree or
>> etc. You can implement them with trees, hash tables, linear lists,
>> whatever.
>>
> 
> Don't forget ISAM files. :-)

Funny you should mention that.  I am currently working on a program
that does such ordered lookups on temporary data read into the program,
and I did not even consider the possibility of using (virtual) memory
to store it, since I do not want to make assumptions regarding how much
data there will be.  ISAM files are just a natural fit.  If you tell me
that what you are calling "maps" are a portable way of doing that, I
suppose that would be useful, although using files directly is fine
with me.

Re: Development process in the Ada community

[Simon Wright]

dennison@telepath.com (Ted Dennison) writes:

> Maps would certianly be my prime candidate. My last project
> incorporated the Booch Components just for the map support. It also
> seemed to be the most talked about other component during the
> strawman list discussions (although admittedly I was doing a lot of
> that talking).

My current (work) project is using the BCs as the infrastructure for a
(Rose)UML-to-Ada tool of mine called ColdFrame (work in progresss at
http://www.pushface.org/coldframe/). I've used

  Maps as the container for all the instances of a class (keyed by the
  Identifier, the (combination of) attributes that uniquely identify
  instances)

  Collections for dealing with the results of searches

  Sets for ensuring uniqueness when navigating from Collections of one
  class via an association (this was overkill, perhaps)

  Ordered Queues for handling events.

No trace of Stacks, Bags, Rings, Graphs, Trees!

Re: Development process in the Ada community

[Ted Dennison]

Randy Brukardt wrote:

> Well, I have a philosophical objection to the GPL (or, more accurately,
> Open Source). I believe programmers have an ethical obligation to stand
> behind their programming. There are exceptions, of course (if the


I really didn't understand what you were getting at here, till I got 
down to this next part:

> has been an important part of RR's business for years. The main problem
> (personally) is that I have a hard time delaying the support for
> unsupported customers. I've actually tried to figure out how to delay
> seeing messages on the Claw mailing list for a couple of days, simply to


Ahhhh. I think I understand. As someone who has multiple publicly 
available projects out there, I certianly know the feeling of moral 
obligation when someone asks for help with a problem in *your* code. 
With me, occasionally someone will just be so lost that it would take 
forever to help them out, and I have other commitments (a job, a house 
and yard, a wife and 2 kids) that preclude me from spending the time to 
give them the help they need. Its always painful when I have to tell 
someone I can't help them any further.


I think no matter how you go, at some point you do have to draw a line. 
ACT seems to do it by prioritzing bug fixes in favor of paying customers 
by being a bit anal about submitted bug reports being in the proper form 
from unsupported users, and by giving supported customers first dibbs on 
newly-developed code and bug fixes. It apparently works for them, but I 
have at times thought I'd have trouble being as rutheless about it as 
they seem to be. And let's not even get into the fact that asking 
customers not to redistribute the fixes you give them to non-customers 
is quite against the spirit of the GPL...

 > facilitate that. (This is the same reason I rarely buy a newspaper --
 > because I feel compelled to read it all -- a time investment I can't
 > make.)

Funny. I have that exact same problem with newspapers too. I tried 
explaining this to my father-in-law (a retired English teacher and 
regular newspaper reader) and he looked at me like I had 3 heads. :-)

Re: Open Source: in conflict with the development process in the Ada community?

[tmoran]

> What we provide most importantly is consulting and help on the use of Ada,
  So ACT should be thought of as a software consulting company that
happens to also maintain a compiler?

Re: Open Source: in conflict with the development process in the Ada community?

[Florian Weimer]

tmoran@acm.org writes:

>> What we provide most importantly is consulting and help on the use of Ada,

>   So ACT should be thought of as a software consulting company that
> happens to also maintain a compiler?

Yes, probably.  If they were a compiler company, they wouldn't be
permitted to give GNAT away for free (at least in Germany, but I think
U.S. law is similar).

Re: Open Source: in conflict with the development process in the Ada community?

[Frank J. Lhota]

Under what law (in either Germany or the U.S.) would forbid a company from
giving away a compiler?

Re: Open Source: in conflict with the development process in the Ada community?

[Florian Weimer]

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:

> Under what law (in either Germany or the U.S.) would forbid a company from
> giving away a compiler?

Regulations against unfair competition.  Hmm, I couldn't find a
reference to specific German law, but I remember a few cases in which
companies were forced to stop giving services away for free.  However,
I'm no longer sure if general provisions against unfair competition
were applied, or some special case law (telco regulations, for
example).

Re: Grace and Maps (was Re: Development process in the Ada community)

[Michael Erdmann]

Marin David Condic wrote:
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:4519e058.0204190529.559a47ae@posting.google.com...
> 
>>I've actually been thinking along similar lines. What I'm wondering is
>>if we should keep the list package as "Lists.Unbounded", or if we
>>should just bag the whole bounded/unbounded issue and make it "Lists".
>>
>>
>>
> O.K. Let's cash in our reality checks and see if they bounce. Would it be
> fair to say that *most* Ada developers and applications are some flavor of
> Windows/Unix with no realtime requirement beyond "Don't run so slow as to
> annoy the user..."? If that's the case, then we're looking at virtual memory
> machines that probably run very fast and hence, having fixed or bounded
> lists doesn't seem like it would be very important.
> 
> If we put out a Grace.Lists and a Grace.Maps, that would certainly be a
> really good start. If at a later point in time there was some kind of
> groundswell indicating that there really was a need for bounded versions,
> why couldn't we go with Grace.Lists.Bounded as an extension? The only reason
> I can think of is that it isn't consistent with Ada.Strings.
> 
> An interesting observation: When I write most apps for a PC in Ada, I tend
> to use the standard, fixed strings only at the points where Ada defined
> functions require them. (Stuff like Text_IO) The rest of the time, I just go
> to Unbounded because from a programming perspective, its just so much more
> convenient. In most instances, whatever performance penalties might exist
> for it are so far below the noise floor that they are invisible. Is this
> experience unique to me or would most Ada programmers report similar
> experience? If Ada were to totally abandon fixed and bounded strings (in the
> sense that they were never there - not from any sort of compatibility
> perspective), would you notice or care most of the time? (Presuming you
> could get them via some add-on package of your own creation if you ever
> really needed them?)

I have to agree on your observation, convenience is very important. In
earlier days there was a lot of disussion about the yield of high level
languages compared with low level methods like assembler. The discusion
was around the same issue, performance, realtime behaviour, memory usage
etc....

So i agree, i would be a good start which is proably covering most of
our requirements.

Without trying it, we will never fail, which means we will continue
discussing without learning anything by testing the aproach in
real life development scenarios.

Regards
     M.Erdmann

Re: Open Source: in conflict with the development process in the Ada community?

[Frank J. Lhota]

If there is a law against giving away software, AOL is in real trouble.

Re: Open Source: in conflict with the development process in the Ada community?

[Robert Dewar]

Florian Weimer <fw@deneb.enyo.de> wrote in message news:<87lmbidfny.fsf@deneb.enyo.de>...
> tmoran@acm.org writes:
> 
> >> What we provide most importantly is consulting and help on the use of Ada,
>  
> >   So ACT should be thought of as a software consulting company that
> > happens to also maintain a compiler?

No. That's quite incorrect. Just like Microsoft (for instance) we
provide
licensed copyrighted software with support for a fee. What
distinguishes
us from Microsoft in this regard is two things

1. Our software license is much more advantageous to users

2. We provide much more extensive support.
 
> Yes, probably.  If they were a compiler company, they wouldn't be
> permitted to give GNAT away for free (at least in Germany, but I think
> U.S. law is similar).

Please don't play amateur lawyer, the above statement is nonsense!

And in any case we are a compiler company, and we do NOT give GNAT Pro
(the name of our commercial product) away for free!

Robert Dewar
Ada Core Technologies

P.S. how anyone even a little remotely aware of current events could
think
that there was a law against giving software away free is surprising
to me.
Florian, don't you follow current events (e.g. Netscape vs Microsoft,
at all?)

Bundling of software can in some cases have Sherman act implications,
but no, there is no law per se against giving things away free :-)
However, don't
expect ACT to be in that business :-)

Re: Development process in the Ada community

[Robert Dewar]

Ted Dennison <dennison@telepath.com> wrote in message news:<3CC10367.4000904@telepath.com>...
> Randy Brukardt wrote:
> 
> > Well, I have a philosophical objection to the GPL (or, more accurately,
> > Open Source). I believe programmers have an ethical obligation to stand
> > behind their programming. There are exceptions, of course (if the

The GPL has very little to do with Open Source. I would say the above
indicates that Randy does not understand the term. The GPL is merely a
software license that gives users of your software more rights than
most
typical licenses. If you say you are philosophically opposed to the
GPL,
you are simply saying that you are happy only with restrictive
licenses
that give your users few rights. Hard to see how you could be
philosophically
in favor of restricting rights in this way, easy enough to see how you
could
be commercially in favor of such restrictions. And indeed it is clear
enough
that Randy's objections to open source should be taken with a grain of
salt,
considering that, like Microsoft, he is in the proprietary software
business
and finding himself in competition with GPL'ed software :-)

> Ahhhh. I think I understand. As someone who has multiple publicly 
> available projects out there, I certianly know the feeling of moral 
> obligation when someone asks for help with a problem in *your* code. 

> With me, occasionally someone will just be so lost that it would take 
> forever to help them out, and I have other commitments (a job, a house 
> and yard, a wife and 2 kids) that preclude me from spending the time to 
> give them the help they need. Its always painful when I have to tell 
> someone I can't help them any further.

And it is *less* painful not to give them anything in the first
place???
Sort of like meeting a beggar on the street and deciding to give
nothing,
because otherwise you will feel a moral obligation to provide food,
clothing,
and housing :-)
 
> I think no matter how you go, at some point you do have to draw a line. 
> ACT seems to do it by prioritizing bug fixes in favor of paying customers 

It is not a matter of prioritizing, ALL our work is aimed at providing
services
to our customers. You need to get used, as you would with any other
company,
of assuming that everything we do is aimed at satisfying our existing
customers
and getting more customers. 

> by being a bit anal about submitted bug reports being in the proper form 
> from unsupported users

That's because we find it is only worth while for us to pay attention
to well
submitted reports. We pay attention to such reports not to help those
who submit them, to whom we have no obligations at all, but because if
the reports
are clear and cleanly submitted, then it may be helpful to our
customers to
fix problems found in this way.

Most useful reports from ACT come from a small group of people to whom
we
have give "external tester" status (those of you reading this know you
are).
These are people who have in the past submitted helpful reports in a 
constructive manner, and we give them a special pseudo-customer number
and
track their submissions. Again, we do this not because of any
obligation to
this group of people, but because they help us with our primary goal
of providing high quality products for our customers.

The majority of reports on the public version from outside this group
have
proved of relatively small value (there are exceptions, but few and
far
between). Mostly they are people asking questions that could for
instance
be answered by reading the manual. For our customers, we are more than
happy
to answer all questions, that's part of what they are paying for, but
we have
no time for non-customers unless they are helping us!

> and by giving supported customers first dibbs on 
> newly-developed code and bug fixes. It apparently works for them, but I 
> have at times thought I'd have trouble being as rutheless about it as 
> they seem to be.

How odd .. Ted Dennison is indeed one of the people who over the years
has
chafed at not being able to get free support, but I don't feel the
least bit
"ruthless" in not providing Ted any kind of support. We are like any
other
company, we have to provide services for our customers, we are not
some kind
of charitable organization that has been set up to keep non-customers
like
Ted happy :-)

> And let's not even get into the fact that asking 
> customers not to redistribute the fixes you give them to non-customers 
> is quite against the spirit of the GPL...

We have never said this to customers (Ted wouldn't know, he has never
been
a customer). Now of course this does not mean Boeing is going to take
the
time, effort (and incur the possible liability) of distributing
software to
Ted. The GPL is about giving Boeing all the freedom that Boeing needs
to make
full use of the software. That is relatively unlikely to include
sending
copies to Ted :-)

By the way, I find it highly amusing for Ted to be pontificating on
the GPL
like this. It is in fact perfectly within the spirit of the GPL to ask
(not
require) people not to distribute certain software at certain times.
For
example, the GNU project itself frowns on people taking untested
snapshots
and making them into widely distributed products. It's just not
helpful to
the GNU project to have this kind of half baked software wandering
around.
Richard Stallman certainly would not agree with Ted's assessment of
the
"spirit of the GPL" here. The spirit of the GPL is about allowing
effective
sharing of software. Sometimes, effective sharing involves NOT
prematurely
widely distributing things, and everyone understands this.

> Funny. I have that exact same problem with newspapers too. I tried 
> explaining this to my father-in-law (a retired English teacher and 
> regular newspaper reader) and he looked at me like I had 3 heads. :-)

Yes I can sympathize (with your father-in-law -- most odd indeeed) :-)

Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community?

[Robert Dewar]

"Kent Paul Dolan" <xanthian@well.com> wrote in message news:<fabfb33253b2dea9ae61e01e4a71de03.48257@mygate.mailgate.org>...

One thing that is interesting here is that we are not really an
Open Source developer. The idea of open source development is that
development is a shared community activity, and that all sorts of
people contribute to the development.

The advantages of such a model are clear: you get a larger community
of people involved in the development.

The disadvantages are also clear, you have far less control over the
development process.

If you follow the gcc development mailing list, you will certainly
see both of these effects in action.

GNAT Pro is not an open source product in this respect. The development
of GNAT Pro is tightly controlled, more tightly controlled indeed internally
than is the case in most other software companies.

Now there is also an open source development community developing for the
FSF version of GNAT at gnu.org, and we participate in this. We hope that
we will be able to take advantage of contributions here and eventually have
some of them show up in GNAT Pro after going through our rigorous internal
process. 

But it is fairly critical that our internal development process is not open
to uncontrolled community contributions.

We have heard recently that the Army has a policy against open source
development, and while I don't know if this is true, or what the details
are, I have some sympathy with the thought behind such a policy. The
concern is centered on the disadvantages that can come with uncontrolled
development, and this is indeed a real concern. 

That's why I think the model of commercial closed development will always
persist, and what I think the ACT experience has shown is that this is by
no means inconsistent with the notions of Free Software and the use of the GPL.

Re: Outside view (still): Development process in the Ada community

[Michael Erdmann]

Marin David Condic wrote:
> Other than issues of time and money, I don't see why it *can't* work. Here's
> the thing: I could put up a web page and declare myself the Informal Ada
> Conventions Consortium and declare "Henceforth, the following packages are
> considered to be Official IACC standards and all Ada implementations need to
> include them in order to be  conformant!" What weight does it carry?
> 
> That's why it would need some kind of committee of concerned citizens under
> the aegis of SIGAda (or some other organization) with some pretty strong
> willingness on the part of vendors to buy into it.

In the Moment i can see only one vendor.But SIGAda may be a good idea!

> The process needs to be
> agile and probably needs to yield reference implementations rather than just
> specifications, or it isn't likely to effectively get anything into various
> compiler distributions.

Yes, this is what we talked earlier about.

Step 1 -Get a group together
Step 2 - make a reference implementation
Step 3 - distribute it with one of the most common compiler(s).


> You'd like to think that perhaps it could produce
> some sort of new extension to the library, say, every 6 months? 

Yes, follow the guideline, release early and often when you are
building the reference implemenation.

> That might
> do a lot to make it reactive to the needs of the community & move Ada closer
> to the capabilities of its competitors.
> 
This is not all, what you need is to have some kind of crystalization
point for such kind of work, in order to avoid that if a maintainer
of a package drops out, a package is without any maintainer.

> Of course, getting any of this off bottom-dead-center is a difficult thing.
> It would require some corporate and institutional support, both for the
> concept and by way of some finances. Is that likely to happen?
I do not think so. In the case of the python enhancement process
have hove not yet found out who is the commercial engiene. But i am
not so sure if it is realy needed.

I think the most important thing in the moment is the step 1,
getting a groups of people together, working( not only discussing) on
packages which are important to the Ada community!

Regards
    M.Erdmann

Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community?

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<fabfb33253b2dea9ae61e01e4a71de03.48257@mygate.mailgate.org>...
>
> One thing that is interesting here is that we are not really an
> Open Source developer. The idea of open source development is that
> development is a shared community activity, and that all sorts of
> people contribute to the development.

According to Eric S. Raymond, "Open Source" does not necessarily imply
the Bazaar model, the Cathedral model (which was once common to many
GNU projects---Emacs, for example, joined the Bazaar only rather
recently) is still considered "Open Source".

Re: Development process in the Ada community

[tmoran]

> > > Open Source). I believe programmers have an ethical obligation to stand
> > > behind their programming.
>
> The GPL has very little to do with Open Source. I would say the above
> indicates that Randy does not understand the term. The GPL is merely a
  Perhaps I shouldn't be guessing what Randy meant, but I suspect he was
thinking "in practice" rather than "in theory", and considering the "give
it away for free, charge a bundle for support" model for GPL product
funding.  That model requires that you do support only for cash, ignoring
any latent feelings of obligation to stand behind your programming.

> The GPL is merely a software license that gives users of your software
> more rights ...
  Different, not More.  A set of rights is not one-dimensional with an
obvious ordering.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Jeffrey Carter]

Marin David Condic wrote:
> 
> O.K. Let's cash in our reality checks and see if they bounce. Would it be
> fair to say that *most* Ada developers and applications are some flavor of
> Windows/Unix with no realtime requirement beyond "Don't run so slow as to
> annoy the user..."? If that's the case, then we're looking at virtual memory
> machines that probably run very fast and hence, having fixed or bounded
> lists doesn't seem like it would be very important.

No, it wouldn't be fair, at least not from my perspective. But it would
be a good start, so I have no objection to it.

> 
> If we put out a Grace.Lists and a Grace.Maps, that would certainly be a
> really good start. If at a later point in time there was some kind of
> groundswell indicating that there really was a need for bounded versions,
> why couldn't we go with Grace.Lists.Bounded as an extension? The only reason
> I can think of is that it isn't consistent with Ada.Strings.

While I agree with this, if Grace becomes accepted, and we submit it to
the ARG as has been requested on the Ada-Comment mailing list, then it
would become part of the Ada.* hierarchy, so I suggest that consistency
with those naming conventions would be a Good Thing.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail

Re: Development process in the Ada community

[tmoran]

> > I certianly know the feeling of moral obligation when someone asks
> > for help with a problem in *your* code.
> > ...
> > Its always painful when I have to tell
> > someone I can't help them any further.
>
> And it is *less* painful not to give them anything in the first
> place???
> Sort of like meeting a beggar on the street and deciding to give
> nothing,
> because otherwise you will feel a moral obligation to provide food,
> clothing,
> and housing :-)
  Perhaps giving them software, then not helping when they get stuck,
is more like finding a beggar, showing him the beer and chips in your
car, driving him out to the beautiful countryside, set him down to
munch the salty chips, then, when he asks for a beer, you announce the
beer, and the ride back to town, are expensive.  I suppose there are
those who would claim the moral high ground "but I fed the beggar".

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Marin David Condic wrote:

> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:4519e058.0204190529.559a47ae@posting.google.com...
> 
>>I've actually been thinking along similar lines. What I'm wondering is
>>if we should keep the list package as "Lists.Unbounded", or if we
>>should just bag the whole bounded/unbounded issue and make it "Lists".
>>
>>
>>
> O.K. Let's cash in our reality checks and see if they bounce. Would it be
> fair to say that *most* Ada developers and applications are some flavor of
> Windows/Unix with no realtime requirement beyond "Don't run so slow as to
> annoy the user..."? If that's the case, then we're looking at virtual memory


I honestly have no clue. The vast majority of my Ada use has been 
real-time or embedded (where dynamic allocation is often unavailable), 
and I do notice that there seem to be a large number of Ada compilers 
for such platforms. But I also realise that's just the view from my 
window, not a scientific representative sample.

What I was thinking is that we have 2 reasonable approaches: The first 
would be to keep "Lists" as a parent package with an "Unbounded" child. 
The main advantage to this, and the reason it currently is this way, is 
that it matches what we already have in place for string support.

Another possiblity would be to keep the name simple (Grace.Lists), and 
give the bounded version its own name when/if the time comes. Something 
like "Circular_Lists" (or Booch's "Ring") might be a possibility. This 
concept extends to Maps too, as we could call them "Maps" and "Hashes" 
rather than "Maps.Unbounded" and "Maps.Bounded". Not only is this a 
simpler structure, we no longer have the name talking about internal 
features of the structure instead of external features. That could be 
good enough for real-time and embedded folks if we document its use (or 
lack of use) of heap properly.

But the argument for consistency with Ada.Strings.* is fairly compelling 
too.

> An interesting observation: When I write most apps for a PC in Ada, I tend
> to use the standard, fixed strings only at the points where Ada defined
> functions require them. (Stuff like Text_IO) The rest of the time, I just go
> to Unbounded because from a programming perspective, its just so much more
> convenient. In most instances, whatever performance penalties might exist


That's funny. If anything, I'm the opposite. I go with fixed strings 
wherever I can without having to keep a separate length variable (which 
can be nearly anywhere once you learn how to do it). Text_IO.Get_Line is 
the annyoing exception where I'd like to use Unbounded, but can't.

Strings a generally the kind of object that only holds one value for 
their entire lifetime. The trick is that figuring out what the proper 
one value is can sometimes be a bit of work. Reading textual input is 
the primary significant exception to this.

> My inclination would be to make Grace.Lists and Grace.Maps and add children
> at a later date if we thought we needed special cases. I'd again make an
> appeal for some version of "Grace.Containers.Lists" and
> "Grace.Containers.Maps" (or some variant thereof) so that there might also
> be easy extensions like: "Grace.Linear_A", "Grace.Statistics", "Grace.XML",
> "Grace.Whatever_Else_Seems_Like_A_Good_Idea"... The names aren't real
> important to me but thinking along the line of problem domains & dividing
> things up under a subheading is something I think would be beneficial in the
> long run.


I'm curious if other people feel this way. I'd lean towards 
"Grace.Lists", as the standard Ada library is equally flat, our list of 
components may not end up being large, and there isn't liable to be much 
common code sitting in the "Components" spec. But I'm not married to the 
idea. We certianly need to name for proper growth, as renaming files in 
CVS is kind of a kludge.


> I've still got the link bookmarked and could possibly spend some time
> developing some test code, etc., if you think that's of value. (Do you have
> a body in some preliminary state I could work to?)


Its actually pretty much done. It could perhaps use some more testing. 
But we just need to arrive at a proper name, and I'll check it into 
Grace's CVS.


> I don't think you need to have the full-blown project setup done in order to
> discuss an interface to Maps. What would you suggest as a means of getting
> that ball rolling? Would you like someone to take the Lists spec and turn it
> into a strawman for Maps? (I hear you're a little preoccupied at the
> moment... :-)

Yeah, that would be a good start. Right now in addtion to this I'm 
trying to figure out if I need to buy 3 smaller child car seats or a 
larger car. :-(

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Michael Erdmann wrote:

> Without trying it, we will never fail, which means we will continue


That ought to be my battle cry! :-)

Tick: "Spoon!"
Authur: "Not in the face! Not in the face!"
T.E.D.: "Without trying, we will never fail!"
(melee ensues)

Re: Development process in the Ada community

[Ted Dennison]

Robert Dewar wrote:

> Ted Dennison <dennison@telepath.com> wrote in message news:<3CC10367.4000904@telepath.com>...
> 
>>With me, occasionally someone will just be so lost that it would take 
>>forever to help them out, and I have other commitments (a job, a house 
>>and yard, a wife and 2 kids) that preclude me from spending the time to 
>>give them the help they need. Its always painful when I have to tell 
>>someone I can't help them any further.
>>
> 
> And it is *less* painful not to give them anything in the first
> place???
> Sort of like meeting a beggar on the street and deciding to give
> nothing,
> because otherwise you will feel a moral obligation to provide food,
> clothing,
> and housing :-)


I'm not sure how your analogy relates to what I said at all (perhaps you 
thought I was talking about not helping at all, rather than giving up 
when there's no more I can reasonably do?). However, that is actually a 
fair charactarization of my attitude toward beggars, so perhaps you are 
onto something. :-)


>>by being a bit anal about submitted bug reports being in the proper form 
>>from unsupported users
>>
> 
> That's because we find it is only worth while for us to pay attention
> to well submitted reports. We pay attention to such reports not to help those


Exactly. I wasn't trying to complain about it, so no explanation was 
really nessecary. I was pointing out what I thought was a pretty 
effective policy of yours.

> How odd .. Ted Dennison is indeed one of the people who over the years
> has chafed at not being able to get free support, but I don't feel the
> least bit "ruthless" in not providing Ted any kind of support. We are like any


Hmmm. I really don't remember ever having any big problem with ACT not 
doing free work for me. However, we've both been around here a very long 
time, and my memory's notoriously bad, so I'll grant that I could be 
wrong. If I ever did cop that kind of attitude, I'm sorry. That's a 
really stupid way for me (or anyone else) to behave.

OK...now that I think about it there was that one time I fatally flubbed 
a bug report (in a way that would have required work on ACT's part to 
straighten it out). But that was my own stupid fault. You were 
absolutely right to bounce it.

>For
>example, the GNU project itself frowns on people taking untested
>snapshots
>and making them into widely distributed products. It's just not
>helpful to
...
> "spirit of the GPL" here. The spirit of the GPL is about allowing
> effective
> sharing of software. Sometimes, effective sharing involves NOT
> prematurely
> widely distributing things, and everyone understands this.


I guess you're right there, as far as the current situation goes. It was 
really more of an issue in days gone by, when there was no public 
baseline like typical GNU projects have to go to for interim bug fixes. 
Thus you were effectively asking people not to allow anyone else access 
to baselined bug fixes. Since Gnat is part of the gcc baseline now, we 
don't really have that problem any more.

Re: Development process in the Ada community

[Ted Dennison]

tmoran@acm.org wrote:

>>The GPL is merely a software license that gives users of your software
>>more rights ...
>>
>   Different, not More.  A set of rights is not one-dimensional with an
> obvious ordering.


I'd say different, and almost always more. I've certianly never read a 
shrink-wrap software license that gives me as much freedom as the GPL. 
Usually they say you can't do anything, and then list a few exceptions 
(eg: install on one machine, make one backup copy, etc). The GPL bascily 
says I can do anything, then lists a few exceptions.

Re: Development process in the Ada community

[Richard Riehle]

tmoran@acm.org wrote:

>
>   Perhaps giving them software, then not helping when they get stuck,
> is more like finding a beggar, showing him the beer and chips in your
> car, driving him out to the beautiful countryside, set him down to
> munch the salty chips, then, when he asks for a beer, you announce the
> beer, and the ride back to town, are expensive.  I suppose there are
> those who would claim the moral high ground "but I fed the beggar".

Someone once described a difference between conservative and a
liberal this way.    The conservative throws a rope toward a drowning
man but makes him swim part of the way to reach it.   A liberal throws
the rope directly to him and lets go of the rope before he reaches shore.
What do you call someone who throws the rope, requires the drowning
person to swim for it, and then lets go of the rope too?

ACT, when working on behalf of its customers, throws them a rope and
requires them to do their part.    This seems an appropriate business
model.
Free GNAT is a rope that has no one holding it at the shoreline end,
and you still have to swim a little bit to use it properly.

Richard Riehle

Re: Development process in the Ada community

[Jason King]

Guys,
Get a grip.  You're complaining about the quality of support for a FREE 
product!  Support costs money to provide.  If you want support buy a 
product that costs money, don't sit around whining about how the free 
compiler you get doesn't come with vendor provided support.
Richard Riehle wrote:
> tmoran@acm.org wrote:
> 
> 
>>  Perhaps giving them software, then not helping when they get stuck,
>>is more like finding a beggar, showing him the beer and chips in your
>>car, 
> Free GNAT is a rope that has no one holding it at the shoreline end,
> and you still have to swim a little bit to use it properly.
> 

Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community?

[Robert Dewar]

Florian Weimer <fw@deneb.enyo.de> wrote in message news:<87bsce1bve.fsf@deneb.enyo.de>...
> dewar@gnat.com (Robert Dewar) writes:
> 
> According to Eric S. Raymond, "Open Source" does not 
> necessarily imply the Bazaar model, the Cathedral model 
> (which was once common to many GNU projects---Emacs, for 
> example, joined the Bazaar only rather
> recently) is still considered "Open Source".


Well I don't think Eric defines these terms for the industry :-)

When people worry about "open source" what they are usually worrying
about is an open and uncontrolled development process. Of course there
can be closed and uncontrolled
development and open and controlled development, but there
is a significant perception that open tends to go with
uncontrolled, and to some extent that's reasonable, if you
want a community to participate energetically then you 
can't tie their hands too tightly :-)

Re: Development process in the Ada community

[Robert Dewar]

tmoran@acm.org wrote in message news:<Itiw8.3027$Wl4.1626920993@newssvr14.news.prodigy.com>...
> and considering the "give
> it away for free, charge a bundle for support" model for 
> GPL product funding.  That model requires that you do 
> support only for cash

Well perhaps some software is sold on that model, I am not
sure what but that's certainly not the Ada Core Technologies model. We
provide licensed copyrighted software bundled with support (a not
unusual model).
Yes, there are some public versions of GNAT, but
they are, from the point of view of our customer base,
quite different.

(warning remember that I have a definite interest in the
success of ACT, so read the following with that in mind,
just as you need to remember that Tom Moran is involved
in commercial products that are to some extent competitive
with ACT, and which have a very different model).

If a customer gets GNAT Pro, they are getting a software
product that is fully backed by our company. They know that
it has been extensively tested, They know that it is properly licensed
(a real concern for many users, since
you never really know the license situation of stuff you
download from miscellaneous places). They know that ACT
will stand behind the product, and they know that ACT
support is unusual in that they have immediate access to
our entire engineering staff, for help not only with problems with
GNAT Pro, but general problems and questions in the use of Ada and
bring their projects to a successful
conclusion. 

Ada Core Technologies is definitely not in the business
of giving things away!

> ignoring any latent feelings of obligation to stand
> behind your programming.

We definitely stand behind GNAT Pro, and will make sure
that users of GNAT Pro are successful in their use of this
product.

From time to time we make public binaries available, and
we make the sources available at gnu.org, and we do this
because we think it is generally advantageous to the Ada
community, but this is done on the basis that there is
no support from us. If people find that worrisome, they
should stay away from unsupported software, but for students and
hobbyists and academic researchers, it is
often quite acceptable to use unsupported software, and
we hope that the public versions of GNAT will be helpful.

What some people seem to be saying is "Hey you shouldn't
make this stuff public, unless you are willing to stand
behind it and support it!" Well that's not the way the
world works. There is no free lunch here. If some philanthropist wants
to make a significant donation to
support the binary version, then that would change things.
So if we really thought people agreed with this quote, we
would have to react by simply not making it available (remember that
the GPL never forces ACT or anyone else
to distribute anything). That would be too bad, and in
fact we know perfectly well that the great majority of
users of the public version understand the situation
exactly. Indeed, the criticisms often come from competitors who
definitely do NOT make their software available, so you
have to wonder :-)

> > The GPL is merely a software license that gives users 
> > of your software
> > more rights ...
>   Different, not More.  A set of rights is not o
> one-dimensional with an
> obvious ordering.

I disagree in this case, my specific comparison was with
the Microsoft license, and it is clear that the GPL and GMGPL as used
by Ada Core Technologies gives you absolutely *ALL* the rights you get
from Microsoft, plus a whole lot more. Indeed I would be very
surprised to see any license
from any seller of proprietary software that was not
a subset of the rights you have with GNAT Pro.

Robert Dewar
Ada Core Technologies

Re: Development process in the Ada community

[Robert Dewar]

tmoran@acm.org wrote in message news:<Itiw8.3027$Wl4.1626920993@newssvr14.news.prodigy.com>

> Different, not More.  A set of rights is not 
> one-dimensional with an obvious ordering.

Tom, since you work with RR, which markets proprietary
products with a proprietary license, here is a specific
challenge. In what respect do the rights conveyed to a
user by RR exceed those conveyed by Ada Core Technologies?

It's certainly the case that some licenses DO convey more
rights, e.g. the BSD license. Microsoft certainly prefers the BSD
license to the GPL (though they of course would
use neither themselves) since they can take BSD stuff and
incorporate it into their proprietary products. We deliberately
prohibit Microsoft from doing this, just as
they prohibit us from using their software (indeed they
don't even give us the sources :-)

One thing I should make clear is that I am not saying I
disapprove of the license that RR uses (unlike Randy who
philosophically objects to our licensing). I think that companies may
use any license that makes sense to them,
that's the way copyright works. We prefer to use a rather
free license because, as I said before, this is better for
our customers, and we find it is smart from all points of view to give
our customers what they need!

Robert Dewar
Ada Core Technologies

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Ted Dennison wrote:

> Marin David Condic wrote:
>> I don't think you need to have the full-blown project setup done in 
>> order to
>> discuss an interface to Maps. What would you suggest as a means of 
>> getting
>> that ball rolling? Would you like someone to take the Lists spec and 
>> turn it
>> into a strawman for Maps? (I hear you're a little preoccupied at the
>> moment... :-)
> 
> 
> Yeah, that would be a good start. Right now in addtion to this I'm 


On second thought, we really ought to get some kind of consensus on 
requirements before rushing headlong into design. If nothing else, it 
will save a lot of arguments.

Requirements I think ought to be included (using the usual should/shall 
language):

Maps shall provide for key lookup in no worse than O(logn) average time 
and O(n) worst case (where n is the # of elements in the map).

Maps shall provide for creation of a sorted list or array, or traversal 
in sorted order, in no worse than O(n) time. (In other words, the map is 
kept sorted as elements are added).

Maps should provide an interface consistent with Lists, as far as is 
practicable.

Comments?

Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community?

[Robert Dewar]

"Kent Paul Dolan" <xanthian@well.com> wrote in message news:<fabfb33253b2dea9ae61e01e4a71de03.48257@mygate.mailgate.org>...

> Thanks extremely much for that economics lesson, Robert.  
> I was about to frame as a query a completely wrongheaded 
> guess at how open source folks get paid a living wage.

As I said earlier, the issue is not really open source per se but
rather the issue is whether companies can successfully use licenses
that convey considerable rights
to customers, including rights to free use, modification and
redistribution (collectively such licenses have been
referred to as Free Software licenses).

I have explained how this model works well for Ada Core Technologies
and its customers. I should mention one more
important aspect of this model (again remember I am wearing my ACT hat
:-)

The way our support works is that people purchase a copy of GNAT Pro
with support for a year. Then, at their option they can renew this
support, which includes getting all
the updated latest versions of GNAT Pro.

Will they renew their support? In practice almost all our
customers do renew. They certainly don't have to, they can
continue to use the version of the compiler they have (since the
license gives them this right, and there are certainly no time bombs
or anything else like that which
would prevent that). The answer is simple, they will renew
if they find

  a) that development of GNAT Pro is continuing and
     valuable new features are being added, so that it
     is worth getting the latest versions.

  b) that the support we provide is valuable

Now remember that ACT is a commercial company, we definitely want
customers to renew. That means we have
a very significant financial incentive to deliver on
both points a) and b) above. This keeps us running fast.
Unlike a proprietary software company that can use restrictive
licenses to keep its customer base captive,
we can't just stop development, degrade support, and sit
back and milk the customer base, since that would be financially
disadvantageous to us (and at the risk of
sounding like General Motors, we think that the continued
health of ACT is an important element in the continued
success and usage of Ada, which we definitely want to
encourage!)

Now of course I am not saying that all proprietary companies provide
poor support, or fail to keep up
a strong development program, but I like the fact that
in our model, our interests are aligned with those of
our customers both philosphically and commercially.

Now, an interesting question, could you use this model for
all software, or at least let's say other software?

Well I can't answer that, but I do remember my brother
saying when he was running DISC (Dewar Information Systems
Corporation) and had over a hundred people working for him,
that he found it annoying that he could only pay Microsoft
$300 for a C compiler. He said "I would far rather pay 10 or 20 times
that, and get a corresponding better product
with better support, since I am betting my company on the
integrity of this product". 

Hobbyists and students often evaluate software purely on
the basis of whether it does what they personally need. 
They would not appear to be customers for the kind of
full-service support that is part of this model. On the
other hand, not much of the software industry depends on
the money spent by students and hobbyists on software, and
it seems quite reasonable to let them get hold of the software they
need with no support and no fees (in practice
such communities tend to regard it as legitimate to trade
software regardless of licensing conditions). I like the
model of unsupported public versions for meeting this need
because I think it realistically addresses this segment.

But when it comes to industrial use, I don't think most
companies want to rely on downloaded software with no
support. 

Suppose I came up with a really good piece of presentation
software that competed effectively with Power Point? Could
I sell this with a non-restrictive license. I think the
answer is that it depends on the price. Power Point itself
is remarkably expensive, and Microsoft's total income from
this product exceeds the cost of producing it by some
enormous factor. I concede that if you think this kind of
discrepancy is reasonable, then it's hard to sustain without
restrictive licensing, but I think if you sold such a product for a
reasonable price, you could definitely succeed. I know that for my own
usage, I have no problem in
paying reasonable prices for software that I need to rely on. What's
the definition of reasonable? For me it is that the company is making
a reasonable profit but not an excessive one. I think software
producers should be able to make a good living, but I don't see that
they have to get super rich. Obviously if I get more extensive support
I expect to pay more so I need to select a product whose level of
support meets my needs.

Ada Core Technologies has a quite clear philosophy of providing very
extensive high level support. That's not
cheap, but that's the market segment we have chosen to
address, because typically Ada is used in large scale
critical systems where this level of support is needed.

Robert Dewar
Ada Core Technologies

Re: Development process in the Ada community

[tmoran]

> > > The GPL is merely a software license that gives users
> > > of your software more rights ...
> >   Different, not More.  A set of rights is not
> > one-dimensional with an obvious ordering.
>
> I disagree in this case, my specific comparison was with
> the Microsoft license,
  Well why didn't you say so.

> and it is clear that the GPL and GMGPL as used
  The GMGPL is quite different from the GPL.  The GPL significantly
restricts what I can do with GPLed software, in a way that other licenses
commonly don't.  It's misleading nonsense to say flatly "McDonald's is
less restrictive than Hamburger Hamlet because it lets me order an Egg
McMuffin".

Re: Development process in the Ada community

[David Botton]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ud6wydz64.fsf@gsfc.nasa.gov...

> Windex "competes" directly with Claw and GWindows. I wrote it because
> Claw was not open source, and GWindows was not available. I'm not
> clear why David Botton wrote GWindows instead of extending Windex.
> They do have different designs under the hood.

GWindows has a number of fundamental differences in design (the most
important to me is multiple event models) and implementation style (the
complete lack of thin bindings as a starting point, ie. I prototype the
needed Win32 functions with in each call in order to maximize the use of the
Ada95 to C mappings).

I've always wondered why you didn't take the time to update GWindows with
some of the thicker parts of Windex ;-)

There are only three thick bindings to Win32 (JEWL is a great teaching tool,
but not practical nor intended to be used for professional development),
GWindows, Windex and CLAW.

A comparison (not updated recently) between GWindows and CLAW is available
at http://www.adapower.com/gwindows/GWindowsVsClaw.html


I should have an update to GWindows available soon and am back working on
the GTK+ bindings and filling in the last gaps for GWindows 1.0 release....
(Sadly, I was sucked out of the Ada world for the last number of months.
Although, I did develop an e-learning product using GWindows in Ada during
that time.)

David Botton

Re: Development process in the Ada community

[David Botton]

----- Original Message -----
From: "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>


> Lets see.. that's (onetwothreefour...) *six* different bindings to
Windows -
> each with different features/capabilities, but probably a good deal of
> overlap. (Will we hear of more? Consider that a "binding to Windows"
> could/should include things like sockets and similar stuff

I disagree, if there are good Ada solutions already why bother. (In the case
of sockets you have AdaSockets or GNAT.Sockets). Thus GWindows does not
include support for Sockets or other aspects of Win32 already supported
directly by Ada95 or GNAT.

> Probably, you really need to have Win32Ada (or similar) no matter what.
This
> thin binding is needed just to keep up with whatever Microsoft comes out
> with next as the OS API, so that if it didn't get included in the more
> abstract API, the programmer still has access to it. (It was originally
> auto-generated, right? So if a new C interface comes out, it can easily be
> re-auto-generated? Sounds important to me...)


Microsoft makes most updates to its platforms these days using COM APIs, so
Win32Ada for those that insist on thin bindings is available and most
everything else GNATCOM takes care of.

David Botton

Re: Development process in the Ada community

[David Botton]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ur8lcvml9.fsf@gsfc.nasa.gov...

> Hmm. GWindows makes a start towards a "subscriber" model of event
> handling (but only a start). That is significantly different from
> Windex and CLAW, which use an "override" model. I don't think one
> windowing system can have both. Hmm; maybe it could; call the
> subscribers, then dispatch.

GWindows in fact offers both and it works out very nicely. GWindows strikes
a good balance in its "subscriber" model of events by just basicly offering
a simple call back registration mechanism removing most of the complexities
of programming in that model. For more complex work the override model can
be used to easily offer more.

> I see no reason not to just use GtkAda.

GtkAda is a nice solution for many problems, but if you are looking to be
native to Win32, it doesn't cut the mustard.

David Botton

Re: Grace and Maps (was Re: Development process in the Ada community)

[Simon Wright]

Ted Dennison <dennison@telepath.com> writes:

> Another possiblity would be to keep the name simple (Grace.Lists),
> and give the bounded version its own name when/if the time
> comes. Something like "Circular_Lists" (or Booch's "Ring") might be
> a possibility. This concept extends to Maps too, as we could call
> them "Maps" and "Hashes" rather than "Maps.Unbounded" and
> "Maps.Bounded". Not only is this a simpler structure, we no longer
> have the name talking about internal features of the structure
> instead of external features. That could be good enough for
> real-time and embedded folks if we document its use (or lack of use)
> of heap properly.

That seems plain peculiar to me. The BC "Collection" and "Ring" have
quite different semantics because they support different
concepts. Collection.Bounded and Collection.Unbounded are different
because they have different runtime behaviour, but they both have the
same interface! In this respect they map onto Ada.Strings, I think.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Simon Wright]

Ted Dennison <dennison@telepath.com> writes:

> Maps shall provide for key lookup in no worse than O(logn) average
> time and O(n) worst case (where n is the # of elements in the map).
> 
> Maps shall provide for creation of a sorted list or array, or
> traversal in sorted order, in no worse than O(n) time. (In other
> words, the map is kept sorted as elements are added).

I was quite surprised by the idea that a map had to (be|behave as
though it was) implemented using a sorted vector of keys ..

Re: Development process in the Ada community

[David Botton]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:ubrtrt3lg3os74@corp.supernews.com...
> So it never made economic sense, I fear.

And thus the "old" non open source model killed off the possibility that
CLAW would be the basis of a standard or be extended by the wider community
of programmers..... or outlive its own developers....

Imagine if my development efforts would have been used to modify and extend
CLAW instead of writing GWindows......

GWindows covers almost all areas of CLAW (some intentionally not covered)
and is way beyond it in other areas (database to control bindings, ActiveX,
etc.), CLAW would have been by now double its feature set and more and I
likely would have already completed many of my long term goals. (For
example, I only need about 6-8 months of full time work to complete, at
least in 1.0 terms, my Delphi like environment for Ada.... Some day.... some
how... eventually....)

Economic sense can be made of this, but not in the traditional ways of
thinking.....

David Botton

Re: Development process in the Ada community

[tmoran]

> Imagine if my development efforts would have been used to modify and extend
> CLAW instead of writing GWindows......
  I have, and I think it a great loss to the Ada community that you didn't.

>GWindows covers almost all areas of CLAW (some intentionally not covered)
>and is way beyond it in other areas (database to control bindings, ActiveX,
  David, it's good to see someone take pride in their product, but IMHO
you exaggerate more than a bit.

>CLAW would be the basis of a standard or be extended by the wider community
>of programmers..... or outlive its own developers....
  Is GWindows then the basis of some standard?  Has it been extended by
the wider community?  Is it under as active development as Claw?  As to
outliving its developers, we'll have to leave that to others to see. ;)
Tom Moran

Re: Grace and Maps (was Re: Development process in the Ada community)

[Hyman Rosen]

Simon Wright wrote:
> I was quite surprised by the idea that a map had to (be|behave as
> though it was) implemented using a sorted vector of keys ..

C++ maps are pretty much universally implemented using
red-black trees. I was quite surprised by the idea that
keeping a map sorted requires a vector :-)

Re: Development process in the Ada community

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> It's certainly the case that some licenses DO convey more
> rights, e.g. the BSD license. Microsoft certainly prefers the BSD
> license to the GPL (though they of course would
> use neither themselves)

Of course they use the GPL only if they have to (e.g. for parts of
Interix), but they pay at least one person for working on free
software which is licensed under the BSD license (and no, it doesn't
run only on Windows)...

Re: Development process in the Ada community

[Adrian Hoe]

"David Botton" <David@Botton.com> wrote in message news:<uc4l4v8tett728@corp.supernews.com>...
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:ubrtrt3lg3os74@corp.supernews.com...
> > So it never made economic sense, I fear.
> 
> And thus the "old" non open source model killed off the possibility that
> CLAW would be the basis of a standard or be extended by the wider community
> of programmers..... or outlive its own developers....
> 
> Imagine if my development efforts would have been used to modify and extend
> CLAW instead of writing GWindows......
> 
> GWindows covers almost all areas of CLAW (some intentionally not covered)
> and is way beyond it in other areas (database to control bindings, ActiveX,
> etc.), CLAW would have been by now double its feature set and more and I
> likely would have already completed many of my long term goals. (For
> example, I only need about 6-8 months of full time work to complete, at
> least in 1.0 terms, my Delphi like environment for Ada.... Some day.... some
> how... eventually....)


Yep, I am eager to see the tool arrives.. some day.. :) But then,
there will be less fun writing Ada codes. All this interesting process
will be subsituted by click, click, click and just click (like in
Delphi right now). :(

                                       -- Adrian Hoe
                                       -- http://adrianhoe.com

Re: Open Source: in conflict with the development process in the Ada community?

[Ingo Marks]

Florian Weimer wrote:

> "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:
> 
>> Under what law (in either Germany or the U.S.) would forbid a company
>> from giving away a compiler?
> 
> Regulations against unfair competition.  Hmm, I couldn't find a
> reference to specific German law, but I remember a few cases in which
> companies were forced to stop giving services away for free.  However,
> I'm no longer sure if general provisions against unfair competition
> were applied, or some special case law (telco regulations, for
> example).

As far I remember a telco (Deutsche Telekom?) was forced to stop a free 
service that customers usually had to pay for. But they gave this free 
service away just to decoy oodles of new customers who normally had went to 
several other telcos. This was a serious unfair competition with a clear
monopolistic tendency.

But as long you don't gain a monopoly then of course you can give products 
and services away for free in Germany. Even Microsoft does it :-) You can 
buy cheap computer magazines with free Microsoft Visual C++ compilers on CD.

Regards,
Ingo

Re: Rant! (was) Development process in the Ada community

[Michal Nowak]

On 2002-04-16 at 10:30 Frank wrote:

>Hi!
>
>I have seen that Oracle's PLSQL is inspired by the Ada standard. I wonder
if
>there are
>some historical material related to PLSQL vs Ada (?), but I don't know the
>history (born too late :-).
>To me it looks like Ada had a golden oportunitue to "ride on the back of a
>tiger" when the PLSQL
>were initiated. Were there some discussion related to this "once upon a
>time"?-) Oracle probably choose their own way due to market analyzis.

That's nice that PLSQL was inspired by Ada, although no many people know
it.
Oracle had some tool for Ada, but now it is gone. There was Pro*Ada
Precompiler,
but it was in versions 7.*. I had no possibility to use (or try it),
because
I started with Oracle from 8.*. I seen somewhere on their web pages, that
Pro*Ada
will be no longer included (but there is ProC/C++, ProFortran and
ProCOBOL). 
However, there is still SQL Module for Ada, but I don't know for how long
it
will exist. Documentation file for this product is dated for December 1997,
while for other products - no earlier than 1999. A bit sad perspective...

Mike

Re: Development process in the Ada community

[Robert Dewar]

tmoran@acm.org wrote in message news:<r1sw8.3545$Dh5.1795316993@newssvr14.news.prodigy.com>> The GMGPL is quite different from the GPL.  The GPL 
> significantly restricts what I can do with GPLed 
> software, in a way that other licenses
> commonly don't.

You are setting up a strawman here. For tools, like Powerpoint say, it
is absolutely clear that similar tools
that are GPL'ed give you uniformly MORE rights than Microsoft (or any
other similar company would give you).

For libraries, it is standard (and recommended practice)
to use a license like the GMGPL, and when this is done
the same comment applies.

So the practical situation in the world is that Free Software
virtually always comes with uniformly more
rights.

Tom, you certainly have a motive to argue against the
use of the GPL, GMGPL etc, since you work for a company
represented by someone who has "philosophical objections"
to the GPL, and you have chosen to work on software that
most definitely is not free software. I understand this,
and as I have said before I strongly support people's right
to use any license they please. But if you argue that your
licensing policy is in any sense superior from a users
point of view, let's have the argument on the basis of the real and
not the imaginary :-)

Please compare CLAW with any commercial free software library, and
describe the manner in which CLAW provides more rights. That seems a
fair challenge to me, I am allowing you to pick absolutely any
commercial free software, it does not have to be GNAT (I perfectly
well understand that you might be able to find some non-commercial
software that was rerstricted, but that's really comparing apples and
oranges to me).









  It's misleading nonsense to say flatly "McDonald's is
> less restrictive than Hamburger Hamlet because it lets me order an Egg
> McMuffin".

Re: Development process in the Ada community

[tmoran]

> Tom, you certainly have a motive to argue against the
Where I come from that's called "resorting to ad hominem argument"
and it's recognized that it has nothing to do with the merits of a case.

> significantly restricts what I can do with GPLed
> software, in a way that other licenses
The original statement was:
>  The GMGPL is quite different from the GPL.  The GPL significantly
>restricts what I can do with GPLed software, in a way that other licenses
  So your defense of the GPL on the basis of the lessened restrictions in
the GMPL amounts to quoting out of context.  That may be OK in propaganda,
but it's recognized as inimical to exploring the merits of a case.

I'm not interested in a propaganda battle.  If you are not interested
in a clear exploration of the merits of the case, then we have nothing
to discuss.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Simon Wright wrote:

> Ted Dennison <dennison@telepath.com> writes:
> 
> 
>>Another possiblity would be to keep the name simple (Grace.Lists),
>>and give the bounded version its own name when/if the time
>>comes. Something like "Circular_Lists" (or Booch's "Ring") might be

 >

> That seems plain peculiar to me. The BC "Collection" and "Ring" have
> quite different semantics because they support different
> concepts. Collection.Bounded and Collection.Unbounded are different
> because they have different runtime behaviour, but they both have the
> same interface! In this respect they map onto Ada.Strings, I think.


My thought was that it would be sensible to give the "bounded" structure 
an interface (and name) commensurate with its unique capabilities and 
weak spots, rather than just try to provide identical interfaces with 
the "unbounded" one. Sort of a "function follows form" concept.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Hyman Rosen wrote:

> Simon Wright wrote:
> 
>> I was quite surprised by the idea that a map had to (be|behave as
>> though it was) implemented using a sorted vector of keys ..
> 
> 
> C++ maps are pretty much universally implemented using
> red-black trees. I was quite surprised by the idea that

I've never implemented a general Map myself, or looked at one. I was 
picturing something along the lines of a binary tree, perhaps balanced 
if you want to get sexy. So that makes sense.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Simon Wright wrote:


> I was quite surprised by the idea that a map had to (be|behave as
> though it was) implemented using a sorted vector of keys ..

Thanks. This is a perfect example of why we need to get consensus on 
requirements before implementing anything. :-)

Re: Development process in the Ada community

[David Botton]

<tmoran@acm.org> wrote in message
news:QEtw8.3627$eg5.1828187369@newssvr14.news.prodigy.com...
> > Imagine if my development efforts would have been used to modify and
extend
> > CLAW instead of writing GWindows......
>   I have, and I think it a great loss to the Ada community that you
didn't.

Your lic. wasn't condusive to it..... I agree, sad.

> >GWindows covers almost all areas of CLAW (some intentionally not covered)
> >and is way beyond it in other areas (database to control bindings,
ActiveX,
>   David, it's good to see someone take pride in their product, but IMHO
> you exaggerate more than a bit.

But less than a byte.... Note that I am not knocking your framework, I think
it is a masterful work and only regret that it was not available under
different lic. terms.

These em' not fightin' words.... It just happens to be that I support
certain areas CLAW doesn't and a few other areas I do support CLAW is a bit
more thorough. If you had a better lic. you would of course be able to grab
some code for GWindows and GNATCOM...... but oh well.

>   Is GWindows then the basis of some standard?

In the same way the Java AWT and SWING is the basis of a standard ;-O

>  Has it been extended by
> the wider community?

Yes, there have been a number of additions (including entire features not
just bug fixes!). The greatest complement in the world is that some one has
extended your work and sent it back in for others to use. Their efforts are
more knoble than mine!

> Is it under as active development as Claw?

Yes. I saddly have to take breaks here and there for extend amounts of time
do to work load from the "other side", but my track record shows that I get
more than a bit done in the days and months I manage to grab here and there
(though they may be far apart....) :-)

I am often envious that you have the opportunity to work full time in Ada
and on your Ada based projects (in part perhaps do to your restrictive
lic.), but in the long term I believe that my approach will pay off in a
larger way (part of which concerns money, but certainly satisfaction comes
not only in the financial arena).

I am certainly already more satisified on a personal level than with any of
what I have produced under traditional terms and licences (Although I do get
a kick out of detecting a company is using software I wrote for their phone
systems from my last gig).

>  As to
> outliving its developers, we'll have to leave that to others to see. ;)

Perhaps, but hopefully we will both be around for another 180 years to see
others enjoy our work. Perhaps by then CLAW will well then be lic. with the
GMGPL unless of course Ada takes over than GPL.....

David Botton

Re: Development process in the Ada community

[David Botton]

The idea is that the tools free the developer up for more interesting and
fun coding...

David Botton


"Adrian Hoe" <byhoe@greenlime.com> wrote in message
news:9ff447f2.0204210302.5f706b6a@posting.google.com...
> Yep, I am eager to see the tool arrives.. some day.. :) But then,
> there will be less fun writing Ada codes. All this interesting process
> will be subsituted by click, click, click and just click (like in
> Delphi right now). :(

Re: Open Source: in conflict with the development process in the Ada community?

[Darren New]

Ingo Marks wrote:
> As far I remember a telco (Deutsche Telekom?) was forced to stop a free
> service that customers usually had to pay for.

This has happened in the US too, on the grounds that the customers
paying for the service were the ones who weren't receiving it. Even the
phones inside the offices of the telcos here have to be paid for by the
telcos. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Development process in the Ada community

[Larry Kilgallen]

In article <3CC1DEF2.4060204@telepath.com>, Ted Dennison <dennison@telepath.com> writes:
> tmoran@acm.org wrote:
> 
>>>The GPL is merely a software license that gives users of your software
>>>more rights ...
>>>
>>   Different, not More.  A set of rights is not one-dimensional with an
>> obvious ordering.
> 
> 
> I'd say different, and almost always more. I've certianly never read a 
> shrink-wrap software license that gives me as much freedom as the GPL. 
> Usually they say you can't do anything, and then list a few exceptions 
> (eg: install on one machine, make one backup copy, etc). The GPL bascily 
> says I can do anything, then lists a few exceptions.

That is in the end-user dimension.

The licensing for many commercial libraries included into other products
allows modifications to those libraries without distributing those changes.
Those libraries allow "more" in the software vendor dimension.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Larry Kilgallen]

In article <3CC21747.5000501@telepath.com>, Ted Dennison <dennison@telepath.com> writes:

> On second thought, we really ought to get some kind of consensus on 
> requirements before rushing headlong into design. If nothing else, it 
> will save a lot of arguments.
> 
> Requirements I think ought to be included (using the usual should/shall 
> language):
> 
> Maps shall provide for key lookup in no worse than O(logn) average time 
> and O(n) worst case (where n is the # of elements in the map).
> 
> Maps shall provide for creation of a sorted list or array, or traversal 
> in sorted order, in no worse than O(n) time. (In other words, the map is 
> kept sorted as elements are added).
> 
> Maps should provide an interface consistent with Lists, as far as is 
> practicable.
> 
> Comments?

While the interface should not _prevent_ implementations from
achieving certain performance goals, I don't think performance
goals should be part of the requirements.  If a vendor wants to
provide a relatively slow implementation, that is their choice,
just like their choice regarding how fast A := B'length should
perform.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Robert Dewar]

David Bolen <db3l@fitlinxx.com> wrote in message news:<ur8lbkxo1.fsf@ctwd0143.fitlinxx.com>...

> And from another language perspective, in Python, the fundamental
> built-in data structure types (aside from numerics) are sequences
> (lists/tuples) and mappings (dictionaries) and certainly in my
> experience they cover the vast majority of practical situations quite
> capably.

Yes, and of course this is an old old idea, copied into Python from the
heritage of ABC, SETL and other precursors. Mappings are of course 
powerful enough to represent anything (and sequences are just special
cases of mappings). That's been known since long before computers existed!

But whether general mappings have a legitimate place in a low level
language (by SETL standards :-) like Ada is open for debate. And in
particular, having them as second class citizens without decent syntax
seems quite dubious.

So you might want to throw into the pot user defined subscripting
and slicing operations :-)

My own view is that it is unlikely that any of this will get anywhere
near smooth enough and with enough consensus to be standardized. I think
people would better spend their effort implementing sample packages than
discussing at random on CLA :-)

Re: Grace and Maps (was Re: Development process in the Ada community)

[Simon Wright]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> While the interface should not _prevent_ implementations from
> achieving certain performance goals, I don't think performance goals
> should be part of the requirements.  If a vendor wants to provide a
> relatively slow implementation, that is their choice, just like
> their choice regarding how fast A := B'length should perform.

As a user as well as a provider, it seems to me that I need both
bounded and unbounded memory behaviour in the same program (for
different instances, of course!); and I'd like to be able to change
without huge costs.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:3CC1C7C6.5030404@telepath.com...
> Michael Erdmann wrote:
>
> > Without trying it, we will never fail, which means we will continue
>
>
> That ought to be my battle cry! :-)
>
> Tick: "Spoon!"
> Authur: "Not in the face! Not in the face!"
> T.E.D.: "Without trying, we will never fail!"
> (melee ensues)
>

    "If we don't succeed, we run the risk of failure."
        --  Al Gore

(Don't know if its an accurate quote, but it applies even if it isn't. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<V+UgdHreGTJg@eisner.encompasserve.org>...
> In article <3CC21747.5000501@telepath.com>, Ted Dennison <dennison@telepath.com> writes:
> 
> > On second thought, we really ought to get some kind of consensus on 
> > requirements before rushing headlong into design. If nothing else, it 
> > will save a lot of arguments.
> > 
> > Requirements I think ought to be included (using the usual should/shall 
> > language):
> > 
> > Maps shall provide for key lookup in no worse than O(logn) average time 
> > and O(n) worst case (where n is the # of elements in the map).
> > 
> > Maps shall provide for creation of a sorted list or array, or traversal 
> > in sorted order, in no worse than O(n) time. (In other words, the map is 
> > kept sorted as elements are added).
> > 
> > Maps should provide an interface consistent with Lists, as far as is 
> > practicable.
> > 
> > Comments?
> 
> While the interface should not _prevent_ implementations from
> achieving certain performance goals, I don't think performance
> goals should be part of the requirements.  If a vendor wants to
> provide a relatively slow implementation, that is their choice,
> just like their choice regarding how fast A := B'length should
> perform.

I can see your point. For real-time use its vital to know this. I'd
prefer to see it in the requrements that Maps are usable in real-time
once the map is already built, which is what these requirements are
getting at.

Perhaps I am committing the cardinal sin of trying to design with
requirements though.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Simon Wright <simon@pushface.org> wrote in message news:<x7vr8l871it.fsf@smaug.pushface.org>...
> As a user as well as a provider, it seems to me that I need both
> bounded and unbounded memory behaviour in the same program (for
> different instances, of course!); and I'd like to be able to change
> without huge costs.

Hmmm. This seems to be going back to the "naming" issue: Do we want
*.Maps.Bounded or *.Hashes?


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<+JjhQCmJYCyP@eisner.encompasserve.org>...

> That is in the end-user dimension.
> 
> The licensing for many commercial libraries included into other products
> allows modifications to those libraries without distributing those changes.
> Those libraries allow "more" in the software vendor dimension.

Just like the GNAT run-time library for example ...

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3CC1BD77.EFDD044C@acm.org...
>
> No, it wouldn't be fair, at least not from my perspective. But it would
> be a good start, so I have no objection to it.
>
Note that the question is more one about generality. I certainly accept that
there *are* people who use Ada in realtime apps where performance &
determinism & possibly task safety would be a critical concern. Just more of
an issue of "who is in the majority" so we can do the Greatest Good For The
Greatest Number. (Also, I don't think that the Grace list package as it
stands at the moment wouldn't be useful in realtime - just that it might not
be applicable without careful analysis & for a number of cases, fixed or
bounded versions might be better. They can always be added if there seems to
be a crying need.)


>
> While I agree with this, if Grace becomes accepted, and we submit it to
> the ARG as has been requested on the Ada-Comment mailing list, then it
> would become part of the Ada.* hierarchy, so I suggest that consistency
> with those naming conventions would be a Good Thing.
>
I'd actually be opposed to getting it into the Ada.* tree. A couple of
reasons: First, this is going to exist as a stand alone tree initially
because you can't add it to the Ada.* tree without being the compiler. Once
it starts showing up in people's code as "Grace.Lists..." nobody is going to
want to go change their existing code to make it all "Ada.Grace.Lists...."
My experience with software is that early decisions about structure are
something you have to live with for a very long time, so you'd better
consider them carefully.

My second reason is that if this collection of stuff should ever get put
under the Ada.* tree, you would instantly make it very difficult to extend
and enhance with future ideas. You'd be up against the inability to modify
anything in the Ada.* tree without being the compiler, plus you'd be up
against all sorts of political forces lobbying for stability and fighting
against an ISO bureaucracy, etc. etc. etc. Far better it should stand on its
own so that it can be treated as a "Convention" rather than a "Standard" and
remain far more flexible & extensible. A library such as this needs to be
enhanced with a fairly rapid product cycle or we would be lagging behind
other languages instead of taking the lead.

That's my take on it anyway. It would be good to know what the rest of the
interested parties think on it - should Grace aim for inclusion in the Ada.*
tree and become part of the ARM? (Can it be part of the ARM and remain
flexible with a fast update cycle?) Or should it aim to be a sideline
convention?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Open Source: in conflict with the development process in the Ada community?

[Robert Dewar]

Ingo Marks <adv@region-nord.de> wrote in message news:<a9u6sm$24c$01$1@news.t-online.com>...
> Florian Weimer wrote:
> 
> > "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:
> > 
> >> Under what law (in either Germany or the U.S.) would forbid a company
> >> from giving away a compiler?
> > 
> > Regulations against unfair competition.

Please go look up the notion of unfair competition. It is far far more
restrictive than you think. Don't guess about the law!

> But as long you don't gain a monopoly then of course you can give products 
> and services away for free in Germany. Even Microsoft does it :-) You can 
> buy cheap computer magazines with free Microsoft Visual C++ compilers on CD.

Indeed!

Re: Open Source: in conflict with the development process in the Ada community?

[Robert Dewar]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9pf6e$bo8$1@nh.pace.co.uk>...

> Hence I wouldn't begrudge any businessman saying "I won't put my software
> out on the net under GPL (or similar) because I don't think I can make a
> profit doing so."

Putting your software out on the net is an orthogonal decision on what
license to use. The GPL does not require you to make your software
available
on the net, and you can put your software on the net without giving
permission to redistribute.

> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> 
> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0204190620.1902ede@posting.google.com...

Marin, please don't quote entire articles, quote selectively, thanks!
It is annoying to have to delete these junk second level quotes. We
all have thread following news readers at this stage.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

dennison@telepath.com (Ted Dennison) writes:

> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<V+UgdHreGTJg@eisner.encompasserve.org>...
> > In article <3CC21747.5000501@telepath.com>, Ted Dennison <dennison@telepath.com> writes:
> > 
> > > On second thought, we really ought to get some kind of consensus on 
> > > requirements before rushing headlong into design. If nothing else, it 
> > > will save a lot of arguments.
> > > 
> > > Requirements I think ought to be included (using the usual should/shall 
> > > language):
> > > 
> > > Maps shall provide for key lookup in no worse than O(logn) average time 
> > > and O(n) worst case (where n is the # of elements in the map).
> > > 
> > > Maps shall provide for creation of a sorted list or array, or traversal 
> > > in sorted order, in no worse than O(n) time. (In other words, the map is 
> > > kept sorted as elements are added).
> > > 
> > > Maps should provide an interface consistent with Lists, as far as is 
> > > practicable.
> > > 
> > > Comments?
> > 
> > While the interface should not _prevent_ implementations from
> > achieving certain performance goals, I don't think performance
> > goals should be part of the requirements.  If a vendor wants to
> > provide a relatively slow implementation, that is their choice,
> > just like their choice regarding how fast A := B'length should
> > perform.
> 
> I can see your point. For real-time use its vital to know this. I'd
> prefer to see it in the requrements that Maps are usable in real-time
> once the map is already built, which is what these requirements are
> getting at.
> 
> Perhaps I am committing the cardinal sin of trying to design with
> requirements though.
> 
> 
> -- 
> T.E.D.
> Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
> Homepage -  http://www.telepath.com/dennison/Ted/TED.html

I think that it should be part of the specification. Otherwise, you
will be tempted to roll your own because you do not trust the
implementation. Essentially, it's a guarantee of 'quality of service'.

If you are not interested in performance, you could very well get by
with just a list implementation and limit your library to that :-)

 

Re: Development process in the Ada community

[Ted Dennison]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<+JjhQCmJYCyP@eisner.encompasserve.org>...
> In article <3CC1DEF2.4060204@telepath.com>, Ted Dennison <dennison@telepath.com> writes:
> > tmoran@acm.org wrote:
> > 
> >>>The GPL is merely a software license that gives users of your software
> >>>more rights ...
> >>>
> >>   Different, not More.  A set of rights is not one-dimensional with an
> >> obvious ordering.
> > 
> > 
> > I'd say different, and almost always more. I've certianly never read a 
> > shrink-wrap software license that gives me as much freedom as the GPL. 
> > Usually they say you can't do anything, and then list a few exceptions 
> > (eg: install on one machine, make one backup copy, etc). The GPL bascily 
> > says I can do anything, then lists a few exceptions.
> 
> That is in the end-user dimension.
> 
> The licensing for many commercial libraries included into other products
> allows modifications to those libraries without distributing those changes.
> Those libraries allow "more" in the software vendor dimension.

Errr...The GPL *also* allows modifications to GPL-ed software without
distributing those changes. It also allows modifications *with*
distributing the changes, under some circumstances. I have yet to see
how anyone has less freedom this way.

As fate would have it, today Eben Moglen, the lawyer for the FSF, has
put an article up at
http://moglen.law.columbia.edu/publications/lu-12.html that touches on
this very subject. (Those of you who don't like reading "GPL
propaganda" would do well to skip the first two paragraphs). His basic
thesis is that defending the GPL is a breeze compared to other
licenses, becuase other licenses generally try to make you trade some
of your legal rights away, while the GPL just *gives* you rights that
you would not otherwise have.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:3CC1C6B3.6060306@telepath.com...
>
> I honestly have no clue. The vast majority of my Ada use has been
> real-time or embedded (where dynamic allocation is often unavailable),
> and I do notice that there seem to be a large number of Ada compilers
> for such platforms. But I also realise that's just the view from my
> window, not a scientific representative sample.
>
To be fair, I have to admit similar ignorance. All I can go on is a general
perception that most programs written are not realtime/embedded so
extrapolate from there and presume that most Ada programs are not
realtime/embedded. You've got to ask "who's the audience?" and starting from
an unproven assumption and using a weak extrapolation, I'm willing to leap
to the forgone conclusion that we ought to target PC/Workstation
non-realtime apps as the first concern. Extensions can always follow.



>
> Another possiblity would be to keep the name simple (Grace.Lists), and
> give the bounded version its own name when/if the time comes. Something
> like "Circular_Lists" (or Booch's "Ring") might be a possibility. This
> concept extends to Maps too, as we could call them "Maps" and "Hashes"
> rather than "Maps.Unbounded" and "Maps.Bounded". Not only is this a
> simpler structure, we no longer have the name talking about internal
> features of the structure instead of external features. That could be
> good enough for real-time and embedded folks if we document its use (or
> lack of use) of heap properly.
>
No reason I can think of not to use new names if we change the underlying
implementation to create a new kind of structure. I could see doing
something like "Grace.Lists" and "Grace.Static_Lists" or any variant that
some dedicated word-scientist would care to come up with. Avoiding saying
anything about the underlying implementation is desirable, but I wouldn't
insist if the alternative is to go through linguistic gyrations to get
there.

OTOH, this is all kind of "new" and someone has to invent names for new
things. So why couldn't we just rectally extract names for new components
that don't necesarily have anything to do with anything?

Grace.Lists - a dynamically linked list.
Grace.Gazorenthorpes - a statically allocated list with a maximum upper
bound.
Grace.Blivets - Like a Gazorenthorpe only with task safety built in.
Grace.Doohickies - Like a map, but static.

We can probably do this all day long - maybe even get a CS book written
about it and be immortalized in the annals of Geekdom forever. :-)


> But the argument for consistency with Ada.Strings.* is fairly compelling
> too.
>
I feel your compellation! :-) I'd like to be consistent with what has gone
before as well. But maybe its time to break with the past? Didn't Mark Twain
say "A foolish consistency is the product of little minds..." ?

This is a tough call, but I think I'd prefer to go with coming up with a
separate name for a list or map that had a significantly different behavior.


>
>
> I'm curious if other people feel this way. I'd lean towards
> "Grace.Lists", as the standard Ada library is equally flat, our list of
> components may not end up being large, and there isn't liable to be much
> common code sitting in the "Components" spec. But I'm not married to the
> idea. We certianly need to name for proper growth, as renaming files in
> CVS is kind of a kludge.
>
Well, maybe there is no reason we can't mix-n-match. If we don't see some
general category of "Containers" being likely - just Lists & Maps (and
variant implementations thereof) then maybe it doesn't need another layer. I
could envision at a later point doing something like "Grace.XML",
"Grace.XML.DOM", "Grace.XML.SAX" and so on if we did want to add something
that had logical sub-domains and/or deeper hierarchy.

My brain seems to like having a phylogenetic tree around for some reason.
Something like: <Library>.<Problem Domain>.<Specific Tool> would seem to be
sufficient to keep my brain happily amused and tranquil in the beautiful
serenity that can only come from a sublime sense of order. How does the rest
of the world feel?

Of course, if we got rid of the "Grace" part and just went with a bunch of
separate libraries under the <Problem Domain>.<Specific Tool> kind of thing,
we'd have categorization without so deep a tree. But then we lose any sense
of a unified library. No really perfect answers out there, are there?


>
> Yeah, that would be a good start. Right now in addtion to this I'm
> trying to figure out if I need to buy 3 smaller child car seats or a
> larger car. :-(
>

I hear minivans are nice. (Wasn't there a parody of the "Spiderman" theme
song called "Married Man" that alluded to minivans? Here we go:
http://www.thebigshow.com/BITPAGES/MARRDMAN.HTM) I should watch it - my
lovely bride could easily take umbrage and seek revenge by coming home with
a fake-wood pannel station wagon. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

Can the requirements be kept lean enough to be put in the banner of the
code? For a widely circulated project, it would be nice to be sure all the
important things go along with the code. A separate document could be
problematic.

I have no objections to doing some requirements first. I think in the case
of our relatively small container stuff, there probably are not a really
long list of them - but there could be for some other libraries.

My suggestions:

1) Maps shall be Stuff That's Cool.
2) Maps shall not be Stuff That Sucks.

:-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:3CC21747.5000501@telepath.com...
>
>
> On second thought, we really ought to get some kind of consensus on
> requirements before rushing headlong into design. If nothing else, it
> will save a lot of arguments.
>
> Requirements I think ought to be included (using the usual should/shall
> language):
>
> Maps shall provide for key lookup in no worse than O(logn) average time
> and O(n) worst case (where n is the # of elements in the map).
>
> Maps shall provide for creation of a sorted list or array, or traversal
> in sorted order, in no worse than O(n) time. (In other words, the map is
> kept sorted as elements are added).
>
> Maps should provide an interface consistent with Lists, as far as is
> practicable.
>
> Comments?
>
>
>
>

Re: Development process in the Ada community

[Marin David Condic]

The problem with any license is that once it gets expensive enough or
restrictive enough, sooner or later someone says "Go Pound Sand!" If someone
says "Here's Library X under the GPL..." and Microsoft doesn't want to be
forced into GPL'ing their stuff just to use Library X, they're going to go
hire a few dozen programmers and say "Go make me something that looks kind
of like this..." They certainly have the money they need not to be cornered
into using someone else's stuff for lack of ability to build one of their
own. Hoping that one day they'll accidentally include some GPL'ed code into
Microsoft Office and be forced to release their source is probably
unrealistic.

I don't begrudge Microsoft using any license they like and I seriously doubt
that the bulk of their customers care if they get the source code or not. If
you don't like their license - go buy something else. That's the free market
system. Maybe one day the Open Source crowd will have everyone using their
products and insisting they get the source or they won't buy and Microsoft
will go the way of Studebaker. I'm just not going to hold my breath waiting
for that event. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87vgalbetj.fsf@deneb.enyo.de...
>
> Of course they use the GPL only if they have to (e.g. for parts of
> Interix), but they pay at least one person for working on free
> software which is licensed under the BSD license (and no, it doesn't
> run only on Windows)...

Re: Development process in the Ada community

[Marin David Condic]

I remember the days when acquiring an Ada compiler required maybe five to
six figures and you couldn't run them on just any old PC. Now I can download
GNAT at no cost from a modest PC and it installs without much fuss and
basically works. Am I going to complain because I can't afford ACT support
for my hobbyist/hacker projects? Not likely. Nor do I feel like I really
*need* much support for the things I'm doing. If ACT wants to make any
version of GNAT available to the general public at no cost, more power to
them and thanks a lot. Its more than I had pre-GNAT.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Richard Riehle" <richard@adaworks.com> wrote in message
news:3CC207BA.5F039C6D@adaworks.com...
>
> Someone once described a difference between conservative and a
> liberal this way.    The conservative throws a rope toward a drowning
> man but makes him swim part of the way to reach it.   A liberal throws
> the rope directly to him and lets go of the rope before he reaches shore.
> What do you call someone who throws the rope, requires the drowning
> person to swim for it, and then lets go of the rope too?
>
> ACT, when working on behalf of its customers, throws them a rope and
> requires them to do their part.    This seems an appropriate business
> model.
> Free GNAT is a rope that has no one holding it at the shoreline end,
> and you still have to swim a little bit to use it properly.
>
> Richard Riehle
>
>
>
>

Re: Development process in the Ada community

[Marin David Condic]

The year is 2099. Programming is now done by plugging an Ethernet wire into
the side of someone's head. (They're called "wireheads" now - not
programmers. But normal people still find them impossible to communicate
with and they have a hard time getting dates. Strangely, pocket protectors
are still worn, but nobody uses pens or pencils anymore.) They "think" the
code into the machine. The main computer at "Alpha Complex" still
"remembers" the GNAT compiler and can regurgitate its source and translate
it into any instruction set the Historians would like for their studies. But
sadly, nobody has inquired about it in quite a while. ACT made a huge
fortune back in the big Ada Fad of 2010 - enough so the organization had a
permanent endowment, but they never built anything new. Now Ada Core
Technologies consists of a single secretary sitting in front of a Fiber Op
waiting for someone to call asking for a support contract and once the check
clears for the Eleventy-Gagillion Dollars (inflation! :-) annual support
fee, she will push the button that will thaw out the brains of all the
techies that were frozen back in 2030 so they can get to work on the
problems. But the jars holding the brains have been collecting dust for some
time now and the secretary spends most of her time polishing her nails and
talking to her boyfriend on the phone. Its nice work, if you can get it.

A bit extreme, maybe, but I think it illustrates my point about how *all*
products have a life-span and ACT, I'm sure, are smart enough to know that &
will evolve new products & services to accommodate that.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Simon Wright" <simon@pushface.org> wrote in message
news:x7vr8lci7mf.fsf@smaug.pushface.org...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
>
> >        Sooner or later, the GNAT compiler will reach a point where
nobody
> > will want to buy suport for it.
>
> There's still a market for support in how to _use_ a product.

Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community?

[Marin David Condic]

I don't know of any company in any industry that can get away with that sort
of attitude for very long. This seems especially true for the software
industry - for either "proprietary" of "open" companies. I don't think the
license has anything to do with it.  The specific license might raise/lower
the entrance/exit barriers, but in the end, a company must provide value
with their software or the customer will go elsewhere. Microsoft with all
its proprietary licensing still brought out software that cost substantially
less and provided substantially more value than (for example) OS-360. In
addition, they *must* find some way of creating *more* value in the future
or the cash cow dries up. They can't lock in their customers any moreso than
DeSoto, Studebaker, Dusenberg, Cord, American Motors, Delorean .......

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0204201744.587dfec7@posting.google.com...
> Unlike a proprietary software company that can use restrictive
> licenses to keep its customer base captive,
> we can't just stop development, degrade support, and sit
> back and milk the customer base, since that would be financially
> disadvantageous to us (and at the risk of

Re: Open Source: in conflict with the development process in the Ada community?

[Marin David Condic]

Anti-trust laws might force you to unbundle products. When a computer
company sells you hardware and throws in a "free" OS and other software, it
isn't really "free", is it? The courts may stop it under an anti-trust suit,
but companies have been giving away stuff "free" for a long time now and I
don't know of any laws that would stop it. (Giving away razors to sell the
blades is the usual example.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87znzy1pif.fsf@deneb.enyo.de...
>
> Regulations against unfair competition.  Hmm, I couldn't find a
> reference to specific German law, but I remember a few cases in which
> companies were forced to stop giving services away for free.  However,
> I'm no longer sure if general provisions against unfair competition
> were applied, or some special case law (telco regulations, for
> example).

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Ted Dennison wrote:
> Hmmm. This seems to be going back to the "naming" issue: Do we want
> *.Maps.Bounded or *.Hashes?

A hash and a map are two different levels. A hash is simply a particular
way of implementing a map. (Assuming you mean "hashtable", but then a
"hash" by itself makes no sense as a datastructure.)

I.e., what keeps a bounded map from being implemented as a tree instead
of a hash? Indeed, for many types, I'd think a tree would be a better
implementation, as a hashtable requires you to be able to manipulate the
key items in a non-opaque manner, while a tree requires only a ordering
operator.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Development process in the Ada community

[Ted Dennison]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0204220627.4da138a8@posting.google.com>...

> As fate would have it, today Eben Moglen, the lawyer for the FSF, has
> put an article up at
> http://moglen.law.columbia.edu/publications/lu-12.html that touches on

Err...change "today" to "today I discovered that". The article itself
seems to be fairly on.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Development process in the Ada community

[Robert Dewar]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0204220627.4da138a8@posting.google.com>...
> As fate would have it, today Eben Moglen, the lawyer for 
> the FSF, has put an article up at
> http://moglen.law.columbia.edu/publications/lu-12.html 
> that touches on this very subject. 

Yes, indeed a useful reference, thanks Ted for posting this. Note that
in practice it is important that typical
GNU compilers, including GNU-C, g++ and GNAT are issued
with relaxed licensing on the runtime that spefically
allows uses of this runtime (or a modification of it) without imposing
GPL licensing on the result

Re: Outside view (still): Development process in the Ada community

[Robert Dewar]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9ppc5$fve$1@nh.pace.co.uk>...
> Other than issues of time and money, I don't see why it 
> *can't* work. Here's the thing: I could put up a web page 
> and declare myself the Informal Ada Conventions 
> Consortium and declare "Henceforth, the following 
> packages are considered to be Official IACC standards and 
> all Ada implementations need to include them in order to > be  conformant!" What weight does it carry?

Well none at all of course. And one thing to realize is
that the ISO process does not have some external legitimacy. It
derives legitimacy from reflecting input
of vendors and serious Ada users. If you can't get vendors
or serious Ada users to buy in, you should not imagine
that you can persuade ISO to issue standards for things
that do not have this kind of interest level.

You certainly can't go to ISO and say, "look, we don't seem
to be able to get any vendors or major Ada users interested, but those
folks who post on CLA are really
enthusiastic".

On the other hand actual useful implementations are definitely a way
to generate such interest, and that
remains the best way to make progress.

An interesting precedent here is the attempt to pseudo-standardize the
Win32 bindings in the ARA
environment. There just was not enough interest to
overcome the problems.

One thing to realize is that official conformance and validation has
largely disappeared as a major concern. The
validation process itself has now been relaxed so that basically all
that needs to happen is a vendor says that
they pass the tests, pay some money, and you get a certificate. ACT
views this kind of validation as pretty
meaningless, and if we do further validations they will
be in the old style with on-site verification.

In fact, while we certainly find it very useful to run the
ACATS tests (we run them every night on all targets and make sure that
we pass them), we see almost no demand for
formal validation.

What I think would be most useful is to generate new bindings and
useful packages. Quite a few people (like Tom and Ted and Florian and
Michael and others -- I am not trying to make a complete list here,
and I would never succeeed) have put in effort on this, and that seems
to
be by far the best use of energy.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Michael Erdmann]

Ted Dennison wrote:
> Ted Dennison wrote:
> 
>> Marin David Condic wrote:
>>
>>> I don't think you need to have the full-blown project setup done in 
>>> order to
>>> discuss an interface to Maps. What would you suggest as a means of 
>>> getting
>>> that ball rolling? Would you like someone to take the Lists spec and 
>>> turn it
>>> into a strawman for Maps? (I hear you're a little preoccupied at the
>>> moment... :-)
>>
>>
>>
>> Yeah, that would be a good start. Right now in addtion to this I'm 
> 
> 
> 
> On second thought, we really ought to get some kind of consensus on 
> requirements before rushing headlong into design. If nothing else, it 
> will save a lot of arguments.
I guess a reference implementation which could be discussed will have
less lines than this thread.

Working in a group on an exsiting reference implementation (which
might be even a bad solution) is more open source style working then 
trying to get some kind of consensus in such a loosly connected
community as comp.lang.ada is!


Regards
    M.Erdmann

Re: Outside view (still): Development process in the Ada community

[Michael Erdmann]

Robert Dewar wrote:
level.
> 
> You certainly can't go to ISO and say, "look, we don't seem
> to be able to get any vendors or major Ada users interested, but those
> folks who post on CLA are really
> enthusiastic".
I agree on this. I have removed the ISO completly from my
Agenda.

..........
> 
> What I think would be most useful is to generate new bindings and
> useful packages. Quite a few people (like Tom and Ted and Florian and
> Michael and others -- I am not trying to make a complete list here,
> and I would never succeeed) have put in effort on this, and that seems
> to
> be by far the best use of energy.
> 
I think you are right. If you look at the open source community,
progress has not been achieved by ISO style of working groups.
In most cases "..release early and often.." and the fact that
the code was "..use full.." in community context was
generating most of the dynamic and the progress.

So i am realy wondering why it is not possible to gather
some people, make a reference implementation of a reasonable
set of simple and well documented package set.

There have been a lot of attempts so far as i know, but
my personal impression was that the way woas more
important then the reaching the destination. So i am
realy wondering if the "..community .." namely
comp.lang.ada realy needs these nice package?

Any how, i need these packages saving precious time. So I
guess somebody else may need them as well. This already
makes it worth to make an additional attempt!

So i am realy wondering if ACT could establish some
kind of public contribtion process. This would
make it possible to boundle the compiler with
some of these packages.
I would expect that ACT, which is an authority in
comp.lang.ada, could be the crystalisation point
for a lot of currently uncoordinated activities.

What do you think?


Regards
    M.Erdmann

Re: Outside view (still): Development process in the Ada community

[Florian Weimer]

Michael Erdmann <Michael.Erdmann@snafu.de> writes:

> So i am realy wondering if ACT could establish some kind of public
> contribtion process. This would make it possible to boundle the
> compiler with some of these packages.

There is already a contribution process: submit a patch to
gcc-patches@gcc.gnu.org. ;-)

Re: Development process in the Ada community

[Randy Brukardt]

David Botton wrote in message ...
>
><tmoran@acm.org> wrote in message
>news:QEtw8.3627$eg5.1828187369@newssvr14.news.prodigy.com...
>> > Imagine if my development efforts would have been used to modify
and extend
>> > CLAW instead of writing GWindows......
>>   I have, and I think it a great loss to the Ada community that you
didn't.
>
>Your lic. wasn't condusive to it..... I agree, sad.

I don't buy it.

You and I discussed Claw, including the licensing at the Washington
SigAda (4 years ago!). I know I told you then that the long-term plan
was to make Claw publically available. If you had simply asked before
starting to work on an alternative, you would have reminded me that we
needed to open up the license. And I'm sure we could have worked out an
acceptable time-table for that.

In any case, I have to wonder why you decided to build something from
scratch rather than building on top of Windex, which already existed and
had the appropriate license. My guess, is that you fell into the same
trap that many of us do: "I can do better than that...". Such a waste of
effort.

>> >GWindows covers almost all areas of CLAW (some intentionally not
covered)
>> >and is way beyond it in other areas (database to control bindings,
ActiveX,
>>   David, it's good to see someone take pride in their product, but
IMHO
>> you exaggerate more than a bit.
>
>But less than a byte.... Note that I am not knocking your framework, I
think
>it is a masterful work and only regret that it was not available under
>different lic. terms.
>
>These em' not fightin' words.... It just happens to be that I support
>certain areas CLAW doesn't and a few other areas I do support CLAW is a
bit
>more thorough. If you had a better lic. you would of course be able to
grab
>some code for GWindows and GNATCOM...... but oh well.


What do you mean by this? Did you mean "grab some code *from* ..."?

If that's what you mean, the answer is "possibly". The Claw tasking
model makes it hard to use code in the bindings that wasn't designed for
it. Luckily, that complexity doesn't extend to the user's code...

> Perhaps, but hopefully we will both be around for another 180 years to
see
> others enjoy our work. Perhaps by then CLAW will well then be lic.
with the
> GMGPL unless of course Ada takes over than GPL.....

You won't have to wait more than however long it takes to read cla today
to see that....

                    Randy.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Jeffrey Carter]

Darren New wrote:
> 
> I.e., what keeps a bounded map from being implemented as a tree instead
> of a hash [table]? Indeed, for many types, I'd think a tree would be a better
> implementation, as a hashtable requires you to be able to manipulate the
> key items in a non-opaque manner, while a tree requires only a ordering
> operator.

Trees also have the advantage that they do not waste space.

The trouble with a tree is that, if it is not balanced, operations can
be O(N) in the worst case. If the tree is balanced, searching is O(log
N), but insertion and deletion are slow, because the tree must be
rebalanced after every modification.

This is why I use skip lists. They do not waste space, and operations
are O(log N) but no rebalancing is needed after modification.

-- 
Jeffrey Carter

Re: Grace and Maps (was Re: Development process in the Ada community)

[David Bolen]

dewar@gnat.com (Robert Dewar) writes:

> David Bolen <db3l@fitlinxx.com> wrote in message news:<ur8lbkxo1.fsf@ctwd0143.fitlinxx.com>...
> 
> > And from another language perspective, in Python, the fundamental
> > built-in data structure types (aside from numerics) are sequences
> > (lists/tuples) and mappings (dictionaries) and certainly in my
> > experience they cover the vast majority of practical situations quite
> > capably.
> 
> Yes, and of course this is an old old idea, copied into Python from the
> heritage of ABC, SETL and other precursors. Mappings are of course 
> powerful enough to represent anything (and sequences are just special
> cases of mappings). That's been known since long before computers existed!

Sorry, didn't mean that to come across as Python inventing the ideas,
only to point out that they prove eminently useful in practice and
without requiring the large number of variations as you might find in
the STL.

> But whether general mappings have a legitimate place in a low level
> language (by SETL standards :-) like Ada is open for debate. And in
> particular, having them as second class citizens without decent syntax
> seems quite dubious.

That's actually an interesting point.  Certainly to my mind part of
what makes lists/dictionaries more convenient (in Python) is the
native syntax support for manipulating them.  But barring an easy way
to do that, at least having them available as clean libraries
consistently available would, I think, go a long way.

> So you might want to throw into the pot user defined subscripting
> and slicing operations :-)

Just have to figure out how to open up Ada's syntax first without a 10
year ISO effort :-)

> My own view is that it is unlikely that any of this will get anywhere
> near smooth enough and with enough consensus to be standardized. I think
> people would better spend their effort implementing sample packages than
> discussing at random on CLA :-)

Ah, but brainstorming is cheap and simple for everyone to have an
opinion :-) Sounds like there might be some coding in the works though
from elsewhere in the thread.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Jeffrey Carter wrote:
> The trouble with a tree is that, if it is not balanced, operations can
> be O(N) in the worst case. If the tree is balanced, searching is O(log
> N), but insertion and deletion are slow, because the tree must be
> rebalanced after every modification.

Well, that's why you use something a little more sophisticated, like a
red-black tree, or a B-tree if your memory I/O works in blocks (like a
disk).

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Larry Kilgallen]

In article <4519e058.0204220531.3a47ba39@posting.google.com>, dennison@telepath.com (Ted Dennison) writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<V+UgdHreGTJg@eisner.encompasserve.org>...
>> In article <3CC21747.5000501@telepath.com>, Ted Dennison <dennison@telepath.com> writes:
>> 
>> > On second thought, we really ought to get some kind of consensus on 
>> > requirements before rushing headlong into design. If nothing else, it 
>> > will save a lot of arguments.
>> > 
>> > Requirements I think ought to be included (using the usual should/shall 
>> > language):
>> > 
>> > Maps shall provide for key lookup in no worse than O(logn) average time 
>> > and O(n) worst case (where n is the # of elements in the map).
>> > 
>> > Maps shall provide for creation of a sorted list or array, or traversal 
>> > in sorted order, in no worse than O(n) time. (In other words, the map is 
>> > kept sorted as elements are added).
>> > 
>> > Maps should provide an interface consistent with Lists, as far as is 
>> > practicable.
>> > 
>> > Comments?
>> 
>> While the interface should not _prevent_ implementations from
>> achieving certain performance goals, I don't think performance
>> goals should be part of the requirements.  If a vendor wants to
>> provide a relatively slow implementation, that is their choice,
>> just like their choice regarding how fast A := B'length should
>> perform.
> 
> I can see your point. For real-time use its vital to know this. I'd
> prefer to see it in the requrements that Maps are usable in real-time
> once the map is already built, which is what these requirements are
> getting at.

Certain operating systems are not suitable for "real-time"[1] use.
Why would you place a requirement on compiler vendors for those
operating systems that they support a performance level no genuine
customer would ever use ?

What aspect of the current Ada95 standard has such a performance
specification ?

[1] For suitable definitions of "real-time".
    In fact, for suitable definitions of "operating systems" :-)

Re: Grace and Maps (was Re: Development process in the Ada community)

[Jeffrey Carter]

Darren New wrote:
> 
> Jeffrey Carter wrote:
> > The trouble with a tree is that, if it is not balanced, operations can
> > be O(N) in the worst case. If the tree is balanced, searching is O(log
> > N), but insertion and deletion are slow, because the tree must be
> > rebalanced after every modification.
> 
> Well, that's why you use something a little more sophisticated, like a
> red-black tree, or a B-tree if your memory I/O works in blocks (like a
> disk).

Maybe my memory is faulty, but I seem to recall that these trees still
need rebalancing to maintain O(log N) search times.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Michael Erdmann wrote:

> Working in a group on an exsiting reference implementation (which
> might be even a bad solution) is more open source style working then 
> trying to get some kind of consensus in such a loosly connected
> community as comp.lang.ada is!

ESR's theory about "OpenSource" development mostly talks about just 
that: development. Before development you have to do some kind of 
design, and before that you have to do some kind of requirements 
analysis. ESR does mention that most OpenSource projects have it fairly 
easy in the RA department, either because their requirements are "clone 
*this* BSD Unix command", or because they start life as one person's 
personal playtoy and grow organicly from there.

We don't have either of those advantages here, so we must do real 
requriements analysis. We can do it by actually trying to achieve 
consensus up front, or by fighting in circles around differing 
implementations created from differing philosophies. The former method 
is ususally much quicker.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Jeffrey Carter wrote:

> Trees also have the advantage that they do not waste space.


...which is something we are already agreeing to trade off when we make 
a structure bounded.

> The trouble with a tree is that, if it is not balanced, operations can
> be O(N) in the worst case. If the tree is balanced, searching is O(log
> N), but insertion and deletion are slow, because the tree must be
> rebalanced after every modification.


Exactly.


> This is why I use skip lists. They do not waste space, and operations
> are O(log N) but no rebalancing is needed after modification.
Hmmm. I'm unfamiliar with skip lists.

(quick web search ensues)

It looks like they are probability based, which means that in the worst 
case it could still behave like a linked-list.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Darren New wrote:

> Jeffrey Carter wrote:
> 
>>The trouble with a tree is that, if it is not balanced, operations can
>>be O(N) in the worst case. If the tree is balanced, searching is O(log
>>N), but insertion and deletion are slow, because the tree must be
>>rebalanced after every modification.
>>
> 
> Well, that's why you use something a little more sophisticated, like a
> red-black tree, or a B-tree if your memory I/O works in blocks (like a
> disk).

A red-black tree still requires balancing when nodes are added, doesn't 
it? Balancing on a bounded structure is likely going to involve moving 
data contents, which is undesirable.

That's why I thought it might make sense to just include a Map, and 
another map-like structure that is naturally bounded. Hash tables came 
to mind.

Re: Development process in the Ada community

[Randy Brukardt]

Marin David Condic wrote in message ...
>I remember the days when acquiring an Ada compiler required maybe five
to
>six figures and you couldn't run them on just any old PC.

Sigh. Nothing like reminscing about the bad old days. There were always
affordable PC compilers (including Janus/Ada on 56K Z-80 CP/M machines).
I suppose you might be able to find a year (1986?) which would meet this
description if you required a validated Ada compiler; but in the years
before it there were no validated Ada compilers that ran on PCs at all,
and in the years after it, there was Janus/Ada (starting at $99) and
Merdian and Ada/Ed. Janus/Ada just required a 640K PC (which was pretty
standard by then).

>Now I can download GNAT at no cost from a modest PC and it installs
without much fuss and
>basically works.

Of course, a "modest PC" now has 100 times the memory and is 100 times
faster. Hardly a fair comparison. About the only difference is the cost
($99 versus nothing). Certainly Janus/Ada "basically worked".

              Randy.

GPL and the big picture (was Re: Development process in the Ada community)

[David Botton]

----- Original Message -----
From: "Randy Brukardt" <randy@rrsoftware.com>

> You and I discussed Claw, including the licensing at the Washington
> SigAda (4 years ago!).
> I know I told you then that the long-term plan
> was to make Claw publically available. If you had simply asked before
> starting to work on an alternative, you would have reminded me that we
> needed to open up the license. And I'm sure we could have worked out an
> acceptable time-table for that.


I don't recall such a conversation, but that's ok.
Action is louder than words, and you have certainly acted!

> In any case, I have to wonder why you decided to build something from
> scratch rather than building on top of Windex, which already existed and
> had the appropriate license. My guess, is that you fell into the same
> trap that many of us do: "I can do better than that...". Such a waste of
> effort.


GWindows took a different direction than both CLAW and Windex. It is easier
to use (testimony of users with experience in all three frameworks) and like
I said, offers many features not found elsewhere (I truly get the impression
you don't know much about the framework - start with
http://www.adapower.com/gwindows/GWindowsVsClaw.html then move on to the
home page http://www.adapower.com/gwindows). I would hardly say the effort
of creating GWindows was a waste (nor was it that big an effort, it is a
labor of love  ;-). I (and others) have written many programs with GWindows
that are running in production environments today (those programs not always
being Open Source). As with most of what I publish as GMGPL (as with many
others actively developing GMGPL libraries), it is a means to an end. I make
my living using my tools not per se building them (although I wish that was
the case). The GMGPL is a tool to advocate Ada and having more than one
GMGPL framework certainly has its P.R. plusses.

You also only see a small part of the big picture. GWindows is part of the
GNATCOM 2.0 design in order to support the creation and native Ada use of
GUI ActiveX controls and a number of other COM/DCOM/ActiveX features. (There
are a number of features in GWindows that are missing from CLAW needed for
this along with the fact that CLAW's tasking model has many problems being
use for this purpose).

BTW, I know of at least two _major_ projects that used CLAW and GNATCOM
together.

GNATCOM itself is only part of a larger project (never named the blanket
project itself...). Another component of that project that is in development
and has taken some serious form is GNavi - The GNU Ada Visual IDE (There is
a very old screen snap shot at
http://www.adapower.com/gwindows/shots/gnavi_snap.jpg). There are other
components in design stages that go with these components as well (Database
related tools, Web Service tools, etc and far more - I certainly don't plan
on spilling all the beans at this point in time :-).

The basic CLAW is too far away from what I need to consider stopping
development on GWindows, putting full force behind extending CLAW "basic"
would be a trap that many fall in to, "cutting off your nose despite your
face" :~) It would also truly be a waste just to catch CLAW basic up to CLAW
full version when you have already written it (the first step before I can
extend CLAW to GWindows functional level)

Can you give a time table (if there is one) for the full version of CLAW to
become GMGPL. Perhaps there is some future in merging with CLAW, but that is
to be seen.

I look forward to the day (I don't suspect it will be that long off) when
your frustrations have vented and attacking my project will no longer be
necessary for you and some clear thinking about the future possibilities
shines forth.

> What do you mean by this? Did you mean "grab some code *from* ..."?
I was referring to the ability to incorporate GMGPL code in to CLAW from
another project or vice versa.

In a nut shell:

I write in Ada because it is the better all around language, I write my
frameworks and tools to make it possible to use Ada on my projects, I
release my work as GMGPL to promote Ada usage. I've gotten the short end of
the stick from Microsoft and Borland more than once, so I learned the hard
way to believe in using (and creating) GPL lic. tools. (Although I prefer
open development models, GPL does not always mean this...)

Ada Core and other companies choosing the GPL to lic. their products will
out live and prosper beyond the current MicroSoft Era of software
development (they already are...)

Making it these days (financially speaking) with the GPL requires the same
skills that all true Entrepreneurs must have, broad vision and self
discipline. Start thinking now about the new models of business that use
open lic. schemes, for tomorrow it may just be too late.

David Botton

Re: Outside view (still): Development process in the Ada community

[Michael Erdmann]

Florian Weimer wrote:
> Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> 
> 
>>So i am realy wondering if ACT could establish some kind of public
>>contribtion process. This would make it possible to boundle the
>>compiler with some of these packages.
>>
> 
> There is already a contribution process: submit a patch to
> gcc-patches@gcc.gnu.org. ;-)
> 

But this has more the falvour of beeing an error correction
process!?

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Jeffrey Carter wrote:
> Maybe my memory is faulty, but I seem to recall that these trees still
> need rebalancing to maintain O(log N) search times.

Yes, but only on inserts, only rebalancing of a limited amount of the
tree (O(log N) for the worst case rebalance) and generally do *not*
require rebalances on every insert. It's not like keeping a list sorted,
for example. For example, a red-black tree touches at worse the nodes
between the node you just inserted and the root, IIRC. A B-tree (which
is based on blocks of pointers) touches the block you inserted in and
potentially back to the root, either splitting or combining as needed. 

Red/black trees don't get nodes moved when they're rebalanced. You just
adjust the pointers. 

I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if
all the elements hash to the same value) or how you'd guarantee any
particular limit on execution time of inserting a value (for example, in
the same case). In contrast, a red-black tree is *never* going to see
O(N) time in any operation.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: GPL and the big picture (was Re: Development process in the Ada community)

[David Botton]

Just to make sure this is not misunderstood. I was expressing my joy at
seeing that CLAW basic has gone GMGPL.

David Botton

"David Botton" <David@Botton.com> wrote in message
news:uc9pspep4lmef2@corp.supernews.com...
> Action is louder than words, and you have certainly acted!

Re: Grace and Maps (was Re: Development process in the Ada community)

[Simon Wright]

Darren New <dnew@san.rr.com> writes:

> I'm not sure why a hashtable wouldn't have a worst-case time of O(N)
> (if all the elements hash to the same value) or how you'd guarantee
> any particular limit on execution time of inserting a value (for
> example, in the same case). In contrast, a red-black tree is *never*
> going to see O(N) time in any operation.

I would have expected a hash table to have O(N) anyway, at least for
searching; it's just that the multiplier is reduced by the number of
hash buckets.

This is certainly the case for the BCs, now you all come to mention
it! Insertion is constant time, though.

Are red-black trees much better than AVL trees (which is what you get
in the BCs)?

Re: Development process in the Ada community

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Of course, a "modest PC" now has 100 times the memory and is 100
> times faster. Hardly a fair comparison. About the only difference is
> the cost ($99 versus nothing). Certainly Janus/Ada "basically
> worked".

Yep, I remember that! Even so far as having shared generics, if I
remember correctly.

The modest PC I used was an 8 MHz PC-AT clone with 2 MB RAM and 20 MB
HDD. Sigh.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Kent Paul Dolan]

"Jeffrey Carter" <jrcarter@acm.org> wrote:

> Darren New wrote:

> > Jeffrey Carter wrote:
> > > The trouble with a tree is that, if it is not balanced, operations can
> > > be O(N) in the worst case. If the tree is balanced, searching is O(log
> > > N), but insertion and deletion are slow, because the tree must be
> > > rebalanced after every modification.

No, the balance need only be _checked_ after every modification; many
insertions or deletions leave the tree in balance, and rebalancing is
still a cheap operation.

It's been a while, but I thought that for many, the amortized cost of
insertion and deletion was still order log N?  The TreeSet that I used
in Java derived from a class with that software contract.

> > Well, that's why you use something a little more sophisticated, like a
> > red-black tree, or a B-tree if your memory I/O works in blocks (like a
> > disk).

> Maybe my memory is faulty, but I seem to recall that these trees still
> need rebalancing to maintain O(log N) search times.

Yes, you are correct; free lunches are still scarce.

xanthian.



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

Darren New <dnew@san.rr.com> writes:

> Jeffrey Carter wrote:
> > Maybe my memory is faulty, but I seem to recall that these trees still
> > need rebalancing to maintain O(log N) search times.
> 
> Yes, but only on inserts, only rebalancing of a limited amount of the
> tree (O(log N) for the worst case rebalance) and generally do *not*
> require rebalances on every insert. It's not like keeping a list sorted,
> for example. For example, a red-black tree touches at worse the nodes
> between the node you just inserted and the root, IIRC. A B-tree (which
> is based on blocks of pointers) touches the block you inserted in and
> potentially back to the root, either splitting or combining as needed. 
> 
> Red/black trees don't get nodes moved when they're rebalanced. You just
> adjust the pointers. 
> 

Yes, they are very nice.

> I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if
> all the elements hash to the same value) or how you'd guarantee any
> particular limit on execution time of inserting a value (for example, in
> the same case). In contrast, a red-black tree is *never* going to see
> O(N) time in any operation.
> 

You're right, you cannot in general guarantee it. But if you use hash
functions which on average change half the bits as a result of a
single bit change in the input, you can rest assured that it will not
happen in practice. A more serious problem is that the average time
increases as you add more data items. For your typical hash link
table, you should try to keep the table not more than 50-80%
full. This will give you search times very close to O(1) with a good
hash function.

For general use, I would certainly prefer a good tree implementation,
but when you need the utmost speed and have a fixed size data set, I
would go for the hash table.

> -- > Darren New > San Diego, CA, USA
> (PST). Cryptokeys on demand.  > The 90/10 rule of toothpaste: the last
> 10% of > the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

Simon Wright <simon@pushface.org> writes:

> Darren New <dnew@san.rr.com> writes:
> 
> > I'm not sure why a hashtable wouldn't have a worst-case time of O(N)
> > (if all the elements hash to the same value) or how you'd guarantee
> > any particular limit on execution time of inserting a value (for
> > example, in the same case). In contrast, a red-black tree is *never*
> > going to see O(N) time in any operation.
> 
> I would have expected a hash table to have O(N) anyway, at least for
> searching; it's just that the multiplier is reduced by the number of
> hash buckets.
> 
> This is certainly the case for the BCs, now you all come to mention
> it! Insertion is constant time, though.
> 
> Are red-black trees much better than AVL trees (which is what you get
> in the BCs)?

You size your hash link table so that the order is what you want. I
usually aim for O(1).

Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community?

[Robert Dewar]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<aa1cde$rbr$1@nh.pace.co.uk>...

> I don't know of any company in any industry that can get away with that sort
> of attitude for very long. This seems especially true for the software
> industry - for either "proprietary" of "open" companies. I don't think the
> license has anything to do with it.  The specific license might raise/lower
> the entrance/exit barriers, but in the end, a company must provide value
> with their software or the customer will go elsewhere. Microsoft with all
> its proprietary licensing still brought out software that cost substantially
> less and provided substantially more value than (for example) OS-360. In
> addition, they *must* find some way of creating *more* value in the future
> or the cash cow dries up. They can't lock in their customers any moreso than
> DeSoto, Studebaker, Dusenberg, Cord, American Motors, Delorean .......

You miss the point. Of course this (behavior commonly referred to as
"bottom feeding") cannot persist for long with respect to a particular
product, but it is remarkably common for a company with a proprietary
software product to essentially abandon continued support, and then
continue to profit from a captive market for what can be a suprising
long time. All I am noting is that our model won't let us do this for
even a short time, and that seems a good thing all round. 

As a company, our policy is to rely on rapid innovation rather than
on restrictive intellectual property rights. We are convinced that if
we continue to innovate rapidly, we can continue to be successful, and
we think this is a model that benefits both us and our customers.

I should also say that I think it leads to a much more satisfying
environment
for software developers. I still spend a lot of my time improving GNAT
by
adding new functionality and improving what is already there, and I
find it
very satisfying that the code I write is open for examination (and
hopefully
appreciation :-) by others. In more concrete terms, I think that this
openness
is one of the reasons that no software engineer has ever left Ada Core
Technologies in its seven years of existance. Which is surprising,
especially
since we can't dangle stock options worth potential millions as an
incentive.

Again, please interpret the above remembering that I have an interest
(both
financial, but more importantly personal, and from the point of view
of general success of Ada) in the continuing success of ACT :-)

Robert Dewar

Re: Grace and Maps (was Re: Development process in the Ada community)

[Alan Reynolds]

Darren New wrote:
> I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if
> all the elements hash to the same value) or how you'd guarantee any
> particular limit on execution time of inserting a value (for example, in
> the same case). In contrast, a red-black tree is *never* going to see
> O(N) time in any operation.
> 

Except for creation :)

Have fun,
Al

Re: Development process in the Ada community

[Marin David Condic]

I actually owned the Janus Ada compiler back then, but I've been hanging
around Ada since probably about 1980 when it was first being discussed &
draft standards were being published. The first Ada compiler I owned was the
Telesoft Ada compiler and that was not validated. IIRC, the version of Janus
Ada I owned was not validated either. There was a time back in The Bad Old
Days when if you wanted a validated compiler, they couldn't be had except on
some rather expensive platforms and at some rather steep prices and
generally there were lots of reasons not to be happy with what they (or the
companies that sold them) did. Certainly Janus Ada was a turning point in
the history of Ada in that it made it accessible at a price within the
bounds of an average programmer. And of course what today is considered
"modest" hardware would have been considered fast/big for a mainframe back
then.

One of the things that hurt Ada was that it was ahead of the hardware needed
by a few years. Once we got beyond 640k limits and hard drives didn't
require a bank note to buy, the environment was there - but already the bad
reputation had got started.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:uc9nipnjt9615c@corp.supernews.com...
>
> Sigh. Nothing like reminscing about the bad old days. There were always
> affordable PC compilers (including Janus/Ada on 56K Z-80 CP/M machines).

Re: Grace and Maps (was Re: Development process in the Ada community)

[Stephen Leake]

Ted Dennison <dennison@telepath.com> writes:

> Requirements I think ought to be included (using the usual
> should/shall language):
> 
> Maps shall provide for key lookup in no worse than O(logn) average
> time and O(n) worst case (where n is the # of elements in the map).
> 
> Maps shall provide for creation of a sorted list or array, or
> traversal in sorted order, in no worse than O(n) time. (In other
> words, the map is kept sorted as elements are added).
> 
> Maps should provide an interface consistent with Lists, as far as is
> practicable.
> 
> Comments?

These work for me.

We could add something about no memory leaks, but maybe that's implied.

One of the requirements for Grace.Lists was that it be useable with
one instantiation. That had a significant impact on the final design.
Do we want to keep that in general for Grace? I think not, if we have
any intention of it being used in serious work. Both the Booch
Components and SAL generally need several instantiations to get useful
stuff, because they provide more flexibility.

-- 
-- Stephe

Re: Grace and Maps (was Re: Development process in the Ada community)

[Stephen Leake]

Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> writes:

> For general use, I would certainly prefer a good tree implementation,
> but when you need the utmost speed and have a fixed size data set, I
> would go for the hash table.

So we need to allow for both:

Grace.Maps.Tree_implementation
Grace.Maps.Hash_Implementation

Hash_implementation will take a generic parameter giving the max N of
the data set, or the size of the hash table, or something similar.

-- 
-- Stephe

Re: Development process in the Ada community

[Hyman Rosen]

Marin David Condic wrote:
>  Hoping that one day they'll accidentally include some GPL'ed code into
> Microsoft Office and be forced to release their source is probably
> unrealistic.

If it was discovered that MSO included GPLed code, MS
could choose to honor the GPL and distribute the source,
or they could stop selling the version of the product
which included the GPLed code. This would generally mean
that unsold product (store shelves, or at distributors)
would be recalled, but people who have bought copies
would be permitted to keep them. If the violation is
found to be deliberate, then various civil or criminal
penalties could apply, but it's unlikely that revealing
the MSO sources would be part of the penalty.

Remember, if someone commits a copyright violation, the
copyright holder does not get to decide what the penalty
should be.

Re: Development process in the Ada community

[Marin David Condic]

Well, that's kind of the point. For one thing, Microsoft isn't likely to
want to open itself to liability by using GPL'ed code and then not handing
out the source. Better to simply spend a million or so having an in-house
team develop their own version that they control. What does it buy them to
try to gain leverage with GPL'ed code? For another thing, Microsoft has
little to zero incentive to want to expose their code publically. That could
only benefit their competitors. So why would they one day have a change of
heart and decide to start GPL-ing things? Finally, I doubt very much that
the bulk of their customers care if they get the source code or not. Arguing
that somehow the customer is going to gain some benefit like protection from
Microsoft going out of business (probably not in my lifetime or at least the
useful life of the software) or that they can get third-party support (they
can get training and help now, but no bug-fix/feature changes - yet still
they buy, so why should Microsoft care?) just doesn't seem to carry much
weight.

Maybe one day Open Source vendors will overtake Microsoft. I just don't see
Microsoft giving up and joining the Open Source strategy either by accident
or design so long as they are on top.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3CC57FEA.8020208@mail.com...
>
> If it was discovered that MSO included GPLed code, MS
> could choose to honor the GPL and distribute the source,
> or they could stop selling the version of the product
> which included the GPLed code. This would generally mean
> that unsold product (store shelves, or at distributors)
> would be recalled, but people who have bought copies
> would be permitted to keep them. If the violation is
> found to be deliberate, then various civil or criminal
> penalties could apply, but it's unlikely that revealing
> the MSO sources would be part of the penalty.
>
> Remember, if someone commits a copyright violation, the
> copyright holder does not get to decide what the penalty
> should be.
>

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Alan Reynolds wrote:
> 
> Darren New wrote:
> > I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if
> > all the elements hash to the same value) or how you'd guarantee any
> > particular limit on execution time of inserting a value (for example, in
> > the same case). In contrast, a red-black tree is *never* going to see
> > O(N) time in any operation.
> >
> 
> Except for creation :)

Well, I think you're misunderstanding what O(N) means here. Red-black
trees don't support a "create the whole tree" operation, and inserting a
single element isn't O(N). I know you're likely joking. (Note that if
you include "creation from scratch and filling it with N items", there's
no algorithm possible that's faster than O(N), as you have to at least
look at all the items.)

The advantage of a red-black tree (or any other search tree) over a hash
is, of course, that the results are sorted, so iterating over it in
order is simple. Implementing a hash version with the same interface as
either a hash or a tree would lose this nice property.

It's possible that there's a version of one of these data structures
that's even faster, based on array heaps or something, but I don't
remember what they might be. There's also other forms of trees, like AVL
trees, whose properties I also don't remember offhand.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Wish List : Ada95 to FOX

[Warren W. Gay VE3WWG]

rc211v wrote:

> On Thu, 18 Apr 2002 18:35:28 +0000 (UTC), "Kent Paul Dolan"
> <xanthian@well.com> wrote:
>>Java is by design OS
>>independent, contributing to breaking the stranglehold of MS-Windows on
>>the market of "things needed to run applications". 
> 
> Java is _by_design_ a marketing product in search of a real problem to
> solve.
> 
> I've recently discovered a very nice portable graphics library, FOX.
> 
> The goal of it's designer is: "Write Once, Compile Anywhere" ... 
> 
> For those who want to take a look go to http://fox-toolkit.org . Just
> download the calculator demo. You will be impressed. 


I like the fact that FOX does not use the precompiler MOC approach

that Qt did. It would be reeeeaaal nice (hint) to have an Ada95
binding to this. I havn't looked at it in detail, so I don't know
how practical this is (written in C++).

One area that has traditionally been a sore point in Ada and GUIs is
the client_data parameter in callbacks.  Gtk kind of hacks around this,
but I'd like to see a more perfect (Ada95) solution to this problem.

I like the idea of requiring a base tagged type as the client data
parameter (classwide?), which defaults to an dummy instance base
type when none is provided.  To actually provide user data, the
user would derive from the base type, and pass that instead
when establishing the callback.

Within the callback, the user would re-cast the base_type to the
type that the callback was actually expecting to get. This way,
if the tagged type provided was not correct for the "cast", an
exception would occur and type safety is maintained.

I think FOX might permit this type of a binding to be accomplished.

I also like the fact that FOX is designed to permit dynamic
messaging between widgets. Qt and MFC for example, are fixed at
compile time by MOC/macros AFAI know.


-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Grace and Maps (was Re: Development process in the Ada community)

[Warren W. Gay VE3WWG]

Ted Dennison wrote:

> Ted Dennison wrote:
>> Marin David Condic wrote:
>>> I don't think you need to have the full-blown project setup done in 
>>> order to
>>> discuss an interface to Maps. What would you suggest as a means of 
>>> getting
>>> that ball rolling? Would you like someone to take the Lists spec and 
>>> turn it
>>> into a strawman for Maps? (I hear you're a little preoccupied at the
>>> moment... :-)
>>
>> Yeah, that would be a good start. Right now in addtion to this I'm 
> 
> On second thought, we really ought to get some kind of consensus on 
> requirements before rushing headlong into design. If nothing else, it 
> will save a lot of arguments.
> 
> Requirements I think ought to be included (using the usual should/shall 
> language):
> 
> Maps shall provide for key lookup in no worse than O(logn) average time 
> and O(n) worst case (where n is the # of elements in the map).
> 
> Maps shall provide for creation of a sorted list or array, or traversal 
> in sorted order, in no worse than O(n) time. (In other words, the map is 
> kept sorted as elements are added).


I'm not sure about this sort requirement. Many applications only need to
fetch a value based upon a key. Requiring that the map be sorted will
probably impose suboptimal performance if your requirement doesn't require
sorting.

The sort requirment could be made as part of iteration, and optionally
at that. Just my $0.02 Cdn, which isn't worth much these days ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

I'd think we would want to retrieve the elements back in order as the
general case. Think about using it to store a directory of files or
something similar - you add/delete elements from the map and then want to
refresh a display to show it to the user. Chances are, sorting is important.
It might pay to have a specific case for a hash table that adds performance
at the price of lack of sorted order, but for a Mark 1, Mod 0 map package,
I'd say it should have sorting.

What do other languages provide with maps? MFC? STL? I'll bet you can get
items sorted on the key.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3CC59ED2.1000803@home.com...
>
> I'm not sure about this sort requirement. Many applications only need to
> fetch a value based upon a key. Requiring that the map be sorted will
> probably impose suboptimal performance if your requirement doesn't require
> sorting.
>
> The sort requirment could be made as part of iteration, and optionally
> at that. Just my $0.02 Cdn, which isn't worth much these days ;-)
>

Re: Grace and Maps (was Re: Development process in the Ada community)

[Alan Reynolds]

Hi Darren,

It was a tongue in cheek comment.  Often creation (or destruction) is 
not looked at as an operation but can have a significant cost.  A lessen 
I learned using C++.

Ted's requirements steer the implementation right at binary trees.  A 
hash table cannot support sorted traversal in O(n) time.

Have fun,
Al

Darren New wrote:
> Alan Reynolds wrote:
> 
>>Darren New wrote:
>>
>>>I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if
>>>all the elements hash to the same value) or how you'd guarantee any
>>>particular limit on execution time of inserting a value (for example, in
>>>the same case). In contrast, a red-black tree is *never* going to see
>>>O(N) time in any operation.
>>>
>>
>>Except for creation :)
> 
> 
> Well, I think you're misunderstanding what O(N) means here. Red-black
> trees don't support a "create the whole tree" operation, and inserting a
> single element isn't O(N). I know you're likely joking. (Note that if
> you include "creation from scratch and filling it with N items", there's
> no algorithm possible that's faster than O(N), as you have to at least
> look at all the items.)
> 
> The advantage of a red-black tree (or any other search tree) over a hash
> is, of course, that the results are sorted, so iterating over it in
> order is simple. Implementing a hash version with the same interface as
> either a hash or a tree would lose this nice property.
> 
> It's possible that there's a version of one of these data structures
> that's even faster, based on array heaps or something, but I don't
> remember what they might be. There's also other forms of trees, like AVL
> trees, whose properties I also don't remember offhand.
> 

Re: Grace and Maps (was Re: Development process in the Ada community)

[Anders Gidenstam]

In article <3CC49C50.485AE213@san.rr.com>,
	Darren New <dnew@san.rr.com> writes:
> Jeffrey Carter wrote:
>> The trouble with a tree is that, if it is not balanced, operations can
>> be O(N) in the worst case. If the tree is balanced, searching is O(log
>> N), but insertion and deletion are slow, because the tree must be
>> rebalanced after every modification.
> 
> Well, that's why you use something a little more sophisticated, like a
> red-black tree, or a B-tree if your memory I/O works in blocks (like a
> disk).
> 

Just to add one more possible implementation data structure, there is
also the random treap, which at least is a bit easier to implement
than an AVL tree.
The random treap is a search tree w.r.t the element keys and a heap
w.r.t an extra field that is assigned a random (uniformly distributed)
value when the element is inserted in the tree.  This will, with a
high probability, keep the tree well balanced.  All operations are
(amortized) O(log N).

I read about them in a course and have a simple implementation on
my (old) homepage:
http://www.dtek.chalmers.se/~d96andgi/Ada/

/Anders
-- 
--------------------------------------------
"A well-written program is its own heaven;
 a poorly-written program is its own hell."
  - The Tao of Programming 

Re: Grace and Maps (was Re: Development process in the Ada community)

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> I'm not sure about this sort requirement. Many applications only need to
> fetch a value based upon a key. Requiring that the map be sorted will
> probably impose suboptimal performance if your requirement doesn't require
> sorting.

If they want to fetch a value based on a key, a sorted structure is
the fasted way to do that. If they don't want to pay for the sorting
overhead on insert, they will pay for the very slow fetch time.

What are the _timing_ requirements in general? fetching a value from a
non-sorted structure is O(n). Fetching from a sorted structure is
generally O(logn), and can be O(1) for an optimal hash table.

Just because the user doesn't need a sorted iteration thru the map
contents, that doesn't mean they don't want a sorted structure.

> The sort requirment could be made as part of iteration, and
> optionally at that. 

This is true; we should allow for different implementations. However,
I seriously doubt anyone would implement a non-sorted map for a
serious application.

-- 
-- Stephe

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Ole-Hjalmar Kristensen wrote:
> You're right, you cannot in general guarantee it. But if you use hash
> functions which on average change half the bits as a result of a
> single bit change in the input, you can rest assured that it will not
> happen in practice.

I haven't done any safety-critical work, but is this how it's really
done? "It's very unlikely this airplane will crash into that nuclear
plant, unless 20 items all hash to the same value"?  :-)  No,
seriously...

In any case, the hashes still have two problems:

1) You *could* be hosed this way, so while they may be faster, they're
still not deterministic, while a red-black tree has a strictly bounded
upper limit on the number of operations (given a particular number of
nodes) which is much lower than that of a hash table. In other words,
the worst-case for a hashtable is still O(N), which if you need realtime
and safety-critical, you have to take it into account.

2) You need to be able to hash the value. A red-black tree needs only an
ordering operator (like "<"), not something that gropes the insides of
an object like a hash needs to. If you want to ensure you have a
particularly good hash, then you are going to have trouble with the
strong typing in Ada, yes? That is, every type of hash table I create is
going to work only if I implement a hash appropriate to the key type,
and that'll have to get reimplemented (to some extent at least) for
every type. On the other hand, most of the built-in types and metatypes
("record", "array", etc) already have ordering operators or rules on how
to deduce them from the components.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Stephen Leake wrote:
> This is true; we should allow for different implementations. However,
> I seriously doubt anyone would implement a non-sorted map for a
> serious application.

I think there are *tons* of applications that use unsorted maps, i.e.,
hash tables. Entire file systems have been built on same, for example.
If the key is an arbitrary value (e.g., some random token used merely to
identify the object, like a social-security-number) then there's little
point in sorting the values. Of course, if you ever need it sorted,
chances are you want to keep it sorted. But AFAIK, none of the scripting
languages (Tcl, Perl, Python) have sorts for their
internally-implemented maps.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Wish List : Ada95 to FOX

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> One area that has traditionally been a sore point in Ada and GUIs is
> the client_data parameter in callbacks.  Gtk kind of hacks around this,
> but I'd like to see a more perfect (Ada95) solution to this problem.

Do you like the Windex solution to this? I use generics. Best example
is in the Menus package.


-- 
-- Stephe

Re: Grace and Maps (was Re: Development process in the Ada community)

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> Stephen Leake wrote:
> > This is true; we should allow for different implementations. However,
> > I seriously doubt anyone would implement a non-sorted map for a
> > serious application.
> 
> I think there are *tons* of applications that use unsorted maps, i.e.,
> hash tables. Entire file systems have been built on same, for example.
> If the key is an arbitrary value (e.g., some random token used merely to
> identify the object, like a social-security-number) then there's little
> point in sorting the values. Of course, if you ever need it sorted,
> chances are you want to keep it sorted. But AFAIK, none of the scripting
> languages (Tcl, Perl, Python) have sorts for their
> internally-implemented maps.

And they all live with O (n) time? amazing ! :).

-- 
-- Stephe

Re: Wish List : Ada95 to FOX

[Randy Brukardt]

Warren W. Gay VE3WWG wrote in message <3CC5997E.4040904@home.com>...

Warren Gay wrote:

>I like the idea of requiring a base tagged type as the client data
>parameter (classwide?), which defaults to an dummy instance base
>type when none is provided.  To actually provide user data, the
>user would derive from the base type, and pass that instead
>when establishing the callback. ...

It's a good idea. So good, in fact, that we use it in Claw to handle the
random globs of data that Windows sends along with notifications. Since
early 1997...

(Rule of thumb #1: someone else has already had any good idea that you
have. :-)

              Randy.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Stephen Leake wrote:
> > point in sorting the values. Of course, if you ever need it sorted,
> > chances are you want to keep it sorted. But AFAIK, none of the scripting
> > languages (Tcl, Perl, Python) have sorts for their
> > internally-implemented maps.
> 
> And they all live with O (n) time? amazing ! :).

No. Hash tables aren't O(n) except in the worst case. In the best case,
they're O(1). When you'd doing things like looking up variables, it's
pretty easy to pay the sort time if you want to iterate over all
variable names in sorted order, compared to getting close to O(1) when
referencing a variable instead of O(logN) each time. Think "symbol
table".

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Outside view (still): Development process in the Ada community

[Florian Weimer]

Michael Erdmann <Michael.Erdmann@snafu.de> writes:

>> There is already a contribution process: submit a patch to
>> gcc-patches@gcc.gnu.org. ;-)

> But this has more the falvour of beeing an error correction
> process!?

Yes, your patch is subjected to review, of course.

Or do you think that the list is for GCC bug fixes only?  This is
wrong, all patches (even patches adding new features) should be sent
to this list for consideration.

Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community?

[Marin David Condic]

Then maybe we're in violent agreement. I don't doubt that having open source
might make for building a fire under a company to continue to provide
support and innovate because the barriers to entry are lower for someone
else to come along and do so as well. Its possible that this is a critical
selling point to the end customer - depending on the product and customer.

I'd continue to contend that the barriers are not infinite even without open
source - just higher. And even Microsoft with large resources and high
barriers to competitors are not in a position to avoid innovation. They have
to at least do what the car companies do with model year changes - keep the
guts unchanged but bend the sheet metal a little different - or nobody wants
to buy the next generation.

As for the wisdom of that strategy? ACT seems to be making it work and other
companies have been successful by adopting a rapid-innovation and
customer-centric approach. Other companies have been successful for long
stretches of time without changing their products much at all (witness the
VW Beetle). So the answer seems to be - as with many things in life - "It
Depends". Is open source critical to that success? Maybe. Maybe its just the
current software-buyer's fad - like tailfins. Maybe it depends on the
product at hand. In any case, its hard to argue with success.

Incidentally, I had not heard it called "bottom feeding". I've heard it
called "milking the cash cow". Bottom feeding is what I've associated with a
stock-buying strategy - find hurting to bankrupt companies and buy the stock
for less than the liquidation value. But I could see how a twist of the
phrase could apply to scouring up the crumbs of business left with a product
as it decays.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0204230444.6684ac@posting.google.com...
>
> You miss the point. Of course this (behavior commonly referred to as
> "bottom feeding") cannot persist for long with respect to a particular
> product, but it is remarkably common for a company with a proprietary

Re: Grace and Maps (was Re: Development process in the Ada community)

[David Bolen]

Simon Wright <simon@pushface.org> writes:

> Darren New <dnew@san.rr.com> writes:
> 
> Are red-black trees much better than AVL trees (which is what you get
> in the BCs)?

I believe the primary difference is a better bound on the number of
operations to perform to re-balance the tree.  In an AVL tree you may
need to perform lg n rotations, whereas in an red-black tree you have
a maximum of 2 rotations for insertion, and 3 for deletion.

How much of an improvement this is would depend on the cost of
performing the rotation.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: Grace and Maps (was Re: Development process in the Ada community)

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Jeffrey Carter wrote:
> 
> > This is why I use skip lists. They do not waste space, and operations
> > are O(log N) but no rebalancing is needed after modification.
> Hmmm. I'm unfamiliar with skip lists.
> 
> (quick web search ensues)
> 
> It looks like they are probability based, which means that in the worst
> case it could still behave like a linked-list.

Skip lists are probabilistically balanced. Average search times are
O(log N). The good news is that even a halfway decent random-number
generator ensures decent balancing if N is large enough to matter. See
figure 8 in

ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf

"Although a skip list may not be balanced, the probability of a skip
list being substantially unbalanced is insignificant. Algorithms for
insertion and deletion in skip lists are simpler and faster than
equivalent algorithms for balanced trees."

-- http://www.cs.umd.edu/~pugh/

Skip lists, like trees and unlike hash tables, provide easy traversal in
sorted order.

-- 
Jeffrey Carter

Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community?

[Jeffrey Carter]

Robert Dewar wrote:
> 
> I should also say that I think it leads to a much more satisfying
> environment
> for software developers. I still spend a lot of my time improving GNAT
> by
> adding new functionality and improving what is already there, and I
> find it
> very satisfying that the code I write is open for examination (and
> hopefully
> appreciation :-) by others. In more concrete terms, I think that this
> openness
> is one of the reasons that no software engineer has ever left Ada Core
> Technologies in its seven years of existance. Which is surprising,
> especially
> since we can't dangle stock options worth potential millions as an
> incentive.

Sounds nice. Too bad I have neither compiler development experience nor
a desire to live in New York.

-- 
Jeffrey Carter

Re: Wish List : Ada95 to FOX

[Jeffrey Carter]

"Warren W. Gay VE3WWG" wrote:
> 
> One area that has traditionally been a sore point in Ada and GUIs is
> the client_data parameter in callbacks.  Gtk kind of hacks around this,
> but I'd like to see a more perfect (Ada95) solution to this problem.

I consider callbacks themselves a sore point. Callbacks are a hack to
handle the inherent concurrency of a windowing system in a sequential
language such as C. The natural approach is to associate a concurrent
blocking queue of events with each window; the application has a task
per window obtaining events from this queue and deciding what to do with
them.

-- 
Jeffrey Carter

Re: Grace and Maps (was Re: Development process in the Ada community)

[Jean-Marc Bourguet]

David Bolen <db3l@fitlinxx.com> writes:

> Simon Wright <simon@pushface.org> writes:
> 
> > Darren New <dnew@san.rr.com> writes:
> > 
> > Are red-black trees much better than AVL trees (which is what you get
> > in the BCs)?
> 
> I believe the primary difference is a better bound on the number of
> operations to perform to re-balance the tree.  In an AVL tree you may
> need to perform lg n rotations, whereas in an red-black tree you have
> a maximum of 2 rotations for insertion, and 3 for deletion.

Red-Black trees are a special case of B-Trees (consider a black node
with its red child and you have a B-Tree bucket).  So the maximum
number of operations needed on insertion and deletioon is of the order
of log n.

-- 
Jean-Marc

Re: Wish List : Ada95 to FOX

[Jean-Pierre Rosen]

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


"Jeffrey Carter" <jeffrey.carter@boeing.com> a �crit dans le message news: 3CC5F5B0.DBC6A6B8@boeing.com...
> "Warren W. Gay VE3WWG" wrote:
> >
> > One area that has traditionally been a sore point in Ada and GUIs is
> > the client_data parameter in callbacks.  Gtk kind of hacks around this,
> > but I'd like to see a more perfect (Ada95) solution to this problem.
>
> I consider callbacks themselves a sore point. Callbacks are a hack to
> handle the inherent concurrency of a windowing system in a sequential
> language such as C. The natural approach is to associate a concurrent
> blocking queue of events with each window; the application has a task
> per window obtaining events from this queue and deciding what to do with
> them.
>
<PLUG>
The issue of call-backs (and more generally of the listener paradigm) will be addressed in a paper that I present at the
Ada-Europe/Vienna conference.
</PLUG>

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

Darren New <dnew@san.rr.com> writes:

> Ole-Hjalmar Kristensen wrote:
> > You're right, you cannot in general guarantee it. But if you use hash
> > functions which on average change half the bits as a result of a
> > single bit change in the input, you can rest assured that it will not
> > happen in practice.
> 
> I haven't done any safety-critical work, but is this how it's really
> done? "It's very unlikely this airplane will crash into that nuclear
> plant, unless 20 items all hash to the same value"?  :-)  No,
> seriously...

I agree, not the thing you would want in a hard real time
safety-critical system. Buf for soft real time, non saftey critical
systems it's good enough. And it really can make a difference in
throughput in for instance applications like relational algebra
processing.

> 
> In any case, the hashes still have two problems:
> 
> 1) You *could* be hosed this way, so while they may be faster, they're
> still not deterministic, while a red-black tree has a strictly bounded
> upper limit on the number of operations (given a particular number of
> nodes) which is much lower than that of a hash table. In other words,
> the worst-case for a hashtable is still O(N), which if you need realtime
> and safety-critical, you have to take it into account.
> 

Agree, although even O(N) might be good enough, depending on you
application. Also, if the probability of O(N) behaviour is
sufficiently low, it may be way below the probability of a system
failure caused by other errors.

> 2) You need to be able to hash the value. A red-black tree needs only an
> ordering operator (like "<"), not something that gropes the insides of
> an object like a hash needs to. If you want to ensure you have a
> particularly good hash, then you are going to have trouble with the
> strong typing in Ada, yes? That is, every type of hash table I create is
> going to work only if I implement a hash appropriate to the key type,
> and that'll have to get reimplemented (to some extent at least) for
> every type. On the other hand, most of the built-in types and metatypes
> ("record", "array", etc) already have ordering operators or rules on how
> to deduce them from the components.
> 

Yes, although the reimplementation usually just consists of calling the
same hash functions with different parameters. After all, we don't
really care what we are hashing, all we need to know is the location
and size of the key, so one good hash function is really all you need.

> -- 
> Darren New 
> San Diego, CA, USA (PST). Cryptokeys on demand.
>    The 90/10 rule of toothpaste: the last 10% of 
>          the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Ole-Hjalmar Kristensen wrote:
> I agree, not the thing you would want in a hard real time
> safety-critical system. Buf for soft real time, non saftey critical
> systems it's good enough. And it really can make a difference in
> throughput in for instance applications like relational algebra
> processing.

Well, there's also the question of the malicious user, who intentionally
inserts a lot of items that hash to the same value (over a web
interface, say) and thereby breaks something.
 
> Yes, although the reimplementation usually just consists of calling the
> same hash functions with different parameters. After all, we don't
> really care what we are hashing, all we need to know is the location
> and size of the key, so one good hash function is really all you need.

Hmmm... So if you have keys you can't break up? I mean, I'm not sure how
you would make a generic hash function that would hash any record, or
any array, or any private type, or ...

In C it's easy - you cast the pointer to a char* and hash, and hope
there's no randomly-initialized padding in the middle. I don't know how
to do this in Ada, tho - it would seem that every private type (for
example) would have to implement its own hash function. Wouldn't it?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[John English]

Marin David Condic wrote:
> 
> What do other languages provide with maps? MFC? STL? I'll bet you can get
> items sorted on the key.

A common approach is to provide a way to get a list of keys, which
you can then sort as you wish before using it to extract elements,
rather than building all the same old sorting functionality into
yet another data structure.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Jeffrey Carter wrote:
> Skip lists are probabilistically balanced. Average search times are
> O(log N). The good news is that even a halfway decent random-number
> generator ensures decent balancing if N is large enough to matter. See
> figure 8 in
> 
> ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf

Excellent reference. But I think there's still a number of advantages to
red-black trees over skip lists. I'm interested in hearing why you think
skip-lists are superior.

Here's my "Top Ten" list...

10) A malicious user could make even the best skip list perform really
poorly. In these days of internet break-ins, this could make a
difference. All the user has to do is know what the random number
generator generates. The user can either delete all the non-level-1
nodes, or run a copy of the PRNG and insert nodes whose value equals the
height of the node. In the latter case, you'd wind up with a string of 1
values, all at height 1, then a string of 2 values all at height 2, then
a string of 3 values all at height 3, etc.

9) The skip-lists look like they take more space. In addition to an
average of 2 pointers for each node, you also have the 'Range value.
Since tree nodes are fixed size, I would think a decent compiler
wouldn't bother to actually encode the size of the node in each node.

8) The skip-lists look like they take more space, part deux. If I do
"insert 1, insert 2, delete 1, insert 3, insert 4, delete 3, insert 5,
insert 6, delete 5, ..." 100 times on a tree, I'm going to use up 100
nodes of memory and have one free left over. With a skip-list, since the
nodes are different sizes, I'll likely have some additional memory
fragmentation. 

On the other hand, I think after re-reading some red-black and AVL
algorithms again, I'm mistaken about the "more space" bit. The problems
with a red-black tree are...

7) The balanced trees require you to carry balance information around in
the nodes - the red-black tree carries the color and the AVL trees carry
the balance.

6) The tree has no obvious way of going from a node to the next node,
making an iterator complex to implement. That is, it's easy to traverse
a tree in order recursively, but somewhat more difficult to traverse a
tree iteratively (in the sense used in Grace.Lists). In a skip-list,
each node points to the next node. On the other hand, I don't see any
obvious way, given an arbitrary node, to do an insert/delete on a
skip-list without repeating the search.

5) The algorithms are admittedly a little more complicated, with
probably a few more assignments of pointers than with skip-lists.
However, the algorithms are well-known, widely available, and only need
to be implemented once, so I don't see the complexity factor as very
important. It might be a touch slower tho, with maybe 8 or 10 pointer
assignments where a skip-list doing the same thing might have 2 or 4.

+=+=+

Overall, it might be that the best implementation is a doubly-linked
list with either a tree or a skip-list on top. That is, either a
skip-list where each node also includes back pointers to the previous
nodes, or a red-black or an AVL tree where each node includes pointers
to the previous and next value. This way, there's an very similar
interface to the List package, except that "insert" takes both a key and
a value, and instantiation requires the "<" operator. You could build it
as essentially a doubly-linked list that keeps itself in order
efficiently. 

I don't see any compelling value of using a skip-list over using a tree,
or vica versa. Perhaps providing both implementations would be of
interest, proving that the interface is sufficiently generic that the
implementation can be completely changed under the covers. This would
allow the real-time folks to get deterministic behavior when they wanted
at the expense of better probabilistic performance.

I'd be interested in hearing what the advantages of the skip-list are
over trees, other than slightly simpler code. Is it just the
performance? (Which is, of course, important.)

> "Although a skip list may not be balanced, the probability of a skip
> list being substantially unbalanced is insignificant.

I think he means a *random* skip-list. The probability is insignificant
if you don't actually *try* to unbalance it.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

Darren New <dnew@san.rr.com> writes:

> Ole-Hjalmar Kristensen wrote:
> > I agree, not the thing you would want in a hard real time
> > safety-critical system. Buf for soft real time, non saftey critical
> > systems it's good enough. And it really can make a difference in
> > throughput in for instance applications like relational algebra
> > processing.
> 
> Well, there's also the question of the malicious user, who intentionally
> inserts a lot of items that hash to the same value (over a web
> interface, say) and thereby breaks something.
>  

OK, but how does this malicious user manage to do this when I'm using
a hash function which on average changes half the bits of its output
for any single bit change in its input? I'm not saying it's
impossible, but it seems pretty far-fetched to me. Of course, if he's
got the source to my program and is good at inverting hash functions
he can do it.  In particular (pardon the C code, but as you say
yourself, in C it's easy), how do you construct your keys so they all
hash to the same value given this particular hash function? :

/* The mixing step */
#define mix(a,b,c) \
{ \
  a=a-b;  a=a-c;  a=a^(c>>13); \
  b=b-c;  b=b-a;  b=b^(a<<8);  \
  c=c-a;  c=c-b;  c=c^(b>>13); \
  a=a-b;  a=a-c;  a=a^(c>>12); \
  b=b-c;  b=b-a;  b=b^(a<<16); \
  c=c-a;  c=c-b;  c=c^(b>>5);  \
  a=a-b;  a=a-c;  a=a^(c>>3);  \
  b=b-c;  b=b-a;  b=b^(a<<10); \
  c=c-a;  c=c-b;  c=c^(b>>15); \
}

/* The whole new hash function */
inline u4 burtle( 
		 register u1 *k,      /* the key */
		 u4           length, /* the length of the key in bytes */
		 u4           initval /* the previous hash, or an arbitrary value */
		 )
{
  register u4 a,b,c;  /* the internal state */
  u4          len;    /* how many key bytes still need mixing */

  /* Set up the internal state */
  len = length;
  a = b = 0x9e3779b9;  /* the golden ratio; an arbitrary value */
  c = initval;         /* variable initialization of internal state */

  /*---------------------------------------- handle most of the key */
  while (len >= 12)
    {
      a=a+(k[0]+((u4)k[1]<<8)+((u4)k[2]<<16) +((u4)k[3]<<24));
      b=b+(k[4]+((u4)k[5]<<8)+((u4)k[6]<<16) +((u4)k[7]<<24));
      c=c+(k[8]+((u4)k[9]<<8)+((u4)k[10]<<16)+((u4)k[11]<<24));
      mix(a,b,c);
      k = k+12; len = len-12;
    }

  /*------------------------------------- handle the last 11 bytes */
  c = c+length;
  switch(len)              /* all the case statements fall through */
    {
    case 11: c=c+((u4)k[10]<<24);
    case 10: c=c+((u4)k[9]<<16);
    case 9 : c=c+((u4)k[8]<<8);
      /* the first byte of c is reserved for the length */
    case 8 : b=b+((u4)k[7]<<24);
    case 7 : b=b+((u4)k[6]<<16);
    case 6 : b=b+((u4)k[5]<<8);
    case 5 : b=b+k[4];
    case 4 : a=a+((u4)k[3]<<24);
    case 3 : a=a+((u4)k[2]<<16);
    case 2 : a=a+((u4)k[1]<<8);
    case 1 : a=a+k[0];
      /* case 0: nothing left to add */
    }
  mix(a,b,c);
  return c;
}


> > Yes, although the reimplementation usually just consists of calling the
> > same hash functions with different parameters. After all, we don't
> > really care what we are hashing, all we need to know is the location
> > and size of the key, so one good hash function is really all you need.
> 
> Hmmm... So if you have keys you can't break up? I mean, I'm not sure how
> you would make a generic hash function that would hash any record, or
> any array, or any private type, or ...
> 

Sure, in that case you will have to call the hash function for each
part of the key.  But in that case, wouldn't you also need to define a
comparision operator if you used a tree?

> In C it's easy - you cast the pointer to a char* and hash, and hope
> there's no randomly-initialized padding in the middle. I don't know

In Ada, you can get rid of any packing if you insist, at least more
portably than in C.

> how to do this in Ada, tho - it would seem that every private type
> (for example) would have to implement its own hash
> function. Wouldn't it?
> 

Hmm. What's wrong with having a generic hash function which you
instantiate for your private type? Provided that you can read the key
as an array of bytes, it should work the same in both C and Ada. I
know this is low-level and dirty, but for hashing, I think it's a
reasonable approach. 

> -- 
> Darren New 
> San Diego, CA, USA (PST). Cryptokeys on demand.
>    The 90/10 rule of toothpaste: the last 10% of 
>          the tube lasts as long as the first 90%.

BTW., I'm not arguing for hash tables everywhere. I'm just saying
there are some appliactions where O(log N) just isn't good enough, and that
hash tables *in practice* is what you need.
 

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

The important thing being that if you can store elements in a map based on a
key for which you have an operation "<" that makes sense, you will in all
likelihood want to scan that map such that you retrieve the elements in
ascending or descending order. How you get there doesn't matter much to me,
except that it should be relatively simple and obvious. I could convince
myself that probably 90% of the uses for a map in practical programming will
want to retrieve the data this way from time to time and designing a package
that precludes (or makes difficult/expensive) this possibility would be A
Bad Thing.

I'd suggest that it should be designed to cover the most general case and
leave a hash-table implementation as an alternate/separate structure.
(Grace.Lists, Grace.Maps, Grace.Hash_Tables, ...?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"John English" <je@brighton.ac.uk> wrote in message
news:3CC6BF2E.51BEC7E1@brighton.ac.uk...
>
> A common approach is to provide a way to get a list of keys, which
> you can then sort as you wish before using it to extract elements,
> rather than building all the same old sorting functionality into
> yet another data structure.
>

Re: Wish List : Ada95 to FOX

[Marin David Condic]

I consider callbacks a butt-ugly solution to anything. :-) I'd much rather
see some kind of messaging or events or whatever rather than have
subprograms lying around with no obvious clue as to what it is that is
calling them or when.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3CC5F5B0.DBC6A6B8@boeing.com...
>
> I consider callbacks themselves a sore point. Callbacks are a hack to
> handle the inherent concurrency of a windowing system in a sequential
> language such as C. The natural approach is to associate a concurrent
> blocking queue of events with each window; the application has a task
> per window obtaining events from this queue and deciding what to do with
> them.
>

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Ole-Hjalmar Kristensen wrote:
> OK, but how does this malicious user manage to do this when I'm using
> a hash function which on average changes half the bits of its output
> for any single bit change in its input? 

It's called the birthday paradox. You hash enough values, you're going
to find collisions. 

> I'm not saying it's
> impossible, but it seems pretty far-fetched to me.

It seemed far-fetched to me that someone would disassemble IIS or XP in
order to find unchecked buffer overflows, but they managed within days
of the release of the software, too.

> Of course, if he's got the source to my program 

I kind of thought that was the point of this exercise - to make source,
yes?

>and is good at inverting hash functions
> he can do it.  In particular (pardon the C code, but as you say
> yourself, in C it's easy), how do you construct your keys so they all
> hash to the same value given this particular hash function? :

Well, it's hard to read when it isn't complete C, but assuming "u4" is
an unsigned integer four bytes long, it's pretty easy.

/* Crappy pseudo-C... This should find about 2**16 collisions. */
for (i = 0; i < 2**32; i++) {
  if (burtle(i, ...) == 27) {
    printf("Found one that hashes to 27: %ul\n", i);
  }
}

> > Hmmm... So if you have keys you can't break up? I mean, I'm not sure how
> > you would make a generic hash function that would hash any record, or
> > any array, or any private type, or ...
> >
> 
> Sure, in that case you will have to call the hash function for each
> part of the key.  But in that case, wouldn't you also need to define a
> comparision operator if you used a tree?

I think there are many more private types that can be ordered than those
that can be hashed, in Ada at least. Most of the fundamental types in
Ada come with ordering operators defined, while few come with hashes
defined. (In Java, "hash" is defined everywhere, for just this reason.)
 
> In Ada, you can get rid of any packing if you insist, at least more
> portably than in C.

Well, yeah, but I don't think you'd want to.
 
> Hmm. What's wrong with having a generic hash function which you
> instantiate for your private type? Provided that you can read the key
> as an array of bytes, it should work the same in both C and Ada.

Well, yeah, but I dont think you can. Doing so would mean that you're
dependent on the packing of the structure, for example. If your private
type contains pointers or gaps in the structure or fields that don't
participate in an equality comparison anything like that, your hash is
going to fail. Remember that you not only have to generate a hash, but
that the hash has to be the same for all values that are considered
equal. If you have a string implementation that has a length count but
leaves junk at the end of the array of characters, a hash based on the
physical contents of the record isn't going to work.

> BTW., I'm not arguing for hash tables everywhere. I'm just saying
> there are some appliactions where O(log N) just isn't good enough, and that
> hash tables *in practice* is what you need.

Agreed. There are many applications where you can control the kind of
key and almost never want the results softed, in which hash tables are
perfect. Symbol tables leap to mind. 

Perhaps the hashtable would be the third data structure, after sorted
maps. :-) Hashtables are actually pretty simple to do, if you make the
user supply the hash value and don't make keys or values limited. A hash
table with implementations specifically having keys being the various
string types would probably satisfy 90% of the need for hash tables, as
well. There aren't a whole lot of operations on a hash table, so it's
pretty easy to put one together, methinks.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Darren New wrote:
> /* Crappy pseudo-C... This should find about 2**16 collisions. */
> for (i = 0; i < 2**32; i++) {
>   if (burtle(i, ...) == 27) {
>     printf("Found one that hashes to 27: %ul\n", i);
>   }
> }

Actually, I take that back. That was dumb. It won't find nearly that
many collisions, if "burtle" is returning a 32-bit integer.

But the point is severalfold:

1) I *can* find collisions, regardless of the code that implements the
hash,

2) Using a cryptographically secure hash with a large range is probably
overkill for a basic hash library, so at least the vulnerability should
be thought about,

3) if you can insert multiple records with the same key, you can wind up
with a system that hashes lots of different stuff to the same value.

4) Hashes are nevertheless an extremely useful library component.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Stephen Leake]

Darren New <dnew@san.rr.com> writes:

> Stephen Leake wrote:
> > > point in sorting the values. Of course, if you ever need it sorted,
> > > chances are you want to keep it sorted. But AFAIK, none of the scripting
> > > languages (Tcl, Perl, Python) have sorts for their
> > > internally-implemented maps.
> > 
> > And they all live with O (n) time? amazing ! :).
> 
> No. Hash tables aren't O(n) except in the worst case. In the best case,
> they're O(1). 

But if I just declare a map in Python, there's no way it's guaranteed
to be best case. So I think you are saying "yes, they live with the
O(n) worst case, and hope for the O(1) best case, and take whatever
they actually get".

Hmm. Maybe there is a way to tell Python what the hash table size
should be, and what hash function to use? Then I can get O(1). I
confess to never having used either a Perl or Python map.

> When you'd doing things like looking up variables, it's pretty easy
> to pay the sort time if you want to iterate over all variable names
> in sorted order, compared to getting close to O(1) when referencing
> a variable instead of O(logN) each time. Think "symbol table".

Well, the question is, is a "typical" map in Perl or Python "close to"
O(n), or "close to" O(1)? Anybody have any data?

If I use a red-black tree, I _know_ it is O(log n).

-- 
-- Stephe

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

This is just a guess based on years of experience building apps - not any
sort of statistical survey. Most of the time that you are likely to use maps
in a garden variety program, they will be used to store a relatively small
amount of data. A few dozen directory names with a few hundred files under
them, might be one example. A few hundred employees indexed by SSN, might be
another. *Most* of the time, I'd suspect you're dealing with some number
less than 1000. Probably, with today's hardware, you'd not notice the
difference if the performance were on the order of O(n!) :-) So the question
is: "Is it worth arguing over the relative performance between a few
alternate implementations?" My guess is that the best solution is to pick
one that will handle the general cases needed for maps reasonably well and
that will be easy to implement and move on.

I certainly have no objection to providing alternate structures that offer
different performance benefits, but the important thing is to get a general
solution available that will work well enough for most of the programmer's
needs. (I'd see those as being "easy to use" and "works reliably", rather
than "must have optimal performance".)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uhem1m47l.fsf@gsfc.nasa.gov...
>
> But if I just declare a map in Python, there's no way it's guaranteed
> to be best case. So I think you are saying "yes, they live with the
> O(n) worst case, and hope for the O(1) best case, and take whatever
> they actually get".
>
> Hmm. Maybe there is a way to tell Python what the hash table size
> should be, and what hash function to use? Then I can get O(1). I
> confess to never having used either a Perl or Python map.
>
> > When you'd doing things like looking up variables, it's pretty easy
> > to pay the sort time if you want to iterate over all variable names
> > in sorted order, compared to getting close to O(1) when referencing
> > a variable instead of O(logN) each time. Think "symbol table".
>
> Well, the question is, is a "typical" map in Perl or Python "close to"
> O(n), or "close to" O(1)? Anybody have any data?
>
> If I use a red-black tree, I _know_ it is O(log n).
>
> --
> -- Stephe

Re: Grace and Maps (was Re: Development process in the Ada community)

[Jeffrey Carter]

		 <3CC48F34.5A474E0F@boeing.com> <3CC4C800.10107@telepath.com> <3CC5F26A.6F74BD0F@boeing.com> <3CC6C8DA.162604F7@san.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Darren New wrote:
> 
> Jeffrey Carter wrote:
> > Skip lists are probabilistically balanced. Average search times are
> > O(log N). The good news is that even a halfway decent random-number
> > generator ensures decent balancing if N is large enough to matter. See
> > figure 8 in
> >
> > ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf

I was a bit imprecise in my language here. The quality of the generator
is not very important if insertions are fairly random. If insertions
tend to be ordered, a poor generator can degrade performance. With a
decent generator, such as the Ada.Float_Random that comes with GNAT, the
order of insertions is immaterial.

> 
> Excellent reference. But I think there's still a number of advantages to
> red-black trees over skip lists. I'm interested in hearing why you think
> skip-lists are superior.

This is the paper in CACM in which Pugh introduced skip lists. Those
were the good old days. You don't find useful algorithms in CACM anymore
...

> 
> Here's my "Top Ten" list...

Looks like 6 to me, with three of them being reasons skip lists are
better :)

> 
> 10) A malicious user could make even the best skip list perform really
> poorly. In these days of internet break-ins, this could make a
> difference. All the user has to do is know what the random number
> generator generates. The user can either delete all the non-level-1
> nodes, or run a copy of the PRNG and insert nodes whose value equals the
> height of the node. In the latter case, you'd wind up with a string of 1
> values, all at height 1, then a string of 2 values all at height 2, then
> a string of 3 values all at height 3, etc.

This is difficult to do if, as one would expect, the random number
generator is seeded using the time. Not impossible, I agree. Is it worth
worrying about in the general case? For small N, the difference in time
is negligible; for large N, the best you can achieve is to slow the
system down. I don't expect generic components to be suitable for secure
applications.

> 
> 9) The skip-lists look like they take more space. In addition to an
> average of 2 pointers for each node, you also have the 'Range value.
> Since tree nodes are fixed size, I would think a decent compiler
> wouldn't bother to actually encode the size of the node in each node.

With the recommended p=0.25, they take an average of 1.333
pointers/node. They have a Height component lacking in trees, but
balanced trees tend to have balance information in the nodes. You've
addressed this below. Some argue that skip lists take less space, but I
consider them equivalent.

> 
> 8) The skip-lists look like they take more space, part deux. If I do
> "insert 1, insert 2, delete 1, insert 3, insert 4, delete 3, insert 5,
> insert 6, delete 5, ..." 100 times on a tree, I'm going to use up 100
> nodes of memory and have one free left over. With a skip-list, since the
> nodes are different sizes, I'll likely have some additional memory
> fragmentation.

True for an unbounded implementation. You could make all the nodes the
same size, if you don't mind the wasted space :) Naturally, a bounded
implementation avoids fragmentation.

> 6) The tree has no obvious way of going from a node to the next node,
> making an iterator complex to implement. That is, it's easy to traverse
> a tree in order recursively, but somewhat more difficult to traverse a
> tree iteratively (in the sense used in Grace.Lists). In a skip-list,
> each node points to the next node. On the other hand, I don't see any
> obvious way, given an arbitrary node, to do an insert/delete on a
> skip-list without repeating the search.

For a general purpose component, I don't see trees offering
insert/delete without a search, either. If you're going to keep state
information about the last search and use it to optimize insert/delete,
you could do that for any implementation.

> 
> 5) The algorithms are admittedly a little more complicated, with
> probably a few more assignments of pointers than with skip-lists.
> However, the algorithms are well-known, widely available, and only need
> to be implemented once, so I don't see the complexity factor as very
> important. It might be a touch slower tho, with maybe 8 or 10 pointer
> assignments where a skip-list doing the same thing might have 2 or 4.

A *little* more complicated? I've seen balanced tree deletion algorithms
in texts that run to 4 pages; compare that to the 20 lines or so for a
skip list.

As for timing, Pugh compares the CPU time of skip lists against several
kinds of balanced trees. Skip lists are about as fast or faster than the
trees for searching, and faster than the trees for insert/delete.
http://www.csihq.com/analysis/skiplist.pdf compares insertion times in
skip lists to B-trees (N=50,000 to 950,000 in 50,000 steps) and found
that Unix system time increased exponentially for N>=600,000, while it
increased linearly for skip lists, indicating that large B-trees did
significantly. Considering only Unix CPU time, skip lists were 5-10
times as fast as B-trees; an order of magnitude is not a "touch" slower.

> I'd be interested in hearing what the advantages of the skip-list are
> over trees, other than slightly simpler code. Is it just the
> performance? (Which is, of course, important.)

Between the significantly simpler algorithms, which are more likely to
be implemented correctly, and the observed performance advantages of
skip lists, the choice seems obvious.

-- 
Jeffrey Carter

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Stephen Leake wrote:
> 
> Darren New <dnew@san.rr.com> writes:
> 
> > Stephen Leake wrote:
> > > > point in sorting the values. Of course, if you ever need it sorted,
> > > > chances are you want to keep it sorted. But AFAIK, none of the scripting
> > > > languages (Tcl, Perl, Python) have sorts for their
> > > > internally-implemented maps.
> > >
> > > And they all live with O (n) time? amazing ! :).
> >
> > No. Hash tables aren't O(n) except in the worst case. In the best case,
> > they're O(1).
> 
> But if I just declare a map in Python, there's no way it's guaranteed
> to be best case. So I think you are saying "yes, they live with the
> O(n) worst case, and hope for the O(1) best case, and take whatever
> they actually get".

Well, if you want to look at it like this, yes. But it's O(N) with a
really tiny constant multiplier. I'd also expect that the hash tables
get grown as the chains get long.

> > When you'd doing things like looking up variables, it's pretty easy
> > to pay the sort time if you want to iterate over all variable names
> > in sorted order, compared to getting close to O(1) when referencing
> > a variable instead of O(logN) each time. Think "symbol table".
> 
> Well, the question is, is a "typical" map in Perl or Python "close to"
> O(n), or "close to" O(1)? Anybody have any data?

Well, honestly, a hash table of any fixed size is technically O(N), but
divided by the number of buckets in the hash table. If the number of
buckets is sufficiently larger than the number of entries, you have O(1)
for practical purposes. Nobody really stores unlimited numbers of items
in a hash. As far as the rehashing goes, you have to touch each item
whenever you rearrange the buckets, to put each in the right bucket, so
that's probably at least O(N) also. 

So yes, my guess is that hashes are O(N) with a really, really small
multiplier, small enough to make O(lg N) operations not worthwhile.
 
> If I use a red-black tree, I _know_ it is O(log n).

O(N)/1000 < O(log N) for sufficiently small N. I think that's the trick.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Jeffrey Carter wrote:
> Darren New wrote:
> >
> > Jeffrey Carter wrote:
> > > Skip lists are probabilistically balanced. Average search times are
> > > O(log N). The good news is that even a halfway decent random-number
> > > generator ensures decent balancing if N is large enough to matter. See
> > > figure 8 in
> > >
> > > ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf
> 
> I was a bit imprecise in my language here. The quality of the generator
> is not very important if insertions are fairly random. If insertions
> tend to be ordered, a poor generator can degrade performance. With a
> decent generator, such as the Ada.Float_Random that comes with GNAT, the
> order of insertions is immaterial.

FWIW, I didn't write this part, in spite of quoting anomolies. :-)

> > Here's my "Top Ten" list...
> 
> Looks like 6 to me, with three of them being reasons skip lists are
> better :)

<foghorn_leghorn> It's a joke, son. A joke, Ah say. </foghorn_leghorn>

> I don't expect generic components to be suitable for secure
> applications.

I would expect generic components to be sufficiently secure to allow
them to be used as (say) part of a CGI script or something. But I think
as long as the potential pitfalls of a worst-case performance are
documented along with how to get around them, it's cool.

> With the recommended p=0.25, they take an average of 1.333
> pointers/node.

This would degrade performance, tho, yes? An average of two extra
link-follows per search? Or am I misunderstanding? (Maybe "p" should be
a parameter? Nah, too messy.)

> True for an unbounded implementation. You could make all the nodes the
> same size, if you don't mind the wasted space :) Naturally, a bounded
> implementation avoids fragmentation.

And I guess with a bounded implementation, you know the right maximum
height too.

> For a general purpose component, I don't see trees offering
> insert/delete without a search, either.

I think you can do this, since Red-Black trees keep a pointer to the
parent. I'm not sure tho, and yes, another friend explained how you'd go
about keeping enough info in a skip-list iterator (basically, N
backpointers where N is the height of the head) to do the inserts and
deletes without the search.

> A *little* more complicated? I've seen balanced tree deletion algorithms
> in texts that run to 4 pages;

Nah.
http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/red_black.html
Not *that* complicated. I'll admit it's not *obvious*, but once given,
it's not *complicated*. On the other hand, skip-list implementations are
*obvious*, but whether they're efficient isn't obvious. Of course, the
paper shows they are.

> Between the significantly simpler algorithms, which are more likely to
> be implemented correctly, and the observed performance advantages of
> skip lists, the choice seems obvious.

Fair enough. I'm convinced. :-) Add a backpointer to each node as well,
and you've got a doubly-linked list that you can search really, really
fast. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[David Bolen]

Jean-Marc Bourguet <jm@bourguet.org> writes:

> David Bolen <db3l@fitlinxx.com> writes:
(...)
> > I believe the primary difference is a better bound on the number of
> > operations to perform to re-balance the tree.  In an AVL tree you may
> > need to perform lg n rotations, whereas in an red-black tree you have
> > a maximum of 2 rotations for insertion, and 3 for deletion.
>
> Red-Black trees are a special case of B-Trees (consider a black node
> with its red child and you have a B-Tree bucket).  So the maximum
> number of operations needed on insertion and deletioon is of the order
> of log n.

Yes, total operations for insertion/deletion is lg n - but the
question was the difference between red-black and AVL (both of which
are balanced trees with O(lg n)), and the difference there is how many
actual rotations you perform while re-balancing the tree.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: Grace and Maps (was Re: Development process in the Ada community)

[Randy Brukardt]

Ole-Hjalmar Kristensen wrote in message
<7vbsc9w367.fsf@vlinux.voxelvision.no>...
>Darren New <dnew@san.rr.com> writes:

>> how to do this in Ada, tho - it would seem that every private type
>> (for example) would have to implement its own hash
>> function. Wouldn't it?
>
>Hmm. What's wrong with having a generic hash function which you
>instantiate for your private type? Provided that you can read the key
>as an array of bytes, it should work the same in both C and Ada. I
>know this is low-level and dirty, but for hashing, I think it's a
>reasonable approach.


Actually, it doesn't even need to be generic. It is easy to write a
hashing algorithm that works with any type that can be streamed (use
streaming operations to convert to an array of stream elements, hash
that) -- I've seen two such implementations in the last few days.

Using streams to do this has the advantage of eliminating packing and
implementation-defined components from concern. It does limit the
applicability of the package to non-limited keys, but that seems to be
an acceptable limitation (do you really need to hash tasks??).

              Randy.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

Darren New <dnew@san.rr.com> writes:

> Ole-Hjalmar Kristensen wrote:
> > OK, but how does this malicious user manage to do this when I'm using
> > a hash function which on average changes half the bits of its output
> > for any single bit change in its input? 
> 
> It's called the birthday paradox. You hash enough values, you're going
> to find collisions. 
> 
> > I'm not saying it's
> > impossible, but it seems pretty far-fetched to me.
> 
> It seemed far-fetched to me that someone would disassemble IIS or XP in
> order to find unchecked buffer overflows, but they managed within days
> of the release of the software, too.
> 
> > Of course, if he's got the source to my program 
> 
> I kind of thought that was the point of this exercise - to make source,
> yes?
> 
> >and is good at inverting hash functions
> > he can do it.  In particular (pardon the C code, but as you say
> > yourself, in C it's easy), how do you construct your keys so they all
> > hash to the same value given this particular hash function? :
> 
> Well, it's hard to read when it isn't complete C, but assuming "u4" is
> an unsigned integer four bytes long, it's pretty easy.
> 
> /* Crappy pseudo-C... This should find about 2**16 collisions. */
> for (i = 0; i < 2**32; i++) {
>   if (burtle(i, ...) == 27) {
>     printf("Found one that hashes to 27: %ul\n", i);
>   }
> }

I'm curious why you expect this to produce 2**16 collisions. The input
has a range of 2**32, but so has the output. Of course, when you fold
it to a shorter table, you will get collisions, so I would expect
2**16 collisions only if my hash link table has 2**16 elements.  But
yes, I see your point that a determined malicious user might make some very
long hash chains. This may or may not be fatal to the system
> 
> > > Hmmm... So if you have keys you can't break up? I mean, I'm not sure how
> > > you would make a generic hash function that would hash any record, or
> > > any array, or any private type, or ...
> > >
> > 
> > Sure, in that case you will have to call the hash function for each
> > part of the key.  But in that case, wouldn't you also need to define a
> > comparision operator if you used a tree?
> 
> I think there are many more private types that can be ordered than those
> that can be hashed, in Ada at least. Most of the fundamental types in
> Ada come with ordering operators defined, while few come with hashes
> defined. (In Java, "hash" is defined everywhere, for just this reason.)
>  
> > In Ada, you can get rid of any packing if you insist, at least more
> > portably than in C.
> 
> Well, yeah, but I don't think you'd want to.
>  
> > Hmm. What's wrong with having a generic hash function which you
> > instantiate for your private type? Provided that you can read the key
> > as an array of bytes, it should work the same in both C and Ada.
> 
> Well, yeah, but I dont think you can. Doing so would mean that you're
> dependent on the packing of the structure, for example. If your private
> type contains pointers or gaps in the structure or fields that don't
> participate in an equality comparison anything like that, your hash is
> going to fail. Remember that you not only have to generate a hash, but
> that the hash has to be the same for all values that are considered
> equal. If you have a string implementation that has a length count but
> leaves junk at the end of the array of characters, a hash based on the
> physical contents of the record isn't going to work.
> 

Neither is a predefined relational operator for the array likely to work.

According to my admittedly rusty memory, the relational operators are
only defined for scalar types and discrete array types, so I cannot
see how you can avoid defining your own for record types. So trees
have the same problem, really.

> > BTW., I'm not arguing for hash tables everywhere. I'm just saying
> > there are some appliactions where O(log N) just isn't good enough, and that
> > hash tables *in practice* is what you need.
> 
> Agreed. There are many applications where you can control the kind of
> key and almost never want the results softed, in which hash tables are
> perfect. Symbol tables leap to mind. 
> 

Also join processing, hash filters and mappings from disk blocks to
buffers to name a few examples of applications I am familiar with. But
those applications are probably so specialized that most programmers
would write their own hash anyway.

> Perhaps the hashtable would be the third data structure, after sorted
> maps. :-) Hashtables are actually pretty simple to do, if you make the
> user supply the hash value and don't make keys or values limited. A hash
> table with implementations specifically having keys being the various
> string types would probably satisfy 90% of the need for hash tables, as
> well. There aren't a whole lot of operations on a hash table, so it's
> pretty easy to put one together, methinks.
> 
> -- 
> Darren New 
> San Diego, CA, USA (PST). Cryptokeys on demand.
>    The 90/10 rule of toothpaste: the last 10% of 
>          the tube lasts as long as the first 90%.

I have usually taken the easy way out and required the existence of a
hash function for any type which is used as a key. Given that
something like the hash function above is available, the hash function
itself for a new type usually reduces to a one-liner.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

Darren New <dnew@san.rr.com> writes:

> Stephen Leake wrote:
> > 
> > Darren New <dnew@san.rr.com> writes:
> > 

<snip>

> 
> So yes, my guess is that hashes are O(N) with a really, really small
> multiplier, small enough to make O(lg N) operations not worthwhile.
>  
> > If I use a red-black tree, I _know_ it is O(log n).
> 
> O(N)/1000 < O(log N) for sufficiently small N. I think that's the trick.
> 

Yes. For time-critical operations I routinely size my hash link table
to be twice as big as the expected max number of entries...

> -- 
> Darren New 
> San Diego, CA, USA (PST). Cryptokeys on demand.
>    The 90/10 rule of toothpaste: the last 10% of 
>          the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[David Bolen]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> But if I just declare a map in Python, there's no way it's guaranteed
> to be best case. So I think you are saying "yes, they live with the
> O(n) worst case, and hope for the O(1) best case, and take whatever
> they actually get".

Yes.  But it's also that a good deal of implementation effort has gone
into making the odds of the O(1) case much better than that of the
O(n) case.

> Hmm. Maybe there is a way to tell Python what the hash table size
> should be, and what hash function to use? Then I can get O(1). I
> confess to never having used either a Perl or Python map.

Python automatically maintains (grows) the hash table so that it is no
more than 2/3 full.  It is limited to a 32-bit key, and is
open-addressed, not chained.  Any "hashable" object in Python may be
used as a dictionary key - objects may implement their own hashing
function if they prefer.  The default hashing function for user
created objects is to hash to the object's location in memory.  The
built-in types tend to have type-specific tuned hashing functions.
The source indicates the algorithm was originally based on Algorithm D
from Knuth Vol. 3, Sec. 6.4.

> Well, the question is, is a "typical" map in Perl or Python "close to"
> O(n), or "close to" O(1)? Anybody have any data?

In Python it's expected to be average O(1), and only extremely rarely
O(n) (e.g., if everything hashes to the same value).  But formally the
operations are still O(n) - a lot of tuning over the course of
Python's evolution just makes the typical case much closer to best
than worst.  In particular, Python's hash table does not depend on the
randomness of the hashing function, and in fact works very well for
very regular (even monotonically increasing) hash functions.

There are some newsgroup posts over the years (look for stuff by Tim
Peters in particular), but I don't know of a formal algorithm analysis
online anywhere.  The dictionary object source itself has quite a bit
of information:

   http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Objects/dictobject.c?rev=HEAD

(Hoping this isn't too off-topic for an Ada group)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

<snip>

> As for timing, Pugh compares the CPU time of skip lists against several
> kinds of balanced trees. Skip lists are about as fast or faster than the
> trees for searching, and faster than the trees for insert/delete.
> http://www.csihq.com/analysis/skiplist.pdf compares insertion times in
> skip lists to B-trees (N=50,000 to 950,000 in 50,000 steps) and found
> that Unix system time increased exponentially for N>=600,000, while it
> increased linearly for skip lists, indicating that large B-trees did
> significantly. Considering only Unix CPU time, skip lists were 5-10
> times as fast as B-trees; an order of magnitude is not a "touch" slower.
> 
This benchmark is a bit strange, in that it compares the performance
of a structure specifically tuned for use on disk (if indeed the
B-tree it refers to is the same as defined by Bayer & McCreight) with
the skip list, which is intented for in-memory use.

Do you know if anyone has bechmarked or analysed the performance of a
skip list if it were to reside on disk? I'm not arguing against skip
lists, just curious if it might be a viable alternative to B-trees for
disk based storage.

> > I'd be interested in hearing what the advantages of the skip-list are
> > over trees, other than slightly simpler code. Is it just the
> > performance? (Which is, of course, important.)
> 
> Between the significantly simpler algorithms, which are more likely to
> be implemented correctly, and the observed performance advantages of
> skip lists, the choice seems obvious.
> 
> -- 
> Jeffrey Carter

Re: GPL and the big picture (was Re: Development process in the Ada community)

[Randy Brukardt]

David Botton wrote in message ...
>----- Original Message -----
>From: "Randy Brukardt" <randy@rrsoftware.com>


>> In any case, I have to wonder why you decided to build something from
>> scratch rather than building on top of Windex, which already existed
and
>> had the appropriate license. My guess, is that you fell into the same
>> trap that many of us do: "I can do better than that...". Such a waste
of
>> effort.
>
>GWindows took a different direction than both CLAW and Windex. (*
Several pages
>of the advantages of GWindows omitted *)

I think you have made my point for me. It's pretty clear that you
thought you could do better than Claw (and still do).

I would argue that most of the differences between Claw and GWindows are
just that: differences, not advantages. I thought that when I first read
your overviews of GWindows (a long time ago...), and I still think that.
Clearly, you don't know how to use Claw as well as I do (who does?). But
I don't think a line-by-line rebuttal serves much a purpose here; it
makes more sense to spend the time on something productive.

>Can you give a time table (if there is one) for the full version of
CLAW to
>become GMGPL. Perhaps there is some future in merging with CLAW, but
that is
>to be seen.


I haven't thought seriously about that recently. The Introductory
version had a fairly similar license to the GPL anyway (less restrictive
for non-commercial use, in fact), so that wasn't a large leap. The full
Claw is a larger leap. Certainly, the next version of the Introductory
version will include more stuff (suggestions of items to include are
welcome), which will have the effect of bringing more of Claw under the
GMGPL.

Let's talk about this some more off-line, OK?

>Making it these days (financially speaking) with the GPL requires the
same
>skills that all true Entrepreneurs must have, broad vision and self
>discipline. Start thinking now about the new models of business that
use
>open lic. schemes, for tomorrow it may just be too late.


I've been doing that for two years. So far, the only thing that seems to
make sense is to convince Robert to hire me at ACT. :-)

                    Randy.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> writes:

<snip>

> 
> Neither is a predefined relational operator for the array likely to work.
> 
> According to my admittedly rusty memory, the relational operators are

Should have been *ordering operators*, of course.

> only defined for scalar types and discrete array types, so I cannot
> see how you can avoid defining your own for record types. So trees
> have the same problem, really.
> 

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Ole-Hjalmar Kristensen wrote in message
> <7vbsc9w367.fsf@vlinux.voxelvision.no>...
> >Darren New <dnew@san.rr.com> writes:
> 
> >> how to do this in Ada, tho - it would seem that every private type
> >> (for example) would have to implement its own hash
> >> function. Wouldn't it?
> >
> >Hmm. What's wrong with having a generic hash function which you
> >instantiate for your private type? Provided that you can read the key
> >as an array of bytes, it should work the same in both C and Ada. I
> >know this is low-level and dirty, but for hashing, I think it's a
> >reasonable approach.
> 
> 
> Actually, it doesn't even need to be generic. It is easy to write a
> hashing algorithm that works with any type that can be streamed (use
> streaming operations to convert to an array of stream elements, hash
> that) -- I've seen two such implementations in the last few days.
> 
> Using streams to do this has the advantage of eliminating packing and
> implementation-defined components from concern. It does limit the
> applicability of the package to non-limited keys, but that seems to be
> an acceptable limitation (do you really need to hash tasks??).
> 
>               Randy.

Excellent idea, unless there is much overhead involved in the
streaming operation. But I suspect it's probably OK.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

> Excellent idea, unless there is much overhead involved in the
> streaming operation. But I suspect it's probably OK.

That's probably a good way to work it if you don't have a user-defined
hash function, or if the user doesn't want to create one. Since you have
to hash the key on every lookup, this would seem to be a lot of overhead
if you can avoid it.

And of course you still have to ensure that two "equal" keys hash to
equal values, implying that two equal keys have to stream out to the
same sequence of bytes.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Stephen Leake]

David Bolen <db3l@fitlinxx.com> writes:

Ok, thanks. That answers my questions. Python maps (hash tables)
should in general be close to O (1).

-- 
-- Stephe

Re: Grace and Maps (was Re: Development process in the Ada community)

[Jeffrey Carter]

Darren New wrote:
> 
> Jeffrey Carter wrote:
> > With the recommended p=0.25, they take an average of 1.333
> > pointers/node.
> 
> This would degrade performance, tho, yes? An average of two extra
> link-follows per search? Or am I misunderstanding? (Maybe "p" should be
> a parameter? Nah, too messy.)

It increases the probability that a search path is longer than expected
compared to p=0.5. But with N=256 and p=0.25, the probability of a
search path of 3*log N (24) is about 0.001.

> > A *little* more complicated? I've seen balanced tree deletion algorithms
> > in texts that run to 4 pages;
> 
> Nah.
> http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/red_black.html
> Not *that* complicated. I'll admit it's not *obvious*, but once given,
> it's not *complicated*. On the other hand, skip-list implementations are
> *obvious*, but whether they're efficient isn't obvious. Of course, the
> paper shows they are.

Let's see, the else part is just as long as the if part, so the insert
is really nearly twice as long as shown, 1.5-2 pages in a text. Full
code for both rotations is another page, and your basic tree insertion
is another page, so that's getting on to 4 pages.

At least it's not recursive. One of the advantages of skip lists is that
there's really only 1 way to implement insert and delete. With most
balanced trees the easier way is with recursion, and eliminating that
recursion is complicated enough that most people don't try.

> Fair enough. I'm convinced. :-) Add a backpointer to each node as well,
> and you've got a doubly-linked list that you can search really, really
> fast. :-)

But now I'm starting to like red-black trees ... :)

-- 
Jeffrey Carter

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Jeffrey Carter wrote:
> Let's see, the else part is just as long as the if part, 

Ah. I hadn't realized it isn't complete. Nevertheless, you still only
have to code it once. :-)

> But now I'm starting to like red-black trees ... :)

Well, B-trees are really the way to go for sorted lists on disk. I've
never seen them implemented any other way. (Not that they haven't been,
I've just never seen it. If someone has, let me know. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Brian Gaffney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9p98h$8hn$1@nh.pace.co.uk>...
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:4519e058.0204190529.559a47ae@posting.google.com...
> >
> > I've actually been thinking along similar lines. What I'm wondering is
> > if we should keep the list package as "Lists.Unbounded", or if we
> > should just bag the whole bounded/unbounded issue and make it "Lists".
> >
> >
. . .
> 
> If we put out a Grace.Lists and a Grace.Maps, that would certainly be a
> really good start. If at a later point in time there was some kind of
> groundswell indicating that there really was a need for bounded versions,
> why couldn't we go with Grace.Lists.Bounded as an extension? The only reason
> I can think of is that it isn't consistent with Ada.Strings.

If I get your intent, I don't think this would work since Grace.List
would be generic.  (Which would be a pain if you needed Bounded
because you didn't wish to instantiate an Unbounded.)

. . .

> My inclination would be to make Grace.Lists and Grace.Maps and add children
> at a later date if we thought we needed special cases. I'd again make an
> appeal for some version of "Grace.Containers.Lists" and
> "Grace.Containers.Maps" (or some variant thereof) so that there might also
> be easy extensions like: "Grace.Linear_A", "Grace.Statistics", "Grace.XML",
> "Grace.Whatever_Else_Seems_Like_A_Good_Idea"... The names aren't real
> important to me but thinking along the line of problem domains & dividing
> things up under a subheading is something I think would be beneficial in the
> long run.

I like the Grace.Containers.Lists idea.  Perhaps the children could be
something like Grace.Containers.Bounded.Lists?  Then you could have a
Grace.Containers.Maps and Grace.Containers.Bounded.Maps, etc.  I don't
know how well this would extend to other types of containers.

Another way to get a default (assuming anyone could stand it) would be
to provide the different version (unbounded, bounded, etc.) and uses a
renames to define the 'default' type (i.e. generic package
Grace.Containers.Lists renames Grace.Containers.Unbounded.Lists).

Re: Grace and Maps (was Re: Development process in the Ada community)

[Jean-Marc Bourguet]

David Bolen <db3l@fitlinxx.com> writes:

> Jean-Marc Bourguet <jm@bourguet.org> writes:
> 
> > David Bolen <db3l@fitlinxx.com> writes:
> (...)
> > > I believe the primary difference is a better bound on the number of
> > > operations to perform to re-balance the tree.  In an AVL tree you may
> > > need to perform lg n rotations, whereas in an red-black tree you have
> > > a maximum of 2 rotations for insertion, and 3 for deletion.
> >
> > Red-Black trees are a special case of B-Trees (consider a black node
> > with its red child and you have a B-Tree bucket).  So the maximum
> > number of operations needed on insertion and deletioon is of the order
> > of log n.
> 
> Yes, total operations for insertion/deletion is lg n - but the
> question was the difference between red-black and AVL (both of which
> are balanced trees with O(lg n)), and the difference there is how many
> actual rotations you perform while re-balancing the tree.

There is an isomorphism between Red-Black trees and B-Trees (if this
is not clear, look for 2-3 and 2-3-4 trees in the litterature, if
memory serves Aho's books on algorithms is a good place) and rotation
with color change are the equivalent of bucket split/merge.  As on
insertion or deletion in a B-Tree, the number of bucket split/merge is
O(lg n) -- I think this is easier to see --, it is true also of the
number of rotation in a Red-Black trees when rebalancing after an
insertion/deletion.

Examples: insert numbers from 1 to 17 in this order in a red-black trees.
          delete the numbers from 1 to 8 in this order in the
          resulting tree.

Yours,

-- 
Jean-Marc

Re: Grace and Maps (was Re: Development process in the Ada community)

[Georg Bauhaus]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
:  My guess is that the best solution is to pick
: one that will handle the general cases needed for maps reasonably well and
: that will be easy to implement and move on.

No I don't think the general case arguement is really helpful
here.  The following is possible and desirable with the existing
libraries (probably not just in my view since it is essentially
about ADTs, isn't it): You declare you want a map, pick the right
one for your purpose at declaraion or initialisation time but
then shut that choice away, hide it from sight.  A decision to
be made per program part, essentially at (re)declaration, and
_not_ anywhere else. A la

   box: map := some_impl.create(...);

: I certainly have no objection to providing alternate structures that offer
: different performance benefits, but the important thing is to get a general
: solution available that will work well enough for most of the programmer's
: needs.

Wouldn't you want, in a language like Ada, the programmer to be
able to choose an appropriate specific map implementation and
use that for the real thing behind a declared map, and _then_
FORGET about it most of the time. No need to think about the
general solution, because you will still be writing programs AS IF
there is a general solution, namely by using an interface,
the Map interface. And if there _is_ a standardised Map
interface, implementors, producers, vendors can glue their
specific implemention(s) to that interface, and you as a
programmer will still be writing essentially portable code,
since only the few lines where a specific container that offers
the Map interface is chosen.

Reading this thread, I start wondering whether the existing 
libraries have been studied as a rich source of ideas?
For example, the most recent addition (afair), Charles,
demonstrates Red-Black trees for containers, Simon's BCs
are full of information about topics covered in this thread,
GNAT.* also adds a wealth of implemention ideas, ...

But I start sounding like I don't want to.

--georg

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

What I imagine is that a Map package spec can be designed that basically
allows for insertion, deletion & update of individual elements and contains
some kind of abstraction to walk through the elements of the map and some
means of making the data persistent. I imagine that the Version-1.0
implementation will be something that supports reasonable access time for
average use. There can be 1024 different implementations behind it that
satisfy any particular implementor's desires if some vendor or some user
wants to do something totally different for whatever reasons. The Mark 1,
Mod 0 Grace implementation just needs to be *an* implementation that works
reasonably well.

The danger is that this discussion is going to drift off expounding
endlessly on the relative merits of hash tables versus b-trees versus
who-knows-what. The mission was to come up with a specification that would
present the developer with something consistent with the spec for
Grace.Lists, yet provided the operations that would be needed & expected for
a map. It doesn't need to be perfect. It doesn't need to be optimal for all
uses. It doesn't need to be the final word on indexed data structures. It
needs to *exist* and be acceptable to a reasonably large majority of Ada
users. After that, it can be polished and polished and polished until it
shines like the sun. After that, any number of variations on a theme can be
composed to satisfy whatever different criteria someone may have. That's the
beauty of being able to create child packages or utilize inheritance - we
can create those variations easily.

Maybe this is an ongoing problem we Ada programmers have - we so much want
to find the perfect solutions that we tend to forget some important
practical concerns. Lots of competing languages *already* have libraries
full of stuff - including Maps. Those competing languages don't present
every possible implementation or even an optimal implementation. What they
present is something that an implementor will find useful *today* to get
their job done. If all Ada can promise is "One day, its going to be really,
really great!!!" developers are going to continue to choose C++, Java, etc.,
where the promise is: "Here's the leverage you need to get an app built fast
right now..."

Sorry. I'm not intending to criticize anyone in particular. Its one of those
"We're all guilty..." kind of situations. My concern is that if this
language wants to have a bigger, better, brighter future, it needs to
provide things that are bigger, better and brighter than what other
languages already offer. It cannot continue to lag behind what developers
can get elsewhere and expect to attract new adherents. In that sense, we've
got a lot of catching up to do and that will require staying focused on
what's important to moving the mission forward.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:aa8ssi$qjr$1@a1-hrz.uni-duisburg.de...
>
> Wouldn't you want, in a language like Ada, the programmer to be
> able to choose an appropriate specific map implementation and
> use that for the real thing behind a declared map, and _then_
> FORGET about it most of the time. No need to think about the
> general solution, because you will still be writing programs AS IF
> there is a general solution, namely by using an interface,
> the Map interface. And if there _is_ a standardised Map
> interface, implementors, producers, vendors can glue their
> specific implemention(s) to that interface, and you as a
> programmer will still be writing essentially portable code,
> since only the few lines where a specific container that offers
> the Map interface is chosen.
>

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

"Brian Gaffney" <Brian.Gaffney@myrealbox.com> wrote in message
news:5e9b8c34.0204241829.67633bdf@posting.google.com...
>
> If I get your intent, I don't think this would work since Grace.List
> would be generic.  (Which would be a pain if you needed Bounded
> because you didn't wish to instantiate an Unbounded.)
>
O.K. So maybe we just need Grace.Lists and Grace.Bounded_Lists? Probably,
90% of the uses will just want a dynamically allocated, linked list
implementation as being Good Enough(tm). Hence, it can benefit from the
shorter name. Lesser demand packages can have longer names either by
dotted-child notation or just more detailed names.

Or we could just invent new names to describe data structures with different
characteristics as I suggested somewhat less seriously elsewhere. You could
have Grace.Lists, Grace.BLists, Grace.Whatever.... So long as it is
documented what the characteristics of a BList are, we don't have a problem.
Or completely make up new names that don't play to anyone's preconceived
notions of what they are.Grace.Rosters? Grace.Rolls? Grace.Catalogs? There
you've got three more names to describe lists with different caracteristics.


>
> I like the Grace.Containers.Lists idea.  Perhaps the children could be
> something like Grace.Containers.Bounded.Lists?  Then you could have a
> Grace.Containers.Maps and Grace.Containers.Bounded.Maps, etc.  I don't
> know how well this would extend to other types of containers.
>
We've got to be *real* careful not to make a naming scheme that tries to
have so many branches to such a depth that everyone will later decide that
it is a Royal Pain In The Posterior to use it. If we start creating subtrees
to describe implementation strategies and characteristics, where does it
end? Grace.Containers.Bounded.Task_Safe.Realtime.Deterministic.Maps? :-) We
can't solve *all* the problems today. A Grace.Containers.Lists and
Grace.Containers.Maps is probably sufficient granularity for now and a
sub-branch could be created later if there is any real need. (Some flavor of
Grace.Bounded_Containers? Although I'd favor shorter names for these things.
Like Grace.Boxes or Grace.Jars - or even an acronym.)


> Another way to get a default (assuming anyone could stand it) would be
> to provide the different version (unbounded, bounded, etc.) and uses a
> renames to define the 'default' type (i.e. generic package
> Grace.Containers.Lists renames Grace.Containers.Unbounded.Lists).

Apply the K.I.S.S. principle here. One of the design criteria was that it be
relatively easy to explain to students - and that was one of the reasons
people had objections to the Booch Components. Too many layers and too much
complexity for the average beginner to make good use of it. Providing a
default renaming of some alternate implementations might not be a bad way to
go, but I'm wondering if it would create too much confusion? Would it be
easy to explain to a beginner?

I think that so long as the tree structure is extensible without too much
pain, it will be satisfactory. One day, we might want a bunch of packages
with the power of the Booch Components & I could see building it under a
heading Grace.Rich_Containers (or whatever) but we need to continue to have
something reasonably simple and straightforward to handle a large percentage
of the needs without too much pain.

MDC


--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Marin David Condic wrote:
> This is just a guess based on years of experience building apps - not any
> sort of statistical survey. Most of the time that you are likely to use maps
> in a garden variety program, they will be used to store a relatively small
> amount of data. A few dozen directory names with a few hundred files under
> them, might be one example. A few hundred employees indexed by SSN, might be
> another. *Most* of the time, I'd suspect you're dealing with some number
> less than 1000.

While I think this is true of in-memory maps, I think it would be most
excellent if we also had disk-based maps (b-trees, for example) that had
the same package interface. It doesn't have to be there day one, but I
think it's worthwhile double-checking the API to make sure there's
nothing there that implies all the data is in memory at once.

> alternate implementations?" My guess is that the best solution is to pick
> one that will handle the general cases needed for maps reasonably well and
> that will be easy to implement and move on.

Sure. I think that's what was being discussed. :-)
 
-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

In the olden days, disk based maps were called "ISAM Files" :-)

1) As long as we have some kind of stream based mechanism to be able to
load/store a map or list to a file, this ought to account for *most* uses of
the data structures since it has to get pretty big to start causing problems
in today's world of cheap & virtual memory.

2) If you want some version of an ISAM file, that's fine, but it *is* a file
so it will likely have needs beyond what an in-memory structure would
require. At that point, I'd say you'd want to at least have a high level of
similarity between the interfaces, but I wouldn't feel the need to have a
slavish compatibility between the two. We should put it in our back pocket
for another day and just be sure that whatever spec is built for Maps, that
it is sufficiently abstract to hide the particulars of the implementation.
That really ought to be enough.

3) Speaking of files, couldn't Ada benefit from having a "Standard" RDBMS?
There used to be AdaSage, but I don't think it was a generic DBMS thing. I
don't even know if it gets much use these days or if it is being actively
maintained. Is there something that could be declared "The Conventional Ada
Answer" for an RDBMS?

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Darren New" <dnew@san.rr.com> wrote in message
news:3CC83282.69C1884F@san.rr.com...
>
> While I think this is true of in-memory maps, I think it would be most
> excellent if we also had disk-based maps (b-trees, for example) that had
> the same package interface. It doesn't have to be there day one, but I
> think it's worthwhile double-checking the API to make sure there's
> nothing there that implies all the data is in memory at once.
>

Re: Outside view (still): Development process in the Ada community

[Michael Erdmann]

Florian Weimer wrote:
> Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> 
> 
>>>There is already a contribution process: submit a patch to
>>>gcc-patches@gcc.gnu.org. ;-)
>>>
> 
>>But this has more the falvour of beeing an error correction
>>process!?
>>
> 
> Yes, your patch is subjected to review, of course.
> 
> Or do you think that the list is for GCC bug fixes only?  This is
> wrong, all patches (even patches adding new features) should be sent
> to this list for consideration.
> 

This is new to me!

Re: Grace and Maps (was Re: Development process in the Ada community)

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I certainly have no objection to providing alternate structures that offer
> different performance benefits, but the important thing is to get a general
> solution available that will work well enough for most of the programmer's
> needs. (I'd see those as being "easy to use" and "works reliably", rather
> than "must have optimal performance".)

I agree. And making the Grace maps "the same as Python" or "the same
as Perl" would be good too. Let's reuse the design experience those
environments have.

-- 
-- Stephe

Re: Grace and Maps (was Re: Development process in the Ada community)

[David Bolen]

Jean-Marc Bourguet <jm@bourguet.org> writes:

> David Bolen <db3l@fitlinxx.com> writes:
(...)
> > Yes, total operations for insertion/deletion is lg n - but the
> > question was the difference between red-black and AVL (both of which
> > are balanced trees with O(lg n)), and the difference there is how many
> > actual rotations you perform while re-balancing the tree.
> 
> There is an isomorphism between Red-Black trees and B-Trees (if this
> is not clear, look for 2-3 and 2-3-4 trees in the litterature, if
> memory serves Aho's books on algorithms is a good place) and rotation
> with color change are the equivalent of bucket split/merge.  As on
> insertion or deletion in a B-Tree, the number of bucket split/merge is
> O(lg n) -- I think this is easier to see --, it is true also of the
> number of rotation in a Red-Black trees when rebalancing after an
> insertion/deletion.

Hmm, this may just be a terminology issue, and I'm far from an expert
on these algorithms, but I did take a quick double check in Cormen's
Intro to Algorithms before that last reply and sections 13.3 and 13.4
cover insertion and deletion and the analysis of only 2 and 3
rotations respectively.

Note that I'm not suggesting that the running time is anything other
than O(lg n), which is definitely true for both operations; just that
the actual number of rotations performed (adjustment of location
within the tree of internal nodes) as the tree is traversed during the
rebalancing is more limited with red-black trees.  Of course, during
the overall process nodes may be re-colored without being rotated, but
while such color changes are part of re-balancing, I don't consider
them a "rotation".

> Examples: insert numbers from 1 to 17 in this order in a red-black trees.
>           delete the numbers from 1 to 8 in this order in the
>           resulting tree.

I tried a quick test of this using the RB implemention in the GNU
libavl library, and in this particular case never found more than a
single rotation per insertion/deletion:

I found (R=rotation, r=red, b=black):

Insertion: 1,2,3R,4,5R,6,7R,8R,9R,10,11R,12R,13R,14,15R,16R,17R
        1: 1b
        2: 1b(,2r)
   R    3: 2b(1r,3r)
        4: 2b(1b,3b(,4r))
   R    5: 2b(1b,4b(3r,5r))
        6: 2b(1b,4r(3b,5b(,6r)))
   R    7: 2b(1b,4r(3b,6b(5r,7r)))
   R    8: 4b(2r(1b,3b),6r(5b,7b(,8r)))
   R    9: 4b(2r(1b,3b),6r(5b,8b(7r,9r)))
       10: 4b(2b(1b,3b),6b(5b,8r(7b,9b(,10r))))
   R   11: 4b(2b(1b,3b),6b(5b,8r(7b,10b(9r,11r))))
   R   12: 4b(2b(1b,3b),8b(6r(5b,7b),10r(9b,11b(,12r))))
   R   13: 4b(2b(1b,3b),8b(6r(5b,7b),10r(9b,12b(11r,13r))))
       14: 4b(2b(1b,3b),8r(6b(5b,7b),10b(9b,12r(11b,13b(,14r)))))
   R   15: 4b(2b(1b,3b),8r(6b(5b,7b),10b(9b,12r(11b,14b(13r,15r)))))
   R   16: 4b(2b(1b,3b),8r(6b(5b,7b),12b(10r(9b,11b),14r(13b,15b(,16r)))))
   R   17: 4b(2b(1b,3b),8r(6b(5b,7b),12b(10r(9b,11b),14r(13b,16b(15r,17r)))))
 
	       +----------- 4b ----------+ 
	  +-- 2b --+            +------- 8r -------+
	 1b        3b      +-- 6b --+        +---- 12b ----+
			  5b        7b  +- 10r -+       +- 14r -+
				       9b       11b   13b    +- 16b -+
							   15r       17r

Deletion: 1R,2R,3R,4R,5R,6R,7R,8R
   R   1: 8b(4b(2b(,3r),6r(5b,7b)),12b(10r(9b,11b),14r(13b,16b(15r,17r))))
   R   2: 8b(4b(3b,6r(5b,7b)),12b(10r(9b,11b),14r(13b,16b(15r,17r))))
   R   3: 8b(6b(4b(,5r),7b),12b(10r(9b,11b),14r(13b,16b(15r,17r))))
   R   4: 8b(6b(5b,7b),12b(10r(9b,11b),14r(13b,16b(15r,17r))))
   R   5: 12b(8b(6b(,7r),10r(9b,11b)),14b(13b,16b(15r,17r)))
   R   6: 12b(8b(7b,10r(9b,11b)),14b(13b,16b(15r,17r)))
   R   7: 12b(10b(8b(,9r),11b),14b(13b,16b(15r,17r)))
   R   8: 12b(10b(9b,11b),14b(13b,16b(15r,17r)))

			 +---- 12b ----+
		    +- 10b -+       +- 14b -+
		   9b       11b   13b    +- 16b -+
				       15r       17r


--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: Grace and Maps (was Re: Development process in the Ada community)

[Simon Wright]

Darren New <dnew@san.rr.com> writes:

"<" vs hash]

>             On the other hand, most of the built-in types and
> metatypes ("record", "array", etc) already have ordering operators
> or rules on how to deduce them from the components.

One of my examples is the Vehicle type, keyed by [licence issueing
office + licence serial code] (both strings): a sort is just as
artificial as a hash, I think.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Simon Wright]

John English <je@brighton.ac.uk> writes:

> Marin David Condic wrote:
> > 
> > What do other languages provide with maps? MFC? STL? I'll bet you can get
> > items sorted on the key.
> 
> A common approach is to provide a way to get a list of keys, which
> you can then sort as you wish before using it to extract elements,
> rather than building all the same old sorting functionality into
> yet another data structure.

This is certainly the BC approach.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> 3) Speaking of files, couldn't Ada benefit from having a "Standard" RDBMS?
> There used to be AdaSage, but I don't think it was a generic DBMS thing. I
> don't even know if it gets much use these days or if it is being actively
> maintained. Is there something that could be declared "The Conventional Ada
> Answer" for an RDBMS?

http://sourceforge.net/projects/gnade/

This is a "standard" interface to databases, both via ODBC, and direct
to a few open source dbms. I don't see any need to reimplement a dbms
in Ada.

-- 
-- Stephe

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Marin David Condic wrote:
> In the olden days, disk based maps were called "ISAM Files" :-)

Actually, I think that was IBM nomenclature for an access mode. I've
seen "KSAM" as well (Keyed Sequential Access Method) to get around the
trademarks. But yes, ISAM was that API to disk-based maps, with b-trees
or whatever being the implementation.
 
> 1) As long as we have some kind of stream based mechanism to be able to
> load/store a map or list to a file, this ought to account for *most* uses of
> the data structures since it has to get pretty big to start causing problems
> in today's world of cheap & virtual memory.

Hrm. Maybe, maybe. Depends on what kind of program you're writing. I'd
hate to suck up and blow out a 10-meg stream file for every hit on my
CGI site where I want to look up one record out of 100,000.

Now, what *would* be cool is if the read-stream routines for the ISAM
implementation could understand the write-stream results from the
in-memory set. Then moving from your suggestion to a "real" disk-based
database is a matter of sucking it in once, then stuffing it into the
disk-based map.

> 2) If you want some version of an ISAM file, that's fine, but it *is* a file
> so it will likely have needs beyond what an in-memory structure would
> require. At that point, I'd say you'd want to at least have a high level of
> similarity between the interfaces, but I wouldn't feel the need to have a
> slavish compatibility between the two. We should put it in our back pocket
> for another day and just be sure that whatever spec is built for Maps, that
> it is sufficiently abstract to hide the particulars of the implementation.
> That really ought to be enough.

I think that was my suggestion. Obviously, you'd need stuff like a file
name, a utility to perhaps pack the file down to minimum size, etc. But
my intent in saying they had the same spec was to imply that in actuall
*access* routines, there needn't be arbitrary changes to the API. Open
and close, sure. But not iterating thru the records, adding or deleting,
etc.

> We've got to be *real* careful not to make a naming scheme that tries to
> have so many branches to such a depth that everyone will later decide that
> it is a Royal Pain In The Posterior to use it.

Yah. Welcome to Java, where you need to instantiate half a dozen
abstract mail APIs just to send an email message that's a printf in C.
:-)
 
-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

"Darren New" <dnew@san.rr.com> wrote in message
news:3CC98B8E.D49A2CEE@san.rr.com...
>
> Hrm. Maybe, maybe. Depends on what kind of program you're writing. I'd
> hate to suck up and blow out a 10-meg stream file for every hit on my
> CGI site where I want to look up one record out of 100,000.
>
O.K., but that's where I'm saying we're looking at 10% of the usages. If we
presume that most of the time, we're talking about maps to hold a few
hundred employee's records, or a few dozen directories & files or whatever
an average map is likely to be used for. The structure should fit into
available memory rather easily & you may only need load/store for
persistence between program runs. If you have a few hundred thousand on up
of something, then you probably want some kind of file since you don't want
to load/store the whole thing - just access/update individual items. For
that, you have an alternative file-based map that will have a similar, but
not identical, interface.

What percentage of the time would you think that an in-memory map might be
just fine? My personal guess would be that if I had an in-memory map it
would satisfy maybe 80% to 90% of the instances where I'd need a map. (YMMV)
Getting that far would satisfy some reasonably large need and the rest we
can worry about as an extra package to be added at a later date.



>
> I think that was my suggestion. Obviously, you'd need stuff like a file
> name, a utility to perhaps pack the file down to minimum size, etc. But
> my intent in saying they had the same spec was to imply that in actuall
> *access* routines, there needn't be arbitrary changes to the API. Open
> and close, sure. But not iterating thru the records, adding or deleting,
> etc.
>
O.K. Sounds like we agree. Package 1 defines the interface needed for an
in-memory map with facilities to get them in and out of streams. Package 2
defines the interface for a disk-based map that probably doesn't need
streams but would need certain file manipulation capabilities. For the
garden variety add/change/delete and scan kinds of stuff, there doesn't need
to be any difference in the interface presented. But you can't just unplug
the one and substitute the other because of some different requirements.


>
> Yah. Welcome to Java, where you need to instantiate half a dozen
> abstract mail APIs just to send an email message that's a printf in C.
> :-)
>
Sometimes, you can't avoid it, but I'd prefer to keep the names for the
things that will get used most commonly short and sweet. Don't make it
painful to use basic lists and basic maps. We can always create special
flavors that have longer names and if you need the capabilities, you put up
with the typing burden. But can you imagine the heat Ada would take if
instead of being able to declare an object as an Integer, you had to do some
version of Ada.Numerics.Scalars.Whole.Bounded.Integer? :-) Or if you simply
wanted to output an integer to the screen you had to do something like
"package My_Integer_IO is new Ada.Text_IO.Integer_IO (Num => Integer) ;"?
Wait a minute.... Ooopps! :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Development process in the Ada community

[Randy Brukardt]

Simon Wright wrote in message ...
>"Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> Of course, a "modest PC" now has 100 times the memory and is 100
>> times faster. Hardly a fair comparison. About the only difference is
>> the cost ($99 versus nothing). Certainly Janus/Ada "basically
>> worked".
>
>Yep, I remember that! Even so far as having shared generics, if I
>remember correctly.


Yes, Janus/Ada 95 still has shared generics. Really ugly to get right in
Ada 95 (Ada 83 was much easier that way).

             Randy.

Re: Wish List : Ada95 to FOX

[rc211v]

On Tue, 23 Apr 2002 17:27:27 GMT, "Warren W. Gay VE3WWG"
<ve3wwg@home.com> wrote:

>that Qt did. It would be reeeeaaal nice (hint) to have an Ada95
>binding to this. I havn't looked at it in detail, so I don't know
>how practical this is (written in C++).
>
>I think FOX might permit this type of a binding to be accomplished.
>
>I also like the fact that FOX is designed to permit dynamic
>messaging between widgets. Qt and MFC for example, are fixed at
>compile time by MOC/macros AFAI know.

I'm glad that you looked at it. 

I'm not a real programmer nor an expert in the gui domain but i
downloaded the library and some examples in source code form.

Under MSVC++, everything compiled without a single problem in less
than five minutes on my laptop (a thinkpad 600x running XP). The
calculator demo is compiled in a few seconds. When you start the demo,
it loads instantly, faster than a native Windows application! 

From what i've seen, the approach promoted by it's designer (Write
Once, Compile Anywhere) seems valid and very efficient in terms of
speed and hardware ressources.

As a regular reader of this ng i posted this after someone talked
about the strength of ADA in terms of portability. A binding with this
library would just enhance this portability in the Gui area. 

Cordially

Re: Grace and Maps (was Re: Development process in the Ada community)

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> O.K. Sounds like we agree. Package 1 defines the interface needed
> for an in-memory map with facilities to get them in and out of
> streams. Package 2 defines the interface for a disk-based map that
> probably doesn't need streams but would need certain file
> manipulation capabilities. For the garden variety add/change/delete
> and scan kinds of stuff, there doesn't need to be any difference in
> the interface presented. But you can't just unplug the one and
> substitute the other because of some different requirements.

The BCs already do 'Input and 'Output for Maps (and indeed many other
container kinds; provided you use GNAT 3.14 or later!). The problem
it seems to me with disk-based containers is that you need to think
very hard about whether they're limited or not; what does assignment
mean for disk-based maps? overwrite, I suppose?

Creation is interesting, too. If you say

  M : Disk_Based_Map;

how do you make sure it's associated with a file? ... well, I guess
that's easy:

  procedure Associate (M : in out Disk_Based_Map;
                       With_File_Named : String);

and raise an exception (No_Associated_File) if the punter tries to use
it before association.

I certainly would expect a Disk_Based_Map to be in Abstract_Map'Class
(perhaps just because that's the way the BCs do it).

Re: Development process in the Ada community

[Michael Erdmann]

After having a long discussion with several people in the
community i think we should proceed in the following way:

Setup a project with the following objectives:

* Creation of a Ada support library which ranges from
   light to havy weight packages till end of this year
   which are making lfe easier.

* In long terms the library should become a defacto
   standard for the Ada community and should be
   boundeld with Ada compilers.

* The licensing of the library will be the commonly
   used FSF 2.0 Liecense with the exceptions listed

   "As a special exception,  if other files  instantiate
    generics from this unit, or you link  this unit with
    other files  to produce an executable, this  unit
    does not  by itself cause  the resulting  executable
    to be covered  by the  GNU  General  Public  License.
    This exception does not however invalidate  any other
    reasons why  the executable file  might be covered
    by the  GNU Public License.."

To achive this the following principles shall be applied:

* Since the idea is to establish a code base relatively
   fast reuse goes over redesign.

* This first component delivered for a certain domain
   defines the base from where the development start.

* For each domain a chmpion has to be defined who is
   in charge of organizing the  packages in the
   hirarchy of his domain, but she/he shall take only
   a minimal influence on the contents of the packages.

* The contents of the packages is completly in the
   responsibility of the package author.

* Please no extensive style discussions, a common style
   will evolve during the first iterations of the
   project.

* Technical discussions? yes, but please keep in mind,
   that the idea is to produce a code base till end
   of the year. Not always the technically best solution
   is needed in the market. A timely solution to a
   problem is the one which counts!

* Documentation is part of the source code. This is
   the only restriction to the contents of the packages.
   It has to be possible to extract automatically
   the package documentations.

Since i have a project at sourceforge.net with the
name ASCL (Application Standard Component library) but
no activity any more i would be willing to drop the
current contents of this project and reorganize it
for this project called:

     Ada Standard Component Library - ASCL

Currently i do see the following domains:

Networking
Communication
Data structures (Containers, lists .....)
Files
Configuration

Any thing i forgot?

Any how i like to invite every body in the community
to spend some time in checking there repositories
for usefull components. If you find something
usefull (which means you already used it your self)
or if you are willing to be the champion of a domain
simply send me a mail, that we get organized!

So lets try it again!

Regrads
     M.Erdmann

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ole-Hjalmar Kristensen]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> What I imagine is that a Map package spec can be designed that basically
> allows for insertion, deletion & update of individual elements and contains
> some kind of abstraction to walk through the elements of the map and some
> means of making the data persistent. I imagine that the Version-1.0
> implementation will be something that supports reasonable access time for
> average use. There can be 1024 different implementations behind it that
> satisfy any particular implementor's desires if some vendor or some user
> wants to do something totally different for whatever reasons. The Mark 1,
> Mod 0 Grace implementation just needs to be *an* implementation that works
> reasonably well.
> 
> The danger is that this discussion is going to drift off expounding
> endlessly on the relative merits of hash tables versus b-trees versus
> who-knows-what. The mission was to come up with a specification that would
> present the developer with something consistent with the spec for
> Grace.Lists, yet provided the operations that would be needed & expected for
> a map. It doesn't need to be perfect. It doesn't need to be optimal for all
> uses. It doesn't need to be the final word on indexed data structures. It
> needs to *exist* and be acceptable to a reasonably large majority of Ada
> users. After that, it can be polished and polished and polished until it
> shines like the sun. After that, any number of variations on a theme can be
> composed to satisfy whatever different criteria someone may have. That's the
> beauty of being able to create child packages or utilize inheritance - we
> can create those variations easily.
> 
> Maybe this is an ongoing problem we Ada programmers have - we so much want
> to find the perfect solutions that we tend to forget some important
> practical concerns. Lots of competing languages *already* have libraries
> full of stuff - including Maps. Those competing languages don't present
> every possible implementation or even an optimal implementation. What they
> present is something that an implementor will find useful *today* to get
> their job done. If all Ada can promise is "One day, its going to be really,
> really great!!!" developers are going to continue to choose C++, Java, etc.,
> where the promise is: "Here's the leverage you need to get an app built fast
> right now..."
> 

<snip>

For an interesting discussion about perfect vs. good enough, see the
link below or do a search on "worse is better"....

http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html

Re: Grace and Maps (was Re: Development process in the Ada community)

[Larry Kilgallen]

In article <aac468$3hh$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> What percentage of the time would you think that an in-memory map might be
> just fine? My personal guess would be that if I had an in-memory map it
> would satisfy maybe 80% to 90% of the instances where I'd need a map. (YMMV)
> Getting that far would satisfy some reasonably large need and the rest we
> can worry about as an extra package to be added at a later date.

Just as I can change:

	Result := By_Location ( US, Massachusetts, Cambridge );

from an array access to a function call at will,

access to sparse data (which is my understanding of what you folks
mean by "maps") should be the same from the client programmer view
regardless of whether the data is in memory or on disk.

Re: Development process in the Ada community

[Robert Dewar]

Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CCA609F.9030503@snafu.de>...

> * In long terms the library should become a defacto
>    standard for the Ada community and should be
>    boundeld with Ada compilers.

Don't count on this kind of bundling. Speaking for ACT, we
would only bundle a library if:

  a) our customers actively needed a supported version
  b) we had the resources to provide full support

I think it's still a success to generate some useful packages
even if they don't get bundled by vendors.

> * Please no extensive style discussions, a common style
>    will evolve during the first iterations of the
>    project.

That seems a mistake to me, it is very difficult to impose a common
standard later on. Why not at least adopt -gnaty as a starting point
together with the general guidelines in AQ&S. I don't think -gnaty
is someone better than some other possible standard, but consistency
is important, and it is important to agree on something.

> Any how i like to invite every body in the community
> to spend some time in checking there repositories
> for usefull components. If you find something
> usefull (which means you already used it your self)
> or if you are willing to be the champion of a domain
> simply send me a mail, that we get organized!

A reasonable invitation! Most certainly ACT spends quite
a bit of time generating such components, and they get
put in our GNAT library, which is available for anyone
to look at and either use, or derive inspirations from :-)

Robert Dewar
Ada Core Technologies

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Marin David Condic wrote:
> What percentage of the time would you think that an in-memory map might be
> just fine? My personal guess would be that if I had an in-memory map it
> would satisfy maybe 80% to 90% of the instances where I'd need a map. (YMMV)
> Getting that far would satisfy some reasonably large need and the rest we
> can worry about as an extra package to be added at a later date.

I agree 100%. I'm just saying that one should check that other than
instantiation and destruction, one should be able to do the same things
with the new package as you did with the old. I dunno, maybe this goes
without saying in Ada, but (for example) making iterators private so you
can't easily get locked into knowing they're memory addresses instead of
file offsets, things like that. Of course, locking comes into it too,
once you get to disk-based stuff, so I think the disk stuff will be a
*superset* of the memory-based stuff. Perhaps you could even map an
instantiation of a disk-based map using the memory-based instantiator
into a temp-file-based map. But yes, this is just idle rambling at this
point.

I think another good thing would be to define the behavior of the map if
it's modified while you're iterating. Or to at a minimum make it clear
that the behavior is undefined. But if you're using a sorted map, it
shouldn't be hard to define the behavior in a relatively intuitive way.

Perhaps all I really need to be saying is that it's likely you want a
tagged type for the lists and maps, just so they *can* be extended in
the future.

> O.K. Sounds like we agree. Package 1 defines the interface needed for an
> in-memory map with facilities to get them in and out of streams. Package 2
> defines the interface for a disk-based map that probably doesn't need
> streams but would need certain file manipulation capabilities. For the
> garden variety add/change/delete and scan kinds of stuff, there doesn't need
> to be any difference in the interface presented. But you can't just unplug
> the one and substitute the other because of some different requirements.

Right. I think that's good. I'd include the streams in version 2, if
only for stuffing said maps over network connections, upgrading formats
to newer versions, etc.

Everything I snipped, I agree with.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Development process in the Ada community

[Michael Erdmann]

Robert Dewar wrote:
> Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CCA609F.9030503@snafu.de>...
> 
> 
>>* In long terms the library should become a defacto
>>   standard for the Ada community and should be
>>   boundeld with Ada compilers.
>>
> 
> Don't count on this kind of bundling. Speaking for ACT, we
> would only bundle a library if:
> 
>   a) our customers actively needed a supported version
>   b) we had the resources to provide full support
> 
> I think it's still a success to generate some useful packages
> even if they don't get bundled by vendors.

I dont count on it, this is just an statement of intention!


>>* Please no extensive style discussions, a common style
>>   will evolve during the first iterations of the
>>   project.
>>
> 
> That seems a mistake to me, it is very difficult to impose a common
> standard later on. Why not at least adopt -gnaty as a starting point
> together with the general guidelines in AQ&S. I don't think -gnaty
> is someone better than some other possible standard, but consistency
> is important, and it is important to agree on something.

But i won't reject a package for style reasons, if it does
what it is expected to do.

I like to avoid discussions about the form of identifiers,
e.g. Container_Type or simply Container.

Sure complete anarchy has to be avoided,
but i like to discuss this issue on a case to case
basis not in general

> 

>>Any how i like to invite every body in the community
>>to spend some time in checking there repositories
>>for usefull components. If you find something
>>usefull (which means you already used it your self)
>>or if you are willing to be the champion of a domain
>>simply send me a mail, that we get organized!
>>
> 
> A reasonable invitation! Most certainly ACT spends quite
> a bit of time generating such components, and they get
> put in our GNAT library, which is available for anyone
> to look at and either use, or derive inspirations from :-)

I hope it works out!

M.Erdmann

Re: Shared generics

[Hyman Rosen]

Randy Brukardt wrote:
> Yes, Janus/Ada 95 still has shared generics. Really ugly to get right in
> Ada 95 (Ada 83 was much easier that way).

I have a question about Ada generics. If I have understood
my text book correctly, one can instantiate a generic with
a local variable as a parameter. This is different from C++,
where a variable used as a generic parameter must be global.
So it seems to me that at least some Ada generics *must* be
implemented by sharing, rather than *can* be.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

I liked the article. I'm not sure I agree that the only two alternatives are
to a) build a perfect system that takes forever to get there or b) build a
lousy system that gets out quickly. I *do* agree that a lousy system that
gets out first and still manages to fill a void is going to generally become
the dominant thing and not allow the "perfect" system that's still in the
lab to get a toe-hold in the marketplace. But why does "Quick" have to
equate to "Lousy"? Couldn't it equate to
"Small-And-Incomplete-But-A-Solid-Basis-On-Which-To-Build"?

My contention would be that it is better to get some useful piece of the
"perfect" solution out there early. When we're talking about the Grace
components, this would be some version of "Get a couple of useful data
structures out there that more-or-less are accepted as the 'conventional
answer' and then build from there." (If Grace.Lists and Grace.Maps got
accepted and shipped with compilers, we'd have A Good Start. The interfaces
are not weak and the design is not poor - just not the answer to all
problems, everywhere.)

This is a similar situation to the AdaOS discussion going on in another
thread. If the AdaOS project had enough software to build a successful
bootstrap and kernel that allowed someone to load one or more programs &
execute, then it would constitute A Good Start that would likely mushroom
from there. If the RTEMS kernel could be used as a kick-off point, maybe
that's a good thing. So what if it doesn't have all the security one might
want or that its a realtime scheduler (on which a non-realtime scheduler
could be built!) - its there and it works. Get a "kit" built that would let
someone compile it with Gnat for a PC and build a bootable floppy. Add on to
it so it could load/execute some rudimentary programs from a floppy. At that
point, you've got a project going that could be enhanced over time.

Maybe RTEMS isn't the right answer - it does present a POSIX interface so
its Just Another Realtime OS rather than being something unique and Ada-ish.
But if it were used to simply provide the RTK (and some device drivers) for
a monolithic realtime Ada program (sounds like an apt description of an OS
to me!), it would allow building a more "Ada-ish" OS on top of it. Possibly
there are other answers that could be made to work even better. But the
point is that getting something out there *NOW* is a whole lot better than
waiting around forever for a thousand other things to get done so that a
"perfect" system can be eventually built. Get the scope of the project down
to something that would be A Good Start & there's no reason that this small
piece can't be well designed and well implemented. It doesn't have to be a
turd to succeed - it could be a diamond-like jewel. Just make it a *SMALL*
jewel that a beginning jeweler can afford to buy and put in a setting. Add
more gems later.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote in message
news:7vvgadecxc.fsf@vlinux.voxelvision.no...
>
> For an interesting discussion about perfect vs. good enough, see the
> link below or do a search on "worse is better"....
>
> http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

Maybe there doesn't need to be a DBMS built in Ada, but it might be nice to
present a "conventional" answer for database work from Ada. IOW, if an
interface to one or more DBMS's is adopted as the "convention" and it ships
with compilers (and maybe an open source DBMS so it all just works right out
of the box) and books get written on how to use Ada with its "conventional"
interface to a database, all that starts to conspire to present the
developer with a really big leverage package. Can C++ interface to a dbms?
Sure. Does your average C++ compiler come with a "standard" interface to a
DBMS and a working open source DBMS so you can just start programming a
database out of the box? No? Boy that sounds like an opportunity to create
some product distinction and offer lots of leverage to the developer to me!

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uwuuu1kx8.fsf@gsfc.nasa.gov...
>
> This is a "standard" interface to databases, both via ODBC, and direct
> to a few open source dbms. I don't see any need to reimplement a dbms
> in Ada.
>

Re: Grace and Maps (was Re: Development process in the Ada community)

[Hyman Rosen]

Marin David Condic wrote:
> some means of making the data persistent

Why? What does persistence have to do with maps?
Besides, doesn't Ada already have serialization
for this kind of thing?

Re: Grace and Maps (was Re: Development process in the Ada community)

[Darren New]

Hyman Rosen wrote:
> 
> Marin David Condic wrote:
> > some means of making the data persistent
> 
> Why? What does persistence have to do with maps?

It's orthogonal and highly useful, so it's worth making sure it works.

> Besides, doesn't Ada already have serialization
> for this kind of thing?

Yes, but you have to make it work, yes? It's not automatic. I think the
point *I* was making was that if you define the actual format on the
stream, then you can switch between implementations of maps by
serializing it out and back in again.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

That's sort of where I was going - a disk based map is going to have issues
of its own that will likely mean it can't have an interface that is
identical to a memory based map. Hence, the Grace components should just
concentrate on getting the memory based map interface right and possibly it
can later be used with adaptations for a disk based map.

Also, I have never had any objection to the BC's being adopted as the
"conventional answer" with the exception that it needed some stuff to
provide a "simple" answer for the uninitiate or the student. I'd still think
it might be a good idea to take something like the Grace components and
graft them onto the BC's in some manner that basically said: "If you need a
simple list or map, for some basic data, go with these components. If you
want to do really sophisticated stuff, then go with these alternate
components."

But then this has been hashed over before and nobody seems to be willing to
settle on one existing library unless its their personal favorite. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Simon Wright" <simon@pushface.org> wrote in message
news:x7vg01hzp2x.fsf@smaug.pushface.org...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
>
> The BCs already do 'Input and 'Output for Maps (and indeed many other
> container kinds; provided you use GNAT 3.14 or later!). The problem
> it seems to me with disk-based containers is that you need to think
> very hard about whether they're limited or not; what does assignment
> mean for disk-based maps? overwrite, I suppose?
>

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

I can't speak for what everyone else means by a map - I mean something where
I store and look up data based on a key. An ISAM file being a typical
example. I want to say "Put (Some_Social_Security_Number,
Some_Student_Record) ;" and "Get (This_SSN, The_Student_Record);" If that
constitutes "sparse data" then I guess that's fine.

If you had "Get" and "Put" and iterators and similar operations, those could
be common without respect to the actual implementation or storage mechanism.
But I think if the intention was to support some disk file with possibly
millions of records in it, then you would likely need a bunch of operations
that would make little to no sense for an in-memory, dynamically allocated,
linked structure. Hence, I'd opt to be as similar as possible, but not make
that a slavish goal.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:tW4Tz4KHL8Bt@eisner.encompasserve.org...
>
> access to sparse data (which is my understanding of what you folks
> mean by "maps") should be the same from the client programmer view
> regardless of whether the data is in memory or on disk.

Re: Shared generics

[Randy Brukardt]

Hyman Rosen wrote in message <3CCD5C64.2030303@mail.com>...
>Randy Brukardt wrote:
>> Yes, Janus/Ada 95 still has shared generics. Really ugly to get right
in
>> Ada 95 (Ada 83 was much easier that way).
>
>I have a question about Ada generics. If I have understood
>my text book correctly, one can instantiate a generic with
>a local variable as a parameter. This is different from C++,
>where a variable used as a generic parameter must be global.

Yes, of course generic instantiations can be in nested scopes, and there
are no restrictions on the parameters.

>So it seems to me that at least some Ada generics *must* be
>implemented by sharing, rather than *can* be.


Depends on what you mean here. Clearly, the instantiation will be
elaborated every time that the outer subprogram is called. So in that
sense, the generic is 'shared'. Of course, that means that you are
thinking of the subprogram body itself as 'shared' as well.

That is not the conventional meaning of 'shared' when talking about
generics. The basic idea is whether or not the code for the generic
appears at the point of the instantiation, tailored for the parameters.
Sharing occurs when two or more (textual) instantiations share part of
the code for the generic unit (usually the body). This can vary from
partial sharing (where what is shared depends on the parameters to the
instantiation) to universal sharing (where there is only a single copy
of the code for the generic unit, which is used by all instantiations).
When an instantiation occurs in a subprogram, there is only one copy of
the code for that instantiation, just as there is only one copy of the
code for the subprogram body. This is not considered that sharing,
because no (sane) implementation would generate multiple copies of the
code for a single subprogram body, and the instantiation is just part of
that body.

            Randy.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Simon Wright]

Hyman Rosen <hyrosen@mail.com> writes:

> Marin David Condic wrote:
> > some means of making the data persistent
> 
> Why? What does persistence have to do with maps?
> Besides, doesn't Ada already have serialization
> for this kind of thing?

Serialization (support of Ada.Streams) is only supported out of the
box for some types; not sure of the full details, but things
referenced by pointers are not included. So any unbounded container
will need some work.

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

Simon Wright <simon@pushface.org> wrote in message news:<x7vsn5d23l0.fsf@smaug.pushface.org>...
> Hyman Rosen <hyrosen@mail.com> writes:
> 
> > Besides, doesn't Ada already have serialization
> > for this kind of thing?
> 
> Serialization (support of Ada.Streams) is only supported out of the
> box for some types; not sure of the full details, but things
> referenced by pointers are not included. So any unbounded container
> will need some work.

Its supported out of the box for all types, but for some (eg:
pointers) it doesn't work so well. (Actually, it works just fine for
pointers too, as long as the program continues to run. :-)  ).

Yes, a container will need some work to make it do the "right thing"
for a stream read or write. I don't see any reason why that work
should not be done. I believe that what we had the Lists package do.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

The spec for the Lists certainly defines some stream operations that
provides for a solution to persistence as well as communication. Maps ought
to do the same. Personally, I think it would be handy to have a couple of
subprograms to explicitly load & store the structure from/to a stream file,
for the sake of simplicity. Some version of: "Here, I figured out a file for
you and went and opened it already - you go put/get your data to/from it and
I don't want to know how you did it..." But maybe that's just me... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0204300605.13180548@posting.google.com...
>
> Yes, a container will need some work to make it do the "right thing"
> for a stream read or write. I don't see any reason why that work
> should not be done. I believe that what we had the Lists package do.
>
>

Re: Grace and Maps (was Re: Development process in the Ada community)

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Maybe there doesn't need to be a DBMS built in Ada, but it might be nice to
> present a "conventional" answer for database work from Ada. 

That's the mission of GNADE.

> <snip>
> Can C++ interface to a dbms? Sure. Does your average C++ compiler
> come with a "standard" interface to a DBMS and a working open source
> DBMS so you can just start programming a database out of the box?
> No? 

Then the market must not want one. Database access has been around a
_long_ time, and is a _huge_ market!

What the market seems to want is Visual Basic-like tools, that make it
easy to build GUI interfaces, with data fields bound to databases.

Actually, SQL and ODBC are the conventional answers. GNADE provides
Ada bindings to ODBC, and SQL as either normal Ada strings, or a
preprocessed "embedded" language addon.
 
-- 
-- Stephe

Re: Grace and Maps (was Re: Development process in the Ada community)

[Marin David Condic]

Milton Freidman is walking down the street with his wife. She says "Honey,
there's a $20 bill lying on the sidewalk." Milton replies "You must be
mistaken dear. If there was a $20 bill on the pavement the market would have
picked it up a long time ago..." :-)

Yes, database access has been around for a long time. Are you sure there's
never been a compiler that shipped with a database at the same time? And met
with some market success? I don't know, but I'd suspect there were probably
some that had at least fairly primitive databases sold with them. I know if
I got one that just came along with the compiler, I'd make use of it -
especially if there was no effort to get it working as might be the case if
I wanted to do something like, say, interface to Oracle.

Maybe if Ada had a "conventional" interface to a database & possibly if
compilers included a usable database (maybe not with every feature possible,
but useful for something more than trivial projects) that fit that
interface, it would be something the market might take notice of. Especially
if the pitch was "You can get it to work on a dozen different
machines/compilers without changing a line of your application..." Its a big
"maybe" but sometimes it pays to float ideas and see what comes up.

Perhaps GNADE attempts to address this need and it might do so fairly well.
I don't know, not being in the database business for quite some time and
never having taken a look at GNADE. (I used to interface Ada to RDB via an
SQL precompiler a very long time ago in a galaxy far, far, away.) My biggest
objection would be that it is not (at present) part of "Conventional Ada"
and it might be tied to a specific compiler at this time. However, if it was
proposed as being "The Answer" and accepted as such, it might help add
leverage to Ada, making Ada a more attractive solution. A rising Ada tide
lifts all boats. If Ada is going to gain market share, it needs to offer
*more* leverage to the developer than other languages and a DBMS of some
sort sounds like "more" to me. Other ideas? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uelgxqf79.fsf@gsfc.nasa.gov...
>
> Then the market must not want one. Database access has been around a
> _long_ time, and is a _huge_ market!
>

Re: Grace and Maps (was Re: Development process in the Ada community)

[Simon Wright]

dennison@telepath.com (Ted Dennison) writes:

> Simon Wright <simon@pushface.org> wrote in message news:<x7vsn5d23l0.fsf@smaug.pushface.org>...
> > Serialization (support of Ada.Streams) is only supported out of the
> > box for some types; not sure of the full details, but things
> > referenced by pointers are not included. So any unbounded container
> > will need some work.
> 
> Its supported out of the box for all types, but for some (eg:
> pointers) it doesn't work so well. (Actually, it works just fine for
> pointers too, as long as the program continues to run. :-) ).

Unless you send the serialized pointer into a different address
context ..

Re: Grace and Maps (was Re: Development process in the Ada community)

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<aam9tu$9ja$1@nh.pace.co.uk>...
> The spec for the Lists certainly defines some stream operations that
> provides for a solution to persistence as well as communication. Maps ought
> to do the same. Personally, I think it would be handy to have a couple of

That would be my input as well.

> subprograms to explicitly load & store the structure from/to a stream file,
> for the sake of simplicity. Some version of: "Here, I figured out a file for
> you and went and opened it already - you go put/get your data to/from it and
> I don't want to know how you did it..." But maybe that's just me... :-)

Given that Ada.Streams.Stream_IO exists, you pretty much already have
that. If you opened the file using Ada.Streams.Stream_IO.Open (or
.Create), the rest is a one-liner.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html